./0002775000764400076440000000000013041752434010356 5ustar iustyiusty./draft-ietf-savi-mix-15.txt0000664000764400076440000005575513032476502015140 0ustar iustyiusty SAVI J. Bi Internet-Draft Tsinghua University Intended status: Standards Track G. Yao Expires: July 5, 2017 Tsinghua University/Baidu J. Halpern Ericsson E. Levy-Abegnoli, Ed. Cisco January 1, 2017 SAVI for Mixed Address Assignment Methods Scenario draft-ietf-savi-mix-15 Abstract In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 5, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Bi, et al. Expires July 5, 2017 [Page 1] Internet-Draft SAVI MIX January 2017 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Recommendations for assignment separation . . . . . . . . . . 5 6. Resolving binding collisions . . . . . . . . . . . . . . . . 6 6.1. Same Address on Different Binding Anchors . . . . . . . . 6 6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6 6.1.2. Exceptions . . . . . . . . . . . . . . . . . . . . . 7 6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 8 6.2. Same Address on the Same Binding Anchor . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction There are currently several Source Address Validation Improvement (SAVI) documents ([RFC6620], [RFC7513] and [RFC7219]) that describe the different methods by which a switch can discover and record bindings between a node's IP address and a binding anchor and use that binding to perform source address validation. Each of these documents specifies how to learn on-link addresses, based on the technique used for their assignment, respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each of these documents describes separately how one particular SAVI method deals with address collisions (same address, different binding anchor). While multiple IP assignment techniques can be used in the same layer-2 domain, this means that a single SAVI device might have to deal with a combination or mix of SAVI methods. The purpose of this document is to provide recommendations to avoid collisions and to Bi, et al. Expires July 5, 2017 [Page 2] Internet-Draft SAVI MIX January 2017 review collisions handling when two or more such methods come up with competing bindings. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Problem Scope Three different IP address assignment techniques have been analyzed for SAVI: 1. StateLess Address AutoConfiguration (SLAAC) - analyzed in SAVI- FCFS[RFC6620] 2. Dynamic Host Control Protocol address assignment (DHCP) - analyzed in SAVI-DHCP[RFC7513] 3. Secure Neighbor Discovery (SeND) address assignment, analyzed in SAVI-SEND[RFC7219] In addition, there is a fourth technique for managing (i.e., creation, management, deletion) a binding on the switch, referred to as "manual". It is based on manual binding configuration. Because how to manage manual bindings is determined by operators, there is not a new SAVI method for manual addresses. All combinations of address assignment techniques can coexist within a layer-2 domain. A SAVI device MUST implement the corresponding binding setup methods (referred to as a "SAVI method") for each such technique that is in use if it is to provide Source Address Validation. SAVI methods are normally viewed as independent from each other, each one handling its own entries. If multiple methods are used in the same device without coordination, each method will attempt to reject packets sourced with any addresses that method did not discover. To prevent addresses discovered by one SAVI method from being filtered out by another method, the SAVI binding table SHOULD be shared by all the SAVI methods in use in the device. This in turn could create some conflict when the same entry is discovered by two different methods. The purpose of this document is of two folds: provide recommendations and methods to avoid conflicts, and to resolve conflicts when they happen. Collisions happening within a given method are outside the scope of this document. Bi, et al. Expires July 5, 2017 [Page 3] Internet-Draft SAVI MIX January 2017 4. Architecture A SAVI device may implement and use multiple SAVI methods. This mechanism, called SAVI-MIX, is proposed as a arbiter of the binding generation algorithms from these multiple methods, generating the final binding entries as illustrated in Figure 1. Once a SAVI method generates a candidate binding, it will request SAVI-MIX to set up a corresponding entry in the binding table. Then SAVI-MIX will check if there is any conflict in the binding table. A new binding will be generated if there is no conflict. If there is a conflict, SAVI-MIX will determine whether to replace the existing binding or reject the candidate binding based on the policies specified in Section 6. As a result of this, the packet filtering in the SAVI device will not be performed by each SAVI method separately. Instead, the table resulting from applying SAVI-MIX will be used to perform filtering. Thus the filtering is based on the combined results of the differents SAVI mechanisms. It is beyond the scope of this document to describe the details of the filtering mechanism and its use of the combined SAVI binding table. Bi, et al. Expires July 5, 2017 [Page 4] Internet-Draft SAVI MIX January 2017 +--------------------------------------------------------+ | | | SAVI Device | | | | | | +------+ +------+ +------+ | | | SAVI | | SAVI | | SAVI | | | | | | | | | | | | FCFS | | DHCP | | SEND | | | +------+ +------+ +------+ | | | | | Binding | | | | | setup | | v v v requests | | +------------------------------+ | | | | | | | SAVI-MIX | | | | | | | +------------------------------+ | | | | | v Final Binding | | +--------------+ | | | Binding | | | | | | | | Table | | | +--------------+ | | | +--------------------------------------------------------+ Figure 1: SAVI-Mix Architecture Each entry in the binding table will contain the following fields: 1. IP source address 2. Binding anchor[RFC7039] 3. Lifetime 4. Creation time 5. Binding methods: the SAVI method used for this entry. 5. Recommendations for assignment separation If each address assignment technique uses a separate portion of the IP address space, collisions won't happen. Using non overlapping Bi, et al. Expires July 5, 2017 [Page 5] Internet-Draft SAVI MIX January 2017 address space across address assignment techniques, and thus across SAVI methods is therefore recommended. To that end, one should: 1. DHCP and SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set the A bit in Prefix information option of Router Advertisement for SLAAC prefix, and set the M bit in Router Advertisement for DHCP prefix. For detail explanations on these bits, refer to [RFC4861][RFC4862]. 2. SeND and non-SeND: avoid mixed environment (where SeND and non- SeND nodes are deployed) or separate the prefixes announced to SeND and non-SenD nodes. One way to separate the prefixes is to have the router(s) announcing different (non-overlapping) prefixes to SeND and to non-SeND nodes, using unicast Router Advertisements[RFC6085], in response to SeND/non-SeND Router Solicit. 6. Resolving binding collisions In situations where collisions can not be avoided by assignment separation, two cases should be considered: 1. The same address is bound on two different binding anchors by different SAVI methods. 2. The same address is bound on the same binding anchor by different SAVI methods. 6.1. Same Address on Different Binding Anchors This would typically occur in case assignment address spaces could not be separated. For instance, an address is assigned by SLAAC on node X, installed in the binding table using SAVI-FCFS, anchored to "anchor-X". Later, the same address is assigned by DHCP to node Y, and SAVI-DHCP will generate a candidate binding entry, anchored to "anchor-Y". 6.1.1. Basic preference If there is any manually configured binding, the SAVI device SHOULD choose the manual configured binding acnhor. For an address not covered by any manual bindings, the SAVI device must decide to which binding anchor the address should be bound (anchor-X or anchor-Y in this example). Current standard documents of address assignment methods have implied the prioritization relationship based on order in time, i.e., first-come first-served. Bi, et al. Expires July 5, 2017 [Page 6] Internet-Draft SAVI MIX January 2017 o SLAAC: s5.4.5 of [RFC4862] o DHCPv4: s3.1-p5 of [RFC2131] o DHCPv6: s18.1.8 of [RFC3315] o SeND: s8 of [RFC3971] In the absence of any configuration or protocol hint (see Section 6.1.2) the SAVI device SHOULD choose the first-come binding anchor, whether it was learnt from SLAAC, SeND or DHCP. 6.1.2. Exceptions There are two identified exceptions to the general prioritization model, one of them being CGA addresses[RFC3971], another one controlled by the configuration of the switch. 6.1.2.1. CGA preference When CGA addresses are used, and a collision is detected, preference should be given to the anchor that carries the CGA credentials once they are verified, in particular the CGA parameters and the RSA options. Note that if an attacker was trying to replay CGA credentials, he would then compete on the base of "First-Come, First- Served" (FCFS) principle. 6.1.2.2. configuration preference For configuration driven exceptions, the SAVI device may allow the configuration of a triplet ("prefix", "anchor", "method") or ("address", "anchor", "method"). The "prefix" or "address" represents the address or address prefix to which this preference entry applies. The "anchor" is the value of a known binding anchor that this device expects to see using this address or addresses from this prefix. The "method" is the SAVI method that this device expects to use in validating address binding entries from the address or prefix. At least one of "anchor" and "method" MUST be specified. Later, if a DAD message [RFC4861] is received with the following conditions verified: 1. The target in the DAD message does not exist in the binding table 2. The target is within the configured "prefix" (or equal to "address") 3. The anchor bound to target is different from the configured anchor, when specified Bi, et al. Expires July 5, 2017 [Page 7] Internet-Draft SAVI MIX January 2017 4. The configured method, if any, is different from SAVI-FCFS The switch SHOULD defend the address by responding to the DAD message, with a NA message, on behalf of the target node. It SHOULD NOT install the entry into the binding table. The DAD message SHOULD be discarded and not forwarded. Forwarding it may cause other SAVI devices to send additional defense NAs. SeND nodes in the network MUST disable the option to ignore unsecured advertisements (see s8 of [RFC3971]). If the option is enabled, the case is outside the scope of this document. It is suggested to limit the rate of defense NAs to reduce security threats to the switch. Or else, a malicious host could consume the resource of the switch heavily with flooding DAD messages. This will simply prevent the node from assigning the address, and will de-facto prioritize the configured anchor. It is especially useful to protect well known bindings such as a static address of a server over anybody, even when the server is down. It is also a way to give priority to a binding learnt from SAVI-DHCP over a binding for the same address, learnt from SAVI-FCFS. 6.1.3. Multiple SAVI Device Scenario A single SAVI device doesn't have the information of all bound addresses on the perimeter. Therefore it is not enough to lookup local bindings to identify a collision. However, assuming DAD is performed throughout the security perimeter for all addresses regardless of the assignment method, then DAD response will inform all SAVI devices about any collision. In that case, "First-Come, First- Served" will apply the same way as in a single switch scenario. If the admin configured on one the switches a prefix (or a single static binding) to defend, the DAD response generated by this switch will also prevent the binding to be installed on other switches of the perimeter. The SAVI MIX preferences of all the SAVI devices in the same layer-2 domain should be consistent. Inconsistent configurations may cause network breaks. 6.2. Same Address on the Same Binding Anchor A binding may be set up on the same binding anchor by multiple methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes obtained from the two methods are different, priority should be given to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least authoritative. The binding will be removed when the prioritized lifetime expires, even if a less authoritative method had a longer lifetime. Bi, et al. Expires July 5, 2017 [Page 8] Internet-Draft SAVI MIX January 2017 7. Security Considerations Combining SAVI methods (as in SAVI MIX) does not improve on or eliminate the security considerations associated with each individual SAVI method. Therefore, security considerations for each enabled SAVI method should be addressed as described in that method's associated RFC. Moreover, combining methods (as in SAVI MIX) has two additional implications for security. First, it may increase susceptibility to DoS attacks, because the SAVI binding setup rate will be the sum of the rates of all enabled SAVI methods. Implementers must take these added resource requirements into account. Second, because SAVI MIX supports multiple binding mechanisms, it potentially reduces the security level to that of the weakest supported method, unless additional steps (e.g. requiring non-overlapping address spaces for different methods) are taken. 8. Privacy Considerations When implementing multiple SAVI methods, privacy considerations of all methods apply cumulatively. 9. IANA Considerations This memo asks the IANA for no new parameters. 10. Acknowledgment Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, David Lamparter, Scott G. Kelly and Jari Arkko for their valuable contributions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . Bi, et al. Expires July 5, 2017 [Page 9] Internet-Draft SAVI MIX January 2017 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, "Address Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085, DOI 10.17487/RFC6085, January 2011, . [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, . [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)", RFC 7219, DOI 10.17487/RFC7219, May 2014, . [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, . 11.2. Informative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, . Authors' Addresses Bi, et al. Expires July 5, 2017 [Page 10] Internet-Draft SAVI MIX January 2017 Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@tsinghua.edu.cn Guang Yao Tsinghua University/Baidu Baidu Science and Technology Park, Building 1 Beijing 100193 China EMail: yaoguang.china@gmail.com Joel M. Halpern Ericsson EMail: joel.halpern@ericsson.com Eric Levy-Abegnoli (editor) Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis 06410 France EMail: elevyabe@cisco.com Bi, et al. Expires July 5, 2017 [Page 11] ./draft-irtf-cfrg-eddsa-08.txt0000664000764400076440000031437212755552611015421 0ustar iustyiusty Network Working Group S. Josefsson Internet-Draft SJD AB Intended status: Informational I. Liusvaara Expires: February 20, 2017 Independent August 19, 2016 Edwards-curve Digital Signature Algorithm (EdDSA) draft-irtf-cfrg-eddsa-08 Abstract The elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA) is described. The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 20, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Josefsson & Liusvaara Expires February 20, 2017 [Page 1] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4 3. EdDSA Algorithm . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Sign . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Verify . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. PureEdDSA, HashEdDSA, and Naming . . . . . . . . . . . . . . 8 5. EdDSA Instances . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Ed25519ph, Ed25519ctx and Ed25519 . . . . . . . . . . . . 9 5.1.1. Modular arithmetic . . . . . . . . . . . . . . . . . 10 5.1.2. Encoding . . . . . . . . . . . . . . . . . . . . . . 10 5.1.3. Decoding . . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. Point addition . . . . . . . . . . . . . . . . . . . 11 5.1.5. Key Generation . . . . . . . . . . . . . . . . . . . 12 5.1.6. Sign . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.7. Verify . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Ed448ph and Ed448 . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Modular arithmetic . . . . . . . . . . . . . . . . . 16 5.2.2. Encoding . . . . . . . . . . . . . . . . . . . . . . 16 5.2.3. Decoding . . . . . . . . . . . . . . . . . . . . . . 16 5.2.4. Point addition . . . . . . . . . . . . . . . . . . . 17 5.2.5. Key Generation . . . . . . . . . . . . . . . . . . . 18 5.2.6. Sign . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.7. Verify . . . . . . . . . . . . . . . . . . . . . . . 19 6. Ed25519 Python illustration . . . . . . . . . . . . . . . . . 19 7. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Test Vectors for Ed25519 . . . . . . . . . . . . . . . . 24 7.2. Test Vectors for Ed25519ctx . . . . . . . . . . . . . . . 28 7.3. Test Vectors for Ed25519ph . . . . . . . . . . . . . . . 30 7.4. Test Vectors for Ed448 . . . . . . . . . . . . . . . . . 30 7.5. Test Vectors for Ed448ph . . . . . . . . . . . . . . . . 38 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10.1. Side-channel leaks . . . . . . . . . . . . . . . . . . . 40 10.2. Randomness considerations . . . . . . . . . . . . . . . 40 10.3. Use of contexts . . . . . . . . . . . . . . . . . . . . 40 10.4. Signature malleability . . . . . . . . . . . . . . . . . 41 10.5. Choice of signature primitive . . . . . . . . . . . . . 41 10.6. Mixing different prehashes . . . . . . . . . . . . . . . 42 10.7. Signing large amounts of data at once . . . . . . . . . 42 10.8. Multiplication by cofactor in verification . . . . . . . 42 10.9. Use of SHAKE256 as hash function . . . . . . . . . . . . 43 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.1. Normative References . . . . . . . . . . . . . . . . . . 43 Josefsson & Liusvaara Expires February 20, 2017 [Page 2] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 11.2. Informative References . . . . . . . . . . . . . . . . . 43 Appendix A. Ed25519/Ed448 Python Library . . . . . . . . . . . . 45 Appendix B. Library driver . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 1. Introduction The Edwards-curve Digital Signature Algorithm (EdDSA) is a variant of Schnorr's signature system with (possibly twisted) Edwards curves. EdDSA needs to be instantiated with certain parameters and this document describes some recommended variants. To facilitate adoption in the Internet community of EdDSA, this document describes the signature scheme in an implementation-oriented way, and provides sample code and test vectors. The advantages with EdDSA include: 1. High-performance on a variety of platforms, 2. Does not require the use of a unique random number for each signature, 3. More resilient to side-channel attacks, 4. Small public keys (32 or 57 bytes) and signatures (64 or 114 bytes) for Ed25519 and Ed448, respectively, 5. The formulas are "complete", i.e., they are valid for all points on the curve, with no exceptions. This obviates the need for EdDSA to perform expensive point validation on untrusted public values, 6. Collision resilience, meaning that hash-function collisions do not break this system. (Only holds for PureEdDSA.) The original EdDSA paper [EDDSA] and the generalized version described in "EdDSA for more curves" [EDDSA2] provide further background. The [RFC7748] document discusses specific curves, including Curve25519 [CURVE25519] and Ed448-Goldilocks [ED448]. Ed25519 is intended to operate at around the 128-bit security level, and Ed448 at around the 224-bit security level. A sufficiently large quantum computer would be able to break both. Reasonable projections of the abilities of classical computers conclude that Ed25519 is perfectly safe. Ed448 is provided for those applications with relaxed performance requirements and where there is a desire to hedge against analytical attacks on elliptic curves. Josefsson & Liusvaara Expires February 20, 2017 [Page 3] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 2. Notation and Conventions The following notation is used throughout the document: p Denotes the prime number defining the underlying field GF(p) finite field with p elements x^y x multiplied by itself y times B generator of the group or subgroup of interest [n]X X added to itself n times h[i] the i'th octet of octet string h_i the i'th bit of h a || b (bit-)string a concatenated with (bit-)string b a <= b a is less than or equal to b a >= b a is greater than or equal to b i+j sum of i and j i*j multiplication of i and j i-j subtraction of j from i i/j division of i by j i x j Cartesian product of i and j (u,v) Elliptic curve point with x coordinate u and y coordinate v SHAKE256(x, y) The y first octets of SHAKE256 [FIPS202] output for input x OCTET(x) The octet with value x OLEN(x) The number of octets in string x dom2(x, y) The blank octet string when signing or verifying Ed25519. Otherwise the octet string: "SigEd25519 no Ed25519 collisions" || octet(x) || octet(OLEN(y)) || y, where x is in range 0-255 and y is octet string of at most 255 octets. "SigEd25519 no Ed25519 collisions" is in ASCII (32 octets) Josefsson & Liusvaara Expires February 20, 2017 [Page 4] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 dom4(x, y) The octet string "SigEd448" || octet(x) || octet(OLEN(y)) || y, where x is in range 0-255 and y is octet string of at most 255 octets. "SigEd448" is in ASCII (8 octets) Parenthesis (i.e., '(' and ')') are used to group expressions, in order to avoid having the description depend on a binding order between operators. Bit strings are converted to octet strings by taking bits from left to right and packing those from least significant bit of each octet to most significant bit, and moving to the next octet when each octet fills up. The conversion from octet string to bit string is the reverse of this process. E.g. the 16-bit bit string b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15 , is converted into two octets x0 and x1 (in this order) as x0 = b7*128+b6*64+b5*32+b4*16+b3*8+b2*4+b1*2+b0 x1 = b15*128+b14*64+b13*32+b12*16+b11*8+b10*4+b9*2+b8 Little-endian encoding into bits places bits from left to right from least significant to most significant. If combined with bit string to octet string conversion defined above, this results in little- endian encoding into octets (if length is not multiple of 8, the most significant bits of last octet remain unused). 3. EdDSA Algorithm EdDSA is a digital signature system with eleven parameters. The generic EdDSA digital signature system with its eleven input parameters is not intended to be implemented directly. Choosing parameters is critical for secure and efficient operation. Instead, you would implement a particular parameter choice for EdDSA (such as Ed25519 or Ed448), sometimes slightly generalized to achieve code re- use to cover Ed25519 and Ed448. Therefore, a precise explanation of the generic EdDSA is thus not particularly useful for implementers. For background and completeness, a succinct description of the generic EdDSA algorithm is given here. The definition of some parameters, such as n and c, may help to explain some non-intuitive steps of the algorithm. This description closely follows [EDDSA2]. Josefsson & Liusvaara Expires February 20, 2017 [Page 5] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 EdDSA has eleven parameters: 1. An odd prime power p. EdDSA uses an elliptic curve over the finite field GF(p). 2. An integer b with 2^(b-1) > p. EdDSA public keys have exactly b bits, and EdDSA signatures have exactly 2*b bits. b is recommended to be multiple of 8, so public key and signature lengths are integral number of octets. 3. A (b-1)-bit encoding of elements of the finite field GF(p). 4. A cryptographic hash function H producing 2*b-bit output. Conservative hash functions (i.e. hash functions where it is infeasible to create collisions) are recommended and do not have much impact on the total cost of EdDSA. 5. An integer c that is 2 or 3. Secret EdDSA scalars are multiples of 2^c. The integer c is the base-2 logarithm of the so called cofactor. 6. An integer n with c <= n < b. Secret EdDSA scalars have exactly n + 1 bits, with the top bit (the 2^n position) always set and the bottom c bits always cleared. 7. A non-square element d of GF(p). The usual recommendation is to take it as the value nearest to zero that gives an acceptable curve. 8. A nonzero square element a of GF(p). The usual recommendation for best performance is a = -1 if p mod 4 = 1, and a = 1 if p mod 4 = 3. 9. An element B != (0,1) of the set E = { (x,y) is a member of GF(p) x GF(p) such that a * x^2 + y^2 = 1 + d * x^2 * y^2 }. 10. An odd prime L such that [L]B = 0 and 2^c * L = #E. The number #E (the number of points on the curve) is part of the standard data provided for an elliptic curve E, or can be computed as cofactor * order. 11. A "prehash" function PH. PureEdDSA means EdDSA where PH is the identity function, i.e., PH(M) = M. HashEdDSA means EdDSA where PH generates a short output, no matter how long the message is; for example, PH(M) = SHA-512(M). Points on the curve form a group under addition, (x3, y3) = (x1, y1) + (x2, y2), with the formulas Josefsson & Liusvaara Expires February 20, 2017 [Page 6] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 x1 * y2 + x2 * y1 y1 * y2 - a * x1 * x2 x3 = --------------------------, y3 = --------------------------- 1 + d * x1 * x2 * y1 * y2 1 - d * x1 * x2 * y1 * y2 The neutral element in the group is (0,1). Unlike many other curves used for cryptographic applications, these formulas are "complete", they are valid for all points on the curve, with no exceptions. In particular, the denominators are non-zero for all input points. There are more efficient formulas, which are still complete, use homogeneous coordinates to avoid the expensive modulo p inversions. See [Faster-ECC] and [Edwards-revisited]. 3.1. Encoding An integer 0 < S < L - 1 is encoded in little-endian form as a b-bit string ENC(S). An element (x,y) of E is encoded as a b-bit string called ENC(x,y) which is the (b-1)-bit encoding of y concatenated with one bit that is 1 if x is negative and 0 if x is not negative. The encoding of GF(p) is used to define "negative" elements of GF(p): specifically, x is negative if the (b-1)-bit encoding of x is lexicographically larger than the (b-1)-bit encoding of -x. 3.2. Keys An EdDSA private key is a b-bit string k. Let the hash H(k) = (h_0, h_1, ..., h_(2b-1)) determine an integer s which is 2^n plus the sum of m = 2^i * h_i for all integer i, c <= i < n. Let s determine the multiple A = [s]B. The EdDSA public key is ENC(A). The bits h_b, ..., h_(2b-1) are used below during signing. 3.3. Sign The EdDSA signature of a message M under a private key k is defined as the PureEdDSA signature of PH(M). In other words, EdDSA simply uses PureEdDSA to sign PH(M). The PureEdDSA signature of a message M under a private key k is the 2*b-bit string ENC(R) || ENC(S). R and S are derived as follows. First define r = H(h_b || ... || h_(2b-1) || M) interpreting 2*b-bit strings in little-endian form as integers in {0, 1, ..., 2^(2*b) - 1}. Let R = [r]B and S = (r + H(ENC(R) || ENC(A) || PH(M)) * s) mod L. The s used here is from the previous section. Josefsson & Liusvaara Expires February 20, 2017 [Page 7] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 3.4. Verify To verify a PureEdDSA signature ENC(R) || ENC(S) on a message M under a public key ENC(A), proceed as follows. Parse the inputs so that A and R are elements of E, and S is a member of the set {0, 1, ..., L-1 }. Compute h = H(ENC(R) || ENC(A) || M) and check the group equation [2^c * S] B = 2^c * R + [2^c * h] A in E. Signature is rejected if parsing fails (including S being out-of-range) or the group equation does not hold. EdDSA verification for a message M is defined as PureEdDSA verification for PH(M). 4. PureEdDSA, HashEdDSA, and Naming One of the parameters of the EdDSA algorithm is the "prehash" function. This may be the identity function, resulting in an algorithm called PureEdDSA, or a collision-resistant hash function such as SHA-512, resulting in an algorithm called HashEdDSA. Choosing which variant to use depends on which property is deemed to be more important between 1) collision resilience, and 2) a single- pass interface for creating signatures. The collision resilience property means EdDSA is secure even if it is feasible to compute collisions for the hash function. The single-pass interface property means that only one pass over the input message is required to create a signature. PureEdDSA requires two passes over the input. Many existing APIs, protocols, and environments assume digital signature algorithms only need one pass over the input, and may have API or bandwidth concerns supporting anything else. Note that single-pass verification is not possible with most uses of signatures, no matter which signature algorithm is chosen. This is because most of the time one can't process the message until signature is validated, which needs a pass on the entire message. This document specify parameters resulting in the HashEdDSA variants Ed25519ph and Ed448ph, and the PureEdDSA variants Ed25519 and Ed448. 5. EdDSA Instances This section instantiate the general EdDSA algorithm for the edwards25519 and edwards448 curves, each for the PureEdDSA and HashEdDSA variants (plus contextualized extension of the Ed25519 scheme. Thus, five different parameter sets are described. Josefsson & Liusvaara Expires February 20, 2017 [Page 8] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 5.1. Ed25519ph, Ed25519ctx and Ed25519 Ed25519 is EdDSA instantiated with: +-----------+-------------------------------------------------------+ | Parameter | Value | +-----------+-------------------------------------------------------+ | p | p of edwards25519 in [RFC7748] (i.e. 2^255 - 19) | | | | | b | 256 | | | | | encoding | 255-bit little-endian encoding of {0, 1, ..., p-1} | | of GF(p) | | | | | | H(x) | SHA-512(dom2(phflag,context)||x) [RFC4634] | | | | | c | base 2 logarithm of cofactor of edwards25519 in | | | [RFC7748] (i.e. 3) | | | | | n | 254 | | | | | d | d of edwards25519 in [RFC7748] (i.e. -121665/121666 = | | | 37095705934669439343138083508754565189542113879843219 | | | 016388785533085940283555) | | | | | a | -1 | | | | | B | (X(P),Y(P)) of edwards25519 in [RFC7748] (i.e. (1511 | | | 22213495354007725011514095885315114540126930418572060 | | | 46113283949847762202, 4631683569492647816942839400347 | | | 5163141307993866256225615783033603165251855960)) | | | | | L | order of edwards25519 in [RFC7748] (i.e. | | | 2^252+27742317777372353535851937790883648493). | | | | | PH(x) | x (i.e. the identity function) | +-----------+-------------------------------------------------------+ Table 1: Parameters of Ed25519 For Ed25519, dom2(f,c) is the empty string. phflag value is irrelevant. The context (if present at all) MUST be empty. This causes the scheme to be one and the same with Ed25519 scheme published earlier. For Ed25519ctx, phflag=0. The context input SHOULD NOT be empty. Josefsson & Liusvaara Expires February 20, 2017 [Page 9] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 For, Ed25519ph, phflag=1 and PH is SHA512 instead. i.e., the input is hashed using SHA-512 before signing with Ed25519. Value of context is set by signer and verifier (maximum of 255 octets, the default is empty string, except for Ed25519 which can't have context) and has to match octet by octet for verification to be successful. The curve used is equivalent to Curve25519 [CURVE25519], under a change of coordinates, which means that the difficulty of the discrete logarithm problem is the same as for Curve25519. 5.1.1. Modular arithmetic For advice on how to implement arithmetic modulo p = 2^255 - 19 efficiently and securely, see Curve25519 [CURVE25519]. For inversion modulo p, it is recommended to use the identity x^-1 = x^(p-2) (mod p). Inverting zero should never happen, as it would either require invalid input, which would have been detected before, or a calculation error. For point decoding or "decompression", square roots modulo p are needed. They can be computed using the Tonelli-Shanks algorithm, or the special case for p = 5 (mod 8). To find a square root of a, first compute the candidate root x = a^((p+3)/8) (mod p). Then there are three cases: x^2 = a (mod p). Then x is a square root. x^2 = -a (mod p). Then 2^((p-1)/4) * x is a square root. a is not a square modulo p. 5.1.2. Encoding All values are coded as octet strings, integers are coded using little-endian convention, i.e., a 32-octet string h h[0],...h[31] represents the integer h[0] + 2^8 * h[1] + ... + 2^248 * h[31]. A curve point (x,y), with coordinates in the range 0 <= x,y < p, is coded as follows. First, encode the y-coordinate as a little-endian string of 32 octets. The most significant bit of the final octet is always zero. To form the encoding of the point, copy the least significant bit of the x-coordinate to the most significant bit of the final octet. Josefsson & Liusvaara Expires February 20, 2017 [Page 10] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 5.1.3. Decoding Decoding a point, given as a 32-octet string, is a little more complicated. 1. First, interpret the string as an integer in little-endian representation. Bit 255 of this number is the least significant bit of the x-coordinate, and denote this value x_0. The y-coordinate is recovered simply by clearing this bit. If the resulting value is >= p, decoding fails. 2. To recover the x coordinate, the curve equation implies x^2 = (y^2 - 1) / (d y^2 + 1) (mod p). The denominator is always nonzero mod p. Let u = y^2 - 1 and v = d y^2 + 1. To compute the square root of (u/v), the first step is to compute the candidate root x = (u/v)^((p+3)/8). This can be done using the following trick, to use a single modular powering for both the inversion of v and the square root: (p+3)/8 3 (p-5)/8 x = (u/v) = u v (u v^7) (mod p) 3. Again, there are three cases: 1. If v x^2 = u (mod p), x is a square root. 2. If v x^2 = -u (mod p), set x <-- x * 2^((p-1)/4), which is a square root. 3. Otherwise, no square root exists modulo p, and decoding fails. 4. Finally, use the x_0 bit to select the right square root. If x = 0, and x_0 = 1, decoding fails. Otherwise, if x_0 != x mod 2, set x <-- p - x. Return the decoded point (x,y). 5.1.4. Point addition For point addition, the following method is recommended. A point (x,y) is represented in extended homogeneous coordinates (X, Y, Z, T), with x = X/Z, y = Y/Z, x * y = T/Z. The neutral point is (0,1), or equivalently in extended homogeneous coordinates (0, Z, Z, 0) for any nonzero Z. The following formulas for adding two points, (x3,y3) = (x1,y1)+(x2,y2) on twisted Edwards curves with a=-1, square a and non-square d are described in [Edwards-revisited], section 3.1, and Josefsson & Liusvaara Expires February 20, 2017 [Page 11] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 in [EFD-TWISTED-ADD]. They are complete, i.e., they work for any pair of valid input points. A = (Y1-X1)*(Y2-X2) B = (Y1+X1)*(Y2+X2) C = T1*2*d*T2 D = Z1*2*Z2 E = B-A F = D-C G = D+C H = B+A X3 = E*F Y3 = G*H T3 = E*H Z3 = F*G For point doubling, (x3,y3) = (x1,y1)+(x1,y1), one could just substitute equal points in above (because of completeness, such substitution is valid), and observe that four multiplications turn into squares. However, using the formulas described in [Edwards-revisited], section 3.2, and in [EFD-TWISTED-DBL] saves a few smaller operations. A = X1^2 B = Y1^2 C = 2*Z1^2 H = A+B E = H-(X1+Y1)^2 G = A-B F = C+G X3 = E*F Y3 = G*H T3 = E*H Z3 = F*G 5.1.5. Key Generation The private key is 32 octets (256 bits, corresponding to b) of cryptographically-secure random data. See [RFC4086] for a discussion about randomness. The 32-byte public key is generated by the following steps. 1. Hash the 32-byte private key using SHA-512, storing the digest in a 64-octet large buffer, denoted h. Only the lower 32 bytes are used for generating the public key. Josefsson & Liusvaara Expires February 20, 2017 [Page 12] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 2. Prune the buffer: The lowest 3 bits of the first octet are cleared, the highest bit of the last octet is cleared, and the second highest bit of the last octet is set. 3. Interpret the buffer as the little-endian integer, forming a secret scalar s. Perform a fixed-base scalar multiplication [s]B. 4. The public key A is the encoding of the point [s]B. First encode the y coordinate (in the range 0 <= y < p) as a little-endian string of 32 octets. The most significant bit of the final octet is always zero. To form the encoding of the point [s]B, copy the least significant bit of the x coordinate to the most significant bit of the final octet. The result is the public key. 5.1.6. Sign The inputs to the signing procedure is the private key, a 32-octet string, and a message M of arbitrary size. For Ed25519ctx and Ed25519ph, there is additionally a context C of at most 255 octets and a flag F, 0 for Ed25519ctx and 1 for Ed25519ph. 1. Hash the private key, 32-octets, using SHA-512. Let h denote the resulting digest. Construct the secret scalar s from the first half of the digest, and the corresponding public key A, as described in the previous section. Let prefix denote the second half of the hash digest, h[32],...,h[63]. 2. Compute SHA-512(dom2(F, C) || prefix || PH(M)), where M is the message to be signed. Interpret the 64-octet digest as a little- endian integer r. 3. Compute the point [r]B. For efficiency, do this by first reducing r modulo L, the group order of B. Let the string R be the encoding of this point. 4. Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 64-octet digest as a little-endian integer k. 5. Compute S = (r + k * s) mod L. For efficiency, again reduce k modulo L first. 6. Form the signature of the concatenation of R (32 octets) and the little-endian encoding of S (32 octets, three most significant bits of the final octet are always zero). Josefsson & Liusvaara Expires February 20, 2017 [Page 13] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 5.1.7. Verify 1. To verify a signature on a message M using public key A, with F being 0 for Ed25519ctx, 1 for Ed25519ph, and if Ed25519ctx or Ed25519ph is being used, C being the context, first split the signature into two 32-octet halves. Decode the first half as a point R, and the second half as an integer S, in the range 0 <= s < L. Decode the public key A as point A'. If any of the decodings fails (including S being out-of-range), the signature is invalid. 2. Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 64-octet digest as a little-endian integer k. 3. Check the group equation [8][S]B = [8]R + [8][k]A'. It's sufficient, but not required, to instead check [S]B = R + [k]A'. 5.2. Ed448ph and Ed448 Josefsson & Liusvaara Expires February 20, 2017 [Page 14] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 Ed448 is EdDSA instantiated with: +-----------+-------------------------------------------------------+ | Parameter | Value | +-----------+-------------------------------------------------------+ | p | p of edwards448 in [RFC7748] (i.e. 2^448 - 2^224 - 1) | | | | | b | 456 | | | | | encoding | 455-bit little-endian encoding of {0, 1, ..., p-1} | | of GF(p) | | | | | | H(x) | SHAKE256(dom4(phflag,context)||x, 114) | | | | | phflag | 0 | | | | | c | base 2 logarithm of cofactor of edwards448 in | | | [RFC7748] (i.e. 2) | | | | | n | 447 | | | | | d | d of edwards448 in [RFC7748] (i.e. -39081) | | | | | a | 1 | | | | | B | (X(P),Y(P)) of edwards448 in [RFC7748] (i.e. (224580 | | | 04029592430018760433409989603624678964163256413424612 | | | 54616869504154674060329090291928693579532825780320751 | | | 46446173674602635247710, 2988192100784814926760179304 | | | 43930673437544040154080242095928241372331506189835876 | | | 00353687865541878473398230323350346250053154506283266 | | | 0)) | | | | | L | order of edwards448 in [RFC7748] (i.e. 2^446 - 13818 | | | 06680989511535200738674851542688033669247488217860989 | | | 4547503885). | | | | | PH(x) | x (i.e. the identity function) | +-----------+-------------------------------------------------------+ Table 2: Parameters of Ed448 Ed448ph is the same but with PH being SHAKE256(x, 64) and phflag being 1, i.e., the input is hashed before signing with Ed448 with a hash constant modified. Josefsson & Liusvaara Expires February 20, 2017 [Page 15] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 Value of context is set by signer and verifier (maximum of 255 octets, the default is empty string) and has to match octet by octet for verification to be successful. The curve is equivalent to Ed448-Goldilocks under change of basepoint, which preserves difficulty of the discrete logarithm. 5.2.1. Modular arithmetic For advice on how to implement arithmetic modulo p = 2^448 - 2^224 - 1 efficiently and securely, see [ED448]. For inversion modulo p, it is recommended to use the identity x^-1 = x^(p-2) (mod p). Inverting zero should never happen, as it would either require invalid input, which would have been detected before, or a calculation error. For point decoding or "decompression", square roots modulo p are needed. They can be computed by first computing candidate root x = a ^ (p+1)/4 (mod p) and then checking if x^2 = a. If it is, then x is square root of a; if it isn't, then a does not have a square root. 5.2.2. Encoding All values are coded as octet strings, and integers are coded using little-endian convention, i.e., a 57-octet string h h[0],...h[56] represents the integer h[0] + 2^8 * h[1] + ... + 2^448 * h[56]. A curve point (x,y), with coordinates in the range 0 <= x,y < p, is coded as follows. First, encode the y-coordinate as a little-endian string of 57 octets. The final octet is always zero. To form the encoding of the point, copy the least significant bit of the x-coordinate to the most significant bit of the final octet. 5.2.3. Decoding Decoding a point, given as a 57-octet string, is a little more complicated. 1. First, interpret the string as an integer in little-endian representation. Bit 455 of this number is the least significant bit of the x-coordinate, and denote this value x_0. The y-coordinate is recovered simply by clearing this bit. If the resulting value is >= p, decoding fails. 2. To recover the x coordinate, the curve equation implies x^2 = (y^2 - 1) / (d y^2 - 1) (mod p). The denominator is always nonzero mod p. Let u = y^2 - 1 and v = d y^2 - 1. To compute the square root of (u/v), the first step is to compute the candidate root x = (u/v)^((p+1)/4). This can be done using the Josefsson & Liusvaara Expires February 20, 2017 [Page 16] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 following trick, to use a single modular powering for both the inversion of v and the square root: (p+1)/4 3 (p-3)/4 x = (u/v) = u v (u^5 v^3) (mod p) 3. If v * x^2 = u, the recovered x coordinate is x. Otherwise no square root exists, and the decoding fails. 4. Finally, use the x_0 bit to select the right square root. If x = 0, and x_0 = 1, decoding fails. Otherwise, if x_0 != x mod 2, set x <-- p - x. Return the decoded point (x,y). 5.2.4. Point addition For point addition, the following method is recommended. A point (x,y) is represented in projective coordinates (X, Y, Z), with x = X/ Z, y = Y/Z. The neutral point is (0,1), or equivalently in projective coordinates (0, Z, Z) for any nonzero Z. The following formulas for adding two points, (x3,y3) = (x1,y1)+(x2,y2) on untwisted Edwards curve (i.e. a=1) with non-square d are described in [Faster-ECC] section 4 and in [EFD-ADD]. They are complete, i.e., they work for any pair of valid input points. A = Z1*Z2 B = A^2 C = X1*X2 D = Y1*Y2 E = d*C*D F = B-E G = B+E H = (X1+Y1)*(X2+Y2) X3 = A*F*(H-C-D) Y3 = A*G*(D-C) Z3 = F*G Again, similarly as with the other curve, doubling formulas can be obtained by substituting equal points, turning four multiplications into squares. However, this is not even nearly optimal, the following formulas described in [Faster-ECC] section 4 and in [EFD-DBL] save multiple multiplications. Josefsson & Liusvaara Expires February 20, 2017 [Page 17] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 B = (X1+Y1)^2 C = X1^2 D = Y1^2 E = C+D H = Z1^2 J = E-2*H X3 = (B-E)*J Y3 = E*(C-D) Z3 = E*J 5.2.5. Key Generation The private key is 57 octets (456 bits, corresponding to b) of cryptographically-secure random data. See [RFC4086] for a discussion about randomness. The 57-byte public key is generated by the following steps: 1. Hash the 57-byte private key using SHAKE256(x, 114), storing the digest in a 114-octet large buffer, denoted h. Only the lower 57 bytes are used for generating the public key. 2. Prune the buffer: The two least significant bits of the first octet are cleared, all 8 bits the last octet are cleared, and the highest bit of the second to last octet is set. 3. Interpret the buffer as the little-endian integer, forming a secret scalar s. Perform a known-base-point scalar multiplication [s]B. 4. The public key A is the encoding of the point [s]B. First encode the y coordinate (in the range 0 <= y < p) as a little-endian string of 57 octets. The most significant bit of the final octet is always zero. To form the encoding of the point [s]B, copy the least significant bit of the x coordinate to the most significant bit of the final octet. The result is the public key. 5.2.6. Sign The inputs to the signing procedure is the private key, a 57-octet string, a flag F, which is 0 for Ed448, 1 for Ed448ph, context C of at most 255 octets and a message M of arbitrary size. 1. Hash the private key, 57-octets, using SHAKE256(x, 114). Let h denote the resulting digest. Construct the secret scalar s from the first half of the digest, and the corresponding public key A, as described in the previous section. Let prefix denote the second half of the hash digest, h[57],...,h[113]. Josefsson & Liusvaara Expires February 20, 2017 [Page 18] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 2. Compute SHAKE256(dom4(F, C) || prefix || PH(M), 114), where M is the message to be signed, F is 1 for Ed448ph, 0 for Ed448 and C is the context to use. Interpret the 114-octet digest as a little-endian integer r. 3. Compute the point [r]B. For efficiency, do this by first reducing r modulo L, the group order of B. Let the string R be the encoding of this point. 4. Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and interpret the 114- octet digest as a little-endian integer k. 5. Compute S = (r + k * s) mod L. For efficiency, again reduce k modulo L first. 6. Form the signature of the concatenation of R (57 octets) and the little-endian encoding of S (57 octets, the ten most significant bits of the final octets are always zero). 5.2.7. Verify 1. To verify a signature on a message M using context C and public key A, with F being 0 for Ed448, 1 for Ed448ph, first split the signature into two 57-octet halves. Decode the first half as a point R, and the second half as an integer S, in the range 0 <= s < L. Decode the public key A as point A'. If any of the decodings fails (including S being out-of-range), the signature is invalid. 2. Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and interpret the 114-octet digest as a little-endian integer k. 3. Check the group equation [4][S]B = [4]R + [4][k]A'. It's sufficient, but not required, to instead check [S]B = R + [k]A'. 6. Ed25519 Python illustration The rest of this section describes how Ed25519 can be implemented in Python (version 3.2 or later) for illustration. See appendix A for the complete implementation and appendix B for a test-driver to run it through some test vectors. Note that this code is not intended for production as it is not proven to be correct for all inputs, nor does it protect against side-channel attacks. The purpose is to illustrate the algorithm to help implementers with their own implementation. First some preliminaries that will be needed. Josefsson & Liusvaara Expires February 20, 2017 [Page 19] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 import hashlib def sha512(s): return hashlib.sha512(s).digest() # Base field Z_p p = 2**255 - 19 def modp_inv(x): return pow(x, p-2, p) # Curve constant d = -121665 * modp_inv(121666) % p # Group order q = 2**252 + 27742317777372353535851937790883648493 def sha512_modq(s): return int.from_bytes(sha512(s), "little") % q Then follows functions to perform point operations. Josefsson & Liusvaara Expires February 20, 2017 [Page 20] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 # Points are represented as tuples (X, Y, Z, T) of extended coordinates, # with x = X/Z, y = Y/Z, x*y = T/Z def point_add(P, Q): A = (P[1]-P[0])*(Q[1]-Q[0]) % p B = (P[1]+P[0])*(Q[1]+Q[0]) % p C = 2 * P[3] * Q[3] * d % p D = 2 * P[2] * Q[2] % p E = B-A F = D-C G = D+C H = B+A return (E*F, G*H, F*G, E*H) # Computes Q = s * Q def point_mul(s, P): Q = (0, 1, 1, 0) # Neutral element while s > 0: # Is there any bit-set predicate? if s & 1: Q = point_add(Q, P) P = point_add(P, P) s >>= 1 return Q def point_equal(P, Q): # x1 / z1 == x2 / z2 <==> x1 * z2 == x2 * z1 if (P[0] * Q[2] - Q[0] * P[2]) % p != 0: return False if (P[1] * Q[2] - Q[1] * P[2]) % p != 0: return False return True Now follows functions for point compression. # Square root of -1 modp_sqrt_m1 = pow(2, (p-1) // 4, p) # Compute corresponding x coordinate, with low bit corresponding to # sign, or return None on failure def recover_x(y, sign): if y >= p: return None x2 = (y*y-1) * modp_inv(d*y*y+1) if x2 == 0: if sign: return None else: Josefsson & Liusvaara Expires February 20, 2017 [Page 21] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 return 0 # Compute square root of x2 x = pow(x2, (p+3) // 8, p) if (x*x - x2) % p != 0: x = x * modp_sqrt_m1 % p if (x*x - x2) % p != 0: return None if (x & 1) != sign: x = p - x return x # Base point g_y = 4 * modp_inv(5) % p g_x = recover_x(g_y, 0) G = (g_x, g_y, 1, g_x * g_y % p) def point_compress(P): zinv = modp_inv(P[2]) x = P[0] * zinv % p y = P[1] * zinv % p return int.to_bytes(y | ((x & 1) << 255), 32, "little") def point_decompress(s): if len(s) != 32: raise Exception("Invalid input length for decompression") y = int.from_bytes(s, "little") sign = y >> 255 y &= (1 << 255) - 1 x = recover_x(y, sign) if x is None: return None else: return (x, y, 1, x*y % p) These are functions for manipulating the private key. Josefsson & Liusvaara Expires February 20, 2017 [Page 22] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 def secret_expand(secret): if len(secret) != 32: raise Exception("Bad size of private key") h = sha512(secret) a = int.from_bytes(h[:32], "little") a &= (1 << 254) - 8 a |= (1 << 254) return (a, h[32:]) def secret_to_public(secret): (a, dummy) = secret_expand(secret) return point_compress(point_mul(a, G)) The signature function works as below. def sign(secret, msg): a, prefix = secret_expand(secret) A = point_compress(point_mul(a, G)) r = sha512_modq(prefix + msg) R = point_mul(r, G) Rs = point_compress(R) h = sha512_modq(Rs + A + msg) s = (r + h * a) % q return Rs + int.to_bytes(s, 32, "little") And finally the verification function. def verify(public, msg, signature): if len(public) != 32: raise Exception("Bad public key length") if len(signature) != 64: Exception("Bad signature length") A = point_decompress(public) if not A: return False Rs = signature[:32] R = point_decompress(Rs) if not R: return False s = int.from_bytes(signature[32:], "little") if s >= q: return False h = sha512_modq(Rs + public + msg) sB = point_mul(s, G) hA = point_mul(h, A) return point_equal(sB, point_add(R, hA)) Josefsson & Liusvaara Expires February 20, 2017 [Page 23] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 7. Test Vectors This section contains test vectors for Ed25519ph, Ed25519ctx, Ed448ph, Ed25519 and Ed448. Each section contains sequence of test vectors. The octets are hex encoded and whitespace is inserted for readability. Ed25519 Ed25519ctx and Ed25519ph private and public keys are 32 octets, signatures are 64 octets. Ed448 and Ed448ph private and public keys are 57 octets, signatures are 114 octets. Messages are of arbitrary length. If context is non-empty, it is given as 1-255 octets. 7.1. Test Vectors for Ed25519 These test vectors are taken from [ED25519-TEST-VECTORS] (but we removed the public key as a suffix of the private key, and removed the message from the signature) and [ED25519-LIBGCRYPT-TEST-VECTORS]. -----TEST 1 ALGORITHM: Ed25519 SECRET KEY: 9d61b19deffd5a60ba844af492ec2cc4 4449c5697b326919703bac031cae7f60 PUBLIC KEY: d75a980182b10ab7d54bfed3c964073a 0ee172f3daa62325af021a68f707511a MESSAGE (length 0 bytes): SIGNATURE: e5564300c360ac729086e2cc806e828a 84877f1eb8e5d974d873e06522490155 5fb8821590a33bacc61e39701cf9b46b d25bf5f0595bbe24655141438e7a100b -----TEST 2 ALGORITHM: Ed25519 SECRET KEY: 4ccd089b28ff96da9db6c346ec114e0f 5b8a319f35aba624da8cf6ed4fb8a6fb Josefsson & Liusvaara Expires February 20, 2017 [Page 24] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 PUBLIC KEY: 3d4017c3e843895a92b70aa74d1b7ebc 9c982ccf2ec4968cc0cd55f12af4660c MESSAGE (length 1 byte): 72 SIGNATURE: 92a009a9f0d4cab8720e820b5f642540 a2b27b5416503f8fb3762223ebdb69da 085ac1e43e15996e458f3613d0f11d8c 387b2eaeb4302aeeb00d291612bb0c00 -----TEST 3 ALGORITHM: Ed25519 SECRET KEY: c5aa8df43f9f837bedb7442f31dcb7b1 66d38535076f094b85ce3a2e0b4458f7 PUBLIC KEY: fc51cd8e6218a1a38da47ed00230f058 0816ed13ba3303ac5deb911548908025 MESSAGE (length 2 bytes): af82 SIGNATURE: 6291d657deec24024827e69c3abe01a3 0ce548a284743a445e3680d7db5ac3ac 18ff9b538d16f290ae67f760984dc659 4a7c15e9716ed28dc027beceea1ec40a -----TEST 1024 ALGORITHM: Ed25519 SECRET KEY: f5e5767cf153319517630f226876b86c 8160cc583bc013744c6bf255f5cc0ee5 PUBLIC KEY: 278117fc144c72340f67d0f2316e8386 ceffbf2b2428c9c51fef7c597f1d426e Josefsson & Liusvaara Expires February 20, 2017 [Page 25] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 MESSAGE (length 1023 bytes): 08b8b2b733424243760fe426a4b54908 632110a66c2f6591eabd3345e3e4eb98 fa6e264bf09efe12ee50f8f54e9f77b1 e355f6c50544e23fb1433ddf73be84d8 79de7c0046dc4996d9e773f4bc9efe57 38829adb26c81b37c93a1b270b20329d 658675fc6ea534e0810a4432826bf58c 941efb65d57a338bbd2e26640f89ffbc 1a858efcb8550ee3a5e1998bd177e93a 7363c344fe6b199ee5d02e82d522c4fe ba15452f80288a821a579116ec6dad2b 3b310da903401aa62100ab5d1a36553e 06203b33890cc9b832f79ef80560ccb9 a39ce767967ed628c6ad573cb116dbef efd75499da96bd68a8a97b928a8bbc10 3b6621fcde2beca1231d206be6cd9ec7 aff6f6c94fcd7204ed3455c68c83f4a4 1da4af2b74ef5c53f1d8ac70bdcb7ed1 85ce81bd84359d44254d95629e9855a9 4a7c1958d1f8ada5d0532ed8a5aa3fb2 d17ba70eb6248e594e1a2297acbbb39d 502f1a8c6eb6f1ce22b3de1a1f40cc24 554119a831a9aad6079cad88425de6bd e1a9187ebb6092cf67bf2b13fd65f270 88d78b7e883c8759d2c4f5c65adb7553 878ad575f9fad878e80a0c9ba63bcbcc 2732e69485bbc9c90bfbd62481d9089b eccf80cfe2df16a2cf65bd92dd597b07 07e0917af48bbb75fed413d238f5555a 7a569d80c3414a8d0859dc65a46128ba b27af87a71314f318c782b23ebfe808b 82b0ce26401d2e22f04d83d1255dc51a ddd3b75a2b1ae0784504df543af8969b e3ea7082ff7fc9888c144da2af58429e c96031dbcad3dad9af0dcbaaaf268cb8 fcffead94f3c7ca495e056a9b47acdb7 51fb73e666c6c655ade8297297d07ad1 ba5e43f1bca32301651339e22904cc8c 42f58c30c04aafdb038dda0847dd988d cda6f3bfd15c4b4c4525004aa06eeff8 ca61783aacec57fb3d1f92b0fe2fd1a8 5f6724517b65e614ad6808d6f6ee34df f7310fdc82aebfd904b01e1dc54b2927 094b2db68d6f903b68401adebf5a7e08 d78ff4ef5d63653a65040cf9bfd4aca7 984a74d37145986780fc0b16ac451649 de6188a7dbdf191f64b5fc5e2ab47b57 Josefsson & Liusvaara Expires February 20, 2017 [Page 26] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 f7f7276cd419c17a3ca8e1b939ae49e4 88acba6b965610b5480109c8b17b80e1 b7b750dfc7598d5d5011fd2dcc5600a3 2ef5b52a1ecc820e308aa342721aac09 43bf6686b64b2579376504ccc493d97e 6aed3fb0f9cd71a43dd497f01f17c0e2 cb3797aa2a2f256656168e6c496afc5f b93246f6b1116398a346f1a641f3b041 e989f7914f90cc2c7fff357876e506b5 0d334ba77c225bc307ba537152f3f161 0e4eafe595f6d9d90d11faa933a15ef1 369546868a7f3a45a96768d40fd9d034 12c091c6315cf4fde7cb68606937380d b2eaaa707b4c4185c32eddcdd306705e 4dc1ffc872eeee475a64dfac86aba41c 0618983f8741c5ef68d3a101e8a3b8ca c60c905c15fc910840b94c00a0b9d0 SIGNATURE: 0aab4c900501b3e24d7cdf4663326a3a 87df5e4843b2cbdb67cbf6e460fec350 aa5371b1508f9f4528ecea23c436d94b 5e8fcd4f681e30a6ac00a9704a188a03 -----TEST SHA(abc) ALGORITHM: Ed25519 SECRET KEY: 833fe62409237b9d62ec77587520911e 9a759cec1d19755b7da901b96dca3d42 PUBLIC KEY: ec172b93ad5e563bf4932c70e1245034 c35467ef2efd4d64ebf819683467e2bf MESSAGE (length 64 bytes): ddaf35a193617abacc417349ae204131 12e6fa4e89a97ea20a9eeee64b55d39a 2192992a274fc1a836ba3c23a3feebbd 454d4423643ce80e2a9ac94fa54ca49f SIGNATURE: dc2a4459e7369633a52b1bf277839a00 201009a3efbf3ecb69bea2186c26b589 09351fc9ac90b3ecfdfbc7c66431e030 3dca179c138ac17ad9bef1177331a704 Josefsson & Liusvaara Expires February 20, 2017 [Page 27] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 ----- 7.2. Test Vectors for Ed25519ctx -----foo ALGORITHM: Ed25519ctx SECRET KEY: 0305334e381af78f141cb666f6199f57 bc3495335a256a95bd2a55bf546663f6 PUBLIC KEY: dfc9425e4f968f7f0c29f0259cf5f9ae d6851c2bb4ad8bfb860cfee0ab248292 MESSAGE (length 16 bytes): f726936d19c800494e3fdaff20b276a8 CONTEXT: 666f6f SIGNATURE: 55a4cc2f70a54e04288c5f4cd1e45a7b b520b36292911876cada7323198dd87a 8b36950b95130022907a7fb7c4e9b2d5 f6cca685a587b4b21f4b888e4e7edb0d -----bar ALGORITHM: Ed25519ctx SECRET KEY: 0305334e381af78f141cb666f6199f57 bc3495335a256a95bd2a55bf546663f6 PUBLIC KEY: dfc9425e4f968f7f0c29f0259cf5f9ae d6851c2bb4ad8bfb860cfee0ab248292 MESSAGE (length 16 bytes): f726936d19c800494e3fdaff20b276a8 CONTEXT: 626172 Josefsson & Liusvaara Expires February 20, 2017 [Page 28] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 SIGNATURE: fc60d5872fc46b3aa69f8b5b4351d580 8f92bcc044606db097abab6dbcb1aee3 216c48e8b3b66431b5b186d1d28f8ee1 5a5ca2df6668346291c2043d4eb3e90d -----foo2 ALGORITHM: Ed25519ctx SECRET KEY: 0305334e381af78f141cb666f6199f57 bc3495335a256a95bd2a55bf546663f6 PUBLIC KEY: dfc9425e4f968f7f0c29f0259cf5f9ae d6851c2bb4ad8bfb860cfee0ab248292 MESSAGE (length 16 bytes): 508e9e6882b979fea900f62adceaca35 CONTEXT: 666f6f SIGNATURE: 8b70c1cc8310e1de20ac53ce28ae6e72 07f33c3295e03bb5c0732a1d20dc6490 8922a8b052cf99b7c4fe107a5abb5b2c 4085ae75890d02df26269d8945f84b0b -----foo3 ALGORITHM: Ed25519ctx SECRET KEY: ab9c2853ce297ddab85c993b3ae14bca d39b2c682beabc27d6d4eb20711d6560 PUBLIC KEY: 0f1d1274943b91415889152e893d80e9 3275a1fc0b65fd71b4b0dda10ad7d772 MESSAGE (length 16 bytes): f726936d19c800494e3fdaff20b276a8 CONTEXT: Josefsson & Liusvaara Expires February 20, 2017 [Page 29] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 666f6f SIGNATURE: 21655b5f1aa965996b3f97b3c849eafb a922a0a62992f73b3d1b73106a84ad85 e9b86a7b6005ea868337ff2d20a7f5fb d4cd10b0be49a68da2b2e0dc0ad8960f ----- 7.3. Test Vectors for Ed25519ph -----TEST abc ALGORITHM: Ed25519ph SECRET KEY: 833fe62409237b9d62ec77587520911e 9a759cec1d19755b7da901b96dca3d42 PUBLIC KEY: ec172b93ad5e563bf4932c70e1245034 c35467ef2efd4d64ebf819683467e2bf MESSAGE (length 3 bytes): 616263 SIGNATURE: 98a70222f0b8121aa9d30f813d683f80 9e462b469c7ff87639499bb94e6dae41 31f85042463c2a355a2003d062adf5aa a10b8c61e636062aaad11c2a26083406 ----- 7.4. Test Vectors for Ed448 -----Blank ALGORITHM: Ed448 SECRET KEY: 6c82a562cb808d10d632be89c8513ebf 6c929f34ddfa8c9f63c9960ef6e348a3 528c8a3fcc2f044e39a3fc5b94492f8f 032e7549a20098f95b PUBLIC KEY: Josefsson & Liusvaara Expires February 20, 2017 [Page 30] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 5fd7449b59b461fd2ce787ec616ad46a 1da1342485a70e1f8a0ea75d80e96778 edf124769b46c7061bd6783df1e50f6c d1fa1abeafe8256180 MESSAGE (length 0 bytes): SIGNATURE: 533a37f6bbe457251f023c0d88f976ae 2dfb504a843e34d2074fd823d41a591f 2b233f034f628281f2fd7a22ddd47d78 28c59bd0a21bfd3980ff0d2028d4b18a 9df63e006c5d1c2d345b925d8dc00b41 04852db99ac5c7cdda8530a113a0f4db b61149f05a7363268c71d95808ff2e65 2600 -----1 octet ALGORITHM: Ed448 SECRET KEY: c4eab05d357007c632f3dbb48489924d 552b08fe0c353a0d4a1f00acda2c463a fbea67c5e8d2877c5e3bc397a659949e f8021e954e0a12274e PUBLIC KEY: 43ba28f430cdff456ae531545f7ecd0a c834a55d9358c0372bfa0c6c6798c086 6aea01eb00742802b8438ea4cb82169c 235160627b4c3a9480 MESSAGE (length 1 byte): 03 SIGNATURE: 26b8f91727bd62897af15e41eb43c377 efb9c610d48f2335cb0bd0087810f435 2541b143c4b981b7e18f62de8ccdf633 fc1bf037ab7cd779805e0dbcc0aae1cb cee1afb2e027df36bc04dcecbf154336 c19f0af7e0a6472905e799f1953d2a0f f3348ab21aa4adafd1d234441cf807c0 3a00 -----1 octet (with context) Josefsson & Liusvaara Expires February 20, 2017 [Page 31] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 ALGORITHM: Ed448 SECRET KEY: c4eab05d357007c632f3dbb48489924d 552b08fe0c353a0d4a1f00acda2c463a fbea67c5e8d2877c5e3bc397a659949e f8021e954e0a12274e PUBLIC KEY: 43ba28f430cdff456ae531545f7ecd0a c834a55d9358c0372bfa0c6c6798c086 6aea01eb00742802b8438ea4cb82169c 235160627b4c3a9480 MESSAGE (length 1 byte): 03 CONTEXT: 666f6f SIGNATURE: d4f8f6131770dd46f40867d6fd5d5055 de43541f8c5e35abbcd001b32a89f7d2 151f7647f11d8ca2ae279fb842d60721 7fce6e042f6815ea000c85741de5c8da 1144a6a1aba7f96de42505d7a7298524 fda538fccbbb754f578c1cad10d54d0d 5428407e85dcbc98a49155c13764e66c 3c00 -----11 octets ALGORITHM: Ed448 SECRET KEY: cd23d24f714274e744343237b93290f5 11f6425f98e64459ff203e8985083ffd f60500553abc0e05cd02184bdb89c4cc d67e187951267eb328 PUBLIC KEY: dcea9e78f35a1bf3499a831b10b86c90 aac01cd84b67a0109b55a36e9328b1e3 65fce161d71ce7131a543ea4cb5f7e9f 1d8b00696447001400 Josefsson & Liusvaara Expires February 20, 2017 [Page 32] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 MESSAGE (length 11 bytes): 0c3e544074ec63b0265e0c SIGNATURE: 1f0a8888ce25e8d458a21130879b840a 9089d999aaba039eaf3e3afa090a09d3 89dba82c4ff2ae8ac5cdfb7c55e94d5d 961a29fe0109941e00b8dbdeea6d3b05 1068df7254c0cdc129cbe62db2dc957d bb47b51fd3f213fb8698f064774250a5 028961c9bf8ffd973fe5d5c206492b14 0e00 -----12 octets ALGORITHM: Ed448 SECRET KEY: 258cdd4ada32ed9c9ff54e63756ae582 fb8fab2ac721f2c8e676a72768513d93 9f63dddb55609133f29adf86ec9929dc cb52c1c5fd2ff7e21b PUBLIC KEY: 3ba16da0c6f2cc1f30187740756f5e79 8d6bc5fc015d7c63cc9510ee3fd44adc 24d8e968b6e46e6f94d19b945361726b d75e149ef09817f580 MESSAGE (length 12 bytes): 64a65f3cdedcdd66811e2915 SIGNATURE: 7eeeab7c4e50fb799b418ee5e3197ff6 bf15d43a14c34389b59dd1a7b1b85b4a e90438aca634bea45e3a2695f1270f07 fdcdf7c62b8efeaf00b45c2c96ba457e b1a8bf075a3db28e5c24f6b923ed4ad7 47c3c9e03c7079efb87cb110d3a99861 e72003cbae6d6b8b827e4e6c143064ff 3c00 -----13 octets ALGORITHM: Ed448 Josefsson & Liusvaara Expires February 20, 2017 [Page 33] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 SECRET KEY: 7ef4e84544236752fbb56b8f31a23a10 e42814f5f55ca037cdcc11c64c9a3b29 49c1bb60700314611732a6c2fea98eeb c0266a11a93970100e PUBLIC KEY: b3da079b0aa493a5772029f0467baebe e5a8112d9d3a22532361da294f7bb381 5c5dc59e176b4d9f381ca0938e13c6c0 7b174be65dfa578e80 MESSAGE (length 13 bytes): 64a65f3cdedcdd66811e2915e7 SIGNATURE: 6a12066f55331b6c22acd5d5bfc5d712 28fbda80ae8dec26bdd306743c5027cb 4890810c162c027468675ecf645a8317 6c0d7323a2ccde2d80efe5a1268e8aca 1d6fbc194d3f77c44986eb4ab4177919 ad8bec33eb47bbb5fc6e28196fd1caf5 6b4e7e0ba5519234d047155ac727a105 3100 -----64 octets ALGORITHM: Ed448 SECRET KEY: d65df341ad13e008567688baedda8e9d cdc17dc024974ea5b4227b6530e339bf f21f99e68ca6968f3cca6dfe0fb9f4fa b4fa135d5542ea3f01 PUBLIC KEY: df9705f58edbab802c7f8363cfe5560a b1c6132c20a9f1dd163483a26f8ac53a 39d6808bf4a1dfbd261b099bb03b3fb5 0906cb28bd8a081f00 MESSAGE (length 64 bytes): bd0f6a3747cd561bdddf4640a332461a 4a30a12a434cd0bf40d766d9c6d458e5 512204a30c17d1f50b5079631f64eb31 12182da3005835461113718d1a5ef944 Josefsson & Liusvaara Expires February 20, 2017 [Page 34] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 SIGNATURE: 554bc2480860b49eab8532d2a533b7d5 78ef473eeb58c98bb2d0e1ce488a98b1 8dfde9b9b90775e67f47d4a1c3482058 efc9f40d2ca033a0801b63d45b3b722e f552bad3b4ccb667da350192b61c508c f7b6b5adadc2c8d9a446ef003fb05cba 5f30e88e36ec2703b349ca229c267083 3900 -----256 octets ALGORITHM: Ed448 SECRET KEY: 2ec5fe3c17045abdb136a5e6a913e32a b75ae68b53d2fc149b77e504132d3756 9b7e766ba74a19bd6162343a21c8590a a9cebca9014c636df5 PUBLIC KEY: 79756f014dcfe2079f5dd9e718be4171 e2ef2486a08f25186f6bff43a9936b9b fe12402b08ae65798a3d81e22e9ec80e 7690862ef3d4ed3a00 MESSAGE (length 256 bytes): 15777532b0bdd0d1389f636c5f6b9ba7 34c90af572877e2d272dd078aa1e567c fa80e12928bb542330e8409f31745041 07ecd5efac61ae7504dabe2a602ede89 e5cca6257a7c77e27a702b3ae39fc769 fc54f2395ae6a1178cab4738e543072f c1c177fe71e92e25bf03e4ecb72f47b6 4d0465aaea4c7fad372536c8ba516a60 39c3c2a39f0e4d832be432dfa9a706a6 e5c7e19f397964ca4258002f7c0541b5 90316dbc5622b6b2a6fe7a4abffd9610 5eca76ea7b98816af0748c10df048ce0 12d901015a51f189f3888145c03650aa 23ce894c3bd889e030d565071c59f409 a9981b51878fd6fc110624dcbcde0bf7 a69ccce38fabdf86f3bef6044819de11 SIGNATURE: c650ddbb0601c19ca11439e1640dd931 f43c518ea5bea70d3dcde5f4191fe53f Josefsson & Liusvaara Expires February 20, 2017 [Page 35] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 00cf966546b72bcc7d58be2b9badef28 743954e3a44a23f880e8d4f1cfce2d7a 61452d26da05896f0a50da66a239a8a1 88b6d825b3305ad77b73fbac0836ecc6 0987fd08527c1a8e80d5823e65cafe2a 3d00 -----1023 octets ALGORITHM: Ed448 SECRET KEY: 872d093780f5d3730df7c212664b37b8 a0f24f56810daa8382cd4fa3f77634ec 44dc54f1c2ed9bea86fafb7632d8be19 9ea165f5ad55dd9ce8 PUBLIC KEY: a81b2e8a70a5ac94ffdbcc9badfc3feb 0801f258578bb114ad44ece1ec0e799d a08effb81c5d685c0c56f64eecaef8cd f11cc38737838cf400 MESSAGE (length 1023 bytes): 6ddf802e1aae4986935f7f981ba3f035 1d6273c0a0c22c9c0e8339168e675412 a3debfaf435ed651558007db4384b650 fcc07e3b586a27a4f7a00ac8a6fec2cd 86ae4bf1570c41e6a40c931db27b2faa 15a8cedd52cff7362c4e6e23daec0fbc 3a79b6806e316efcc7b68119bf46bc76 a26067a53f296dafdbdc11c77f7777e9 72660cf4b6a9b369a6665f02e0cc9b6e dfad136b4fabe723d2813db3136cfde9 b6d044322fee2947952e031b73ab5c60 3349b307bdc27bc6cb8b8bbd7bd32321 9b8033a581b59eadebb09b3c4f3d2277 d4f0343624acc817804728b25ab79717 2b4c5c21a22f9c7839d64300232eb66e 53f31c723fa37fe387c7d3e50bdf9813 a30e5bb12cf4cd930c40cfb4e1fc6225 92a49588794494d56d24ea4b40c89fc0 596cc9ebb961c8cb10adde976a5d602b 1c3f85b9b9a001ed3c6a4d3b1437f520 96cd1956d042a597d561a596ecd3d173 5a8d570ea0ec27225a2c4aaff26306d1 526c1af3ca6d9cf5a2c98f47e1c46db9 Josefsson & Liusvaara Expires February 20, 2017 [Page 36] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 a33234cfd4d81f2c98538a09ebe76998 d0d8fd25997c7d255c6d66ece6fa56f1 1144950f027795e653008f4bd7ca2dee 85d8e90f3dc315130ce2a00375a318c7 c3d97be2c8ce5b6db41a6254ff264fa6 155baee3b0773c0f497c573f19bb4f42 40281f0b1f4f7be857a4e59d416c06b4 c50fa09e1810ddc6b1467baeac5a3668 d11b6ecaa901440016f389f80acc4db9 77025e7f5924388c7e340a732e554440 e76570f8dd71b7d640b3450d1fd5f041 0a18f9a3494f707c717b79b4bf75c984 00b096b21653b5d217cf3565c9597456 f70703497a078763829bc01bb1cbc8fa 04eadc9a6e3f6699587a9e75c94e5bab 0036e0b2e711392cff0047d0d6b05bd2 a588bc109718954259f1d86678a579a3 120f19cfb2963f177aeb70f2d4844826 262e51b80271272068ef5b3856fa8535 aa2a88b2d41f2a0e2fda7624c2850272 ac4a2f561f8f2f7a318bfd5caf969614 9e4ac824ad3460538fdc25421beec2cc 6818162d06bbed0c40a387192349db67 a118bada6cd5ab0140ee273204f628aa d1c135f770279a651e24d8c14d75a605 9d76b96a6fd857def5e0b354b27ab937 a5815d16b5fae407ff18222c6d1ed263 be68c95f32d908bd895cd76207ae7264 87567f9a67dad79abec316f683b17f2d 02bf07e0ac8b5bc6162cf94697b3c27c d1fea49b27f23ba2901871962506520c 392da8b6ad0d99f7013fbc06c2c17a56 9500c8a7696481c1cd33e9b14e40b82e 79a5f5db82571ba97bae3ad3e0479515 bb0e2b0f3bfcd1fd33034efc6245eddd 7ee2086ddae2600d8ca73e214e8c2b0b db2b047c6a464a562ed77b73d2d841c4 b34973551257713b753632efba348169 abc90a68f42611a40126d7cb21b58695 568186f7e569d2ff0f9e745d0487dd2e b997cafc5abf9dd102e62ff66cba87 SIGNATURE: e301345a41a39a4d72fff8df69c98075 a0cc082b802fc9b2b6bc503f926b65bd df7f4c8f1cb49f6396afc8a70abe6d8a ef0db478d4c6b2970076c6a0484fe76d 76b3a97625d79f1ce240e7c576750d29 Josefsson & Liusvaara Expires February 20, 2017 [Page 37] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 5528286f719b413de9ada3e8eb78ed57 3603ce30d8bb761785dc30dbc320869e 1a00 ----- 7.5. Test Vectors for Ed448ph -----TEST abc ALGORITHM: Ed448ph SECRET KEY: 833fe62409237b9d62ec77587520911e 9a759cec1d19755b7da901b96dca3d42 ef7822e0d5104127dc05d6dbefde69e3 ab2cec7c867c6e2c49 PUBLIC KEY: 259b71c19f83ef77a7abd26524cbdb31 61b590a48f7d17de3ee0ba9c52beb743 c09428a131d6b1b57303d90d8132c276 d5ed3d5d01c0f53880 MESSAGE (length 3 bytes): 616263 SIGNATURE: 822f6901f7480f3d5f562c592994d969 3602875614483256505600bbc281ae38 1f54d6bce2ea911574932f52a4e6cadd 78769375ec3ffd1b801a0d9b3f4030cd 433964b6457ea39476511214f97469b5 7dd32dbc560a9a94d00bff07620464a3 ad203df7dc7ce360c3cd3696d9d9fab9 0f00 -----TEST abc (with context) ALGORITHM: Ed448ph SECRET KEY: 833fe62409237b9d62ec77587520911e 9a759cec1d19755b7da901b96dca3d42 ef7822e0d5104127dc05d6dbefde69e3 ab2cec7c867c6e2c49 Josefsson & Liusvaara Expires February 20, 2017 [Page 38] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 PUBLIC KEY: 259b71c19f83ef77a7abd26524cbdb31 61b590a48f7d17de3ee0ba9c52beb743 c09428a131d6b1b57303d90d8132c276 d5ed3d5d01c0f53880 MESSAGE (length 3 bytes): 616263 CONTEXT: 666f6f SIGNATURE: c32299d46ec8ff02b54540982814dce9 a05812f81962b649d528095916a2aa48 1065b1580423ef927ecf0af5888f90da 0f6a9a85ad5dc3f280d91224ba9911a3 653d00e484e2ce232521481c8658df30 4bb7745a73514cdb9bf3e15784ab7128 4f8d0704a608c54a6b62d97beb511d13 2100 ----- 8. Acknowledgements EdDSA and Ed25519 was initially described in a paper due to Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. The Ed448 curves is due to Mike Hamburg. This draft is based on an earlier draft co-authored by Niels Moeller. Feedback on this document was received from Werner Koch, Damien Miller, Bob Bradley, Franck Rondepierre, Alexey Melnikov, Kenny Paterson, and Robert Edmonds. The Ed25519 test vectors were double checked by Bob Bradley using 3 separate implementations (one based on TweetNaCl and 2 different implementations based on code from SUPERCOP). 9. IANA Considerations None. 10. Security Considerations Josefsson & Liusvaara Expires February 20, 2017 [Page 39] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 10.1. Side-channel leaks For implementations performing signatures, secrecy of the private key is fundamental. It is possible to protect against some side-channel attacks by ensuring that the implementation executes exactly the same sequence of instructions and performs exactly the same memory accesses, for any value of the private key. To make an implementation side-channel silent in this way, the modulo p arithmetic must not use any data-dependent branches, e.g., related to carry propagation. Side channel-silent point addition is straightforward, thanks to the unified formulas. Scalar multiplication, multiplying a point by an integer, needs some additional effort to implement in a side-channel silent manner. One simple approach is to implement a side-channel silent conditional assignment, and use together with the binary algorithm to examine one bit of the integer at a time. Compared to other signature schemes, avoiding data-dependent branches is easier due to side-channel silent modulo p arithmetic being easier (with recommended curves) and having complete addition formulas instead of having number of special cases. Note that the example implementations in this document do not attempt to be side-channel silent. 10.2. Randomness considerations EdDSA signatures are deterministic. This protects against attacks arising from signing with bad randomness, effects of which can depending on algorithm range up to full private key compromise. It can be surprisingly hard to ensure good-quality random numbers and there have been numerous security failures relating to this. Obviously, private key generation requires randomness, but due to the fact that private key is hashed before use, a few missing bits of entropy aren't a disaster. The basic signature verification is also deterministic. However some speedups by verifying multiple signatures at once do require random numbers. 10.3. Use of contexts Contexts can be used to separate uses of the protocol between different protocols (which is very hard to reliably do otherwise) and Josefsson & Liusvaara Expires February 20, 2017 [Page 40] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 between different uses within the same protocol. However, the following SHOULD be kept in mind when using this facility: The context SHOULD be a constant string specified by the protocol using it. It SHOULD NOT incorporate variable elements from the message itself. Contexts SHOULD NOT be used opportunistically, as that kind of use is very error-prone. If contexts are used, one SHOULD require all signature schemes available for use in that purpose support contexts. Contexts are an extra input, which percolates out of APIs, as such, even if signature scheme supports contexts, those may not be available for use. This problem is compounded by the fact that many times the application is not invoking the signing and verification functions directly, but via some other protocol. 10.4. Signature malleability Some systems assume signatures are not malleable: That is, given a valid signature for some message under some key, the attacker can't produce another valid signature for the same message and key. Ed25519 and Ed448 signatures are not malleable due to the verification check that decoded S is smaller than l. Without this check, one can add multiple of l into scalar part and still pass signature verification, resulting in malleable signatures. 10.5. Choice of signature primitive The Ed25519 and Ed25519ph have nominal strength of 128 bits, whereas Ed448 and Ed448ph have strength of 224. While the lower strength is sufficient for the foreseeable future, the higher level brings some defense against possible future cryptographic advances. Both are demolished by quantum computers just about the same. The Ed25519ph and Ed448ph variants are prehashed. This is mainly useful for inter-operation with legacy APIs, since in most of the cases, either the amount of data signed is not large, or the protocol is in position to do digesting in ways better than just prehashing (e.g. tree hashing or splitting the data). The prehashing also makes the functions greatly more vulnerable to weaknesses in hash functions used. These variants SHOULD NOT be used. Ed25519ctx and Ed448 have contexts. However, this is balanced by the problems noted in section about contexts. Josefsson & Liusvaara Expires February 20, 2017 [Page 41] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 On implementation front, Ed25519 is widely implemented, and has many high-quality implementations. The others have much worse support. As summary, if high 128-bit security level is enough, use of Ed25519 is RECOMMENDED, otherwise Ed448 is RECOMMENDED. 10.6. Mixing different prehashes The schemes described in this document are designed to be resistant to mixing prehashes. That is, it is infeasible to find a message that verifies using the same signature under another scheme, even if original signed message was chosen. Thus one can use the same keypair for both Ed25519, Ed25519ctx and Ed25519ph and correspondingly with Ed448 and Ed448ph. The "SigEd25519 no Ed25519 collisions" constant is chosen to be textual string such that it does not decode as a point. Because the inner hash input in Ed25519 signature always starts with a valid point, there is no way trivial collision can be constructed. In the case of seed hash, trivial collisions are so unlikely, even with attacker choosing all inputs, that it is much more probable that something else goes catastrophically wrong. 10.7. Signing large amounts of data at once Avoid signing large amounts of data at once (where "large" depends on expected verifier). In particular, unless the underlying protocol does not require it, the receiver MUST buffer the entire message (or enough information to reconstruct it, e.g. compressed or encrypted version) to be verified. This is needed because most of the time, it is unsafe to process unverified data, and verifying the signature makes a pass through whole message, causing ultimately at least two passes through. As API consideration, this means that any IUF (Initialize Update Finalize) verification interface is prone to misuse It is a bad idea to modify Ed25519 or Ed448 signing to be able to create valid Ed25519/Ed448 signatures using IUF interface with only constant buffering. Pretty much any error in such would cause catastrophic security failure. 10.8. Multiplication by cofactor in verification The given verification formulas for both Ed25519 and Ed448 multiply points by the cofactor. While this is not strictly necessary for security (in fact, any signature that meets the non-multiplied Josefsson & Liusvaara Expires February 20, 2017 [Page 42] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 equation will satisfy the multiplied one), in some applications it is undesirable for implementations to disagree about exact set of valid signatures. Such disagreements could open up e.g. fingerprinting attacks. 10.9. Use of SHAKE256 as hash function Ed448 uses SHAKE256 as hash function, even if SHAKE256 is specifically defined not to be a hash function. The first potentially troublesome property is that shorter outputs are prefixes of longer ones. This is acceptable because output lengths are fixed. The second potentially troublesome property is failing to meet standard hash security notions (especially with preimages). However, the estimated 256-bit security level against collisions and preimages is sufficient to pair with 224-bit level elliptic curve. 11. References 11.1. Normative References [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 2006, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [FIPS202] National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS 202, August 2015. 11.2. Informative References [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [EDDSA] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. Yang, "High-speed high-security signatures", WWW http://ed25519.cr.yp.to/ed25519-20110926.pdf, September 2011. Josefsson & Liusvaara Expires February 20, 2017 [Page 43] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 [EDDSA2] Bernstein, D., Josefsson, S., Lange, T., Schwabe, P., and B. Yang, "EdDSA for more curves", WWW http://ed25519.cr.yp.to/eddsa-20150704.pdf, July 2015. [Faster-ECC] Bernstein, D. and T. Lange, "Faster addition and doubling on elliptic curves", WWW http://eprint.iacr.org/2007/286, July 2007. [Edwards-revisited] Hisil, H., Wong, K., Carter, G., and E. Dawson, "Twisted Edwards Curves Revisited", WWW http://eprint.iacr.org/2008/522, December 2008. [EFD-TWISTED-ADD] Hisil, H., Wong, K., Carter, G., and E. Dawson, "EFD / Genus-1 large-characteristic / Extended coordinates with a=-1 for twisted Edwards curves", WWW http://www.hyperelliptic.org/EFD/g1p/ auto-twisted-extended-1.html#addition-add-2008-hwcd-3, December 2008. [EFD-TWISTED-DBL] Hisil, H., Wong, K., Carter, G., and E. Dawson, "EFD / Genus-1 large-characteristic / Extended coordinates with a=-1 for twisted Edwards curves", WWW http://www.hyperelliptic.org/EFD/g1p/ auto-twisted-extended-1.html#doubling-dbl-2008-hwcd, December 2008. [CURVE25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", WWW http://cr.yp.to/ecdh.html, February 2006. [ED448] Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", WWW http://eprint.iacr.org/2015/625, June 2015. [ED25519-TEST-VECTORS] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. Yang, "Ed25519 test vectors", WWW http://ed25519.cr.yp.to/python/sign.input, July 2011. [ED25519-LIBGCRYPT-TEST-VECTORS] Koch, W., "Ed25519 Libgcrypt test vectors", WWW http://git.gnupg.org/cgi- bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=tests/t-ed25519.in p;h=e13566f826321eece65e02c593bc7d885b3dbe23;hb=refs/ heads/master, July 2014. Josefsson & Liusvaara Expires February 20, 2017 [Page 44] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 [EFD-ADD] Bernstein, D. and T. Lange, "Explicit-Formulas Database / Genus-1 large-characteristic / Projective coordinates for Edwards curves", WWW http://www.hyperelliptic.org/EFD/g1p/ auto-edwards-projective.html#addition-add-2007-bl, 2007. [EFD-DBL] Bernstein, D. and T. Lange, "Explicit-Formulas Database / Genus-1 large-characteristic / Projective coordinates for Edwards curves", WWW http://www.hyperelliptic.org/EFD/g1p/ auto-edwards-projective.html#doubling-dbl-2007-bl, 2007. Appendix A. Ed25519/Ed448 Python Library Below is an example implementation of Ed25519/Ed448 written in Python, version 3.2 or higher is required. Note: This code is not intended for production. Although it should produce correct results for every input, it is slow and makes no attempt to avoid side-channel attacks. [A note to RFC-Editor: Please don't change the relative indentations here: This code is written in programming language where relative indentations are meaningful, so changing those changes program meaning (authors: check this still works in AUTH48). Remove this note before publication.] import hashlib; import os; #Compute candidate square root of x modulo p, with p = 3 (mod 4). def sqrt4k3(x,p): return pow(x,(p + 1)//4,p) #Compute candidate square root of x modulo p, with p = 5 (mod 8). def sqrt8k5(x,p): y = pow(x,(p+3)//8,p) #If the square root exists, it is either y, or y*2^(p-1)/4. if (y * y) % p == x % p: return y else: z = pow(2,(p - 1)//4,p) return (y * z) % p #Decode a hexadecimal string representation of integer. def hexi(s): return int.from_bytes(bytes.fromhex(s),byteorder="big") #Rotate a word x by b places to the left. def rol(x,b): return ((x << b) | (x >> (64 - b))) & (2**64-1) #From little-endian. def from_le(s): return int.from_bytes(s, byteorder="little") Josefsson & Liusvaara Expires February 20, 2017 [Page 45] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 #Do the SHA-3 state transform on state s. def sha3_transform(s): ROTATIONS = [0,1,62,28,27,36,44,6,55,20,3,10,43,25,39,41,45,15,\ 21,8,18,2,61,56,14] PERMUTATION = [1,6,9,22,14,20,2,12,13,19,23,15,4,24,21,8,16,5,3,\ 18,17,11,7,10] RC = [0x0000000000000001,0x0000000000008082,0x800000000000808a,\ 0x8000000080008000,0x000000000000808b,0x0000000080000001,\ 0x8000000080008081,0x8000000000008009,0x000000000000008a,\ 0x0000000000000088,0x0000000080008009,0x000000008000000a,\ 0x000000008000808b,0x800000000000008b,0x8000000000008089,\ 0x8000000000008003,0x8000000000008002,0x8000000000000080,\ 0x000000000000800a,0x800000008000000a,0x8000000080008081,\ 0x8000000000008080,0x0000000080000001,0x8000000080008008] for rnd in range(0,24): #AddColumnParity (Theta) c = [0]*5; d = [0]*5; for i in range(0,25): c[i%5]^=s[i] for i in range(0,5): d[i]=c[(i+4)%5]^rol(c[(i+1)%5],1) for i in range(0,25): s[i]^=d[i%5] #RotateWords (Rho). for i in range(0,25): s[i]=rol(s[i],ROTATIONS[i]) #PermuteWords (Pi) t = s[PERMUTATION[0]] for i in range(0,len(PERMUTATION)-1): s[PERMUTATION[i]]=s[PERMUTATION[i+1]] s[PERMUTATION[-1]]=t; #NonlinearMixRows (Chi) for i in range(0,25,5): t=[s[i],s[i+1],s[i+2],s[i+3],s[i+4],s[i],s[i+1]] for j in range(0,5): s[i+j]=t[j]^((~t[j+1])&(t[j+2])) #AddRoundConstant (Iota) s[0]^=RC[rnd] #Reinterpret octet array b to word array and XOR it to state s. def reinterpret_to_words_and_xor(s,b): for j in range(0,len(b)//8): s[j]^=from_le(b[8*j:][:8]) #Reinterpret word array w to octet array and return it. def reinterpret_to_octets(w): mp=bytearray() for j in range(0,len(w)): mp+=w[j].to_bytes(8,byteorder="little") return mp #(semi-)generic SHA-3 implementation Josefsson & Liusvaara Expires February 20, 2017 [Page 46] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 def sha3_raw(msg,r_w,o_p,e_b): r_b=8*r_w s=[0]*25 #Handle whole blocks. idx=0 blocks=len(msg)//r_b for i in range(0,blocks): reinterpret_to_words_and_xor(s,msg[idx:][:r_b]) idx+=r_b sha3_transform(s) #Handle last block padding. m=bytearray(msg[idx:]) m.append(o_p) while len(m) < r_b: m.append(0) m[len(m)-1]|=128 #Handle padded last block. reinterpret_to_words_and_xor(s,m) sha3_transform(s) #Output. out = bytearray() while len(out)>((b-1)&7) #Decode y. If this fails, fail. y = self.base_field.frombytes(s,b) if y is None: return (None,None) #Try to recover x. If it does not exist, or is zero and xs is #wrong, fail. x=self.solve_x2(y).sqrt() if x is None or (x.iszero() and xs!=x.sign()): return (None,None) #If sign of x isn't correct, flip it. if x.sign()!=xs: x=-x # Return the constructed point. return (x,y) def encode_base(self,b): xp,yp=self.x/self.z,self.y/self.z #Encode y. s=bytearray(yp.tobytes(b)) #Add sign bit of x to encoding. if xp.sign()!=0: s[(b-1)//8]|=1<<(b-1)%8 return s def __mul__(self,x): r=self.zero_elem() s=self while x > 0: if (x%2)>0: r=r+s s=s.double() x=x//2 return r #Check two points are equal. def __eq__(self,y): #Need to check x1/z1 == x2/z2 and similarly for y, so cross- #multiply to eliminate divisions. xn1=self.x*y.z xn2=y.x*self.z yn1=self.y*y.z yn2=y.y*self.z return xn1==xn2 and yn1==yn2 #Check two points are not equal. Josefsson & Liusvaara Expires February 20, 2017 [Page 49] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 def __ne__(self,y): return not (self==y) #A point on Edwards25519 class Edwards25519Point(EdwardsPoint): #Create a new point on curve. base_field=Field(1,2**255-19) d=-base_field.make(121665)/base_field.make(121666) f0=base_field.make(0) f1=base_field.make(1) xb=base_field.make(hexi("216936D3CD6E53FEC0A4E231FDD6DC5C692CC76"+\ "09525A7B2C9562D608F25D51A")) yb=base_field.make(hexi("666666666666666666666666666666666666666"+\ "6666666666666666666666658")) #The standard base point. @staticmethod def stdbase(): return Edwards25519Point(Edwards25519Point.xb,\ Edwards25519Point.yb) def __init__(self,x,y): #Check the point is actually on the curve. if y*y-x*x!=self.f1+self.d*x*x*y*y: raise ValueError("Invalid point") self.initpoint(x, y) self.t=x*y #Decode a point representation. def decode(self,s): x,y=self.decode_base(s,256); return Edwards25519Point(x, y) if x is not None else None #Encode a point representation def encode(self): return self.encode_base(256) #Construct neutral point on this curve. def zero_elem(self): return Edwards25519Point(self.f0,self.f1) #Solve for x^2. def solve_x2(self,y): return ((y*y-self.f1)/(self.d*y*y+self.f1)) #Point addition. def __add__(self,y): #The formulas are from EFD. tmp=self.zero_elem() zcp=self.z*y.z A=(self.y-self.x)*(y.y-y.x) B=(self.y+self.x)*(y.y+y.x) C=(self.d+self.d)*self.t*y.t D=zcp+zcp E,H=B-A,B+A F,G=D-C,D+C Josefsson & Liusvaara Expires February 20, 2017 [Page 50] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 tmp.x,tmp.y,tmp.z,tmp.t=E*F,G*H,F*G,E*H return tmp #Point doubling. def double(self): #The formulas are from EFD (with assumption a=-1 propagated). tmp=self.zero_elem() A=self.x*self.x B=self.y*self.y Ch=self.z*self.z C=Ch+Ch H=A+B xys=self.x+self.y E=H-xys*xys G=A-B F=C+G tmp.x,tmp.y,tmp.z,tmp.t=E*F,G*H,F*G,E*H return tmp #Order of basepoint. def l(self): return hexi("1000000000000000000000000000000014def9dea2f79cd"+\ "65812631a5cf5d3ed") #The logarithm of cofactor. def c(self): return 3 #The highest set bit def n(self): return 254 #The coding length def b(self): return 256 #Validity check (for debugging) def is_valid_point(self): x,y,z,t=self.x,self.y,self.z,self.t x2=x*x y2=y*y z2=z*z lhs=(y2-x2)*z2 rhs=z2*z2+self.d*x2*y2 assert(lhs == rhs) assert(t*z == x*y) #A point on Edward448 class Edwards448Point(EdwardsPoint): #Create a new point on curve. base_field=Field(1,2**448-2**224-1) d=base_field.make(-39081) f0=base_field.make(0) f1=base_field.make(1) xb=base_field.make(hexi("4F1970C66BED0DED221D15A622BF36DA9E14657"+\ "0470F1767EA6DE324A3D3A46412AE1AF72AB66511433B80E18B00938E26"+\ "26A82BC70CC05E")) Josefsson & Liusvaara Expires February 20, 2017 [Page 51] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 yb=base_field.make(hexi("693F46716EB6BC248876203756C9C7624BEA737"+\ "36CA3984087789C1E05A0C2D73AD3FF1CE67C39C4FDBD132C4ED7C8AD98"+\ "08795BF230FA14")) #The standard base point. @staticmethod def stdbase(): return Edwards448Point(Edwards448Point.xb,Edwards448Point.yb) def __init__(self,x,y): #Check the point is actually on the curve. if y*y+x*x!=self.f1+self.d*x*x*y*y: raise ValueError("Invalid point") self.initpoint(x, y) #Decode a point representation. def decode(self,s): x,y=self.decode_base(s,456); return Edwards448Point(x, y) if x is not None else None #Encode a point representation def encode(self): return self.encode_base(456) #Construct neutral point on this curve. def zero_elem(self): return Edwards448Point(self.f0,self.f1) #Solve for x^2. def solve_x2(self,y): return ((y*y-self.f1)/(self.d*y*y-self.f1)) #Point addition. def __add__(self,y): #The formulas are from EFD. tmp=self.zero_elem() xcp,ycp,zcp=self.x*y.x,self.y*y.y,self.z*y.z B=zcp*zcp E=self.d*xcp*ycp F,G=B-E,B+E tmp.x=zcp*F*((self.x+self.y)*(y.x+y.y)-xcp-ycp) tmp.y,tmp.z=zcp*G*(ycp-xcp),F*G return tmp #Point doubling. def double(self): #The formulas are from EFD. tmp=self.zero_elem() x1s,y1s,z1s=self.x*self.x,self.y*self.y,self.z*self.z xys=self.x+self.y F=x1s+y1s J=F-(z1s+z1s) tmp.x,tmp.y,tmp.z=(xys*xys-x1s-y1s)*J,F*(x1s-y1s),F*J return tmp #Order of basepoint. def l(self): Josefsson & Liusvaara Expires February 20, 2017 [Page 52] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 return hexi("3ffffffffffffffffffffffffffffffffffffffffffffff"+\ "fffffffff7cca23e9c44edb49aed63690216cc2728dc58f552378c2"+\ "92ab5844f3") #The logarithm of cofactor. def c(self): return 2 #The highest set bit def n(self): return 447 #The coding length def b(self): return 456 #Validity check (for debugging) def is_valid_point(self): x,y,z=self.x,self.y,self.z x2=x*x y2=y*y z2=z*z lhs=(x2+y2)*z2 rhs=z2*z2+self.d*x2*y2 assert(lhs == rhs) #Simple self-check. def curve_self_check(point): p=point q=point.zero_elem() z=q l=p.l()+1 p.is_valid_point() q.is_valid_point() for i in range(0,point.b()): if (l>>i)&1 != 0: q=q+p q.is_valid_point() p=p.double() p.is_valid_point() assert q.encode() == point.encode() assert q.encode() != p.encode() assert q.encode() != z.encode() #Simple self-check. def self_check_curves(): curve_self_check(Edwards25519Point.stdbase()) curve_self_check(Edwards448Point.stdbase()) #PureEdDSA scheme. #Limitation: Only b mod 8 = 0 is handled. class PureEdDSA: #Create a new object. def __init__(self,properties): self.B=properties["B"] Josefsson & Liusvaara Expires February 20, 2017 [Page 53] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 self.H=properties["H"] self.l=self.B.l() self.n=self.B.n() self.b=self.B.b() self.c=self.B.c() #Clamp a private scalar. def __clamp(self,a): _a = bytearray(a) for i in range(0,self.c): _a[i//8]&=~(1<<(i%8)) _a[self.n//8]|=1<<(self.n%8) for i in range(self.n+1,self.b): _a[i//8]&=~(1<<(i%8)) return _a #Generate a key. If privkey is None, random one is generated. #In any case, privkey, pubkey pair is returned. def keygen(self,privkey): #If no private key data given, generate random. if privkey is None: privkey=os.urandom(self.b//8) #Expand key. khash=self.H(privkey,None,None) a=from_le(self.__clamp(khash[:self.b//8])) #Return the keypair (public key is A=Enc(aB). return privkey,(self.B*a).encode() #Sign with keypair. def sign(self,privkey,pubkey,msg,ctx,hflag): #Expand key. khash=self.H(privkey,None,None) a=from_le(self.__clamp(khash[:self.b//8])) seed=khash[self.b//8:] #Calculate r and R (R only used in encoded form) r=from_le(self.H(seed+msg,ctx,hflag))%self.l R=(self.B*r).encode() #Calculate h. h=from_le(self.H(R+pubkey+msg,ctx,hflag))%self.l #Calculate s. S=((r+h*a)%self.l).to_bytes(self.b//8,byteorder="little") #The final signature is concatenation of R and S. return R+S #Verify signature with public key. def verify(self,pubkey,msg,sig,ctx,hflag): #Sanity-check sizes. if len(sig)!=self.b//4: return False if len(pubkey)!=self.b//8: return False #Split signature into R and S, and parse. Rraw,Sraw=sig[:self.b//8],sig[self.b//8:] R,S=self.B.decode(Rraw),from_le(Sraw) #Parse public key. A=self.B.decode(pubkey) #Check parse results. Josefsson & Liusvaara Expires February 20, 2017 [Page 54] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 if (R is None) or (A is None) or S>=self.l: return False #Calculate h. h=from_le(self.H(Rraw+pubkey+msg,ctx,hflag))%self.l #Calculate left and right sides of check eq. rhs=R+(A*h) lhs=self.B*S for i in range(0, self.c): lhs = lhs.double() rhs = rhs.double() #Check eq. holds? return lhs==rhs def Ed25519_inthash(data,ctx,hflag): if (ctx is not None and len(ctx) > 0) or hflag: raise ValueError("Contexts/hashes not supported") return hashlib.sha512(data).digest() #The base PureEdDSA schemes. pEd25519=PureEdDSA({\ "B":Edwards25519Point.stdbase(),\ "H":Ed25519_inthash\ }) def Ed25519ctx_inthash(data,ctx,hflag): dompfx = b"" PREFIX=b"SigEd25519 no Ed25519 collisions" if ctx is not None: if len(ctx) > 255: raise ValueError("Context too big") dompfx=PREFIX+bytes([1 if hflag else 0,len(ctx)])+ctx return hashlib.sha512(dompfx+data).digest() pEd25519ctx=PureEdDSA({\ "B":Edwards25519Point.stdbase(),\ "H":Ed25519ctx_inthash\ }) def Ed448_inthash(data,ctx,hflag): dompfx = b"" if ctx is not None: if len(ctx) > 255: raise ValueError("Context too big") dompfx=b"SigEd448"+bytes([1 if hflag else 0,len(ctx)])+ctx return shake256(dompfx+data,114) pEd448 = PureEdDSA({\ "B":Edwards448Point.stdbase(),\ "H":Ed448_inthash\ }) Josefsson & Liusvaara Expires February 20, 2017 [Page 55] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 #EdDSA scheme. class EdDSA: #Create a new scheme object, with specified PureEdDSA base scheme #and specified prehash. def __init__(self,pure_scheme,prehash): self.__pflag = True self.__pure=pure_scheme self.__prehash=prehash if self.__prehash is None: self.__prehash = lambda x,y:x self.__pflag = False # Generate a key. If privkey is none, generates a random # privkey key, otherwise uses specified private key. # Returns pair (privkey, pubkey). def keygen(self,privkey): return self.__pure.keygen(privkey) # Sign message msg using specified keypair. def sign(self,privkey,pubkey,msg,ctx=None): if ctx is None: ctx=b""; return self.__pure.sign(privkey,pubkey,self.__prehash(msg,ctx),\ ctx,self.__pflag) # Verify signature sig on message msg using public key pubkey. def verify(self,pubkey,msg,sig,ctx=None): if ctx is None: ctx=b""; return self.__pure.verify(pubkey,self.__prehash(msg,ctx),sig,\ ctx,self.__pflag) def Ed448ph_prehash(data,ctx): return shake256(data,64) #Our signature schemes. Ed25519 = EdDSA(pEd25519,None) Ed25519ctx = EdDSA(pEd25519ctx,None) Ed25519ph = EdDSA(pEd25519ctx,lambda x,y:hashlib.sha512(x).digest()) Ed448 = EdDSA(pEd448,None) Ed448ph = EdDSA(pEd448,Ed448ph_prehash) def eddsa_obj(name): if name == "Ed25519": return Ed25519 if name == "Ed25519ctx": return Ed25519ctx if name == "Ed25519ph": return Ed25519ph if name == "Ed448": return Ed448 if name == "Ed448ph": return Ed448ph raise NotImplementedError("Algorithm not implemented") Josefsson & Liusvaara Expires February 20, 2017 [Page 56] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 Appendix B. Library driver Below is a command-line tool that uses the library above to perform computations, for interactive use or for self-checking. [A note to RFC-Editor: Please don't change the relative indentations here: This code is written in programming language where relative indentations are meaningful, so changing those changes program meaning (authors: check this still works in AUTH48). Remove this note before publication.] Josefsson & Liusvaara Expires February 20, 2017 [Page 57] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 import sys import binascii from eddsa2 import Ed25519 def munge_string(s, pos, change): return (s[:pos] + int.to_bytes(s[pos] ^ change, 1, "little") + s[pos+1:]) # Read a file in the format of # http://ed25519.cr.yp.to/python/sign.input lineno = 0 while True: line = sys.stdin.readline() if not line: break lineno = lineno + 1 print(lineno) fields = line.split(":") secret = (binascii.unhexlify(fields[0]))[:32] public = binascii.unhexlify(fields[1]) msg = binascii.unhexlify(fields[2]) signature = binascii.unhexlify(fields[3])[:64] privkey,pubkey = Ed25519.keygen(secret) assert public == pubkey assert signature == Ed25519.sign(privkey, pubkey, msg) assert Ed25519.verify(public, msg, signature) if len(msg) == 0: bad_msg = b"x" else: bad_msg = munge_string(msg, len(msg) // 3, 4) assert not Ed25519.verify(public, bad_msg, signature) bad_signature = munge_string(signature, 20, 8) assert not Ed25519.verify(public, msg, bad_signature) bad_signature = munge_string(signature, 40, 16) assert not Ed25519.verify(public, msg, bad_signature) Authors' Addresses Simon Josefsson SJD AB Email: simon@josefsson.org URI: http://josefsson.org/ Josefsson & Liusvaara Expires February 20, 2017 [Page 58] Internet-Draft EdDSA: Ed25519 and Ed448 August 2016 Ilari Liusvaara Independent Email: ilariliusvaara@welho.com Josefsson & Liusvaara Expires February 20, 2017 [Page 59] ./rfc-index.txt0000664000764400076440000616302113041603171012776 0ustar iustyiusty ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC INDEX ------------- (CREATED ON: 01/24/2017.) This file contains citations for all RFCs in numeric order. RFC citations appear in this format: #### Title of RFC. Author 1, Author 2, Author 3. Issue date. (Format: ASCII) (Obsoletes xxx) (Obsoleted by xxx) (Updates xxx) (Updated by xxx) (Also FYI ####) (Status: ssssss) (DOI: ddd) or #### Not Issued. For example: 1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. October 1989. (Format: TXT=298, PS=551697, PDF=197036 bytes) (Also RFC1119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1129) Key to citations: #### is the RFC number. Following the RFC number are the title, the author(s), and the publication date of the RFC. Each of these is terminated by a period. Following the number are the title (terminated with a period), the author, or list of authors (terminated with a period), and the date (terminated with a period). The format and length follow in parenthesis. One or more of the following alternative formats are listed: ASCII text (TXT), PostScript (PS), and/or Adobe (PDF). Each format is followed by an equals sign and the number of bytes for that version. For example (Format: TXT=aaaaa, PS=bbbbbb bytes) shows that the ASCII text version is aaaaa bytes, and the PostScript version of the RFC is bbbbbb bytes. Obsoletes xxxx refers to other RFCs that this one replaces; Obsoleted by xxxx refers to RFCs that have replaced this one. Updates xxxx refers to other RFCs that this one merely updates but does not replace); Updated by xxxx refers to RFCs that have updated (but not replaced) this one. Generally, only immediately succeeding and/or preceding RFCs are indicated, not the entire history of each related earlier or later RFC in a related series. The (Also FYI ##) or (Also STD ##) or (Also BCP ##) phrase gives the equivalent FYI, STD, or BCP number if the RFC is also in those document sub-series. The Status field gives the document's current status (see RFC 2026). The (DOI ddd) field gives the Digital Object Identifier. RFCs may be obtained in a number of ways, using HTTP, FTP, or email. See the RFC Editor Web page http://www.rfc-editor.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC INDEX --------- 0001 Host Software. S. Crocker. April 1969. (Format: TXT=21088 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0001) 0002 Host software. B. Duvall. April 1969. (Format: TXT=17145 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0002) 0003 Documentation conventions. S.D. Crocker. April 1969. (Format: TXT=2323 bytes) (Obsoleted by RFC0010) (Status: UNKNOWN) (DOI: 10.17487/RFC0003) 0004 Network timetable. E.B. Shapiro. March 1969. (Format: TXT=5933 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0004) 0005 Decode Encode Language (DEL). J. Rulifson. June 1969. (Format: TXT=26408 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0005) 0006 Conversation with Bob Kahn. S.D. Crocker. April 1969. (Format: TXT=1568 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0006) 0007 Host-IMP interface. G. Deloche. May 1969. (Format: TXT=13408 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0007) 0008 ARPA Network Functional Specifications. G. Deloche. May 1969. (Format: PDF=750612 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0008) 0009 Host Software. G. Deloche. May 1969. (Format: PDF=722638 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0009) 0010 Documentation conventions. S.D. Crocker. July 1969. (Format: TXT=3348 bytes) (Obsoletes RFC0003) (Obsoleted by RFC0016) (Updated by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0010) 0011 Implementation of the Host - Host Software Procedures in GORDO. G. Deloche. August 1969. (Format: TXT=46971, PDF=2186431 bytes) (Obsoleted by RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0011) 0012 IMP-Host interface flow diagrams. M. Wingfield. August 1969. (Format: TXT=177, PS=1489750, PDF=1163721 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0012) 0013 Zero Text Length EOF Message. V. Cerf. August 1969. (Format: TXT=1070 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0013) 0014 Not Issued. 0015 Network subsystem for time sharing hosts. C.S. Carr. September 1969. (Format: TXT=10695 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0015) 0016 M.I.T. S. Crocker. August 1969. (Format: TXT=682 bytes) (Obsoletes RFC0010) (Obsoleted by RFC0024) (Updated by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0016) 0017 Some questions re: Host-IMP Protocol. J.E. Kreznar. August 1969. (Format: TXT=6065 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0017) 0018 IMP-IMP and HOST-HOST Control Links. V. Cerf. September 1969. (Format: TXT=634 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0018) 0019 Two protocol suggestions to reduce congestion at swap bound nodes. J.E. Kreznar. October 1969. (Format: TXT=3392 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0019) 0020 ASCII format for network interchange. V.G. Cerf. October 1969. (Format: TXT=18504, PDF=197096 bytes) (Also STD0080) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0020) 0021 Network meeting. V.G. Cerf. October 1969. (Format: TXT=2143 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0021) 0022 Host-host control message formats. V.G. Cerf. October 1969. (Format: TXT=4606 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0022) 0023 Transmission of Multiple Control Messages. G. Gregg. October 1969. (Format: TXT=690 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0023) 0024 Documentation Conventions. S.D. Crocker. November 1969. (Format: TXT=3460 bytes) (Obsoletes RFC0016) (Updates RFC0010, RFC0016) (Updated by RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0024) 0025 No High Link Numbers. S.D. Crocker. October 1969. (Format: TXT=479 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0025) 0026 Not Issued. 0027 Documentation Conventions. S.D. Crocker. December 1969. (Format: TXT=3661 bytes) (Updates RFC0010, RFC0016, RFC0024) (Updated by RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0027) 0028 Time Standards. W.K. English. January 1970. (Format: TXT=557 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0028) 0029 Response to RFC 28. R.E. Kahn. January 1970. (Format: TXT=790 bytes) (Also RFC0028) (Status: UNKNOWN) (DOI: 10.17487/RFC0029) 0030 Documentation Conventions. S.D. Crocker. February 1970. (Format: TXT=4041 bytes) (Updates RFC0010, RFC0016, RFC0024, RFC0027) (Status: UNKNOWN) (DOI: 10.17487/RFC0030) 0031 Binary Message Forms in Computer. D. Bobrow, W.R. Sutherland. February 1968. (Format: TXT=11191 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0031) 0032 Some Thoughts on SRI's Proposed Real Time Clock. J. Cole. February 1970. (Format: TXT=2216 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0032) 0033 New Host-Host Protocol. S.D. Crocker. February 1970. (Format: TXT=44167 bytes) (Obsoletes RFC0011) (Updated by RFC0036, RFC0047) (Status: UNKNOWN) (DOI: 10.17487/RFC0033) 0034 Some Brief Preliminary Notes on the Augmentation Research Center Clock. W.K. English. February 1970. (Format: TXT=2534 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0034) 0035 Network Meeting. S.D. Crocker. March 1970. (Format: TXT=1282 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0035) 0036 Protocol Notes. S.D. Crocker. March 1970. (Format: TXT=13893 bytes) (Updates RFC0033) (Updated by RFC0039, RFC0044) (Status: UNKNOWN) (DOI: 10.17487/RFC0036) 0037 Network Meeting Epilogue, etc. S.D. Crocker. March 1970. (Format: TXT=9107 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0037) 0038 Comments on Network Protocol from NWG/RFC #36. S.M. Wolfe. March 1970. (Format: TXT=2536 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0038) 0039 Comments on Protocol Re: NWG/RFC #36. E. Harslem, J.F. Heafner. March 1970. (Format: TXT=4779 bytes) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0039) 0040 More Comments on the Forthcoming Protocol. E. Harslem, J.F. Heafner. March 1970. (Format: TXT=3825 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0040) 0041 IMP-IMP Teletype Communication. J.T. Melvin. March 1970. (Format: TXT=1038 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0041) 0042 Message Data Types. E. Ancona. March 1970. (Format: TXT=5247 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0042) 0043 Proposed Meeting. A.G. Nemeth. April 1970. (Format: TXT=1600 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0043) 0044 Comments on NWG/RFC 33 and 36. A. Shoshani, R. Long, A. Landsberg. April 1970. (Format: TXT=7381 bytes) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0044) 0045 New Protocol is Coming. J. Postel, S.D. Crocker. April 1970. (Format: TXT=1130 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0045) 0046 ARPA Network protocol notes. E. Meyer. April 1970. (Format: TXT=41338 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0046) 0047 BBN's Comments on NWG/RFC #33. J. Postel, S. Crocker. April 1970. (Format: TXT=5343 bytes) (Updates RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0047) 0048 Possible protocol plateau. J. Postel, S.D. Crocker. April 1970. (Format: TXT=41696 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0048) 0049 Conversations with S. Crocker (UCLA). E. Meyer. April 1970. (Format: TXT=12384 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0049) 0050 Comments on the Meyer Proposal. E. Harslen, J. Heafner. April 1970. (Format: TXT=4070 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0050) 0051 Proposal for a Network Interchange Language. M. Elie. May 1970. (Format: PDF=967411 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0051) 0052 Updated distribution list. J. Postel, S.D. Crocker. July 1970. (Format: TXT=5088 bytes) (Updated by RFC0069) (Status: UNKNOWN) (DOI: 10.17487/RFC0052) 0053 Official protocol mechanism. S.D. Crocker. June 1970. (Format: TXT=2330 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0053) 0054 Official Protocol Proffering. S.D. Crocker, J. Postel, J. Newkirk, M. Kraley. June 1970. (Format: TXT=20131 bytes) (Updated by RFC0057) (Status: UNKNOWN) (DOI: 10.17487/RFC0054) 0055 Prototypical implementation of the NCP. J. Newkirk, M. Kraley, J. Postel, S.D. Crocker. June 1970. (Format: TXT=48070 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0055) 0056 Third Level Protocol: Logger Protocol. E. Belove, D. Black, R. Flegal, L.G. Farquar. June 1970. (Format: TXT=13066 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0056) 0057 Thoughts and Reflections on NWG/RFC 54. M. Kraley, J. Newkirk. June 1970. (Format: TXT=8360 bytes) (Updates RFC0054) (Status: UNKNOWN) (DOI: 10.17487/RFC0057) 0058 Logical Message Synchronization. T.P. Skinner. June 1970. (Format: TXT=3767 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0058) 0059 Flow Control - Fixed Versus Demand Allocation. E. Meyer. June 1970. (Format: TXT=17691 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0059) 0060 A Simplified NCP Protocol. R. Kalin. July 1970. (Format: TXT=18694 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0060) 0061 Note on Interprocess Communication in a Resource Sharing Computer Network. D.C. Walden. July 1970. (Format: TXT=43946 bytes) (Obsoleted by RFC0062) (Status: UNKNOWN) (DOI: 10.17487/RFC0061) 0062 Systems for Interprocess Communication in a Resource Sharing Computer Network. D.C. Walden. August 1970. (Format: TXT=55784 bytes) (Obsoletes RFC0061) (Status: UNKNOWN) (DOI: 10.17487/RFC0062) 0063 Belated Network Meeting Report. V.G. Cerf. July 1970. (Format: TXT=2961 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0063) 0064 Getting rid of marking. M. Elie. July 1970. (Format: TXT=7556 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0064) 0065 Comments on Host/Host Protocol document #1. D.C. Walden. August 1970. (Format: TXT=5628 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0065) 0066 NIC - third level ideas and other noise. S.D. Crocker. August 1970. (Format: TXT=4575 bytes) (Obsoleted by RFC0123) (Updated by RFC0080, RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0066) 0067 Proposed Change to Host/IMP Spec to Eliminate Marking. W.R. Crowther. January 1970. (Format: TXT=1534 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0067) 0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM. M. Elie. August 1970. (Format: TXT=5041 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0068) 0069 Distribution List Change for MIT. A.K. Bhushan. September 1970. (Format: TXT=841 bytes) (Updates RFC0052) (Status: UNKNOWN) (DOI: 10.17487/RFC0069) 0070 Note on Padding. S.D. Crocker. October 1970. (Format: TXT=12790 bytes) (Updated by RFC0228) (Status: UNKNOWN) (DOI: 10.17487/RFC0070) 0071 Reallocation in Case of Input Error. T. Schipper. September 1970. (Format: TXT=1265 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0071) 0072 Proposed Moratorium on Changes to Network Protocol. R.D. Bressler. September 1970. (Format: TXT=4047 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0072) 0073 Response to NWG/RFC 67. S.D. Crocker. September 1970. (Format: TXT=1268 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0073) 0074 Specifications for Network Use of the UCSB On-Line System. J.E. White. October 1970. (Format: TXT=21368, PDF=521403 bytes) (Updated by RFC0217, RFC0225) (Status: UNKNOWN) (DOI: 10.17487/RFC0074) 0075 Network Meeting. S.D. Crocker. October 1970. (Format: TXT=1318 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0075) 0076 Connection by name: User oriented protocol. J. Bouknight, J. Madden, G.R. Grossman. October 1970. (Format: TXT=26504 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0076) 0077 Network meeting report. J. Postel. November 1970. (Format: TXT=19196 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0077) 0078 NCP Status Report: UCSB/Rand. E. Harslem, J.F. Heafner, J.E. White. October 1970. (Format: TXT=1303 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0078) 0079 Logger Protocol error. E. Meyer. November 1970. (Format: TXT=1515 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0079) 0080 Protocols and Data Formats. E. Harslem, J.F. Heafner. December 1970. (Format: TXT=17620 bytes) (Obsoleted by RFC0123) (Updates RFC0066) (Updated by RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0080) 0081 Request for Reference Information. J. Bouknight. December 1970. (Format: TXT=956 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0081) 0082 Network Meeting Notes. E. Meyer. December 1970. (Format: TXT=38023 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0082) 0083 Language-machine for data reconfiguration. R.H. Anderson, E. Harslem, J.F. Heafner. December 1970. (Format: TXT=22253 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0083) 0084 List of NWG/RFC's 1-80. J.B. North. December 1970. (Format: TXT=12613 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0084) 0085 Network Working Group meeting. S.D. Crocker. December 1970. (Format: TXT=1547 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0085) 0086 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display. S.D. Crocker. January 1971. (Format: TXT=7103 bytes) (Updated by RFC0125) (Status: UNKNOWN) (DOI: 10.17487/RFC0086) 0087 Topic for Discussion at the Next Network Working Group Meeting. A. Vezza. January 1971. (Format: TXT=3593 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0087) 0088 NETRJS: A third level protocol for Remote Job Entry. R.T. Braden, S.M. Wolfe. January 1971. (Format: TXT=19691 bytes) (Obsoleted by RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0088) 0089 Some historic moments in networking. R.M. Metcalfe. January 1971. (Format: TXT=16832 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0089) 0090 CCN as a Network Service Center. R.T. Braden. January 1971. (Format: TXT=11929 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0090) 0091 Proposed User-User Protocol. G.H. Mealy. December 1970. (Format: TXT=27005 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0091) 0092 Not Issued. 0093 Initial Connection Protocol. A.M. McKenzie. January 1971. (Format: TXT=1746 bytes) (Updates RFC0066, RFC0080) (Status: UNKNOWN) (DOI: 10.17487/RFC0093) 0094 Some thoughts on Network Graphics. E. Harslem, J.F. Heafner. February 1971. (Format: TXT=13516 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0094) 0095 Distribution of NWG/RFC's through the NIC. S. Crocker. February 1971. (Format: TXT=8692 bytes) (Obsoleted by RFC0155) (Status: UNKNOWN) (DOI: 10.17487/RFC0095) 0096 An Interactive Network Experiment to Study Modes of Access the Network Information Center. R.W. Watson. February 1971. (Format: TXT=11334 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0096) 0097 First Cut at a Proposed Telnet Protocol. J.T. Melvin, R.W. Watson. February 1971. (Format: TXT=24034, PDF=403375 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0097) 0098 Logger Protocol Proposal. E. Meyer, T. Skinner. February 1971. (Format: TXT=24536 bytes) (Updated by RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0098) 0099 Network Meeting. P.M. Karp. February 1971. (Format: TXT=1010 bytes) (Updated by RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0099) 0100 Categorization and guide to NWG/RFCs. P.M. Karp. February 1971. (Format: TXT=62473 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0100) 0101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971. R.W. Watson. February 1971. (Format: TXT=30343 bytes) (Updated by RFC0108, RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0101) 0102 Output of the Host-Host Protocol glitch cleaning committee. S.D. Crocker. February 1971. (Format: TXT=8511 bytes) (Updated by RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0102) 0103 Implementation of Interrupt Keys. R.B. Kalin. February 1971. (Format: TXT=7592 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0103) 0104 Link 191. J.B. Postel, S.D. Crocker. February 1971. (Format: TXT=1017 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0104) 0105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB. J.E. White. March 1971. (Format: TXT=21938 bytes) (Updated by RFC0217) (Status: UNKNOWN) (DOI: 10.17487/RFC0105) 0106 User/Server Site Protocol Network Host Questionnaire. T.C. O'Sullivan. March 1971. (Format: TXT=6946 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0106) 0107 Output of the Host-Host Protocol Glitch Cleaning Committee. R.D. Bressler, S.D. Crocker, W.R. Crowther, G.R. Grossman, R.S. Tomlinson, J.E. White. March 1971. (Format: TXT=18109 bytes) (Updates RFC0102) (Updated by RFC0111, RFC0124, RFC0132, RFC0154, RFC0179) (Status: UNKNOWN) (DOI: 10.17487/RFC0107) 0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971. R.W. Watson. March 1971. (Format: TXT=1597 bytes) (Updates RFC0101) (Status: UNKNOWN) (DOI: 10.17487/RFC0108) 0109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host. J. Winett. March 1971. (Format: TXT=27716, PDF=645921 bytes) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0109) 0110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts. J. Winett. March 1971. (Format: TXT=8586, PDF=738470 bytes) (Updated by RFC0135) (Status: UNKNOWN) (DOI: 10.17487/RFC0110) 0111 Pressure from the Chairman. S.D. Crocker. March 1971. (Format: TXT=2098 bytes) (Updates RFC0107) (Updated by RFC0130) (Status: UNKNOWN) (DOI: 10.17487/RFC0111) 0112 User/Server Site Protocol: Network Host Questionnaire. T.C. O'Sullivan. April 1971. (Format: TXT=1465, PDF=347370 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0112) 0113 Network activity report: UCSB Rand. E. Harslem, J.F. Heafner, J.E. White. April 1971. (Format: TXT=3442 bytes) (Updated by RFC0227) (Status: UNKNOWN) (DOI: 10.17487/RFC0113) 0114 File Transfer Protocol. A.K. Bhushan. April 1971. (Format: TXT=38981 bytes) (Updated by RFC0133, RFC0141, RFC0171, RFC0172) (Status: UNKNOWN) (DOI: 10.17487/RFC0114) 0115 Some Network Information Center policies on handling documents. R.W. Watson, J.B. North. April 1971. (Format: TXT=16775 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0115) 0116 Structure of the May NWG Meeting. S.D. Crocker. April 1971. (Format: TXT=2395 bytes) (Updates RFC0099) (Updated by RFC0131, RFC0156) (Status: UNKNOWN) (DOI: 10.17487/RFC0116) 0117 Some comments on the official protocol. J. Wong. April 1971. (Format: TXT=7128 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0117) 0118 Recommendations for facility documentation. R.W. Watson. April 1971. (Format: TXT=4573 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0118) 0119 Network Fortran Subprograms. M. Krilanovich. April 1971. (Format: TXT=39140, PDF=760848 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0119) 0120 Network PL1 subprograms. M. Krilanovich. April 1971. (Format: TXT=37192 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0120) 0121 Network on-line operators. M. Krilanovich. April 1971. (Format: TXT=29419 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0121) 0122 Network specifications for UCSB's Simple-Minded File System. J.E. White. April 1971. (Format: TXT=47638 bytes) (Updated by RFC0217, RFC0269, RFC0399, RFC0431) (Status: UNKNOWN) (DOI: 10.17487/RFC0122) 0123 Proffered Official ICP. S.D. Crocker. April 1971. (Format: TXT=4812 bytes) (Obsoletes RFC0066, RFC0080) (Obsoleted by RFC0165) (Updates RFC0098, RFC0101) (Updated by RFC0127, RFC0143, RFC0148) (Status: UNKNOWN) (DOI: 10.17487/RFC0123) 0124 Typographical error in RFC 107. J.T. Melvin. April 1971. (Format: TXT=659 bytes) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0124) 0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream. J. McConnell. April 1971. (Format: TXT=8133 bytes) (Updates RFC0086) (Updated by RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0125) 0126 Graphics Facilities at Ames Research Center. J. McConnell. April 1971. (Format: TXT=1974 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0126) 0127 Comments on RFC 123. J. Postel. April 1971. (Format: TXT=2305 bytes) (Obsoleted by RFC0145) (Updates RFC0123) (Updated by RFC0151) (Status: UNKNOWN) (DOI: 10.17487/RFC0127) 0128 Bytes. J. Postel. April 1971. (Format: TXT=2745 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0128) 0129 Request for comments on socket name structure. E. Harslem, J. Heafner, E. Meyer. April 1971. (Format: TXT=11175 bytes) (Updated by RFC0147) (Status: UNKNOWN) (DOI: 10.17487/RFC0129) 0130 Response to RFC 111: Pressure from the chairman. J.F. Heafner. April 1971. (Format: TXT=2580 bytes) (Updates RFC0111) (Status: UNKNOWN) (DOI: 10.17487/RFC0130) 0131 Response to RFC 116: May NWG meeting. E. Harslem, J.F. Heafner. April 1971. (Format: TXT=5375 bytes) (Updates RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0131) 0132 Typographical Error in RFC 107. J.E. White. April 1971. (Format: TXT=1058 bytes) (Obsoleted by RFC0154) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0132) 0133 File Transfer and Error Recovery. R.L. Sunberg. April 1971. (Format: TXT=8322 bytes) (Updates RFC0114) (Status: UNKNOWN) (DOI: 10.17487/RFC0133) 0134 Network Graphics meeting. A. Vezza. April 1971. (Format: TXT=2684 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0134) 0135 Response to NWG/RFC 110. W. Hathaway. April 1971. (Format: TXT=5282 bytes) (Updates RFC0110) (Status: UNKNOWN) (DOI: 10.17487/RFC0135) 0136 Host accounting and administrative procedures. R.E. Kahn. April 1971. (Format: TXT=8016 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0136) 0137 Telnet Protocol - a proposed document. T.C. O'Sullivan. April 1971. (Format: TXT=17606 bytes) (Updated by RFC0139) (Status: UNKNOWN) (DOI: 10.17487/RFC0137) 0138 Status report on proposed Data Reconfiguration Service. R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. April 1971. (Format: TXT=46641 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0138) 0139 Discussion of Telnet Protocol. T.C. O'Sullivan. May 1971. (Format: TXT=26085 bytes) (Updates RFC0137) (Updated by RFC0158) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0139) 0140 Agenda for the May NWG meeting. S.D. Crocker. May 1971. (Format: TXT=6934 bytes) (Updated by RFC0149) (Status: UNKNOWN) (DOI: 10.17487/RFC0140) 0141 Comments on RFC 114: A File Transfer Protocol. E. Harslem, J.F. Heafner. April 1971. (Format: TXT=3781 bytes) (Updates RFC0114) (Status: UNKNOWN) (DOI: 10.17487/RFC0141) 0142 Time-Out Mechanism in the Host-Host Protocol. C. Kline, J. Wong. May 1971. (Format: TXT=4372 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0142) 0143 Regarding proffered official ICP. W. Naylor, J. Wong, C. Kline, J. Postel. May 1971. (Format: TXT=6963 bytes) (Obsoleted by RFC0165) (Updates RFC0123, RFC0145) (Status: UNKNOWN) (DOI: 10.17487/RFC0143) 0144 Data sharing on computer networks. A. Shoshani. April 1971. (Format: TXT=13744 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0144) 0145 Initial Connection Protocol Control Commands. J. Postel. May 1971. (Format: TXT=2490, PS=552114, PDF=15869 bytes) (Obsoletes RFC0127) (Obsoleted by RFC0165) (Updated by RFC0143) (Status: UNKNOWN) (DOI: 10.17487/RFC0145) 0146 Views on issues relevant to data sharing on computer networks. P.M. Karp, D.B. McKay, D.C.M. Wood. May 1971. (Format: TXT=9828 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0146) 0147 Definition of a socket. J.M. Winett. May 1971. (Format: TXT=6438 bytes) (Updates RFC0129) (Status: UNKNOWN) (DOI: 10.17487/RFC0147) 0148 Comments on RFC 123. A.K. Bhushan. May 1971. (Format: TXT=1149 bytes) (Updates RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0148) 0149 Best Laid Plans. S.D. Crocker. May 1971. (Format: TXT=1057 bytes) (Updates RFC0140) (Status: UNKNOWN) (DOI: 10.17487/RFC0149) 0150 Use of IPC Facilities: A Working Paper. R.B. Kalin. May 1971. (Format: TXT=28163 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0150) 0151 Comments on a proffered official ICP: RFCs 123, 127. A. Shoshani. May 1971. (Format: TXT=3623 bytes) (Updates RFC0127) (Status: UNKNOWN) (DOI: 10.17487/RFC0151) 0152 SRI Artificial Intelligence status report. M. Wilber. May 1971. (Format: TXT=2726 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0152) 0153 SRI ARC-NIC status. J.T. Melvin, R.W. Watson. May 1971. (Format: TXT=8573 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0153) 0154 Exposition Style. S.D. Crocker. May 1971. (Format: TXT=1293 bytes) (Obsoletes RFC0132) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0154) 0155 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT=11054 bytes) (Obsoletes RFC0095) (Obsoleted by RFC0168) (Status: UNKNOWN) (DOI: 10.17487/RFC0155) 0156 Status of the Illinois site: Response to RFC 116. J. Bouknight. April 1971. (Format: TXT=1171 bytes) (Updates RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0156) 0157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems. V.G. Cerf. May 1971. (Format: TXT=3159 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0157) 0158 Telnet Protocol: A Proposed Document. T.C. O'Sullivan. May 1971. (Format: TXT=21025, PDF=429985 bytes) (Obsoleted by RFC0495) (Updates RFC0139) (Updated by RFC0318) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0158) 0159 Not Issued. 0160 RFC brief list. Network Information Center. Stanford Research Institute. May 1971. (Format: TXT=12173 bytes) (Obsoleted by RFC0200, RFC0999) (Updates NIC6716) (Status: UNKNOWN) (DOI: 10.17487/RFC0160) 0161 Solution to the race condition in the ICP. A. Shoshani. May 1971. (Format: TXT=2026 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0161) 0162 NETBUGGER3. M. Kampe. May 1971. (Format: TXT=3153 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0162) 0163 Data transfer protocols. V.G. Cerf. May 1971. (Format: TXT=5465 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0163) 0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71. J.F. Heafner. May 1971. (Format: TXT=58597 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0164) 0165 Proffered Official Initial Connection Protocol. J. Postel. May 1971. (Format: TXT=8488, PDF=248876 bytes) (Obsoletes RFC0145, RFC0143, RFC0123) (Updated by NIC7101) (Status: UNKNOWN) (DOI: 10.17487/RFC0165) 0166 Data Reconfiguration Service: An implementation specification. R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. May 1971. (Format: TXT=42094 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0166) 0167 Socket conventions reconsidered. A.K. Bhushan, R.M. Metcalfe, J.M. Winett. May 1971. (Format: TXT=7643 bytes) (Also RFC0129, RFC0147) (Status: UNKNOWN) (DOI: 10.17487/RFC0167) 0168 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT=13294 bytes) (Obsoletes RFC0155) (Obsoleted by RFC0211) (Status: UNKNOWN) (DOI: 10.17487/RFC0168) 0169 COMPUTER NETWORKS. S.D. Crocker. May 1971. (Format: TXT=7061, PDF=178823 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0169) 0170 RFC List by Number. Network Information Center. Stanford Research Institute. June 1971. (Format: TXT=17670 bytes) (Obsoleted by RFC0200) (Status: UNKNOWN) (DOI: 10.17487/RFC0170) 0171 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White. June 1971. (Format: TXT=20616 bytes) (Obsoleted by RFC0264) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) (DOI: 10.17487/RFC0171) 0172 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. June 1971. (Format: TXT=21328 bytes) (Obsoleted by RFC0265) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) (DOI: 10.17487/RFC0172) 0173 Network Data Management Committee Meeting Announcement. P.M. Karp, D.B. McKay. June 1971. (Format: TXT=4239 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0173) 0174 UCLA - Computer Science Graphics Overview. J. Postel, V.G. Cerf. June 1971. (Format: TXT=5037 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0174) 0175 Comments on "Socket Conventions Reconsidered". E. Harslem, J.F. Heafner. June 1971. (Format: TXT=2225 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0175) 0176 Comments on "Byte size for connections". A.K. Bhushan, R. Kanodia, R.M. Metcalfe, J. Postel. June 1971. (Format: TXT=7269 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0176) 0177 Device independent graphical display description. J. McConnell. June 1971. (Format: TXT=20474 bytes) (Updates RFC0125) (Updated by RFC0181) (Status: UNKNOWN) (DOI: 10.17487/RFC0177) 0178 Network graphic attention handling. I.W. Cotton. June 1971. (Format: TXT=24522 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0178) 0179 Link Number Assignments. A.M. McKenzie. June 1971. (Format: TXT=1221 bytes) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0179) 0180 File system questionnaire. A.M. McKenzie. June 1971. (Format: TXT=8154 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0180) 0181 Modifications to RFC 177. J. McConnell. July 1971. (Format: TXT=4892 bytes) (Updates RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0181) 0182 Compilation of list of relevant site reports. J.B. North. June 1971. (Format: TXT=2565 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0182) 0183 EBCDIC Codes and Their Mapping to ASCII. J.M. Winett. July 1971. (Format: TXT=22256, PDF=577092 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0183) 0184 Proposed graphic display modes. K.C. Kelley. July 1971. (Format: TXT=18678 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0184) 0185 NIC distribution of manuals and handbooks. J.B. North. July 1971. (Format: TXT=1406 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0185) 0186 Network graphics loader. J.C. Michener. July 1971. (Format: TXT=30557 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0186) 0187 Network/440 Protocol Concept. D.B. McKay, D.P. Karp. July 1971. (Format: TXT=25042 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0187) 0188 Data management meeting announcement. P.M. Karp, D.B. McKay. January 1971. (Format: TXT=3383 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0188) 0189 Interim NETRJS specifications. R.T. Braden. July 1971. (Format: TXT=41383 bytes) (Obsoletes RFC0088) (Obsoleted by RFC0599) (Updated by RFC0283) (Status: UNKNOWN) (DOI: 10.17487/RFC0189) 0190 DEC PDP-10-IMLAC communications system. L.P. Deutsch. July 1971. (Format: TXT=18752 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0190) 0191 Graphics implementation and conceptualization at Augmentation Research Center. C.H. Irby. July 1971. (Format: TXT=8179 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0191) 0192 Some factors which a Network Graphics Protocol must consider. R.W. Watson. July 1971. (Format: TXT=48540 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0192) 0193 NETWORK CHECKOUT. E. Harslem, J.F. Heafner. July 1971. (Format: TXT=3622 bytes) (Obsoleted by RFC0198) (Updated by RFC0198) (Status: UNKNOWN) (DOI: 10.17487/RFC0193) 0194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes. V. Cerf, E. Harslem, J. Heafner, B. Metcalfe, J. White. July 1971. (Format: TXT=32716 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0194) 0195 Data computers-data descriptions and access language. G.H. Mealy. July 1971. (Format: TXT=8704 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0195) 0196 Mail Box Protocol. R.W. Watson. July 1971. (Format: TXT=7016 bytes) (Obsoleted by RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0196) 0197 Initial Connection Protocol - Reviewed. A. Shoshani, E. Harslem. July 1971. (Format: TXT=7094 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0197) 0198 Site Certification - Lincoln Labs 360/67. J.F. Heafner. July 1971. (Format: TXT=855 bytes) (Obsoletes RFC0193) (Obsoleted by RFC0214) (Updates RFC0193) (Status: UNKNOWN) (DOI: 10.17487/RFC0198) 0199 Suggestions for a Network Data-Tablet Graphics Protocol. T. Williams. July 1971. (Format: TXT=18660, PDF=542961 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0199) 0200 RFC list by number. J.B. North. August 1971. (Format: TXT=19256 bytes) (Obsoletes RFC0170, RFC0160) (Obsoleted by NIC7724) (Status: UNKNOWN) (DOI: 10.17487/RFC0200) 0201 Not Issued. 0202 Possible Deadlock in ICP. S.M. Wolfe, J. Postel. July 1971. (Format: TXT=2796 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0202) 0203 Achieving reliable communication. R.B. Kalin. August 1971. (Format: TXT=9253 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0203) 0204 Sockets in use. J. Postel. August 1971. (Format: TXT=1379 bytes) (Updated by RFC0234) (Status: UNKNOWN) (DOI: 10.17487/RFC0204) 0205 NETCRT - a character display protocol. R.T. Braden. August 1971. (Format: TXT=28272 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0205) 0206 A User TELNET Description of an Initial Implementation. J. White. August 1971. (Format: TXT=33152, PDF=617017 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0206) 0207 September Network Working Group meeting. A. Vezza. August 1971. (Format: TXT=3356 bytes) (Obsoleted by RFC0212) (Status: UNKNOWN) (DOI: 10.17487/RFC0207) 0208 Address tables. A.M. McKenzie. August 1971. (Format: TXT=5858 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0208) 0209 Host/IMP interface documentation. B. Cosell. August 1971. (Format: TXT=2566 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0209) 0210 Improvement of Flow Control. W. Conrad. August 1971. (Format: TXT=3329 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0210) 0211 ARPA Network Mailing Lists. J.B. North. August 1971. (Format: TXT=13205, PDF=210300 bytes) (Obsoletes RFC0168) (Obsoleted by RFC0300) (Status: UNKNOWN) (DOI: 10.17487/RFC0211) 0212 NWG meeting on network usage. Information Sciences Institute University of Southern California. August 1971. (Format: TXT=4356 bytes) (Obsoletes RFC0207) (Updated by RFC0222) (Status: UNKNOWN) (DOI: 10.17487/RFC0212) 0213 IMP System change notification. B. Cosell. August 1971. (Format: TXT=1589 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0213) 0214 Network checkpoint. E. Harslem. August 1971. (Format: TXT=3047 bytes) (Obsoletes RFC0198) (Status: UNKNOWN) (DOI: 10.17487/RFC0214) 0215 NCP, ICP, and Telnet: The Terminal IMP implementation. A.M. McKenzie. August 1971. (Format: TXT=16645 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0215) 0216 Telnet Access to UCSB's On-Line System. J.E. White. September 1971. (Format: TXT=37570, PDF=908675 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0216) 0217 Specifications changes for OLS, RJE/RJOR, and SMFS. J.E. White. September 1971. (Format: TXT=2956 bytes) (Updates RFC0074, RFC0105, RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0217) 0218 Changing the IMP status reporting facility. B. Cosell. September 1971. (Format: TXT=1131 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0218) 0219 User's View of the Datacomputer. R. Winter. September 1971. (Format: TXT=16631 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0219) 0220 Not Issued. 0221 Mail Box Protocol: Version 2. R.W. Watson. August 1971. (Format: TXT=9805 bytes) (Obsoletes RFC0196) (Obsoleted by RFC0278) (Status: UNKNOWN) (DOI: 10.17487/RFC0221) 0222 Subject: System programmer's workshop. R.M. Metcalfe. September 1971. (Format: TXT=4023 bytes) (Updates RFC0212) (Updated by RFC0234) (Status: UNKNOWN) (DOI: 10.17487/RFC0222) 0223 Network Information Center schedule for network users. J.T. Melvin, R.W. Watson. September 1971. (Format: TXT=5369 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0223) 0224 Comments on Mailbox Protocol. A.M. McKenzie. September 1971. (Format: TXT=3583 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0224) 0225 Rand/UCSB network graphics experiment. E. Harslem, R. Stoughton. September 1971. (Format: TXT=13573 bytes) (Updates RFC0074) (Status: UNKNOWN) (DOI: 10.17487/RFC0225) 0226 Standardization of host mnemonics. P.M. Karp. September 1971. (Format: TXT=2012 bytes) (Obsoleted by RFC0247) (Status: UNKNOWN) (DOI: 10.17487/RFC0226) 0227 Data transfer rates (Rand/UCLA). J.F. Heafner, E. Harslem. September 1971. (Format: TXT=2451 bytes) (Updates RFC0113) (Status: UNKNOWN) (DOI: 10.17487/RFC0227) 0228 Clarification. D.C. Walden. September 1971. (Format: TXT=715 bytes) (Updates RFC0070) (Status: UNKNOWN) (DOI: 10.17487/RFC0228) 0229 Standard host names. J. Postel. September 1971. (Format: TXT=3388 bytes) (Obsoleted by RFC0236) (Status: UNKNOWN) (DOI: 10.17487/RFC0229) 0230 Toward reliable operation of minicomputer-based terminals on a TIP. T. Pyke. September 1971. (Format: TXT=7040 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0230) 0231 Service center standards for remote usage: A user's view. J.F. Heafner, E. Harslem. September 1971. (Format: TXT=9692 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0231) 0232 Postponement of network graphics meeting. A. Vezza. September 1971. (Format: TXT=899 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0232) 0233 Standardization of host call letters. A. Bhushan, R. Metcalfe. September 1971. (Format: TXT=3206 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0233) 0234 Network Working Group meeting schedule. A. Vezza. October 1971. (Format: TXT=1634 bytes) (Updates RFC0222, RFC0204) (Status: UNKNOWN) (DOI: 10.17487/RFC0234) 0235 Site status. E. Westheimer. September 1971. (Format: TXT=7994 bytes) (Obsoleted by RFC0240) (Status: UNKNOWN) (DOI: 10.17487/RFC0235) 0236 Standard host names. J. Postel. September 1971. (Format: TXT=5112 bytes) (Obsoletes RFC0229) (Status: UNKNOWN) (DOI: 10.17487/RFC0236) 0237 NIC view of standard host names. R.W. Watson. October 1971. (Format: TXT=2212 bytes) (Obsoleted by RFC0273) (Status: UNKNOWN) (DOI: 10.17487/RFC0237) 0238 Comments on DTP and FTP proposals. R.T. Braden. September 1971. (Format: TXT=2735 bytes) (Updates RFC0171, RFC0172) (Status: UNKNOWN) (DOI: 10.17487/RFC0238) 0239 Host mnemonics proposed in RFC 226 (NIC 7625). R.T. Braden. September 1971. (Format: TXT=2236 bytes) (Also RFC0226, RFC0229, RFC0236) (Status: UNKNOWN) (DOI: 10.17487/RFC0239) 0240 Site Status. A.M. McKenzie. September 1971. (Format: TXT=7948 bytes) (Obsoletes RFC0235) (Obsoleted by RFC0252) (Status: UNKNOWN) (DOI: 10.17487/RFC0240) 0241 Connecting computers to MLC ports. A.M. McKenzie. September 1971. (Format: TXT=3739 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0241) 0242 Data Descriptive Language for Shared Data. L. Haibt, A.P. Mullery. July 1971. (Format: TXT=18151 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0242) 0243 Network and data sharing bibliography. A.P. Mullery. October 1971. (Format: TXT=12432 bytes) (Obsoleted by RFC0290) (Status: UNKNOWN) (DOI: 10.17487/RFC0243) 0244 Not Issued. 0245 Reservations for Network Group meeting. C. Falls. October 1971. (Format: TXT=1142 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0245) 0246 Network Graphics meeting. A. Vezza. October 1971. (Format: TXT=856 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0246) 0247 Proffered set of standard host names. P.M. Karp. October 1971. (Format: TXT=7122 bytes) (Obsoletes RFC0226) (Status: UNKNOWN) (DOI: 10.17487/RFC0247) 0248 Not Issued. 0249 Coordination of equipment and supplies purchase. R.F. Borelli. October 1971. (Format: TXT=4561 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0249) 0250 Some thoughts on file transfer. H. Brodie. October 1971. (Format: TXT=2446 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0250) 0251 Weather data. D. Stern. October 1971. (Format: TXT=1907 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0251) 0252 Network host status. E. Westheimer. October 1971. (Format: TXT=5531 bytes) (Obsoletes RFC0240) (Obsoleted by RFC0255) (Status: UNKNOWN) (DOI: 10.17487/RFC0252) 0253 Second Network Graphics meeting details. J.A. Moorer. October 1971. (Format: TXT=1981 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0253) 0254 Scenarios for using ARPANET computers. A. Bhushan. October 1971. (Format: TXT=40998, PDF=4903124 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0254) 0255 Status of network hosts. E. Westheimer. October 1971. (Format: TXT=4002 bytes) (Obsoletes RFC0252) (Obsoleted by RFC0266) (Status: UNKNOWN) (DOI: 10.17487/RFC0255) 0256 IMPSYS change notification. B. Cosell. November 1971. (Format: TXT=1240 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0256) 0257 Not Issued. 0258 Not Issued. 0259 Not Issued. 0260 Not Issued. 0261 Not Issued. 0262 Not Issued. 0263 "Very Distant" Host interface. A.M. McKenzie. December 1971. (Format: TXT=3914 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0263) 0264 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White. January 1972. (Format: TXT=20907 bytes) (Obsoletes RFC0171) (Obsoleted by RFC0354) (Updated by RFC0310) (Also RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0264) 0265 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. November 1971. (Format: TXT=3914 bytes) (Obsoletes RFC0172) (Obsoleted by RFC0354) (Updated by RFC0281, RFC0294, RFC0310) (Also RFC0264) (Status: UNKNOWN) (DOI: 10.17487/RFC0265) 0266 Network host status. E. Westheimer. November 1971. (Format: TXT=3174 bytes) (Obsoletes RFC0255) (Obsoleted by RFC0267) (Status: UNKNOWN) (DOI: 10.17487/RFC0266) 0267 Network Host Status. E. Westheimer. November 1971. (Format: TXT=7862 bytes) (Obsoletes RFC0266) (Obsoleted by RFC0287) (Status: UNKNOWN) (DOI: 10.17487/RFC0267) 0268 Graphics facilities information. J. Postel. November 1971. (Format: TXT=1298 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0268) 0269 Some Experience with File Transfer. H. Brodie. December 1971. (Format: TXT=5961 bytes) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0269) 0270 Correction to BBN Report No. 1822 (NIC NO 7958). A.M. McKenzie. January 1972. (Format: TXT=1371 bytes) (Updates NIC7959) (Status: UNKNOWN) (DOI: 10.17487/RFC0270) 0271 IMP System change notifications. B. Cosell. January 1972. (Format: TXT=4022 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0271) 0272 Not Issued. 0273 More on standard host names. R.W. Watson. October 1971. (Format: TXT=4589 bytes) (Obsoletes RFC0237) (Status: UNKNOWN) (DOI: 10.17487/RFC0273) 0274 Establishing a local guide for network usage. E. Forman. November 1971. (Format: TXT=7114 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0274) 0275 Not Issued. 0276 NIC course. R.W. Watson. November 1971. (Format: TXT=1183 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0276) 0277 Not Issued. 0278 Revision of the Mail Box Protocol. A.K. Bhushan, R.T. Braden, E. Harslem, J.F. Heafner, A.M. McKenzie, J.T. Melvin, R.L. Sundberg, R.W. Watson, J.E. White. November 1971. (Format: TXT=7526 bytes) (Obsoletes RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0278) 0279 Not Issued. 0280 A Draft of Host Names. R.W. Watson. November 1971. (Format: TXT=3629 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0280) 0281 Suggested addition to File Transfer Protocol. A.M. McKenzie. December 1971. (Format: TXT=12006 bytes) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0281) 0282 Graphics meeting report. M.A. Padlipsky. December 1971. (Format: TXT=18100 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0282) 0283 NETRJT: Remote Job Service Protocol for TIPS. R.T. Braden. December 1971. (Format: TXT=18771 bytes) (Updates RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0283) 0284 Not Issued. 0285 Network graphics. D. Huff. December 1971. (Format: TXT=18076 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0285) 0286 Network Library Information System. E. Forman. December 1971. (Format: TXT=2079 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0286) 0287 Status of Network Hosts. E. Westheimer. December 1971. (Format: TXT=9217 bytes) (Obsoletes RFC0267) (Obsoleted by RFC0288) (Status: UNKNOWN) (DOI: 10.17487/RFC0287) 0288 Network host status. E. Westheimer. January 1972. (Format: TXT=8501 bytes) (Obsoletes RFC0287) (Obsoleted by RFC0293) (Updated by RFC0293) (Status: UNKNOWN) (DOI: 10.17487/RFC0288) 0289 What we hope is an official list of host names. R.W. Watson. December 1971. (Format: TXT=5069 bytes) (Obsoleted by RFC0384) (Status: UNKNOWN) (DOI: 10.17487/RFC0289) 0290 Computer networks and data sharing: A bibliography. A.P. Mullery. January 1972. (Format: TXT=34329 bytes) (Obsoletes RFC0243) (Status: UNKNOWN) (DOI: 10.17487/RFC0290) 0291 Data Management Meeting Announcement. D.B. McKay. January 1972. (Format: TXT=3375 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0291) 0292 Graphics Protocol: Level 0 only. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. January 1972. (Format: TXT=22342 bytes) (Obsoleted by RFC0493) (Status: UNKNOWN) (DOI: 10.17487/RFC0292) 0293 Network Host Status. E. Westheimer. January 1972. (Format: TXT=7639 bytes) (Obsoletes RFC0288) (Obsoleted by RFC0298) (Updates RFC0288) (Status: UNKNOWN) (DOI: 10.17487/RFC0293) 0294 The Use of "Set Data Type" Transaction in File Transfer Protocol. A.K. Bhushan. January 1972. (Format: TXT=3924 bytes) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0294) 0295 Report of the Protocol Workshop, 12 October 1971. J. Postel. January 1972. (Format: TXT=5432 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0295) 0296 DS-1 Display System. D.E. Liddle. January 1972. (Format: TXT=37921, PDF=1560765 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0296) 0297 TIP Message Buffers. D.C. Walden. January 1972. (Format: TXT=3517 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0297) 0298 Network host status. E. Westheimer. February 1972. (Format: TXT=8770 bytes) (Obsoletes RFC0293) (Obsoleted by RFC0306) (Status: UNKNOWN) (DOI: 10.17487/RFC0298) 0299 Information Management System. D. Hopkin. February 1972. (Format: TXT=1825 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0299) 0300 ARPA Network mailing lists. J.B. North. January 1972. (Format: TXT=16357 bytes) (Obsoletes RFC0211) (Obsoleted by RFC0303) (Status: UNKNOWN) (DOI: 10.17487/RFC0300) 0301 BBN IMP (#5) and NCC Schedule March 4, 1971. R. Alter. February 1972. (Format: TXT=1487 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0301) 0302 Exercising The ARPANET. R.F. Bryan. February 1972. (Format: TXT=5452 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0302) 0303 ARPA Network mailing lists. Network Information Center. Stanford Research Institute. March 1972. (Format: TXT=18193 bytes) (Obsoletes RFC0300) (Obsoleted by RFC0329) (Status: UNKNOWN) (DOI: 10.17487/RFC0303) 0304 Data Management System Proposal for the ARPA Network. D.B. McKay. February 1972. (Format: TXT=20446, PDF=465564 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0304) 0305 Unknown Host Numbers. R. Alter. February 1972. (Format: TXT=1998 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0305) 0306 Network host status. E. Westheimer. February 1972. (Format: TXT=7485 bytes) (Obsoletes RFC0298) (Obsoleted by RFC0315) (Status: UNKNOWN) (DOI: 10.17487/RFC0306) 0307 Using network Remote Job Entry. E. Harslem. February 1972. (Format: TXT=12032 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0307) 0308 ARPANET host availability data. M. Seriff. March 1972. (Format: TXT=5948 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0308) 0309 Data and File Transfer Workshop Announcement. A.K. Bhushan. March 1972. (Format: TXT=9404 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0309) 0310 Another Look at Data and File Transfer Protocols. A.K. Bhushan. April 1972. (Format: TXT=18593 bytes) (Updates RFC0264, RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0310) 0311 New Console Attachments to the USCB Host. R.F. Bryan. February 1972. (Format: TXT=3141 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0311) 0312 Proposed Change in IMP-to-Host Protocol. A.M. McKenzie. March 1972. (Format: TXT=3562 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0312) 0313 Computer based instruction. T.C. O'Sullivan. March 1972. (Format: TXT=19880 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0313) 0314 Network Graphics Working Group Meeting. I.W. Cotton. March 1972. (Format: TXT=1836 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0314) 0315 Network Host Status. E. Westheimer. March 1972. (Format: TXT=7818 bytes) (Obsoletes RFC0306) (Obsoleted by RFC0319) (Status: UNKNOWN) (DOI: 10.17487/RFC0315) 0316 ARPA Network Data Management Working Group. D.B. McKay, A.P. Mullery. February 1972. (Format: TXT=15494 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0316) 0317 Official Host-Host Protocol Modification: Assigned Link Numbers. J. Postel. March 1972. (Format: TXT=1593 bytes) (Obsoleted by RFC0604) (Status: UNKNOWN) (DOI: 10.17487/RFC0317) 0318 Telnet Protocols. J. Postel. April 1972. (Format: TXT=34928 bytes) (Updates RFC0158) (Updated by RFC0435) (Also RFC0139, RFC0158) (Status: UNKNOWN) (DOI: 10.17487/RFC0318) 0319 Network Host Status. E. Westheimer. March 1972. (Format: TXT=8955 bytes) (Obsoletes RFC0315) (Updated by RFC0326) (Status: UNKNOWN) (DOI: 10.17487/RFC0319) 0320 Workshop on Hard Copy Line Graphics. R. Reddy. March 1972. (Format: TXT=5600, PDF=14422 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0320) 0321 CBI Networking Activity at MITRE. P.M. Karp. March 1972. (Format: TXT=20500 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0321) 0322 Well known socket numbers. V. Cerf, J. Postel. March 1972. (Format: TXT=1735 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0322) 0323 Formation of Network Measurement Group (NMG). V. Cerf. March 1972. (Format: TXT=15777 bytes) (Updated by RFC0388) (Status: UNKNOWN) (DOI: 10.17487/RFC0323) 0324 RJE Protocol meeting. J. Postel. April 1972. (Format: TXT=1176 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0324) 0325 Network Remote Job Entry program - NETRJS. G. Hicks. April 1972. (Format: TXT=17499 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0325) 0326 Network Host Status. E. Westheimer. April 1972. (Format: TXT=7944 bytes) (Obsoleted by RFC0330) (Updates RFC0319) (Status: UNKNOWN) (DOI: 10.17487/RFC0326) 0327 Data and File Transfer workshop notes. A.K. Bhushan. April 1972. (Format: TXT=11792 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0327) 0328 Suggested Telnet Protocol Changes. J. Postel. April 1972. (Format: TXT=2685 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0328) 0329 ARPA Network Mailing Lists. Network Information Center. Stanford Research Institute. May 1972. (Format: TXT=23861 bytes) (Obsoletes RFC0303) (Obsoleted by RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0329) 0330 Network Host Status. E. Westheimer. April 1972. (Format: TXT=8085 bytes) (Obsoletes RFC0326) (Updated by RFC0332) (Status: UNKNOWN) (DOI: 10.17487/RFC0330) 0331 IMP System Change Notification. J.M. McQuillan. April 1972. (Format: TXT=2339 bytes) (Obsoleted by RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0331) 0332 Network Host Status. E. Westheimer. April 1972. (Format: TXT=8427 bytes) (Obsoleted by RFC0342) (Updates RFC0330) (Status: UNKNOWN) (DOI: 10.17487/RFC0332) 0333 Proposed experiment with a Message Switching Protocol. R.D. Bressler, D. Murphy, D.C. Walden. May 1972. (Format: TXT=62507 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0333) 0334 Network Use on May 8. A.M. McKenzie. May 1972. (Format: TXT=1376 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0334) 0335 New Interface - IMP/360. R.F. Bryan. May 1972. (Format: TXT=934 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0335) 0336 Level 0 Graphic Input Protocol. I.W. Cotton. May 1972. (Format: TXT=3787 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0336) 0337 Not Issued. 0338 EBCDIC/ASCII Mapping for Network RJE. R.T. Braden. May 1972. (Format: TXT=11494, PS=2386987, PDF=1871020 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0338) 0339 MLTNET: A "Multi Telnet" Subsystem for Tenex. R. Thomas. May 1972. (Format: TXT=7941 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0339) 0340 Proposed Telnet Changes. T.C. O'Sullivan. May 1972. (Format: TXT=2656 bytes) (Also RFC0328) (Status: UNKNOWN) (DOI: 10.17487/RFC0340) 0341 Not Issued. 0342 Network Host Status. E. Westheimer. May 1972. (Format: TXT=8382 bytes) (Obsoletes RFC0332) (Obsoleted by RFC0344) (Status: UNKNOWN) (DOI: 10.17487/RFC0342) 0343 IMP System change notification. A.M. McKenzie. May 1972. (Format: TXT=3370 bytes) (Obsoletes RFC0331) (Obsoleted by RFC0359) (Status: UNKNOWN) (DOI: 10.17487/RFC0343) 0344 Network Host Status. E. Westheimer. May 1972. (Format: TXT=8221 bytes) (Obsoletes RFC0342) (Obsoleted by RFC0353) (Status: UNKNOWN) (DOI: 10.17487/RFC0344) 0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN). K.C. Kelley. May 1972. (Format: TXT=1999 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0345) 0346 Satellite Considerations. J. Postel. May 1972. (Format: TXT=2778 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0346) 0347 Echo process. J. Postel. May 1972. (Format: TXT=1377 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0347) 0348 Discard Process. J. Postel. May 1972. (Format: TXT=1181 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0348) 0349 Proposed Standard Socket Numbers. J. Postel. May 1972. (Format: TXT=1663 bytes) (Obsoleted by RFC0433) (Also RFC0204, RFC0322) (Status: UNKNOWN) (DOI: 10.17487/RFC0349) 0350 User Accounts for UCSB On-Line System. R. Stoughton. May 1972. (Format: TXT=5117 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0350) 0351 Graphics information form for the ARPANET graphics resources notebook. D. Crocker. June 1972. (Format: TXT=2150 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0351) 0352 TIP Site Information Form. D. Crocker. June 1972. (Format: TXT=2266 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0352) 0353 Network host status. E. Westheimer. June 1972. (Format: TXT=8747 bytes) (Obsoletes RFC0344) (Obsoleted by RFC0362) (Status: UNKNOWN) (DOI: 10.17487/RFC0353) 0354 File Transfer Protocol. A.K. Bhushan. July 1972. (Format: TXT=58074 bytes) (Obsoletes RFC0264, RFC0265) (Obsoleted by RFC0542) (Updated by RFC0385, RFC0454, RFC0683) (Status: UNKNOWN) (DOI: 10.17487/RFC0354) 0355 Response to NWG/RFC 346. J. Davidson. June 1972. (Format: TXT=3717 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0355) 0356 ARPA Network Control Center. R. Alter. June 1972. (Format: TXT=1963 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0356) 0357 Echoing strategy for satellite links. J. Davidson. June 1972. (Format: TXT=30103 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0357) 0358 Not Issued. 0359 Status of the Release of the New IMP System (2600). D.C. Walden. June 1972. (Format: TXT=2015 bytes) (Obsoletes RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0359) 0360 Proposed Remote Job Entry Protocol. C. Holland. June 1972. (Format: TXT=39473, PDF=1187574 bytes) (Obsoleted by RFC0407) (Status: UNKNOWN) (DOI: 10.17487/RFC0360) 0361 Deamon Processes on Host 106. R.D. Bressler. July 1972. (Format: TXT=1480 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0361) 0362 Network Host Status. E. Westheimer. June 1972. (Format: TXT=8631 bytes) (Obsoletes RFC0353) (Obsoleted by RFC0366) (Status: UNKNOWN) (DOI: 10.17487/RFC0362) 0363 ARPA Network mailing lists. Network Information Center. Stanford Research Institute. August 1972. (Format: TXT=25356 bytes) (Obsoletes RFC0329) (Obsoleted by RFC0402) (Status: UNKNOWN) (DOI: 10.17487/RFC0363) 0364 Serving remote users on the ARPANET. M.D. Abrams. July 1972. (Format: TXT=11253 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0364) 0365 Letter to All TIP Users. D.C. Walden. July 1972. (Format: TXT=10331 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0365) 0366 Network Host Status. E. Westheimer. July 1972. (Format: TXT=8278 bytes) (Obsoletes RFC0362) (Obsoleted by RFC0367) (Status: UNKNOWN) (DOI: 10.17487/RFC0366) 0367 Network host status. E. Westheimer. July 1972. (Format: TXT=8057 bytes) (Obsoletes RFC0366) (Obsoleted by RFC0370) (Status: UNKNOWN) (DOI: 10.17487/RFC0367) 0368 Comments on "Proposed Remote Job Entry Protocol". R.T. Braden. July 1972. (Format: TXT=3883 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0368) 0369 Evaluation of ARPANET services January-March, 1972. J.R. Pickens. July 1972. (Format: TXT=24414 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0369) 0370 Network Host Status. E. Westheimer. July 1972. (Format: TXT=8389 bytes) (Obsoletes RFC0367) (Updated by RFC0376) (Status: UNKNOWN) (DOI: 10.17487/RFC0370) 0371 Demonstration at International Computer Communications Conference. R.E. Kahn. July 1972. (Format: TXT=3728 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0371) 0372 Notes on a Conversation with Bob Kahn on the ICCC. R.W. Watson. July 1972. (Format: TXT=6040 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0372) 0373 Arbitrary Character Sets. J. McCarthy. July 1972. (Format: TXT=7783 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0373) 0374 IMP System Announcement. A.M. McKenzie. July 1972. (Format: TXT=3963 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0374) 0375 Not Issued. 0376 Network Host Status. E. Westheimer. August 1972. (Format: TXT=8861 bytes) (Updates RFC0370) (Status: UNKNOWN) (DOI: 10.17487/RFC0376) 0377 Using TSO via ARPA Network Virtual Terminal. R.T. Braden. August 1972. (Format: TXT=7093 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0377) 0378 Traffic statistics (July 1972). A.M. McKenzie. August 1972. (Format: TXT=5730 bytes) (Obsoleted by RFC0391) (Status: UNKNOWN) (DOI: 10.17487/RFC0378) 0379 Using TSO at CCN. R. Braden. August 1972. (Format: TXT=8674 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0379) 0380 Not Issued. 0381 Three aids to improved network operation. J.M. McQuillan. July 1972. (Format: TXT=9305 bytes) (Updated by RFC0394) (Status: UNKNOWN) (DOI: 10.17487/RFC0381) 0382 Mathematical Software on the ARPA Network. L. McDaniel. August 1972. (Format: TXT=2041 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0382) 0383 Not Issued. 0384 Official site idents for organizations in the ARPA Network. J.B. North. August 1972. (Format: TXT=10401 bytes) (Obsoletes RFC0289) (Status: UNKNOWN) (DOI: 10.17487/RFC0384) 0385 Comments on the File Transfer Protocol. A.K. Bhushan. August 1972. (Format: TXT=13030 bytes) (Updates RFC0354) (Updated by RFC0414) (Status: UNKNOWN) (DOI: 10.17487/RFC0385) 0386 Letter to TIP users-2. B. Cosell, D.C. Walden. August 1972. (Format: TXT=12475 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0386) 0387 Some experiences in implementing Network Graphics Protocol Level 0. K.C. Kelley, J. Meir. August 1972. (Format: TXT=9059 bytes) (Updated by RFC0401) (Status: UNKNOWN) (DOI: 10.17487/RFC0387) 0388 NCP statistics. V. Cerf. August 1972. (Format: TXT=8458 bytes) (Updates RFC0323) (Status: UNKNOWN) (DOI: 10.17487/RFC0388) 0389 UCLA Campus Computing Network Liaison Staff for ARPA Network. B. Noble. August 1972. (Format: TXT=2819 bytes) (Obsoleted by RFC0423) (Status: UNKNOWN) (DOI: 10.17487/RFC0389) 0390 TSO Scenario. R.T. Braden. September 1972. (Format: TXT=6103 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0390) 0391 Traffic statistics (August 1972). A.M. McKenzie. September 1972. (Format: TXT=4695 bytes) (Obsoletes RFC0378) (Status: UNKNOWN) (DOI: 10.17487/RFC0391) 0392 Measurement of host costs for transmitting network data. G. Hicks, B.D. Wessler. September 1972. (Format: TXT=14462 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0392) 0393 Comments on Telnet Protocol Changes. J.M. Winett. October 1972. (Format: TXT=9435 bytes) (Also RFC0109, RFC0139, RFC0158, RFC0318, RFC0328) (Status: UNKNOWN) (DOI: 10.17487/RFC0393) 0394 Two Proposed Changes to the IMP-Host Protocol. J.M. McQuillan. September 1972. (Format: TXT=5780 bytes) (Updates RFC0381) (Status: UNKNOWN) (DOI: 10.17487/RFC0394) 0395 Switch Settings on IMPs and TIPs. J.M. McQuillan. October 1972. (Format: TXT=1827 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0395) 0396 Network Graphics Working Group Meeting - Second Iteration. S. Bunch. November 1972. (Format: TXT=2224 bytes) (Updated by RFC0474) (Status: UNKNOWN) (DOI: 10.17487/RFC0396) 0397 Not Issued. 0398 UCSB Online Graphics. J.R. Pickens, E. Faeh. September 1972. (Format: TXT=3846 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0398) 0399 SMFS Login and Logout. M. Krilanovich. September 1972. (Format: TXT=3024 bytes) (Obsoleted by RFC0431) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0399) 0400 Traffic Statistics (September 1972). A.M. McKenzie. October 1972. (Format: TXT=5435 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0400) 0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates. J. Hansen. October 1972. (Format: TXT=3894 bytes) (Updates RFC0387) (Status: UNKNOWN) (DOI: 10.17487/RFC0401) 0402 ARPA Network Mailing Lists. J.B. North. October 1972. (Format: TXT=28162 bytes) (Obsoletes RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0402) 0403 Desirability of a Network 1108 Service. G. Hicks. January 1973. (Format: TXT=9750, PDF=219744 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0403) 0404 Host Address Changes Involving Rand and ISI. A.M. McKenzie. October 1972. (Format: TXT=944 bytes) (Updated by RFC0405) (Status: UNKNOWN) (DOI: 10.17487/RFC0404) 0405 Correction to RFC 404. A.M. McKenzie. October 1972. (Format: TXT=1103 bytes) (Updates RFC0404) (Status: UNKNOWN) (DOI: 10.17487/RFC0405) 0406 Scheduled IMP Software Releases. J.M. McQuillan. October 1972. (Format: TXT=2468 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0406) 0407 Remote Job Entry Protocol. R.D. Bressler, R. Guida, A.M. McKenzie. October 1972. (Format: TXT=47556 bytes) (Obsoletes RFC0360) (Status: HISTORIC) (DOI: 10.17487/RFC0407) 0408 NETBANK. A.D. Owen, J. Postel. October 1972. (Format: TXT=1645 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0408) 0409 Tenex interface to UCSB's Simple-Minded File System. J.E. White. December 1972. (Format: TXT=14231 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0409) 0410 Removal of the 30-Second Delay When Hosts Come Up. J.M. McQuillan. November 1972. (Format: TXT=3964 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0410) 0411 New MULTICS Network Software Features. M.A. Padlipsky. November 1972. (Format: TXT=3024 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0411) 0412 User FTP Documentation. G. Hicks. November 1972. (Format: TXT=17510 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0412) 0413 Traffic statistics (October 1972). A.M. McKenzie. November 1972. (Format: TXT=16145 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0413) 0414 File Transfer Protocol (FTP) status and further comments. A.K. Bhushan. December 1972. (Format: TXT=12845 bytes) (Updates RFC0385) (Status: UNKNOWN) (DOI: 10.17487/RFC0414) 0415 Tenex bandwidth. H. Murray. November 1972. (Format: TXT=3456 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0415) 0416 ARC System Will Be Unavailable for Use During Thanksgiving Week. J.C. Norton. November 1972. (Format: TXT=2205 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0416) 0417 Link usage violation. J. Postel, C. Kline. December 1972. (Format: TXT=901 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0417) 0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center. W. Hathaway. November 1972. (Format: PDF=1080191 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0418) 0419 To: Network liaisons and station agents. A. Vezza. December 1972. (Format: TXT=1252 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0419) 0420 CCA ICCC weather demo. H. Murray. January 1973. (Format: TXT=14752 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0420) 0421 Software Consulting Service for Network Users. A.M. McKenzie. November 1972. (Format: TXT=2483 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0421) 0422 Traffic statistics (November 1972). A.M. McKenzie. December 1972. (Format: TXT=5494 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0422) 0423 UCLA Campus Computing Network Liaison Staff for ARPANET. B. Noble. December 1972. (Format: TXT=2890 bytes) (Obsoletes RFC0389) (Status: UNKNOWN) (DOI: 10.17487/RFC0423) 0424 Not Issued. 0425 "But my NCP costs $500 a day". R.D. Bressler. December 1972. (Format: TXT=1763 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0425) 0426 Reconnection Protocol. R. Thomas. January 1973. (Format: TXT=26548 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0426) 0427 Not Issued. 0428 Not Issued. 0429 Character Generator Process. J. Postel. December 1972. (Format: TXT=1319 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0429) 0430 Comments on File Transfer Protocol. R.T. Braden. February 1973. (Format: TXT=18696 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0430) 0431 Update on SMFS Login and Logout. M. Krilanovich. December 1972. (Format: TXT=4196 bytes) (Obsoletes RFC0399) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0431) 0432 Network logical map. N. Neigus. December 1972. (Format: TXT=1291, PDF=148880, PS=1344571 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0432) 0433 Socket number list. J. Postel. December 1972. (Format: TXT=6834 bytes) (Obsoletes RFC0349) (Obsoleted by RFC0503) (Status: UNKNOWN) (DOI: 10.17487/RFC0433) 0434 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT=2242 bytes) (Obsoleted by RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0434) 0435 Telnet issues. B. Cosell, D.C. Walden. January 1973. (Format: TXT=23019 bytes) (Updates RFC0318) (Status: UNKNOWN) (DOI: 10.17487/RFC0435) 0436 Announcement of RJS at UCSB. M. Krilanovich. January 1973. (Format: TXT=2579 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0436) 0437 Data Reconfiguration Service at UCSB. E. Faeh. June 1973. (Format: TXT=21562 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0437) 0438 FTP server-server interaction. R. Thomas, R. Clements. January 1973. (Format: TXT=6514 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0438) 0439 PARRY encounters the DOCTOR. V. Cerf. January 1973. (Format: TXT=7066 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0439) 0440 Scheduled network software maintenance. D.C. Walden. January 1973. (Format: TXT=1870 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0440) 0441 Inter-Entity Communication - an experiment. R.D. Bressler, R. Thomas. January 1973. (Format: TXT=12876 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0441) 0442 Current flow-control scheme for IMPSYS. V. Cerf. January 1973. (Format: TXT=16315 bytes) (Updated by RFC0449) (Status: UNKNOWN) (DOI: 10.17487/RFC0442) 0443 Traffic statistics (December 1972). A.M. McKenzie. January 1973. (Format: TXT=5664 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0443) 0444 Not Issued. 0445 IMP/TIP preventive maintenance schedule. A.M. McKenzie. January 1973. (Format: TXT=2668 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0445) 0446 Proposal to consider a network program resource notebook. L.P. Deutsch. January 1973. (Format: TXT=3053 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0446) 0447 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT=2332 bytes) (Obsoletes RFC0434) (Obsoleted by RFC0476) (Status: UNKNOWN) (DOI: 10.17487/RFC0447) 0448 Print files in FTP. R.T. Braden. February 1973. (Format: TXT=6838 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0448) 0449 Current flow-control scheme for IMPSYS. D.C. Walden. January 1973. (Format: TXT=1662 bytes) (Updates RFC0442) (Status: UNKNOWN) (DOI: 10.17487/RFC0449) 0450 MULTICS sampling timeout change. M.A. Padlipsky. February 1973. (Format: TXT=924 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0450) 0451 Tentative proposal for a Unified User Level Protocol. M.A. Padlipsky. February 1973. (Format: TXT=8114 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0451) 0452 TELNET Command at Host LL. J. Winett. February 1973. (Format: TXT=28415, PDF=777983 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0452) 0453 Meeting announcement to discuss a network mail system. M.D. Kudlick. February 1973. (Format: TXT=4572 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0453) 0454 File Transfer Protocol - meeting announcement and a new proposed document. A.M. McKenzie. February 1973. (Format: TXT=78966 bytes) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0454) 0455 Traffic statistics (January 1973). A.M. McKenzie. February 1973. (Format: TXT=5746 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0455) 0456 Memorandum: Date change of mail meeting. M.D. Kudlick. February 1973. (Format: TXT=950 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0456) 0457 TIPUG. D.C. Walden. February 1973. (Format: TXT=845 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0457) 0458 Mail retrieval via FTP. R.D. Bressler, R. Thomas. February 1973. (Format: TXT=2705 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0458) 0459 Network questionnaires. W. Kantrowitz. February 1973. (Format: TXT=1950 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0459) 0460 NCP survey. C. Kline. February 1973. (Format: TXT=10324 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0460) 0461 Telnet Protocol meeting announcement. A.M. McKenzie. February 1973. (Format: TXT=1966 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0461) 0462 Responding to user needs. J. Iseli, D. Crocker. February 1973. (Format: TXT=2808 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0462) 0463 FTP comments and response to RFC 430. A.K. Bhushan. February 1973. (Format: TXT=5729 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0463) 0464 Resource notebook framework. M.D. Kudlick. February 1973. (Format: TXT=3684 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0464) 0465 Not Issued. 0466 Telnet logger/server for host LL-67. J.M. Winett. February 1973. (Format: TXT=17595 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0466) 0467 Proposed change to Host-Host Protocol: Resynchronization of connection status. J.D. Burchfiel, R.S. Tomlinson. February 1973. (Format: TXT=14325 bytes) (Updated by RFC0492) (Status: UNKNOWN) (DOI: 10.17487/RFC0467) 0468 FTP data compression. R.T. Braden. March 1973. (Format: TXT=14909 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0468) 0469 Network mail meeting summary. M.D. Kudlick. March 1973. (Format: TXT=17774 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0469) 0470 Change in socket for TIP news facility. R. Thomas. March 1973. (Format: TXT=1014 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0470) 0471 Workshop on multi-site executive programs. R. Thomas. March 1973. (Format: TXT=3339 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0471) 0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925). S. Bunch. March 1973. (Format: TXT=4780 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0472) 0473 MIX and MIXAL?. D.C. Walden. February 1973. (Format: TXT=868 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0473) 0474 Announcement of NGWG meeting: Call for papers. S. Bunch. March 1973. (Format: TXT=1170 bytes) (Updates RFC0396) (Status: UNKNOWN) (DOI: 10.17487/RFC0474) 0475 FTP and Network Mail System. A.K. Bhushan. March 1973. (Format: TXT=21928, PDF=600361 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0475) 0476 IMP/TIP memory retrofit schedule (rev 2). A.M. McKenzie. March 1973. (Format: TXT=2281 bytes) (Obsoletes RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0476) 0477 Remote Job Service at UCSB. M. Krilanovich. May 1973. (Format: TXT=40535 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0477) 0478 FTP server-server interaction - II. R.D. Bressler, R. Thomas. March 1973. (Format: TXT=4199 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0478) 0479 Use of FTP by the NIC Journal. J.E. White. March 1973. (Format: TXT=11183 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0479) 0480 Host-dependent FTP parameters. J.E. White. March 1973. (Format: TXT=2084 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0480) 0481 Not Issued. 0482 Traffic statistics (February 1973). A.M. McKenzie. March 1973. (Format: TXT=6162 bytes) (Updated by RFC0497) (Status: UNKNOWN) (DOI: 10.17487/RFC0482) 0483 Cancellation of the resource notebook framework meeting. M.D. Kudlick. March 1973. (Format: TXT=1021 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0483) 0484 Not Issued. 0485 MIX and MIXAL at UCSB. J.R. Pickens. March 1973. (Format: TXT=2226 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0485) 0486 Data transfer revisited. R.D. Bressler. March 1973. (Format: TXT=4664 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0486) 0487 Free file transfer. R.D. Bressler. April 1973. (Format: TXT=3249 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0487) 0488 NLS classes at network sites. M.F. Auerbach. March 1973. (Format: TXT=3806 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0488) 0489 Comment on resynchronization of connection status proposal. J. Postel. March 1973. (Format: TXT=2010 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0489) 0490 Surrogate RJS for UCLA-CCN. J.R. Pickens. March 1973. (Format: TXT=9858 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0490) 0491 What is "Free"?. M.A. Padlipsky. April 1973. (Format: TXT=5872 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0491) 0492 Response to RFC 467. E. Meyer. April 1973. (Format: TXT=18791 bytes) (Updates RFC0467) (Status: UNKNOWN) (DOI: 10.17487/RFC0492) 0493 GRAPHICS PROTOCOL. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. April 1973. (Format: TXT=67843, PDF=1563891 bytes) (Obsoletes RFC0292) (Status: UNKNOWN) (DOI: 10.17487/RFC0493) 0494 Availability of MIX and MIXAL in the Network. D.C. Walden. April 1973. (Format: TXT=2007 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0494) 0495 Telnet Protocol specifications. A.M. McKenzie. May 1973. (Format: TXT=4260 bytes) (Obsoletes RFC0158) (Updated by RFC0562) (Status: UNKNOWN) (DOI: 10.17487/RFC0495) 0496 TNLS quick reference card is available. M.F. Auerbach. April 1973. (Format: TXT=1110 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0496) 0497 Traffic Statistics (March 1973). A.M. McKenzie. April 1973. (Format: TXT=6078, PDF=191264 bytes) (Updates RFC0482) (Status: UNKNOWN) (DOI: 10.17487/RFC0497) 0498 On mail service to CCN. R.T. Braden. April 1973. (Format: TXT=5315 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0498) 0499 Harvard's network RJE. B.R. Reussow. April 1973. (Format: TXT=12584 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0499) 0500 Integration of data management systems on a computer network. A. Shoshani, I. Spiegler. April 1973. (Format: PDF=3045801 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0500) 0501 Un-muddling "free file transfer". K.T. Pogran. May 1973. (Format: TXT=13177 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0501) 0502 Not Issued. 0503 Socket number list. N. Neigus, J. Postel. April 1973. (Format: TXT=8690 bytes) (Obsoletes RFC0433) (Obsoleted by RFC0739) (Status: UNKNOWN) (DOI: 10.17487/RFC0503) 0504 Distributed resources workshop announcement. R. Thomas. April 1973. (Format: TXT=9061 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0504) 0505 Two solutions to a file transfer access problem. M.A. Padlipsky. June 1973. (Format: TXT=7476 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0505) 0506 FTP command naming problem. M.A. Padlipsky. June 1973. (Format: TXT=1974 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0506) 0507 Not Issued. 0508 Real-time data transmission on the ARPANET. L. Pfeifer, J. McAfee. May 1973. (Format: TXT=25002 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0508) 0509 Traffic statistics (April 1973). A.M. McKenzie. April 1973. (Format: TXT=6538 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0509) 0510 Request for network mailbox addresses. J.E. White. May 1973. (Format: TXT=4150 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0510) 0511 Enterprise phone service to NIC from ARPANET sites. J.B. North. May 1973. (Format: TXT=4664 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0511) 0512 More on lost message detection. W. Hathaway. May 1973. (Format: TXT=3641 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0512) 0513 Comments on the new Telnet specifications. W. Hathaway. May 1973. (Format: TXT=7980 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0513) 0514 Network make-work. W. Kantrowitz. June 1973. (Format: TXT=8734 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0514) 0515 Specifications for Datalanguage, Version 0/9. R. Winter. June 1973. (Format: TXT=60557 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0515) 0516 Lost message detection. J. Postel. May 1973. (Format: TXT=4086 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0516) 0517 Not Issued. 0518 ARPANET accounts. N. Vaughan, E.J. Feinler. June 1973. (Format: TXT=12880 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0518) 0519 Resource Evaluation. J.R. Pickens. June 1973. (Format: TXT=7750, PDF=224969 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0519) 0520 Memo to FTP group: Proposal for File Access Protocol. J.D. Day. June 1973. (Format: TXT=16825 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0520) 0521 Restricted use of IMP DDT. A.M. McKenzie. May 1973. (Format: TXT=3724 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0521) 0522 Traffic Statistics (May 1973). A.M. McKenzie. June 1973. (Format: TXT=6125, PDF=163705 bytes) (Updates RFC0509) (Status: UNKNOWN) (DOI: 10.17487/RFC0522) 0523 SURVEY is in operation again. A.K. Bhushan. June 1973. (Format: TXT=2852 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0523) 0524 Proposed Mail Protocol. J.E. White. June 1973. (Format: TXT=75385 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0524) 0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing. W. Parrish, J.R. Pickens. June 1973. (Format: TXT=18501, PS=304440, PDF=228274 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0525) 0526 Technical meeting: Digital image processing software systems. W.K. Pratt. June 1973. (Format: TXT=4062 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0526) 0527 ARPAWOCKY. R. Merryman. May 1973. (Format: TXT=1857 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0527) 0528 Software checksumming in the IMP and network reliability. J.M. McQuillan. June 1973. (Format: TXT=23152 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0528) 0529 Note on protocol synch sequences. A.M. McKenzie, R. Thomas, R.S. Tomlinson, K.T. Pogran. June 1973. (Format: TXT=9068 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0529) 0530 Report on the Survey Project. A.K. Bhushan. June 1973. (Format: PDF=408102 bytes) (Updates RFC0308, RFC0523) (Status: UNKNOWN) (DOI: 10.17487/RFC0530) 0531 Feast or famine? A response to two recent RFC's about network information. M.A. Padlipsky. June 1973. (Format: TXT=5070 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0531) 0532 UCSD-CC Server-FTP facility. R.G. Merryman. July 1973. (Format: TXT=7298 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0532) 0533 Message-ID numbers. D.C. Walden. July 1973. (Format: TXT=2102 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0533) 0534 Lost message detection. D.C. Walden. July 1973. (Format: TXT=3227 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0534) 0535 Comments on File Access Protocol. R. Thomas. July 1973. (Format: TXT=8393, PDF=239916 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0535) 0536 Not Issued. 0537 Announcement of NGG meeting July 16-17. S. Bunch. June 1973. (Format: TXT=2695 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0537) 0538 Traffic statistics (June 1973). A.M. McKenzie. July 1973. (Format: TXT=6389 bytes) (Updated by RFC0556) (Status: UNKNOWN) (DOI: 10.17487/RFC0538) 0539 Thoughts on the mail protocol proposed in RFC 524. D. Crocker, J. Postel. July 1973. (Format: TXT=6213 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0539) 0540 Not Issued. 0541 Not Issued. 0542 File Transfer Protocol. N. Neigus. August 1973. (Format: TXT=100666 bytes) (Obsoletes RFC0354) (Obsoleted by RFC0765) (Updated by RFC0614, RFC0640) (Also RFC0454, RFC0495) (Status: UNKNOWN) (DOI: 10.17487/RFC0542) 0543 Network journal submission and delivery. N.D. Meyer. July 1973. (Format: TXT=15621 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0543) 0544 Locating on-line documentation at SRI-ARC. N.D. Meyer, K. Kelley. July 1973. (Format: TXT=1541 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0544) 0545 Of what quality be the UCSB resources evaluators?. J.R. Pickens. July 1973. (Format: TXT=3754 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0545) 0546 Tenex load averages for July 1973. R. Thomas. August 1973. (Format: TXT=6632, PS=356023, PDF=268918 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0546) 0547 Change to the Very Distant Host specification. D.C. Walden. August 1973. (Format: TXT=6236 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0547) 0548 Hosts using the IMP Going Down message. D.C. Walden. August 1973. (Format: TXT=1435 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0548) 0549 Minutes of Network Graphics Group meeting, 15-17 July 1973. J.C. Michener. July 1973. (Format: TXT=23367 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0549) 0550 NIC NCP experiment. L.P. Deutsch. August 1973. (Format: TXT=3688 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0550) 0551 NYU, ANL, and LBL Joining the Net. Y. Feinroth, R. Fink. August 1973. (Format: TXT=3020, PDF=73188 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0551) 0552 Single access to standard protocols. A.D. Owen. July 1973. (Format: TXT=1404 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0552) 0553 Draft design for a text/graphics protocol. C.H. Irby, K. Victor. July 1973. (Format: TXT=35414 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0553) 0554 Not Issued. 0555 Responses to critiques of the proposed mail protocol. J.E. White. July 1973. (Format: TXT=21521 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0555) 0556 Traffic Statistics (July 1973). A.M. McKenzie. August 1973. (Format: TXT=6648, PDF=142156 bytes) (Updates RFC0538) (Status: UNKNOWN) (DOI: 10.17487/RFC0556) 0557 REVELATIONS IN NETWORK HOST MEASUREMENTS. B.D. Wessler. August 1973. (Format: TXT=3167, PDF=90256 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0557) 0558 Not Issued. 0559 Comments on The New Telnet Protocol and its Implementation. A.K. Bushan. August 1973. (Format: TXT=10643 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0559) 0560 Remote Controlled Transmission and Echoing Telnet option. D. Crocker, J. Postel. August 1973. (Format: TXT=22686, PDF=649235 bytes) (Updated by RFC0581) (Status: UNKNOWN) (DOI: 10.17487/RFC0560) 0561 Standardizing Network Mail Headers. A.K. Bhushan, K.T. Pogran, R.S. Tomlinson, J.E. White. September 1973. (Format: TXT=6159 bytes) (Updated by RFC0680) (Status: UNKNOWN) (DOI: 10.17487/RFC0561) 0562 Modifications to the TELNET Specification. A.M. McKenzie. August 1973. (Format: TXT=2760, PDF=79307 bytes) (Updates RFC0495) (Status: UNKNOWN) (DOI: 10.17487/RFC0562) 0563 Comments on the RCTE Telnet option. J. Davidson. August 1973. (Format: TXT=10788 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0563) 0564 Not Issued. 0565 Storing network survey data at the datacomputer. D. Cantor. August 1973. (Format: TXT=9307 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0565) 0566 Traffic statistics (August 1973). A.M. McKenzie. September 1973. (Format: TXT=6674 bytes) (Updated by RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0566) 0567 Cross Country Network Bandwidth. L.P. Deutsch. September 1973. (Format: TXT=1529 bytes) (Updated by RFC0568) (Status: UNKNOWN) (DOI: 10.17487/RFC0567) 0568 Response to RFC 567 - cross country network bandwidth. J.M. McQuillan. September 1973. (Format: TXT=3244 bytes) (Updates RFC0567) (Status: UNKNOWN) (DOI: 10.17487/RFC0568) 0569 NETED: A Common Editor for the ARPA Network. M.A. Padlipsky. October 1973. (Format: TXT=17717 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0569) 0570 Experimental input mapping between NVT ASCII and UCSB On Line System. J.R. Pickens. October 1973. (Format: TXT=177, PS=488023, PDF=375635 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0570) 0571 TENEX FTP PROBLEM. R. Braden. November 1973. (Format: TXT=1530 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0571) 0572 Not Issued. 0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS. A. Bhushan. September 1973. (Format: TXT=19474, PDF=543794 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0573) 0574 Announcement of a Mail Facility at UCSB. M. Krilanovich. September 1973. (Format: TXT=1253, PDF=40358 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0574) 0575 Not Issued. 0576 Proposal for modifying linking. K. Victor. September 1973. (Format: TXT=3916, PDF=175955 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0576) 0577 Mail priority. D. Crocker. October 1973. (Format: TXT=2434, PDF=91292 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0577) 0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle. A.K. Bhushan, N.D. Ryan. October 1973. (Format: TXT=21185, PDF=1044808 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0578) 0579 Traffic statistics (September 1973). A.M. McKenzie. November 1973. (Format: TXT=7827, PDF=283306 bytes) (Updates RFC0566) (Updated by RFC0586) (Status: UNKNOWN) (DOI: 10.17487/RFC0579) 0580 Note to Protocol Designers and Implementers. J. Postel. October 1973. (Format: TXT=1451 bytes) (Updated by RFC0582) (Status: UNKNOWN) (DOI: 10.17487/RFC0580) 0581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option. D. Crocker, J. Postel. November 1973. (Format: TXT=11060, PDF=385657 bytes) (Updates RFC0560) (Status: UNKNOWN) (DOI: 10.17487/RFC0581) 0582 Comments on RFC 580: Machine readable protocols. R. Clements. November 1973. (Format: TXT=1635 bytes) (Updates RFC0580) (Status: UNKNOWN) (DOI: 10.17487/RFC0582) 0583 Not Issued. 0584 Charter for ARPANET Users Interest Working Group. J. Iseli, D. Crocker, N. Neigus. November 1973. (Format: TXT=3461 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0584) 0585 ARPANET users interest working group meeting. D. Crocker, N. Neigus, E.J. Feinler, J. Iseli. November 1973. (Format: TXT=18243 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0585) 0586 Traffic statistics (October 1973). A.M. McKenzie. November 1973. (Format: TXT=7428, PDF=231714 bytes) (Updates RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0586) 0587 Announcing New Telnet Options. J. Postel. November 1973. (Format: TXT=832 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0587) 0588 London Node Is Now Up. A. Stokes. October 1973. (Format: TXT=5608, PDF=180352 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0588) 0589 CCN NETRJS server messages to remote user. R.T. Braden. November 1973. (Format: TXT=7998 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0589) 0590 MULTICS address change. M.A. Padlipsky. November 1973. (Format: TXT=1436 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0590) 0591 Addition to the Very Distant Host specifications. D.C. Walden. November 1973. (Format: TXT=901 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0591) 0592 Some thoughts on system design to facilitate resource sharing. R.W. Watson. November 1973. (Format: TXT=10323, PDF=289505 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0592) 0593 Telnet and FTP implementation schedule change. A.M. McKenzie, J. Postel. November 1973. (Format: TXT=2506 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0593) 0594 Speedup of Host-IMP interface. J.D. Burchfiel. December 1973. (Format: TXT=5855, PDF=182977 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0594) 0595 Second thoughts in defense of the Telnet Go-Ahead. W. Hathaway. December 1973. (Format: TXT=13507 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0595) 0596 Second thoughts on Telnet Go-Ahead. E.A. Taft. December 1973. (Format: TXT=11919 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0596) 0597 Host status. N. Neigus, E.J. Feinler. December 1973. (Format: TXT=11678 bytes) (Updated by RFC0603) (Status: UNKNOWN) (DOI: 10.17487/RFC0597) 0598 RFC index - December 5, 1973. Network Information Center. Stanford Research Institute. December 1973. (Format: PDF=1078956 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0598) 0599 Update on NETRJS. R.T. Braden. December 1973. (Format: TXT=16590 bytes) (Obsoletes RFC0189) (Obsoleted by RFC0740) (Status: UNKNOWN) (DOI: 10.17487/RFC0599) 0600 Interfacing an Illinois plasma terminal to the ARPANET. A. Berggreen. November 1973. (Format: TXT=8510, PDF=213041 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0600) 0601 Traffic statistics (November 1973). A.M. McKenzie. December 1973. (Format: TXT=9100 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0601) 0602 "The stockings were hung by the chimney with care". R.M. Metcalfe. December 1973. (Format: TXT=1988 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0602) 0603 Response to RFC 597: Host status. J.D. Burchfiel. December 1973. (Format: TXT=1482 bytes) (Updates RFC0597) (Updated by RFC0613) (Status: UNKNOWN) (DOI: 10.17487/RFC0603) 0604 Assigned link numbers. J. Postel. December 1973. (Format: TXT=2758 bytes) (Obsoletes RFC0317) (Obsoleted by RFC0739) (Status: UNKNOWN) (DOI: 10.17487/RFC0604) 0605 Not Issued. 0606 Host names on-line. L.P. Deutsch. December 1973. (Format: TXT=6855 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0606) 0607 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg. January 1974. (Format: TXT=8652 bytes) (Obsoleted by RFC0624) (Updated by RFC0614) (Status: UNKNOWN) (DOI: 10.17487/RFC0607) 0608 Host names on-line. M.D. Kudlick. January 1974. (Format: TXT=7010 bytes) (Obsoleted by RFC0810) (Status: UNKNOWN) (DOI: 10.17487/RFC0608) 0609 Statement of upcoming move of NIC/NLS service. B. Ferguson. January 1974. (Format: TXT=1260 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0609) 0610 Further datalanguage design concepts. R. Winter, J. Hill, W. Greiff. December 1973. (Format: TXT=198692 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0610) 0611 Two changes to the IMP/Host Protocol to improve user/network communications. D.C. Walden. February 1974. (Format: TXT=7481 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0611) 0612 Traffic statistics (December 1973). A.M. McKenzie. January 1974. (Format: TXT=9667 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0612) 0613 Network connectivity: A response to RFC 603. A.M. McKenzie. January 1974. (Format: TXT=2557 bytes) (Updates RFC0603) (Status: UNKNOWN) (DOI: 10.17487/RFC0613) 0614 Response to RFC 607: "Comments on the File Transfer Protocol". K.T. Pogran, N. Neigus. January 1974. (Format: TXT=11409 bytes) (Updates RFC0542, RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0614) 0615 Proposed Network Standard Data Pathname syntax. D. Crocker. March 1974. (Format: TXT=9448 bytes) (Obsoleted by RFC0645) (Status: UNKNOWN) (DOI: 10.17487/RFC0615) 0616 LATEST NETWORK MAPS. D. Walden. February 1973. (Format: TXT=848, PDF=117083 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0616) 0617 Note on socket number assignment. E.A. Taft. February 1974. (Format: TXT=8062 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0617) 0618 Few observations on NCP statistics. E.A. Taft. February 1974. (Format: TXT=4929 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0618) 0619 Mean round-trip times in the ARPANET. W. Naylor, H. Opderbeck. March 1974. (Format: TXT=30946 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0619) 0620 Request for monitor host table updates. B. Ferguson. March 1974. (Format: TXT=1950 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0620) 0621 NIC user directories at SRI ARC. M.D. Kudlick. March 1974. (Format: TXT=1351 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0621) 0622 Scheduling IMP/TIP down time. A.M. McKenzie. March 1974. (Format: TXT=4367 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0622) 0623 Comments on on-line host name service. M. Krilanovich. February 1974. (Format: TXT=3740 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0623) 0624 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg, W. Hathaway, J.E. White. February 1974. (Format: TXT=10105 bytes) (Obsoletes RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0624) 0625 On-line hostnames service. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT=2172 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0625) 0626 On a possible lockup condition in IMP subnet due to message sequencing. L. Kleinrock, H. Opderbeck. March 1974. (Format: TXT=13150 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0626) 0627 ASCII text file of hostnames. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT=2007 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0627) 0628 Status of RFC numbers and a note on pre-assigned journal numbers. M.L. Keeney. March 1974. (Format: TXT=1036 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0628) 0629 Scenario for using the Network Journal. J.B. North. March 1974. (Format: TXT=4504 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0629) 0630 FTP error code usage for more reliable mail service. J. Sussman. April 1974. (Format: TXT=4070 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0630) 0631 International meeting on minicomputers and data communication: Call for papers. A. Danthine. April 1974. (Format: TXT=2707 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0631) 0632 Throughput degradations for single packet messages. H. Opderbeck. May 1974. (Format: TXT=14563 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0632) 0633 IMP/TIP preventive maintenance schedule. A.M. McKenzie. March 1974. (Format: TXT=3733 bytes) (Obsoleted by RFC0638) (Status: UNKNOWN) (DOI: 10.17487/RFC0633) 0634 Change in network address for Haskins Lab. A.M. McKenzie. April 1974. (Format: TXT=1098 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0634) 0635 Assessment of ARPANET protocols. V. Cerf. April 1974. (Format: TXT=338, PDF=3208268 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0635) 0636 TIP/Tenex reliability improvements. J.D. Burchfiel, B. Cosell, R.S. Tomlinson, D.C. Walden. June 1974. (Format: TXT=19914 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0636) 0637 Change of network address for SU-DSL. A.M. McKenzie. April 1974. (Format: TXT=916 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0637) 0638 IMP/TIP preventive maintenance schedule. A.M. McKenzie. April 1974. (Format: TXT=4088 bytes) (Obsoletes RFC0633) (Status: UNKNOWN) (DOI: 10.17487/RFC0638) 0639 Not Issued. 0640 Revised FTP reply codes. J. Postel. June 1974. (Format: TXT=39670 bytes) (Updates RFC0542) (Status: UNKNOWN) (DOI: 10.17487/RFC0640) 0641 Not Issued. 0642 Ready line philosophy and implementation. J.D. Burchfiel. July 1974. (Format: TXT=8414 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0642) 0643 Network Debugging Protocol. E. Mader. July 1974. (Format: TXT=12563 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0643) 0644 On the problem of signature authentication for network mail. R. Thomas. July 1974. (Format: TXT=9501 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0644) 0645 Network Standard Data Specification syntax. D. Crocker. June 1974. (Format: TXT=16561, PDF=567325 bytes) (Obsoletes RFC0615) (Status: UNKNOWN) (DOI: 10.17487/RFC0645) 0646 Not Issued. 0647 Proposed protocol for connecting host computers to ARPA-like networks via front end processors. M.A. Padlipsky. November 1974. (Format: TXT=57785, PDF=1948940 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0647) 0648 Not Issued. 0649 Not Issued. 0650 Not Issued. 0651 Revised Telnet status option. D. Crocker. October 1974. (Format: TXT=4360 bytes) (Obsoleted by RFC0859) (Status: UNKNOWN) (DOI: 10.17487/RFC0651) 0652 Telnet output carriage-return disposition option. D. Crocker. October 1974. (Format: TXT=7003 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0652) 0653 Telnet output horizontal tabstops option. D. Crocker. October 1974. (Format: TXT=4694 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0653) 0654 Telnet output horizontal tab disposition option. D. Crocker. October 1974. (Format: TXT=6158 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0654) 0655 Telnet output formfeed disposition option. D. Crocker. October 1974. (Format: TXT=5991 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0655) 0656 Telnet output vertical tabstops option. D. Crocker. October 1974. (Format: TXT=4858 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0656) 0657 Telnet output vertical tab disposition option. D. Crocker. October 1974. (Format: TXT=5759 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0657) 0658 Telnet output linefeed disposition. D. Crocker. October 1974. (Format: TXT=6484 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0658) 0659 Announcing additional Telnet options. J. Postel. October 1974. (Format: TXT=2016 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0659) 0660 Some changes to the IMP and the IMP/Host interface. D.C. Walden. October 1974. (Format: TXT=4991 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0660) 0661 Protocol information. J. Postel. November 1974. (Format: TXT=29534, PDF=1071305 bytes) (Updated by RFC0694) (Status: UNKNOWN) (DOI: 10.17487/RFC0661) 0662 Performance improvement in ARPANET file transfers from Multics. R. Kanodia. November 1974. (Format: TXT=8872 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0662) 0663 Lost message detection and recovery protocol. R. Kanodia. November 1974. (Format: TXT=44702 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0663) 0664 Not Issued. 0665 Not Issued. 0666 Specification of the Unified User-Level Protocol. M.A. Padlipsky. November 1974. (Format: TXT=49024 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0666) 0667 Host Ports. S.G. Chipman. December 1974. (Format: TXT=3244, PDF=52660 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0667) 0668 Not Issued. 0669 November, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. December 1974. (Format: TXT=5121, PDF=134962 bytes) (Updates RFC0702) (Updated by RFC0679) (Status: UNKNOWN) (DOI: 10.17487/RFC0669) 0670 Not Issued. 0671 Note on Reconnection Protocol. R. Schantz. December 1974. (Format: TXT=24125, PDF=686491 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0671) 0672 Multi-site data collection facility. R. Schantz. December 1974. (Format: TXT=25736 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0672) 0673 Not Issued. 0674 Procedure call documents: Version 2. J. Postel, J.E. White. December 1974. (Format: TXT=12178 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0674) 0675 Specification of Internet Transmission Control Program. V. Cerf, Y. Dalal, C. Sunshine. December 1974. (Format: TXT=156874 bytes) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0675) 0676 Not Issued. 0677 Maintenance of duplicate databases. P.R. Johnson, R. Thomas. January 1975. (Format: TXT=22990 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0677) 0678 Standard file formats. J. Postel. December 1974. (Format: TXT=12393 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0678) 0679 February, 1975, survey of New-Protocol Telnet servers. D.W. Dodds. February 1975. (Format: TXT=5263, PDF=142853 bytes) (Updates RFC0669) (Updated by RFC0703) (Status: UNKNOWN) (DOI: 10.17487/RFC0679) 0680 Message Transmission Protocol. T.H. Myer, D.A. Henderson. April 1975. (Format: TXT=11539 bytes) (Updates RFC0561) (Status: UNKNOWN) (DOI: 10.17487/RFC0680) 0681 Network UNIX. S. Holmgren. March 1975. (Format: TXT=18874 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0681) 0682 Not Issued. 0683 FTPSRV - Tenex extension for paged files. R. Clements. April 1975. (Format: TXT=8806 bytes) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0683) 0684 Commentary on procedure calling as a network protocol. R. Schantz. April 1975. (Format: TXT=21164 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0684) 0685 Response time in cross network debugging. M. Beeler. April 1975. (Format: TXT=6914 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0685) 0686 Leaving well enough alone. B. Harvey. May 1975. (Format: TXT=24605 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0686) 0687 IMP/Host and Host/IMP Protocol changes. D.C. Walden. June 1975. (Format: TXT=6013 bytes) (Obsoleted by RFC0704) (Updated by RFC0690) (Status: UNKNOWN) (DOI: 10.17487/RFC0687) 0688 Tentative schedule for the new Telnet implementation for the TIP. D.C. Walden. June 1975. (Format: TXT=1593 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0688) 0689 Tenex NCP finite state machine for connections. R. Clements. May 1975. (Format: TXT=13101 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0689) 0690 Comments on the proposed Host/IMP Protocol changes. J. Postel. June 1975. (Format: TXT=7215 bytes) (Updates RFC0687) (Updated by RFC0692) (Status: UNKNOWN) (DOI: 10.17487/RFC0690) 0691 One more try on the FTP. B. Harvey. June 1975. (Format: TXT=32821 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0691) 0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690). S.M. Wolfe. June 1975. (Format: TXT=2681 bytes) (Updates RFC0690) (Status: UNKNOWN) (DOI: 10.17487/RFC0692) 0693 Not Issued. 0694 Protocol information. J. Postel. June 1975. (Format: TXT=52961, PDF=1457530 bytes) (Updates RFC0661) (Status: UNKNOWN) (DOI: 10.17487/RFC0694) 0695 Official change in Host-Host Protocol. M. Krilanovich. July 1975. (Format: TXT=3425 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0695) 0696 Comments on the IMP/Host and Host/IMP Protocol changes. V.G. Cerf. July 1975. (Format: TXT=4432, PDF=227873 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0696) 0697 CWD command of FTP. J. Lieb. July 1975. (Format: TXT=3047 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0697) 0698 Telnet extended ASCII option. T. Mock. July 1975. (Format: TXT=5086 bytes) (Obsoleted by RFC5198) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0698) 0699 Request For Comments summary notes: 600-699. J. Postel, J. Vernon. November 1982. (Format: TXT=14688 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0699) 0700 Protocol experiment. E. Mader, W.W. Plummer, R.S. Tomlinson. August 1974. (Format: TXT=14600 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0700) 0701 August, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. August 1974. (Format: TXT=3549 bytes) (Updated by RFC0702) (Status: UNKNOWN) (DOI: 10.17487/RFC0701) 0702 September, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. September 1974. (Format: TXT=5386 bytes) (Updates RFC0701) (Updated by RFC0669) (Status: UNKNOWN) (DOI: 10.17487/RFC0702) 0703 July, 1975, survey of New-Protocol Telnet Servers. D.W. Dodds. July 1975. (Format: TXT=5691 bytes) (Updates RFC0679) (Status: UNKNOWN) (DOI: 10.17487/RFC0703) 0704 IMP/Host and Host/IMP Protocol change. P.J. Santos. September 1975. (Format: TXT=7504 bytes) (Obsoletes RFC0687) (Status: UNKNOWN) (DOI: 10.17487/RFC0704) 0705 Front-end Protocol B6700 version. R.F. Bryan. November 1975. (Format: TXT=70998 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0705) 0706 On the junk mail problem. J. Postel. November 1975. (Format: TXT=2085 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0706) 0707 High-level framework for network-based resource sharing. J.E. White. December 1975. (Format: TXT=57254 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0707) 0708 Elements of a Distributed Programming System. J.E. White. January 1976. (Format: TXT=57888 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0708) 0709 Not Issued. 0710 Not Issued. 0711 Not Issued. 0712 Distributed Capability Computing System (DCCS). J.E. Donnelley. February 1976. (Format: TXT=40127, PDF=1201164 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0712) 0713 MSDTP-Message Services Data Transmission Protocol. J. Haverty. April 1976. (Format: TXT=41175 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0713) 0714 Host-Host Protocol for an ARPANET-Type Network. A.M. McKenzie. April 1976. (Format: TXT=56322, PDF=1599012 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0714) 0715 Not Issued. 0716 Interim Revision to Appendix F of BBN 1822. D.C. Walden, J. Levin. May 1976. (Format: TXT=3345 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0716) 0717 Assigned Network Numbers. J. Postel. July 1976. (Format: TXT=2322 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0717) 0718 Comments on RCTE from the Tenex Implementation Experience. J. Postel. June 1976. (Format: TXT=3829 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0718) 0719 Discussion on RCTE. J. Postel. July 1976. (Format: TXT=4708 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0719) 0720 Address Specification Syntax for Network Mail. D. Crocker. August 1976. (Format: TXT=6602 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0720) 0721 Out-of-Band Control Signals in a Host-to-Host Protocol. L.L. Garlick. September 1976. (Format: TXT=13566 bytes) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0721) 0722 Thoughts on Interactions in Distributed Services. J. Haverty. September 1976. (Format: TXT=29478 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0722) 0723 Not Issued. 0724 Proposed official standard for the format of ARPA Network messages. D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. May 1977. (Format: TXT=75554 bytes) (Obsoleted by RFC0733) (Status: UNKNOWN) (DOI: 10.17487/RFC0724) 0725 RJE protocol for a resource sharing network. J.D. Day, G.R. Grossman. March 1977. (Format: TXT=44025 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0725) 0726 Remote Controlled Transmission and Echoing Telnet option. J. Postel, D. Crocker. March 1977. (Format: TXT=38651 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0726) 0727 Telnet logout option. M.R. Crispin. April 1977. (Format: TXT=5674 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0727) 0728 Minor pitfall in the Telnet Protocol. J.D. Day. April 1977. (Format: TXT=2224 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0728) 0729 Telnet byte macro option. D. Crocker. May 1977. (Format: TXT=6509 bytes) (Obsoleted by RFC0735) (Status: UNKNOWN) (DOI: 10.17487/RFC0729) 0730 Extensible field addressing. J. Postel. May 1977. (Format: TXT=9519 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0730) 0731 Telnet Data Entry Terminal option. J.D. Day. June 1977. (Format: TXT=61648 bytes) (Obsoleted by RFC0732) (Status: UNKNOWN) (DOI: 10.17487/RFC0731) 0732 Telnet Data Entry Terminal option. J.D. Day. September 1977. (Format: TXT=57160 bytes) (Obsoletes RFC0731) (Updated by RFC1043) (Status: UNKNOWN) (DOI: 10.17487/RFC0732) 0733 Standard for the format of ARPA network text messages. D. Crocker, J. Vittal, K.T. Pogran, D.A. Henderson. November 1977. (Format: TXT=73006 bytes) (Obsoletes RFC0724) (Obsoleted by RFC0822) (Status: UNKNOWN) (DOI: 10.17487/RFC0733) 0734 SUPDUP Protocol. M.R. Crispin. October 1977. (Format: TXT=33256 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0734) 0735 Revised Telnet byte macro option. D. Crocker, R.H. Gumpertz. November 1977. (Format: TXT=10585 bytes) (Obsoletes RFC0729) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0735) 0736 Telnet SUPDUP option. M.R. Crispin. October 1977. (Format: TXT=3081 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0736) 0737 FTP extension: XSEN. K. Harrenstien. October 1977. (Format: TXT=2127 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0737) 0738 Time server. K. Harrenstien. October 1977. (Format: TXT=1851 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0738) 0739 Assigned numbers. J. Postel. November 1977. (Format: TXT=16346 bytes) (Obsoletes RFC0604, RFC0503) (Obsoleted by RFC0750) (Status: HISTORIC) (DOI: 10.17487/RFC0739) 0740 NETRJS Protocol. R.T. Braden. November 1977. (Format: TXT=38833 bytes) (Obsoletes RFC0599) (Status: HISTORIC) (DOI: 10.17487/RFC0740) 0741 Specifications for the Network Voice Protocol (NVP). D. Cohen. November 1977. (Format: TXT=57581 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0741) 0742 NAME/FINGER Protocol. K. Harrenstien. December 1977. (Format: TXT=12321 bytes) (Obsoleted by RFC1288, RFC1196, RFC1194) (Status: UNKNOWN) (DOI: 10.17487/RFC0742) 0743 FTP extension: XRSQ/XRCP. K. Harrenstien. December 1977. (Format: TXT=16249 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0743) 0744 MARS - a Message Archiving and Retrieval Service. J. Sattley. January 1978. (Format: TXT=10984 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0744) 0745 JANUS interface specifications. M. Beeler. March 1978. (Format: TXT=21453 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0745) 0746 SUPDUP graphics extension. R. Stallman. March 1978. (Format: TXT=30197 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0746) 0747 Recent extensions to the SUPDUP Protocol. M.R. Crispin. March 1978. (Format: TXT=2870 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0747) 0748 Telnet randomly-lose option. M.R. Crispin. April 1978. (Format: TXT=2741 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0748) 0749 Telnet SUPDUP-Output option. B. Greenberg. September 1978. (Format: TXT=8933 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0749) 0750 Assigned numbers. J. Postel. September 1978. (Format: TXT=19979 bytes) (Obsoletes RFC0739) (Obsoleted by RFC0755) (Status: HISTORIC) (DOI: 10.17487/RFC0750) 0751 Survey of FTP mail and MLFL. P.D. Lebling. December 1978. (Format: TXT=10069 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0751) 0752 Universal host table. M.R. Crispin. January 1979. (Format: TXT=33793 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0752) 0753 Internet Message Protocol. J. Postel. March 1979. (Format: TXT=93363 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0753) 0754 Out-of-net host addresses for mail. J. Postel. April 1979. (Format: TXT=19212 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0754) 0755 Assigned numbers. J. Postel. May 1979. (Format: TXT=22039 bytes) (Obsoletes RFC0750) (Obsoleted by RFC0758) (Status: HISTORIC) (DOI: 10.17487/RFC0755) 0756 NIC name server - a datagram-based information utility. J.R. Pickens, E.J. Feinler, J.E. Mathis. July 1979. (Format: TXT=23491 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0756) 0757 Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems. D.P. Deutsch. September 1979. (Format: TXT=35618 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0757) 0758 Assigned numbers. J. Postel. August 1979. (Format: TXT=22911 bytes) (Obsoletes RFC0755) (Obsoleted by RFC0762) (Status: HISTORIC) (DOI: 10.17487/RFC0758) 0759 Internet Message Protocol. J. Postel. August 1980. (Format: TXT=123606 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0759) 0760 DoD standard Internet Protocol. J. Postel. January 1980. (Format: TXT=81507 bytes) (Obsoletes IEN123) (Obsoleted by RFC0791) (Updated by RFC0777) (Status: UNKNOWN) (DOI: 10.17487/RFC0760) 0761 DoD standard Transmission Control Protocol. J. Postel. January 1980. (Format: TXT=167049 bytes) (Obsoleted by RFC0793, RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0761) 0762 Assigned numbers. J. Postel. January 1980. (Format: TXT=24668 bytes) (Obsoletes RFC0758) (Obsoleted by RFC0770) (Status: HISTORIC) (DOI: 10.17487/RFC0762) 0763 Role mailboxes. M.D. Abrams. May 1980. (Format: TXT=942 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0763) 0764 Telnet Protocol specification. J. Postel. June 1980. (Format: TXT=40005 bytes) (Obsoleted by RFC0854) (Status: UNKNOWN) (DOI: 10.17487/RFC0764) 0765 File Transfer Protocol specification. J. Postel. June 1980. (Format: TXT=146641 bytes) (Obsoletes RFC0542) (Obsoleted by RFC0959) (Status: UNKNOWN) (DOI: 10.17487/RFC0765) 0766 Internet Protocol Handbook: Table of contents. J. Postel. July 1980. (Format: TXT=3465 bytes) (Obsoleted by RFC0774) (Status: UNKNOWN) (DOI: 10.17487/RFC0766) 0767 Structured format for transmission of multi-media documents. J. Postel. August 1980. (Format: TXT=59971 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0767) 0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT=5896 bytes) (Also STD0006) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0768) 0769 Rapicom 450 facsimile file format. J. Postel. September 1980. (Format: TXT=4079 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0769) 0770 Assigned numbers. J. Postel. September 1980. (Format: TXT=26248 bytes) (Obsoletes RFC0762) (Obsoleted by RFC0776) (Status: HISTORIC) (DOI: 10.17487/RFC0770) 0771 Mail transition plan. V.G. Cerf, J. Postel. September 1980. (Format: TXT=18623 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0771) 0772 Mail Transfer Protocol. S. Sluizer, J. Postel. September 1980. (Format: TXT=61061 bytes) (Obsoleted by RFC0780) (Status: UNKNOWN) (DOI: 10.17487/RFC0772) 0773 Comments on NCP/TCP mail service transition strategy. V.G. Cerf. October 1980. (Format: TXT=22181 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0773) 0774 Internet Protocol Handbook: Table of contents. J. Postel. October 1980. (Format: TXT=3452 bytes) (Obsoletes RFC0766) (Status: UNKNOWN) (DOI: 10.17487/RFC0774) 0775 Directory oriented FTP commands. D. Mankins, D. Franklin, A.D. Owen. December 1980. (Format: TXT=9511 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0775) 0776 Assigned numbers. J. Postel. January 1981. (Format: TXT=30311 bytes) (Obsoletes RFC0770) (Obsoleted by RFC0790) (Status: HISTORIC) (DOI: 10.17487/RFC0776) 0777 Internet Control Message Protocol. J. Postel. April 1981. (Format: TXT=19407 bytes) (Obsoleted by RFC0792) (Updates RFC0760) (Status: UNKNOWN) (DOI: 10.17487/RFC0777) 0778 DCNET Internet Clock Service. D.L. Mills. April 1981. (Format: TXT=9464 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0778) 0779 Telnet send-location option. E. Killian. April 1981. (Format: TXT=2564 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0779) 0780 Mail Transfer Protocol. S. Sluizer, J. Postel. May 1981. (Format: TXT=80352 bytes) (Obsoletes RFC0772) (Obsoleted by RFC0788) (Status: UNKNOWN) (DOI: 10.17487/RFC0780) 0781 Specification of the Internet Protocol (IP) timestamp option. Z. Su. May 1981. (Format: TXT=4002 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0781) 0782 Virtual Terminal management model. J. Nabielsky, A.P. Skelton. January 1981. (Format: TXT=43589 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0782) 0783 TFTP Protocol (revision 2). K.R. Sollins. June 1981. (Format: TXT=23522 bytes) (Obsoletes IEN133) (Obsoleted by RFC1350) (Status: UNKNOWN) (DOI: 10.17487/RFC0783) 0784 Mail Transfer Protocol: ISI TOPS20 implementation. S. Sluizer, J. Postel. July 1981. (Format: TXT=5856 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0784) 0785 Mail Transfer Protocol: ISI TOPS20 file definitions. S. Sluizer, J. Postel. July 1981. (Format: TXT=7032 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0785) 0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface. S. Sluizer, J. Postel. July 1981. (Format: TXT=3129 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0786) 0787 Connectionless data transmission survey/tutorial. A.L. Chapin. July 1981. (Format: TXT=84265 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0787) 0788 Simple Mail Transfer Protocol. J. Postel. November 1981. (Format: TXT=109001 bytes) (Obsoletes RFC0780) (Obsoleted by RFC0821) (Status: UNKNOWN) (DOI: 10.17487/RFC0788) 0789 Vulnerabilities of network control protocols: An example. E.C. Rosen. July 1981. (Format: TXT=25541 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0789) 0790 Assigned numbers. J. Postel. September 1981. (Format: TXT=35316 bytes) (Obsoletes RFC0776) (Obsoleted by RFC0820) (Status: HISTORIC) (DOI: 10.17487/RFC0790) 0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779 bytes) (Obsoletes RFC0760) (Updated by RFC1349, RFC2474, RFC6864) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0791) 0792 Internet Control Message Protocol. J. Postel. September 1981. (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950, RFC4884, RFC6633, RFC6918) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0792) 0793 Transmission Control Protocol. J. Postel. September 1981. (Format: TXT=172710 bytes) (Obsoletes RFC0761) (Updated by RFC1122, RFC3168, RFC6093, RFC6528) (Also STD0007) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0793) 0794 Pre-emption. V.G. Cerf. September 1981. (Format: TXT=5906 bytes) (Updates IEN125) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0794) 0795 Service mappings. J. Postel. September 1981. (Format: TXT=5228 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0795) 0796 Address mappings. J. Postel. September 1981. (Format: TXT=11239 bytes) (Obsoletes IEN115) (Status: HISTORIC) (DOI: 10.17487/RFC0796) 0797 Format for Bitmap files. A.R. Katz. September 1981. (Format: TXT=3067 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0797) 0798 Decoding facsimile data from the Rapicom 450. A.R. Katz. September 1981. (Format: TXT=38867 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0798) 0799 Internet name domains. D.L. Mills. September 1981. (Format: TXT=13896 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0799) 0800 Request For Comments summary notes: 700-799. J. Postel, J. Vernon. November 1982. (Format: TXT=18354 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0800) 0801 NCP/TCP transition plan. J. Postel. November 1981. (Format: TXT=42041 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0801) 0802 ARPANET 1822L Host Access Protocol. A.G. Malis. November 1981. (Format: TXT=62470 bytes) (Obsoleted by RFC0851) (Status: UNKNOWN) (DOI: 10.17487/RFC0802) 0803 Dacom 450/500 facsimile data transcoding. A. Agarwal, M.J. O'Connor, D.L. Mills. November 1981. (Format: TXT=33826 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0803) 0804 CCITT draft recommendation T.4. International Telegraph and Telephone Consultative Committee of the International Telecommunication Union. January 1981. (Format: TXT=17025 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0804) 0805 Computer mail meeting notes. J. Postel. February 1982. (Format: TXT=12522 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0805) 0806 Proposed Federal Information Processing Standard: Specification for message format for computer based message systems. National Bureau of Standards. September 1981. (Format: TXT=216377 bytes) (Obsoleted by RFC0841) (Status: UNKNOWN) (DOI: 10.17487/RFC0806) 0807 Multimedia mail meeting notes. J. Postel. February 1982. (Format: TXT=11633 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0807) 0808 Summary of computer mail services meeting held at BBN on 10 January 1979. J. Postel. March 1982. (Format: TXT=15930 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0808) 0809 UCL facsimile system. T. Chang. February 1982. (Format: TXT=171153 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0809) 0810 DoD Internet host table specification. E.J. Feinler, K. Harrenstien, Z. Su, V. White. March 1982. (Format: TXT=14196 bytes) (Obsoletes RFC0608) (Obsoleted by RFC0952) (Status: UNKNOWN) (DOI: 10.17487/RFC0810) 0811 Hostnames Server. K. Harrenstien, V. White, E.J. Feinler. March 1982. (Format: TXT=7771 bytes) (Obsoleted by RFC0953) (Status: UNKNOWN) (DOI: 10.17487/RFC0811) 0812 NICNAME/WHOIS. K. Harrenstien, V. White. March 1982. (Format: TXT=5389 bytes) (Obsoleted by RFC0954, RFC3912) (Status: UNKNOWN) (DOI: 10.17487/RFC0812) 0813 Window and Acknowledgement Strategy in TCP. D.D. Clark. July 1982. (Format: TXT=38110 bytes) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0813) 0814 Name, addresses, ports, and routes. D.D. Clark. July 1982. (Format: TXT=24663 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0814) 0815 IP datagram reassembly algorithms. D.D. Clark. July 1982. (Format: TXT=14575 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0815) 0816 Fault isolation and recovery. D.D. Clark. July 1982. (Format: TXT=20106 bytes) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0816) 0817 Modularity and efficiency in protocol implementation. D.D. Clark. July 1982. (Format: TXT=45931 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0817) 0818 Remote User Telnet service. J. Postel. November 1982. (Format: TXT=3693 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0818) 0819 The Domain Naming Convention for Internet User Applications. Z. Su, J. Postel. August 1982. (Format: TXT=35314 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0819) 0820 Assigned numbers. J. Postel. August 1982. (Format: TXT=54213 bytes) (Obsoletes RFC0790) (Obsoleted by RFC0870) (Status: HISTORIC) (DOI: 10.17487/RFC0820) 0821 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format: TXT=124482 bytes) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0821) 0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. D. Crocker. August 1982. (Format: TXT=106299 bytes) (Obsoletes RFC0733) (Obsoleted by RFC2822) (Updated by RFC1123, RFC2156, RFC1327, RFC1138, RFC1148) (Also STD0011) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0822) 0823 DARPA Internet gateway. R.M. Hinden, A. Sheltzer. September 1982. (Format: TXT=62620 bytes) (Updates IEN109, IEN30) (Status: HISTORIC) (DOI: 10.17487/RFC0823) 0824 CRONUS Virtual Local Network. W.I. MacGregor, D.C. Tappan. August 1982. (Format: TXT=58732 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0824) 0825 Request for comments on Requests For Comments. J. Postel. November 1982. (Format: TXT=4255 bytes) (Obsoleted by RFC1111, RFC1543, RFC2223) (Status: UNKNOWN) (DOI: 10.17487/RFC0825) 0826 Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. D. Plummer. November 1982. (Format: TXT=21556 bytes) (Updated by RFC5227, RFC5494) (Also STD0037) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0826) 0827 Exterior Gateway Protocol (EGP). E.C. Rosen. October 1982. (Format: TXT=68436 bytes) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0827) 0828 Data communications: IFIP's international "network" of experts. K. Owen. August 1982. (Format: TXT=29922 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0828) 0829 Packet satellite technology reference sources. V.G. Cerf. November 1982. (Format: TXT=10919 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0829) 0830 Distributed system for Internet name service. Z. Su. October 1982. (Format: TXT=31597 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0830) 0831 Backup access to the European side of SATNET. R.T. Braden. December 1982. (Format: TXT=11735 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0831) 0832 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT=42751 bytes) (Obsoleted by RFC0833) (Status: UNKNOWN) (DOI: 10.17487/RFC0832) 0833 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT=42973 bytes) (Obsoletes RFC0832) (Obsoleted by RFC0834) (Status: UNKNOWN) (DOI: 10.17487/RFC0833) 0834 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT=42764 bytes) (Obsoletes RFC0833) (Obsoleted by RFC0835) (Status: UNKNOWN) (DOI: 10.17487/RFC0834) 0835 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT=42959 bytes) (Obsoletes RFC0834) (Obsoleted by RFC0836) (Status: UNKNOWN) (DOI: 10.17487/RFC0835) 0836 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT=43643 bytes) (Obsoletes RFC0835) (Obsoleted by RFC0837) (Status: UNKNOWN) (DOI: 10.17487/RFC0836) 0837 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT=44864 bytes) (Obsoletes RFC0836) (Obsoleted by RFC0838) (Status: UNKNOWN) (DOI: 10.17487/RFC0837) 0838 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT=45033 bytes) (Obsoletes RFC0837) (Obsoleted by RFC0839) (Status: UNKNOWN) (DOI: 10.17487/RFC0838) 0839 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT=45175 bytes) (Obsoletes RFC0838) (Obsoleted by RFC0842) (Status: UNKNOWN) (DOI: 10.17487/RFC0839) 0840 Official protocols. J. Postel. April 1983. (Format: TXT=33534 bytes) (Obsoleted by RFC0880) (Status: HISTORIC) (DOI: 10.17487/RFC0840) 0841 Specification for message format for Computer Based Message Systems. National Bureau of Standards. January 1983. (Format: TXT=231871 bytes) (Obsoletes RFC0806) (Status: UNKNOWN) (DOI: 10.17487/RFC0841) 0842 Who talks TCP? - survey of 1 February 83. D. Smallberg. February 1983. (Format: TXT=45962 bytes) (Obsoletes RFC0839) (Obsoleted by RFC0843) (Status: UNKNOWN) (DOI: 10.17487/RFC0842) 0843 Who talks TCP? - survey of 8 February 83. D. Smallberg. February 1983. (Format: TXT=46193 bytes) (Obsoletes RFC0842) (Obsoleted by RFC0845) (Updated by RFC0844) (Status: UNKNOWN) (DOI: 10.17487/RFC0843) 0844 Who talks ICMP, too? - Survey of 18 February 1983. R. Clements. February 1983. (Format: TXT=9078 bytes) (Updates RFC0843) (Status: UNKNOWN) (DOI: 10.17487/RFC0844) 0845 Who talks TCP? - survey of 15 February 1983. D. Smallberg. February 1983. (Format: TXT=45983 bytes) (Obsoletes RFC0843) (Obsoleted by RFC0846) (Status: UNKNOWN) (DOI: 10.17487/RFC0845) 0846 Who talks TCP? - survey of 22 February 1983. D. Smallberg. February 1983. (Format: TXT=45597 bytes) (Obsoletes RFC0845) (Obsoleted by RFC0847) (Status: UNKNOWN) (DOI: 10.17487/RFC0846) 0847 Summary of Smallberg surveys. A. Westine, D. Smallberg, J. Postel. February 1983. (Format: TXT=3789 bytes) (Obsoletes RFC0846) (Status: UNKNOWN) (DOI: 10.17487/RFC0847) 0848 Who provides the "little" TCP services?. D. Smallberg. March 1983. (Format: TXT=10985 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0848) 0849 Suggestions for improved host table distribution. M.R. Crispin. May 1983. (Format: TXT=5178 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0849) 0850 Standard for interchange of USENET messages. M.R. Horton. June 1983. (Format: TXT=43871 bytes) (Obsoleted by RFC1036) (Status: UNKNOWN) (DOI: 10.17487/RFC0850) 0851 ARPANET 1822L Host Access Protocol. A.G. Malis. April 1983. (Format: TXT=72042 bytes) (Obsoletes RFC0802) (Obsoleted by RFC0878) (Status: UNKNOWN) (DOI: 10.17487/RFC0851) 0852 ARPANET short blocking feature. A.G. Malis. April 1983. (Format: TXT=17151 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0852) 0853 Not Issued. 0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds. May 1983. (Format: TXT=39371 bytes) (Obsoletes RFC0764) (Updated by RFC5198) (Also STD0008) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0854) 0855 Telnet Option Specifications. J. Postel, J.K. Reynolds. May 1983. (Format: TXT=6218 bytes) (Obsoletes NIC18640) (Also STD0008) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0855) 0856 Telnet Binary Transmission. J. Postel, J. Reynolds. May 1983. (Format: TXT=8965 bytes) (Obsoletes NIC15389) (Also STD0027) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0856) 0857 Telnet Echo Option. J. Postel, J. Reynolds. May 1983. (Format: TXT=10859 bytes) (Obsoletes NIC15390) (Also STD0028) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0857) 0858 Telnet Suppress Go Ahead Option. J. Postel, J. Reynolds. May 1983. (Format: TXT=3712 bytes) (Obsoletes NIC15392) (Also STD0029) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0858) 0859 Telnet Status Option. J. Postel, J. Reynolds. May 1983. (Format: TXT=4273 bytes) (Obsoletes RFC0651) (Also STD0030) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0859) 0860 Telnet Timing Mark Option. J. Postel, J. Reynolds. May 1983. (Format: TXT=7881 bytes) (Obsoletes NIC16238) (Also STD0031) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0860) 0861 Telnet Extended Options: List Option. J. Postel, J. Reynolds. May 1983. (Format: TXT=3068 bytes) (Obsoletes NIC16239) (Also STD0032) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0861) 0862 Echo Protocol. J. Postel. May 1983. (Format: TXT=1237 bytes) (Also STD0020) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0862) 0863 Discard Protocol. J. Postel. May 1983. (Format: TXT=1239 bytes) (Also STD0021) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0863) 0864 Character Generator Protocol. J. Postel. May 1983. (Format: TXT=6842 bytes) (Also STD0022) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0864) 0865 Quote of the Day Protocol. J. Postel. May 1983. (Format: TXT=1676 bytes) (Also STD0023) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0865) 0866 Active users. J. Postel. May 1983. (Format: TXT=2029 bytes) (Also STD0024) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0866) 0867 Daytime Protocol. J. Postel. May 1983. (Format: TXT=2289 bytes) (Also STD0025) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0867) 0868 Time Protocol. J. Postel, K. Harrenstien. May 1983. (Format: TXT=3024 bytes) (Also STD0026) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0868) 0869 Host Monitoring Protocol. R. Hinden. December 1983. (Format: TXT=94550 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0869) 0870 Assigned numbers. J.K. Reynolds, J. Postel. October 1983. (Format: TXT=56055 bytes) (Obsoletes RFC0820) (Obsoleted by RFC0900) (Status: HISTORIC) (DOI: 10.17487/RFC0870) 0871 Perspective on the ARPANET reference model. M.A. Padlipsky. September 1982. (Format: TXT=74455 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0871) 0872 TCP-on-a-LAN. M.A. Padlipsky. September 1982. (Format: TXT=22446 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0872) 0873 Illusion of vendor support. M.A. Padlipsky. September 1982. (Format: TXT=23095 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0873) 0874 Critique of X.25. M.A. Padlipsky. September 1982. (Format: TXT=36386 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0874) 0875 Gateways, architectures, and heffalumps. M.A. Padlipsky. September 1982. (Format: TXT=22816 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0875) 0876 Survey of SMTP implementations. D. Smallberg. September 1983. (Format: TXT=37775 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0876) 0877 Standard for the transmission of IP datagrams over public data networks. J.T. Korb. September 1983. (Format: TXT=3272 bytes) (Obsoleted by RFC1356) (Status: UNKNOWN) (DOI: 10.17487/RFC0877) 0878 ARPANET 1822L Host Access Protocol. A.G. Malis. December 1983. (Format: TXT=74774 bytes) (Obsoletes RFC0851) (Status: UNKNOWN) (DOI: 10.17487/RFC0878) 0879 The TCP Maximum Segment Size and Related Topics. J. Postel. November 1983. (Format: TXT=22024 bytes) (Obsoleted by RFC7805) (Updated by RFC6691) (Status: HISTORIC) (DOI: 10.17487/RFC0879) 0880 Official protocols. J.K. Reynolds, J. Postel. October 1983. (Format: TXT=37332 bytes) (Obsoletes RFC0840) (Obsoleted by RFC0901) (Status: HISTORIC) (DOI: 10.17487/RFC0880) 0881 Domain names plan and schedule. J. Postel. November 1983. (Format: TXT=23490 bytes) (Updated by RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0881) 0882 Domain names: Concepts and facilities. P.V. Mockapetris. November 1983. (Format: TXT=79776 bytes) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN) (DOI: 10.17487/RFC0882) 0883 Domain names: Implementation specification. P.V. Mockapetris. November 1983. (Format: TXT=175067 bytes) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN) (DOI: 10.17487/RFC0883) 0884 Telnet terminal type option. M. Solomon, E. Wimmers. December 1983. (Format: TXT=7881 bytes) (Obsoleted by RFC0930) (Status: UNKNOWN) (DOI: 10.17487/RFC0884) 0885 Telnet end of record option. J. Postel. December 1983. (Format: TXT=3232 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0885) 0886 Proposed standard for message header munging. M.T. Rose. December 1983. (Format: TXT=30566 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0886) 0887 Resource Location Protocol. M. Accetta. December 1983. (Format: TXT=36770 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0887) 0888 "STUB" Exterior Gateway Protocol. L. Seamonson, E.C. Rosen. January 1984. (Format: TXT=53227 bytes) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0888) 0889 Internet Delay Experiments. D.L. Mills. December 1983. (Format: TXT=27128 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0889) 0890 Exterior Gateway Protocol implementation schedule. J. Postel. February 1984. (Format: TXT=5899 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0890) 0891 DCN Local-Network Protocols. D.L. Mills. December 1983. (Format: TXT=65340 bytes) (Also STD0044) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0891) 0892 ISO Transport Protocol specification. International Organization for Standardization. December 1983. (Format: TXT=158151 bytes) (Obsoleted by RFC0905) (Status: UNKNOWN) (DOI: 10.17487/RFC0892) 0893 Trailer encapsulations. S. Leffler, M.J. Karels. April 1984. (Format: TXT=13353 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0893) 0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks. C. Hornig. April 1984. (Format: TXT=5697 bytes) (Also STD0041) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0894) 0895 Standard for the transmission of IP datagrams over experimental Ethernet networks. J. Postel. April 1984. (Format: TXT=4985 bytes) (Also STD0042) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0895) 0896 Congestion Control in IP/TCP Internetworks. J. Nagle. January 1984. (Format: TXT=26782 bytes) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0896) 0897 Domain name system implementation schedule. J. Postel. February 1984. (Format: TXT=15683 bytes) (Updates RFC0881) (Updated by RFC0921) (Status: UNKNOWN) (DOI: 10.17487/RFC0897) 0898 Gateway special interest group meeting notes. R.M. Hinden, J. Postel, M. Muuss, J.K. Reynolds. April 1984. (Format: TXT=42112 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0898) 0899 Request For Comments summary notes: 800-899. J. Postel, A. Westine. May 1984. (Format: TXT=39996 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0899) 0900 Assigned Numbers. J.K. Reynolds, J. Postel. June 1984. (Format: TXT=82116 bytes) (Obsoletes RFC0870) (Obsoleted by RFC0923) (Status: HISTORIC) (DOI: 10.17487/RFC0900) 0901 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. June 1984. (Format: TXT=41058 bytes) (Obsoletes RFC0880) (Obsoleted by RFC0924) (Status: UNKNOWN) (DOI: 10.17487/RFC0901) 0902 ARPA Internet Protocol policy. J.K. Reynolds, J. Postel. July 1984. (Format: TXT=11027 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0902) 0903 A Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. June 1984. (Format: TXT=9345 bytes) (Also STD0038) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0903) 0904 Exterior Gateway Protocol formal specification. D.L. Mills. April 1984. (Format: TXT=65226 bytes) (Updates RFC0827, RFC0888) (Status: HISTORIC) (DOI: 10.17487/RFC0904) 0905 ISO Transport Protocol specification ISO DP 8073. ISO. April 1984. (Format: TXT=249214 bytes) (Obsoletes RFC0892) (Status: UNKNOWN) (DOI: 10.17487/RFC0905) 0906 Bootstrap loading using TFTP. R. Finlayson. June 1984. (Format: TXT=10102 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0906) 0907 Host Access Protocol specification. Bolt Beranek and Newman Laboratories. July 1984. (Format: TXT=129985 bytes) (Updated by RFC1221) (Also STD0040) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0907) 0908 Reliable Data Protocol. D. Velten, R.M. Hinden, J. Sax. July 1984. (Format: TXT=97646 bytes) (Updated by RFC1151) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0908) 0909 Loader Debugger Protocol. C. Welles, W. Milliken. July 1984. (Format: TXT=209813 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0909) 0910 Multimedia mail meeting notes. H.C. Forsdick. August 1984. (Format: TXT=24915 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0910) 0911 EGP Gateway under Berkeley UNIX 4.2. P. Kirton. August 1984. (Format: TXT=55908 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0911) 0912 Authentication service. M. St. Johns. September 1984. (Format: TXT=4544 bytes) (Obsoleted by RFC0931) (Status: UNKNOWN) (DOI: 10.17487/RFC0912) 0913 Simple File Transfer Protocol. M. Lottor. September 1984. (Format: TXT=20929 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0913) 0914 Thinwire protocol for connecting personal computers to the Internet. D.J. Farber, G. Delp, T.M. Conte. September 1984. (Format: TXT=57288 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0914) 0915 Network mail path service. M.A. Elvy, R. Nedved. December 1984. (Format: TXT=21635 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0915) 0916 Reliable Asynchronous Transfer Protocol (RATP). G.G. Finn. October 1984. (Format: TXT=110737 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0916) 0917 Internet subnets. J.C. Mogul. October 1984. (Format: TXT=47072 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0917) 0918 Post Office Protocol. J.K. Reynolds. October 1984. (Format: TXT=9876 bytes) (Obsoleted by RFC0937) (Status: UNKNOWN) (DOI: 10.17487/RFC0918) 0919 Broadcasting Internet Datagrams. J.C. Mogul. October 1984. (Format: TXT=16382 bytes) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0919) 0920 Domain requirements. J. Postel, J.K. Reynolds. October 1984. (Format: TXT=27823 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0920) 0921 Domain name system implementation schedule - revised. J. Postel. October 1984. (Format: TXT=23318 bytes) (Updates RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0921) 0922 Broadcasting Internet datagrams in the presence of subnets. J.C. Mogul. October 1984. (Format: TXT=24147 bytes) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0922) 0923 Assigned numbers. J.K. Reynolds, J. Postel. October 1984. (Format: TXT=96467 bytes) (Obsoletes RFC0900) (Obsoleted by RFC0943) (Status: HISTORIC) (DOI: 10.17487/RFC0923) 0924 Official ARPA-Internet protocols for connecting personal computers to the Internet. J.K. Reynolds, J. Postel. October 1984. (Format: TXT=48513 bytes) (Obsoletes RFC0901) (Obsoleted by RFC0944) (Status: UNKNOWN) (DOI: 10.17487/RFC0924) 0925 Multi-LAN address resolution. J. Postel. October 1984. (Format: TXT=31137 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0925) 0926 Protocol for providing the connectionless mode network services. International Organization for Standardization. December 1984. (Format: TXT=165895 bytes) (Obsoleted by RFC0994) (Status: UNKNOWN) (DOI: 10.17487/RFC0926) 0927 TACACS user identification Telnet option. B.A. Anderson. December 1984. (Format: TXT=5474 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0927) 0928 Introduction to proposed DoD standard H-FP. M.A. Padlipsky. December 1984. (Format: TXT=60461 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0928) 0929 Proposed Host-Front End Protocol. J. Lilienkamp, R. Mandell, M.A. Padlipsky. December 1984. (Format: TXT=135042 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0929) 0930 Telnet terminal type option. M. Solomon, E. Wimmers. January 1985. (Format: TXT=6583 bytes) (Obsoletes RFC0884) (Obsoleted by RFC1091) (Status: UNKNOWN) (DOI: 10.17487/RFC0930) 0931 Authentication server. M. St. Johns. January 1985. (Format: TXT=8982 bytes) (Obsoletes RFC0912) (Obsoleted by RFC1413) (Status: UNKNOWN) (DOI: 10.17487/RFC0931) 0932 Subnetwork addressing scheme. D.D. Clark. January 1985. (Format: TXT=9283 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0932) 0933 Output marking Telnet option. S. Silverman. January 1985. (Format: TXT=6715 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0933) 0934 Proposed standard for message encapsulation. M.T. Rose, E.A. Stefferud. January 1985. (Format: TXT=21770 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0934) 0935 Reliable link layer protocols. J.G. Robinson. January 1985. (Format: TXT=31625 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0935) 0936 Another Internet subnet addressing scheme. M.J. Karels. February 1985. (Format: TXT=10179 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0936) 0937 Post Office Protocol: Version 2. M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds. February 1985. (Format: TXT=42370 bytes) (Obsoletes RFC0918) (Status: HISTORIC) (DOI: 10.17487/RFC0937) 0938 Internet Reliable Transaction Protocol functional and interface specification. T. Miller. February 1985. (Format: TXT=39478 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0938) 0939 Executive summary of the NRC report on transport protocols for Department of Defense data networks. National Research Council. February 1985. (Format: TXT=42345 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0939) 0940 Toward an Internet standard scheme for subnetting. Gateway Algorithms and Data Structures Task Force. April 1985. (Format: TXT=6881 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0940) 0941 Addendum to the network service definition covering network layer addressing. International Organization for Standardization. April 1985. (Format: TXT=68733 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0941) 0942 Transport protocols for Department of Defense data networks. National Research Council. February 1985. (Format: TXT=217284 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0942) 0943 Assigned numbers. J.K. Reynolds, J. Postel. April 1985. (Format: TXT=105234 bytes) (Obsoletes RFC0923) (Obsoleted by RFC0960) (Status: HISTORIC) (DOI: 10.17487/RFC0943) 0944 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. April 1985. (Format: TXT=61373 bytes) (Obsoletes RFC0924) (Obsoleted by RFC0961) (Status: UNKNOWN) (DOI: 10.17487/RFC0944) 0945 DoD statement on the NRC report. J. Postel. May 1985. (Format: TXT=5017 bytes) (Obsoleted by RFC1039) (Status: UNKNOWN) (DOI: 10.17487/RFC0945) 0946 Telnet terminal location number option. R. Nedved. May 1985. (Format: TXT=6285 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0946) 0947 Multi-network broadcasting within the Internet. K. Lebowitz, D. Mankins. June 1985. (Format: TXT=12569 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0947) 0948 Two methods for the transmission of IP datagrams over IEEE 802.3 networks. I. Winston. June 1985. (Format: TXT=11495 bytes) (Obsoleted by RFC1042) (Status: UNKNOWN) (DOI: 10.17487/RFC0948) 0949 FTP unique-named store command. M.A. Padlipsky. July 1985. (Format: TXT=4017 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0949) 0950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. August 1985. (Format: TXT=37985 bytes) (Updates RFC0792) (Updated by RFC6918) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0950) 0951 Bootstrap Protocol. W.J. Croft, J. Gilmore. September 1985. (Format: TXT=28354 bytes) (Updated by RFC1395, RFC1497, RFC1532, RFC1542, RFC5494) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC0951) 0952 DoD Internet host table specification. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT=12388 bytes) (Obsoletes RFC0810) (Updated by RFC1123) (Status: UNKNOWN) (DOI: 10.17487/RFC0952) 0953 Hostname Server. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT=8305 bytes) (Obsoletes RFC0811) (Status: HISTORIC) (DOI: 10.17487/RFC0953) 0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC0954) 0955 Towards a transport service for transaction processing applications. R.T. Braden. September 1985. (Format: TXT=22497 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0955) 0956 Algorithms for synchronizing network clocks. D.L. Mills. September 1985. (Format: TXT=67387 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0956) 0957 Experiments in network clock synchronization. D.L. Mills. September 1985. (Format: TXT=68952 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0957) 0958 Network Time Protocol (NTP). D.L. Mills. September 1985. (Format: TXT=30723 bytes) (Obsoleted by RFC1059, RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC0958) 0959 File Transfer Protocol. J. Postel, J. Reynolds. October 1985. (Format: TXT=147316 bytes) (Obsoletes RFC0765) (Updated by RFC2228, RFC2640, RFC2773, RFC3659, RFC5797, RFC7151) (Also STD0009) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0959) 0960 Assigned numbers. J.K. Reynolds, J. Postel. December 1985. (Format: TXT=125814 bytes) (Obsoletes RFC0943) (Obsoleted by RFC0990) (Status: HISTORIC) (DOI: 10.17487/RFC0960) 0961 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. December 1985. (Format: TXT=52672 bytes) (Obsoletes RFC0944) (Obsoleted by RFC0991) (Status: UNKNOWN) (DOI: 10.17487/RFC0961) 0962 TCP-4 prime. M.A. Padlipsky. November 1985. (Format: TXT=2773 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0962) 0963 Some problems with the specification of the Military Standard Internet Protocol. D.P. Sidhu. November 1985. (Format: TXT=44019 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0963) 0964 Some problems with the specification of the Military Standard Transmission Control Protocol. D.P. Sidhu, T. Blumer. November 1985. (Format: TXT=20972 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0964) 0965 Format for a graphical communication protocol. L. Aguilar. December 1985. (Format: TXT=105456 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0965) 0966 Host groups: A multicast extension to the Internet Protocol. S.E. Deering, D.R. Cheriton. December 1985. (Format: TXT=59469 bytes) (Obsoleted by RFC0988) (Status: UNKNOWN) (DOI: 10.17487/RFC0966) 0967 All victims together. M.A. Padlipsky. December 1985. (Format: TXT=4706 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0967) 0968 Twas the night before start-up. V.G. Cerf. December 1985. (Format: TXT=2459 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0968) 0969 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, L. Zhang. December 1985. (Format: TXT=40040 bytes) (Obsoleted by RFC0998) (Status: UNKNOWN) (DOI: 10.17487/RFC0969) 0970 On Packet Switches With Infinite Storage. J. Nagle. December 1985. (Format: TXT=35316 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0970) 0971 Survey of data representation standards. A.L. DeSchon. January 1986. (Format: TXT=22883 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0971) 0972 Password Generator Protocol. F.J. Wancho. January 1986. (Format: TXT=3890 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0972) 0973 Domain system changes and observations. P.V. Mockapetris. January 1986. (Format: TXT=22364 bytes) (Obsoleted by RFC1034, RFC1035) (Updates RFC0882, RFC0883) (Status: UNKNOWN) (DOI: 10.17487/RFC0973) 0974 Mail routing and the domain system. C. Partridge. January 1986. (Format: TXT=18581 bytes) (Obsoleted by RFC2821) (Also STD0010) (Status: HISTORIC) (DOI: 10.17487/RFC0974) 0975 Autonomous confederations. D.L. Mills. February 1986. (Format: TXT=28010 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0975) 0976 UUCP mail interchange format standard. M.R. Horton. February 1986. (Format: TXT=26814 bytes) (Updated by RFC1137) (Status: UNKNOWN) (DOI: 10.17487/RFC0976) 0977 Network News Transfer Protocol. B. Kantor, P. Lapsley. February 1986. (Format: TXT=55062 bytes) (Obsoleted by RFC3977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0977) 0978 Voice File Interchange Protocol (VFIP). J.K. Reynolds, R. Gillman, W.A. Brackenridge, A. Witkowski, J. Postel. February 1986. (Format: TXT=9223 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0978) 0979 PSN End-to-End functional specification. A.G. Malis. March 1986. (Format: TXT=39472 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0979) 0980 Protocol document order information. O.J. Jacobsen, J. Postel. March 1986. (Format: TXT=24416 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0980) 0981 Experimental multiple-path routing algorithm. D.L. Mills. March 1986. (Format: TXT=59069 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0981) 0982 Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address. H.W. Braun. April 1986. (Format: TXT=22595 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0982) 0983 ISO transport arrives on top of the TCP. D.E. Cass, M.T. Rose. April 1986. (Format: TXT=59819 bytes) (Obsoleted by RFC1006) (Status: UNKNOWN) (DOI: 10.17487/RFC0983) 0984 PCMAIL: A distributed mail system for personal computers. D.D. Clark, M.L. Lambert. May 1986. (Format: TXT=69333 bytes) (Obsoleted by RFC0993) (Status: UNKNOWN) (DOI: 10.17487/RFC0984) 0985 Requirements for Internet gateways - draft. National Science Foundation, Network Technical Advisory Group. May 1986. (Format: TXT=59221 bytes) (Obsoleted by RFC1009) (Status: UNKNOWN) (DOI: 10.17487/RFC0985) 0986 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol. R.W. Callon, H.W. Braun. June 1986. (Format: TXT=13950 bytes) (Obsoleted by RFC1069) (Status: UNKNOWN) (DOI: 10.17487/RFC0986) 0987 Mapping between X.400 and RFC 822. S.E. Kille. June 1986. (Format: TXT=127540 bytes) (Obsoleted by RFC2156, RFC1327) (Updated by RFC1026, RFC1138, RFC1148) (Status: UNKNOWN) (DOI: 10.17487/RFC0987) 0988 Host extensions for IP multicasting. S.E. Deering. July 1986. (Format: TXT=45220 bytes) (Obsoletes RFC0966) (Obsoleted by RFC1054, RFC1112) (Status: UNKNOWN) (DOI: 10.17487/RFC0988) 0989 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures. J. Linn. February 1987. (Format: TXT=63934 bytes) (Obsoleted by RFC1040, RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC0989) 0990 Assigned numbers. J.K. Reynolds, J. Postel. November 1986. (Format: TXT=174784 bytes) (Obsoletes RFC0960) (Obsoleted by RFC1010) (Updated by RFC0997) (Status: HISTORIC) (DOI: 10.17487/RFC0990) 0991 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. November 1986. (Format: TXT=65205 bytes) (Obsoletes RFC0961) (Obsoleted by RFC1011) (Status: UNKNOWN) (DOI: 10.17487/RFC0991) 0992 On communication support for fault tolerant process groups. K.P. Birman, T.A. Joseph. November 1986. (Format: TXT=52313 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0992) 0993 PCMAIL: A distributed mail system for personal computers. D.D. Clark, M.L. Lambert. December 1986. (Format: TXT=71725 bytes) (Obsoletes RFC0984) (Obsoleted by RFC1056) (Status: UNKNOWN) (DOI: 10.17487/RFC0993) 0994 Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service. International Organization for Standardization. March 1986. (Format: TXT=129006 bytes) (Obsoletes RFC0926) (Status: UNKNOWN) (DOI: 10.17487/RFC0994) 0995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473. International Organization for Standardization. April 1986. (Format: TXT=94069 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC0995) 0996 Statistics server. D.L. Mills. February 1987. (Format: TXT=6127 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC0996) 0997 Internet numbers. J.K. Reynolds, J. Postel. March 1987. (Format: TXT=123919 bytes) (Obsoleted by RFC1020, RFC1117) (Updates RFC0990) (Status: UNKNOWN) (DOI: 10.17487/RFC0997) 0998 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, L. Zhang. March 1987. (Format: TXT=57147 bytes) (Obsoletes RFC0969) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0998) 0999 Requests For Comments summary notes: 900-999. A. Westine, J. Postel. April 1987. (Format: TXT=62877 bytes) (Obsoletes RFC0160) (Obsoleted by RFC1000) (Status: UNKNOWN) (DOI: 10.17487/RFC0999) 1000 Request For Comments reference guide. J.K. Reynolds, J. Postel. August 1987. (Format: TXT=323960 bytes) (Obsoletes RFC0999) (Status: UNKNOWN) (DOI: 10.17487/RFC1000) 1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods. NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. March 1987. (Format: TXT=158437 bytes) (Also STD0019) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1001) 1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications. NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. March 1987. (Format: TXT=170262 bytes) (Also STD0019) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1002) 1003 Issues in defining an equations representation standard. A.R. Katz. March 1987. (Format: TXT=19816 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1003) 1004 Distributed-protocol authentication scheme. D.L. Mills. April 1987. (Format: TXT=21402 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1004) 1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP). A. Khanna, A.G. Malis. May 1987. (Format: TXT=69957 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1005) 1006 ISO Transport Service on top of the TCP Version: 3. M.T. Rose, D.E. Cass. May 1987. (Format: TXT=30662 bytes) (Obsoletes RFC0983) (Updated by RFC2126) (Also STD0035) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1006) 1007 Military supplement to the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT=51280 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1007) 1008 Implementation guide for the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT=204664 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1008) 1009 Requirements for Internet gateways. R.T. Braden, J. Postel. June 1987. (Format: TXT=128173 bytes) (Obsoletes RFC0985) (Obsoleted by RFC1812) (Status: HISTORIC) (DOI: 10.17487/RFC1009) 1010 Assigned numbers. J.K. Reynolds, J. Postel. May 1987. (Format: TXT=78179 bytes) (Obsoletes RFC0990) (Obsoleted by RFC1060) (Status: HISTORIC) (DOI: 10.17487/RFC1010) 1011 Official Internet protocols. J.K. Reynolds, J. Postel. May 1987. (Format: TXT=74593 bytes) (Obsoletes RFC0991) (Updated by RFC6093) (Status: UNKNOWN) (DOI: 10.17487/RFC1011) 1012 Bibliography of Request For Comments 1 through 999. J.K. Reynolds, J. Postel. June 1987. (Format: TXT=129194 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1012) 1013 X Window System Protocol, version 11: Alpha update April 1987. R.W. Scheifler. June 1987. (Format: TXT=244905 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1013) 1014 XDR: External Data Representation standard. Sun Microsystems. June 1987. (Format: TXT=39316 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1014) 1015 Implementation plan for interagency research Internet. B.M. Leiner. July 1987. (Format: TXT=63159 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1015) 1016 Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID). W. Prue, J. Postel. July 1987. (Format: TXT=47922 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1016) 1017 Network requirements for scientific research: Internet task force on scientific computing. B.M. Leiner. August 1987. (Format: TXT=49512 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1017) 1018 Some comments on SQuID. A.M. McKenzie. August 1987. (Format: TXT=7931 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1018) 1019 Report of the Workshop on Environments for Computational Mathematics. D. Arnon. September 1987. (Format: TXT=21151 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1019) 1020 Internet numbers. S. Romano, M.K. Stahl. November 1987. (Format: TXT=146864 bytes) (Obsoletes RFC0997) (Obsoleted by RFC1062, RFC1117, RFC1166) (Status: UNKNOWN) (DOI: 10.17487/RFC1020) 1021 High-level Entity Management System (HEMS). C. Partridge, G. Trewitt. October 1987. (Format: TXT=12993 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1021) 1022 High-level Entity Management Protocol (HEMP). C. Partridge, G. Trewitt. October 1987. (Format: TXT=25348 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1022) 1023 HEMS monitoring and control language. G. Trewitt, C. Partridge. October 1987. (Format: TXT=40992 bytes) (Obsoleted by RFC1076) (Status: UNKNOWN) (DOI: 10.17487/RFC1023) 1024 HEMS variable definitions. C. Partridge, G. Trewitt. October 1987. (Format: TXT=126536 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1024) 1025 TCP and IP bake off. J. Postel. September 1987. (Format: TXT=11648 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1025) 1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822). S.E. Kille. September 1987. (Format: TXT=7117 bytes) (Obsoleted by RFC2156, RFC1327) (Updates RFC0987) (Updated by RFC1138, RFC1148) (Status: UNKNOWN) (DOI: 10.17487/RFC1026) 1027 Using ARP to implement transparent subnet gateways. S. Carl-Mitchell, J.S. Quarterman. October 1987. (Format: TXT=21297 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1027) 1028 Simple Gateway Monitoring Protocol. J. Davin, J.D. Case, M. Fedor, M.L. Schoffstall. November 1987. (Format: TXT=82440 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1028) 1029 More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets. G. Parr. May 1988. (Format: TXT=44019 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1029) 1030 On testing the NETBLT Protocol over divers networks. M.L. Lambert. November 1987. (Format: TXT=40964 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1030) 1031 MILNET name domain transition. W.D. Lazear. November 1987. (Format: TXT=20137 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1031) 1032 Domain administrators guide. M.K. Stahl. November 1987. (Format: TXT=29454 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1032) 1033 Domain Administrators Operations Guide. M. Lottor. November 1987. (Format: TXT=37263 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1033) 1034 Domain names - concepts and facilities. P.V. Mockapetris. November 1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4343, RFC4035, RFC4592, RFC5936, RFC8020) (Also STD0013) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1034) 1035 Domain names - implementation and specification. P.V. Mockapetris. November 1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2673, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035, RFC4343, RFC5936, RFC5966, RFC6604, RFC7766) (Also STD0013) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1035) 1036 Standard for interchange of USENET messages. M.R. Horton, R. Adams. December 1987. (Format: TXT=46891 bytes) (Obsoletes RFC0850) (Obsoleted by RFC5536, RFC5537) (Status: UNKNOWN) (DOI: 10.17487/RFC1036) 1037 NFILE - a file access protocol. B. Greenberg, S. Keene. December 1987. (Format: TXT=197312 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1037) 1038 Draft revised IP security option. M. St. Johns. January 1988. (Format: TXT=15879 bytes) (Obsoleted by RFC1108) (Status: UNKNOWN) (DOI: 10.17487/RFC1038) 1039 DoD statement on Open Systems Interconnection protocols. D. Latham. January 1988. (Format: TXT=6194 bytes) (Obsoletes RFC0945) (Status: UNKNOWN) (DOI: 10.17487/RFC1039) 1040 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures. J. Linn. January 1988. (Format: TXT=76276 bytes) (Obsoletes RFC0989) (Obsoleted by RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC1040) 1041 Telnet 3270 regime option. Y. Rekhter. January 1988. (Format: TXT=11608 bytes) (Updated by RFC6270) (Status: HISTORIC) (DOI: 10.17487/RFC1041) 1042 Standard for the transmission of IP datagrams over IEEE 802 networks. J. Postel, J.K. Reynolds. February 1988. (Format: TXT=34359 bytes) (Obsoletes RFC0948) (Also STD0043) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1042) 1043 Telnet Data Entry Terminal option: DODIIS implementation. A. Yasuda, T. Thompson. February 1988. (Format: TXT=59478 bytes) (Updates RFC0732) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1043) 1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification. K. Hardwick, J. Lekashman. February 1988. (Format: TXT=100836 bytes) (Updated by RFC5494) (Also STD0045) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1044) 1045 VMTP: Versatile Message Transaction Protocol: Protocol specification. D.R. Cheriton. February 1988. (Format: TXT=272058 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1045) 1046 Queuing algorithm to provide type-of-service for IP links. W. Prue, J. Postel. February 1988. (Format: TXT=30106 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1046) 1047 Duplicate messages and SMTP. C. Partridge. February 1988. (Format: TXT=5888 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1047) 1048 BOOTP vendor information extensions. P.A. Prindeville. February 1988. (Format: TXT=15423 bytes) (Obsoleted by RFC1084, RFC1395, RFC1497, RFC1533) (Status: UNKNOWN) (DOI: 10.17487/RFC1048) 1049 Content-type header field for Internet messages. M.A. Sirbu. March 1988. (Format: TXT=18923 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1049) 1050 RPC: Remote Procedure Call Protocol specification. Sun Microsystems. April 1988. (Format: TXT=51540 bytes) (Obsoleted by RFC1057) (Status: HISTORIC) (DOI: 10.17487/RFC1050) 1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks. P.A. Prindeville. March 1988. (Format: TXT=7779 bytes) (Obsoleted by RFC1201) (Status: HISTORIC) (DOI: 10.17487/RFC1051) 1052 IAB recommendations for the development of Internet network management standards. V.G. Cerf. April 1988. (Format: TXT=30569 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1052) 1053 Telnet X.3 PAD option. S. Levy, T. Jacobson. April 1988. (Format: TXT=48952 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1053) 1054 Host extensions for IP multicasting. S.E. Deering. May 1988. (Format: TXT=45465 bytes) (Obsoletes RFC0988) (Obsoleted by RFC1112) (Status: UNKNOWN) (DOI: 10.17487/RFC1054) 1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP. J.L. Romkey. June 1988. (Format: TXT=12578 bytes) (Also STD0047) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1055) 1056 PCMAIL: A distributed mail system for personal computers. M.L. Lambert. June 1988. (Format: TXT=85368 bytes) (Obsoletes RFC0993) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1056) 1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun Microsystems. June 1988. (Format: TXT=52462 bytes) (Obsoletes RFC1050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1057) 1058 Routing Information Protocol. C.L. Hedrick. June 1988. (Format: TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Status: HISTORIC) (DOI: 10.17487/RFC1058) 1059 Network Time Protocol (version 1) specification and implementation. D.L. Mills. July 1988. (Format: TXT=140890 bytes) (Obsoletes RFC0958) (Obsoleted by RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC1059) 1060 Assigned numbers. J.K. Reynolds, J. Postel. March 1990. (Format: TXT=177923 bytes) (Obsoletes RFC1010) (Obsoleted by RFC1340) (Updated by RFC1349) (Status: HISTORIC) (DOI: 10.17487/RFC1060) 1061 Not Issued. 1062 Internet numbers. S. Romano, M.K. Stahl, M. Recker. August 1988. (Format: TXT=198729 bytes) (Obsoletes RFC1020) (Obsoleted by RFC1117, RFC1166) (Status: UNKNOWN) (DOI: 10.17487/RFC1062) 1063 IP MTU discovery options. J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie. July 1988. (Format: TXT=27121 bytes) (Obsoleted by RFC1191) (Status: UNKNOWN) (DOI: 10.17487/RFC1063) 1064 Interactive Mail Access Protocol: Version 2. M.R. Crispin. July 1988. (Format: TXT=57813 bytes) (Obsoleted by RFC1176, RFC1203) (Status: UNKNOWN) (DOI: 10.17487/RFC1064) 1065 Structure and identification of management information for TCP/IP-based internets. K. McCloghrie, M.T. Rose. August 1988. (Format: TXT=38858 bytes) (Obsoleted by RFC1155) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1065) 1066 Management Information Base for network management of TCP/IP-based internets. K. McCloghrie, M.T. Rose. August 1988. (Format: TXT=135177 bytes) (Obsoleted by RFC1156) (Status: UNKNOWN) (DOI: 10.17487/RFC1066) 1067 Simple Network Management Protocol. J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. August 1988. (Format: TXT=69592 bytes) (Obsoleted by RFC1098) (Status: UNKNOWN) (DOI: 10.17487/RFC1067) 1068 Background File Transfer Program (BFTP). A.L. DeSchon, R.T. Braden. August 1988. (Format: TXT=51004 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1068) 1069 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol. R.W. Callon, H.W. Braun. February 1989. (Format: TXT=24268 bytes) (Obsoletes RFC0986) (Status: UNKNOWN) (DOI: 10.17487/RFC1069) 1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer. R.A. Hagens, N.E. Hall, M.T. Rose. February 1989. (Format: TXT=37354 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1070) 1071 Computing the Internet checksum. R.T. Braden, D.A. Borman, C. Partridge. September 1988. (Format: TXT=54941 bytes) (Updated by RFC1141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1071) 1072 TCP extensions for long-delay paths. V. Jacobson, R.T. Braden. October 1988. (Format: TXT=36000 bytes) (Obsoleted by RFC1323, RFC2018, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1072) 1073 Telnet window size option. D. Waitzman. October 1988. (Format: TXT=7639 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1073) 1074 NSFNET backbone SPF based Interior Gateway Protocol. J. Rekhter. October 1988. (Format: TXT=10872 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1074) 1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. November 1988. (Format: TXT=54731 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1075) 1076 HEMS monitoring and control language. G. Trewitt, C. Partridge. November 1988. (Format: TXT=98774 bytes) (Obsoletes RFC1023) (Status: UNKNOWN) (DOI: 10.17487/RFC1076) 1077 Critical issues in high bandwidth networking. B.M. Leiner. November 1988. (Format: TXT=116464 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1077) 1078 TCP port service Multiplexer (TCPMUX). M. Lottor. November 1988. (Format: TXT=3248 bytes) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC1078) 1079 Telnet terminal speed option. C.L. Hedrick. December 1988. (Format: TXT=4942 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1079) 1080 Telnet remote flow control option. C.L. Hedrick. November 1988. (Format: TXT=6688 bytes) (Obsoleted by RFC1372) (Status: UNKNOWN) (DOI: 10.17487/RFC1080) 1081 Post Office Protocol: Version 3. M.T. Rose. November 1988. (Format: TXT=37009 bytes) (Obsoleted by RFC1225) (Status: UNKNOWN) (DOI: 10.17487/RFC1081) 1082 Post Office Protocol: Version 3: Extended service offerings. M.T. Rose. November 1988. (Format: TXT=25423 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1082) 1083 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. December 1988. (Format: TXT=27128 bytes) (Obsoleted by RFC1100) (Status: HISTORIC) (DOI: 10.17487/RFC1083) 1084 BOOTP vendor information extensions. J.K. Reynolds. December 1988. (Format: TXT=16327 bytes) (Obsoletes RFC1048) (Obsoleted by RFC1395, RFC1497, RFC1533) (Status: UNKNOWN) (DOI: 10.17487/RFC1084) 1085 ISO presentation services on top of TCP/IP based internets. M.T. Rose. December 1988. (Format: TXT=64643 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1085) 1086 ISO-TP0 bridge between TCP and X.25. J.P. Onions, M.T. Rose. December 1988. (Format: TXT=19934 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1086) 1087 Ethics and the Internet. Defense Advanced Research Projects Agency, Internet Activities Board. January 1989. (Format: TXT=4582 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1087) 1088 Standard for the transmission of IP datagrams over NetBIOS networks. L.J. McLaughlin. February 1989. (Format: TXT=5579 bytes) (Also STD0048) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1088) 1089 SNMP over Ethernet. M. Schoffstall, C. Davin, M. Fedor, J. Case. February 1989. (Format: TXT=4458 bytes) (Obsoleted by RFC4789) (Status: UNKNOWN) (DOI: 10.17487/RFC1089) 1090 SMTP on X.25. R. Ullmann. February 1989. (Format: TXT=6141 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1090) 1091 Telnet terminal-type option. J. VanBokkelen. February 1989. (Format: TXT=13439 bytes) (Obsoletes RFC0930) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1091) 1092 EGP and policy based routing in the new NSFNET backbone. J. Rekhter. February 1989. (Format: TXT=11865 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1092) 1093 NSFNET routing architecture. H.W. Braun. February 1989. (Format: TXT=20629 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1093) 1094 NFS: Network File System Protocol specification. B. Nowicki. March 1989. (Format: TXT=51454 bytes) (Also RFC1813) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1094) 1095 Common Management Information Services and Protocol over TCP/IP (CMOT). U.S. Warrier, L. Besaw. April 1989. (Format: TXT=157506 bytes) (Obsoleted by RFC1189) (Status: UNKNOWN) (DOI: 10.17487/RFC1095) 1096 Telnet X display location option. G.A. Marcy. March 1989. (Format: TXT=4634 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1096) 1097 Telnet subliminal-message option. B. Miller. April 1989. (Format: TXT=5490 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1097) 1098 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. April 1989. (Format: TXT=71563 bytes) (Obsoletes RFC1067) (Obsoleted by RFC1157) (Status: UNKNOWN) (DOI: 10.17487/RFC1098) 1099 Request for Comments Summary: RFC Numbers 1000-1099. J. Reynolds. December 1991. (Format: TXT=49108 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1099) 1100 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1989. (Format: TXT=30101 bytes) (Obsoletes RFC1083) (Obsoleted by RFC1130) (Status: HISTORIC) (DOI: 10.17487/RFC1100) 1101 DNS encoding of network names and other types. P.V. Mockapetris. April 1989. (Format: TXT=28677 bytes) (Updates RFC1034, RFC1035) (Status: UNKNOWN) (DOI: 10.17487/RFC1101) 1102 Policy routing in Internet protocols. D.D. Clark. May 1989. (Format: TXT=59664 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1102) 1103 Proposed standard for the transmission of IP datagrams over FDDI Networks. D. Katz. June 1989. (Format: TXT=19439 bytes) (Obsoleted by RFC1188) (Status: UNKNOWN) (DOI: 10.17487/RFC1103) 1104 Models of policy based routing. H.W. Braun. June 1989. (Format: TXT=25468 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1104) 1105 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1989. (Format: TXT=37644 bytes) (Obsoleted by RFC1163) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1105) 1106 TCP big window and NAK options. R. Fox. June 1989. (Format: TXT=37105 bytes) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1106) 1107 Plan for Internet directory services. K.R. Sollins. July 1989. (Format: TXT=51773 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1107) 1108 U.S. Department of Defense Security Options for the Internet Protocol. S. Kent. November 1991. (Format: TXT=41791 bytes) (Obsoletes RFC1038) (Status: HISTORIC) (DOI: 10.17487/RFC1108) 1109 Report of the second Ad Hoc Network Management Review Group. V.G. Cerf. August 1989. (Format: TXT=20642 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1109) 1110 Problem with the TCP big window option. A.M. McKenzie. August 1989. (Format: TXT=5778 bytes) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1110) 1111 Request for comments on Request for Comments: Instructions to RFC authors. J. Postel. August 1989. (Format: TXT=11793 bytes) (Obsoletes RFC0825) (Obsoleted by RFC1543, RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1111) 1112 Host extensions for IP multicasting. S.E. Deering. August 1989. (Format: TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1112) 1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures. J. Linn. August 1989. (Format: TXT=89293 bytes) (Obsoletes RFC0989, RFC1040) (Obsoleted by RFC1421) (Status: HISTORIC) (DOI: 10.17487/RFC1113) 1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management. S.T. Kent, J. Linn. August 1989. (Format: TXT=69661 bytes) (Obsoleted by RFC1422) (Status: HISTORIC) (DOI: 10.17487/RFC1114) 1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers. J. Linn. August 1989. (Format: TXT=18226 bytes) (Obsoleted by RFC1423) (Status: HISTORIC) (DOI: 10.17487/RFC1115) 1116 Telnet Linemode option. D.A. Borman. August 1989. (Format: TXT=47473 bytes) (Obsoleted by RFC1184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1116) 1117 Internet numbers. S. Romano, M.K. Stahl, M. Recker. August 1989. (Format: TXT=324666 bytes) (Obsoletes RFC1062, RFC1020, RFC0997) (Obsoleted by RFC1166) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1117) 1118 Hitchhikers guide to the Internet. E. Krol. September 1989. (Format: TXT=62757 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1118) 1119 Network Time Protocol (version 2) specification and implementation. D.L. Mills. September 1989. (Format: TXT=143, PS=518020, PDF=187940 bytes) (Obsoletes RFC0958, RFC1059) (Obsoleted by RFC1305) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1119) 1120 Internet Activities Board. V. Cerf. September 1989. (Format: TXT=26123 bytes) (Obsoleted by RFC1160) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1120) 1121 Act one - the poems. J. Postel, L. Kleinrock, V.G. Cerf, B. Boehm. September 1989. (Format: TXT=10644 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1121) 1122 Requirements for Internet Hosts - Communication Layers. R. Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updates RFC0793) (Updated by RFC1349, RFC4379, RFC5884, RFC6093, RFC6298, RFC6633, RFC6864) (Also STD0003) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1122) 1123 Requirements for Internet Hosts - Application and Support. R. Braden, Ed.. October 1989. (Format: TXT=245503 bytes) (Updates RFC0822, RFC0952) (Updated by RFC1349, RFC2181, RFC5321, RFC5966, RFC7766) (Also STD0003) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1123) 1124 Policy issues in interconnecting networks. B.M. Leiner. September 1989. (Format: TXT=118, PS=315692, PDF=143819 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1124) 1125 Policy requirements for inter Administrative Domain routing. D. Estrin. November 1989. (Format: TXT=55248, PS=282123, PDF=289862 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1125) 1126 Goals and functional requirements for inter-autonomous system routing. M. Little. October 1989. (Format: TXT=62725 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1126) 1127 Perspective on the Host Requirements RFCs. R.T. Braden. October 1989. (Format: TXT=41267 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1127) 1128 Measured performance of the Network Time Protocol in the Internet system. D.L. Mills. October 1989. (Format: TXT=314, PS=633742, PDF=197897 bytes) (Status: UNKNOWN) (DOI: 10.17487/RFC1128) 1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. October 1989. (Format: TXT=298, PS=551697, PDF=197036 bytes) (Also RFC1119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1129) 1130 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. October 1989. (Format: TXT=33858 bytes) (Obsoletes RFC1100) (Obsoleted by RFC1140) (Status: HISTORIC) (DOI: 10.17487/RFC1130) 1131 OSPF specification. J. Moy. October 1989. (Format: TXT=268, PS=2293049, PDF=685585 bytes) (Obsoleted by RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1131) 1132 Standard for the transmission of 802.2 packets over IPX networks. L.J. McLaughlin. November 1989. (Format: TXT=7902 bytes) (Also STD0049) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1132) 1133 Routing between the NSFNET and the DDN. J.Y. Yu, H.W. Braun. November 1989. (Format: TXT=23169 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1133) 1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links. D. Perkins. November 1989. (Format: TXT=87352 bytes) (Obsoleted by RFC1171) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1134) 1135 Helminthiasis of the Internet. J.K. Reynolds. December 1989. (Format: TXT=77033 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1135) 1136 Administrative Domains and Routing Domains: A model for routing in the Internet. S. Hares, D. Katz. December 1989. (Format: TXT=22158 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1136) 1137 Mapping between full RFC 822 and RFC 822 with restricted encoding. S. Kille. December 1989. (Format: TXT=6266 bytes) (Updates RFC0976) (Status: HISTORIC) (DOI: 10.17487/RFC1137) 1138 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. December 1989. (Format: TXT=191029 bytes) (Obsoleted by RFC2156, RFC1327) (Updates RFC1026, RFC0987, RFC0822) (Updated by RFC1148) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1138) 1139 Echo function for ISO 8473. R.A. Hagens. January 1990. (Format: TXT=14229 bytes) (Obsoleted by RFC1574, RFC1575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1139) 1140 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. May 1990. (Format: TXT=60501 bytes) (Obsoletes RFC1130) (Obsoleted by RFC1200) (Status: HISTORIC) (DOI: 10.17487/RFC1140) 1141 Incremental updating of the Internet checksum. T. Mallory, A. Kullberg. January 1990. (Format: TXT=3587 bytes) (Updates RFC1071) (Updated by RFC1624) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1141) 1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran, Ed.. February 1990. (Format: TXT=425379, PS=1440951, PDF=490300 bytes) (Obsoleted by RFC7142) (Status: HISTORIC) (DOI: 10.17487/RFC1142) 1143 The Q Method of Implementing TELNET Option Negotiation. D.J. Bernstein. February 1990. (Format: TXT=23331 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1143) 1144 Compressing TCP/IP Headers for Low-Speed Serial Links. V. Jacobson. February 1990. (Format: TXT=120959, PS=534729, PDF=255616 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1144) 1145 TCP alternate checksum options. J. Zweig, C. Partridge. February 1990. (Format: TXT=11052 bytes) (Obsoleted by RFC1146, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1145) 1146 TCP alternate checksum options. J. Zweig, C. Partridge. March 1990. (Format: TXT=10955 bytes) (Obsoletes RFC1145) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1146) 1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices. R.H. Stine. April 1990. (Format: TXT=336906, PS=555225, PDF=308602 bytes) (Obsoleted by RFC1470) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1147) 1148 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. March 1990. (Format: TXT=194292 bytes) (Obsoleted by RFC2156, RFC1327) (Updates RFC1026, RFC0987, RFC1138, RFC0822) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1148) 1149 Standard for the transmission of IP datagrams on avian carriers. D. Waitzman. April 1990. (Format: TXT=3329 bytes) (Updated by RFC2549, RFC6214) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1149) 1150 FYI on FYI: Introduction to the FYI Notes. G.S. Malkin, J.K. Reynolds. March 1990. (Format: TXT=7867 bytes) (Obsoleted by RFC6360) (Status: HISTORIC) (DOI: 10.17487/RFC1150) 1151 Version 2 of the Reliable Data Protocol (RDP). C. Partridge, R.M. Hinden. April 1990. (Format: TXT=8293 bytes) (Updates RFC0908) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1151) 1152 Workshop report: Internet research steering group workshop on very-high-speed networks. C. Partridge. April 1990. (Format: TXT=64003 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1152) 1153 Digest message format. F.J. Wancho. April 1990. (Format: TXT=6632 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1153) 1154 Encoding header field for internet messages. D. Robinson, R. Ullmann. April 1990. (Format: TXT=12214 bytes) (Obsoleted by RFC1505) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1154) 1155 Structure and identification of management information for TCP/IP-based internets. M.T. Rose, K. McCloghrie. May 1990. (Format: TXT=40927 bytes) (Obsoletes RFC1065) (Also STD0016) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1155) 1156 Management Information Base for network management of TCP/IP-based internets. K. McCloghrie, M.T. Rose. May 1990. (Format: TXT=138781 bytes) (Obsoletes RFC1066) (Status: HISTORIC) (DOI: 10.17487/RFC1156) 1157 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. May 1990. (Format: TXT=74894 bytes) (Obsoletes RFC1098) (Status: HISTORIC) (DOI: 10.17487/RFC1157) 1158 Management Information Base for network management of TCP/IP-based internets: MIB-II. M.T. Rose. May 1990. (Format: TXT=212152 bytes) (Obsoleted by RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1158) 1159 Message Send Protocol. R. Nelson. June 1990. (Format: TXT=3957 bytes) (Obsoleted by RFC1312) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1159) 1160 Internet Activities Board. V. Cerf. May 1990. (Format: TXT=28182 bytes) (Obsoletes RFC1120) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1160) 1161 SNMP over OSI. M.T. Rose. June 1990. (Format: TXT=16036 bytes) (Obsoleted by RFC1418) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1161) 1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base. G. Satz. June 1990. (Format: TXT=109893 bytes) (Obsoleted by RFC1238) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1162) 1163 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1990. (Format: TXT=69404 bytes) (Obsoletes RFC1105) (Obsoleted by RFC1267) (Status: HISTORIC) (DOI: 10.17487/RFC1163) 1164 Application of the Border Gateway Protocol in the Internet. J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. June 1990. (Format: TXT=56278 bytes) (Obsoleted by RFC1268) (Status: HISTORIC) (DOI: 10.17487/RFC1164) 1165 Network Time Protocol (NTP) over the OSI Remote Operations Service. J. Crowcroft, J.P. Onions. June 1990. (Format: TXT=18277 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1165) 1166 Internet numbers. S. Kirkpatrick, M.K. Stahl, M. Recker. July 1990. (Format: TXT=566778 bytes) (Obsoletes RFC1117, RFC1062, RFC1020) (Updated by RFC5737) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1166) 1167 Thoughts on the National Research and Education Network. V.G. Cerf. July 1990. (Format: TXT=20682 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1167) 1168 Intermail and Commercial Mail Relay services. A. Westine, A.L. DeSchon, J. Postel, C.E. Ward. July 1990. (Format: TXT=40306, PS=149816, PDF=55890 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1168) 1169 Explaining the role of GOSIP. V.G. Cerf, K.L. Mills. August 1990. (Format: TXT=30255 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1169) 1170 Public key standards and licenses. R.B. Fougner. January 1991. (Format: TXT=3144 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1170) 1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links. D. Perkins. July 1990. (Format: TXT=92321 bytes) (Obsoletes RFC1134) (Obsoleted by RFC1331) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1171) 1172 Point-to-Point Protocol (PPP) initial configuration options. D. Perkins, R. Hobby. July 1990. (Format: TXT=76132 bytes) (Obsoleted by RFC1331, RFC1332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1172) 1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet. J. VanBokkelen. August 1990. (Format: TXT=12527 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1173) 1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status. V.G. Cerf. August 1990. (Format: TXT=21321 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1174) 1175 FYI on where to start: A bibliography of internetworking information. K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, M.K. Stahl, A. Yuan. August 1990. (Format: TXT=67330 bytes) (Also FYI0003) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1175) 1176 Interactive Mail Access Protocol: Version 2. M.R. Crispin. August 1990. (Format: TXT=67330 bytes) (Obsoletes RFC1064) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1176) 1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions. G.S. Malkin, A.N. Marine, J.K. Reynolds. August 1990. (Format: TXT=52852 bytes) (Obsoleted by RFC1206) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1177) 1178 Choosing a name for your computer. D. Libes. August 1990. (Format: TXT=18472 bytes) (Also FYI0005) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1178) 1179 Line printer daemon protocol. L. McLaughlin. August 1990. (Format: TXT=24324 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1179) 1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. January 1991. (Format: TXT=65494 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1180) 1181 RIPE Terms of Reference. R. Blokzijl. September 1990. (Format: TXT=2523 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1181) 1182 Not Issued. 1183 New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris. October 1990. (Format: TXT=23788 bytes) (Updates RFC1034, RFC1035) (Updated by RFC5395, RFC5864, RFC6195, RFC6895) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1183) 1184 Telnet Linemode Option. D.A. Borman. October 1990. (Format: TXT=53085 bytes) (Obsoletes RFC1116) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1184) 1185 TCP Extension for High-Speed Paths. V. Jacobson, R.T. Braden, L. Zhang. October 1990. (Format: TXT=49508 bytes) (Obsoleted by RFC1323) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1185) 1186 MD4 Message Digest Algorithm. R.L. Rivest. October 1990. (Format: TXT=35391 bytes) (Obsoleted by RFC1320) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1186) 1187 Bulk Table Retrieval with the SNMP. M.T. Rose, K. McCloghrie, J.R. Davin. October 1990. (Format: TXT=27220 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1187) 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks. D. Katz. October 1990. (Format: TXT=22424 bytes) (Obsoletes RFC1103) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1188) 1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP). U.S. Warrier, L. Besaw, L. LaBarre, B.D. Handspicker. October 1990. (Format: TXT=32928 bytes) (Obsoletes RFC1095) (Status: HISTORIC) (DOI: 10.17487/RFC1189) 1190 Experimental Internet Stream Protocol: Version 2 (ST-II). C. Topolcic. October 1990. (Format: TXT=386909 bytes) (Obsoletes IEN119) (Obsoleted by RFC1819) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1190) 1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990. (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1191) 1192 Commercialization of the Internet summary report. B. Kahin. November 1990. (Format: TXT=35253 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1192) 1193 Client requirements for real-time communication services. D. Ferrari. November 1990. (Format: TXT=61540 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1193) 1194 Finger User Information Protocol. D.P. Zimmerman. November 1990. (Format: TXT=24626 bytes) (Obsoletes RFC0742) (Obsoleted by RFC1196, RFC1288) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1194) 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments. R.W. Callon. December 1990. (Format: TXT=187866, PS=362052 bytes) (Updated by RFC1349, RFC5302, RFC5304) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1195) 1196 Finger User Information Protocol. D.P. Zimmerman. December 1990. (Format: TXT=24799 bytes) (Obsoletes RFC1194, RFC0742) (Obsoleted by RFC1288) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1196) 1197 Using ODA for translating multimedia information. M. Sherman. December 1990. (Format: TXT=3620 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1197) 1198 FYI on the X window system. R.W. Scheifler. January 1991. (Format: TXT=3629 bytes) (Also FYI0006) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1198) 1199 Request for Comments Summary Notes: 1100-1199. J. Reynolds. December 1991. (Format: TXT=46443 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1199) 1200 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1991. (Format: TXT=67069 bytes) (Obsoletes RFC1140) (Obsoleted by RFC1250) (Status: HISTORIC) (DOI: 10.17487/RFC1200) 1201 Transmitting IP traffic over ARCNET networks. D. Provan. February 1991. (Format: TXT=16565 bytes) (Obsoletes RFC1051) (Also STD0046) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1201) 1202 Directory Assistance service. M.T. Rose. February 1991. (Format: TXT=21645 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1202) 1203 Interactive Mail Access Protocol: Version 3. J. Rice. February 1991. (Format: TXT=123325 bytes) (Obsoletes RFC1064) (Status: HISTORIC) (DOI: 10.17487/RFC1203) 1204 Message Posting Protocol (MPP). S. Yeh, D. Lee. February 1991. (Format: TXT=11371 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1204) 1205 5250 Telnet interface. P. Chmielewski. February 1991. (Format: TXT=27179 bytes) (Updated by RFC2877) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1205) 1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions. G.S. Malkin, A.N. Marine. February 1991. (Format: TXT=72479 bytes) (Obsoletes RFC1177) (Obsoleted by RFC1325) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1206) 1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions. G.S. Malkin, A.N. Marine, J.K. Reynolds. February 1991. (Format: TXT=33385 bytes) (Also FYI0007) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1207) 1208 A Glossary of Networking Terms. O.J. Jacobsen, D.C. Lynch. March 1991. (Format: TXT=41156 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1208) 1209 The Transmission of IP Datagrams over the SMDS Service. D. Piscitello, J. Lawrence. March 1991. (Format: TXT=24662 bytes) (Also STD0052) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1209) 1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990. V.G. Cerf, P.T. Kirstein, B. Randell. March 1991. (Format: TXT=79048 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1210) 1211 Problems with the maintenance of large mailing lists. A. Westine, J. Postel. March 1991. (Format: TXT=96167 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1211) 1212 Concise MIB definitions. M.T. Rose, K. McCloghrie. March 1991. (Format: TXT=43579 bytes) (Also STD0016) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1212) 1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II. K. McCloghrie, M. Rose. March 1991. (Format: TXT=142158 bytes) (Obsoletes RFC1158) (Updated by RFC2011, RFC2012, RFC2013) (Also STD0017) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1213) 1214 OSI internet management: Management Information Base. L. LaBarre. April 1991. (Format: TXT=172564 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1214) 1215 Convention for defining traps for use with the SNMP. M.T. Rose. March 1991. (Format: TXT=19336 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1215) 1216 Gigabit network economics and paradigm shifts. P. Richard, P. Kynikos. April 1991. (Format: TXT=8130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1216) 1217 Memo from the Consortium for Slow Commotion Research (CSCR). V.G. Cerf. April 1991. (Format: TXT=11079 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1217) 1218 Naming scheme for c=US. North American Directory Forum. April 1991. (Format: TXT=42698 bytes) (Obsoleted by RFC1255, RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1218) 1219 On the assignment of subnet numbers. P.F. Tsuchiya. April 1991. (Format: TXT=30609 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1219) 1220 Point-to-Point Protocol extensions for bridging. F. Baker. April 1991. (Format: TXT=38165 bytes) (Obsoleted by RFC1638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1220) 1221 Host Access Protocol (HAP) specification: Version 2. W. Edmond. April 1991. (Format: TXT=152740 bytes) (Updates RFC0907) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1221) 1222 Advancing the NSFNET routing architecture. H.W. Braun, Y. Rekhter. May 1991. (Format: TXT=15067 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1222) 1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel. J.M. Halpern. May 1991. (Format: TXT=29601 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1223) 1224 Techniques for managing asynchronously generated alerts. L. Steinberg. May 1991. (Format: TXT=54303 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1224) 1225 Post Office Protocol: Version 3. M.T. Rose. May 1991. (Format: TXT=37340 bytes) (Obsoletes RFC1081) (Obsoleted by RFC1460) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1225) 1226 Internet protocol encapsulation of AX.25 frames. B. Kantor. May 1991. (Format: TXT=2573 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1226) 1227 SNMP MUX protocol and MIB. M.T. Rose. May 1991. (Format: TXT=25868 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1227) 1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface. G. Carpenter, B. Wijnen. May 1991. (Format: TXT=96972 bytes) (Obsoleted by RFC1592) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1228) 1229 Extensions to the generic-interface MIB. K. McCloghrie. May 1991. (Format: TXT=36022 bytes) (Obsoleted by RFC1573) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1229) 1230 IEEE 802.4 Token Bus MIB. K. McCloghrie, R. Fox. May 1991. (Format: TXT=53100 bytes) (Updated by RFC1239) (Status: HISTORIC) (DOI: 10.17487/RFC1230) 1231 IEEE 802.5 Token Ring MIB. K. McCloghrie, R. Fox, E. Decker. May 1991. (Format: TXT=53542 bytes) (Obsoleted by RFC1743, RFC1748) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1231) 1232 Definitions of managed objects for the DS1 Interface type. F. Baker, C.P. Kolb. May 1991. (Format: TXT=60757 bytes) (Obsoleted by RFC1406) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1232) 1233 Definitions of managed objects for the DS3 Interface type. T.A. Cox, K. Tesink. May 1991. (Format: TXT=49559 bytes) (Obsoleted by RFC1407) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1233) 1234 Tunneling IPX traffic through IP networks. D. Provan. June 1991. (Format: TXT=12333 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1234) 1235 Coherent File Distribution Protocol. J. Ioannidis, G. Maguire. June 1991. (Format: TXT=29345 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1235) 1236 IP to X.121 address mapping for DDN. L. Morales, P. Hasse. June 1991. (Format: TXT=12626 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1236) 1237 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, E. Gardner, R. Callon. July 1991. (Format: TXT=116989, PS=160478, PDF=171423 bytes) (Obsoleted by RFC1629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1237) 1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542). G. Satz. June 1991. (Format: TXT=65159 bytes) (Obsoletes RFC1162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1238) 1239 Reassignment of experimental MIBs to standard MIBs. J.K. Reynolds. June 1991. (Format: TXT=3656 bytes) (Updates RFC1229, RFC1230, RFC1231, RFC1232, RFC1233) (Status: HISTORIC) (DOI: 10.17487/RFC1239) 1240 OSI connectionless transport services on top of UDP: Version 1. C. Shue, W. Haggerty, K. Dobbins. June 1991. (Format: TXT=18140 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1240) 1241 Scheme for an internet encapsulation protocol: Version 1. R.A. Woodburn, D.L. Mills. July 1991. (Format: TXT=42468, PS=128921, PDF=44593 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1241) 1242 Benchmarking Terminology for Network Interconnection Devices. S. Bradner. July 1991. (Format: TXT=22817 bytes) (Updated by RFC6201) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1242) 1243 AppleTalk Management Information Base. S. Waldbusser. July 1991. (Format: TXT=61985 bytes) (Obsoleted by RFC1742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1243) 1244 Site Security Handbook. J.P. Holbrook, J.K. Reynolds. July 1991. (Format: TXT=259129 bytes) (Obsoleted by RFC2196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1244) 1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT=26160, PS=33546, PDF=31723 bytes) (Also RFC1246, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1245) 1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format: TXT=70441, PS=141924, PDF=84633 bytes) (Also RFC1245, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1246) 1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT=433332, PS=989724, PDF=490300 bytes) (Obsoletes RFC1131) (Obsoleted by RFC1583) (Updated by RFC1349) (Also RFC1245, RFC1246) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1247) 1248 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. July 1991. (Format: TXT=74347 bytes) (Obsoleted by RFC1252) (Updated by RFC1349) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1248) 1249 DIXIE Protocol Specification. T. Howes, M. Smith, B. Beecher. August 1991. (Format: TXT=20028 bytes) (Also RFC1202) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1249) 1250 IAB Official Protocol Standards. J. Postel. August 1991. (Format: TXT=62555 bytes) (Obsoletes RFC1200) (Obsoleted by RFC2200, RFC1280) (Status: HISTORIC) (DOI: 10.17487/RFC1250) 1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members. G. Malkin. August 1991. (Format: TXT=70383 bytes) (Obsoleted by RFC1336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1251) 1252 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT=74471 bytes) (Obsoletes RFC1248) (Obsoleted by RFC1253) (Also RFC1245, RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1252) 1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT=74453 bytes) (Obsoletes RFC1252) (Obsoleted by RFC1850) (Also RFC1245, RFC1246, RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1253) 1254 Gateway Congestion Control Survey. A. Mankin, K. Ramakrishnan. August 1991. (Format: TXT=67609 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1254) 1255 A Naming Scheme for c=US. The North American Directory Forum. September 1991. (Format: TXT=51103 bytes) (Obsoletes RFC1218) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1255) 1256 ICMP Router Discovery Messages. S. Deering, Ed.. September 1991. (Format: TXT=43059 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1256) 1257 Isochronous applications do not require jitter-controlled networks. C. Partridge. September 1991. (Format: TXT=11075 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1257) 1258 BSD Rlogin. B. Kantor. September 1991. (Format: TXT=10763 bytes) (Obsoleted by RFC1282) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1258) 1259 Building the open road: The NREN as test-bed for the national public network. M. Kapor. September 1991. (Format: TXT=61654 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1259) 1260 Not Issued. 1261 Transition of Nic Services. S. Williamson, L. Nobile. September 1991. (Format: TXT=4244 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1261) 1262 Guidelines for Internet Measurement Activities. V.G. Cerf. October 1991. (Format: TXT=6381 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1262) 1263 TCP Extensions Considered Harmful. S. O'Malley, L.L. Peterson. October 1991. (Format: TXT=54078 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1263) 1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria. R.M. Hinden. October 1991. (Format: TXT=17016 bytes) (Obsoleted by RFC4794) (Status: HISTORIC) (DOI: 10.17487/RFC1264) 1265 BGP Protocol Analysis. Y. Rekhter. October 1991. (Format: TXT=20728 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1265) 1266 Experience with the BGP Protocol. Y. Rekhter. October 1991. (Format: TXT=21938 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1266) 1267 Border Gateway Protocol 3 (BGP-3). K. Lougheed, Y. Rekhter. October 1991. (Format: TXT=80724 bytes) (Obsoletes RFC1163) (Status: HISTORIC) (DOI: 10.17487/RFC1267) 1268 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. October 1991. (Format: TXT=31102 bytes) (Obsoletes RFC1164) (Obsoleted by RFC1655) (Status: HISTORIC) (DOI: 10.17487/RFC1268) 1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3. S. Willis, J.W. Burruss. October 1991. (Format: TXT=25717 bytes) (Obsoleted by RFC4273) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1269) 1270 SNMP Communications Services. F. Kastenholz. October 1991. (Format: TXT=26167 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1270) 1271 Remote Network Monitoring Management Information Base. S. Waldbusser. November 1991. (Format: TXT=184111 bytes) (Obsoleted by RFC1757) (Updated by RFC1513) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1271) 1272 Internet Accounting: Background. C. Mills, D. Hirsh, G.R. Ruth. November 1991. (Format: TXT=46562 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1272) 1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations. M.F. Schwartz. November 1991. (Format: TXT=19949 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1273) 1274 The COSINE and Internet X.500 Schema. P. Barker, S. Kille. November 1991. (Format: TXT=92827 bytes) (Obsoleted by RFC4524) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1274) 1275 Replication Requirements to provide an Internet Directory using X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT=4616, PS=83736, PDF=73349 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1275) 1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT=33731, PS=217170 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1276) 1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers. S.E. Hardcastle-Kille. November 1991. (Format: TXT=22254, PS=176169 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1277) 1278 A string encoding of Presentation Address. S.E. Hardcastle-Kille. November 1991. (Format: TXT=10256, PS=128696 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1278) 1279 X.500 and Domains. S.E. Hardcastle-Kille. November 1991. (Format: TXT=26669, PS=170029, PDF=142776 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1279) 1280 IAB Official Protocol Standards. J. Postel. March 1992. (Format: TXT=70458 bytes) (Obsoletes RFC1250) (Obsoleted by RFC1360) (Status: HISTORIC) (DOI: 10.17487/RFC1280) 1281 Guidelines for the Secure Operation of the Internet. R. Pethia, S. Crocker, B. Fraser. November 1991. (Format: TXT=22618 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1281) 1282 BSD Rlogin. B. Kantor. December 1991. (Format: TXT=10704 bytes) (Obsoletes RFC1258) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1282) 1283 SNMP over OSI. M. Rose. December 1991. (Format: TXT=16857 bytes) (Obsoleted by RFC1418) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1283) 1284 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Cook, Ed.. December 1991. (Format: TXT=43225 bytes) (Obsoleted by RFC1398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1284) 1285 FDDI Management Information Base. J. Case. January 1992. (Format: TXT=99747 bytes) (Updated by RFC1512) (Status: HISTORIC) (DOI: 10.17487/RFC1285) 1286 Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. December 1991. (Format: TXT=79104 bytes) (Obsoleted by RFC1493, RFC1525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1286) 1287 Towards the Future Internet Architecture. D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby. December 1991. (Format: TXT=59812 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1287) 1288 The Finger User Information Protocol. D. Zimmerman. December 1991. (Format: TXT=25161 bytes) (Obsoletes RFC1196, RFC1194, RFC0742) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1288) 1289 DECnet Phase IV MIB Extensions. J. Saperia. December 1991. (Format: TXT=122272 bytes) (Obsoleted by RFC1559) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1289) 1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. December 1991. (Format: TXT=46997 bytes) (Obsoleted by RFC1402) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1290) 1291 Mid-Level Networks Potential Technical Services. V. Aggarwal. December 1991. (Format: TXT=24314, PS=218918 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1291) 1292 A Catalog of Available X.500 Implementations. R. Lang, R. Wright. January 1992. (Format: TXT=129468 bytes) (Obsoleted by RFC1632) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1292) 1293 Inverse Address Resolution Protocol. T. Bradley, C. Brown. January 1992. (Format: TXT=11368 bytes) (Obsoleted by RFC2390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1293) 1294 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. Brown, A. Malis. January 1992. (Format: TXT=54992 bytes) (Obsoleted by RFC1490, RFC2427) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1294) 1295 User Bill of Rights for entries and listings in the Public Directory. The North American Directory Forum. January 1992. (Format: TXT=3502 bytes) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1295) 1296 Internet Growth (1981-1991). M. Lottor. January 1992. (Format: TXT=20103 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1296) 1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS"). D. Johnson. January 1992. (Format: TXT=32964 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1297) 1298 SNMP over IPX. R. Wormley, S. Bostock. February 1992. (Format: TXT=7878 bytes) (Obsoleted by RFC1420) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1298) 1299 Summary of 1200-1299. M. Kennedy. January 1997. (Format: TXT=36594 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1299) 1300 Remembrances of Things Past. S. Greenfield. February 1992. (Format: TXT=4963 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1300) 1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K. Marzullo. February 1992. (Format: TXT=91976 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1301) 1302 Building a Network Information Services Infrastructure. D. Sitzler, P. Smith, A. Marine. February 1992. (Format: TXT=29135 bytes) (Also FYI0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1302) 1303 A Convention for Describing SNMP-based Agents. K. McCloghrie, M. Rose. February 1992. (Format: TXT=22915 bytes) (Also RFC1155, RFC1157, RFC1212, RFC1213) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1303) 1304 Definitions of Managed Objects for the SIP Interface Type. T. Cox, Ed., K. Tesink, Ed.. February 1992. (Format: TXT=52491 bytes) (Obsoleted by RFC1694) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1304) 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis. D. Mills. March 1992. (Format: TXT=307085, PDF=442493 bytes) (Obsoletes RFC0958, RFC1059, RFC1119) (Obsoleted by RFC5905) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1305) 1306 Experiences Supporting By-Request Circuit-Switched T3 Networks. A. Nicholson, J. Young. March 1992. (Format: TXT=25788 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1306) 1307 Dynamically Switched Link Control Protocol. J. Young, A. Nicholson. March 1992. (Format: TXT=24145 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1307) 1308 Executive Introduction to Directory Services Using the X.500 Protocol. C. Weider, J. Reynolds. March 1992. (Format: TXT=9392 bytes) (Also FYI0013) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1308) 1309 Technical Overview of Directory Services Using the X.500 Protocol. C. Weider, J. Reynolds, S. Heker. March 1992. (Format: TXT=35694 bytes) (Also FYI0014) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1309) 1310 The Internet Standards Process. L. Chapin. March 1992. (Format: TXT=54738 bytes) (Obsoleted by RFC1602) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1310) 1311 Introduction to the STD Notes. J. Postel. March 1992. (Format: TXT=11308 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1311) 1312 Message Send Protocol 2. R. Nelson, G. Arnold. April 1992. (Format: TXT=18037 bytes) (Obsoletes RFC1159) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1312) 1313 Today's Programming for KRFC AM 1313 Internet Talk Radio. C. Partridge. April 1992. (Format: TXT=5444 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1313) 1314 A File Format for the Exchange of Images in the Internet. A. Katz, D. Cohen. April 1992. (Format: TXT=54072 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1314) 1315 Management Information Base for Frame Relay DTEs. C. Brown, F. Baker, C. Carvalho. April 1992. (Format: TXT=33825 bytes) (Obsoleted by RFC2115) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1315) 1316 Definitions of Managed Objects for Character Stream Devices. B. Stewart. April 1992. (Format: TXT=35143 bytes) (Obsoleted by RFC1658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1316) 1317 Definitions of Managed Objects for RS-232-like Hardware Devices. B. Stewart. April 1992. (Format: TXT=30442 bytes) (Obsoleted by RFC1659) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1317) 1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices. B. Stewart. April 1992. (Format: TXT=19570 bytes) (Obsoleted by RFC1660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1318) 1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992. (Format: TXT=25661 bytes) (Obsoleted by RFC6149) (Status: HISTORIC) (DOI: 10.17487/RFC1319) 1320 The MD4 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT=32407 bytes) (Obsoletes RFC1186) (Obsoleted by RFC6150) (Status: HISTORIC) (DOI: 10.17487/RFC1320) 1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT=35222 bytes) (Updated by RFC6151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1321) 1322 A Unified Approach to Inter-Domain Routing. D. Estrin, Y. Rekhter, S. Hotz. May 1992. (Format: TXT=96934 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1322) 1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992. (Format: TXT=84558 bytes) (Obsoletes RFC1072, RFC1185) (Obsoleted by RFC7323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1323) 1324 A Discussion on Computer Network Conferencing. D. Reed. May 1992. (Format: TXT=24988 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1324) 1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions. G. Malkin, A. Marine. May 1992. (Format: TXT=91884 bytes) (Obsoletes RFC1206) (Obsoleted by RFC1594) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1325) 1326 Mutual Encapsulation Considered Dangerous. P. Tsuchiya. May 1992. (Format: TXT=11277 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1326) 1327 Mapping between X.400(1988) / ISO 10021 and RFC 822. S. Hardcastle-Kille. May 1992. (Format: TXT=228598 bytes) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148) (Obsoleted by RFC2156) (Updates RFC0822) (Updated by RFC1495) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1327) 1328 X.400 1988 to 1984 downgrading. S. Hardcastle-Kille. May 1992. (Format: TXT=10006 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1328) 1329 Thoughts on Address Resolution for Dual MAC FDDI Networks. P. Kuehn. May 1992. (Format: TXT=58150 bytes) (Updated by RFC5494) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1329) 1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community. ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet). May 1992. (Format: TXT=192925 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1330) 1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links. W. Simpson. May 1992. (Format: TXT=129892 bytes) (Obsoletes RFC1171, RFC1172) (Obsoleted by RFC1548) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1331) 1332 The PPP Internet Protocol Control Protocol (IPCP). G. McGregor. May 1992. (Format: TXT=17613 bytes) (Obsoletes RFC1172) (Updated by RFC3241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1332) 1333 PPP Link Quality Monitoring. W. Simpson. May 1992. (Format: TXT=29965 bytes) (Obsoleted by RFC1989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1333) 1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992. (Format: TXT=33248 bytes) (Obsoleted by RFC1994) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1334) 1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion. Z. Wang, J. Crowcroft. May 1992. (Format: TXT=15418 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1335) 1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members. G. Malkin. May 1992. (Format: TXT=92119 bytes) (Obsoletes RFC1251) (Also FYI0009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1336) 1337 TIME-WAIT Assassination Hazards in TCP. R. Braden. May 1992. (Format: TXT=22887 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1337) 1338 Supernetting: an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. June 1992. (Format: TXT=47975 bytes) (Obsoleted by RFC1519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1338) 1339 Remote Mail Checking Protocol. S. Dorner, P. Resnick. June 1992. (Format: TXT=13115 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1339) 1340 Assigned Numbers. J. Reynolds, J. Postel. July 1992. (Format: TXT=232974 bytes) (Obsoletes RFC1060) (Obsoleted by RFC1700) (Status: HISTORIC) (DOI: 10.17487/RFC1340) 1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein, N. Freed. June 1992. (Format: TXT=211117, PS=347082, PDF=192244 bytes) (Obsoleted by RFC1521) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1341) 1342 Representation of Non-ASCII Text in Internet Message Headers. K. Moore. June 1992. (Format: TXT=15845 bytes) (Obsoleted by RFC1522) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1342) 1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information. N. Borenstein. June 1992. (Format: TXT=29295, PS=59978, PDF=28495 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1343) 1344 Implications of MIME for Internet Mail Gateways. N. Borenstein. June 1992. (Format: TXT=25872, PS=51812, PDF=24430 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1344) 1345 Character Mnemonics and Character Sets. K. Simonsen. June 1992. (Format: TXT=249737 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1345) 1346 Resource Allocation, Control, and Accounting for the Use of Network Resources. P. Jones. June 1992. (Format: TXT=13084 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1346) 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing. R. Callon. June 1992. (Format: TXT=26563, PS=42398, PDF=22398 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1347) 1348 DNS NSAP RRs. B. Manning. July 1992. (Format: TXT=6871 bytes) (Obsoleted by RFC1637) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1348) 1349 Type of Service in the Internet Protocol Suite. P. Almquist. July 1992. (Format: TXT=68949 bytes) (Obsoleted by RFC2474) (Updates RFC1248, RFC1247, RFC1195, RFC1123, RFC1122, RFC1060, RFC0791) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1349) 1350 The TFTP Protocol (Revision 2). K. Sollins. July 1992. (Format: TXT=24599 bytes) (Obsoletes RFC0783) (Updated by RFC1782, RFC1783, RFC1784, RFC1785, RFC2347, RFC2348, RFC2349) (Also STD0033) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1350) 1351 SNMP Administrative Model. J. Davin, J. Galvin, K. McCloghrie. July 1992. (Format: TXT=80721 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1351) 1352 SNMP Security Protocols. J. Galvin, K. McCloghrie, J. Davin. July 1992. (Format: TXT=95732 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1352) 1353 Definitions of Managed Objects for Administration of SNMP Parties. K. McCloghrie, J. Davin, J. Galvin. July 1992. (Format: TXT=59556 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1353) 1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT=24905 bytes) (Obsoleted by RFC2096) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1354) 1355 Privacy and Accuracy Issues in Network Information Center Databases. J. Curran, A. Marine. August 1992. (Format: TXT=8858 bytes) (Also FYI0015) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1355) 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode. A. Malis, D. Robinson, R. Ullmann. August 1992. (Format: TXT=32043 bytes) (Obsoletes RFC0877) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1356) 1357 A Format for E-mailing Bibliographic Records. D. Cohen. July 1992. (Format: TXT=25021 bytes) (Obsoleted by RFC1807) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1357) 1358 Charter of the Internet Architecture Board (IAB). L. Chapin. August 1992. (Format: TXT=11328 bytes) (Obsoleted by RFC1601) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1358) 1359 Connecting to the Internet - What Connecting Institutions Should Anticipate. ACM SIGUCCS. August 1992. (Format: TXT=53449 bytes) (Also FYI0016) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1359) 1360 IAB Official Protocol Standards. J. Postel. September 1992. (Format: TXT=71860 bytes) (Obsoletes RFC1280) (Obsoleted by RFC1410) (Status: HISTORIC) (DOI: 10.17487/RFC1360) 1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992. (Format: TXT=23812 bytes) (Obsoleted by RFC1769) (Also RFC1305) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1361) 1362 Novell IPX over Various WAN Media (IPXWAN). M. Allen. September 1992. (Format: TXT=30219 bytes) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1362) 1363 A Proposed Flow Specification. C. Partridge. September 1992. (Format: TXT=59214 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1363) 1364 BGP OSPF Interaction. K. Varadhan. September 1992. (Format: TXT=32121 bytes) (Obsoleted by RFC1403) (Also RFC1247, RFC1267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1364) 1365 An IP Address Extension Proposal. K. Siyan. September 1992. (Format: TXT=12790 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1365) 1366 Guidelines for Management of IP Address Space. E. Gerich. October 1992. (Format: TXT=17793 bytes) (Obsoleted by RFC1466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1366) 1367 Schedule for IP Address Space Management Guidelines. C. Topolcic. October 1992. (Format: TXT=4780 bytes) (Obsoleted by RFC1467) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1367) 1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices. D. McMaster, K. McCloghrie. October 1992. (Format: TXT=83905 bytes) (Obsoleted by RFC1516) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1368) 1369 Implementation Notes and Experience for the Internet Ethernet MIB. F. Kastenholz. October 1992. (Format: TXT=13961 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1369) 1370 Applicability Statement for OSPF. Internet Architecture Board, L. Chapin. October 1992. (Format: TXT=4303 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1370) 1371 Choosing a Common IGP for the IP Internet. P. Gross. October 1992. (Format: TXT=18168 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1371) 1372 Telnet Remote Flow Control Option. C. Hedrick, D. Borman. October 1992. (Format: TXT=11098 bytes) (Obsoletes RFC1080) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1372) 1373 Portable DUAs. T. Tignor. October 1992. (Format: TXT=19931 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1373) 1374 IP and ARP on HIPPI. J. Renwick, A. Nicholson. October 1992. (Format: TXT=100903 bytes) (Obsoleted by RFC2834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1374) 1375 Suggestion for New Classes of IP Addresses. P. Robinson. October 1992. (Format: TXT=16990 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1375) 1376 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. November 1992. (Format: TXT=12448 bytes) (Obsoleted by RFC1762) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1376) 1377 The PPP OSI Network Layer Control Protocol (OSINLCP). D. Katz. November 1992. (Format: TXT=22109 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1377) 1378 The PPP AppleTalk Control Protocol (ATCP). B. Parker. November 1992. (Format: TXT=28496 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1378) 1379 Extending TCP for Transactions -- Concepts. R. Braden. November 1992. (Format: TXT=91353 bytes) (Obsoleted by RFC6247) (Updated by RFC1644) (Status: HISTORIC) (DOI: 10.17487/RFC1379) 1380 IESG Deliberations on Routing and Addressing. P. Gross, P. Almquist. November 1992. (Format: TXT=49415 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1380) 1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. November 1992. (Format: TXT=71253 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1381) 1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop, Ed.. November 1992. (Format: TXT=153877 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1382) 1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992. (Format: TXT=32680 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1383) 1384 Naming Guidelines for Directory Pilots. P. Barker, S.E. Hardcastle-Kille. January 1993. (Format: TXT=25870, PS=175044, PDF=134487 bytes) (Obsoleted by RFC1617, RTR0011) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1384) 1385 EIP: The Extended Internet Protocol. Z. Wang. November 1992. (Format: TXT=39123 bytes) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1385) 1386 The US Domain. A. Cooper, J. Postel. December 1992. (Format: TXT=62310 bytes) (Obsoleted by RFC1480) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1386) 1387 RIP Version 2 Protocol Analysis. G. Malkin. January 1993. (Format: TXT=5598 bytes) (Obsoleted by RFC1721) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1387) 1388 RIP Version 2 Carrying Additional Information. G. Malkin. January 1993. (Format: TXT=16227 bytes) (Obsoleted by RFC1723) (Updates RFC1058) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1388) 1389 RIP Version 2 MIB Extensions. G. Malkin, F. Baker. January 1993. (Format: TXT=23569 bytes) (Obsoleted by RFC1724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1389) 1390 Transmission of IP and ARP over FDDI Networks. D. Katz. January 1993. (Format: TXT=22077 bytes) (Also STD0036) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1390) 1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force. G. Malkin. January 1993. (Format: TXT=41892 bytes) (Obsoleted by RFC1539) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1391) 1392 Internet Users' Glossary. G. Malkin, T. LaQuey Parker. January 1993. (Format: TXT=104624 bytes) (Obsoleted by RFC1983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1392) 1393 Traceroute Using an IP Option. G. Malkin. January 1993. (Format: TXT=13140 bytes) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1393) 1394 Relationship of Telex Answerback Codes to Internet Domains. P. Robinson. January 1993. (Format: TXT=43776 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1394) 1395 BOOTP Vendor Information Extensions. J. Reynolds. January 1993. (Format: TXT=16314 bytes) (Obsoletes RFC1084, RFC1048) (Obsoleted by RFC1497, RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1395) 1396 The Process for Organization of Internet Standards Working Group (POISED). S. Crocker. January 1993. (Format: TXT=22096 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1396) 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol. D. Haskin. January 1993. (Format: TXT=4124 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1397) 1398 Definitions of Managed Objects for the Ethernet-Like Interface Types. F. Kastenholz. January 1993. (Format: TXT=36684 bytes) (Obsoletes RFC1284) (Obsoleted by RFC1623) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1398) 1399 Summary of 1300-1399. J. Elliott. January 1997. (Format: TXT=43662 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1399) 1400 Transition and Modernization of the Internet Registration Service. S. Williamson. March 1993. (Format: TXT=13008 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1400) 1401 Correspondence between the IAB and DISA on the use of DNS. Internet Architecture Board. January 1993. (Format: TXT=12528 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1401) 1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. January 1993. (Format: TXT=71176 bytes) (Obsoletes RFC1290) (Also FYI0010) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1402) 1403 BGP OSPF Interaction. K. Varadhan. January 1993. (Format: TXT=36173 bytes) (Obsoletes RFC1364) (Status: HISTORIC) (DOI: 10.17487/RFC1403) 1404 A Model for Common Operational Statistics. B. Stockman. January 1993. (Format: TXT=52814 bytes) (Obsoleted by RFC1857) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1404) 1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail). C. Allocchio. January 1993. (Format: TXT=33885 bytes) (Obsoleted by RFC2162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1405) 1406 Definitions of Managed Objects for the DS1 and E1 Interface Types. F. Baker, Ed., J. Watt, Ed.. January 1993. (Format: TXT=97559 bytes) (Obsoletes RFC1232) (Obsoleted by RFC2495) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1406) 1407 Definitions of Managed Objects for the DS3/E3 Interface Type. T. Cox, K. Tesink. January 1993. (Format: TXT=90682 bytes) (Obsoletes RFC1233) (Obsoleted by RFC2496) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1407) 1408 Telnet Environment Option. D. Borman, Ed.. January 1993. (Format: TXT=13936 bytes) (Updated by RFC1571) (Status: HISTORIC) (DOI: 10.17487/RFC1408) 1409 Telnet Authentication Option. D. Borman, Ed.. January 1993. (Format: TXT=13119 bytes) (Obsoleted by RFC1416) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1409) 1410 IAB Official Protocol Standards. J. Postel, Ed.. March 1993. (Format: TXT=76524 bytes) (Obsoletes RFC1360) (Obsoleted by RFC1500) (Status: HISTORIC) (DOI: 10.17487/RFC1410) 1411 Telnet Authentication: Kerberos Version 4. D. Borman, Ed.. January 1993. (Format: TXT=7967 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1411) 1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format: TXT=6952 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1412) 1413 Identification Protocol. M. St. Johns. February 1993. (Format: TXT=16291 bytes) (Obsoletes RFC0931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1413) 1414 Identification MIB. M. St. Johns, M. Rose. February 1993. (Format: TXT=14165 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1414) 1415 FTP-FTAM Gateway Specification. J. Mindel, R. Slaski. January 1993. (Format: TXT=128261 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1415) 1416 Telnet Authentication Option. D. Borman, Ed.. February 1993. (Format: TXT=13270 bytes) (Obsoletes RFC1409) (Obsoleted by RFC2941) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1416) 1417 NADF Standing Documents: A Brief Overview. The North American Directory Forum. February 1993. (Format: TXT=7270 bytes) (Obsoletes RFC1295, RFC1255, RFC1218) (Obsoleted by RFC1758) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1417) 1418 SNMP over OSI. M. Rose. March 1993. (Format: TXT=7721 bytes) (Obsoletes RFC1161, RFC1283) (Status: HISTORIC) (DOI: 10.17487/RFC1418) 1419 SNMP over AppleTalk. G. Minshall, M. Ritter. March 1993. (Format: TXT=16470 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1419) 1420 SNMP over IPX. S. Bostock. March 1993. (Format: TXT=6762 bytes) (Obsoletes RFC1298) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1420) 1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. J. Linn. February 1993. (Format: TXT=103894 bytes) (Obsoletes RFC1113) (Status: HISTORIC) (DOI: 10.17487/RFC1421) 1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. S. Kent. February 1993. (Format: TXT=86085 bytes) (Obsoletes RFC1114) (Status: HISTORIC) (DOI: 10.17487/RFC1422) 1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. D. Balenson. February 1993. (Format: TXT=33277 bytes) (Obsoletes RFC1115) (Status: HISTORIC) (DOI: 10.17487/RFC1423) 1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services. B. Kaliski. February 1993. (Format: TXT=17537 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1424) 1425 SMTP Service Extensions. J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT=20932 bytes) (Obsoleted by RFC1651) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1425) 1426 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT=11661 bytes) (Obsoleted by RFC1652) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1426) 1427 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, Ed., K. Moore. February 1993. (Format: TXT=17856 bytes) (Obsoleted by RFC1653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1427) 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. G. Vaudreuil. February 1993. (Format: TXT=12064 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1428) 1429 Listserv Distribute Protocol. E. Thomas. February 1993. (Format: TXT=17759 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1429) 1430 A Strategic Plan for Deploying an Internet X.500 Directory Service. S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent. February 1993. (Format: TXT=47587 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1430) 1431 DUA Metrics (OSI-DS 33 (v2)). P. Barker. February 1993. (Format: TXT=42240 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1431) 1432 Recent Internet Books. J. Quarterman. March 1993. (Format: TXT=27089 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1432) 1433 Directed ARP. J. Garrett, J. Hagan, J. Wong. March 1993. (Format: TXT=41028 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1433) 1434 Data Link Switching: Switch-to-Switch Protocol. R. Dixon, D. Kushi. March 1993. (Format: TXT=80182, PS=292006, PDF=181839 bytes) (Obsoleted by RFC1795) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1434) 1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles. March 1993. (Format: TXT=2708 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1435) 1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol). F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. Albert. March 1993. (Format: TXT=36493 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1436) 1437 The Extension of MIME Content-Types to a New Medium. N. Borenstein, M. Linimon. April 1993. (Format: TXT=13356 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1437) 1438 Internet Engineering Task Force Statements Of Boredom (SOBs). A. Lyman Chapin, C. Huitema. April 1993. (Format: TXT=3044 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1438) 1439 The Uniqueness of Unique Identifiers. C. Finseth. March 1993. (Format: TXT=20477 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1439) 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer. R. Troth. July 1993. (Format: TXT=17366 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1440) 1441 Introduction to version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=25386 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1441) 1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=95779 bytes) (Obsoleted by RFC1902) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1442) 1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=60947 bytes) (Obsoleted by RFC1903) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1443) 1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=57744 bytes) (Obsoleted by RFC1904) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1444) 1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. (Format: TXT=99443 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1445) 1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. (Format: TXT=108733 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1446) 1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2). K. McCloghrie, J. Galvin. April 1993. (Format: TXT=80762 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1447) 1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=74224 bytes) (Obsoleted by RFC1905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1448) 1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=41161 bytes) (Obsoleted by RFC1906) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1449) 1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=42172 bytes) (Obsoleted by RFC1907) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1450) 1451 Manager-to-Manager Management Information Base. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=62935 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1451) 1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=32176 bytes) (Obsoleted by RFC1908) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1452) 1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers. W. Chimiak. April 1993. (Format: TXT=23563 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1453) 1454 Comparison of Proposals for Next Version of IP. T. Dixon. May 1993. (Format: TXT=35064 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1454) 1455 Physical Link Security Type of Service. D. Eastlake 3rd. May 1993. (Format: TXT=12391 bytes) (Obsoleted by RFC2474) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1455) 1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification. Vietnamese Standardization Working Group. May 1993. (Format: TXT=14775 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1456) 1457 Security Label Framework for the Internet. R. Housley. May 1993. (Format: TXT=35802 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1457) 1458 Requirements for Multicast Protocols. R. Braudes, S. Zabele. May 1993. (Format: TXT=48106 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1458) 1459 Internet Relay Chat Protocol. J. Oikarinen, D. Reed. May 1993. (Format: TXT=138964 bytes) (Updated by RFC2810, RFC2811, RFC2812, RFC2813, RFC7194) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1459) 1460 Post Office Protocol - Version 3. M. Rose. June 1993. (Format: TXT=38827 bytes) (Obsoletes RFC1225) (Obsoleted by RFC1725) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1460) 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25. D. Throop. May 1993. (Format: TXT=47945 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1461) 1462 FYI on "What is the Internet?". E. Krol, E. Hoffman. May 1993. (Format: TXT=27811 bytes) (Also FYI0020) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1462) 1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings. E. Hoffman, L. Jackson. May 1993. (Format: TXT=7116 bytes) (Also FYI0019) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1463) 1464 Using the Domain Name System To Store Arbitrary String Attributes. R. Rosenbaum. May 1993. (Format: TXT=7953 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1464) 1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing. D. Eppenberger. May 1993. (Format: TXT=66833 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1465) 1466 Guidelines for Management of IP Address Space. E. Gerich. May 1993. (Format: TXT=22262 bytes) (Obsoletes RFC1366) (Obsoleted by RFC2050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1466) 1467 Status of CIDR Deployment in the Internet. C. Topolcic. August 1993. (Format: TXT=20720 bytes) (Obsoletes RFC1367) (Status: HISTORIC) (DOI: 10.17487/RFC1467) 1468 Japanese Character Encoding for Internet Messages. J. Murai, M. Crispin, E. van der Poel. June 1993. (Format: TXT=10970 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1468) 1469 IP Multicast over Token-Ring Local Area Networks. T. Pusateri. June 1993. (Format: TXT=8189 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1469) 1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices. R. Enger, J. Reynolds. June 1993. (Format: TXT=308528 bytes) (Obsoletes RFC1147) (Also FYI0002) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1470) 1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT=53558 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1471) 1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT=27152 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1472) 1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT=20484 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1473) 1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT=31846 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1474) 1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format: TXT=77854 bytes) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1475) 1476 RAP: Internet Route Access Protocol. R. Ullmann. June 1993. (Format: TXT=45560 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1476) 1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format: TXT=32238 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1477) 1478 An Architecture for Inter-Domain Policy Routing. M. Steenstrup. June 1993. (Format: TXT=90673 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1478) 1479 Inter-Domain Policy Routing Protocol Specification: Version 1. M. Steenstrup. July 1993. (Format: TXT=275823 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1479) 1480 The US Domain. A. Cooper, J. Postel. June 1993. (Format: TXT=100556 bytes) (Obsoletes RFC1386) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1480) 1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling. C. Huitema. July 1993. (Format: TXT=3502 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1481) 1482 Aggregation Support in the NSFNET Policy-Based Routing Database. M. Knopper, S. Richardson. June 1993. (Format: TXT=25330 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1482) 1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5. Juha Heinanen. July 1993. (Format: TXT=35192 bytes) (Obsoleted by RFC2684) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1483) 1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)). S. Hardcastle-Kille. July 1993. (Format: TXT=48974 bytes) (Obsoleted by RFC1781, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1484) 1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)). S. Hardcastle-Kille. July 1993. (Format: TXT=11158 bytes) (Obsoleted by RFC1779, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1485) 1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. (Format: TXT=26373 bytes) (Obsoleted by RFC1528, RFC1529) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1486) 1487 X.500 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. Kille. July 1993. (Format: TXT=44947 bytes) (Obsoleted by RFC1777, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1487) 1488 The X.500 String Representation of Standard Attribute Syntaxes. T. Howes, S. Kille, W. Yeong, C. Robbins. July 1993. (Format: TXT=17182 bytes) (Obsoleted by RFC1778) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1488) 1489 Registration of a Cyrillic Character Set. A. Chernov. July 1993. (Format: TXT=7798 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1489) 1490 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. Brown, A. Malis. July 1993. (Format: TXT=75206 bytes) (Obsoletes RFC1294) (Obsoleted by RFC2427) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1490) 1491 A Survey of Advanced Usages of X.500. C. Weider, R. Wright. July 1993. (Format: TXT=34883 bytes) (Also FYI0021) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1491) 1492 An Access Control Protocol, Sometimes Called TACACS. C. Finseth. July 1993. (Format: TXT=41880 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1492) 1493 Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. July 1993. (Format: TXT=74493 bytes) (Obsoletes RFC1286) (Obsoleted by RFC4188) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1493) 1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies. H. Alvestrand, S. Thompson. August 1993. (Format: TXT=37273 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1494) 1495 Mapping between X.400 and RFC-822 Message Bodies. H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson. August 1993. (Format: TXT=20071 bytes) (Obsoleted by RFC2156) (Updates RFC1327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1495) 1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages. H. Alvestrand, J. Romaguera, K. Jordan. August 1993. (Format: TXT=8411 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1496) 1497 BOOTP Vendor Information Extensions. J. Reynolds. August 1993. (Format: TXT=16805 bytes) (Obsoletes RFC1395, RFC1084, RFC1048) (Obsoleted by RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1497) 1498 On the Naming and Binding of Network Destinations. J. Saltzer. August 1993. (Format: TXT=24698 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1498) 1499 Summary of 1400-1499. J. Elliott. January 1997. (Format: TXT=40923 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1499) 1500 Internet Official Protocol Standards. J. Postel. August 1993. (Format: TXT=79557 bytes) (Obsoletes RFC1410) (Obsoleted by RFC1540) (Status: HISTORIC) (DOI: 10.17487/RFC1500) 1501 OS/2 User Group. E. Brunsen. August 1993. (Format: TXT=3636 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1501) 1502 X.400 Use of Extended Character Sets. H. Alvestrand. August 1993. (Format: TXT=27976 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1502) 1503 Algorithms for Automating Administration in SNMPv2 Managers. K. McCloghrie, M. Rose. August 1993. (Format: TXT=33542 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1503) 1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing. A. Oppenheimer. August 1993. (Format: TXT=201553 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1504) 1505 Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. Ullmann. August 1993. (Format: TXT=63796 bytes) (Obsoletes RFC1154) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1505) 1506 A Tutorial on Gatewaying between X.400 and Internet Mail. J. Houttuin. August 1993. (Format: TXT=85550 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1506) 1507 DASS - Distributed Authentication Security Service. C. Kaufman. September 1993. (Format: TXT=287809 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1507) 1508 Generic Security Service Application Program Interface. J. Linn. September 1993. (Format: TXT=111228 bytes) (Obsoleted by RFC2078) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1508) 1509 Generic Security Service API : C-bindings. J. Wray. September 1993. (Format: TXT=99608 bytes) (Obsoleted by RFC2744) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1509) 1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. September 1993. (Format: TXT=275395 bytes) (Obsoleted by RFC4120, RFC6649) (Status: HISTORIC) (DOI: 10.17487/RFC1510) 1511 Common Authentication Technology Overview. J. Linn. September 1993. (Format: TXT=4185 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1511) 1512 FDDI Management Information Base. J. Case, A. Rijsinghani. September 1993. (Format: TXT=108589 bytes) (Updates RFC1285) (Status: HISTORIC) (DOI: 10.17487/RFC1512) 1513 Token Ring Extensions to the Remote Network Monitoring MIB. S. Waldbusser. September 1993. (Format: TXT=121974 bytes) (Updates RFC1271) (Status: HISTORIC) (DOI: 10.17487/RFC1513) 1514 Host Resources MIB. P. Grillo, S. Waldbusser. September 1993. (Format: TXT=63775 bytes) (Obsoleted by RFC2790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1514) 1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). D. McMaster, K. McCloghrie, S. Roberts. September 1993. (Format: TXT=52828 bytes) (Obsoleted by RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1515) 1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices. D. McMaster, K. McCloghrie. September 1993. (Format: TXT=82918 bytes) (Obsoletes RFC1368) (Obsoleted by RFC2108) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1516) 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R. Hinden. September 1993. (Format: TXT=7357 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1517) 1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, T. Li. September 1993. (Format: TXT=72609 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1518) 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338) (Obsoleted by RFC4632) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1519) 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment. Y. Rekhter, C. Topolcic. September 1993. (Format: TXT=20389 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1520) 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein, N. Freed. September 1993. (Format: TXT=187424, PS=393670, PDF=205091 bytes) (Obsoletes RFC1341) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updated by RFC1590) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1521) 1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. K. Moore. September 1993. (Format: TXT=22502 bytes) (Obsoletes RFC1342) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1522) 1523 The text/enriched MIME Content-type. N. Borenstein. September 1993. (Format: TXT=32691 bytes) (Obsoleted by RFC1563, RFC1896) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1523) 1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information. N. Borenstein. September 1993. (Format: TXT=26464 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1524) 1525 Definitions of Managed Objects for Source Routing Bridges. E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani. September 1993. (Format: TXT=38100 bytes) (Obsoletes RFC1286) (Status: HISTORIC) (DOI: 10.17487/RFC1525) 1526 Assignment of System Identifiers for TUBA/CLNP Hosts. D. Piscitello. September 1993. (Format: TXT=16848 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1526) 1527 What Should We Plan Given the Dilemma of the Network?. G. Cook. September 1993. (Format: TXT=46935 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1527) 1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures. C. Malamud, M. Rose. October 1993. (Format: TXT=18576 bytes) (Obsoletes RFC1486) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1528) 1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies. C. Malamud, M. Rose. October 1993. (Format: TXT=11142 bytes) (Obsoletes RFC1486) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1529) 1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy. C. Malamud, M. Rose. October 1993. (Format: TXT=15031 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1530) 1531 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT=96192 bytes) (Obsoleted by RFC1541) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1531) 1532 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Format: TXT=51545 bytes) (Obsoleted by RFC1542) (Updates RFC0951) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1532) 1533 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. October 1993. (Format: TXT=50919 bytes) (Obsoletes RFC1497, RFC1395, RFC1084, RFC1048) (Obsoleted by RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1533) 1534 Interoperation Between DHCP and BOOTP. R. Droms. October 1993. (Format: TXT=6966 bytes) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1534) 1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software. E. Gavron. October 1993. (Format: TXT=9722 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1535) 1536 Common DNS Implementation Errors and Suggested Fixes. A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller. October 1993. (Format: TXT=25476 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1536) 1537 Common DNS Data File Configuration Errors. P. Beertema. October 1993. (Format: TXT=19825 bytes) (Obsoleted by RFC1912) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1537) 1538 Advanced SNA/IP : A Simple SNA Transport Protocol. W. Behl, B. Sterling, W. Teskey. October 1993. (Format: TXT=21217 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1538) 1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force. G. Malkin. October 1993. (Format: TXT=48199 bytes) (Obsoletes RFC1391) (Obsoleted by RFC1718) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1539) 1540 Internet Official Protocol Standards. J. Postel. October 1993. (Format: TXT=75496 bytes) (Obsoletes RFC1500) (Obsoleted by RFC1600) (Status: HISTORIC) (DOI: 10.17487/RFC1540) 1541 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT=96950 bytes) (Obsoletes RFC1531) (Obsoleted by RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1541) 1542 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Format: TXT=52948 bytes) (Obsoletes RFC1532) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1542) 1543 Instructions to RFC Authors. J. Postel. October 1993. (Format: TXT=31383 bytes) (Obsoletes RFC1111, RFC0825) (Obsoleted by RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1543) 1544 The Content-MD5 Header Field. M. Rose. November 1993. (Format: TXT=6478 bytes) (Obsoleted by RFC1864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1544) 1545 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. November 1993. (Format: TXT=8985 bytes) (Obsoleted by RFC1639) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1545) 1546 Host Anycasting Service. C. Partridge, T. Mendez, W. Milliken. November 1993. (Format: TXT=22263 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1546) 1547 Requirements for an Internet Standard Point-to-Point Protocol. D. Perkins. December 1993. (Format: TXT=49810 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1547) 1548 The Point-to-Point Protocol (PPP). W. Simpson. December 1993. (Format: TXT=111638 bytes) (Obsoletes RFC1331) (Obsoleted by RFC1661) (Updated by RFC1570) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1548) 1549 PPP in HDLC Framing. W. Simpson, Ed.. December 1993. (Format: TXT=36352 bytes) (Obsoleted by RFC1662) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1549) 1550 IP: Next Generation (IPng) White Paper Solicitation. S. Bradner, A. Mankin. December 1993. (Format: TXT=12472 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1550) 1551 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. December 1993. (Format: TXT=54210 bytes) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1551) 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP). W. Simpson. December 1993. (Format: TXT=29173 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1552) 1553 Compressing IPX Headers Over WAN Media (CIPX). S. Mathur, M. Lewis. December 1993. (Format: TXT=47450 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1553) 1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP. M. Ohta, K. Handa. December 1993. (Format: TXT=11449 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1554) 1555 Hebrew Character Encoding for Internet Messages. H. Nussbacher, Y. Bourvine. December 1993. (Format: TXT=9273 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1555) 1556 Handling of Bi-directional Texts in MIME. H. Nussbacher. December 1993. (Format: TXT=5602 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1556) 1557 Korean Character Encoding for Internet Messages. U. Choi, K. Chon, H. Park. December 1993. (Format: TXT=8736 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1557) 1558 A String Representation of LDAP Search Filters. T. Howes. December 1993. (Format: TXT=5239 bytes) (Obsoleted by RFC1960) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1558) 1559 DECnet Phase IV MIB Extensions. J. Saperia. December 1993. (Format: TXT=125427 bytes) (Obsoletes RFC1289) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1559) 1560 The MultiProtocol Internet. B. Leiner, Y. Rekhter. December 1993. (Format: TXT=16651 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1560) 1561 Use of ISO CLNP in TUBA Environments. D. Piscitello. December 1993. (Format: TXT=55902 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1561) 1562 Naming Guidelines for the AARNet X.500 Directory Service. G. Michaelson, M. Prior. December 1993. (Format: TXT=6884 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1562) 1563 The text/enriched MIME Content-type. N. Borenstein. January 1994. (Format: TXT=32913, PS=73543, PDF=37459 bytes) (Obsoletes RFC1523) (Obsoleted by RFC1896) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1563) 1564 DSA Metrics (OSI-DS 34 (v3)). P. Barker, R. Hedberg. January 1994. (Format: TXT=46205 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1564) 1565 Network Services Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT=29761 bytes) (Obsoleted by RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1565) 1566 Mail Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT=33136 bytes) (Obsoleted by RFC2249, RFC2789) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1566) 1567 X.500 Directory Monitoring MIB. G. Mansfield, S. Kille. January 1994. (Format: TXT=33527 bytes) (Obsoleted by RFC2605) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1567) 1568 Simple Network Paging Protocol - Version 1(b). A. Gwinn. January 1994. (Format: TXT=16558 bytes) (Obsoleted by RFC1645) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1568) 1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures. M. Rose. January 1994. (Format: TXT=12597 bytes) (Obsoleted by RFC1703) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1569) 1570 PPP LCP Extensions. W. Simpson, Ed.. January 1994. (Format: TXT=35719 bytes) (Updates RFC1548) (Updated by RFC2484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1570) 1571 Telnet Environment Option Interoperability Issues. D. Borman. January 1994. (Format: TXT=8117 bytes) (Updates RFC1408) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1571) 1572 Telnet Environment Option. S. Alexander, Ed.. January 1994. (Format: TXT=14676 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1572) 1573 Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F. Kastenholz. January 1994. (Format: TXT=123057 bytes) (Obsoletes RFC1229) (Obsoleted by RFC2233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1573) 1574 Essential Tools for the OSI Internet. S. Hares, C. Wittbrodt. February 1994. (Format: TXT=27735 bytes) (Obsoletes RFC1139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1574) 1575 An Echo Function for CLNP (ISO 8473). S. Hares, C. Wittbrodt. February 1994. (Format: TXT=22479 bytes) (Obsoletes RFC1139) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1575) 1576 TN3270 Current Practices. J. Penner. January 1994. (Format: TXT=24477 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1576) 1577 Classical IP and ARP over ATM. M. Laubach. January 1994. (Format: TXT=41239 bytes) (Obsoleted by RFC2225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1577) 1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions. J. Sellers. February 1994. (Format: TXT=113646 bytes) (Obsoleted by RFC1941) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1578) 1579 Firewall-Friendly FTP. S. Bellovin. February 1994. (Format: TXT=8806 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1579) 1580 Guide to Network Resource Tools. EARN Staff. March 1994. (Format: TXT=235112 bytes) (Also FYI0023) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1580) 1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT=7536 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1581) 1582 Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT=63271 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1582) 1583 OSPF Version 2. J. Moy. March 1994. (Format: TXT=532636, PS=990794, PDF=465711 bytes) (Obsoletes RFC1247) (Obsoleted by RFC2178) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1583) 1584 Multicast Extensions to OSPF. J. Moy. March 1994. (Format: TXT=262463, PS=426358, PDF=243185 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1584) 1585 MOSPF: Analysis and Experience. J. Moy. March 1994. (Format: TXT=29754 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1585) 1586 Guidelines for Running OSPF Over Frame Relay Networks. O. deSouza, M. Rodrigues. March 1994. (Format: TXT=14968 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1586) 1587 The OSPF NSSA Option. R. Coltun, V. Fuller. March 1994. (Format: TXT=37412 bytes) (Obsoleted by RFC3101) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1587) 1588 White Pages Meeting Report. J. Postel, C. Anderson. February 1994. (Format: TXT=77945 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1588) 1589 A Kernel Model for Precision Timekeeping. D. Mills. March 1994. (Format: TXT=88129 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1589) 1590 Media Type Registration Procedure. J. Postel. March 1994. (Format: TXT=13044 bytes) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updates RFC1521) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1590) 1591 Domain Name System Structure and Delegation. J. Postel. March 1994. (Format: TXT=16481 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1591) 1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0. B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters. March 1994. (Format: TXT=135259 bytes) (Obsoletes RFC1228) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1592) 1593 SNA APPN Node MIB. W. McKenzie, J. Cheng. March 1994. (Format: TXT=207882 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1593) 1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions. A. Marine, J. Reynolds, G. Malkin. March 1994. (Format: TXT=98753 bytes) (Obsoletes RFC1325) (Obsoleted by RFC2664) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1594) 1595 Definitions of Managed Objects for the SONET/SDH Interface Type. T. Brown, K. Tesink. March 1994. (Format: TXT=121937 bytes) (Obsoleted by RFC2558) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1595) 1596 Definitions of Managed Objects for Frame Relay Service. T. Brown, Ed.. March 1994. (Format: TXT=88795 bytes) (Obsoleted by RFC1604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1596) 1597 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot. March 1994. (Format: TXT=17430 bytes) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1597) 1598 PPP in X.25. W. Simpson. March 1994. (Format: TXT=13835 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1598) 1599 Summary of 1500-1599. M. Kennedy. January 1997. (Format: TXT=43761 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1599) 1600 Internet Official Protocol Standards. J. Postel. March 1994. (Format: TXT=80958 bytes) (Obsoletes RFC1540) (Obsoleted by RFC1610) (Status: HISTORIC) (DOI: 10.17487/RFC1600) 1601 Charter of the Internet Architecture Board (IAB). C. Huitema. March 1994. (Format: TXT=12424 bytes) (Obsoletes RFC1358) (Obsoleted by RFC2850) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1601) 1602 The Internet Standards Process -- Revision 2. Internet Architecture Board, Internet Engineering Steering Group. March 1994. (Format: TXT=88465 bytes) (Obsoletes RFC1310) (Obsoleted by RFC2026) (Updated by RFC1871) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1602) 1603 IETF Working Group Guidelines and Procedures. E. Huizer, D. Crocker. March 1994. (Format: TXT=63900 bytes) (Obsoleted by RFC2418) (Updated by RFC1871) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1603) 1604 Definitions of Managed Objects for Frame Relay Service. T. Brown, Ed.. March 1994. (Format: TXT=88770 bytes) (Obsoletes RFC1596) (Obsoleted by RFC2954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1604) 1605 SONET to Sonnet Translation. W. Shakespeare. April 1994. (Format: TXT=4451 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1605) 1606 A Historical Perspective On The Usage Of IP Version 9. J. Onions. April 1994. (Format: TXT=8398 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1606) 1607 A VIEW FROM THE 21ST CENTURY. V. Cerf. April 1994. (Format: TXT=28165 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1607) 1608 Representing IP Information in the X.500 Directory. T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri. March 1994. (Format: TXT=40269 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1608) 1609 Charting Networks in the X.500 Directory. G. Mansfield, T. Johannsen, M. Knopper. March 1994. (Format: TXT=30044 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1609) 1610 Internet Official Protocol Standards. J. Postel. July 1994. (Format: TXT=81346 bytes) (Obsoletes RFC1600) (Obsoleted by RFC1720) (Status: HISTORIC) (DOI: 10.17487/RFC1610) 1611 DNS Server MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT=58700 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1611) 1612 DNS Resolver MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT=61382 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1612) 1613 cisco Systems X.25 over TCP (XOT). J. Forster, G. Satz, G. Glick, R. Day. May 1994. (Format: TXT=29267 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1613) 1614 Network Access to Multimedia Information. C. Adie. May 1994. (Format: TXT=187253 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1614) 1615 Migrating from X.400(84) to X.400(88). J. Houttuin, J. Craigie. May 1994. (Format: TXT=39693 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1615) 1616 X.400(1988) for the Academic and Research Community in Europe. RARE WG-MSG Task Force 88, E. Huizer, Ed., J. Romaguera, Ed.. May 1994. (Format: TXT=107432 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1616) 1617 Naming and Structuring Guidelines for X.500 Directory Pilots. P. Barker, S. Kille, T. Lenggenhager. May 1994. (Format: TXT=56739 bytes) (Obsoletes RFC1384) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1617) 1618 PPP over ISDN. W. Simpson. May 1994. (Format: TXT=14896 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1618) 1619 PPP over SONET/SDH. W. Simpson. May 1994. (Format: TXT=8893 bytes) (Obsoleted by RFC2615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1619) 1620 Internet Architecture Extensions for Shared Media. B. Braden, J. Postel, Y. Rekhter. May 1994. (Format: TXT=44999 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1620) 1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: TXT=128905 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1621) 1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT=34837 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1622) 1623 Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. May 1994. (Format: TXT=38745 bytes) (Obsoletes RFC1398) (Obsoleted by RFC1643) (Status: HISTORIC) (DOI: 10.17487/RFC1623) 1624 Computation of the Internet Checksum via Incremental Update. A. Rijsinghani, Ed.. May 1994. (Format: TXT=9836 bytes) (Updates RFC1141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1624) 1625 WAIS over Z39.50-1988. M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte. June 1994. (Format: TXT=14694 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1625) 1626 Default IP MTU for use over ATM AAL5. R. Atkinson. May 1994. (Format: TXT=11841 bytes) (Obsoleted by RFC2225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1626) 1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified). E. Lear, E. Fair, D. Crocker, T. Kessler. July 1994. (Format: TXT=18823 bytes) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1627) 1628 UPS Management Information Base. J. Case, Ed.. May 1994. (Format: TXT=83439 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1628) 1629 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, R. Callon, E. Gardner, Y. Rekhter. May 1994. (Format: TXT=131640 bytes) (Obsoletes RFC1237) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1629) 1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web. T. Berners-Lee. June 1994. (Format: TXT=57601 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1630) 1631 The IP Network Address Translator (NAT). K. Egevang, P. Francis. May 1994. (Format: TXT=22714 bytes) (Obsoleted by RFC3022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1631) 1632 A Revised Catalog of Available X.500 Implementations. A. Getchell, Ed., S. Sataluri, Ed.. May 1994. (Format: TXT=124111 bytes) (Obsoletes RFC1292) (Obsoleted by RFC2116) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1632) 1633 Integrated Services in the Internet Architecture: an Overview. R. Braden, D. Clark, S. Shenker. June 1994. (Format: TXT=89691, PS=207016, PDF=201858 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1633) 1634 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. May 1994. (Format: TXT=55347 bytes) (Obsoletes RFC1551, RFC1362) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1634) 1635 How to Use Anonymous FTP. P. Deutsch, A. Emtage, A. Marine. May 1994. (Format: TXT=27258 bytes) (Also FYI0024) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1635) 1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994. R. Braden, D. Clark, S. Crocker, C. Huitema. June 1994. (Format: TXT=130761 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1636) 1637 DNS NSAP Resource Records. B. Manning, R. Colella. June 1994. (Format: TXT=21768 bytes) (Obsoletes RFC1348) (Obsoleted by RFC1706) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1637) 1638 PPP Bridging Control Protocol (BCP). F. Baker, R. Bowen. June 1994. (Format: TXT=58477 bytes) (Obsoletes RFC1220) (Obsoleted by RFC2878) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1638) 1639 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. June 1994. (Format: TXT=10055 bytes) (Obsoletes RFC1545) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1639) 1640 The Process for Organization of Internet Standards Working Group (POISED). S. Crocker. June 1994. (Format: TXT=21780 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1640) 1641 Using Unicode with MIME. D. Goldsmith, M. Davis. July 1994. (Format: TXT=11258, PS=20451, PDF=11658 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1641) 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode. D. Goldsmith, M. Davis. July 1994. (Format: TXT=27770, PS=50907, PDF=29573 bytes) (Obsoleted by RFC2152) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1642) 1643 Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. July 1994. (Format: TXT=39008 bytes) (Obsoletes RFC1623) (Obsoleted by RFC3638) (Status: HISTORIC) (DOI: 10.17487/RFC1643) 1644 T/TCP -- TCP Extensions for Transactions Functional Specification. R. Braden. July 1994. (Format: TXT=87362 bytes) (Obsoleted by RFC6247) (Updates RFC1379) (Status: HISTORIC) (DOI: 10.17487/RFC1644) 1645 Simple Network Paging Protocol - Version 2. A. Gwinn. July 1994. (Format: TXT=31243 bytes) (Obsoletes RFC1568) (Obsoleted by RFC1861) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1645) 1646 TN3270 Extensions for LUname and Printer Selection. C. Graves, T. Butts, M. Angel. July 1994. (Format: TXT=27564 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1646) 1647 TN3270 Enhancements. B. Kelly. July 1994. (Format: TXT=84420 bytes) (Obsoleted by RFC2355) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1647) 1648 Postmaster Convention for X.400 Operations. A. Cargille. July 1994. (Format: TXT=8761 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1648) 1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community. R. Hagens, A. Hansen. July 1994. (Format: TXT=28138 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1649) 1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2. F. Kastenholz. August 1994. (Format: TXT=40484 bytes) (Obsoleted by RFC2358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1650) 1651 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: TXT=22153 bytes) (Obsoletes RFC1425) (Obsoleted by RFC1869) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1651) 1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: TXT=11842 bytes) (Obsoletes RFC1426) (Obsoleted by RFC6152) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1652) 1653 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. July 1994. (Format: TXT=17883 bytes) (Obsoletes RFC1427) (Obsoleted by RFC1870) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1653) 1654 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed.. July 1994. (Format: TXT=130118 bytes) (Obsoleted by RFC1771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1654) 1655 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, Ed., P. Gross, Ed.. July 1994. (Format: TXT=43664 bytes) (Obsoletes RFC1268) (Obsoleted by RFC1772) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1655) 1656 BGP-4 Protocol Document Roadmap and Implementation Experience. P. Traina. July 1994. (Format: TXT=7705 bytes) (Obsoleted by RFC1773) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1656) 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss, J. Chu, Ed.. July 1994. (Format: TXT=45505 bytes) (Obsoleted by RFC4273) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1657) 1658 Definitions of Managed Objects for Character Stream Devices using SMIv2. B. Stewart. July 1994. (Format: TXT=32579 bytes) (Obsoletes RFC1316) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1658) 1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2. B. Stewart. July 1994. (Format: TXT=36479 bytes) (Obsoletes RFC1317) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1659) 1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2. B. Stewart. July 1994. (Format: TXT=16784 bytes) (Obsoletes RFC1318) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1660) 1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994. (Format: TXT=103026 bytes) (Obsoletes RFC1548) (Updated by RFC2153) (Also STD0051) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1661) 1662 PPP in HDLC-like Framing. W. Simpson, Ed.. July 1994. (Format: TXT=48058 bytes) (Obsoletes RFC1549) (Also STD0051) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1662) 1663 PPP Reliable Transmission. D. Rand. July 1994. (Format: TXT=17281 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1663) 1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables. C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. August 1994. (Format: TXT=50783 bytes) (Obsoleted by RFC2163) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1664) 1665 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. July 1994. (Format: TXT=133381 bytes) (Obsoleted by RFC1666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1665) 1666 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. August 1994. (Format: TXT=134385 bytes) (Obsoletes RFC1665) (Status: HISTORIC) (DOI: 10.17487/RFC1666) 1667 Modeling and Simulation Requirements for IPng. S. Symington, D. Wood, M. Pullen. August 1994. (Format: TXT=17291 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1667) 1668 Unified Routing Requirements for IPng. D. Estrin, T. Li, Y. Rekhter. August 1994. (Format: TXT=5106 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1668) 1669 Market Viability as a IPng Criteria. J. Curran. August 1994. (Format: TXT=8099 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1669) 1670 Input to IPng Engineering Considerations. D. Heagerty. August 1994. (Format: TXT=5350 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1670) 1671 IPng White Paper on Transition and Other Considerations. B. Carpenter. August 1994. (Format: TXT=17631 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1671) 1672 Accounting Requirements for IPng. N. Brownlee. August 1994. (Format: TXT=6185 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1672) 1673 Electric Power Research Institute Comments on IPng. R. Skelton. August 1994. (Format: TXT=7476 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1673) 1674 A Cellular Industry View of IPng. M. Taylor. August 1994. (Format: TXT=6157 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1674) 1675 Security Concerns for IPng. S. Bellovin. August 1994. (Format: TXT=8290 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1675) 1676 INFN Requirements for an IPng. A. Ghiselli, D. Salomoni, C. Vistoli. August 1994. (Format: TXT=8493 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1676) 1677 Tactical Radio Frequency Communication Requirements for IPng. B. Adamson. August 1994. (Format: TXT=24065 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1677) 1678 IPng Requirements of Large Corporate Networks. E. Britton, J. Tavs. August 1994. (Format: TXT=18650 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1678) 1679 HPN Working Group Input to the IPng Requirements Solicitation. D. Green, P. Irey, D. Marlow, K. O'Donoghue. August 1994. (Format: TXT=22974 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1679) 1680 IPng Support for ATM Services. C. Brazdziunas. August 1994. (Format: TXT=17846 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1680) 1681 On Many Addresses per Host. S. Bellovin. August 1994. (Format: TXT=11964 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1681) 1682 IPng BSD Host Implementation Analysis. J. Bound. August 1994. (Format: TXT=22295 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1682) 1683 Multiprotocol Interoperability In IPng. R. Clark, M. Ammar, K. Calvert. August 1994. (Format: TXT=28201 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1683) 1684 Introduction to White Pages Services based on X.500. P. Jurg. August 1994. (Format: TXT=22985 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1684) 1685 Writing X.400 O/R Names. H. Alvestrand. August 1994. (Format: TXT=21242 bytes) (Also RTR0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1685) 1686 IPng Requirements: A Cable Television Industry Viewpoint. M. Vecchi. August 1994. (Format: TXT=39052 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1686) 1687 A Large Corporate User's View of IPng. E. Fleischman. August 1994. (Format: TXT=34120 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1687) 1688 IPng Mobility Considerations. W. Simpson. August 1994. (Format: TXT=19151 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1688) 1689 A Status Report on Networked Information Retrieval: Tools and Groups. J. Foster, Ed.. August 1994. (Format: TXT=375469 bytes) (Also FYI0025) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1689) 1690 Introducing the Internet Engineering and Planning Group (IEPG). G. Huston. August 1994. (Format: TXT=3013 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1690) 1691 The Document Architecture for the Cornell Digital Library. W. Turner. August 1994. (Format: TXT=20438 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1691) 1692 Transport Multiplexing Protocol (TMux). P. Cameron, D. Crocker, D. Cohen, J. Postel. August 1994. (Format: TXT=26163 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1692) 1693 An Extension to TCP : Partial Order Service. T. Connolly, P. Amer, P. Conrad. November 1994. (Format: TXT=90100 bytes) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1693) 1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2. T. Brown, Ed., K. Tesink, Ed.. August 1994. (Format: TXT=70856 bytes) (Obsoletes RFC1304) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1694) 1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2. M. Ahmed, Ed., K. Tesink, Ed.. August 1994. (Format: TXT=175461 bytes) (Obsoleted by RFC2515) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1695) 1696 Modem Management Information Base (MIB) using SMIv2. J. Barnes, L. Brown, R. Royston, S. Waldbusser. August 1994. (Format: TXT=54054 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1696) 1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2. D. Brower, Ed., B. Purvy, A. Daniel, M. Sinykin, J. Smith. August 1994. (Format: TXT=76202 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1697) 1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications. P. Furniss. October 1994. (Format: TXT=67433 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1698) 1699 Summary of 1600-1699. J. Elliott. January 1997. (Format: TXT=40674 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1699) 1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format: TXT=458860 bytes) (Obsoletes RFC1340) (Obsoleted by RFC3232) (Status: HISTORIC) (DOI: 10.17487/RFC1700) 1701 Generic Routing Encapsulation (GRE). S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994. (Format: TXT=15460 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1701) 1702 Generic Routing Encapsulation over IPv4 networks. S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994. (Format: TXT=7288 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1702) 1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures. M. Rose. October 1994. (Format: TXT=17985 bytes) (Obsoletes RFC1569) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1703) 1704 On Internet Authentication. N. Haller, R. Atkinson. October 1994. (Format: TXT=42269 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1704) 1705 Six Virtual Inches to the Left: The Problem with IPng. R. Carlson, D. Ficarella. October 1994. (Format: TXT=65222 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1705) 1706 DNS NSAP Resource Records. B. Manning, R. Colella. October 1994. (Format: TXT=19721 bytes) (Obsoletes RFC1637) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1706) 1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. Ullmann. October 1994. (Format: TXT=37568 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1707) 1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3. D. Gowin. October 1994. (Format: TXT=26523 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1708) 1709 K-12 Internetworking Guidelines. J. Gargano, D. Wasley. November 1994. (Format: TXT=66659, PS=662030, PDF=134065 bytes) (Also FYI0026) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1709) 1710 Simple Internet Protocol Plus White Paper. R. Hinden. October 1994. (Format: TXT=56910 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1710) 1711 Classifications in E-mail Routing. J. Houttuin. October 1994. (Format: TXT=47584 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1711) 1712 DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. Pleitner, D. Baldoni. November 1994. (Format: TXT=13237 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1712) 1713 Tools for DNS debugging. A. Romao. November 1994. (Format: TXT=33500 bytes) (Also FYI0027) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1713) 1714 Referral Whois Protocol (RWhois). S. Williamson, M. Kosters. November 1994. (Format: TXT=85395, PS=204207, PDF=85556 bytes) (Obsoleted by RFC2167) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1714) 1715 The H Ratio for Address Assignment Efficiency. C. Huitema. November 1994. (Format: TXT=7392 bytes) (Updated by RFC3194) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1715) 1716 Towards Requirements for IP Routers. P. Almquist, F. Kastenholz. November 1994. (Format: TXT=432330 bytes) (Obsoleted by RFC1812) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1716) 1717 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr. November 1994. (Format: TXT=46264 bytes) (Obsoleted by RFC1990) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1717) 1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force. IETF Secretariat, G. Malkin. November 1994. (Format: TXT=50458 bytes) (Obsoletes RFC1539) (Obsoleted by RFC3160) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1718) 1719 A Direction for IPng. P. Gross. December 1994. (Format: TXT=11118 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1719) 1720 Internet Official Protocol Standards. J. Postel. November 1994. (Format: TXT=89063 bytes) (Obsoletes RFC1610) (Obsoleted by RFC1780) (Status: HISTORIC) (DOI: 10.17487/RFC1720) 1721 RIP Version 2 Protocol Analysis. G. Malkin. November 1994. (Format: TXT=6680 bytes) (Obsoletes RFC1387) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1721) 1722 RIP Version 2 Protocol Applicability Statement. G. Malkin. November 1994. (Format: TXT=10236 bytes) (Also STD0057) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1722) 1723 RIP Version 2 - Carrying Additional Information. G. Malkin. November 1994. (Format: TXT=18597 bytes) (Obsoletes RFC1388) (Obsoleted by RFC2453) (Updates RFC1058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1723) 1724 RIP Version 2 MIB Extension. G. Malkin, F. Baker. November 1994. (Format: TXT=29645 bytes) (Obsoletes RFC1389) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1724) 1725 Post Office Protocol - Version 3. J. Myers, M. Rose. November 1994. (Format: TXT=35058 bytes) (Obsoletes RFC1460) (Obsoleted by RFC1939) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1725) 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1726) 1727 A Vision of an Integrated Internet Information Service. C. Weider, P. Deutsch. December 1994. (Format: TXT=28468 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1727) 1728 Resource Transponders. C. Weider. December 1994. (Format: TXT=12092 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1728) 1729 Using the Z39.50 Information Retrieval Protocol. C. Lynch. December 1994. (Format: TXT=20927 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1729) 1730 Internet Message Access Protocol - Version 4. M. Crispin. December 1994. (Format: TXT=156660 bytes) (Obsoleted by RFC2060, RFC2061) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1730) 1731 IMAP4 Authentication Mechanisms. J. Myers. December 1994. (Format: TXT=11433 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1731) 1732 IMAP4 Compatibility with IMAP2 and IMAP2bis. M. Crispin. December 1994. (Format: TXT=9276 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1732) 1733 Distributed Electronic Mail Models in IMAP4. M. Crispin. December 1994. (Format: TXT=6205 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1733) 1734 POP3 AUTHentication command. J. Myers. December 1994. (Format: TXT=8499 bytes) (Obsoleted by RFC5034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1734) 1735 NBMA Address Resolution Protocol (NARP). J. Heinanen, R. Govindan. December 1994. (Format: TXT=24485 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1735) 1736 Functional Recommendations for Internet Resource Locators. J. Kunze. February 1995. (Format: TXT=22415 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1736) 1737 Functional Requirements for Uniform Resource Names. K. Sollins, L. Masinter. December 1994. (Format: TXT=16337 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1737) 1738 Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McCahill. December 1994. (Format: TXT=51348 bytes) (Obsoleted by RFC4248, RFC4266) (Updated by RFC1808, RFC2368, RFC2396, RFC3986, RFC6196, RFC6270) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1738) 1739 A Primer On Internet and TCP/IP Tools. G. Kessler, S. Shepard. December 1994. (Format: TXT=102676 bytes) (Obsoleted by RFC2151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1739) 1740 MIME Encapsulation of Macintosh Files - MacMIME. P. Faltstrom, D. Crocker, E. Fair. December 1994. (Format: TXT=31297 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1740) 1741 MIME Content Type for BinHex Encoded Files. P. Faltstrom, D. Crocker, E. Fair. December 1994. (Format: TXT=10155 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1741) 1742 AppleTalk Management Information Base II. S. Waldbusser, K. Frisa. January 1995. (Format: TXT=168306 bytes) (Obsoletes RFC1243) (Status: HISTORIC) (DOI: 10.17487/RFC1742) 1743 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT=43224 bytes) (Obsoletes RFC1231) (Obsoleted by RFC1748) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1743) 1744 Observations on the Management of the Internet Address Space. G. Huston. December 1994. (Format: TXT=32411 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1744) 1745 BGP4/IDRP for IP---OSPF Interaction. K. Varadhan, S. Hares, Y. Rekhter. December 1994. (Format: TXT=43675 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1745) 1746 Ways to Define User Expectations. B. Manning, D. Perkins. December 1994. (Format: TXT=46164 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1746) 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2. J. Hilgeman, S. Nix, A. Bartky, W. Clark, Ed.. January 1995. (Format: TXT=147388 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1747) 1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT=43224 bytes) (Obsoletes RFC1743, RFC1231) (Updated by RFC1749) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1748) 1749 IEEE 802.5 Station Source Routing MIB using SMIv2. K. McCloghrie, F. Baker, E. Decker. December 1994. (Format: TXT=17563 bytes) (Updates RFC1748) (Status: HISTORIC) (DOI: 10.17487/RFC1749) 1750 Randomness Recommendations for Security. D. Eastlake 3rd, S. Crocker, J. Schiller. December 1994. (Format: TXT=73842 bytes) (Obsoleted by RFC4086) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1750) 1751 A Convention for Human-Readable 128-bit Keys. D. McDonald. December 1994. (Format: TXT=31428 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1751) 1752 The Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin. January 1995. (Format: TXT=127784 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1752) 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture. N. Chiappa. December 1994. (Format: TXT=46586 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1753) 1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1. M. Laubach. January 1995. (Format: TXT=13483 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1754) 1755 ATM Signaling Support for IP over ATM. M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis. February 1995. (Format: TXT=55209 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1755) 1756 Remote Write Protocol - Version 1.0. T. Rinne. January 1995. (Format: TXT=22078 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1756) 1757 Remote Network Monitoring Management Information Base. S. Waldbusser. February 1995. (Format: TXT=208117 bytes) (Obsoletes RFC1271) (Obsoleted by RFC2819) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1757) 1758 NADF Standing Documents: A Brief Overview. The North American Directory Forum. February 1995. (Format: TXT=7294 bytes) (Obsoletes RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1758) 1759 Printer MIB. R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. March 1995. (Format: TXT=239228 bytes) (Obsoleted by RFC3805) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1759) 1760 The S/KEY One-Time Password System. N. Haller. February 1995. (Format: TXT=31124 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1760) 1761 Snoop Version 2 Packet Capture File Format. B. Callaghan, R. Gilligan. February 1995. (Format: TXT=10761 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1761) 1762 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. March 1995. (Format: TXT=12709 bytes) (Obsoletes RFC1376) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1762) 1763 The PPP Banyan Vines Control Protocol (BVCP). S. Senum. March 1995. (Format: TXT=17817 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1763) 1764 The PPP XNS IDP Control Protocol (XNSCP). S. Senum. March 1995. (Format: TXT=9525 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1764) 1765 OSPF Database Overflow. J. Moy. March 1995. (Format: TXT=21613 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1765) 1766 Tags for the Identification of Languages. H. Alvestrand. March 1995. (Format: TXT=16966 bytes) (Obsoleted by RFC3066, RFC3282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1766) 1767 MIME Encapsulation of EDI Objects. D. Crocker. March 1995. (Format: TXT=15293 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1767) 1768 Host Group Extensions for CLNP Multicasting. D. Marlow. March 1995. (Format: TXT=111499 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1768) 1769 Simple Network Time Protocol (SNTP). D. Mills. March 1995. (Format: TXT=34454 bytes) (Obsoletes RFC1361) (Obsoleted by RFC2030, RFC4330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1769) 1770 IPv4 Option for Sender Directed Multi-Destination Delivery. C. Graff. March 1995. (Format: TXT=11606 bytes) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1770) 1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. (Format: TXT=131903 bytes) (Obsoletes RFC1654) (Obsoleted by RFC4271) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1771) 1772 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. March 1995. (Format: TXT=43916 bytes) (Obsoletes RFC1655) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1772) 1773 Experience with the BGP-4 protocol. P. Traina. March 1995. (Format: TXT=19936 bytes) (Obsoletes RFC1656) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1773) 1774 BGP-4 Protocol Analysis. P. Traina, Ed.. March 1995. (Format: TXT=23823 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1774) 1775 To Be "On" the Internet. D. Crocker. March 1995. (Format: TXT=8454 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1775) 1776 The Address is the Message. S. Crocker. April 1995. (Format: TXT=2051 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1776) 1777 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. Kille. March 1995. (Format: TXT=45459 bytes) (Obsoletes RFC1487) (Obsoleted by RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1777) 1778 The String Representation of Standard Attribute Syntaxes. T. Howes, S. Kille, W. Yeong, C. Robbins. March 1995. (Format: TXT=19053 bytes) (Obsoletes RFC1488) (Obsoleted by RFC3494) (Updated by RFC2559) (Status: HISTORIC) (DOI: 10.17487/RFC1778) 1779 A String Representation of Distinguished Names. S. Kille. March 1995. (Format: TXT=12429 bytes) (Obsoletes RFC1485) (Obsoleted by RFC2253, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1779) 1780 Internet Official Protocol Standards. J. Postel, Ed.. March 1995. (Format: TXT=86594 bytes) (Obsoletes RFC1720) (Obsoleted by RFC1800) (Status: HISTORIC) (DOI: 10.17487/RFC1780) 1781 Using the OSI Directory to Achieve User Friendly Naming. S. Kille. March 1995. (Format: TXT=47129 bytes) (Obsoletes RFC1484) (Obsoleted by RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1781) 1782 TFTP Option Extension. G. Malkin, A. Harkin. March 1995. (Format: TXT=11508 bytes) (Obsoleted by RFC2347) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1782) 1783 TFTP Blocksize Option. G. Malkin, A. Harkin. March 1995. (Format: TXT=7814 bytes) (Obsoleted by RFC2348) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1783) 1784 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. March 1995. (Format: TXT=6106 bytes) (Obsoleted by RFC2349) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1784) 1785 TFTP Option Negotiation Analysis. G. Malkin, A. Harkin. March 1995. (Format: TXT=3354 bytes) (Updates RFC1350) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1785) 1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++). T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu. March 1995. (Format: TXT=133643 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1786) 1787 Routing in a Multi-provider Internet. Y. Rekhter. April 1995. (Format: TXT=20754 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1787) 1788 ICMP Domain Name Messages. W. Simpson. April 1995. (Format: TXT=11722 bytes) (Obsoleted by RFC6918) (Status: HISTORIC) (DOI: 10.17487/RFC1788) 1789 INETPhone: Telephone Services and Servers on Internet. C. Yang. April 1995. (Format: TXT=14186 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1789) 1790 An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols. V. Cerf. April 1995. (Format: TXT=8226 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1790) 1791 TCP And UDP Over IPX Networks With Fixed Path MTU. T. Sung. April 1995. (Format: TXT=22347 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1791) 1792 TCP/IPX Connection Mib Specification. T. Sung. April 1995. (Format: TXT=16389 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1792) 1793 Extending OSPF to Support Demand Circuits. J. Moy. April 1995. (Format: TXT=78728 bytes) (Updated by RFC3883) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1793) 1794 DNS Support for Load Balancing. T. Brisco. April 1995. (Format: TXT=15494 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1794) 1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1. L. Wells, A. Bartky, Ed.. April 1995. (Format: TXT=214848 bytes) (Obsoletes RFC1434) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1795) 1796 Not All RFCs are Standards. C. Huitema, J. Postel, S. Crocker. April 1995. (Format: TXT=7049 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1796) 1797 Class A Subnet Experiment. Internet Assigned Numbers Authority (IANA). April 1995. (Format: TXT=6779 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1797) 1798 Connection-less Lightweight X.500 Directory Access Protocol. A. Young. June 1995. (Format: TXT=18548 bytes) (Obsoleted by RFC3352) (Status: HISTORIC) (DOI: 10.17487/RFC1798) 1799 Request for Comments Summary RFC Numbers 1700-1799. M. Kennedy. January 1997. (Format: TXT=42038 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1799) 1800 Internet Official Protocol Standards. J. Postel, Ed.. July 1995. (Format: TXT=83649 bytes) (Obsoletes RFC1780) (Obsoleted by RFC1880) (Status: HISTORIC) (DOI: 10.17487/RFC1800) 1801 MHS use of the X.500 Directory to support MHS Routing. S. Kille. June 1995. (Format: TXT=156462 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1801) 1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing. H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera. June 1995. (Format: TXT=24637 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1802) 1803 Recommendations for an X.500 Production Directory Service. R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong. June 1995. (Format: TXT=14721 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1803) 1804 Schema Publishing in X.500 Directory. G. Mansfield, P. Rajeev, S. Raghavan, T. Howes. June 1995. (Format: TXT=18268 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1804) 1805 Location-Independent Data/Software Integrity Protocol. A. Rubin. June 1995. (Format: TXT=13352 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1805) 1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header. R. Troost, S. Dorner. June 1995. (Format: TXT=15548 bytes) (Obsoleted by RFC2183) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1806) 1807 A Format for Bibliographic Records. R. Lasher, D. Cohen. June 1995. (Format: TXT=29417 bytes) (Obsoletes RFC1357) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1807) 1808 Relative Uniform Resource Locators. R. Fielding. June 1995. (Format: TXT=34950 bytes) (Obsoleted by RFC3986) (Updates RFC1738) (Updated by RFC2368, RFC2396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1808) 1809 Using the Flow Label Field in IPv6. C. Partridge. June 1995. (Format: TXT=13591 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1809) 1810 Report on MD5 Performance. J. Touch. June 1995. (Format: TXT=16607 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1810) 1811 U.S. Government Internet Domain Names. Federal Networking Council. June 1995. (Format: TXT=6641 bytes) (Obsoleted by RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1811) 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1812) 1813 NFS Version 3 Protocol Specification. B. Callaghan, B. Pawlowski, P. Staubach. June 1995. (Format: TXT=229793 bytes) (Also RFC1094) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1813) 1814 Unique Addresses are Good. E. Gerich. June 1995. (Format: TXT=5936 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1814) 1815 Character Sets ISO-10646 and ISO-10646-J-1. M. Ohta. July 1995. (Format: TXT=11823 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1815) 1816 U.S. Government Internet Domain Names. Federal Networking Council. August 1995. (Format: TXT=17979 bytes) (Obsoletes RFC1811) (Obsoleted by RFC2146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1816) 1817 CIDR and Classful Routing. Y. Rekhter. August 1995. (Format: TXT=3416 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1817) 1818 Best Current Practices. J. Postel, T. Li, Y. Rekhter. August 1995. (Format: TXT=4114 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1818) 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+. L. Delgrossi, Ed., L. Berger, Ed.. August 1995. (Format: TXT=266875 bytes) (Obsoletes RFC1190, IEN119) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1819) 1820 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT=14672 bytes) (Obsoleted by RFC1844) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1820) 1821 Integration of Real-time Services in an IP-ATM Network Architecture. M. Borden, E. Crawley, B. Davie, S. Batsell. August 1995. (Format: TXT=64466 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1821) 1822 A Grant of Rights to Use a Specific IBM patent with Photuris. J. Lowe. August 1995. (Format: TXT=2664 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1822) 1823 The LDAP Application Program Interface. T. Howes, M. Smith. August 1995. (Format: TXT=41081 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1823) 1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4). H. Danisch. August 1995. (Format: TXT=45540 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1824) 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. (Format: TXT=56772 bytes) (Obsoleted by RFC2401) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1825) 1826 IP Authentication Header. R. Atkinson. August 1995. (Format: TXT=27583 bytes) (Obsoleted by RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1826) 1827 IP Encapsulating Security Payload (ESP). R. Atkinson. August 1995. (Format: TXT=30278 bytes) (Obsoleted by RFC2406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1827) 1828 IP Authentication using Keyed MD5. P. Metzger, W. Simpson. August 1995. (Format: TXT=9800 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1828) 1829 The ESP DES-CBC Transform. P. Karn, P. Metzger, W. Simpson. August 1995. (Format: TXT=19291 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1829) 1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. August 1995. (Format: TXT=16555 bytes) (Obsoleted by RFC3030) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1830) 1831 RPC: Remote Procedure Call Protocol Specification Version 2. R. Srinivasan. August 1995. (Format: TXT=37798 bytes) (Obsoleted by RFC5531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1831) 1832 XDR: External Data Representation Standard. R. Srinivasan. August 1995. (Format: TXT=47418 bytes) (Obsoleted by RFC4506) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1832) 1833 Binding Protocols for ONC RPC Version 2. R. Srinivasan. August 1995. (Format: TXT=24449 bytes) (Updated by RFC5665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1833) 1834 Whois and Network Information Lookup Service, Whois++. J. Gargano, K. Weiss. August 1995. (Format: TXT=14429 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1834) 1835 Architecture of the WHOIS++ service. P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider. August 1995. (Format: TXT=80581 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1835) 1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree. S. Kille. August 1995. (Format: TXT=20175 bytes) (Obsoleted by RFC2294) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1836) 1837 Representing Tables and Subtrees in the X.500 Directory. S. Kille. August 1995. (Format: TXT=10924 bytes) (Obsoleted by RFC2293) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1837) 1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses. S. Kille. August 1995. (Format: TXT=12216 bytes) (Obsoleted by RFC2164) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1838) 1839 Not Issued. 1840 Not Issued. 1841 PPP Network Control Protocol for LAN Extension. J. Chapman, D. Coli, A. Harvey, B. Jensen, K. Rowett. September 1995. (Format: TXT=146206 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1841) 1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages. Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang. August 1995. (Format: TXT=24143 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1842) 1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters. F. Lee. August 1995. (Format: TXT=8787 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1843) 1844 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT=15072 bytes) (Obsoletes RFC1820) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1844) 1845 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. Freed, A. Cargille. September 1995. (Format: TXT=15399 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1845) 1846 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. (Format: TXT=6558 bytes) (Updated by RFC7504) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1846) 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker, N. Freed. October 1995. (Format: TXT=23679 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1847) 1848 MIME Object Security Services. S. Crocker, N. Freed, J. Galvin, S. Murphy. October 1995. (Format: TXT=95010 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1848) 1849 "Son of 1036": News Article Format and Transmission. H. Spencer. March 2010. (Format: TXT=259422 bytes) (Obsoleted by RFC5536, RFC5537) (Status: HISTORIC) (DOI: 10.17487/RFC1849) 1850 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. November 1995. (Format: TXT=140255 bytes) (Obsoletes RFC1253) (Obsoleted by RFC4750) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1850) 1851 The ESP Triple DES Transform. P. Karn, P. Metzger, W. Simpson. September 1995. (Format: TXT=20000 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1851) 1852 IP Authentication using Keyed SHA. P. Metzger, W. Simpson. September 1995. (Format: TXT=9367 bytes) (Obsoleted by RFC2841) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1852) 1853 IP in IP Tunneling. W. Simpson. October 1995. (Format: TXT=14803 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1853) 1854 SMTP Service Extension for Command Pipelining. N. Freed. October 1995. (Format: TXT=14097 bytes) (Obsoleted by RFC2197) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1854) 1855 Netiquette Guidelines. S. Hambridge. October 1995. (Format: TXT=46185 bytes) (Also FYI0028) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1855) 1856 The Opstat Client-Server Model for Statistics Retrieval. H. Clark. September 1995. (Format: TXT=29954 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1856) 1857 A Model for Common Operational Statistics. M. Lambert. October 1995. (Format: TXT=55314 bytes) (Obsoletes RFC1404) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1857) 1858 Security Considerations for IP Fragment Filtering. G. Ziemba, D. Reed, P. Traina. October 1995. (Format: TXT=20468 bytes) (Updated by RFC3128) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1858) 1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension. Y. Pouffary. October 1995. (Format: TXT=14572 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1859) 1860 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. October 1995. (Format: TXT=5694 bytes) (Obsoleted by RFC1878) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1860) 1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced. A. Gwinn. October 1995. (Format: TXT=49181 bytes) (Obsoletes RFC1645) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1861) 1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994. M. McCahill, J. Romkey, M. Schwartz, K. Sollins, T. Verschuren, C. Weider. November 1995. (Format: TXT=62483 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1862) 1863 A BGP/IDRP Route Server alternative to a full mesh routing. D. Haskin. October 1995. (Format: TXT=37426 bytes) (Obsoleted by RFC4223) (Status: HISTORIC) (DOI: 10.17487/RFC1863) 1864 The Content-MD5 Header Field. J. Myers, M. Rose. October 1995. (Format: TXT=7216 bytes) (Obsoletes RFC1544) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1864) 1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet. W. Houser, J. Griffin, C. Hage. January 1996. (Format: TXT=98361 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1865) 1866 Hypertext Markup Language - 2.0. T. Berners-Lee, D. Connolly. November 1995. (Format: TXT=146904 bytes) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1866) 1867 Form-based File Upload in HTML. E. Nebel, L. Masinter. November 1995. (Format: TXT=26183 bytes) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1867) 1868 ARP Extension - UNARP. G. Malkin. November 1995. (Format: TXT=7681 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1868) 1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. November 1995. (Format: TXT=23299 bytes) (Obsoletes RFC1651) (Obsoleted by RFC2821) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1869) 1870 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. November 1995. (Format: TXT=18226 bytes) (Obsoletes RFC1653) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1870) 1871 Addendum to RFC 1602 -- Variance Procedure. J. Postel. November 1995. (Format: TXT=7747 bytes) (Obsoleted by RFC2026) (Updates RFC1602, RFC1603) (Status: HISTORIC) (DOI: 10.17487/RFC1871) 1872 The MIME Multipart/Related Content-type. E. Levinson. December 1995. (Format: TXT=15565 bytes) (Obsoleted by RFC2112) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1872) 1873 Message/External-Body Content-ID Access Type. E. Levinson. December 1995. (Format: TXT=5878 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1873) 1874 SGML Media Types. E. Levinson. December 1995. (Format: TXT=12515 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1874) 1875 UNINETT PCA Policy Statements. N. Berge. December 1995. (Format: TXT=19089 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1875) 1876 A Means for Expressing Location Information in the Domain Name System. C. Davis, P. Vixie, T. Goodwin, I. Dickinson. January 1996. (Format: TXT=29631 bytes) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1876) 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses. S. Cobb. December 1995. (Format: TXT=10591 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1877) 1878 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. December 1995. (Format: TXT=19414 bytes) (Obsoletes RFC1860) (Status: HISTORIC) (DOI: 10.17487/RFC1878) 1879 Class A Subnet Experiment Results and Recommendations. B. Manning, Ed.. January 1996. (Format: TXT=10589 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1879) 1880 Internet Official Protocol Standards. J. Postel, Ed.. November 1995. (Format: TXT=89153 bytes) (Obsoletes RFC1800) (Obsoleted by RFC1920) (Status: HISTORIC) (DOI: 10.17487/RFC1880) 1881 IPv6 Address Allocation Management. IAB, IESG. December 1995. (Format: TXT=3215 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1881) 1882 The 12-Days of Technology Before Christmas. B. Hancock. December 1995. (Format: TXT=9130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1882) 1883 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1995. (Format: TXT=82089 bytes) (Obsoleted by RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1883) 1884 IP Version 6 Addressing Architecture. R. Hinden, Ed., S. Deering, Ed.. December 1995. (Format: TXT=37860 bytes) (Obsoleted by RFC2373) (Status: HISTORIC) (DOI: 10.17487/RFC1884) 1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). A. Conta, S. Deering. December 1995. (Format: TXT=32214 bytes) (Obsoleted by RFC2463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1885) 1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema. December 1995. (Format: TXT=6424 bytes) (Obsoleted by RFC3596) (Updated by RFC2874, RFC3152) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1886) 1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, Ed., T. Li, Ed.. December 1995. (Format: TXT=66066 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1887) 1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. August 1996. (Format: TXT=36469 bytes) (Obsoleted by RFC4048) (Updated by RFC4548) (Status: HISTORIC) (DOI: 10.17487/RFC1888) 1889 RTP: A Transport Protocol for Real-Time Applications. Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. January 1996. (Format: TXT=188544 bytes) (Obsoleted by RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1889) 1890 RTP Profile for Audio and Video Conferences with Minimal Control. Audio-Video Transport Working Group, H. Schulzrinne. January 1996. (Format: TXT=37509 bytes) (Obsoleted by RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1890) 1891 SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996. (Format: TXT=65192 bytes) (Obsoleted by RFC3461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1891) 1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. G. Vaudreuil. January 1996. (Format: TXT=7800 bytes) (Obsoleted by RFC3462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1892) 1893 Enhanced Mail System Status Codes. G. Vaudreuil. January 1996. (Format: TXT=28218 bytes) (Obsoleted by RFC3463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1893) 1894 An Extensible Message Format for Delivery Status Notifications. K. Moore, G. Vaudreuil. January 1996. (Format: TXT=77462 bytes) (Obsoleted by RFC3464) (Updated by RFC2852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1894) 1895 The Application/CALS-1840 Content-type. E. Levinson. February 1996. (Format: TXT=10576 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1895) 1896 The text/enriched MIME Content-type. P. Resnick, A. Walker. February 1996. (Format: TXT=45926, PS=81217 bytes) (Obsoletes RFC1523, RFC1563) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1896) 1897 IPv6 Testing Address Allocation. R. Hinden, J. Postel. January 1996. (Format: TXT=6643 bytes) (Obsoleted by RFC2471) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1897) 1898 CyberCash Credit Card Protocol Version 0.8. D. Eastlake 3rd, B. Boesch, S. Crocker, M. Yesil. February 1996. (Format: TXT=113633 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1898) 1899 Request for Comments Summary RFC Numbers 1800-1899. J. Elliott. January 1997. (Format: TXT=37984 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1899) 1900 Renumbering Needs Work. B. Carpenter, Y. Rekhter. February 1996. (Format: TXT=9528 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1900) 1901 Introduction to Community-based SNMPv2. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=15903 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1901) 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=77453 bytes) (Obsoletes RFC1442) (Obsoleted by RFC2578) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1902) 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=52652 bytes) (Obsoletes RFC1443) (Obsoleted by RFC2579) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1903) 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=47083 bytes) (Obsoletes RFC1444) (Obsoleted by RFC2580) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1904) 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=55526 bytes) (Obsoletes RFC1448) (Obsoleted by RFC3416) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1905) 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=27465 bytes) (Obsoletes RFC1449) (Obsoleted by RFC3417) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1906) 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=34881 bytes) (Obsoletes RFC1450) (Obsoleted by RFC3418) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1907) 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=21463 bytes) (Obsoletes RFC1452) (Obsoleted by RFC2576) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1908) 1909 An Administrative Infrastructure for SNMPv2. K. McCloghrie, Ed.. February 1996. (Format: TXT=45773 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1909) 1910 User-based Security Model for SNMPv2. G. Waters, Ed.. February 1996. (Format: TXT=98252 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1910) 1911 Voice Profile for Internet Mail. G. Vaudreuil. February 1996. (Format: TXT=50242 bytes) (Obsoleted by RFC2421, RFC2422, RFC2423) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1911) 1912 Common DNS Operational and Configuration Errors. D. Barr. February 1996. (Format: TXT=38252 bytes) (Obsoletes RFC1537) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1912) 1913 Architecture of the Whois++ Index Service. C. Weider, J. Fullton, S. Spero. February 1996. (Format: TXT=33743 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1913) 1914 How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz, C. Weider. February 1996. (Format: TXT=17842 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1914) 1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol. F. Kastenholz. February 1996. (Format: TXT=14347 bytes) (Also BCP0003) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1915) 1916 Enterprise Renumbering: Experience and Information Solicitation. H. Berkowitz, P. Ferguson, W. Leland, P. Nesser. February 1996. (Format: TXT=16117 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1916) 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA. P. Nesser II. February 1996. (Format: TXT=23623 bytes) (Also BCP0004) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1917) 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Updated by RFC6761) (Also BCP0005) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1918) 1919 Classical versus Transparent IP Proxies. M. Chatel. March 1996. (Format: TXT=87374 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1919) 1920 Internet Official Protocol Standards. J. Postel. March 1996. (Format: TXT=91936 bytes) (Obsoletes RFC1880) (Obsoleted by RFC2000) (Status: HISTORIC) (DOI: 10.17487/RFC1920) 1921 TNVIP Protocol. J. Dujonc. March 1996. (Format: TXT=57475 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1921) 1922 Chinese Character Encoding for Internet Messages. HF. Zhu, DY. Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. March 1996. (Format: TXT=50995 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1922) 1923 RIPv1 Applicability Statement for Historic Status. J. Halpern, S. Bradner. March 1996. (Format: TXT=5560 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1923) 1924 A Compact Representation of IPv6 Addresses. R. Elz. April 1996. (Format: TXT=10409 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1924) 1925 The Twelve Networking Truths. R. Callon. April 1996. (Format: TXT=4294 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1925) 1926 An Experimental Encapsulation of IP Datagrams on Top of ATM. J. Eriksson. April 1996. (Format: TXT=2969 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1926) 1927 Suggested Additional MIME Types for Associating Documents. C. Rogers. April 1996. (Format: TXT=5254 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1927) 1928 SOCKS Protocol Version 5. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones. March 1996. (Format: TXT=19741 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1928) 1929 Username/Password Authentication for SOCKS V5. M. Leech. March 1996. (Format: TXT=3568 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1929) 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS). J. Hawkinson, T. Bates. March 1996. (Format: TXT=22073 bytes) (Updated by RFC6996, RFC7300) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1930) 1931 Dynamic RARP Extensions for Automatic Network Address Acquisition. D. Brownell. April 1996. (Format: TXT=27544 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1931) 1932 IP over ATM: A Framework Document. R. Cole, D. Shur, C. Villamizar. April 1996. (Format: TXT=68031 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1932) 1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. April 1996. (Format: TXT=47005 bytes) (Obsoleted by RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1933) 1934 Ascend's Multilink Protocol Plus (MP+). K. Smith. April 1996. (Format: TXT=87072 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1934) 1935 What is the Internet, Anyway?. J. Quarterman, S. Carl-Mitchell. April 1996. (Format: TXT=30369 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1935) 1936 Implementing the Internet Checksum in Hardware. J. Touch, B. Parham. April 1996. (Format: TXT=36618 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1936) 1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks. Y. Rekhter, D. Kandlur. May 1996. (Format: TXT=18302 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1937) 1938 A One-Time Password System. N. Haller, C. Metz. May 1996. (Format: TXT=44844 bytes) (Obsoleted by RFC2289) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1938) 1939 Post Office Protocol - Version 3. J. Myers, M. Rose. May 1996. (Format: TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957, RFC2449, RFC6186) (Also STD0053) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1939) 1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1). D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala. May 1996. (Format: TXT=60858 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1940) 1941 Frequently Asked Questions for Schools. J. Sellers, J. Robichaux. May 1996. (Format: TXT=150980 bytes) (Obsoletes RFC1578) (Also FYI0022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1941) 1942 HTML Tables. D. Raggett. May 1996. (Format: TXT=68705 bytes) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1942) 1943 Building an X.500 Directory Service in the US. B. Jennings. May 1996. (Format: TXT=51266 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1943) 1944 Benchmarking Methodology for Network Interconnect Devices. S. Bradner, J. McQuaid. May 1996. (Format: TXT=66061 bytes) (Obsoleted by RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1944) 1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding, H. Frystyk. May 1996. (Format: TXT=137582 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1945) 1946 Native ATM Support for ST2+. S. Jackowski. May 1996. (Format: TXT=50430 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1946) 1947 Greek Character Encoding for Electronic Mail Messages. D. Spinellis. May 1996. (Format: TXT=14428 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1947) 1948 Defending Against Sequence Number Attacks. S. Bellovin. May 1996. (Format: TXT=13074 bytes) (Obsoleted by RFC6528) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1948) 1949 Scalable Multicast Key Distribution. A. Ballardie. May 1996. (Format: TXT=41853 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1949) 1950 ZLIB Compressed Data Format Specification version 3.3. P. Deutsch, J-L. Gailly. May 1996. (Format: TXT=20502, PS=37768, PDF=36393 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1950) 1951 DEFLATE Compressed Data Format Specification version 1.3. P. Deutsch. May 1996. (Format: TXT=36944, PS=57408, PDF=56620 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1951) 1952 GZIP file format specification version 4.3. P. Deutsch. May 1996. (Format: TXT=25036, PS=43337, PDF=43211 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1952) 1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. May 1996. (Format: TXT=43749 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1953) 1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. May 1996. (Format: TXT=16075 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1954) 1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG. R. Hinden. June 1996. (Format: TXT=10115 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1955) 1956 Registration in the MIL Domain. D. Engebretson, R. Plzak. June 1996. (Format: TXT=2923 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1956) 1957 Some Observations on Implementations of the Post Office Protocol (POP3). R. Nelson. June 1996. (Format: TXT=2325 bytes) (Updates RFC1939) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1957) 1958 Architectural Principles of the Internet. B. Carpenter, Ed.. June 1996. (Format: TXT=17345 bytes) (Updated by RFC3439) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1958) 1959 An LDAP URL Format. T. Howes, M. Smith. June 1996. (Format: TXT=7243 bytes) (Obsoleted by RFC2255) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1959) 1960 A String Representation of LDAP Search Filters. T. Howes. June 1996. (Format: TXT=5288 bytes) (Obsoletes RFC1558) (Obsoleted by RFC2254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1960) 1961 GSS-API Authentication Method for SOCKS Version 5. P. McMahon. June 1996. (Format: TXT=16036 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1961) 1962 The PPP Compression Control Protocol (CCP). D. Rand. June 1996. (Format: TXT=18005 bytes) (Updated by RFC2153) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1962) 1963 PPP Serial Data Transport Protocol (SDTP). K. Schneider, S. Venters. August 1996. (Format: TXT=38185 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1963) 1964 The Kerberos Version 5 GSS-API Mechanism. J. Linn. June 1996. (Format: TXT=47413 bytes) (Updated by RFC4121, RFC6649) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1964) 1965 Autonomous System Confederations for BGP. P. Traina. June 1996. (Format: TXT=13575 bytes) (Obsoleted by RFC3065) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1965) 1966 BGP Route Reflection An alternative to full mesh IBGP. T. Bates, R. Chandra. June 1996. (Format: TXT=14320 bytes) (Obsoleted by RFC4456) (Updated by RFC2796) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1966) 1967 PPP LZS-DCP Compression Protocol (LZS-DCP). K. Schneider, R. Friend. August 1996. (Format: TXT=40039 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1967) 1968 The PPP Encryption Control Protocol (ECP). G. Meyer. June 1996. (Format: TXT=20781 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1968) 1969 The PPP DES Encryption Protocol (DESE). K. Sklower, G. Meyer. June 1996. (Format: TXT=20383 bytes) (Obsoleted by RFC2419) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1969) 1970 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. August 1996. (Format: TXT=197632 bytes) (Obsoleted by RFC2461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1970) 1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. August 1996. (Format: TXT=56890 bytes) (Obsoleted by RFC2462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1971) 1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996. (Format: TXT=6353 bytes) (Obsoleted by RFC2464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1972) 1973 PPP in Frame Relay. W. Simpson. June 1996. (Format: TXT=14780 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1973) 1974 PPP Stac LZS Compression Protocol. R. Friend, W. Simpson. August 1996. (Format: TXT=45267 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1974) 1975 PPP Magnalink Variable Resource Compression. D. Schremp, J. Black, J. Weiss. August 1996. (Format: TXT=8655 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1975) 1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE). K. Schneider, S. Venters. August 1996. (Format: TXT=19781 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1976) 1977 PPP BSD Compression Protocol. V. Schryver. August 1996. (Format: TXT=50747 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1977) 1978 PPP Predictor Compression Protocol. D. Rand. August 1996. (Format: TXT=17424 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1978) 1979 PPP Deflate Protocol. J. Woods. August 1996. (Format: TXT=18803 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1979) 1980 A Proposed Extension to HTML : Client-Side Image Maps. J. Seidman. August 1996. (Format: TXT=13448 bytes) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1980) 1981 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul. August 1996. (Format: TXT=34088 bytes) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1981) 1982 Serial Number Arithmetic. R. Elz, R. Bush. August 1996. (Format: TXT=14440 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1982) 1983 Internet Users' Glossary. G. Malkin, Ed.. August 1996. (Format: TXT=123008 bytes) (Obsoletes RFC1392) (Also FYI0018) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1983) 1984 IAB and IESG Statement on Cryptographic Technology and the Internet. IAB, IESG. August 1996. (Format: TXT=10738 bytes) (Also BCP0200) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1984) 1985 SMTP Service Extension for Remote Message Queue Starting. J. De Winter. August 1996. (Format: TXT=14815 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1985) 1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP). W. Polites, W. Wollman, D. Woo, R. Langan. August 1996. (Format: TXT=49772 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1986) 1987 Ipsilon's General Switch Management Protocol Specification Version 1.1. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. August 1996. (Format: TXT=105821 bytes) (Updated by RFC2297) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1987) 1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework. G. McAnally, D. Gilbert, J. Flick. August 1996. (Format: TXT=3821 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1988) 1989 PPP Link Quality Monitoring. W. Simpson. August 1996. (Format: TXT=29289 bytes) (Obsoletes RFC1333) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1989) 1990 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti. August 1996. (Format: TXT=53271 bytes) (Obsoletes RFC1717) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1990) 1991 PGP Message Exchange Formats. D. Atkins, W. Stallings, P. Zimmermann. August 1996. (Format: TXT=46255 bytes) (Obsoleted by RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1991) 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1992) 1993 PPP Gandalf FZA Compression Protocol. A. Barbir, D. Carr, W. Simpson. August 1996. (Format: TXT=9811 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1993) 1994 PPP Challenge Handshake Authentication Protocol (CHAP). W. Simpson. August 1996. (Format: TXT=24094 bytes) (Obsoletes RFC1334) (Updated by RFC2484) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1994) 1995 Incremental Zone Transfer in DNS. M. Ohta. August 1996. (Format: TXT=16810 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1995) 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie. August 1996. (Format: TXT=15247 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1996) 1997 BGP Communities Attribute. R. Chandra, P. Traina, T. Li. August 1996. (Format: TXT=8275 bytes) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1997) 1998 An Application of the BGP Community Attribute in Multi-home Routing. E. Chen, T. Bates. August 1996. (Format: TXT=16953 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1998) 1999 Request for Comments Summary RFC Numbers 1900-1999. J. Elliott. January 1997. (Format: TXT=39819 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1999) 2000 Internet Official Protocol Standards. J. Postel, Ed.. February 1997. (Format: TXT=121356 bytes) (Obsoletes RFC1920) (Obsoleted by RFC2200) (Status: HISTORIC) (DOI: 10.17487/RFC2000) 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997. (Format: TXT=12981 bytes) (Obsoleted by RFC2581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2001) 2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format: TXT=193103 bytes) (Obsoleted by RFC3220) (Updated by RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2002) 2003 IP Encapsulation within IP. C. Perkins. October 1996. (Format: TXT=30291 bytes) (Updated by RFC3168, RFC6864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2003) 2004 Minimal Encapsulation within IP. C. Perkins. October 1996. (Format: TXT=12202 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2004) 2005 Applicability Statement for IP Mobility Support. J. Solomon. October 1996. (Format: TXT=10509 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2005) 2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2. D. Cong, M. Hamlen, C. Perkins. October 1996. (Format: TXT=95030 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2006) 2007 Catalogue of Network Training Materials. J. Foster, M. Isaacs, M. Prior. October 1996. (Format: TXT=78941 bytes) (Also FYI0029) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2007) 2008 Implications of Various Address Allocation Policies for Internet Routing. Y. Rekhter, T. Li. October 1996. (Format: TXT=34717 bytes) (Also BCP0007) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2008) 2009 GPS-Based Addressing and Routing. T. Imielinski, J. Navas. November 1996. (Format: TXT=66229 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2009) 2010 Operational Criteria for Root Name Servers. B. Manning, P. Vixie. October 1996. (Format: TXT=14870 bytes) (Obsoleted by RFC2870) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2010) 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT=31168 bytes) (Obsoleted by RFC4293) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2011) 2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT=16792 bytes) (Obsoleted by RFC4022) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2012) 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT=9333 bytes) (Obsoleted by RFC4113) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2013) 2014 IRTF Research Group Guidelines and Procedures. A. Weinrib, J. Postel. October 1996. (Format: TXT=27507 bytes) (Also BCP0008) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2014) 2015 MIME Security with Pretty Good Privacy (PGP). M. Elkins. October 1996. (Format: TXT=14223 bytes) (Updated by RFC3156) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2015) 2016 Uniform Resource Agents (URAs). L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan. October 1996. (Format: TXT=38355 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2016) 2017 Definition of the URL MIME External-Body Access-Type. N. Freed, K. Moore, A. Cargille. October 1996. (Format: TXT=9000 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2017) 2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996. (Format: TXT=25671 bytes) (Obsoletes RFC1072) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2018) 2019 Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996. (Format: TXT=12344 bytes) (Obsoleted by RFC2467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2019) 2020 IEEE 802.12 Interface MIB. J. Flick. October 1996. (Format: TXT=72135 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2020) 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2. S. Waldbusser. January 1997. (Format: TXT=262223 bytes) (Obsoleted by RFC4502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2021) 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks. G. Armitage. November 1996. (Format: TXT=189219 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2022) 2023 IP Version 6 over PPP. D. Haskin, E. Allen. October 1996. (Format: TXT=20275 bytes) (Obsoleted by RFC2472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2023) 2024 Definitions of Managed Objects for Data Link Switching using SMIv2. D. Chen, Ed., P. Gayek, S. Nix. October 1996. (Format: TXT=173952 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2024) 2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October 1996. (Format: TXT=101692 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2025) 2026 The Internet Standards Process -- Revision 3. S. Bradner. October 1996. (Format: TXT=86731 bytes) (Obsoletes RFC1602, RFC1871) (Updated by RFC3667, RFC3668, RFC3932, RFC3978, RFC3979, RFC5378, RFC5657, RFC5742, RFC6410, RFC7100, RFC7127, RFC7475) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2026) 2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. October 1996. (Format: TXT=24207 bytes) (Obsoleted by RFC2282) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2027) 2028 The Organizations Involved in the IETF Standards Process. R. Hovey, S. Bradner. October 1996. (Format: TXT=13865 bytes) (Updated by RFC3668, RFC3979) (Also BCP0011) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2028) 2029 RTP Payload Format of Sun's CellB Video Encoding. M. Speer, D. Hoffman. October 1996. (Format: TXT=11216 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2029) 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996. (Format: TXT=48620 bytes) (Obsoletes RFC1769) (Obsoleted by RFC4330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2030) 2031 IETF-ISOC relationship. E. Huizer. October 1996. (Format: TXT=8816 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2031) 2032 RTP Payload Format for H.261 Video Streams. T. Turletti, C. Huitema. October 1996. (Format: TXT=27488 bytes) (Obsoleted by RFC4587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2032) 2033 Local Mail Transfer Protocol. J. Myers. October 1996. (Format: TXT=14711 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2033) 2034 SMTP Service Extension for Returning Enhanced Error Codes. N. Freed. October 1996. (Format: TXT=10460 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2034) 2035 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, R. Frederick, S. McCanne. October 1996. (Format: TXT=30079 bytes) (Obsoleted by RFC2435) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2035) 2036 Observations on the use of Components of the Class A Address Space within the Internet. G. Huston. October 1996. (Format: TXT=20743 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2036) 2037 Entity MIB using SMIv2. K. McCloghrie, A. Bierman. October 1996. (Format: TXT=74362 bytes) (Obsoleted by RFC2737) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2037) 2038 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. Fernando, V. Goyal. October 1996. (Format: TXT=23266 bytes) (Obsoleted by RFC2250) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2038) 2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers. C. Kalbfleisch. November 1996. (Format: TXT=31966 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2039) 2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms. R. Baldwin, R. Rivest. October 1996. (Format: TXT=54598 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2040) 2041 Mobile Network Tracing. B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz. October 1996. (Format: TXT=64688 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2041) 2042 Registering New BGP Attribute Types. B. Manning. January 1997. (Format: TXT=4001 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2042) 2043 The PPP SNA Control Protocol (SNACP). A. Fuqua. October 1996. (Format: TXT=13719 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2043) 2044 UTF-8, a transformation format of Unicode and ISO 10646. F. Yergeau. October 1996. (Format: TXT=11932 bytes) (Obsoleted by RFC2279) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2044) 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed, N. Borenstein. November 1996. (Format: TXT=72932 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231, RFC5335, RFC6532) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2045) 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein. November 1996. (Format: TXT=105854 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646, RFC3798, RFC5147, RFC6657) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2046) 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. K. Moore. November 1996. (Format: TXT=33262 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2047) 2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin, J. Postel. November 1996. (Format: TXT=45033 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Obsoleted by RFC4288, RFC4289) (Updated by RFC3023) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2048) 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996. (Format: TXT=51207 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2049) 2050 Internet Registry IP Allocation Guidelines. K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format: TXT=28975 bytes) (Obsoletes RFC1466) (Obsoleted by RFC7020) (Status: HISTORIC) (DOI: 10.17487/RFC2050) 2051 Definitions of Managed Objects for APPC using SMIv2. M. Allen, B. Clouston, Z. Kielczewski, W. Kwan, B. Moore. October 1996. (Format: TXT=239359 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2051) 2052 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie. October 1996. (Format: TXT=19257 bytes) (Obsoleted by RFC2782) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2052) 2053 The AM (Armenia) Domain. E. Der-Danieliantz. October 1996. (Format: TXT=4128 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2053) 2054 WebNFS Client Specification. B. Callaghan. October 1996. (Format: TXT=36354 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2054) 2055 WebNFS Server Specification. B. Callaghan. October 1996. (Format: TXT=20498 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2055) 2056 Uniform Resource Locators for Z39.50. R. Denenberg, J. Kunze, D. Lynch. November 1996. (Format: TXT=14204 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2056) 2057 Source Directed Access Control on the Internet. S. Bradner. November 1996. (Format: TXT=56664 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2057) 2058 Remote Authentication Dial In User Service (RADIUS). C. Rigney, A. Rubens, W. Simpson, S. Willens. January 1997. (Format: TXT=118880 bytes) (Obsoleted by RFC2138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2058) 2059 RADIUS Accounting. C. Rigney. January 1997. (Format: TXT=44237 bytes) (Obsoleted by RFC2139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2059) 2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. December 1996. (Format: TXT=166513 bytes) (Obsoletes RFC1730) (Obsoleted by RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2060) 2061 IMAP4 Compatibility with IMAP2bis. M. Crispin. December 1996. (Format: TXT=5867 bytes) (Obsoletes RFC1730) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2061) 2062 Internet Message Access Protocol - Obsolete Syntax. M. Crispin. December 1996. (Format: TXT=14222 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2062) 2063 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. January 1997. (Format: TXT=89092 bytes) (Obsoleted by RFC2722) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2063) 2064 Traffic Flow Measurement: Meter MIB. N. Brownlee. January 1997. (Format: TXT=67520 bytes) (Obsoleted by RFC2720) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2064) 2065 Domain Name System Security Extensions. D. Eastlake 3rd, C. Kaufman. January 1997. (Format: TXT=97718 bytes) (Obsoleted by RFC2535) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2065) 2066 TELNET CHARSET Option. R. Gellens. January 1997. (Format: TXT=26088 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2066) 2067 IP over HIPPI. J. Renwick. January 1997. (Format: TXT=66702 bytes) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2067) 2068 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. (Format: TXT=378114 bytes) (Obsoleted by RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2068) 2069 An Extension to HTTP : Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. January 1997. (Format: TXT=41733 bytes) (Obsoleted by RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2069) 2070 Internationalization of the Hypertext Markup Language. F. Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format: TXT=91887 bytes) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC2070) 2071 Network Renumbering Overview: Why would I want it and what is it anyway?. P. Ferguson, H. Berkowitz. January 1997. (Format: TXT=33218 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2071) 2072 Router Renumbering Guide. H. Berkowitz. January 1997. (Format: TXT=110591 bytes) (Updated by RFC4192) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2072) 2073 An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. January 1997. (Format: TXT=15549 bytes) (Obsoleted by RFC2374) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2073) 2074 Remote Network Monitoring MIB Protocol Identifiers. A. Bierman, R. Iddon. January 1997. (Format: TXT=81262 bytes) (Obsoleted by RFC2895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2074) 2075 IP Echo Host Service. C. Partridge. January 1997. (Format: TXT=12536 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2075) 2076 Common Internet Message Headers. J. Palme. February 1997. (Format: TXT=47639 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2076) 2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions. S. Nelson, C. Parks, Mitra. January 1997. (Format: TXT=30158 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2077) 2078 Generic Security Service Application Program Interface, Version 2. J. Linn. January 1997. (Format: TXT=185990 bytes) (Obsoletes RFC1508) (Obsoleted by RFC2743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2078) 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format: TXT=8757 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2079) 2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT=47534 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2080) 2081 RIPng Protocol Applicability Statement. G. Malkin. January 1997. (Format: TXT=6821 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2081) 2082 RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997. (Format: TXT=25436 bytes) (Obsoleted by RFC4822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2082) 2083 PNG (Portable Network Graphics) Specification Version 1.0. T. Boutell. March 1997. (Format: TXT=242528 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2083) 2084 Considerations for Web Transaction Security. G. Bossert, S. Cooper, W. Drummond. January 1997. (Format: TXT=9022 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2084) 2085 HMAC-MD5 IP Authentication with Replay Prevention. M. Oehler, R. Glenn. February 1997. (Format: TXT=13399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2085) 2086 IMAP4 ACL extension. J. Myers. January 1997. (Format: TXT=13925 bytes) (Obsoleted by RFC4314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2086) 2087 IMAP4 QUOTA extension. J. Myers. January 1997. (Format: TXT=8542 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2087) 2088 IMAP4 non-synchronizing literals. J. Myers. January 1997. (Format: TXT=4052 bytes) (Obsoleted by RFC7888) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2088) 2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent. B. Wijnen, D. Levi. January 1997. (Format: TXT=23814 bytes) (Obsoleted by RFC2576) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2089) 2090 TFTP Multicast Option. A. Emberson. February 1997. (Format: TXT=11857 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2090) 2091 Triggered Extensions to RIP to Support Demand Circuits. G. Meyer, S. Sherry. January 1997. (Format: TXT=44835 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2091) 2092 Protocol Analysis for Triggered RIP. S. Sherry, G. Meyer. January 1997. (Format: TXT=10865 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2092) 2093 Group Key Management Protocol (GKMP) Specification. H. Harney, C. Muckenhirn. July 1997. (Format: TXT=48678 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2093) 2094 Group Key Management Protocol (GKMP) Architecture. H. Harney, C. Muckenhirn. July 1997. (Format: TXT=53097 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2094) 2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. January 1997. (Format: TXT=10446 bytes) (Obsoleted by RFC2195) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2095) 2096 IP Forwarding Table MIB. F. Baker. January 1997. (Format: TXT=35930 bytes) (Obsoletes RFC1354) (Obsoleted by RFC4292) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2096) 2097 The PPP NetBIOS Frames Control Protocol (NBFCP). G. Pall. January 1997. (Format: TXT=27104 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2097) 2098 Toshiba's Router Architecture Extensions for ATM : Overview. Y. Katsube, K. Nagami, H. Esaki. February 1997. (Format: TXT=43622 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2098) 2099 Request for Comments Summary RFC Numbers 2000-2099. J. Elliott. March 1997. (Format: TXT=40763 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2099) 2100 The Naming of Hosts. J. Ashworth. April 1997. (Format: TXT=4077 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2100) 2101 IPv4 Address Behaviour Today. B. Carpenter, J. Crowcroft, Y. Rekhter. February 1997. (Format: TXT=31407 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2101) 2102 Multicast Support for Nimrod : Requirements and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT=50963 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2102) 2103 Mobility Support for Nimrod : Challenges and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT=41352 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2103) 2104 HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997. (Format: TXT=22297 bytes) (Updated by RFC6151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2104) 2105 Cisco Systems' Tag Switching Architecture Overview. Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow. February 1997. (Format: TXT=33013 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2105) 2106 Data Link Switching Remote Access Protocol. S. Chiang, J. Lee, H. Yasuda. February 1997. (Format: TXT=40819 bytes) (Obsoleted by RFC2114) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2106) 2107 Ascend Tunnel Management Protocol - ATMP. K. Hamzeh. February 1997. (Format: TXT=44300 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2107) 2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. February 1997. (Format: TXT=166336 bytes) (Obsoletes RFC1516) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2108) 2109 HTTP State Management Mechanism. D. Kristol, L. Montulli. February 1997. (Format: TXT=43469 bytes) (Obsoleted by RFC2965) (Status: HISTORIC) (DOI: 10.17487/RFC2109) 2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann. March 1997. (Format: TXT=41961 bytes) (Obsoleted by RFC2557) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2110) 2111 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. March 1997. (Format: TXT=9099 bytes) (Obsoleted by RFC2392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2111) 2112 The MIME Multipart/Related Content-type. E. Levinson. March 1997. (Format: TXT=17052 bytes) (Obsoletes RFC1872) (Obsoleted by RFC2387) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2112) 2113 IP Router Alert Option. D. Katz. February 1997. (Format: TXT=7924 bytes) (Updated by RFC5350, RFC6398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2113) 2114 Data Link Switching Client Access Protocol. S. Chiang, J. Lee, H. Yasuda. February 1997. (Format: TXT=50872 bytes) (Obsoletes RFC2106) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2114) 2115 Management Information Base for Frame Relay DTEs Using SMIv2. C. Brown, F. Baker. September 1997. (Format: TXT=59950 bytes) (Obsoletes RFC1315) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2115) 2116 X.500 Implementations Catalog-96. C. Apple, K. Rossen. April 1997. (Format: TXT=243994 bytes) (Obsoletes RFC1632) (Also FYI0011) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2116) 2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1997. (Format: TXT=151886 bytes) (Obsoleted by RFC2362) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2117) 2118 Microsoft Point-To-Point Compression (MPPC) Protocol. G. Pall. March 1997. (Format: TXT=17443 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2118) 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. (Format: TXT=4723 bytes) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2119) 2120 Managing the X.500 Root Naming Context. D. Chadwick. March 1997. (Format: TXT=30773 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2120) 2121 Issues affecting MARS Cluster Size. G. Armitage. March 1997. (Format: TXT=26781 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2121) 2122 VEMMI URL Specification. D. Mavrakis, H. Layec, K. Kartmann. March 1997. (Format: TXT=25043 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2122) 2123 Traffic Flow Measurement: Experiences with NeTraMet. N. Brownlee. March 1997. (Format: TXT=81874 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2123) 2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0. P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons. March 1997. (Format: TXT=47912 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2124) 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP). C. Richards, K. Smith. March 1997. (Format: TXT=49213 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2125) 2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March 1997. (Format: TXT=51032 bytes) (Updates RFC1006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2126) 2127 ISDN Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT=95994 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2127) 2128 Dial Control Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT=66153 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2128) 2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification. K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki. April 1997. (Format: TXT=41137 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2129) 2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996. C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. April 1997. (Format: TXT=63443 bytes) (Updated by RFC6055) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2130) 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by RFC3396, RFC4361, RFC5494, RFC6842) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2131) 2132 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. March 1997. (Format: TXT=63670 bytes) (Obsoletes RFC1533) (Updated by RFC3442, RFC3942, RFC4361, RFC4833, RFC5494) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2132) 2133 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997. (Format: TXT=69737 bytes) (Obsoleted by RFC2553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2133) 2134 Articles of Incorporation of Internet Society. ISOC Board of Trustees. April 1997. (Format: TXT=9131 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2134) 2135 Internet Society By-Laws. ISOC Board of Trustees. April 1997. (Format: TXT=20467 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2135) 2136 Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format: TXT=56354 bytes) (Updates RFC1035) (Updated by RFC3007, RFC4035, RFC4033, RFC4034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2136) 2137 Secure Domain Name System Dynamic Update. D. Eastlake 3rd. April 1997. (Format: TXT=24824 bytes) (Obsoleted by RFC3007) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2137) 2138 Remote Authentication Dial In User Service (RADIUS). C. Rigney, A. Rubens, W. Simpson, S. Willens. April 1997. (Format: TXT=120407 bytes) (Obsoletes RFC2058) (Obsoleted by RFC2865) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2138) 2139 RADIUS Accounting. C. Rigney. April 1997. (Format: TXT=44919 bytes) (Obsoletes RFC2059) (Obsoleted by RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2139) 2140 TCP Control Block Interdependence. J. Touch. April 1997. (Format: TXT=26032 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2140) 2141 URN Syntax. R. Moats. May 1997. (Format: TXT=14077 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2141) 2142 Mailbox Names for Common Services, Roles and Functions. D. Crocker. May 1997. (Format: TXT=12195 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2142) 2143 Encapsulating IP with the Small Computer System Interface. B. Elliston. May 1997. (Format: TXT=10749 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2143) 2144 The CAST-128 Encryption Algorithm. C. Adams. May 1997. (Format: TXT=37532 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2144) 2145 Use and Interpretation of HTTP Version Numbers. J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk. May 1997. (Format: TXT=13659 bytes) (Obsoleted by RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2145) 2146 U.S. Government Internet Domain Names. Federal Networking Council. May 1997. (Format: TXT=26564 bytes) (Obsoletes RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2146) 2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format: TXT=1883 bytes) (Obsoleted by RFC2675) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2147) 2148 Deployment of the Internet White Pages Service. H. Alvestrand, P. Jurg. September 1997. (Format: TXT=31539 bytes) (Also BCP0015) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2148) 2149 Multicast Server Architectures for MARS-based ATM multicasting. R. Talpade, M. Ammar. May 1997. (Format: TXT=42007 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2149) 2150 Humanities and Arts: Sharing Center Stage on the Internet. J. Max, W. Stickle. October 1997. (Format: TXT=154037 bytes) (Also FYI0031) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2150) 2151 A Primer On Internet and TCP/IP Tools and Utilities. G. Kessler, S. Shepard. June 1997. (Format: TXT=114130 bytes) (Obsoletes RFC1739) (Also FYI0030) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2151) 2152 UTF-7 A Mail-Safe Transformation Format of Unicode. D. Goldsmith, M. Davis. May 1997. (Format: TXT=28065 bytes) (Obsoletes RFC1642) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2152) 2153 PPP Vendor Extensions. W. Simpson. May 1997. (Format: TXT=10780 bytes) (Updates RFC1661, RFC1962) (Updated by RFC5342, RFC7042) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2153) 2154 OSPF with Digital Signatures. S. Murphy, M. Badger, B. Wellington. June 1997. (Format: TXT=72701 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2154) 2155 Definitions of Managed Objects for APPN using SMIv2. B. Clouston, B. Moore. June 1997. (Format: TXT=213809 bytes) (Obsoleted by RFC2455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2155) 2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME. S. Kille. January 1998. (Format: TXT=280385 bytes) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495) (Updates RFC0822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2156) 2157 Mapping between X.400 and RFC-822/MIME Message Bodies. H. Alvestrand. January 1998. (Format: TXT=92554 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2157) 2158 X.400 Image Body Parts. H. Alvestrand. January 1998. (Format: TXT=5547 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2158) 2159 A MIME Body Part for FAX. H. Alvestrand. January 1998. (Format: TXT=11471 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2159) 2160 Carrying PostScript in X.400 and MIME. H. Alvestrand. January 1998. (Format: TXT=7059 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2160) 2161 A MIME Body Part for ODA. H. Alvestrand. January 1998. (Format: TXT=8009 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2161) 2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail. C. Allocchio. January 1998. (Format: TXT=58553 bytes) (Obsoletes RFC1405) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2162) 2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM). C. Allocchio. January 1998. (Format: TXT=58789 bytes) (Obsoletes RFC1664) (Updated by RFC3597) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2163) 2164 Use of an X.500/LDAP directory to support MIXER address mapping. S. Kille. January 1998. (Format: TXT=16701 bytes) (Obsoletes RFC1838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2164) 2165 Service Location Protocol. J. Veizades, E. Guttman, C. Perkins, S. Kaplan. June 1997. (Format: TXT=169889 bytes) (Updated by RFC2608, RFC2609) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2165) 2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements. D. Bryant, P. Brittain. June 1997. (Format: TXT=75527 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2166) 2167 Referral Whois (RWhois) Protocol V1.5. S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra. June 1997. (Format: TXT=136355 bytes) (Obsoletes RFC1714) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2167) 2168 Resolution of Uniform Resource Identifiers using the Domain Name System. R. Daniel, M. Mealling. June 1997. (Format: TXT=46528 bytes) (Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updated by RFC2915) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2168) 2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel. June 1997. (Format: TXT=17763 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2169) 2170 Application REQuested IP over ATM (AREQUIPA). W. Almesberger, J. Le Boudec, P. Oechslin. July 1997. (Format: TXT=22874 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2170) 2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT=17480 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2171) 2172 MAPOS Version 1 Assigned Numbers. M. Maruyama, K. Murakami. June 1997. (Format: TXT=4857 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2172) 2173 A MAPOS version 1 Extension - Node Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT=12251 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2173) 2174 A MAPOS version 1 Extension - Switch-Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT=47967 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2174) 2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing. K. Murakami, M. Maruyama. June 1997. (Format: TXT=11677 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2175) 2176 IPv4 over MAPOS Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT=12305 bytes) (Updated by RFC5494) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2176) 2177 IMAP4 IDLE command. B. Leiba. June 1997. (Format: TXT=6770 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2177) 2178 OSPF Version 2. J. Moy. July 1997. (Format: TXT=495866 bytes) (Obsoletes RFC1583) (Obsoleted by RFC2328) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2178) 2179 Network Security For Trade Shows. A. Gwinn. July 1997. (Format: TXT=20690 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2179) 2180 IMAP4 Multi-Accessed Mailbox Practice. M. Gahrns. July 1997. (Format: TXT=24750 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2180) 2181 Clarifications to the DNS Specification. R. Elz, R. Bush. July 1997. (Format: TXT=36989 bytes) (Updates RFC1034, RFC1035, RFC1123) (Updated by RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2181) 2182 Selection and Operation of Secondary DNS Servers. R. Elz, R. Bush, S. Bradner, M. Patton. July 1997. (Format: TXT=27456 bytes) (Also BCP0016) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2182) 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field. R. Troost, S. Dorner, K. Moore, Ed.. August 1997. (Format: TXT=23150 bytes) (Obsoletes RFC1806) (Updated by RFC2184, RFC2231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2183) 2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. August 1997. (Format: TXT=17635 bytes) (Obsoleted by RFC2231) (Updates RFC2045, RFC2047, RFC2183) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2184) 2185 Routing Aspects of IPv6 Transition. R. Callon, D. Haskin. September 1997. (Format: TXT=31281 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2185) 2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT=18808 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2186) 2187 Application of Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT=51662 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2187) 2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2. M. Banan, M. Taylor, J. Cheng. September 1997. (Format: TXT=118374 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2188) 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --. A. Ballardie. September 1997. (Format: TXT=52043 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2189) 2190 RTP Payload Format for H.263 Video Streams. C. Zhu. September 1997. (Format: TXT=26409 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2190) 2191 VENUS - Very Extensive Non-Unicast Service. G. Armitage. September 1997. (Format: TXT=31316 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2191) 2192 IMAP URL Scheme. C. Newman. September 1997. (Format: TXT=31426 bytes) (Obsoleted by RFC5092) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2192) 2193 IMAP4 Mailbox Referrals. M. Gahrns. September 1997. (Format: TXT=16248 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2193) 2194 Review of Roaming Implementations. B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. September 1997. (Format: TXT=81533 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2194) 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. September 1997. (Format: TXT=10468 bytes) (Obsoletes RFC2095) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2195) 2196 Site Security Handbook. B. Fraser. September 1997. (Format: TXT=191772 bytes) (Obsoletes RFC1244) (Also FYI0008) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2196) 2197 SMTP Service Extension for Command Pipelining. N. Freed. September 1997. (Format: TXT=15003 bytes) (Obsoletes RFC1854) (Obsoleted by RFC2920) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2197) 2198 RTP Payload for Redundant Audio Data. C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis. September 1997. (Format: TXT=25166 bytes) (Updated by RFC6354) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2198) 2199 Request for Comments Summary RFC Numbers 2100-2199. A. Ramos. January 1998. (Format: TXT=47664 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2199) 2200 Internet Official Protocol Standards. J. Postel. June 1997. (Format: TXT=94506 bytes) (Obsoletes RFC1250, RFC2000) (Obsoleted by RFC2300) (Status: HISTORIC) (DOI: 10.17487/RFC2200) 2201 Core Based Trees (CBT) Multicast Routing Architecture. A. Ballardie. September 1997. (Format: TXT=38040 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2201) 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1. P. Cheng, R. Glenn. September 1997. (Format: TXT=11945 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2202) 2203 RPCSEC_GSS Protocol Specification. M. Eisler, A. Chiu, L. Ling. September 1997. (Format: TXT=50937 bytes) (Updated by RFC5403) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2203) 2204 ODETTE File Transfer Protocol. D. Nash. September 1997. (Format: TXT=151857 bytes) (Obsoleted by RFC5024) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2204) 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September 1997. (Format: TXT=223974 bytes) (Updated by RFC2750, RFC3936, RFC4495, RFC5946, RFC6437, RFC6780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2205) 2206 RSVP Management Information Base using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT=112937 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2206) 2207 RSVP Extensions for IPSEC Data Flows. L. Berger, T. O'Malley. September 1997. (Format: TXT=30473 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2207) 2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment. A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang. September 1997. (Format: TXT=14289 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2208) 2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules. R. Braden, L. Zhang. September 1997. (Format: TXT=51690 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2209) 2210 The Use of RSVP with IETF Integrated Services. J. Wroclawski. September 1997. (Format: TXT=77613 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2210) 2211 Specification of the Controlled-Load Network Element Service. J. Wroclawski. September 1997. (Format: TXT=46523 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2211) 2212 Specification of Guaranteed Quality of Service. S. Shenker, C. Partridge, R. Guerin. September 1997. (Format: TXT=52330 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2212) 2213 Integrated Services Management Information Base using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT=36147 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2213) 2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT=15971 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2214) 2215 General Characterization Parameters for Integrated Service Network Elements. S. Shenker, J. Wroclawski. September 1997. (Format: TXT=39552 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2215) 2216 Network Element Service Specification Template. S. Shenker, J. Wroclawski. September 1997. (Format: TXT=53655 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2216) 2217 Telnet Com Port Control Option. G. Clark. October 1997. (Format: TXT=31664 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2217) 2218 A Common Schema for the Internet White Pages Service. T. Genovese, B. Jennings. October 1997. (Format: TXT=16258 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2218) 2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2219) 2220 The Application/MARC Content-type. R. Guenther. October 1997. (Format: TXT=7025 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2220) 2221 IMAP4 Login Referrals. M. Gahrns. October 1997. (Format: TXT=9251 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2221) 2222 Simple Authentication and Security Layer (SASL). J. Myers. October 1997. (Format: TXT=35010 bytes) (Obsoleted by RFC4422, RFC4752) (Updated by RFC2444) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2222) 2223 Instructions to RFC Authors. J. Postel, J. Reynolds. October 1997. (Format: TXT=37948 bytes) (Obsoletes RFC1543, RFC1111, RFC0825) (Obsoleted by RFC7322) (Updated by RFC5741, RFC6949) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2223) 2224 NFS URL Scheme. B. Callaghan. October 1997. (Format: TXT=22726 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2224) 2225 Classical IP and ARP over ATM. M. Laubach, J. Halpern. April 1998. (Format: TXT=65779 bytes) (Obsoletes RFC1626, RFC1577) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2225) 2226 IP Broadcast over ATM Networks. T. Smith, G. Armitage. October 1997. (Format: TXT=30661 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2226) 2227 Simple Hit-Metering and Usage-Limiting for HTTP. J. Mogul, P. Leach. October 1997. (Format: TXT=85127 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2227) 2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997. (Format: TXT=58733 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2228) 2229 A Dictionary Server Protocol. R. Faith, B. Martin. October 1997. (Format: TXT=59551 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2229) 2230 Key Exchange Delegation Record for the DNS. R. Atkinson. November 1997. (Format: TXT=25563 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2230) 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997. (Format: TXT=19280 bytes) (Obsoletes RFC2184) (Updates RFC2045, RFC2047, RFC2183) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2231) 2232 Definitions of Managed Objects for DLUR using SMIv2. B. Clouston, Ed., B. Moore, Ed.. November 1997. (Format: TXT=37955 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2232) 2233 The Interfaces Group MIB using SMIv2. K. McCloghrie, F. Kastenholz. November 1997. (Format: TXT=148033 bytes) (Obsoletes RFC1573) (Obsoleted by RFC2863) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2233) 2234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. November 1997. (Format: TXT=24265 bytes) (Obsoleted by RFC4234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2234) 2235 Hobbes' Internet Timeline. R. Zakon. November 1997. (Format: TXT=43060 bytes) (Also FYI0032) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2235) 2236 Internet Group Management Protocol, Version 2. W. Fenner. November 1997. (Format: TXT=51048 bytes) (Updates RFC1112) (Updated by RFC3376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2236) 2237 Japanese Character Encoding for Internet Messages. K. Tamaru. November 1997. (Format: TXT=11628 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2237) 2238 Definitions of Managed Objects for HPR using SMIv2. B. Clouston, Ed., B. Moore, Ed.. November 1997. (Format: TXT=65498 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2238) 2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. November 1997. (Format: TXT=80651 bytes) (Obsoleted by RFC2668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2239) 2240 A Legal Basis for Domain Name Allocation. O. Vaughan. November 1997. (Format: TXT=13602 bytes) (Obsoleted by RFC2352) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2240) 2241 DHCP Options for Novell Directory Services. D. Provan. November 1997. (Format: TXT=8419 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2241) 2242 NetWare/IP Domain Name and Information. R. Droms, K. Fong. November 1997. (Format: TXT=10653 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2242) 2243 OTP Extended Responses. C. Metz. November 1997. (Format: TXT=19730 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2243) 2244 ACAP -- Application Configuration Access Protocol. C. Newman, J. G. Myers. November 1997. (Format: TXT=154610 bytes) (Updated by RFC6075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2244) 2245 Anonymous SASL Mechanism. C. Newman. November 1997. (Format: TXT=9974 bytes) (Obsoleted by RFC4505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2245) 2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. (Format: TXT=170401 bytes) (Obsoleted by RFC4346) (Updated by RFC3546, RFC5746, RFC6176, RFC7465, RFC7507, RFC7919) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2246) 2247 Using Domains in LDAP/X.500 Distinguished Names. S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri. January 1998. (Format: TXT=12411 bytes) (Updated by RFC4519, RFC4524) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2247) 2248 Network Services Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT=34106 bytes) (Obsoletes RFC1565) (Obsoleted by RFC2788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2248) 2249 Mail Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT=52334 bytes) (Obsoletes RFC1566) (Obsoleted by RFC2789) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2249) 2250 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. Fernando, V. Goyal, M. Civanlar. January 1998. (Format: TXT=34293 bytes) (Obsoletes RFC2038) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2250) 2251 Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes, S. Kille. December 1997. (Format: TXT=114488 bytes) (Obsoleted by RFC4510, RFC4511, RFC4513, RFC4512) (Updated by RFC3377, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2251) 2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. M. Wahl, A. Coulbeck, T. Howes, S. Kille. December 1997. (Format: TXT=60204 bytes) (Obsoleted by RFC4510, RFC4517, RFC4523, RFC4512) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2252) 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. M. Wahl, S. Kille, T. Howes. December 1997. (Format: TXT=18226 bytes) (Obsoletes RFC1779) (Obsoleted by RFC4510, RFC4514) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2253) 2254 The String Representation of LDAP Search Filters. T. Howes. December 1997. (Format: TXT=13511 bytes) (Obsoletes RFC1960) (Obsoleted by RFC4510, RFC4515) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2254) 2255 The LDAP URL Format. T. Howes, M. Smith. December 1997. (Format: TXT=20685 bytes) (Obsoletes RFC1959) (Obsoleted by RFC4510, RFC4516) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2255) 2256 A Summary of the X.500(96) User Schema for use with LDAPv3. M. Wahl. December 1997. (Format: TXT=32377 bytes) (Obsoleted by RFC4517, RFC4519, RFC4523, RFC4512, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2256) 2257 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. Wijnen, D. Francisco. January 1998. (Format: TXT=177452 bytes) (Obsoleted by RFC2741) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2257) 2258 Internet Nomenclator Project. J. Ordille. January 1998. (Format: TXT=34871 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2258) 2259 Simple Nomenclator Query Protocol (SNQP). J. Elliott, J. Ordille. January 1998. (Format: TXT=58508 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2259) 2260 Scalable Support for Multi-homed Multi-provider Connectivity. T. Bates, Y. Rekhter. January 1998. (Format: TXT=28085 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2260) 2261 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT=128036 bytes) (Obsoleted by RFC2271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2261) 2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT=88254 bytes) (Obsoleted by RFC2272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2262) 2263 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. (Format: TXT=143493 bytes) (Obsoleted by RFC2273) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2263) 2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. January 1998. (Format: TXT=168759 bytes) (Obsoleted by RFC2274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2264) 2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. January 1998. (Format: TXT=77807 bytes) (Obsoleted by RFC2275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2265) 2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices. J. Flick. January 1998. (Format: TXT=134027 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2266) 2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. January 1998. (Format: TXT=21032 bytes) (Obsoleted by RFC2827) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2267) 2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. March 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2268) 2269 Using the MARS Model in non-ATM NBMA Networks. G. Armitage. January 1998. (Format: TXT=12094 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2269) 2270 Using a Dedicated AS for Sites Homed to a Single Provider. J. Stewart, T. Bates, R. Chandra, E. Chen. January 1998. (Format: TXT=12063 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2270) 2271 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT=128227 bytes) (Obsoletes RFC2261) (Obsoleted by RFC2571) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2271) 2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT=88445 bytes) (Obsoletes RFC2262) (Obsoleted by RFC2572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2272) 2273 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. (Format: TXT=143754 bytes) (Obsoletes RFC2263) (Obsoleted by RFC2573) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2273) 2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. January 1998. (Format: TXT=168950 bytes) (Obsoletes RFC2264) (Obsoleted by RFC2574) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2274) 2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. January 1998. (Format: TXT=77998 bytes) (Obsoletes RFC2265) (Obsoleted by RFC2575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2275) 2276 Architectural Principles of Uniform Resource Name Resolution. K. Sollins. January 1998. (Format: TXT=64811 bytes) (Updated by RFC3401) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2276) 2277 IETF Policy on Character Sets and Languages. H. Alvestrand. January 1998. (Format: TXT=16622 bytes) (Also BCP0018) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2277) 2278 IANA Charset Registration Procedures. N. Freed, J. Postel. January 1998. (Format: TXT=18881 bytes) (Obsoleted by RFC2978) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2278) 2279 UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998. (Format: TXT=21634 bytes) (Obsoletes RFC2044) (Obsoleted by RFC3629) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2279) 2280 Routing Policy Specification Language (RPSL). C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar. January 1998. (Format: TXT=114985 bytes) (Obsoleted by RFC2622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2280) 2281 Cisco Hot Standby Router Protocol (HSRP). T. Li, B. Cole, P. Morton, D. Li. March 1998. (Format: TXT=35161 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2281) 2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. February 1998. (Format: TXT=29852 bytes) (Obsoletes RFC2027) (Obsoleted by RFC2727) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2282) 2283 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. Katz, Y. Rekhter. February 1998. (Format: TXT=18946 bytes) (Obsoleted by RFC2858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2283) 2284 PPP Extensible Authentication Protocol (EAP). L. Blunk, J. Vollbrecht. March 1998. (Format: TXT=29452 bytes) (Obsoleted by RFC3748) (Updated by RFC2484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2284) 2285 Benchmarking Terminology for LAN Switching Devices. R. Mandeville. February 1998. (Format: TXT=43130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2285) 2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. J. Kapp. February 1998. (Format: TXT=11849 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2286) 2287 Definitions of System-Level Managed Objects for Applications. C. Krupczak, J. Saperia. February 1998. (Format: TXT=98210 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2287) 2288 Using Existing Bibliographic Identifiers as Uniform Resource Names. C. Lynch, C. Preston, R. Daniel. February 1998. (Format: TXT=21628 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2288) 2289 A One-Time Password System. N. Haller, C. Metz, P. Nesser, M. Straw. February 1998. (Format: TXT=56495 bytes) (Obsoletes RFC1938) (Also STD0061) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2289) 2290 Mobile-IPv4 Configuration Option for PPP IPCP. J. Solomon, S. Glass. February 1998. (Format: TXT=39421 bytes) (Updates RFC2002) (Updated by RFC2794) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2290) 2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web. J. Slein, F. Vitali, E. Whitehead, D. Durand. February 1998. (Format: TXT=44036 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2291) 2292 Advanced Sockets API for IPv6. W. Stevens, M. Thomas. February 1998. (Format: TXT=152077 bytes) (Obsoleted by RFC3542) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2292) 2293 Representing Tables and Subtrees in the X.500 Directory. S. Kille. March 1998. (Format: TXT=12539 bytes) (Obsoletes RFC1837) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2293) 2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree. S. Kille. March 1998. (Format: TXT=22059 bytes) (Obsoletes RFC1836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2294) 2295 Transparent Content Negotiation in HTTP. K. Holtman, A. Mutz. March 1998. (Format: TXT=125130 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2295) 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. K. Holtman, A. Mutz. March 1998. (Format: TXT=26932 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2296) 2297 Ipsilon's General Switch Management Protocol Specification Version 2.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. March 1998. (Format: TXT=280484 bytes) (Updates RFC1987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2297) 2298 An Extensible Message Format for Message Disposition Notifications. R. Fajman. March 1998. (Format: TXT=62059 bytes) (Obsoleted by RFC3798) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2298) 2299 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT=51234 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2299) 2300 Internet Official Protocol Standards. J. Postel. May 1998. (Format: TXT=128322 bytes) (Obsoletes RFC2200) (Obsoleted by RFC2400) (Status: HISTORIC) (DOI: 10.17487/RFC2300) 2301 File Format for Internet Fax. L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. March 1998. (Format: TXT=200525 bytes) (Obsoleted by RFC3949) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2301) 2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration. G. Parsons, J. Rafferty, S. Zilles. March 1998. (Format: TXT=14375 bytes) (Obsoleted by RFC3302) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2302) 2303 Minimal PSTN address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT=14625 bytes) (Obsoleted by RFC3191) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2303) 2304 Minimal FAX address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT=13236 bytes) (Obsoleted by RFC3192) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2304) 2305 A Simple Mode of Facsimile Using Internet Mail. K. Toyoda, H. Ohno, J. Murai, D. Wing. March 1998. (Format: TXT=24624 bytes) (Obsoleted by RFC3965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2305) 2306 Tag Image File Format (TIFF) - F Profile for Facsimile. G. Parsons, J. Rafferty. March 1998. (Format: TXT=59358 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2306) 2307 An Approach for Using LDAP as a Network Information Service. L. Howard. March 1998. (Format: TXT=41396 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2307) 2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998. (Format: TXT=41428 bytes) (Updates RFC1034, RFC1035) (Updated by RFC4035, RFC4033, RFC4034, RFC6604, RFC8020) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2308) 2309 Recommendations on Queue Management and Congestion Avoidance in the Internet. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. April 1998. (Format: TXT=38079 bytes) (Obsoleted by RFC7567) (Updated by RFC7141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2309) 2310 The Safe Response Header Field. K. Holtman. April 1998. (Format: TXT=8091 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2310) 2311 S/MIME Version 2 Message Specification. S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. (Format: TXT=70901 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2311) 2312 S/MIME Version 2 Certificate Handling. S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. March 1998. (Format: TXT=39829 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2312) 2313 PKCS #1: RSA Encryption Version 1.5. B. Kaliski. March 1998. (Format: TXT=37777 bytes) (Obsoleted by RFC2437) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2313) 2314 PKCS #10: Certification Request Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT=15814 bytes) (Obsoleted by RFC2986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2314) 2315 PKCS #7: Cryptographic Message Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT=69679 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2315) 2316 Report of the IAB Security Architecture Workshop. S. Bellovin. April 1998. (Format: TXT=19733 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2316) 2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P. Vixie. March 1998. (Format: TXT=17744 bytes) (Also BCP0020) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2317) 2318 The text/css Media Type. H. Lie, B. Bos, C. Lilley. March 1998. (Format: TXT=7819 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2318) 2319 Ukrainian Character Set KOI8-U. KOI8-U Working Group. April 1998. (Format: TXT=18042 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2319) 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB). M. Greene, J. Luciani, K. White, T. Kuo. April 1998. (Format: TXT=102116 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2320) 2321 RITA -- The Reliable Internetwork Troubleshooting Agent. A. Bressen. April 1998. (Format: TXT=12302 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2321) 2322 Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal, R. van Mook. April 1998. (Format: TXT=12665 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2322) 2323 IETF Identification and Security Guidelines. A. Ramos. April 1998. (Format: TXT=9257 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2323) 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. April 1998. (Format: TXT=19610 bytes) (Updated by RFC7168) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2324) 2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2. M. Slavitch. April 1998. (Format: TXT=12726 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2325) 2326 Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R. Lanphier. April 1998. (Format: TXT=195010 bytes) (Obsoleted by RFC7826) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2326) 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April 1998. (Format: TXT=87096 bytes) (Obsoleted by RFC4566) (Updated by RFC3266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2327) 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367 bytes) (Obsoletes RFC2178) (Updated by RFC5709, RFC6549, RFC6845, RFC6860, RFC7474, RFC8042) (Also STD0054) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2328) 2329 OSPF Standardization Report. J. Moy. April 1998. (Format: TXT=15130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2329) 2330 Framework for IP Performance Metrics. V. Paxson, G. Almes, J. Mahdavi, M. Mathis. May 1998. (Format: TXT=94387 bytes) (Updated by RFC7312) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2330) 2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update. M. Maher. April 1998. (Format: TXT=61119 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2331) 2332 NBMA Next Hop Resolution Protocol (NHRP). J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy. April 1998. (Format: TXT=126978 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2332) 2333 NHRP Protocol Applicability Statement. D. Cansever. April 1998. (Format: TXT=20164 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2333) 2334 Server Cache Synchronization Protocol (SCSP). J. Luciani, G. Armitage, J. Halpern, N. Doraswamy. April 1998. (Format: TXT=98161 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2334) 2335 A Distributed NHRP Service Using SCSP. J. Luciani. April 1998. (Format: TXT=14007 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2335) 2336 Classical IP and ARP over ATM to NHRP Transition. J. Luciani. July 1998. (Format: TXT=10500 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2336) 2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM. D. Farinacci, D. Meyer, Y. Rekhter. April 1998. (Format: TXT=16357 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2337) 2338 Virtual Router Redundancy Protocol. S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. April 1998. (Format: TXT=59871 bytes) (Obsoleted by RFC3768) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2338) 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols. The Internet Society, Sun Microsystems. May 1998. (Format: TXT=10745 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2339) 2340 Nortel's Virtual Network Switching (VNS) Overview. B. Jamoussi, D. Jamieson, D. Williston, S. Gabe. May 1998. (Format: TXT=30731 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2340) 2341 Cisco Layer Two Forwarding (Protocol) "L2F". A. Valencia, M. Littlewood, T. Kolar. May 1998. (Format: TXT=66592 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2341) 2342 IMAP4 Namespace. M. Gahrns, C. Newman. May 1998. (Format: TXT=19489 bytes) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2342) 2343 RTP Payload Format for Bundled MPEG. M. Civanlar, G. Cash, B. Haskell. May 1998. (Format: TXT=16557 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2343) 2344 Reverse Tunneling for Mobile IP. G. Montenegro, Ed.. May 1998. (Format: TXT=39468 bytes) (Obsoleted by RFC3024) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2344) 2345 Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G. Oglesby. May 1998. (Format: TXT=29707 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2345) 2346 Making Postscript and PDF International. J. Palme. May 1998. (Format: TXT=12382 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2346) 2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: TXT=13060 bytes) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2347) 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: TXT=9515 bytes) (Obsoletes RFC1783) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2348) 2349 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. May 1998. (Format: TXT=7848 bytes) (Obsoletes RFC1784) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2349) 2350 Expectations for Computer Security Incident Response. N. Brownlee, E. Guttman. June 1998. (Format: TXT=86545 bytes) (Also BCP0021) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2350) 2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP. A. Robert. May 1998. (Format: TXT=43440 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2351) 2352 A Convention For Using Legal Names as Domain Names. O. Vaughan. May 1998. (Format: TXT=16354 bytes) (Obsoletes RFC2240) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2352) 2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document. G. Dudley. May 1998. (Format: TXT=116972 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2353) 2354 Options for Repair of Streaming Media. C. Perkins, O. Hodson. June 1998. (Format: TXT=28876 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2354) 2355 TN3270 Enhancements. B. Kelly. June 1998. (Format: TXT=89394 bytes) (Obsoletes RFC1647) (Updated by RFC6270) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2355) 2356 Sun's SKIP Firewall Traversal for Mobile IP. G. Montenegro, V. Gupta. June 1998. (Format: TXT=53198 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2356) 2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols. A. Mankin, A. Romanow, S. Bradner, V. Paxson. June 1998. (Format: TXT=24130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2357) 2358 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick, J. Johnson. June 1998. (Format: TXT=87891 bytes) (Obsoletes RFC1650) (Obsoleted by RFC2665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2358) 2359 IMAP4 UIDPLUS extension. J. Myers. June 1998. (Format: TXT=10862 bytes) (Obsoleted by RFC4315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2359) 2360 Guide for Internet Standards Writers. G. Scott. June 1998. (Format: TXT=47280 bytes) (Also BCP0022) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2360) 2361 WAVE and AVI Codec Registries. E. Fleischman. June 1998. (Format: TXT=97796 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2361) 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1998. (Format: TXT=159833 bytes) (Obsoletes RFC2117) (Obsoleted by RFC4601, RFC5059) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2362) 2363 PPP Over FUNI. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT=22576 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2363) 2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT=23539 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2364) 2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. (Format: TXT=17770 bytes) (Also BCP0023) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2365) 2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks. C. Chung, M. Greene. July 1998. (Format: TXT=134312 bytes) (Obsoleted by RFC2417) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2366) 2367 PF_KEY Key Management API, Version 2. D. McDonald, C. Metz, B. Phan. July 1998. (Format: TXT=146754 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2367) 2368 The mailto URL scheme. P. Hoffman, L. Masinter, J. Zawinski. July 1998. (Format: TXT=16502 bytes) (Obsoleted by RFC6068) (Updates RFC1738, RFC1808) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2368) 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2369) 2370 The OSPF Opaque LSA Option. R. Coltun. July 1998. (Format: TXT=33789 bytes) (Obsoleted by RFC5250) (Updated by RFC3630) (Also RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2370) 2371 Transaction Internet Protocol Version 3.0. J. Lyon, K. Evans, J. Klein. July 1998. (Format: TXT=71399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2371) 2372 Transaction Internet Protocol - Requirements and Supplemental Information. K. Evans, J. Klein, J. Lyon. July 1998. (Format: TXT=53699 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2372) 2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July 1998. (Format: TXT=52526 bytes) (Obsoletes RFC1884) (Obsoleted by RFC3513) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2373) 2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M. O'Dell, S. Deering. July 1998. (Format: TXT=25068 bytes) (Obsoletes RFC2073) (Obsoleted by RFC3587) (Status: HISTORIC) (DOI: 10.17487/RFC2374) 2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Format: TXT=14356 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2375) 2376 XML Media Types. E. Whitehead, M. Murata. July 1998. (Format: TXT=32143 bytes) (Obsoleted by RFC3023) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2376) 2377 Naming Plan for Internet Directory-Enabled Applications. A. Grimstad, R. Huber, S. Sataluri, M. Wahl. September 1998. (Format: TXT=38274 bytes) (Updated by RFC4519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2377) 2378 The CCSO Nameserver (Ph) Architecture. R. Hedberg, P. Pomes. September 1998. (Format: TXT=38960 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2378) 2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. (Format: TXT=15174 bytes) (Also BCP0024) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2379) 2380 RSVP over ATM Implementation Requirements. L. Berger. August 1998. (Format: TXT=31234 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2380) 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM. M. Garrett, M. Borden. August 1998. (Format: TXT=107299 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2381) 2382 A Framework for Integrated Services and RSVP over ATM. E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. August 1998. (Format: TXT=73865 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2382) 2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version. M. Suzuki. August 1998. (Format: TXT=99889 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2383) 2384 POP URL Scheme. R. Gellens. August 1998. (Format: TXT=13649 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2384) 2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A. Heffernan. August 1998. (Format: TXT=12315 bytes) (Obsoleted by RFC5925) (Updated by RFC6691) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2385) 2386 A Framework for QoS-based Routing in the Internet. E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. August 1998. (Format: TXT=93459 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2386) 2387 The MIME Multipart/Related Content-type. E. Levinson. August 1998. (Format: TXT=18864 bytes) (Obsoletes RFC2112) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2387) 2388 Returning Values from Forms: multipart/form-data. L. Masinter. August 1998. (Format: TXT=16531 bytes) (Obsoleted by RFC7578) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2388) 2389 Feature negotiation mechanism for the File Transfer Protocol. P. Hethmon, R. Elz. August 1998. (Format: TXT=18536 bytes) (Also RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2389) 2390 Inverse Address Resolution Protocol. T. Bradley, C. Brown, A. Malis. September 1998. (Format: TXT=20849 bytes) (Obsoletes RFC1293) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2390) 2391 Load Sharing using IP Network Address Translation (LSNAT). P. Srisuresh, D. Gan. August 1998. (Format: TXT=44884 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2391) 2392 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. August 1998. (Format: TXT=11141 bytes) (Obsoletes RFC2111) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2392) 2393 IP Payload Compression Protocol (IPComp). A. Shacham, R. Monsour, R. Pereira, M. Thomas. December 1998. (Format: TXT=20757 bytes) (Obsoleted by RFC3173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2393) 2394 IP Payload Compression Using DEFLATE. R. Pereira. December 1998. (Format: TXT=11053 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2394) 2395 IP Payload Compression Using LZS. R. Friend, R. Monsour. December 1998. (Format: TXT=14882 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2395) 2396 Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998. (Format: TXT=83639 bytes) (Obsoleted by RFC3986) (Updates RFC1808, RFC1738) (Updated by RFC2732) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2396) 2397 The "data" URL scheme. L. Masinter. August 1998. (Format: TXT=9514 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2397) 2398 Some Testing Tools for TCP Implementors. S. Parker, C. Schmechel. August 1998. (Format: TXT=24107 bytes) (Also FYI0033) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2398) 2399 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT=45853 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2399) 2400 Internet Official Protocol Standards. J. Postel, J. Reynolds. September 1998. (Format: TXT=110969 bytes) (Obsoletes RFC2300) (Obsoleted by RFC2500) (Status: HISTORIC) (DOI: 10.17487/RFC2400) 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2401) 2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. (Format: TXT=52831 bytes) (Obsoletes RFC1826) (Obsoleted by RFC4302, RFC4305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2402) 2403 The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn. November 1998. (Format: TXT=13578 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2403) 2404 The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. November 1998. (Format: TXT=13089 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2404) 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N. Doraswamy. November 1998. (Format: TXT=20208 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2405) 2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998. (Format: TXT=54202 bytes) (Obsoletes RFC1827) (Obsoleted by RFC4303, RFC4305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2406) 2407 The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November 1998. (Format: TXT=67878 bytes) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2407) 2408 Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November 1998. (Format: TXT=209175 bytes) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2408) 2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998. (Format: TXT=94949 bytes) (Obsoleted by RFC4306) (Updated by RFC4109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2409) 2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent. November 1998. (Format: TXT=11239 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2410) 2411 IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November 1998. (Format: TXT=22983 bytes) (Obsoleted by RFC6071) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2411) 2412 The OAKLEY Key Determination Protocol. H. Orman. November 1998. (Format: TXT=118649 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2412) 2413 Dublin Core Metadata for Resource Discovery. S. Weibel, J. Kunze, C. Lagoze, M. Wolf. September 1998. (Format: TXT=15501 bytes) (Obsoleted by RFC5013) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2413) 2414 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. September 1998. (Format: TXT=32019 bytes) (Obsoleted by RFC3390) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2414) 2415 Simulation Studies of Increased Initial TCP Window Size. K. Poduri, K. Nichols. September 1998. (Format: TXT=24205 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2415) 2416 When TCP Starts Up With Four Packets Into Only Three Buffers. T. Shepard, C. Partridge. September 1998. (Format: TXT=12663 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2416) 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks. C. Chung, M. Greene. September 1998. (Format: TXT=134862 bytes) (Obsoletes RFC2366) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2417) 2418 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998. (Format: TXT=62857 bytes) (Obsoletes RFC1603) (Updated by RFC3934, RFC7475, RFC7776) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2418) 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis). K. Sklower, G. Meyer. September 1998. (Format: TXT=24414 bytes) (Obsoletes RFC1969) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2419) 2420 The PPP Triple-DES Encryption Protocol (3DESE). H. Kummert. September 1998. (Format: TXT=16729 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2420) 2421 Voice Profile for Internet Mail - version 2. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT=123663 bytes) (Obsoletes RFC1911) (Obsoleted by RFC3801) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2421) 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT=10157 bytes) (Obsoletes RFC1911) (Obsoleted by RFC3802) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2422) 2423 VPIM Voice Message MIME Sub-type Registration. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT=10729 bytes) (Obsoletes RFC1911) (Obsoleted by RFC3801) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2423) 2424 Content Duration MIME Header Definition. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT=7116 bytes) (Obsoleted by RFC3803) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2424) 2425 A MIME Content-Type for Directory Information. T. Howes, M. Smith, F. Dawson. September 1998. (Format: TXT=64478 bytes) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2425) 2426 vCard MIME Directory Profile. F. Dawson, T. Howes. September 1998. (Format: TXT=74646 bytes) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2426) 2427 Multiprotocol Interconnect over Frame Relay. C. Brown, A. Malis. September 1998. (Format: TXT=74671 bytes) (Obsoletes RFC1490, RFC1294) (Also STD0055) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2427) 2428 FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C. Metz. September 1998. (Format: TXT=16028 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2428) 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. October 1998. (Format: TXT=43166 bytes) (Obsoleted by RFC4629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2429) 2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE). T. Li, Y. Rekhter. October 1998. (Format: TXT=40148 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2430) 2431 RTP Payload Format for BT.656 Video Encoding. D. Tynan. October 1998. (Format: TXT=22323 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2431) 2432 Terminology for IP Multicast Benchmarking. K. Dubray. October 1998. (Format: TXT=29758 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2432) 2433 Microsoft PPP CHAP Extensions. G. Zorn, S. Cobb. October 1998. (Format: TXT=34502 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2433) 2434 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. October 1998. (Format: TXT=25092 bytes) (Obsoleted by RFC5226) (Updated by RFC3692) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2434) 2435 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart. October 1998. (Format: TXT=54173 bytes) (Obsoletes RFC2035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2435) 2436 Collaboration between ISOC/IETF and ITU-T. R. Brett, S. Bradner, G. Parsons. October 1998. (Format: TXT=31154 bytes) (Obsoleted by RFC3356) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2436) 2437 PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998. (Format: TXT=73529 bytes) (Obsoletes RFC2313) (Obsoleted by RFC3447) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2437) 2438 Advancement of MIB specifications on the IETF Standards Track. M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998. (Format: TXT=13633 bytes) (Also BCP0027) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2438) 2439 BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan. November 1998. (Format: TXT=86376 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2439) 2440 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R. Thayer. November 1998. (Format: TXT=141371 bytes) (Obsoleted by RFC4880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2440) 2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998. D. Cohen. November 1998. (Format: TXT=11992 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2441) 2442 The Batch SMTP Media Type. N. Freed, D. Newman, J. Belissent, M. Hoy. November 1998. (Format: TXT=18384 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2442) 2443 A Distributed MARS Service Using SCSP. J. Luciani, A. Gallo. November 1998. (Format: TXT=41451 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2443) 2444 The One-Time-Password SASL Mechanism. C. Newman. October 1998. (Format: TXT=13408 bytes) (Updates RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2444) 2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar). F. Dawson, D. Stenerson. November 1998. (Format: TXT=291838 bytes) (Obsoleted by RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2445) 2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries. S. Silverberg, S. Mansour, F. Dawson, R. Hopson. November 1998. (Format: TXT=225964 bytes) (Obsoleted by RFC5546) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2446) 2447 iCalendar Message-Based Interoperability Protocol (iMIP). F. Dawson, S. Mansour, S. Silverberg. November 1998. (Format: TXT=33480 bytes) (Obsoleted by RFC6047) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2447) 2448 AT&T's Error Resilient Video Transmission Technique. M. Civanlar, G. Cash, B. Haskell. November 1998. (Format: TXT=14655 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2448) 2449 POP3 Extension Mechanism. R. Gellens, C. Newman, L. Lundblade. November 1998. (Format: TXT=36017 bytes) (Updates RFC1939) (Updated by RFC5034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2449) 2450 Proposed TLA and NLA Assignment Rule. R. Hinden. December 1998. (Format: TXT=24486 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2450) 2451 The ESP CBC-Mode Cipher Algorithms. R. Pereira, R. Adams. November 1998. (Format: TXT=26400 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2451) 2452 IP Version 6 Management Information Base for the Transmission Control Protocol. M. Daniele. December 1998. (Format: TXT=19066 bytes) (Obsoleted by RFC4022) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2452) 2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT=98462 bytes) (Obsoletes RFC1723) (Updated by RFC4822) (Also STD0056) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2453) 2454 IP Version 6 Management Information Base for the User Datagram Protocol. M. Daniele. December 1998. (Format: TXT=15862 bytes) (Obsoleted by RFC4113) (Status: HISTORIC) (DOI: 10.17487/RFC2454) 2455 Definitions of Managed Objects for APPN. B. Clouston, B. Moore. November 1998. (Format: TXT=251061 bytes) (Obsoletes RFC2155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2455) 2456 Definitions of Managed Objects for APPN TRAPS. B. Clouston, B. Moore. November 1998. (Format: TXT=44023 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2456) 2457 Definitions of Managed Objects for Extended Border Node. B. Clouston, B. Moore. November 1998. (Format: TXT=54380 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2457) 2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations. H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan. November 1998. (Format: TXT=139100 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2458) 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999. (Format: TXT=278438 bytes) (Obsoleted by RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2459) 2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1998. (Format: TXT=85490 bytes) (Obsoletes RFC1883) (Updated by RFC5095, RFC5722, RFC5871, RFC6437, RFC6564, RFC6935, RFC6946, RFC7045, RFC7112) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2460) 2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998. (Format: TXT=222516 bytes) (Obsoletes RFC1970) (Obsoleted by RFC4861) (Updated by RFC4311) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2461) 2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT=61210 bytes) (Obsoletes RFC1971) (Obsoleted by RFC4862) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2462) 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering. December 1998. (Format: TXT=34190 bytes) (Obsoletes RFC1885) (Obsoleted by RFC4443) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2463) 2464 Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. December 1998. (Format: TXT=12725 bytes) (Obsoletes RFC1972) (Updated by RFC6085) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2464) 2465 Management Information Base for IP Version 6: Textual Conventions and General Group. D. Haskin, S. Onishi. December 1998. (Format: TXT=77339 bytes) (Obsoleted by RFC4293) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2465) 2466 Management Information Base for IP Version 6: ICMPv6 Group. D. Haskin, S. Onishi. December 1998. (Format: TXT=27547 bytes) (Obsoleted by RFC4293) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2466) 2467 Transmission of IPv6 Packets over FDDI Networks. M. Crawford. December 1998. (Format: TXT=16028 bytes) (Obsoletes RFC2019) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2467) 2468 I REMEMBER IANA. V. Cerf. October 1998. (Format: TXT=8543 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2468) 2469 A Caution On The Canonical Ordering Of Link-Layer Addresses. T. Narten, C. Burton. December 1998. (Format: TXT=9948 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2469) 2470 Transmission of IPv6 Packets over Token Ring Networks. M. Crawford, T. Narten, S. Thomas. December 1998. (Format: TXT=21677 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2470) 2471 IPv6 Testing Address Allocation. R. Hinden, R. Fink, J. Postel. December 1998. (Format: TXT=8031 bytes) (Obsoletes RFC1897) (Obsoleted by RFC3701) (Status: HISTORIC) (DOI: 10.17487/RFC2471) 2472 IP Version 6 over PPP. D. Haskin, E. Allen. December 1998. (Format: TXT=29696 bytes) (Obsoletes RFC2023) (Obsoleted by RFC5072, RFC5172) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2472) 2473 Generic Packet Tunneling in IPv6 Specification. A. Conta, S. Deering. December 1998. (Format: TXT=77956 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2473) 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. December 1998. (Format: TXT=50576 bytes) (Obsoletes RFC1455, RFC1349) (Updates RFC0791) (Updated by RFC3168, RFC3260) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2474) 2475 An Architecture for Differentiated Services. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format: TXT=94786 bytes) (Updated by RFC3260) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2475) 2476 Message Submission. R. Gellens, J. Klensin. December 1998. (Format: TXT=30050 bytes) (Obsoleted by RFC4409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2476) 2477 Criteria for Evaluating Roaming Protocols. B. Aboba, G. Zorn. January 1999. (Format: TXT=23530 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2477) 2478 The Simple and Protected GSS-API Negotiation Mechanism. E. Baize, D. Pinkas. December 1998. (Format: TXT=35581 bytes) (Obsoleted by RFC4178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2478) 2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API). C. Adams. December 1998. (Format: TXT=156070 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2479) 2480 Gateways and MIME Security Multiparts. N. Freed. January 1999. (Format: TXT=11751 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2480) 2481 A Proposal to add Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd. January 1999. (Format: TXT=64559 bytes) (Obsoleted by RFC3168) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2481) 2482 Language Tagging in Unicode Plain Text. K. Whistler, G. Adams. January 1999. (Format: TXT=27800 bytes) (Obsoleted by RFC6082) (Status: HISTORIC) (DOI: 10.17487/RFC2482) 2483 URI Resolution Services Necessary for URN Resolution. M. Mealling, R. Daniel. January 1999. (Format: TXT=30518 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2483) 2484 PPP LCP Internationalization Configuration Option. G. Zorn. January 1999. (Format: TXT=8330 bytes) (Updates RFC2284, RFC1994, RFC1570) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2484) 2485 DHCP Option for The Open Group's User Authentication Protocol. S. Drach. January 1999. (Format: TXT=7205 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2485) 2486 The Network Access Identifier. B. Aboba, M. Beadles. January 1999. (Format: TXT=14261 bytes) (Obsoleted by RFC4282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2486) 2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman. January 1999. (Format: TXT=15120 bytes) (Obsoleted by RFC3207) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2487) 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms. M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT=47857 bytes) (Also BCP0028) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2488) 2489 Procedure for Defining New DHCP Options. R. Droms. January 1999. (Format: TXT=10484 bytes) (Obsoleted by RFC2939) (Also BCP0029) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2489) 2490 A Simulation Model for IP Multicast with RSVP. M. Pullen, R. Malghan, L. Lavu, G. Duan, J. Ma, H. Nah. January 1999. (Format: TXT=74936, PS=1956365, PDF=135368 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2490) 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks. G. Armitage, P. Schulter, M. Jork, G. Harter. January 1999. (Format: TXT=100782 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2491) 2492 IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. January 1999. (Format: TXT=21199 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2492) 2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. K. Tesink, Ed.. January 1999. (Format: TXT=18749 bytes) (Obsoleted by RFC3593) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2493) 2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type. D. Fowler, Ed.. January 1999. (Format: TXT=47208 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2494) 2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types. D. Fowler, Ed.. January 1999. (Format: TXT=155560 bytes) (Obsoletes RFC1406) (Obsoleted by RFC3895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2495) 2496 Definitions of Managed Object for the DS3/E3 Interface Type. D. Fowler, Ed.. January 1999. (Format: TXT=124251 bytes) (Obsoletes RFC1407) (Obsoleted by RFC3896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2496) 2497 Transmission of IPv6 Packets over ARCnet Networks. I. Souvatzis. January 1999. (Format: TXT=10304 bytes) (Also RFC1201) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2497) 2498 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. January 1999. (Format: TXT=17869 bytes) (Obsoleted by RFC2678) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2498) 2499 Request for Comments Summary. A. Ramos. July 1999. (Format: TXT=43431 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2499) 2500 Internet Official Protocol Standards. J. Reynolds, R. Braden. June 1999. (Format: TXT=78845 bytes) (Obsoletes RFC2400) (Obsoleted by RFC2600) (Status: HISTORIC) (DOI: 10.17487/RFC2500) 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations. S. Corson, J. Macker. January 1999. (Format: TXT=28912 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2501) 2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment. M. Pullen, M. Myjak, C. Bouwens. February 1999. (Format: TXT=28190 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2502) 2503 MIME Types for Use with the ISO ILL Protocol. R. Moulton, M. Needleman. February 1999. (Format: TXT=9078 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2503) 2504 Users' Security Handbook. E. Guttman, L. Leong, G. Malkin. February 1999. (Format: TXT=74036 bytes) (Also FYI0034) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2504) 2505 Anti-Spam Recommendations for SMTP MTAs. G. Lindberg. February 1999. (Format: TXT=53597 bytes) (Also BCP0030) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2505) 2506 Media Feature Tag Registration Procedure. K. Holtman, A. Mutz, T. Hardie. March 1999. (Format: TXT=24892 bytes) (Also BCP0031) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2506) 2507 IP Header Compression. M. Degermark, B. Nordgren, S. Pink. February 1999. (Format: TXT=106292 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2507) 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. S. Casner, V. Jacobson. February 1999. (Format: TXT=60474 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2508) 2509 IP Header Compression over PPP. M. Engan, S. Casner, C. Bormann. February 1999. (Format: TXT=18676 bytes) (Obsoleted by RFC3544) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2509) 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols. C. Adams, S. Farrell. March 1999. (Format: TXT=158178 bytes) (Obsoleted by RFC4210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2510) 2511 Internet X.509 Certificate Request Message Format. M. Myers, C. Adams, D. Solo, D. Kemp. March 1999. (Format: TXT=48278 bytes) (Obsoleted by RFC4211) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2511) 2512 Accounting Information for ATM Networks. K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. February 1999. (Format: TXT=29119 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2512) 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks. K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. February 1999. (Format: TXT=60789 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2513) 2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management. M. Noto, E. Spiegel, K. Tesink. February 1999. (Format: TXT=37583 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2514) 2515 Definitions of Managed Objects for ATM Management. K. Tesink, Ed. February 1999. (Format: TXT=179993 bytes) (Obsoletes RFC1695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2515) 2516 A Method for Transmitting PPP Over Ethernet (PPPoE). L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format: TXT=32537 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2516) 2517 Building Directories from DNS: Experiences from WWWSeeker. R. Moats, R. Huber. February 1999. (Format: TXT=14001 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2517) 2518 HTTP Extensions for Distributed Authoring -- WEBDAV. Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. February 1999. (Format: TXT=202829 bytes) (Obsoleted by RFC4918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2518) 2519 A Framework for Inter-Domain Route Aggregation. E. Chen, J. Stewart. February 1999. (Format: TXT=25394 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2519) 2520 NHRP with Mobile NHCs. J. Luciani, H. Suzuki, N. Doraswamy, D. Horton. February 1999. (Format: TXT=16763 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2520) 2521 ICMP Security Failures Messages. P. Karn, W. Simpson. March 1999. (Format: TXT=14637 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2521) 2522 Photuris: Session-Key Management Protocol. P. Karn, W. Simpson. March 1999. (Format: TXT=157224 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2522) 2523 Photuris: Extended Schemes and Attributes. P. Karn, W. Simpson. March 1999. (Format: TXT=38166 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2523) 2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3. M. Banan. February 1999. (Format: TXT=153171 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2524) 2525 Known TCP Implementation Problems. V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz. March 1999. (Format: TXT=137201 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2525) 2526 Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. (Format: TXT=14555 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2526) 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford. March 1999. (Format: TXT=91860 bytes) (Obsoleted by RFC3647) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2527) 2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates. R. Housley, W. Polk. March 1999. (Format: TXT=18273 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2528) 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2529) 2530 Indicating Supported Media Features Using Extensions to DSN and MDN. D. Wing. March 1999. (Format: TXT=7824 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2530) 2531 Content Feature Schema for Internet Fax. G. Klyne, L. McIntyre. March 1999. (Format: TXT=88295 bytes) (Obsoleted by RFC2879) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2531) 2532 Extended Facsimile Using Internet Mail. L. Masinter, D. Wing. March 1999. (Format: TXT=22717 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2532) 2533 A Syntax for Describing Media Feature Sets. G. Klyne. March 1999. (Format: TXT=79057 bytes) (Updated by RFC2738, RFC2938) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2533) 2534 Media Features for Display, Print, and Fax. L. Masinter, D. Wing, A. Mutz, K. Holtman. March 1999. (Format: TXT=15466 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2534) 2535 Domain Name System Security Extensions. D. Eastlake 3rd. March 1999. (Format: TXT=110958 bytes) (Obsoletes RFC2065) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2181, RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445, RFC3597, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2535) 2536 DSA KEYs and SIGs in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT=11121 bytes) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2536) 2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT=10810 bytes) (Obsoleted by RFC3110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2537) 2538 Storing Certificates in the Domain Name System (DNS). D. Eastlake 3rd, O. Gudmundsson. March 1999. (Format: TXT=19857 bytes) (Obsoleted by RFC4398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2538) 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT=21049 bytes) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2539) 2540 Detached Domain Name System (DNS) Information. D. Eastlake 3rd. March 1999. (Format: TXT=12546 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2540) 2541 DNS Security Operational Considerations. D. Eastlake 3rd. March 1999. (Format: TXT=14498 bytes) (Obsoleted by RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2541) 2542 Terminology and Goals for Internet Fax. L. Masinter. March 1999. (Format: TXT=46372 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2542) 2543 SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999. (Format: TXT=338861 bytes) (Obsoleted by RFC3261, RFC3262, RFC3263, RFC3264, RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2543) 2544 Benchmarking Methodology for Network Interconnect Devices. S. Bradner, J. McQuaid. March 1999. (Format: TXT=66688 bytes) (Obsoletes RFC1944) (Updated by RFC6201, RFC6815) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2544) 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont. March 1999. (Format: TXT=10209 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2545) 2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999. (Format: TXT=17844 bytes) (Obsoleted by RFC2772) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2546) 2547 BGP/MPLS VPNs. E. Rosen, Y. Rekhter. March 1999. (Format: TXT=63270 bytes) (Obsoleted by RFC4364) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2547) 2548 Microsoft Vendor-specific RADIUS Attributes. G. Zorn. March 1999. (Format: TXT=80763 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2548) 2549 IP over Avian Carriers with Quality of Service. D. Waitzman. April 1999. (Format: TXT=9519 bytes) (Updates RFC1149) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2549) 2550 Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. April 1999. (Format: TXT=28011 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2550) 2551 The Roman Standards Process -- Revision III. S. Bradner. April 1999. (Format: TXT=28054 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2551) 2552 Architecture for the Information Brokerage in the ACTS Project GAIA. M. Blinov, M. Bessonov, C. Clissmann. April 1999. (Format: TXT=65172 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2552) 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2553) 2554 SMTP Service Extension for Authentication. J. Myers. March 1999. (Format: TXT=20534 bytes) (Obsoleted by RFC4954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2554) 2555 30 Years of RFCs. RFC Editor, et al.. April 1999. (Format: TXT=42902 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2555) 2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status. S. Bradner. March 1999. (Format: TXT=5864 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2556) 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann, N. Shelness. March 1999. (Format: TXT=61854 bytes) (Obsoletes RFC2110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2557) 2558 Definitions of Managed Objects for the SONET/SDH Interface Type. K. Tesink. March 1999. (Format: TXT=138550 bytes) (Obsoletes RFC1595) (Obsoleted by RFC3592) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2558) 2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2. S. Boeyen, T. Howes, P. Richard. April 1999. (Format: TXT=22889 bytes) (Obsoleted by RFC3494) (Updates RFC1778) (Status: HISTORIC) (DOI: 10.17487/RFC2559) 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 1999. (Format: TXT=43243 bytes) (Obsoleted by RFC6960) (Updated by RFC6277) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2560) 2561 Base Definitions of Managed Objects for TN3270E Using SMIv2. K. White, R. Moore. April 1999. (Format: TXT=113705 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2561) 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB). K. White, R. Moore. April 1999. (Format: TXT=110633 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2562) 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients. R. Troll. May 1999. (Format: TXT=17838 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2563) 2564 Application Management MIB. C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. May 1999. (Format: TXT=183314 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2564) 2565 Internet Printing Protocol/1.0: Encoding and Transport. R. Herriot, Ed., S. Butler, P. Moore, R. Turner. April 1999. (Format: TXT=80439 bytes) (Obsoleted by RFC2910) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2565) 2566 Internet Printing Protocol/1.0: Model and Semantics. R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell. April 1999. (Format: TXT=438887 bytes) (Obsoleted by RFC2911) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2566) 2567 Design Goals for an Internet Printing Protocol. F. Wright. April 1999. (Format: TXT=90260 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2567) 2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol. S. Zilles. April 1999. (Format: TXT=23547 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2568) 2569 Mapping between LPD and IPP Protocols. R. Herriot, Ed., T. Hastings, N. Jacobs, J. Martin. April 1999. (Format: TXT=57886 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2569) 2570 Introduction to Version 3 of the Internet-standard Network Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. April 1999. (Format: TXT=50381 bytes) (Obsoleted by RFC3410) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2570) 2571 An Architecture for Describing SNMP Management Frameworks. B. Wijnen, D. Harrington, R. Presuhn. April 1999. (Format: TXT=139260 bytes) (Obsoletes RFC2271) (Obsoleted by RFC3411) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2571) 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. April 1999. (Format: TXT=96035 bytes) (Obsoletes RFC2272) (Obsoleted by RFC3412) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2572) 2573 SNMP Applications. D. Levi, P. Meyer, B. Stewart. April 1999. (Format: TXT=150427 bytes) (Obsoletes RFC2273) (Obsoleted by RFC3413) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2573) 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. April 1999. (Format: TXT=190755 bytes) (Obsoletes RFC2274) (Obsoleted by RFC3414) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2574) 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. April 1999. (Format: TXT=79642 bytes) (Obsoletes RFC2275) (Obsoleted by RFC3415) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2575) 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. March 2000. (Format: TXT=98589 bytes) (Obsoletes RFC1908, RFC2089) (Obsoleted by RFC3584) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2576) 2577 FTP Security Considerations. M. Allman, S. Ostermann. May 1999. (Format: TXT=17870 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2577) 2578 Structure of Management Information Version 2 (SMIv2). K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT=89712 bytes) (Obsoletes RFC1902) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2578) 2579 Textual Conventions for SMIv2. K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT=59039 bytes) (Obsoletes RFC1903) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2579) 2580 Conformance Statements for SMIv2. K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT=54253 bytes) (Obsoletes RFC1904) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2580) 2581 TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April 1999. (Format: TXT=31351 bytes) (Obsoletes RFC2001) (Obsoleted by RFC5681) (Updated by RFC3390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2581) 2582 The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T. Henderson. April 1999. (Format: TXT=29393 bytes) (Obsoleted by RFC3782) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2582) 2583 Guidelines for Next Hop Client (NHC) Developers. R. Carlson, L. Winkler. May 1999. (Format: TXT=21338 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2583) 2584 Definitions of Managed Objects for APPN/HPR in IP Networks. B. Clouston, B. Moore. May 1999. (Format: TXT=40187 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2584) 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP. R. Housley, P. Hoffman. May 1999. (Format: TXT=14813 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2585) 2586 The Audio/L16 MIME content type. J. Salsman, H. Alvestrand. May 1999. (Format: TXT=8694 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2586) 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema. S. Boeyen, T. Howes, P. Richard. June 1999. (Format: TXT=15102 bytes) (Obsoleted by RFC4523) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2587) 2588 IP Multicast and Firewalls. R. Finlayson. May 1999. (Format: TXT=28622 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2588) 2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services. Y. Yaacovi, M. Wahl, T. Genovese. May 1999. (Format: TXT=26855 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2589) 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification. A. Conta, A. Malis, M. Mueller. May 1999. (Format: TXT=41817 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2590) 2591 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT=52920 bytes) (Obsoleted by RFC3231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2591) 2592 Definitions of Managed Objects for the Delegation of Management Script. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT=110629 bytes) (Obsoleted by RFC3165) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2592) 2593 Script MIB Extensibility Protocol Version 1.0. J. Schoenwaelder, J. Quittek. May 1999. (Format: TXT=49663 bytes) (Obsoleted by RFC3179) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2593) 2594 Definitions of Managed Objects for WWW Services. H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder. May 1999. (Format: TXT=88876 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2594) 2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. (Format: TXT=32440 bytes) (Updated by RFC4616, RFC7817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2595) 2596 Use of Language Codes in LDAP. M. Wahl, T. Howes. May 1999. (Format: TXT=17413 bytes) (Obsoleted by RFC3866) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2596) 2597 Assured Forwarding PHB Group. J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. June 1999. (Format: TXT=24068 bytes) (Updated by RFC3260) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2597) 2598 An Expedited Forwarding PHB. V. Jacobson, K. Nichols, K. Poduri. June 1999. (Format: TXT=23656 bytes) (Obsoleted by RFC3246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2598) 2599 Request for Comments Summary RFC Numbers 2500-2599. A. DeLaCruz. March 2000. (Format: TXT=45845 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2599) 2600 Internet Official Protocol Standards. J. Reynolds, R. Braden. March 2000. (Format: TXT=86139 bytes) (Obsoletes RFC2500) (Obsoleted by RFC2700) (Status: HISTORIC) (DOI: 10.17487/RFC2600) 2601 ILMI-Based Server Discovery for ATMARP. M. Davison. June 1999. (Format: TXT=11820 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2601) 2602 ILMI-Based Server Discovery for MARS. M. Davison. June 1999. (Format: TXT=12031 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2602) 2603 ILMI-Based Server Discovery for NHRP. M. Davison. June 1999. (Format: TXT=11865 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2603) 2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. June 1999. (Format: TXT=65329 bytes) (Obsoleted by RFC2636) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2604) 2605 Directory Server Monitoring MIB. G. Mansfield, S. Kille. June 1999. (Format: TXT=49166 bytes) (Obsoletes RFC1567) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2605) 2606 Reserved Top Level DNS Names. D. Eastlake 3rd, A. Panitz. June 1999. (Format: TXT=8008 bytes) (Updated by RFC6761) (Also BCP0032) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2606) 2607 Proxy Chaining and Policy Implementation in Roaming. B. Aboba, J. Vollbrecht. June 1999. (Format: TXT=33271 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2607) 2608 Service Location Protocol, Version 2. E. Guttman, C. Perkins, J. Veizades, M. Day. June 1999. (Format: TXT=129475 bytes) (Updates RFC2165) (Updated by RFC3224) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2608) 2609 Service Templates and Service: Schemes. E. Guttman, C. Perkins, J. Kempf. June 1999. (Format: TXT=72842 bytes) (Updates RFC2165) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2609) 2610 DHCP Options for Service Location Protocol. C. Perkins, E. Guttman. June 1999. (Format: TXT=10859 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2610) 2611 URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. June 1999. (Format: TXT=26916 bytes) (Obsoleted by RFC3406) (Also BCP0033) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2611) 2612 The CAST-256 Encryption Algorithm. C. Adams, J. Gilchrist. June 1999. (Format: TXT=37468 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2612) 2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0. R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser. June 1999. (Format: TXT=88701 bytes) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2613) 2614 An API for Service Location. J. Kempf, E. Guttman. June 1999. (Format: TXT=164002 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2614) 2615 PPP over SONET/SDH. A. Malis, W. Simpson. June 1999. (Format: TXT=18708 bytes) (Obsoletes RFC1619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2615) 2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999. (Format: TXT=422317, PS=5529857, PDF=550558 bytes) (Obsoletes RFC2068) (Obsoleted by RFC7230, RFC7231, RFC7232, RFC7233, RFC7234, RFC7235) (Updated by RFC2817, RFC5785, RFC6266, RFC6585) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2616) 2617 HTTP Authentication: Basic and Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. June 1999. (Format: TXT=77638 bytes) (Obsoletes RFC2069) (Obsoleted by RFC7235, RFC7615, RFC7616, RFC7617) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2617) 2618 RADIUS Authentication Client MIB. B. Aboba, G. Zorn. June 1999. (Format: TXT=26889 bytes) (Obsoleted by RFC4668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2618) 2619 RADIUS Authentication Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT=30464 bytes) (Obsoleted by RFC4669) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2619) 2620 RADIUS Accounting Client MIB. B. Aboba, G. Zorn. June 1999. (Format: TXT=23960 bytes) (Obsoleted by RFC4670) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2620) 2621 RADIUS Accounting Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT=27768 bytes) (Obsoleted by RFC4671) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2621) 2622 Routing Policy Specification Language (RPSL). C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra. June 1999. (Format: TXT=140811 bytes) (Obsoletes RFC2280) (Updated by RFC4012, RFC7909) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2622) 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5. M. Eisler. June 1999. (Format: TXT=42521 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2623) 2624 NFS Version 4 Design Considerations. S. Shepler. June 1999. (Format: TXT=52891 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2624) 2625 IP and ARP over Fibre Channel. M. Rajagopal, R. Bhagwat, W. Rickard. June 1999. (Format: TXT=137741 bytes) (Obsoleted by RFC4338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2625) 2626 The Internet and the Millennium Problem (Year 2000). P. Nesser II. June 1999. (Format: TXT=547560 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2626) 2627 Key Management for Multicast: Issues and Architectures. D. Wallner, E. Harder, R. Agee. June 1999. (Format: TXT=59263 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2627) 2628 Simple Cryptographic Program Interface (Crypto API). V. Smyslov. June 1999. (Format: TXT=60070 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2628) 2629 Writing I-Ds and RFCs using XML. M. Rose. June 1999. (Format: TXT=48677 bytes) (Obsoleted by RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2629) 2630 Cryptographic Message Syntax. R. Housley. June 1999. (Format: TXT=128599 bytes) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2630) 2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999. (Format: TXT=25932 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2631) 2632 S/MIME Version 3 Certificate Handling. B. Ramsdell, Ed.. June 1999. (Format: TXT=27925 bytes) (Obsoleted by RFC3850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2632) 2633 S/MIME Version 3 Message Specification. B. Ramsdell, Ed.. June 1999. (Format: TXT=67870 bytes) (Obsoleted by RFC3851) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2633) 2634 Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June 1999. (Format: TXT=131153 bytes) (Updated by RFC5035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2634) 2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*). S. Hambridge, A. Lunde. June 1999. (Format: TXT=44669 bytes) (Also FYI0035) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2635) 2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. July 1999. (Format: TXT=65288, PS=1120860, PDF=173655 bytes) (Obsoletes RFC2604) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2636) 2637 Point-to-Point Tunneling Protocol (PPTP). K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. July 1999. (Format: TXT=132565 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2637) 2638 A Two-bit Differentiated Services Architecture for the Internet. K. Nichols, V. Jacobson, L. Zhang. July 1999. (Format: TXT=72785, PS=1610846, PDF=315195 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2638) 2639 Internet Printing Protocol/1.0: Implementer's Guide. T. Hastings, C. Manros. July 1999. (Format: TXT=145086 bytes) (Obsoleted by RFC3196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2639) 2640 Internationalization of the File Transfer Protocol. B. Curtin. July 1999. (Format: TXT=57204 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2640) 2641 Cabletron's VlanHello Protocol Specification Version 4. D. Hamilton, D. Ruffen. August 1999. (Format: TXT=34686 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2641) 2642 Cabletron's VLS Protocol Specification. L. Kane. August 1999. (Format: TXT=204347 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2642) 2643 Cabletron's SecureFast VLAN Operational Model. D. Ruffen, T. Len, J. Yanacek. August 1999. (Format: TXT=121786 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2643) 2644 Changing the Default for Directed Broadcasts in Routers. D. Senie. August 1999. (Format: TXT=6820 bytes) (Updates RFC1812) (Also BCP0034) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2644) 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses. R. Gellens. August 1999. (Format: TXT=16302 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2645) 2646 The Text/Plain Format Parameter. R. Gellens, Ed.. August 1999. (Format: TXT=29175 bytes) (Obsoleted by RFC3676) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2646) 2647 Benchmarking Terminology for Firewall Performance. D. Newman. August 1999. (Format: TXT=45374 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2647) 2648 A URN Namespace for IETF Documents. R. Moats. August 1999. (Format: TXT=46826 bytes) (Updated by RFC6924) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2648) 2649 An LDAP Control and Schema for Holding Operation Signatures. B. Greenblatt, P. Richard. August 1999. (Format: TXT=20470 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2649) 2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu. August 1999. (Format: TXT=55272 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2650) 2651 The Architecture of the Common Indexing Protocol (CIP). J. Allen, M. Mealling. August 1999. (Format: TXT=41933 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2651) 2652 MIME Object Definitions for the Common Indexing Protocol (CIP). J. Allen, M. Mealling. August 1999. (Format: TXT=42464 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2652) 2653 CIP Transport Protocols. J. Allen, P. Leach, R. Hedberg. August 1999. (Format: TXT=22999 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2653) 2654 A Tagged Index Object for use in the Common Indexing Protocol. R. Hedberg, B. Greenblatt, R. Moats, M. Wahl. August 1999. (Format: TXT=46739 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2654) 2655 CIP Index Object Format for SOIF Objects. T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels. August 1999. (Format: TXT=34285 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2655) 2656 Registration Procedures for SOIF Template Types. T. Hardie. August 1999. (Format: TXT=17409 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2656) 2657 LDAPv2 Client vs. the Index Mesh. R. Hedberg. August 1999. (Format: TXT=19251 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2657) 2658 RTP Payload Format for PureVoice(tm) Audio. K. McKay. August 1999. (Format: TXT=21895 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2658) 2659 Security Extensions For HTML. E. Rescorla, A. Schiffman. August 1999. (Format: TXT=8134 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2659) 2660 The Secure HyperText Transfer Protocol. E. Rescorla, A. Schiffman. August 1999. (Format: TXT=95645 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2660) 2661 Layer Two Tunneling Protocol "L2TP". W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. August 1999. (Format: TXT=168150 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2661) 2662 Definitions of Managed Objects for the ADSL Lines. G. Bathrick, F. Ly. August 1999. (Format: TXT=247122 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2662) 2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. (Format: TXT=72265 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2663) 2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions. R. Plzak, A. Wells, E. Krol. August 1999. (Format: TXT=23640 bytes) (Obsoletes RFC1594) (Also FYI0004) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2664) 2665 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick, J. Johnson. August 1999. (Format: TXT=110038 bytes) (Obsoletes RFC2358) (Obsoleted by RFC3635) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2665) 2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets. J. Flick. August 1999. (Format: TXT=37699 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2666) 2667 IP Tunnel MIB. D. Thaler. August 1999. (Format: TXT=32770 bytes) (Obsoleted by RFC4087) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2667) 2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. August 1999. (Format: TXT=121843 bytes) (Obsoletes RFC2239) (Obsoleted by RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2668) 2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems. M. St. Johns, Ed.. August 1999. (Format: TXT=112880 bytes) (Obsoleted by RFC4639) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2669) 2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces. M. St. Johns, Ed.. August 1999. (Format: TXT=141077 bytes) (Obsoleted by RFC4546) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2670) 2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999. (Format: TXT=15257 bytes) (Obsoleted by RFC6891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2671) 2672 Non-Terminal DNS Name Redirection. M. Crawford. August 1999. (Format: TXT=18321 bytes) (Obsoleted by RFC6672) (Updated by RFC4592, RFC6604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2672) 2673 Binary Labels in the Domain Name System. M. Crawford. August 1999. (Format: TXT=12379 bytes) (Obsoleted by RFC6891) (Updates RFC1035) (Updated by RFC3363, RFC3364) (Status: HISTORIC) (DOI: 10.17487/RFC2673) 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions. E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. August 1999. (Format: TXT=159971 bytes) (Obsoleted by RFC4363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2674) 2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT=17320 bytes) (Obsoletes RFC2147) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2675) 2676 QoS Routing Mechanisms and OSPF Extensions. G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A. Orda, T. Przygienda. August 1999. (Format: TXT=124563 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2676) 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP). M. Greene, J. Cucchiara, J. Luciani. August 1999. (Format: TXT=129699 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2677) 2678 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. September 1999. (Format: TXT=18087 bytes) (Obsoletes RFC2498) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2678) 2679 A One-way Delay Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT=43542 bytes) (Obsoleted by RFC7679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2679) 2680 A One-way Packet Loss Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT=32266 bytes) (Obsoleted by RFC7680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2680) 2681 A Round-trip Delay Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT=44357 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2681) 2682 Performance Issues in VC-Merge Capable ATM LSRs. I. Widjaja, A. Elwalid. September 1999. (Format: TXT=29491 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2682) 2683 IMAP4 Implementation Recommendations. B. Leiba. September 1999. (Format: TXT=56300 bytes) (Updated by RFC7162) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2683) 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5. D. Grossman, J. Heinanen. September 1999. (Format: TXT=51390 bytes) (Obsoletes RFC1483) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2684) 2685 Virtual Private Networks Identifier. B. Fox, B. Gleeson. September 1999. (Format: TXT=11168 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2685) 2686 The Multi-Class Extension to Multi-Link PPP. C. Bormann. September 1999. (Format: TXT=24192 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2686) 2687 PPP in a Real-time Oriented HDLC-like Framing. C. Bormann. September 1999. (Format: TXT=28699 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2687) 2688 Integrated Services Mappings for Low Speed Networks. S. Jackowski, D. Putzolu, E. Crawley, B. Davie. September 1999. (Format: TXT=36685 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2688) 2689 Providing Integrated Services over Low-bitrate Links. C. Bormann. September 1999. (Format: TXT=34345 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2689) 2690 A Proposal for an MOU-Based ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT=14221 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2690) 2691 A Memorandum of Understanding for an ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT=18940 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2691) 2692 SPKI Requirements. C. Ellison. September 1999. (Format: TXT=29569 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2692) 2693 SPKI Certificate Theory. C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. September 1999. (Format: TXT=96699 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2693) 2694 DNS extensions to Network Address Translators (DNS_ALG). P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. September 1999. (Format: TXT=67720 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2694) 2695 Authentication Mechanisms for ONC RPC. A. Chiu. September 1999. (Format: TXT=39286 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2695) 2696 LDAP Control Extension for Simple Paged Results Manipulation. C. Weider, A. Herron, A. Anantha, T. Howes. September 1999. (Format: TXT=12809 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2696) 2697 A Single Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT=10309 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2697) 2698 A Two Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT=9368 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2698) 2699 Request for Comments Summary RFC Numbers 2600-2699. S. Ginoza. May 2000. (Format: TXT=42462 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2699) 2700 Internet Official Protocol Standards. J. Reynolds, R. Braden. August 2000. (Format: TXT=90213 bytes) (Obsoletes RFC2600) (Obsoleted by RFC2800) (Status: HISTORIC) (DOI: 10.17487/RFC2700) 2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol. G. Malkin. September 1999. (Format: TXT=17571 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2701) 2702 Requirements for Traffic Engineering Over MPLS. D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus. September 1999. (Format: TXT=68386 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2702) 2703 Protocol-independent Content Negotiation Framework. G. Klyne. September 1999. (Format: TXT=42071 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2703) 2704 The KeyNote Trust-Management System Version 2. M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. September 1999. (Format: TXT=79998 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2704) 2705 Media Gateway Control Protocol (MGCP) Version 1.0. M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. October 1999. (Format: TXT=304056 bytes) (Obsoleted by RFC3435) (Updated by RFC3660) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2705) 2706 ECML v1: Field Names for E-Commerce. D. Eastlake 3rd, T. Goldstein. October 1999. (Format: TXT=26135 bytes) (Obsoleted by RFC3106) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2706) 2707 Job Monitoring MIB - V1.0. R. Bergman, T. Hastings, S. Isaacson, H. Lewis. November 1999. (Format: TXT=255685 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2707) 2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB. R. Bergman. November 1999. (Format: TXT=57489 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2708) 2709 Security Model with Tunnel-mode IPsec for NAT Domains. P. Srisuresh. October 1999. (Format: TXT=24552 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2709) 2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Format: TXT=46838 bytes) (Updated by RFC3590, RFC3810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2710) 2711 IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. (Format: TXT=11973 bytes) (Updated by RFC6398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2711) 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2712) 2713 Schema for Representing Java(tm) Objects in an LDAP Directory. V. Ryan, S. Seligman, R. Lee. October 1999. (Format: TXT=40745 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2713) 2714 Schema for Representing CORBA Object References in an LDAP Directory. V. Ryan, R. Lee, S. Seligman. October 1999. (Format: TXT=14709 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2714) 2715 Interoperability Rules for Multicast Routing Protocols. D. Thaler. October 1999. (Format: TXT=49638 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2715) 2716 PPP EAP TLS Authentication Protocol. B. Aboba, D. Simon. October 1999. (Format: TXT=50108 bytes) (Obsoleted by RFC5216) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2716) 2717 Registration Procedures for URL Scheme Names. R. Petke, I. King. November 1999. (Format: TXT=19780 bytes) (Obsoleted by RFC4395) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2717) 2718 Guidelines for new URL Schemes. L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. November 1999. (Format: TXT=19208 bytes) (Obsoleted by RFC4395) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2718) 2719 Framework Architecture for Signaling Transport. L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp. October 1999. (Format: TXT=48646 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2719) 2720 Traffic Flow Measurement: Meter MIB. N. Brownlee. October 1999. (Format: TXT=103781 bytes) (Obsoletes RFC2064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2720) 2721 RTFM: Applicability Statement. N. Brownlee. October 1999. (Format: TXT=21200 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2721) 2722 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. October 1999. (Format: TXT=114064 bytes) (Obsoletes RFC2063) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2722) 2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups. N. Brownlee. October 1999. (Format: TXT=44406 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2723) 2724 RTFM: New Attributes for Traffic Flow Measurement. S. Handelman, S. Stibler, N. Brownlee, G. Ruth. October 1999. (Format: TXT=37951 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2724) 2725 Routing Policy System Security. C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. December 1999. (Format: TXT=101649 bytes) (Updated by RFC4012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2725) 2726 PGP Authentication for RIPE Database Updates. J. Zsako. December 1999. (Format: TXT=22594 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2726) 2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. February 2000. (Format: TXT=33396 bytes) (Obsoletes RFC2282) (Obsoleted by RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2727) 2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal. R. Panabaker, S. Wegerif, D. Zigmond. November 1999. (Format: TXT=49099 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2728) 2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications. P. Bagnall, R. Briscoe, A. Poppitt. December 1999. (Format: TXT=53322 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2729) 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP). S. Hanna, B. Patel, M. Shah. December 1999. (Format: TXT=120341 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2730) 2731 Encoding Dublin Core Metadata in HTML. J. Kunze. December 1999. (Format: TXT=42450 bytes) (Obsoleted by RFC5791) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2731) 2732 Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999. (Format: TXT=7984 bytes) (Obsoleted by RFC3986) (Updates RFC2396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2732) 2733 An RTP Payload Format for Generic Forward Error Correction. J. Rosenberg, H. Schulzrinne. December 1999. (Format: TXT=53120 bytes) (Obsoleted by RFC5109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2733) 2734 IPv4 over IEEE 1394. P. Johansson. December 1999. (Format: TXT=69314 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2734) 2735 NHRP Support for Virtual Private Networks. B. Fox, B. Petri. December 1999. (Format: TXT=26451 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2735) 2736 Guidelines for Writers of RTP Payload Format Specifications. M. Handley, C. Perkins. December 1999. (Format: TXT=24143 bytes) (Also BCP0036) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2736) 2737 Entity MIB (Version 2). K. McCloghrie, A. Bierman. December 1999. (Format: TXT=125141 bytes) (Obsoletes RFC2037) (Obsoleted by RFC4133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2737) 2738 Corrections to "A Syntax for Describing Media Feature Sets". G. Klyne. December 1999. (Format: TXT=8353 bytes) (Updates RFC2533) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2738) 2739 Calendar Attributes for vCard and LDAP. T. Small, D. Hennessy, F. Dawson. January 2000. (Format: TXT=25892 bytes) (Updated by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2739) 2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT=189810 bytes) (Obsoleted by RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2740) 2741 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. Wijnen, M. Ellison, D. Francisco. January 2000. (Format: TXT=199867 bytes) (Obsoletes RFC2257) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2741) 2742 Definitions of Managed Objects for Extensible SNMP Agents. L. Heintz, S. Gudur, M. Ellison. January 2000. (Format: TXT=36644 bytes) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2742) 2743 Generic Security Service Application Program Interface Version 2, Update 1. J. Linn. January 2000. (Format: TXT=229418 bytes) (Obsoletes RFC2078) (Updated by RFC5554) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2743) 2744 Generic Security Service API Version 2 : C-bindings. J. Wray. January 2000. (Format: TXT=218572 bytes) (Obsoletes RFC1509) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2744) 2745 RSVP Diagnostic Messages. A. Terzis, B. Braden, S. Vincent, L. Zhang. January 2000. (Format: TXT=52256 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2745) 2746 RSVP Operation Over IP Tunnels. A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. January 2000. (Format: TXT=58094 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2746) 2747 RSVP Cryptographic Authentication. F. Baker, B. Lindell, M. Talwar. January 2000. (Format: TXT=49477 bytes) (Updated by RFC3097) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2747) 2748 The COPS (Common Open Policy Service) Protocol. D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. January 2000. (Format: TXT=90906 bytes) (Updated by RFC4261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2748) 2749 COPS usage for RSVP. S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. January 2000. (Format: TXT=33477 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2749) 2750 RSVP Extensions for Policy Control. S. Herzog. January 2000. (Format: TXT=26379 bytes) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2750) 2751 Signaled Preemption Priority Policy Element. S. Herzog. January 2000. (Format: TXT=21451 bytes) (Obsoleted by RFC3181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2751) 2752 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog. January 2000. (Format: TXT=33954 bytes) (Obsoleted by RFC3182) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2752) 2753 A Framework for Policy-based Admission Control. R. Yavatkar, D. Pendarakis, R. Guerin. January 2000. (Format: TXT=49763 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2753) 2754 RPS IANA Issues. C. Alaettinoglu, C. Villamizar, R. Govindan. January 2000. (Format: TXT=11582 bytes) (Obsoleted by RFC6254) (Status: HISTORIC) (DOI: 10.17487/RFC2754) 2755 Security Negotiation for WebNFS. A. Chiu, M. Eisler, B. Callaghan. January 2000. (Format: TXT=23493 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2755) 2756 Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. January 2000. (Format: TXT=32176 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2756) 2757 Long Thin Networks. G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. January 2000. (Format: TXT=112988 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2757) 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring. K. White. February 2000. (Format: TXT=145581 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2758) 2759 Microsoft PPP CHAP Extensions, Version 2. G. Zorn. January 2000. (Format: TXT=34178 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2759) 2760 Ongoing TCP Research Related to Satellites. M. Allman, Ed., S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. February 2000. (Format: TXT=111141 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2760) 2761 Terminology for ATM Benchmarking. J. Dunn, C. Martin. February 2000. (Format: TXT=61219 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2761) 2762 Sampling of the Group Membership in RTP. J. Rosenberg, H. Schulzrinne. February 2000. (Format: TXT=25796 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2762) 2763 Dynamic Hostname Exchange Mechanism for IS-IS. N. Shen, H. Smit. February 2000. (Format: TXT=8593 bytes) (Obsoleted by RFC5301) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2763) 2764 A Framework for IP Based Virtual Private Networks. B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February 2000. (Format: TXT=163215 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2764) 2765 Stateless IP/ICMP Translation Algorithm (SIIT). E. Nordmark. February 2000. (Format: TXT=59465 bytes) (Obsoleted by RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2765) 2766 Network Address Translation - Protocol Translation (NAT-PT). G. Tsirtsis, P. Srisuresh. February 2000. (Format: TXT=49836 bytes) (Obsoleted by RFC4966) (Updated by RFC3152) (Status: HISTORIC) (DOI: 10.17487/RFC2766) 2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS). K. Tsuchiya, H. Higuchi, Y. Atarashi. February 2000. (Format: TXT=26402 bytes) (Obsoleted by RFC6535) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2767) 2768 Network Policy and Services: A Report of a Workshop on Middleware. B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, B. Teitelbaum. February 2000. (Format: TXT=81034 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2768) 2769 Routing Policy System Replication. C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer. February 2000. (Format: TXT=95255 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2769) 2770 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. February 2000. (Format: TXT=8988 bytes) (Obsoleted by RFC3180) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2770) 2771 An Abstract API for Multicast Address Allocation. R. Finlayson. February 2000. (Format: TXT=20954 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2771) 2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT=28565 bytes) (Obsoletes RFC2546) (Updated by RFC3152) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2772) 2773 Encryption using KEA and SKIPJACK. R. Housley, P. Yee, W. Nace. February 2000. (Format: TXT=20008 bytes) (Updates RFC0959) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2773) 2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. February 2000. (Format: TXT=39719 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2774) 2775 Internet Transparency. B. Carpenter. February 2000. (Format: TXT=42956 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2775) 2776 Multicast-Scope Zone Announcement Protocol (MZAP). M. Handley, D. Thaler, R. Kermode. February 2000. (Format: TXT=61628 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2776) 2777 Publicly Verifiable Nomcom Random Selection. D. Eastlake 3rd. February 2000. (Format: TXT=30064 bytes) (Obsoleted by RFC3797) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2777) 2778 A Model for Presence and Instant Messaging. M. Day, J. Rosenberg, H. Sugano. February 2000. (Format: TXT=35153 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2778) 2779 Instant Messaging / Presence Protocol Requirements. M. Day, S. Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT=47420 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2779) 2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000. (Format: TXT=18954 bytes) (Updated by RFC4443, RFC5237, RFC5771, RFC6335, RFC7045) (Also BCP0037) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2780) 2781 UTF-16, an encoding of ISO 10646. P. Hoffman, F. Yergeau. February 2000. (Format: TXT=29870 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2781) 2782 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie, L. Esibov. February 2000. (Format: TXT=24013 bytes) (Obsoletes RFC2052) (Updated by RFC6335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2782) 2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0. J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. March 2000. (Format: TXT=61421 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2783) 2784 Generic Routing Encapsulation (GRE). D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina. March 2000. (Format: TXT=16627 bytes) (Updated by RFC2890) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2784) 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME. R. Zuccherato. March 2000. (Format: TXT=24415 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2785) 2786 Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000. (Format: TXT=43280 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2786) 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol. B. Jewell, D. Chuang. March 2000. (Format: TXT=56672 bytes) (Obsoleted by RFC6527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2787) 2788 Network Services Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT=43906 bytes) (Obsoletes RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2788) 2789 Mail Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT=65671 bytes) (Obsoletes RFC2249, RFC1566) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2789) 2790 Host Resources MIB. S. Waldbusser, P. Grillo. March 2000. (Format: TXT=95807 bytes) (Obsoletes RFC1514) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2790) 2791 Scalable Routing Design Principles. J. Yu. July 2000. (Format: TXT=63416 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2791) 2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System. M. Blaze, J. Ioannidis, A. Keromytis. March 2000. (Format: TXT=13461 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2792) 2793 RTP Payload for Text Conversation. G. Hellstrom. May 2000. (Format: TXT=20674 bytes) (Obsoleted by RFC4103) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2793) 2794 Mobile IP Network Access Identifier Extension for IPv4. P. Calhoun, C. Perkins. March 2000. (Format: TXT=16960 bytes) (Updates RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2794) 2795 The Infinite Monkey Protocol Suite (IMPS). S. Christey. April 2000. (Format: TXT=42902 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2795) 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP. T. Bates, R. Chandra, E. Chen. April 2000. (Format: TXT=20174 bytes) (Obsoleted by RFC4456) (Updates RFC1966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2796) 2797 Certificate Management Messages over CMS. M. Myers, X. Liu, J. Schaad, J. Weinstein. April 2000. (Format: TXT=103357 bytes) (Obsoleted by RFC5272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2797) 2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith. April 2000. (Format: TXT=32929 bytes) (Updated by RFC3698, RFC4519, RFC4524) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2798) 2799 Request for Comments Summary RFC Numbers 2700-2799. S. Ginoza. September 2000. (Format: TXT=42622 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2799) 2800 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. May 2001. (Format: TXT=101648 bytes) (Obsoletes RFC2700) (Obsoleted by RFC2900) (Status: HISTORIC) (DOI: 10.17487/RFC2800) 2801 Internet Open Trading Protocol - IOTP Version 1.0. D. Burdett. April 2000. (Format: TXT=598794 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2801) 2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP). K. Davidson, Y. Kawatsura. April 2000. (Format: TXT=52756 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2802) 2803 Digest Values for DOM (DOMHASH). H. Maruyama, K. Tamura, N. Uramoto. April 2000. (Format: TXT=22552 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2803) 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format: TXT=18934 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2804) 2805 Media Gateway Control Protocol Architecture and Requirements. N. Greene, M. Ramalho, B. Rosen. April 2000. (Format: TXT=88190 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2805) 2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format: TXT=50647 bytes) (Obsoleted by RFC3966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2806) 2807 XML Signature Requirements. J. Reagle. July 2000. (Format: TXT=21973 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2807) 2808 The SecurID(r) SASL Mechanism. M. Nystrom. April 2000. (Format: TXT=20342 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2808) 2809 Implementation of L2TP Compulsory Tunneling via RADIUS. B. Aboba, G. Zorn. April 2000. (Format: TXT=47259 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2809) 2810 Internet Relay Chat: Architecture. C. Kalt. April 2000. (Format: TXT=19087 bytes) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2810) 2811 Internet Relay Chat: Channel Management. C. Kalt. April 2000. (Format: TXT=40788 bytes) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2811) 2812 Internet Relay Chat: Client Protocol. C. Kalt. April 2000. (Format: TXT=122637 bytes) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2812) 2813 Internet Relay Chat: Server Protocol. C. Kalt. April 2000. (Format: TXT=56681 bytes) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2813) 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks. R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. May 2000. (Format: TXT=141886 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2814) 2815 Integrated Service Mappings on IEEE 802 Networks. M. Seaman, A. Smith, E. Crawley, J. Wroclawski. May 2000. (Format: TXT=42403 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2815) 2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies. A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman. May 2000. (Format: TXT=119043 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2816) 2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May 2000. (Format: TXT=27598 bytes) (Updates RFC2616) (Updated by RFC7230, RFC7231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2817) 2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT=15170 bytes) (Updated by RFC5785, RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2818) 2819 Remote Network Monitoring Management Information Base. S. Waldbusser. May 2000. (Format: TXT=198676 bytes) (Obsoletes RFC1757) (Also STD0059) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2819) 2820 Access Control Requirements for LDAP. E. Stokes, D. Byrne, B. Blakley, P. Behera. May 2000. (Format: TXT=18172 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2820) 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869) (Obsoleted by RFC5321) (Updated by RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2821) 2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format: TXT=110695 bytes) (Obsoletes RFC0822) (Obsoleted by RFC5322) (Updated by RFC5335, RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2822) 2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing. J. Carlson, P. Langner, E. Hernandez-Valencia, J. Manchester. May 2000. (Format: TXT=60049 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2823) 2824 Call Processing Language Framework and Requirements. J. Lennox, H. Schulzrinne. May 2000. (Format: TXT=58711 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2824) 2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols. IAB, L. Daigle, Ed.. May 2000. (Format: TXT=15612 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2825) 2826 IAB Technical Comment on the Unique DNS Root. Internet Architecture Board. May 2000. (Format: TXT=13400 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2826) 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2827) 2828 Internet Security Glossary. R. Shirey. May 2000. (Format: TXT=489292 bytes) (Obsoleted by RFC4949) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2828) 2829 Authentication Methods for LDAP. M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. May 2000. (Format: TXT=33471 bytes) (Obsoleted by RFC4513, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2829) 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. J. Hodges, R. Morgan, M. Wahl. May 2000. (Format: TXT=24469 bytes) (Obsoleted by RFC4511, RFC4513, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2830) 2831 Using Digest Authentication as a SASL Mechanism. P. Leach, C. Newman. May 2000. (Format: TXT=58124 bytes) (Obsoleted by RFC6331) (Status: HISTORIC) (DOI: 10.17487/RFC2831) 2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0. S. Hollenbeck, M. Srivastava. May 2000. (Format: TXT=77057 bytes) (Updated by RFC3632) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2832) 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. H. Schulzrinne, S. Petrack. May 2000. (Format: TXT=68786 bytes) (Obsoleted by RFC4733, RFC4734) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2833) 2834 ARP and IP Broadcast over HIPPI-800. J.-M. Pittet. May 2000. (Format: TXT=76243 bytes) (Obsoletes RFC1374) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2834) 2835 IP and ARP over HIPPI-6400 (GSN). J.-M. Pittet. May 2000. (Format: TXT=74178 bytes) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2835) 2836 Per Hop Behavior Identification Codes. S. Brim, B. Carpenter, F. Le Faucheur. May 2000. (Format: TXT=13399 bytes) (Obsoleted by RFC3140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2836) 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard. K. Teow. May 2000. (Format: TXT=87860 bytes) (Obsoleted by RFC4044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2837) 2838 Uniform Resource Identifiers for Television Broadcasts. D. Zigmond, M. Vickers. May 2000. (Format: TXT=11405 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2838) 2839 Internet Kermit Service. F. da Cruz, J. Altman. May 2000. (Format: TXT=42726 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2839) 2840 TELNET KERMIT OPTION. J. Altman, F. da Cruz. May 2000. (Format: TXT=22519 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2840) 2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC). P. Metzger, W. Simpson. November 2000. (Format: TXT=14139 bytes) (Obsoletes RFC1852) (Status: HISTORIC) (DOI: 10.17487/RFC2841) 2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. May 2000. (Format: TXT=8366 bytes) (Obsoleted by RFC3392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2842) 2843 Proxy-PAR. P. Droz, T. Przygienda. May 2000. (Format: TXT=27891 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2843) 2844 OSPF over ATM and Proxy-PAR. T. Przygienda, P. Droz, R. Haas. May 2000. (Format: TXT=32146 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2844) 2845 Secret Key Transaction Authentication for DNS (TSIG). P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington. May 2000. (Format: TXT=32272 bytes) (Updates RFC1035) (Updated by RFC3645, RFC4635, RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2845) 2846 GSTN Address Element Extensions in E-mail Services. C. Allocchio. June 2000. (Format: TXT=54316 bytes) (Updated by RFC3191, RFC3192) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2846) 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM. M. Eisler. June 2000. (Format: TXT=50045 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2847) 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services. S. Petrack, L. Conroy. June 2000. (Format: TXT=168851 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2848) 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification. G. Good. June 2000. (Format: TXT=26017 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2849) 2850 Charter of the Internet Architecture Board (IAB). Internet Architecture Board, B. Carpenter, Ed.. May 2000. (Format: TXT=15984 bytes) (Obsoletes RFC1601) (Also BCP0039) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2850) 2851 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. June 2000. (Format: TXT=32587 bytes) (Obsoleted by RFC3291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2851) 2852 Deliver By SMTP Service Extension. D. Newman. June 2000. (Format: TXT=29285 bytes) (Updates RFC1894) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2852) 2853 Generic Security Service API Version 2 : Java Bindings. J. Kabat, M. Upadhyay. June 2000. (Format: TXT=199512 bytes) (Obsoleted by RFC5653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2853) 2854 The 'text/html' Media Type. D. Connolly, L. Masinter. June 2000. (Format: TXT=16135 bytes) (Obsoletes RFC2070, RFC1980, RFC1942, RFC1867, RFC1866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2854) 2855 DHCP for IEEE 1394. K. Fujisawa. June 2000. (Format: TXT=8070 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2855) 2856 Textual Conventions for Additional High Capacity Data Types. A. Bierman, K. McCloghrie, R. Presuhn. June 2000. (Format: TXT=20954 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2856) 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH. A. Keromytis, N. Provos. June 2000. (Format: TXT=13544 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2857) 2858 Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. June 2000. (Format: TXT=23305 bytes) (Obsoletes RFC2283) (Obsoleted by RFC4760) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2858) 2859 A Time Sliding Window Three Colour Marker (TSWTCM). W. Fang, N. Seddigh, B. Nandy. June 2000. (Format: TXT=19203 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2859) 2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority. B. Carpenter, F. Baker, M. Roberts. June 2000. (Format: TXT=12361 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2860) 2861 TCP Congestion Window Validation. M. Handley, J. Padhye, S. Floyd. June 2000. (Format: TXT=26993 bytes) (Obsoleted by RFC7661) (Status: HISTORIC) (DOI: 10.17487/RFC2861) 2862 RTP Payload Format for Real-Time Pointers. M. Civanlar, G. Cash. June 2000. (Format: TXT=12031 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2862) 2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June 2000. (Format: TXT=155014 bytes) (Obsoletes RFC2233) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2863) 2864 The Inverted Stack Table Extension to the Interfaces Group MIB. K. McCloghrie, G. Hanson. June 2000. (Format: TXT=21445 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2864) 2865 Remote Authentication Dial In User Service (RADIUS). C. Rigney, S. Willens, A. Rubens, W. Simpson. June 2000. (Format: TXT=146456 bytes) (Obsoletes RFC2138) (Updated by RFC2868, RFC3575, RFC5080, RFC6929) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2865) 2866 RADIUS Accounting. C. Rigney. June 2000. (Format: TXT=51135 bytes) (Obsoletes RFC2139) (Updated by RFC2867, RFC5080, RFC5997) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2866) 2867 RADIUS Accounting Modifications for Tunnel Protocol Support. G. Zorn, B. Aboba, D. Mitton. June 2000. (Format: TXT=51135 bytes) (Updates RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2867) 2868 RADIUS Attributes for Tunnel Protocol Support. G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. June 2000. (Format: TXT=42609 bytes) (Updates RFC2865) (Updated by RFC3575) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2868) 2869 RADIUS Extensions. C. Rigney, W. Willats, P. Calhoun. June 2000. (Format: TXT=96854 bytes) (Updated by RFC3579, RFC5080) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2869) 2870 Root Name Server Operational Requirements. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. June 2000. (Format: TXT=21133 bytes) (Obsoletes RFC2010) (Obsoleted by RFC7720) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2870) 2871 A Framework for Telephony Routing over IP. J. Rosenberg, H. Schulzrinne. June 2000. (Format: TXT=60664 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2871) 2872 Application and Sub Application Identity Policy Element for Use with RSVP. Y. Bernet, R. Pabbati. June 2000. (Format: TXT=10933 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2872) 2873 TCP Processing of the IPv4 Precedence Field. X. Xiao, A. Hannan, V. Paxson, E. Crabbe. June 2000. (Format: TXT=15565 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2873) 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT=44204 bytes) (Updates RFC1886) (Updated by RFC3152, RFC3226, RFC3363, RFC3364) (Status: HISTORIC) (DOI: 10.17487/RFC2874) 2875 Diffie-Hellman Proof-of-Possession Algorithms. H. Prafullchandra, J. Schaad. July 2000. (Format: TXT=45231 bytes) (Obsoleted by RFC6955) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2875) 2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July 2000. (Format: TXT=29265 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2876) 2877 5250 Telnet Enhancements. T. Murphy Jr., P. Rieth, J. Stevens. July 2000. (Format: TXT=83369 bytes) (Obsoleted by RFC4777) (Updates RFC1205) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2877) 2878 PPP Bridging Control Protocol (BCP). M. Higashiyama, F. Baker. July 2000. (Format: TXT=79527 bytes) (Obsoletes RFC1638) (Obsoleted by RFC3518) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2878) 2879 Content Feature Schema for Internet Fax (V2). G. Klyne, L. McIntyre. August 2000. (Format: TXT=104032 bytes) (Obsoletes RFC2531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2879) 2880 Internet Fax T.30 Feature Mapping. L. McIntyre, G. Klyne. August 2000. (Format: TXT=75973 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2880) 2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model. D. Mitton, M. Beadles. July 2000. (Format: TXT=45029 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2881) 2882 Network Access Servers Requirements: Extended RADIUS Practices. D. Mitton. July 2000. (Format: TXT=31426 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2882) 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP. S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. July 2000. (Format: TXT=35794 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2883) 2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks. J. Hadi Salim, U. Ahmed. July 2000. (Format: TXT=44647 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2884) 2885 Megaco Protocol version 0.8. F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers. August 2000. (Format: TXT=344871 bytes) (Obsoleted by RFC3015) (Status: HISTORIC) (DOI: 10.17487/RFC2885) 2886 Megaco Errata. T. Taylor. August 2000. (Format: TXT=41311 bytes) (Obsoleted by RFC3015) (Status: HISTORIC) (DOI: 10.17487/RFC2886) 2887 The Reliable Multicast Design Space for Bulk Data Transfer. M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. August 2000. (Format: TXT=51135 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2887) 2888 Secure Remote Access with L2TP. P. Srisuresh. August 2000. (Format: TXT=41255 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2888) 2889 Benchmarking Methodology for LAN Switching Devices. R. Mandeville, J. Perser. August 2000. (Format: TXT=73251 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2889) 2890 Key and Sequence Number Extensions to GRE. G. Dommety. September 2000. (Format: TXT=14503 bytes) (Updates RFC2784) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2890) 2891 LDAP Control Extension for Server Side Sorting of Search Results. T. Howes, M. Wahl, A. Anantha. August 2000. (Format: TXT=15833 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2891) 2892 The Cisco SRP MAC Layer Protocol. D. Tsiang, G. Suwala. August 2000. (Format: TXT=107645 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2892) 2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. August 2000. (Format: TXT=62731 bytes) (Obsoletes RFC1933) (Obsoleted by RFC4213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2893) 2894 Router Renumbering for IPv6. M. Crawford. August 2000. (Format: TXT=69135 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2894) 2895 Remote Network Monitoring MIB Protocol Identifier Reference. A. Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT=88094 bytes) (Obsoletes RFC2074) (Updated by RFC3395) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2895) 2896 Remote Network Monitoring MIB Protocol Identifier Macros. A. Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT=135768 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2896) 2897 Proposal for an MGCP Advanced Audio Package. D. Cromwell. August 2000. (Format: TXT=67459 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2897) 2898 PKCS #5: Password-Based Cryptography Specification Version 2.0. B. Kaliski. September 2000. (Format: TXT=68692 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2898) 2899 Request for Comments Summary RFC Numbers 2800-2899. S. Ginoza. May 2001. (Format: TXT=43805 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2899) 2900 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. August 2001. (Format: TXT=112809 bytes) (Obsoletes RFC2800) (Obsoleted by RFC3000) (Status: HISTORIC) (DOI: 10.17487/RFC2900) 2901 Guide to Administrative Procedures of the Internet Infrastructure. Z. Wenzel, J. Klensin, R. Bush, S. Huter. August 2000. (Format: TXT=63680 bytes) (Also FYI0037) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2901) 2902 Overview of the 1998 IAB Routing Workshop. S. Deering, S. Hares, C. Perkins, R. Perlman. August 2000. (Format: TXT=32773 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2902) 2903 Generic AAA Architecture. C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence. August 2000. (Format: TXT=60627 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2903) 2904 AAA Authorization Framework. J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT=78098 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2904) 2905 AAA Authorization Application Examples. J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT=118645 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2905) 2906 AAA Authorization Requirements. S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT=48618 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2906) 2907 MADCAP Multicast Scope Nesting State Option. R. Kermode. September 2000. (Format: TXT=27572 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2907) 2908 The Internet Multicast Address Allocation Architecture. D. Thaler, M. Handley, D. Estrin. September 2000. (Format: TXT=30515 bytes) (Obsoleted by RFC6308) (Status: HISTORIC) (DOI: 10.17487/RFC2908) 2909 The Multicast Address-Set Claim (MASC) Protocol. P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler. September 2000. (Format: TXT=127278 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC2909) 2910 Internet Printing Protocol/1.1: Encoding and Transport. R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. September 2000. (Format: TXT=100599 bytes) (Obsoletes RFC2565) (Obsoleted by RFC8010) (Updated by RFC3380, RFC3381, RFC3382, RFC3510, RFC3995, RFC7472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2910) 2911 Internet Printing Protocol/1.1: Model and Semantics. T. Hastings, Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell. September 2000. (Format: TXT=575805 bytes) (Obsoletes RFC2566) (Obsoleted by RFC8011) (Updated by RFC3380, RFC3382, RFC3996, RFC3995, RFC7472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2911) 2912 Indicating Media Features for MIME Content. G. Klyne. September 2000. (Format: TXT=20618 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2912) 2913 MIME Content Types in Media Feature Expressions. G. Klyne. September 2000. (Format: TXT=16095 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2913) 2914 Congestion Control Principles. S. Floyd. September 2000. (Format: TXT=43823 bytes) (Updated by RFC7141) (Also BCP0041) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2914) 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record. M. Mealling, R. Daniel. September 2000. (Format: TXT=41521 bytes) (Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updates RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2915) 2916 E.164 number and DNS. P. Faltstrom. September 2000. (Format: TXT=18159 bytes) (Obsoleted by RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2916) 2917 A Core MPLS IP VPN Architecture. K. Muthukrishnan, A. Malis. September 2000. (Format: TXT=35352 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2917) 2918 Route Refresh Capability for BGP-4. E. Chen. September 2000. (Format: TXT=7354 bytes) (Updated by RFC7313) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2918) 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists. R. Chandhok, G. Wenger. March 2001. (Format: TXT=18480 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2919) 2920 SMTP Service Extension for Command Pipelining. N. Freed. September 2000. (Format: TXT=17065 bytes) (Obsoletes RFC2197) (Also STD0060) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2920) 2921 6BONE pTLA and pNLA Formats (pTLA). B. Fink. September 2000. (Format: TXT=14218 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2921) 2922 Physical Topology MIB. A. Bierman, K. Jones. September 2000. (Format: TXT=66830 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2922) 2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000. (Format: TXT=30976 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2923) 2924 Accounting Attributes and Record Formats. N. Brownlee, A. Blount. September 2000. (Format: TXT=75561 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2924) 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. K. White. September 2000. (Format: TXT=150691 bytes) (Obsoleted by RFC4560) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2925) 2926 Conversion of LDAP Schemas to and from SLP Templates. J. Kempf, R. Moats, P. St. Pierre. September 2000. (Format: TXT=55365 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2926) 2927 MIME Directory Profile for LDAP Schema. M. Wahl. September 2000. (Format: TXT=16122 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2927) 2928 Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. Fink, T. Hain. September 2000. (Format: TXT=11882 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2928) 2929 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd, E. Brunner-Williams, B. Manning. September 2000. (Format: TXT=22454 bytes) (Obsoleted by RFC5395) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2929) 2930 Secret Key Establishment for DNS (TKEY RR). D. Eastlake 3rd. September 2000. (Format: TXT=34894 bytes) (Updated by RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2930) 2931 DNS Request and Transaction Signatures ( SIG(0)s ). D. Eastlake 3rd. September 2000. (Format: TXT=19073 bytes) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2931) 2932 IPv4 Multicast Routing MIB. K. McCloghrie, D. Farinacci, D. Thaler. October 2000. (Format: TXT=50430 bytes) (Obsoleted by RFC5132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2932) 2933 Internet Group Management Protocol MIB. K. McCloghrie, D. Farinacci, D. Thaler. October 2000. (Format: TXT=33406 bytes) (Obsoleted by RFC5519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2933) 2934 Protocol Independent Multicast MIB for IPv4. K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner. October 2000. (Format: TXT=48379 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2934) 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement. D. Eastlake 3rd, C. Smith. September 2000. (Format: TXT=16168 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2935) 2936 HTTP MIME Type Handler Detection. D. Eastlake 3rd, C. Smith, D. Soroka. September 2000. (Format: TXT=25238 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2936) 2937 The Name Service Search Option for DHCP. C. Smith. September 2000. (Format: TXT=8368 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2937) 2938 Identifying Composite Media Features. G. Klyne, L. Masinter. September 2000. (Format: TXT=34451 bytes) (Updates RFC2533) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2938) 2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types. R. Droms. September 2000. (Format: TXT=13631 bytes) (Obsoletes RFC2489) (Also BCP0043) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2939) 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. A. Smith, D. Partain, J. Seligson. October 2000. (Format: TXT=52427 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2940) 2941 Telnet Authentication Option. T. Ts'o, Ed., J. Altman. September 2000. (Format: TXT=52427 bytes) (Obsoletes RFC1416) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2941) 2942 Telnet Authentication: Kerberos Version 5. T. Ts'o. September 2000. (Format: TXT=14562 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2942) 2943 TELNET Authentication Using DSA. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT=21694 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2943) 2944 Telnet Authentication: SRP. T. Wu. September 2000. (Format: TXT=13933 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2944) 2945 The SRP Authentication and Key Exchange System. T. Wu. September 2000. (Format: TXT=17843 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2945) 2946 Telnet Data Encryption Option. T. Ts'o. September 2000. (Format: TXT=16527 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2946) 2947 Telnet Encryption: DES3 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT=11064 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2947) 2948 Telnet Encryption: DES3 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT=11064 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2948) 2949 Telnet Encryption: CAST-128 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT=9240 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2949) 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT=9267 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2950) 2951 TELNET Authentication Using KEA and SKIPJACK. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT=20757 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2951) 2952 Telnet Encryption: DES 64 bit Cipher Feedback. T. Ts'o. September 2000. (Format: TXT=9064 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2952) 2953 Telnet Encryption: DES 64 bit Output Feedback. T. Ts'o. September 2000. (Format: TXT=8995 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2953) 2954 Definitions of Managed Objects for Frame Relay Service. K. Rehbehn, D. Fowler. October 2000. (Format: TXT=164217 bytes) (Obsoletes RFC1604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2954) 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function. K. Rehbehn, O. Nicklass, G. Mouradian. October 2000. (Format: TXT=83281 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2955) 2956 Overview of 1999 IAB Network Layer Workshop. M. Kaat. October 2000. (Format: TXT=36830 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2956) 2957 The application/whoispp-query Content-Type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT=10262 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2957) 2958 The application/whoispp-response Content-type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT=9995 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2958) 2959 Real-Time Transport Protocol Management Information Base. M. Baugher, B. Strahm, I. Suconick. October 2000. (Format: TXT=62063 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2959) 2960 Stream Control Transmission Protocol. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. October 2000. (Format: TXT=297757 bytes) (Obsoleted by RFC4960) (Updated by RFC3309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2960) 2961 RSVP Refresh Overhead Reduction Extensions. L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini. April 2001. (Format: TXT=81675 bytes) (Updated by RFC5063) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2961) 2962 An SNMP Application Level Gateway for Payload Address Translation. D. Raz, J. Schoenwaelder, B. Sugla. October 2000. (Format: TXT=46803 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2962) 2963 A Rate Adaptive Shaper for Differentiated Services. O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT=39895 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2963) 2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT=18899 bytes) (Also BCP0044) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2964) 2965 HTTP State Management Mechanism. D. Kristol, L. Montulli. October 2000. (Format: TXT=56176 bytes) (Obsoletes RFC2109) (Obsoleted by RFC6265) (Status: HISTORIC) (DOI: 10.17487/RFC2965) 2966 Domain-wide Prefix Distribution with Two-Level IS-IS. T. Li, T. Przygienda, H. Smit. October 2000. (Format: TXT=32465 bytes) (Obsoleted by RFC5302) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2966) 2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways. L. Daigle, R. Hedberg. October 2000. (Format: TXT=209845 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2967) 2968 Mesh of Multiple DAG servers - Results from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT=19306 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2968) 2969 Wide Area Directory Deployment - Experiences from TISDAG. T. Eklof, L. Daigle. October 2000. (Format: TXT=43002 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2969) 2970 Architecture for Integrated Directory Services - Result from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT=40448 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2970) 2971 IMAP4 ID extension. T. Showalter. October 2000. (Format: TXT=14670 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2971) 2972 Context and Goals for Common Name Resolution. N. Popp, M. Mealling, L. Masinter, K. Sollins. October 2000. (Format: TXT=26252 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2972) 2973 IS-IS Mesh Groups. R. Balay, D. Katz, J. Parker. October 2000. (Format: TXT=14846 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2973) 2974 Session Announcement Protocol. M. Handley, C. Perkins, E. Whelan. October 2000. (Format: TXT=40129 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2974) 2975 Introduction to Accounting Management. B. Aboba, J. Arkko, D. Harrington. October 2000. (Format: TXT=129771 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2975) 2976 The SIP INFO Method. S. Donovan. October 2000. (Format: TXT=17736 bytes) (Obsoleted by RFC6086) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2976) 2977 Mobile IP Authentication, Authorization, and Accounting Requirements. S. Glass, T. Hiller, S. Jacobs, C. Perkins. October 2000. (Format: TXT=63520 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2977) 2978 IANA Charset Registration Procedures. N. Freed, J. Postel. October 2000. (Format: TXT=21615 bytes) (Obsoletes RFC2278) (Also BCP0019) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2978) 2979 Behavior of and Requirements for Internet Firewalls. N. Freed. October 2000. (Format: TXT=14350 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2979) 2980 Common NNTP Extensions. S. Barber. October 2000. (Format: TXT=57165 bytes) (Updated by RFC3977, RFC4643, RFC4644, RFC6048) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2980) 2981 Event MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT=98248 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2981) 2982 Distributed Management Expression MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT=81371 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2982) 2983 Differentiated Services and Tunnels. D. Black. October 2000. (Format: TXT=35644 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2983) 2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams. October 2000. (Format: TXT=11591 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2984) 2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0. M. Nystrom, B. Kaliski. November 2000. (Format: TXT=70703 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2985) 2986 PKCS #10: Certification Request Syntax Specification Version 1.7. M. Nystrom, B. Kaliski. November 2000. (Format: TXT=27794 bytes) (Obsoletes RFC2314) (Updated by RFC5967) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2986) 2987 Registration of Charset and Languages Media Features Tags. P. Hoffman. November 2000. (Format: TXT=8799 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2987) 2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000. (Format: TXT=15280 bytes) (Obsoleted by RFC6298) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2988) 2989 Criteria for Evaluating AAA Protocols for Network Access. B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques. November 2000. (Format: TXT=53197 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2989) 2990 Next Steps for the IP QoS Architecture. G. Huston. November 2000. (Format: TXT=65450 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2990) 2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D. Thaler, C. Hopps. November 2000. (Format: TXT=17796 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2991) 2992 Analysis of an Equal-Cost Multi-Path Algorithm. C. Hopps. November 2000. (Format: TXT=17524 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2992) 2993 Architectural Implications of NAT. T. Hain. November 2000. (Format: TXT=74136 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2993) 2994 A Description of the MISTY1 Encryption Algorithm. H. Ohta, M. Matsui. November 2000. (Format: TXT=17803 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2994) 2995 Pre-Spirits Implementations of PSTN-initiated Services. H. Lu, Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart. November 2000. (Format: TXT=96427 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2995) 2996 Format of the RSVP DCLASS Object. Y. Bernet. November 2000. (Format: TXT=18929 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2996) 2997 Specification of the Null Service Type. Y. Bernet, A. Smith, B. Davie. November 2000. (Format: TXT=25071 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2997) 2998 A Framework for Integrated Services Operation over Diffserv Networks. Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. November 2000. (Format: TXT=76378 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2998) 2999 Request for Comments Summary RFC Numbers 2900-2999. S. Ginoza. August 2001. (Format: TXT=45307 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2999) 3000 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, L. Shiota. November 2001. (Format: TXT=115207 bytes) (Obsoletes RFC2900) (Obsoleted by RFC3300) (Status: HISTORIC) (DOI: 10.17487/RFC3000) 3001 A URN Namespace of Object Identifiers. M. Mealling. November 2000. (Format: TXT=7459 bytes) (Obsoleted by RFC3061) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3001) 3002 Overview of 2000 IAB Wireless Internetworking Workshop. D. Mitzel. December 2000. (Format: TXT=101466 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3002) 3003 The audio/mpeg Media Type. M. Nilsson. November 2000. (Format: TXT=8381 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3003) 3004 The User Class Option for DHCP. G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. November 2000. (Format: TXT=10423 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3004) 3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: TXT=5682 bytes) (Also BCP0045) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3005) 3006 Integrated Services in the Presence of Compressible Flows. B. Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski. November 2000. (Format: TXT=31588 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3006) 3007 Secure Domain Name System (DNS) Dynamic Update. B. Wellington. November 2000. (Format: TXT=18056 bytes) (Obsoletes RFC2137) (Updates RFC2535, RFC2136) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3007) 3008 Domain Name System Security (DNSSEC) Signing Authority. B. Wellington. November 2000. (Format: TXT=13484 bytes) (Obsoleted by RFC4035, RFC4033, RFC4034) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3008) 3009 Registration of parityfec MIME types. J. Rosenberg, H. Schulzrinne. November 2000. (Format: TXT=16022 bytes) (Obsoleted by RFC5109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3009) 3010 NFS version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. December 2000. (Format: TXT=450434 bytes) (Obsoleted by RFC3530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3010) 3011 The IPv4 Subnet Selection Option for DHCP. G. Waters. November 2000. (Format: TXT=13967 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3011) 3012 Mobile IPv4 Challenge/Response Extensions. C. Perkins, P. Calhoun. November 2000. (Format: TXT=37005 bytes) (Obsoleted by RFC4721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3012) 3013 Recommended Internet Service Provider Security Services and Procedures. T. Killalea. November 2000. (Format: TXT=27905 bytes) (Also BCP0046) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3013) 3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: TXT=48287 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3014) 3015 Megaco Protocol Version 1.0. F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. November 2000. (Format: TXT=385432 bytes) (Obsoletes RFC2885, RFC2886) (Obsoleted by RFC3525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3015) 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams. Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. November 2000. (Format: TXT=47070 bytes) (Obsoleted by RFC6416) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3016) 3017 XML DTD for Roaming Access Phone Book. M. Riegel, G. Zorn. December 2000. (Format: TXT=59762 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3017) 3018 Unified Memory Space Protocol Specification. A. Bogdanov. December 2000. (Format: TXT=177783 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3018) 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol. B. Haberman, R. Worzella. January 2001. (Format: TXT=28293 bytes) (Obsoleted by RFC5519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3019) 3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function. P. Pate, B. Lynch, K. Rehbehn. December 2000. (Format: TXT=67736 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3020) 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links. A. Retana, R. White, V. Fuller, D. McPherson. December 2000. (Format: TXT=19771 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3021) 3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. (Format: TXT=37675 bytes) (Obsoletes RFC1631) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3022) 3023 XML Media Types. M. Murata, S. St. Laurent, D. Kohn. January 2001. (Format: TXT=86011 bytes) (Obsoletes RFC2376) (Obsoleted by RFC7303) (Updates RFC2048) (Updated by RFC6839) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3023) 3024 Reverse Tunneling for Mobile IP, revised. G. Montenegro, Ed.. January 2001. (Format: TXT=63929 bytes) (Obsoletes RFC2344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3024) 3025 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. February 2001. (Format: TXT=15611 bytes) (Obsoleted by RFC3115) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3025) 3026 Liaison to IETF/ISOC on ENUM. R. Blane. January 2001. (Format: TXT=11460 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3026) 3027 Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. (Format: TXT=48662 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3027) 3028 Sieve: A Mail Filtering Language. T. Showalter. January 2001. (Format: TXT=73582 bytes) (Obsoleted by RFC5228, RFC5429) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3028) 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols. C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato. February 2001. (Format: TXT=107347 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3029) 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. December 2000. (Format: TXT=23405 bytes) (Obsoletes RFC1830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3030) 3031 Multiprotocol Label Switching Architecture. E. Rosen, A. Viswanathan, R. Callon. January 2001. (Format: TXT=147175 bytes) (Updated by RFC6178, RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3031) 3032 MPLS Label Stack Encoding. E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001. (Format: TXT=48314 bytes) (Updated by RFC3443, RFC4182, RFC5332, RFC3270, RFC5129, RFC5462, RFC5586, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3032) 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol. M. Suzuki. January 2001. (Format: TXT=52188 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3033) 3034 Use of Label Switching on Frame Relay Networks Specification. A. Conta, P. Doolan, A. Malis. January 2001. (Format: TXT=53176 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3034) 3035 MPLS using LDP and ATM VC Switching. B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan. January 2001. (Format: TXT=46463 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3035) 3036 LDP Specification. L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. January 2001. (Format: TXT=274855 bytes) (Obsoleted by RFC5036) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3036) 3037 LDP Applicability. B. Thomas, E. Gray. January 2001. (Format: TXT=13601 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3037) 3038 VCID Notification over ATM link for LDP. K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan. January 2001. (Format: TXT=39134 bytes) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3038) 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile. S. Santesson, W. Polk, P. Barzin, M. Nystrom. January 2001. (Format: TXT=67619 bytes) (Obsoleted by RFC3739) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3039) 3040 Internet Web Replication and Caching Taxonomy. I. Cooper, I. Melve, G. Tomlinson. January 2001. (Format: TXT=63257 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3040) 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January 2001. (Format: TXT=44446 bytes) (Obsoleted by RFC4941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3041) 3042 Enhancing TCP's Loss Recovery Using Limited Transmit. M. Allman, H. Balakrishnan, S. Floyd. January 2001. (Format: TXT=19885 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3042) 3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations. M. Mealling. January 2001. (Format: TXT=8136 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3043) 3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace. S. Rozenfeld. January 2001. (Format: TXT=28094 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3044) 3045 Storing Vendor Information in the LDAP root DSE. M. Meredith. January 2001. (Format: TXT=10518 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3045) 3046 DHCP Relay Agent Information Option. M. Patrick. January 2001. (Format: TXT=30633 bytes) (Updated by RFC6607) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3046) 3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi. January 2001. (Format: TXT=16292 bytes) (Obsoleted by RFC5577) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3047) 3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer. B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby. January 2001. (Format: TXT=48965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3048) 3049 TN3270E Service Location and Session Balancing. J. Naugle, K. Kasthurirangan, G. Ledford. January 2001. (Format: TXT=40743 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3049) 3050 Common Gateway Interface for SIP. J. Lennox, H. Schulzrinne, J. Rosenberg. January 2001. (Format: TXT=76652 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3050) 3051 IP Payload Compression Using ITU-T V.44 Packet Method. J. Heath, J. Border. January 2001. (Format: TXT=15845 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3051) 3052 Service Management Architectures Issues and Review. M. Eder, S. Nag. January 2001. (Format: TXT=31859 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3052) 3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini, D. Lento. January 2001. (Format: TXT=27336 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3053) 3054 Megaco IP Phone Media Gateway Application Profile. P. Blatherwick, R. Bell, P. Holland. January 2001. (Format: TXT=31971 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3054) 3055 Management Information Base for the PINT Services Architecture. M. Krishnaswamy, D. Romascanu. February 2001. (Format: TXT=39315 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3055) 3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT=54902 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3056) 3057 ISDN Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. February 2001. (Format: TXT=13601 bytes) (Obsoleted by RFC4233) (Updated by RFC3807) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3057) 3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes, P. Hartmann, D. Kuenzi. February 2001. (Format: TXT=17257 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3058) 3059 Attribute List Extension for the Service Location Protocol. E. Guttman. February 2001. (Format: TXT=11208 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3059) 3060 Policy Core Information Model -- Version 1 Specification. B. Moore, E. Ellesson, J. Strassner, A. Westerinen. February 2001. (Format: TXT=240309 bytes) (Updated by RFC3460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3060) 3061 A URN Namespace of Object Identifiers. M. Mealling. February 2001. (Format: TXT=8387 bytes) (Obsoletes RFC3001) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3061) 3062 LDAP Password Modify Extended Operation. K. Zeilenga. February 2001. (Format: TXT=11807 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3062) 3063 MPLS Loop Prevention Mechanism. Y. Ohba, Y. Katsube, E. Rosen, P. Doolan. February 2001. (Format: TXT=93523 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3063) 3064 MGCP CAS Packages. B. Foster. February 2001. (Format: TXT=116818 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3064) 3065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. February 2001. (Format: TXT=20529 bytes) (Obsoletes RFC1965) (Obsoleted by RFC5065) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3065) 3066 Tags for the Identification of Languages. H. Alvestrand. January 2001. (Format: TXT=26522 bytes) (Obsoletes RFC1766) (Obsoleted by RFC4646, RFC4647) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3066) 3067 TERENA'S Incident Object Description and Exchange Format Requirements. J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. February 2001. (Format: TXT=36836 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3067) 3068 An Anycast Prefix for 6to4 Relay Routers. C. Huitema. June 2001. (Format: TXT=20120 bytes) (Obsoleted by RFC7526) (Status: HISTORIC) (DOI: 10.17487/RFC3068) 3069 VLAN Aggregation for Efficient IP Address Allocation. D. McPherson, B. Dykes. February 2001. (Format: TXT=14891 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3069) 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay. V. Rawat, R. Tio, S. Nanji, R. Verma. February 2001. (Format: TXT=12940 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3070) 3071 Reflections on the DNS, RFC 1591, and Categories of Domains. J. Klensin. February 2001. (Format: TXT=24892 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3071) 3072 Structured Data Exchange Format (SDXF). M. Wildgrube. March 2001. (Format: TXT=48481 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3072) 3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration. J. Collins. March 2001. (Format: TXT=9076 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3073) 3074 DHC Load Balancing Algorithm. B. Volz, S. Gonczi, T. Lemon, R. Stevens. February 2001. (Format: TXT=19374 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3074) 3075 XML-Signature Syntax and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2001. (Format: TXT=145520 bytes) (Obsoleted by RFC3275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3075) 3076 Canonical XML Version 1.0. J. Boyer. March 2001. (Format: TXT=63955 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3076) 3077 A Link-Layer Tunneling Mechanism for Unidirectional Links. E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang. March 2001. (Format: TXT=52410 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3077) 3078 Microsoft Point-To-Point Encryption (MPPE) Protocol. G. Pall, G. Zorn. March 2001. (Format: TXT=22952 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3078) 3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). G. Zorn. March 2001. (Format: TXT=38905 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3079) 3080 The Blocks Extensible Exchange Protocol Core. M. Rose. March 2001. (Format: TXT=82089 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3080) 3081 Mapping the BEEP Core onto TCP. M. Rose. March 2001. (Format: TXT=14008 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3081) 3082 Notification and Subscription for SLP. J. Kempf, J. Goldschmidt. March 2001. (Format: TXT=33410 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3082) 3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems. R. Woundy. March 2001. (Format: TXT=88318 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3083) 3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. March 2001. (Format: TXT=79341 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3084) 3085 URN Namespace for NewsML Resources. A. Coates, D. Allen, D. Rivers-Moore. March 2001. (Format: TXT=10016 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3085) 3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification. K. Nichols, B. Carpenter. April 2001. (Format: TXT=63122 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3086) 3087 Control of Service Context using SIP Request-URI. B. Campbell, R. Sparks. April 2001. (Format: TXT=83612 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3087) 3088 OpenLDAP Root Service An experimental LDAP referral service. K. Zeilenga. April 2001. (Format: TXT=19471 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3088) 3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. H. Kitamura. April 2001. (Format: TXT=25193 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3089) 3090 DNS Security Extension Clarification on Zone Status. E. Lewis. March 2001. (Format: TXT=24166 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3090) 3091 Pi Digit Generation Protocol. H. Kennedy. April 2001. (Format: TXT=10375 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3091) 3092 Etymology of "Foo". D. Eastlake 3rd, C. Manros, E. Raymond. April 2001. (Format: TXT=29235 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3092) 3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. April 2001. (Format: TXT=22405 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3093) 3094 Tekelec's Transport Adapter Layer Interface. D. Sprague, R. Benedyk, D. Brendes, J. Keller. April 2001. (Format: TXT=265099 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3094) 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: TXT=368746 bytes) (Updated by RFC3759, RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3095) 3096 Requirements for robust IP/UDP/RTP header compression. M. Degermark, Ed.. July 2001. (Format: TXT=15018 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3096) 3097 RSVP Cryptographic Authentication -- Updated Message Type Value. R. Braden, L. Zhang. April 2001. (Format: TXT=6320 bytes) (Updates RFC2747) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3097) 3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$. T. Gavin, D. Eastlake 3rd, S. Hambridge. April 2001. (Format: TXT=64687 bytes) (Also FYI0038) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3098) 3099 Request for Comments Summary RFC Numbers 3000-3099. S. Ginoza. November 2001. (Format: TXT=48990 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3099) 3100 Not Issued. 3101 The OSPF Not-So-Stubby Area (NSSA) Option. P. Murphy. January 2003. (Format: TXT=76243 bytes) (Obsoletes RFC1587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3101) 3102 Realm Specific IP: Framework. M. Borella, J. Lo, D. Grabelsky, G. Montenegro. October 2001. (Format: TXT=73856 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3102) 3103 Realm Specific IP: Protocol Specification. M. Borella, D. Grabelsky, J. Lo, K. Taniguchi. October 2001. (Format: TXT=115855 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3103) 3104 RSIP Support for End-to-end IPsec. G. Montenegro, M. Borella. October 2001. (Format: TXT=38719 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3104) 3105 Finding an RSIP Server with SLP. J. Kempf, G. Montenegro. October 2001. (Format: TXT=21427 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3105) 3106 ECML v1.1: Field Specifications for E-Commerce. D. Eastlake 3rd, T. Goldstein. April 2001. (Format: TXT=40715 bytes) (Obsoletes RFC2706) (Updated by RFC4112) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3106) 3107 Carrying Label Information in BGP-4. Y. Rekhter, E. Rosen. May 2001. (Format: TXT=16442 bytes) (Updated by RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3107) 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections. R. Kumar, M. Mostafa. May 2001. (Format: TXT=248037 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3108) 3109 Request to Move STD 39 to Historic Status. R. Braden, R. Bush, J. Klensin. May 2001. (Format: TXT=5841 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3109) 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). D. Eastlake 3rd. May 2001. (Format: TXT=14587 bytes) (Obsoletes RFC2537) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3110) 3111 Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT=25543 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3111) 3112 LDAP Authentication Password Schema. K. Zeilenga. May 2001. (Format: TXT=17116 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3112) 3113 3GPP-IETF Standardization Collaboration. K. Rosenbrock, R. Sanmugam, S. Bradner, J. Klensin. June 2001. (Format: TXT=11405 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3113) 3114 Implementing Company Classification Policy with the S/MIME Security Label. W. Nicolls. May 2002. (Format: TXT=27764 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3114) 3115 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. April 2001. (Format: TXT=16363 bytes) (Obsoletes RFC3025) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3115) 3116 Methodology for ATM Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT=295052 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3116) 3117 On the Design of Application Protocols. M. Rose. November 2001. (Format: TXT=57279 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3117) 3118 Authentication for DHCP Messages. R. Droms, Ed., W. Arbaugh, Ed.. June 2001. (Format: TXT=35536 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3118) 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. June 2001. (Format: TXT=37796 bytes) (Obsoleted by RFC5219) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3119) 3120 A URN Namespace for XML.org. K. Best, N. Walsh. June 2001. (Format: TXT=8068 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3120) 3121 A URN Namespace for OASIS. K. Best, N. Walsh. June 2001. (Format: TXT=11074 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3121) 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. A. Conta. June 2001. (Format: TXT=40416 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3122) 3123 A DNS RR Type for Lists of Address Prefixes (APL RR). P. Koch. June 2001. (Format: TXT=14648 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3123) 3124 The Congestion Manager. H. Balakrishnan, S. Seshan. June 2001. (Format: TXT=53591 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3124) 3125 Electronic Signature Policies. J. Ross, D. Pinkas, N. Pope. September 2001. (Format: TXT=95505 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3125) 3126 Electronic Signature Formats for long term electronic signatures. D. Pinkas, J. Ross, N. Pope. September 2001. (Format: TXT=175886 bytes) (Obsoleted by RFC5126) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3126) 3127 Authentication, Authorization, and Accounting: Protocol Evaluation. D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, M. Stevens, B. Wolff. June 2001. (Format: TXT=170579 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3127) 3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858). I. Miller. June 2001. (Format: TXT=8242 bytes) (Updates RFC1858) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3128) 3129 Requirements for Kerberized Internet Negotiation of Keys. M. Thomas. June 2001. (Format: TXT=11401 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3129) 3130 Notes from the State-Of-The-Technology: DNSSEC. E. Lewis. June 2001. (Format: TXT=22291 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3130) 3131 3GPP2-IETF Standardization Collaboration. S. Bradner, P. Calhoun, H. Cuschieri, S. Dennett, G. Flynn, M. Lipford, M. McPheters. June 2001. (Format: TXT=13643 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3131) 3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement. J. Kempf. June 2001. (Format: TXT=34985 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3132) 3133 Terminology for Frame Relay Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT=44182 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3133) 3134 Terminology for ATM ABR Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT=29542 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3134) 3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations. J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby. June 2001. (Format: TXT=114825 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3135) 3136 The SPIRITS Architecture. L. Slutsman, Ed., I. Faynberg, H. Lu, M. Weissman. June 2001. (Format: TXT=19241 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3136) 3137 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson. June 2001. (Format: TXT=8140 bytes) (Obsoleted by RFC6987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3137) 3138 Extended Assignments in 233/8. D. Meyer. June 2001. (Format: TXT=6776 bytes) (Obsoleted by RFC5771) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3138) 3139 Requirements for Configuration Management of IP-based Networks. L. Sanchez, K. McCloghrie, J. Saperia. June 2001. (Format: TXT=23624 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3139) 3140 Per Hop Behavior Identification Codes. D. Black, S. Brim, B. Carpenter, F. Le Faucheur. June 2001. (Format: TXT=16586 bytes) (Obsoletes RFC2836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3140) 3141 CDMA2000 Wireless Data Requirements for AAA. T. Hiller, P. Walsh, X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H. Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P. Calhoun, C. Lo, E. Jaques, E. Campbell, Y.Xu,S.Baba,T.Ayaki,T.Seki,A.Hameed. June 2001. (Format: TXT=27998 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3141) 3142 An IPv6-to-IPv4 Transport Relay Translator. J. Hagino, K. Yamamoto. June 2001. (Format: TXT=20864 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3142) 3143 Known HTTP Proxy/Caching Problems. I. Cooper, J. Dilley. June 2001. (Format: TXT=57117 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3143) 3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring. D. Romascanu. August 2001. (Format: TXT=62491 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3144) 3145 L2TP Disconnect Cause Information. R. Verma, M. Verma, J. Carlson. July 2001. (Format: TXT=17421 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3145) 3146 Transmission of IPv6 Packets over IEEE 1394 Networks. K. Fujisawa, A. Onoe. October 2001. (Format: TXT=16569 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3146) 3147 Generic Routing Encapsulation over CLNS Networks. P. Christian. July 2001. (Format: TXT=14125 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3147) 3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics. M. Mathis, M. Allman. July 2001. (Format: TXT=36041 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3148) 3149 MGCP Business Phone Packages. A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram. September 2001. (Format: TXT=77304 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3149) 3150 End-to-end Performance Implications of Slow Links. S. Dawkins, G. Montenegro, M. Kojo, V. Magret. July 2001. (Format: TXT=39942 bytes) (Also BCP0048) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3150) 3151 A URN Namespace for Public Identifiers. N. Walsh, J. Cowan, P. Grosso. August 2001. (Format: TXT=15595 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3151) 3152 Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT=5727 bytes) (Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also BCP0049) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3152) 3153 PPP Multiplexing. R. Pazhyannur, I. Ali, C. Fox. August 2001. (Format: TXT=19244 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3153) 3154 Requirements and Functional Architecture for an IP Host Alerting Protocol. J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu. August 2001. (Format: TXT=31534 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3154) 3155 End-to-end Performance Implications of Links with Errors. S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya. August 2001. (Format: TXT=36388 bytes) (Also BCP0050) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3155) 3156 MIME Security with OpenPGP. M. Elkins, D. Del Torto, R. Levien, T. Roessler. August 2001. (Format: TXT=26809 bytes) (Updates RFC2015) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3156) 3157 Securely Available Credentials - Requirements. A. Arsenault, S. Farrell. August 2001. (Format: TXT=46169 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3157) 3158 RTP Testing Strategies. C. Perkins, J. Rosenberg, H. Schulzrinne. August 2001. (Format: TXT=48208 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3158) 3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer. August 2001. (Format: TXT=78621 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3159) 3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force. S. Harris. August 2001. (Format: TXT=98411 bytes) (Obsoletes RFC1718) (Obsoleted by RFC4677) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3160) 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001. (Format: TXT=54585 bytes) (Updated by RFC5816) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3161) 3162 RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. (Format: TXT=20492 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3162) 3163 ISO/IEC 9798-3 Authentication SASL Mechanism. R. Zuccherato, M. Nystrom. August 2001. (Format: TXT=32498 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3163) 3164 The BSD Syslog Protocol. C. Lonvick. August 2001. (Format: TXT=72951 bytes) (Obsoleted by RFC5424) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3164) 3165 Definitions of Managed Objects for the Delegation of Management Scripts. D. Levi, J. Schoenwaelder. August 2001. (Format: TXT=134479 bytes) (Obsoletes RFC2592) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3165) 3166 Request to Move RFC 1403 to Historic Status. D. Meyer, J. Scudder. August 2001. (Format: TXT=3740 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3166) 3167 Request to Move RFC 1745 to Historic Status. D. Meyer, J. Scudder. August 2001. (Format: TXT=3825 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3167) 3168 The Addition of Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd, D. Black. September 2001. (Format: TXT=170966 bytes) (Obsoletes RFC2481) (Updates RFC2003, RFC2474, RFC2401, RFC0793) (Updated by RFC4301, RFC6040) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3168) 3169 Criteria for Evaluating Network Access Server Protocols. M. Beadles, D. Mitton. September 2001. (Format: TXT=35303 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3169) 3170 IP Multicast Applications: Challenges and Solutions. B. Quinn, K. Almeroth. September 2001. (Format: TXT=67207 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3170) 3171 IANA Guidelines for IPv4 Multicast Address Assignments. Z. Albanna, K. Almeroth, D. Meyer, M. Schipper. August 2001. (Format: TXT=15389 bytes) (Obsoleted by RFC5771) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3171) 3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa"). G. Huston, Ed.. September 2001. (Format: TXT=18097 bytes) (Also BCP0052) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3172) 3173 IP Payload Compression Protocol (IPComp). A. Shacham, B. Monsour, R. Pereira, M. Thomas. September 2001. (Format: TXT=15389 bytes) (Obsoletes RFC2393) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3173) 3174 US Secure Hash Algorithm 1 (SHA1). D. Eastlake 3rd, P. Jones. September 2001. (Format: TXT=35525 bytes) (Updated by RFC4634, RFC6234) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3174) 3175 Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. September 2001. (Format: TXT=88681 bytes) (Updated by RFC5350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3175) 3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks. P. Phaal, S. Panchen, N. McKee. September 2001. (Format: TXT=60171 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3176) 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT=23178 bytes) (Obsoleted by RFC6177) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3177) 3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. Snyder. October 2001. (Format: TXT=24453 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3178) 3179 Script MIB Extensibility Protocol Version 1.1. J. Schoenwaelder, J. Quittek. October 2001. (Format: TXT=56311 bytes) (Obsoletes RFC2593) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3179) 3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001. (Format: TXT=8225 bytes) (Obsoletes RFC2770) (Also BCP0053) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3180) 3181 Signaled Preemption Priority Policy Element. S. Herzog. October 2001. (Format: TXT=21990 bytes) (Obsoletes RFC2751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3181) 3182 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, R. Hess. October 2001. (Format: TXT=36544 bytes) (Obsoletes RFC2752) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3182) 3183 Domain Security Services using S/MIME. T. Dean, W. Ottaway. October 2001. (Format: TXT=57129 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3183) 3184 IETF Guidelines for Conduct. S. Harris. October 2001. (Format: TXT=7413 bytes) (Obsoleted by RFC7154) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3184) 3185 Reuse of CMS Content Encryption Keys. S. Farrell, S. Turner. October 2001. (Format: TXT=20404 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3185) 3186 MAPOS/PPP Tunneling mode. S. Shimizu, T. Kawano, K. Murakami, E. Beier. December 2001. (Format: TXT=27109 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3186) 3187 Using International Standard Book Numbers as Uniform Resource Names. J. Hakala, H. Walravens. October 2001. (Format: TXT=22620 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3187) 3188 Using National Bibliography Numbers as Uniform Resource Names. J. Hakala. October 2001. (Format: TXT=27923 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3188) 3189 RTP Payload Format for DV (IEC 61834) Video. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT=25991 bytes) (Obsoleted by RFC6469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3189) 3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT=34977 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3190) 3191 Minimal GSTN address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT=24235 bytes) (Obsoletes RFC2303) (Updates RFC2846) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3191) 3192 Minimal FAX address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT=18813 bytes) (Obsoletes RFC2304) (Updates RFC2846) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3192) 3193 Securing L2TP using IPsec. B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth. November 2001. (Format: TXT=63804 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3193) 3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio. A. Durand, C. Huitema. November 2001. (Format: TXT=14539 bytes) (Updates RFC1715) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3194) 3195 Reliable Delivery for syslog. D. New, M. Rose. November 2001. (Format: TXT=60960 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3195) 3196 Internet Printing Protocol/1.1: Implementor's Guide. T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst. November 2001. (Format: TXT=200720 bytes) (Obsoletes RFC2639) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3196) 3197 Applicability Statement for DNS MIB Extensions. R. Austein. November 2001. (Format: TXT=8610 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3197) 3198 Terminology for Policy-Based Management. A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format: TXT=47806 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198) 3199 Request for Comments Summary RFC Numbers 3100-3199. S. Ginoza. February 2003. (Format: TXT=47287 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3199) 3200 Not Issued. 3201 Definitions of Managed Objects for Circuit to Interface Translation. R. Steinberger, O. Nicklass. January 2002. (Format: TXT=45583 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3201) 3202 Definitions of Managed Objects for Frame Relay Service Level Definitions. R. Steinberger, O. Nicklass. January 2002. (Format: TXT=130816 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3202) 3203 DHCP reconfigure extension. Y. T'Joens, C. Hublet, P. De Schrijver. December 2001. (Format: TXT=11857 bytes) (Updated by RFC6704) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3203) 3204 MIME media types for ISUP and QSIG Objects. E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun. December 2001. (Format: TXT=19712 bytes) (Updated by RFC3459, RFC5621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3204) 3205 On the use of HTTP as a Substrate. K. Moore. February 2002. (Format: TXT=34785 bytes) (Also BCP0056) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3205) 3206 The SYS and AUTH POP Response Codes. R. Gellens. February 2002. (Format: TXT=9917 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3206) 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. P. Hoffman. February 2002. (Format: TXT=18679 bytes) (Obsoletes RFC2487) (Updated by RFC7817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3207) 3208 PGM Reliable Transport Protocol Specification. T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano. December 2001. (Format: TXT=244637 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3208) 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels. D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. December 2001. (Format: TXT=132264 bytes) (Updated by RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC5711, RFC6780, RFC6790, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3209) 3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels. D. Awduche, A. Hannan, X. Xiao. December 2001. (Format: TXT=17691 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3210) 3211 Password-based Encryption for CMS. P. Gutmann. December 2001. (Format: TXT=30527 bytes) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3211) 3212 Constraint-Based LSP Setup using LDP. B. Jamoussi, Ed., L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A. Malis. January 2002. (Format: TXT=87591 bytes) (Updated by RFC3468, RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3212) 3213 Applicability Statement for CR-LDP. J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright. January 2002. (Format: TXT=14489 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3213) 3214 LSP Modification Using CR-LDP. J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li. January 2002. (Format: TXT=25453 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3214) 3215 LDP State Machine. C. Boscher, P. Cheval, L. Wu, E. Gray. January 2002. (Format: TXT=117278 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3215) 3216 SMIng Objectives. C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss. December 2001. (Format: TXT=58551 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3216) 3217 Triple-DES and RC2 Key Wrapping. R. Housley. December 2001. (Format: TXT=19855 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3217) 3218 Preventing the Million Message Attack on Cryptographic Message Syntax. E. Rescorla. January 2002. (Format: TXT=16047 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3218) 3219 Telephony Routing over IP (TRIP). J. Rosenberg, H. Salama, M. Squire. January 2002. (Format: TXT=184618 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3219) 3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT=238343 bytes) (Obsoletes RFC2002) (Obsoleted by RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3220) 3221 Commentary on Inter-Domain Routing in the Internet. G. Huston. December 2001. (Format: TXT=66580 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3221) 3222 Terminology for Forwarding Information Base (FIB) based Router Performance. G. Trotter. December 2001. (Format: TXT=25483 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3222) 3223 Not Issued. 3224 Vendor Extensions for Service Location Protocol, Version 2. E. Guttman. January 2002. (Format: TXT=19618 bytes) (Updates RFC2608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3224) 3225 Indicating Resolver Support of DNSSEC. D. Conrad. December 2001. (Format: TXT=11548 bytes) (Updated by RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3225) 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements. O. Gudmundsson. December 2001. (Format: TXT=12078 bytes) (Updates RFC2535, RFC2874) (Updated by RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3226) 3227 Guidelines for Evidence Collection and Archiving. D. Brezinski, T. Killalea. February 2002. (Format: TXT=18468 bytes) (Also BCP0055) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3227) 3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP). B. Fenner. February 2002. (Format: TXT=6473 bytes) (Also BCP0057) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3228) 3229 Delta encoding in HTTP. J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein. January 2002. (Format: TXT=111953 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3229) 3230 Instance Digests in HTTP. J. Mogul, A. Van Hoff. January 2002. (Format: TXT=26846 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3230) 3231 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. January 2002. (Format: TXT=61308 bytes) (Obsoletes RFC2591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3231) 3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database. J. Reynolds, Ed.. January 2002. (Format: TXT=3849 bytes) (Obsoletes RFC1700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3232) 3233 Defining the IETF. P. Hoffman, S. Bradner. February 2002. (Format: TXT=6401 bytes) (Also BCP0058) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3233) 3234 Middleboxes: Taxonomy and Issues. B. Carpenter, S. Brim. February 2002. (Format: TXT=62329 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3234) 3235 Network Address Translator (NAT)-Friendly Application Design Guidelines. D. Senie. January 2002. (Format: TXT=29588 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3235) 3236 The 'application/xhtml+xml' Media Type. M. Baker, P. Stark. January 2002. (Format: TXT=16750 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3236) 3237 Requirements for Reliable Server Pooling. M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman. January 2002. (Format: TXT=16986 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3237) 3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services. S. Floyd, L. Daigle. January 2002. (Format: TXT=42336 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3238) 3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations. C. Kugler, H. Lewis, T. Hastings. February 2002. (Format: TXT=29532 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3239) 3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration. D. Clunie, E. Cordonnier. February 2002. (Format: TXT=9102 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3240) 3241 Robust Header Compression (ROHC) over PPP. C. Bormann. April 2002. (Format: TXT=24424 bytes) (Updates RFC1332) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3241) 3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP. L-E. Jonsson, G. Pelletier. April 2002. (Format: TXT=49007 bytes) (Obsoleted by RFC4362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3242) 3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression. L-E. Jonsson. April 2002. (Format: TXT=12451 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3243) 3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols. M. Swift, J. Trostle, J. Brezak. February 2002. (Format: TXT=13334 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3244) 3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2). J. Klensin, Ed., IAB. March 2002. (Format: TXT=23758 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3245) 3246 An Expedited Forwarding PHB (Per-Hop Behavior). B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis. March 2002. (Format: TXT=33896 bytes) (Obsoletes RFC2598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3246) 3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior). A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan. March 2002. (Format: TXT=53786 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3247) 3248 A Delay Bound alternative revision of RFC 2598. G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein. March 2002. (Format: TXT=21597 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3248) 3249 Implementers Guide for Facsimile Using Internet Mail. V. Cancio, M. Moldovan, H. Tamura, D. Wing. September 2002. (Format: TXT=40413 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3249) 3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration. L. McIntyre, G. Parsons, J. Rafferty. September 2002. (Format: TXT=17876 bytes) (Obsoleted by RFC3950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3250) 3251 Electricity over IP. B. Rajagopalan. April 2002. (Format: TXT=18994 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3251) 3252 Binary Lexical Octet Ad-hoc Transport. H. Kennedy. April 2002. (Format: TXT=25962 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3252) 3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning). G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead. March 2002. (Format: TXT=245514 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3253) 3254 Definitions for talking about directories. H. Alvestrand. April 2002. (Format: TXT=21541 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3254) 3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads. N. Jones, C. Murton. April 2002. (Format: TXT=14192 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3255) 3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option. D. Jones, R. Woundy. April 2002. (Format: TXT=8551 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3256) 3257 Stream Control Transmission Protocol Applicability Statement. L. Coene. April 2002. (Format: TXT=24198 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3257) 3258 Distributing Authoritative Name Servers via Shared Unicast Addresses. T. Hardie. April 2002. (Format: TXT=22195 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3258) 3259 A Message Bus for Local Coordination. J. Ott, C. Perkins, D. Kutscher. April 2002. (Format: TXT=84125 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3259) 3260 New Terminology and Clarifications for Diffserv. D. Grossman. April 2002. (Format: TXT=21900 bytes) (Updates RFC2474, RFC2475, RFC2597) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3260) 3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002. (Format: TXT=647976 bytes) (Obsoletes RFC2543) (Updated by RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC5621, RFC5626, RFC5630, RFC5922, RFC5954, RFC6026, RFC6141, RFC6665, RFC6878, RFC7462, RFC7463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3261) 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT=29643 bytes) (Obsoletes RFC2543) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3262) 3263 Session Initiation Protocol (SIP): Locating SIP Servers. J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT=42310 bytes) (Obsoletes RFC2543) (Updated by RFC7984) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3263) 3264 An Offer/Answer Model with Session Description Protocol (SDP). J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT=60854 bytes) (Obsoletes RFC2543) (Updated by RFC6157) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3264) 3265 Session Initiation Protocol (SIP)-Specific Event Notification. A. B. Roach. June 2002. (Format: TXT=89005 bytes) (Obsoletes RFC2543) (Obsoleted by RFC6665) (Updates RFC3261) (Updated by RFC5367, RFC5727, RFC6446) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3265) 3266 Support for IPv6 in Session Description Protocol (SDP). S. Olson, G. Camarillo, A. B. Roach. June 2002. (Format: TXT=8693 bytes) (Obsoleted by RFC4566) (Updates RFC2327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3266) 3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 bytes) (Obsoleted by RFC4867) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3267) 3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS). P. Chown. June 2002. (Format: TXT=13530 bytes) (Obsoleted by RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3268) 3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents. R. Kermode, L. Vicisano. April 2002. (Format: TXT=25258 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3269) 3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services. F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. May 2002. (Format: TXT=137960 bytes) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3270) 3271 The Internet is for Everyone. V. Cerf. April 2002. (Format: TXT=12345 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3271) 3272 Overview and Principles of Internet Traffic Engineering. D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. May 2002. (Format: TXT=190384 bytes) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3272) 3273 Remote Network Monitoring Management Information Base for High Capacity Networks. S. Waldbusser. July 2002. (Format: TXT=150924 bytes) (Updated by RFC4502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3273) 3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS). P. Gutmann. June 2002. (Format: TXT=11276 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3274) 3275 (Extensible Markup Language) XML-Signature Syntax and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2002. (Format: TXT=164198 bytes) (Obsoletes RFC3075) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3275) 3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing. B. Ray, R. Abbi. May 2002. (Format: TXT=122991 bytes) (Obsoleted by RFC4319) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3276) 3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance. D. McPherson. April 2002. (Format: TXT=13077 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3277) 3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). S. Blake-Wilson, D. Brown, P. Lambert. April 2002. (Format: TXT=33779 bytes) (Obsoleted by RFC5753) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3278) 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. L. Bassham, W. Polk, R. Housley. April 2002. (Format: TXT=53833 bytes) (Updated by RFC4055, RFC4491, RFC5480, RFC5758) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3279) 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, W. Polk, W. Ford, D. Solo. April 2002. (Format: TXT=295556 bytes) (Obsoletes RFC2459) (Obsoleted by RFC5280) (Updated by RFC4325, RFC4630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3280) 3281 An Internet Attribute Certificate Profile for Authorization. S. Farrell, R. Housley. April 2002. (Format: TXT=90580 bytes) (Obsoleted by RFC5755) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3281) 3282 Content Language Headers. H. Alvestrand. May 2002. (Format: TXT=14022 bytes) (Obsoletes RFC1766) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3282) 3283 Guide to Internet Calendaring. B. Mahoney, G. Babics, A. Taler. June 2002. (Format: TXT=31768 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3283) 3284 The VCDIFF Generic Differencing and Compression Data Format. D. Korn, J. MacDonald, J. Mogul, K. Vo. June 2002. (Format: TXT=64035 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3284) 3285 Using Microsoft Word to create Internet Drafts and RFCs. M. Gahrns, T. Hain. May 2002. (Format: TXT=34556 bytes) (Obsoleted by RFC5385) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3285) 3286 An Introduction to the Stream Control Transmission Protocol (SCTP). L. Ong, J. Yoakum. May 2002. (Format: TXT=22644 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3286) 3287 Remote Monitoring MIB Extensions for Differentiated Services. A. Bierman. July 2002. (Format: TXT=249622 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3287) 3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP). E. O'Tuathail, M. Rose. June 2002. (Format: TXT=27434 bytes) (Obsoleted by RFC4227) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3288) 3289 Management Information Base for the Differentiated Services Architecture. F. Baker, K. Chan, A. Smith. May 2002. (Format: TXT=239041 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3289) 3290 An Informal Management Model for Diffserv Routers. Y. Bernet, S. Blake, D. Grossman, A. Smith. May 2002. (Format: TXT=129443 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3290) 3291 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. May 2002. (Format: TXT=43564 bytes) (Obsoletes RFC2851) (Obsoleted by RFC4001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3291) 3292 General Switch Management Protocol (GSMP) V3. A. Doria, F. Hellstrand, K. Sundell, T. Worster. June 2002. (Format: TXT=318983 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3292) 3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP). T. Worster, A. Doria, J. Buerkle. June 2002. (Format: TXT=18206 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3293) 3294 General Switch Management Protocol (GSMP) Applicability. A. Doria, K. Sundell. June 2002. (Format: TXT=18294 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3294) 3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP). H. Sjostrand, J. Buerkle, B. Srinivasan. June 2002. (Format: TXT=95516 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3295) 3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories. K. Zeilenga. July 2002. (Format: TXT=27389 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3296) 3297 Content Negotiation for Messaging Services based on Email. G. Klyne, R. Iwazaki, D. Crocker. July 2002. (Format: TXT=97094 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3297) 3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements. I. Faynberg, J. Gato, H. Lu, L. Slutsman. August 2002. (Format: TXT=36560 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3298) 3299 Request for Comments Summary RFC Numbers 3200-3299. S. Ginoza. December 2003. (Format: TXT=63813 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3299) 3300 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. November 2002. (Format: TXT=127805 bytes) (Obsoletes RFC3000) (Obsoleted by RFC3600) (Status: HISTORIC) (DOI: 10.17487/RFC3300) 3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions. Y. T'Joens, P. Crivellari, B. Sales. June 2002. (Format: TXT=42756 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3301) 3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration. G. Parsons, J. Rafferty. September 2002. (Format: TXT=15183 bytes) (Obsoletes RFC2302) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3302) 3303 Middlebox communication architecture and framework. P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan. August 2002. (Format: TXT=91209 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3303) 3304 Middlebox Communications (midcom) Protocol Requirements. R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore. August 2002. (Format: TXT=16187 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3304) 3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations. M. Mealling, Ed., R. Denenberg, Ed.. August 2002. (Format: TXT=21793 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3305) 3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Format: TXT=12713 bytes) (Updated by RFC3956, RFC4489, RFC7371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3306) 3307 Allocation Guidelines for IPv6 Multicast Addresses. B. Haberman. August 2002. (Format: TXT=15742 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3307) 3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension. P. Calhoun, W. Luo, D. McPherson, K. Peirce. November 2002. (Format: TXT=21536 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3308) 3309 Stream Control Transmission Protocol (SCTP) Checksum Change. J. Stone, R. Stewart, D. Otis. September 2002. (Format: TXT=34670 bytes) (Obsoleted by RFC4960) (Updates RFC2960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3309) 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA). A. Niemi, J. Arkko, V. Torvinen. September 2002. (Format: TXT=36985 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3310) 3311 The Session Initiation Protocol (SIP) UPDATE Method. J. Rosenberg. October 2002. (Format: TXT=28125 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3311) 3312 Integration of Resource Management and Session Initiation Protocol (SIP). G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. October 2002. (Format: TXT=65757, PS=655218, PDF=130391 bytes) (Updated by RFC4032, RFC5027) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3312) 3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization. W. Marshall, Ed.. January 2003. (Format: TXT=36866 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3313) 3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. M. Wasserman, Ed.. September 2002. (Format: TXT=48168 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3314) 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT=231402 bytes) (Updated by RFC4361, RFC5494, RFC6221, RFC6422, RFC6644, RFC7083, RFC7227, RFC7283, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3315) 3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts. J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. April 2003. (Format: TXT=48741 bytes) (Obsoleted by RFC7066) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3316) 3317 Differentiated Services Quality of Service Policy Information Base. K. Chan, R. Sahita, S. Hahn, K. McCloghrie. March 2003. (Format: TXT=188553 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3317) 3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie. March 2003. (Format: TXT=144530 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3318) 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers. H. Schulzrinne, B. Volz. July 2003. (Format: TXT=14444 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3319) 3320 Signaling Compression (SigComp). R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg. January 2003. (Format: TXT=137035 bytes) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3320) 3321 Signaling Compression (SigComp) - Extended Operations. H. Hannu, J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price. January 2003. (Format: TXT=39433 bytes) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3321) 3322 Signaling Compression (SigComp) Requirements & Assumptions. H. Hannu. January 2003. (Format: TXT=27533 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3322) 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J. Peterson. November 2002. (Format: TXT=54116 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3323) 3324 Short Term Requirements for Network Asserted Identity. M. Watson. November 2002. (Format: TXT=21964 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3324) 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks. C. Jennings, J. Peterson, M. Watson. November 2002. (Format: TXT=36170 bytes) (Updated by RFC5876) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3325) 3326 The Reason Header Field for the Session Initiation Protocol (SIP). H. Schulzrinne, D. Oran, G. Camarillo. December 2002. (Format: TXT=15695 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3326) 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts. D. Willis, B. Hoeneisen. December 2002. (Format: TXT=36493 bytes) (Updated by RFC5626) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3327) 3328 Not Issued. 3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP). J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka. January 2003. (Format: TXT=51503 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3329) 3330 Special-Use IPv4 Addresses. IANA. September 2002. (Format: TXT=16200 bytes) (Obsoleted by RFC5735) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3330) 3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer. K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock, J. Heitz. September 2002. (Format: TXT=210807 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3331) 3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA). G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed.. September 2002. (Format: TXT=265055 bytes) (Obsoleted by RFC4666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3332) 3334 Policy-Based Accounting. T. Zseby, S. Zander, C. Carle. October 2002. (Format: TXT=103014 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3334) 3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet. T. Harding, R. Drummond, C. Shih. September 2002. (Format: TXT=59687 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3335) 3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2). B. Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT=33631 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3336) 3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2. B. Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT=14911 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3337) 3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA). S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. October 2002. (Format: TXT=34480 bytes) (Obsoleted by RFC6535) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3338) 3339 Date and Time on the Internet: Timestamps. G. Klyne, C. Newman. July 2002. (Format: TXT=35064 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3339) 3340 The Application Exchange Core. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT=74266 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3340) 3341 The Application Exchange (APEX) Access Service. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT=46675 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3341) 3342 The Application Exchange (APEX) Option Party Pack, Part Deux!. E. Dixon, H. Franklin, J. Kint, G. Klyne, D. New, S. Pead, M. Rose, M. Schwartz. July 2002. (Format: TXT=34300 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3342) 3343 The Application Exchange (APEX) Presence Service. M. Rose, G. Klyne, D. Crocker. April 2003. (Format: TXT=42043 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3343) 3344 IP Mobility Support for IPv4. C. Perkins, Ed.. August 2002. (Format: TXT=241041 bytes) (Obsoletes RFC3220) (Obsoleted by RFC5944) (Updated by RFC4636, RFC4721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3344) 3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition. D. McPherson, V. Gill, D. Walton, A. Retana. August 2002. (Format: TXT=38137 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3345) 3346 Applicability Statement for Traffic Engineering with MPLS. J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S. Lai. August 2002. (Format: TXT=33754 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3346) 3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations. M. Krueger, R. Haagens. July 2002. (Format: TXT=58097 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3347) 3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension. M. Gahrns, R. Cheng. July 2002. (Format: TXT=11868 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3348) 3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force. M. Rose. July 2002. (Format: TXT=7916 bytes) (Also BCP0059) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3349) 3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals. N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk. August 2002. (Format: TXT=33894 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3351) 3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status. K. Zeilenga. March 2003. (Format: TXT=7265 bytes) (Obsoletes RFC1798) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3352) 3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment. D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari. August 2002. (Format: TXT=65860 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3353) 3354 Internet Open Trading Protocol Version 2 Requirements. D. Eastlake 3rd. August 2002. (Format: TXT=9671 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3354) 3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5). A. Singh, R. Turner, R. Tio, S. Nanji. August 2002. (Format: TXT=25114 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3355) 3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines. G. Fishman, S. Bradner. August 2002. (Format: TXT=27149 bytes) (Obsoletes RFC2436) (Obsoleted by RFC6756) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3356) 3357 One-way Loss Pattern Sample Metrics. R. Koodli, R. Ravikanth. August 2002. (Format: TXT=30570 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3357) 3358 Optional Checksums in Intermediate System to Intermediate System (ISIS). T. Przygienda. August 2002. (Format: TXT=8266 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3358) 3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System. T. Przygienda. August 2002. (Format: TXT=7843 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3359) 3360 Inappropriate TCP Resets Considered Harmful. S. Floyd. August 2002. (Format: TXT=46748 bytes) (Also BCP0060) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3360) 3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers. H. Schulzrinne. August 2002. (Format: TXT=12549 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3361) 3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration. G. Parsons. August 2002. (Format: TXT=8301 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3362) 3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002. (Format: TXT=11055 bytes) (Updates RFC2673, RFC2874) (Updated by RFC6672) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3363) 3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). R. Austein. August 2002. (Format: TXT=26544 bytes) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3364) 3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols. J. Schiller. August 2002. (Format: TXT=16411 bytes) (Also BCP0061) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3365) 3366 Advice to link designers on link Automatic Repeat reQuest (ARQ). G. Fairhurst, L. Wood. August 2002. (Format: TXT=66097 bytes) (Also BCP0062) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3366) 3367 Common Name Resolution Protocol (CNRP). N. Popp, M. Mealling, M. Moseley. August 2002. (Format: TXT=86889 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3367) 3368 The 'go' URI Scheme for the Common Name Resolution Protocol. M. Mealling. August 2002. (Format: TXT=12726 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3368) 3369 Cryptographic Message Syntax (CMS). R. Housley. August 2002. (Format: TXT=113975 bytes) (Obsoletes RFC2630, RFC3211) (Obsoleted by RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3369) 3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August 2002. (Format: TXT=51001 bytes) (Obsoletes RFC2630, RFC3211) (Updated by RFC5754) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3370) 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base. E. Caves, P. Calhoun, R. Wheeler. August 2002. (Format: TXT=139974 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3371) 3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures. A. Vemuri, J. Peterson. September 2002. (Format: TXT=49893 bytes) (Also BCP0063) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3372) 3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies. D. Katz, R. Saluja. September 2002. (Format: TXT=19522 bytes) (Obsoleted by RFC5303) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3373) 3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network. J. Kempf, Ed.. September 2002. (Format: TXT=28245 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3374) 3375 Generic Registry-Registrar Protocol Requirements. S. Hollenbeck. September 2002. (Format: TXT=46022 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3375) 3376 Internet Group Management Protocol, Version 3. B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. October 2002. (Format: TXT=119726 bytes) (Updates RFC2236) (Updated by RFC4604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3376) 3377 Lightweight Directory Access Protocol (v3): Technical Specification. J. Hodges, R. Morgan. September 2002. (Format: TXT=9981 bytes) (Obsoleted by RFC4510) (Updates RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3377) 3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams. R. Housley, S. Hollenbeck. September 2002. (Format: TXT=18803 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3378) 3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements. D. Pinkas, R. Housley. September 2002. (Format: TXT=32455 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3379) 3380 Internet Printing Protocol (IPP): Job and Printer Set Operations. T. Hastings, R. Herriot, C. Kugler, H. Lewis. September 2002. (Format: TXT=132044 bytes) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3380) 3381 Internet Printing Protocol (IPP): Job Progress Attributes. T. Hastings, H. Lewis, R. Bergman. September 2002. (Format: TXT=36595 bytes) (Obsoleted by RFC8011) (Updates RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3381) 3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax. R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler. September 2002. (Format: TXT=78173 bytes) (Obsoleted by RFC8010, RFC8011) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3382) 3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. September 2002. (Format: TXT=45893 bytes) (Obsoleted by RFC4520) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3383) 3384 Lightweight Directory Access Protocol (version 3) Replication Requirements. E. Stokes, R. Weiser, R. Moats, R. Huber. October 2002. (Format: TXT=66871 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3384) 3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations. D. Sheinwald, J. Satran, P. Thaler, V. Cavanna. September 2002. (Format: TXT=53450 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3385) 3386 Network Hierarchy and Multilayer Survivability. W. Lai, Ed., D. McDysan, Ed.. November 2002. (Format: TXT=65345 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3386) 3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network. M. Eder, H. Chaskar, S. Nag. September 2002. (Format: TXT=52693 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3387) 3388 Grouping of Media Lines in the Session Description Protocol (SDP). G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne. December 2002. (Format: TXT=39365 bytes) (Obsoleted by RFC5888) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3388) 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN). R. Zopf. September 2002. (Format: TXT=17018 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3389) 3390 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. October 2002. (Format: TXT=36177 bytes) (Obsoletes RFC2414) (Updates RFC2581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3390) 3391 The MIME Application/Vnd.pwg-multiplexed Content-Type. R. Herriot. December 2002. (Format: TXT=54739 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3391) 3392 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. November 2002. (Format: TXT=9885 bytes) (Obsoletes RFC2842) (Obsoleted by RFC5492) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3392) 3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). C. Demichelis, P. Chimento. November 2002. (Format: TXT=47731 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3393) 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad, R. Housley. September 2002. (Format: TXT=73072 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3394) 3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions. A. Bierman, C. Bucci, R. Dietz, A. Warth. September 2002. (Format: TXT=43862 bytes) (Updates RFC2895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3395) 3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4). T. Lemon, S. Cheshire. November 2002. (Format: TXT=18779 bytes) (Updates RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3396) 3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option. B. Aboba, S. Cheshire. November 2002. (Format: TXT=15446 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3397) 3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping. G. Camarillo, A. B. Roach, J. Peterson, L. Ong. December 2002. (Format: TXT=166197 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3398) 3400 Not Issued. 3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS. M. Mealling. October 2002. (Format: TXT=10172 bytes) (Obsoletes RFC2915, RFC2168) (Updates RFC2276) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3401) 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm. M. Mealling. October 2002. (Format: TXT=38925 bytes) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3402) 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database. M. Mealling. October 2002. (Format: TXT=31058 bytes) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3403) 3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI). M. Mealling. October 2002. (Format: TXT=40124 bytes) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3404) 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures. M. Mealling. October 2002. (Format: TXT=19469 bytes) (Also BCP0065) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3405) 3406 Uniform Resource Names (URN) Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. October 2002. (Format: TXT=43707 bytes) (Obsoletes RFC2611) (Also BCP0066) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3406) 3407 Session Description Protocol (SDP) Simple Capability Declaration. F. Andreasen. October 2002. (Format: TXT=21133 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3407) 3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile. Z. Liu, K. Le. December 2002. (Format: TXT=14805 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3408) 3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression. K. Svanbro. December 2002. (Format: TXT=25815 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3409) 3410 Introduction and Applicability Statements for Internet-Standard Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. December 2002. (Format: TXT=61461 bytes) (Obsoletes RFC2570) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3410) 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. December 2002. (Format: TXT=140096 bytes) (Obsoletes RFC2571) (Updated by RFC5343, RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3411) 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. December 2002. (Format: TXT=95710 bytes) (Obsoletes RFC2572) (Updated by RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3412) 3413 Simple Network Management Protocol (SNMP) Applications. D. Levi, P. Meyer, B. Stewart. December 2002. (Format: TXT=153719 bytes) (Obsoletes RFC2573) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3413) 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. December 2002. (Format: TXT=193558 bytes) (Obsoletes RFC2574) (Updated by RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3414) 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. December 2002. (Format: TXT=82046 bytes) (Obsoletes RFC2575) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3415) 3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT=70043 bytes) (Obsoletes RFC1905) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3416) 3417 Transport Mappings for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT=38650 bytes) (Obsoletes RFC1906) (Updated by RFC4789, RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3417) 3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT=49096 bytes) (Obsoletes RFC1907) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3418) 3419 Textual Conventions for Transport Addresses. M. Daniele, J. Schoenwaelder. December 2002. (Format: TXT=37466 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3419) 3420 Internet Media Type message/sipfrag. R. Sparks. November 2002. (Format: TXT=14745 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3420) 3421 Select and Sort Extensions for the Service Location Protocol (SLP). W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. November 2002. (Format: TXT=15260 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3421) 3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS). O. Okamoto, M. Maruyama, T. Sajima. November 2002. (Format: TXT=37576 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3422) 3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0. K. Zhang, E. Elkin. November 2002. (Format: TXT=97731 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3423) 3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation. L. Daigle, Ed., IAB. November 2002. (Format: TXT=18165 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3424) 3425 Obsoleting IQUERY. D. Lawrence. November 2002. (Format: TXT=8615 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3425) 3426 General Architectural and Policy Considerations. S. Floyd. November 2002. (Format: TXT=54868 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3426) 3427 Change Process for the Session Initiation Protocol (SIP). A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, B. Rosen. December 2002. (Format: TXT=26234 bytes) (Obsoleted by RFC5727) (Updated by RFC3968, RFC3969) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3427) 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging. B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. December 2002. (Format: TXT=41475 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3428) 3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions. H. Ohta. November 2002. (Format: TXT=10903 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3429) 3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping. J. Schoenwaelder. December 2002. (Format: TXT=21527 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3430) 3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002. (Format: TXT=12849 bytes) (Obsoleted by RFC5231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3431) 3432 Network performance measurement with periodic streams. V. Raisanen, G. Grotefeld, A. Morton. November 2002. (Format: TXT=52493 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3432) 3433 Entity Sensor Management Information Base. A. Bierman, D. Romascanu, K.C. Norseth. December 2002. (Format: TXT=31857 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3433) 3434 Remote Monitoring MIB Extensions for High Capacity Alarms. A. Bierman, K. McCloghrie. December 2002. (Format: TXT=51072 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3434) 3435 Media Gateway Control Protocol (MGCP) Version 1.0. F. Andreasen, B. Foster. January 2003. (Format: TXT=467084 bytes) (Obsoletes RFC2705) (Updated by RFC3661) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3435) 3436 Transport Layer Security over Stream Control Transmission Protocol. A. Jungmaier, E. Rescorla, M. Tuexen. December 2002. (Format: TXT=16333 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3436) 3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation. W. Palter, W. Townsley. December 2002. (Format: TXT=20820 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3437) 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update. W. Townsley. December 2002. (Format: TXT=9135 bytes) (Also BCP0068) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3438) 3439 Some Internet Architectural Guidelines and Philosophy. R. Bush, D. Meyer. December 2002. (Format: TXT=70333 bytes) (Updates RFC1958) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3439) 3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines. F. Ly, G. Bathrick. December 2002. (Format: TXT=76058 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3440) 3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP). R. Kumar. January 2003. (Format: TXT=122455 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3441) 3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4. T. Lemon, S. Cheshire, B. Volz. December 2002. (Format: TXT=19370 bytes) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3442) 3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks. P. Agarwal, B. Akyol. January 2003. (Format: TXT=18749 bytes) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3443) 3444 On the Difference between Information Models and Data Models. A. Pras, J. Schoenwaelder. January 2003. (Format: TXT=18596 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3444) 3445 Limiting the Scope of the KEY Resource Record (RR). D. Massey, S. Rose. December 2002. (Format: TXT=20947 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3445) 3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP). D. Kim, D. Meyer, H. Kilmer, D. Farinacci. January 2003. (Format: TXT=14792 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3446) 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. J. Jonsson, B. Kaliski. February 2003. (Format: TXT=143173 bytes) (Obsoletes RFC2437) (Obsoleted by RFC8017) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3447) 3448 TCP Friendly Rate Control (TFRC): Protocol Specification. M. Handley, S. Floyd, J. Padhye, J. Widmer. January 2003. (Format: TXT=52657 bytes) (Obsoleted by RFC5348) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3448) 3449 TCP Performance Implications of Network Path Asymmetry. H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. December 2002. (Format: TXT=108839 bytes) (Also BCP0069) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3449) 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation. M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. December 2002. (Format: TXT=86022 bytes) (Obsoleted by RFC5775) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3450) 3451 Layered Coding Transport (LCT) Building Block. M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT=72594 bytes) (Obsoleted by RFC5651) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3451) 3452 Forward Error Correction (FEC) Building Block. M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT=38368 bytes) (Obsoleted by RFC5052, RFC5445) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3452) 3453 The Use of Forward Error Correction (FEC) in Reliable Multicast. M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT=46853 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3453) 3454 Preparation of Internationalized Strings ("stringprep"). P. Hoffman, M. Blanchet. December 2002. (Format: TXT=138684 bytes) (Obsoleted by RFC7564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3454) 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP). M. Garcia-Martin, E. Henrikson, D. Mills. January 2003. (Format: TXT=79620 bytes) (Obsoleted by RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3455) 3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode. B. Patel, B. Aboba, S. Kelly, V. Gupta. January 2003. (Format: TXT=40340 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3456) 3457 Requirements for IPsec Remote Access Scenarios. S. Kelly, S. Ramamoorthi. January 2003. (Format: TXT=75167 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3457) 3458 Message Context for Internet Mail. E. Burger, E. Candell, C. Eliot, G. Klyne. January 2003. (Format: TXT=34181 bytes) (Updated by RFC3938) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3458) 3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter. E. Burger. January 2003. (Format: TXT=54282 bytes) (Updates RFC3204) (Updated by RFC5621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3459) 3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed.. January 2003. (Format: TXT=212453 bytes) (Updates RFC3060) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3460) 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs). K. Moore. January 2003. (Format: TXT=76076 bytes) (Obsoletes RFC1891) (Updated by RFC3798, RFC3885, RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3461) 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. G. Vaudreuil. January 2003. (Format: TXT=12186 bytes) (Obsoletes RFC1892) (Obsoleted by RFC6522) (Updated by RFC5337) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3462) 3463 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003. (Format: TXT=31832 bytes) (Obsoletes RFC1893) (Updated by RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3463) 3464 An Extensible Message Format for Delivery Status Notifications. K. Moore, G. Vaudreuil. January 2003. (Format: TXT=83060 bytes) (Obsoletes RFC1894) (Updated by RFC4865, RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3464) 3465 TCP Congestion Control with Appropriate Byte Counting (ABC). M. Allman. February 2003. (Format: TXT=23486 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3465) 3466 A Model for Content Internetworking (CDI). M. Day, B. Cain, G. Tomlinson, P. Rzewski. February 2003. (Format: TXT=37684 bytes) (Obsoleted by RFC7336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3466) 3467 Role of the Domain Name System (DNS). J. Klensin. February 2003. (Format: TXT=84570 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3467) 3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols. L. Andersson, G. Swallow. February 2003. (Format: TXT=22072 bytes) (Updates RFC3212, RFC3472, RFC3475, RFC3476) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3468) 3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery. V. Sharma, Ed., F. Hellstrand, Ed.. February 2003. (Format: TXT=89331 bytes) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3469) 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols. S. Hollenbeck, M. Rose, L. Masinter. January 2003. (Format: TXT=64252 bytes) (Also BCP0070) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3470) 3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description. L. Berger, Ed.. January 2003. (Format: TXT=72105 bytes) (Updated by RFC4201, RFC4328, RFC4872, RFC6002, RFC6003, RFC6205, RFC7074, RFC7699) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3471) 3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions. P. Ashwood-Smith, Ed., L. Berger, Ed.. January 2003. (Format: TXT=49006 bytes) (Updated by RFC3468, RFC4201) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3472) 3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. L. Berger, Ed.. January 2003. (Format: TXT=91808 bytes) (Updated by RFC4003, RFC4201, RFC4420, RFC4783, RFC4874, RFC4873, RFC4974, RFC5063, RFC5151, RFC5420, RFC6002, RFC6003, RFC6780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3473) 3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON). Z. Lin, D. Pendarakis. March 2003. (Format: TXT=52551 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3474) 3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON). O. Aboul-Magd. March 2003. (Format: TXT=29995 bytes) (Updated by RFC3468) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3475) 3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling. B. Rajagopalan. March 2003. (Format: TXT=22009 bytes) (Updated by RFC3468) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3476) 3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE). K. Kompella, Y. Rekhter. January 2003. (Format: TXT=19899 bytes) (Updated by RFC6107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3477) 3478 Graceful Restart Mechanism for Label Distribution Protocol. M. Leelanivas, Y. Rekhter, R. Aggarwal. February 2003. (Format: TXT=29248 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3478) 3479 Fault Tolerance for the Label Distribution Protocol (LDP). A. Farrel, Ed.. February 2003. (Format: TXT=115778 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3479) 3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol). K. Kompella, Y. Rekhter, A. Kullberg. February 2003. (Format: TXT=17076 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3480) 3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks. H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov. February 2003. (Format: TXT=61528 bytes) (Also BCP0071) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3481) 3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview. M. Foster, T. McGarry, J. Yu. February 2003. (Format: TXT=78552 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3482) 3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR). D. Rawlins, A. Kulkarni, M. Bokaemper, K. Chan. March 2003. (Format: TXT=19869 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3483) 3484 Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format: TXT=55076 bytes) (Obsoleted by RFC6724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3484) 3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp). M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach. February 2003. (Format: TXT=80195 bytes) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3485) 3486 Compressing the Session Initiation Protocol (SIP). G. Camarillo. February 2003. (Format: TXT=24181 bytes) (Updated by RFC5049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3486) 3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP). H. Schulzrinne. February 2003. (Format: TXT=39615 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3487) 3488 Cisco Systems Router-port Group Management Protocol (RGMP). I. Wu, T. Eckert. February 2003. (Format: TXT=37152 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3488) 3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. March 2003. (Format: TXT=117562 bytes) (Obsoleted by RFC5389) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3489) 3490 Internationalizing Domain Names in Applications (IDNA). P. Faltstrom, P. Hoffman, A. Costello. March 2003. (Format: TXT=51943 bytes) (Obsoleted by RFC5890, RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3490) 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN). P. Hoffman, M. Blanchet. March 2003. (Format: TXT=10316 bytes) (Obsoleted by RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3491) 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. (Format: TXT=67439 bytes) (Updated by RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3492) 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3493) 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status. K. Zeilenga. March 2003. (Format: TXT=9225 bytes) (Obsoletes RFC1484, RFC1485, RFC1487, RFC1777, RFC1778, RFC1779, RFC1781, RFC2559) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3494) 3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration. B. Beser, P. Duffy, Ed.. March 2003. (Format: TXT=26817 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3495) 3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. A. G. Malis, T. Hsiao. March 2003. (Format: TXT=11431 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3496) 3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video. L. Gharai, C. Perkins, G. Goncher, A. Mankin. March 2003. (Format: TXT=26094 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3497) 3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures. J. Kuhfeld, J. Johnson, M. Thatcher. March 2003. (Format: TXT=78701 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3498) 3499 Request for Comments Summary RFC Numbers 3400-3499. S. Ginoza. December 2003. (Format: TXT=88033 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3499) 3500 Not Issued. 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. M. Crispin. March 2003. (Format: TXT=227640 bytes) (Obsoletes RFC2060) (Updated by RFC4466, RFC4469, RFC4551, RFC5032, RFC5182, RFC5738, RFC6186, RFC6858, RFC7817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3501) 3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension. M. Crispin. March 2003. (Format: TXT=13379 bytes) (Updated by RFC4466, RFC4469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3502) 3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP). A. Melnikov. March 2003. (Format: TXT=16937 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3503) 3504 Internet Open Trading Protocol (IOTP) Version 1, Errata. D. Eastlake. March 2003. (Format: TXT=8655 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3504) 3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements. D. Eastlake. March 2003. (Format: TXT=13915 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3505) 3506 Requirements and Design for Voucher Trading System (VTS). K. Fujimura, D. Eastlake. March 2003. (Format: TXT=30945 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3506) 3507 Internet Content Adaptation Protocol (ICAP). J. Elson, A. Cerpa. April 2003. (Format: TXT=98772 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3507) 3508 H.323 Uniform Resource Locator (URL) Scheme Registration. O. Levin. April 2003. (Format: TXT=10983 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3508) 3509 Alternative Implementations of OSPF Area Border Routers. A. Zinin, A. Lindem, D. Yeung. April 2003. (Format: TXT=24326 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3509) 3510 Internet Printing Protocol/1.1: IPP URL Scheme. R. Herriot, I. McDonald. April 2003. (Format: TXT=22009 bytes) (Updates RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3510) 3511 Benchmarking Methodology for Firewall Performance. B. Hickman, D. Newman, S. Tadjudin, T. Martin. April 2003. (Format: TXT=67916 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3511) 3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP). M. MacFaden, D. Partain, J. Saperia, W. Tackabury. April 2003. (Format: TXT=196529 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3512) 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. (Format: TXT=53920 bytes) (Obsoletes RFC2373) (Obsoleted by RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3513) 3514 The Security Flag in the IPv4 Header. S. Bellovin. April 2003. (Format: TXT=11211 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3514) 3515 The Session Initiation Protocol (SIP) Refer Method. R. Sparks. April 2003. (Format: TXT=47788 bytes) (Updated by RFC7647) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3515) 3516 IMAP4 Binary Content Extension. L. Nerenberg. April 2003. (Format: TXT=14598 bytes) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3516) 3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP. E. Blanton, M. Allman, K. Fall, L. Wang. April 2003. (Format: TXT=27855 bytes) (Obsoleted by RFC6675) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3517) 3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP). M. Higashiyama, F. Baker, T. Liao. April 2003. (Format: TXT=82102 bytes) (Obsoletes RFC2878) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3518) 3519 Mobile IP Traversal of Network Address Translation (NAT) Devices. H. Levkowetz, S. Vaarala. April 2003. (Format: TXT=80522 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3519) 3520 Session Authorization Policy Element. L-N. Hamer, B. Gage, B. Kosinski, H. Shieh. April 2003. (Format: TXT=63445 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3520) 3521 Framework for Session Set-up with Media Authorization. L-N. Hamer, B. Gage, H. Shieh. April 2003. (Format: TXT=59548 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3521) 3522 The Eifel Detection Algorithm for TCP. R. Ludwig, M. Meyer. April 2003. (Format: TXT=33731 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3522) 3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology. J. Polk. April 2003. (Format: TXT=10190 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3523) 3524 Mapping of Media Streams to Resource Reservation Flows. G. Camarillo, A. Monrad. April 2003. (Format: TXT=11249 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3524) 3525 Gateway Control Protocol Version 1. C. Groves, Ed., M. Pantaleo, Ed., T. Anderson, Ed., T. Taylor, Ed.. June 2003. (Format: TXT=439674 bytes) (Obsoletes RFC3015) (Obsoleted by RFC5125) (Status: HISTORIC) (DOI: 10.17487/RFC3525) 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). T. Kivinen, M. Kojo. May 2003. (Format: TXT=19166 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3526) 3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4. K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy. April 2003. (Format: TXT=16831 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3527) 3528 Mesh-enhanced Service Location Protocol (mSLP). W. Zhao, H. Schulzrinne, E. Guttman. April 2003. (Format: TXT=35208 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3528) 3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP). W. Harold. April 2003. (Format: TXT=23314 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3529) 3530 Network File System (NFS) version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. April 2003. (Format: TXT=600988 bytes) (Obsoletes RFC3010) (Obsoleted by RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3530) 3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block. M. Blanchet. April 2003. (Format: TXT=11314 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3531) 3532 Requirements for the Dynamic Partitioning of Switching Elements. T. Anderson, J. Buerkle. May 2003. (Format: TXT=25119 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3532) 3533 The Ogg Encapsulation Format Version 0. S. Pfeiffer. May 2003. (Format: TXT=32045 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3533) 3534 The application/ogg Media Type. L. Walleij. May 2003. (Format: TXT=10013 bytes) (Obsoleted by RFC5334) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3534) 3535 Overview of the 2002 IAB Network Management Workshop. J. Schoenwaelder. May 2003. (Format: TXT=42566 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3535) 3536 Terminology Used in Internationalization in the IETF. P. Hoffman. May 2003. (Format: TXT=64284 bytes) (Obsoleted by RFC6365) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3536) 3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key. J. Schaad, R. Housley. May 2003. (Format: TXT=16885 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3537) 3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP). Y. Kawatsura. June 2003. (Format: TXT=103475 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3538) 3539 Authentication, Authorization and Accounting (AAA) Transport Profile. B. Aboba, J. Wood. June 2003. (Format: TXT=93110 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3539) 3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces. N. Spring, D. Wetherall, D. Ely. June 2003. (Format: TXT=30081 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3540) 3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D). A. Walsh. May 2003. (Format: TXT=11358 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3541) 3542 Advanced Sockets Application Program Interface (API) for IPv6. W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. May 2003. (Format: TXT=173028 bytes) (Obsoletes RFC2292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3542) 3543 Registration Revocation in Mobile IPv4. S. Glass, M. Chandra. August 2003. (Format: TXT=81805 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3543) 3544 IP Header Compression over PPP. T. Koren, S. Casner, C. Bormann. July 2003. (Format: TXT=27627 bytes) (Obsoletes RFC2509) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3544) 3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering. T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy. July 2003. (Format: TXT=48278 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3545) 3546 Transport Layer Security (TLS) Extensions. S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. June 2003. (Format: TXT=63437 bytes) (Obsoleted by RFC4366) (Updates RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3546) 3547 The Group Domain of Interpretation. M. Baugher, B. Weis, T. Hardjono, H. Harney. July 2003. (Format: TXT=108901 bytes) (Obsoleted by RFC6407) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3547) 3548 The Base16, Base32, and Base64 Data Encodings. S. Josefsson, Ed.. July 2003. (Format: TXT=26363 bytes) (Obsoleted by RFC4648) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3548) 3549 Linux Netlink as an IP Services Protocol. J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov. July 2003. (Format: TXT=72161 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3549) 3550 RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. July 2003. (Format: TXT=259985, PS=630740, PDF=504117 bytes) (Obsoletes RFC1889) (Updated by RFC5506, RFC5761, RFC6051, RFC6222, RFC7022, RFC7160, RFC7164) (Also STD0064) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3550) 3551 RTP Profile for Audio and Video Conferences with Minimal Control. H. Schulzrinne, S. Casner. July 2003. (Format: TXT=106621, PS=317286, PDF=237831 bytes) (Obsoletes RFC1890) (Updated by RFC5761, RFC7007) (Also STD0065) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3551) 3552 Guidelines for Writing RFC Text on Security Considerations. E. Rescorla, B. Korver. July 2003. (Format: TXT=110393 bytes) (Also BCP0072) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3552) 3553 An IETF URN Sub-namespace for Registered Protocol Parameters. M. Mealling, L. Masinter, T. Hardie, G. Klyne. June 2003. (Format: TXT=14815 bytes) (Also BCP0073) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3553) 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec. S. Bellovin, J. Ioannidis, A. Keromytis, R. Stewart. July 2003. (Format: TXT=20102 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3554) 3555 MIME Type Registration of RTP Payload Formats. S. Casner, P. Hoschka. July 2003. (Format: TXT=56618 bytes) (Obsoleted by RFC4855, RFC4856) (Updated by RFC3625, RFC4629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3555) 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth. S. Casner. July 2003. (Format: TXT=15310 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3556) 3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding. Q. Xie, Ed.. July 2003. (Format: TXT=29692 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3557) 3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV). A. Li. July 2003. (Format: TXT=49787 bytes) (Updated by RFC4788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3558) 3559 Multicast Address Allocation MIB. D. Thaler. June 2003. (Format: TXT=68239 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3559) 3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS). R. Housley. July 2003. (Format: TXT=37381 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3560) 3561 Ad hoc On-Demand Distance Vector (AODV) Routing. C. Perkins, E. Belding-Royer, S. Das. July 2003. (Format: TXT=90356 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3561) 3562 Key Management Considerations for the TCP MD5 Signature Option. M. Leech. July 2003. (Format: TXT=14965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3562) 3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development. A. Zinin. July 2003. (Format: TXT=14974 bytes) (Updated by RFC6233) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3563) 3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering. F. Le Faucheur, W. Lai. July 2003. (Format: TXT=50808 bytes) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3564) 3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. July 2003. (Format: TXT=26773 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3565) 3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec. S. Frankel, H. Herbert. September 2003. (Format: TXT=24645 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3566) 3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication. T. Li, R. Atkinson. July 2003. (Format: TXT=13467 bytes) (Obsoleted by RFC5304) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3567) 3568 Known Content Network (CN) Request-Routing Mechanisms. A. Barbir, B. Cain, R. Nair, O. Spatscheck. July 2003. (Format: TXT=42443 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3568) 3569 An Overview of Source-Specific Multicast (SSM). S. Bhattacharyya, Ed.. July 2003. (Format: TXT=29387 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3569) 3570 Content Internetworking (CDI) Scenarios. P. Rzewski, M. Day, D. Gilletti. July 2003. (Format: TXT=42432 bytes) (Obsoleted by RFC6770) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3570) 3571 Framework Policy Information Base for Usage Feedback. D. Rawlins, A. Kulkarni, K. Ho Chan, M. Bokaemper, D. Dutt. August 2003. (Format: TXT=70894 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3571) 3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH). T. Ogura, M. Maruyama, T. Yoshida. July 2003. (Format: TXT=30607 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3572) 3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP). I. Goyret. July 2003. (Format: TXT=22758 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3573) 3574 Transition Scenarios for 3GPP Networks. J. Soininen, Ed.. August 2003. (Format: TXT=23359 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3574) 3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service). B. Aboba. July 2003. (Format: TXT=15539 bytes) (Updates RFC2865, RFC2868) (Updated by RFC6929) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3575) 3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. July 2003. (Format: TXT=70027 bytes) (Obsoleted by RFC5176) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3576) 3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules. S. Waldbusser, R. Cole, C. Kalbfleisch, D. Romascanu. August 2003. (Format: TXT=68551 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3577) 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP). G. Camarillo, A. B. Roach, J. Peterson, L. Ong. August 2003. (Format: TXT=26667 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3578) 3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP). B. Aboba, P. Calhoun. September 2003. (Format: TXT=104469 bytes) (Updates RFC2869) (Updated by RFC5080) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3579) 3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines. P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese. September 2003. (Format: TXT=66136 bytes) (Updated by RFC7268) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3580) 3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing. J. Rosenberg, H. Schulzrinne. August 2003. (Format: TXT=66133 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3581) 3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B. Black, V. Gill. August 2003. (Format: TXT=17045 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3582) 3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP. H. Chaskar, Ed.. September 2003. (Format: TXT=22541 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3583) 3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. August 2003. (Format: TXT=115222 bytes) (Obsoletes RFC2576) (Also BCP0074) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3584) 3585 IPsec Configuration Policy Information Model. J. Jason, L. Rafalow, E. Vyncke. August 2003. (Format: TXT=187308 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3585) 3586 IP Security Policy (IPSP) Requirements. M. Blaze, A. Keromytis, M. Richardson, L. Sanchez. August 2003. (Format: TXT=22068 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3586) 3587 IPv6 Global Unicast Address Format. R. Hinden, S. Deering, E. Nordmark. August 2003. (Format: TXT=8783 bytes) (Obsoletes RFC2374) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3587) 3588 Diameter Base Protocol. P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko. September 2003. (Format: TXT=341261 bytes) (Obsoleted by RFC6733) (Updated by RFC5729, RFC5719, RFC6408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3588) 3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. J. Loughney. September 2003. (Format: TXT=8010 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3589) 3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol. B. Haberman. September 2003. (Format: TXT=11554 bytes) (Updates RFC2710) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3590) 3591 Definitions of Managed Objects for the Optical Interface Type. H-K. Lam, M. Stewart, A. Huynh. September 2003. (Format: TXT=310815 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3591) 3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type. K. Tesink. September 2003. (Format: TXT=143588 bytes) (Obsoletes RFC2558) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3592) 3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. K. Tesink, Ed.. September 2003. (Format: TXT=20363 bytes) (Obsoletes RFC2493) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3593) 3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option. P. Duffy. September 2003. (Format: TXT=12521 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3594) 3595 Textual Conventions for IPv6 Flow Label. B. Wijnen. September 2003. (Format: TXT=11746 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3595) 3596 DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant, M. Souissi. October 2003. (Format: TXT=14093 bytes) (Obsoletes RFC3152, RFC1886) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3596) 3597 Handling of Unknown DNS Resource Record (RR) Types. A. Gustafsson. September 2003. (Format: TXT=17559 bytes) (Updates RFC2163, RFC2535) (Updated by RFC4033, RFC4034, RFC4035, RFC5395, RFC6195, RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3597) 3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison. September 2003. (Format: TXT=11151 bytes) (Obsoleted by RFC5233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3598) 3599 Request for Comments Summary RFC Numbers 3500-3599. S. Ginoza. December 2003. (Format: TXT=76893 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3599) 3600 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. November 2003. (Format: TXT=134338 bytes) (Obsoletes RFC3300) (Obsoleted by RFC3700) (Status: HISTORIC) (DOI: 10.17487/RFC3600) 3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses. C. Allocchio. September 2003. (Format: TXT=18572 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3601) 3602 The AES-CBC Cipher Algorithm and Its Use with IPsec. S. Frankel, R. Glenn, S. Kelly. September 2003. (Format: TXT=30254 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3602) 3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture. W. Marshall, Ed., F. Andreasen, Ed.. October 2003. (Format: TXT=67509 bytes) (Obsoleted by RFC5503) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3603) 3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3). H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe. October 2003. (Format: TXT=30805 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3604) 3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). C. Huitema. October 2003. (Format: TXT=17270 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3605) 3606 Definitions of Supplemental Managed Objects for ATM Interface. F. Ly, M. Noto, A. Smith, E. Spiegel, K. Tesink. November 2003. (Format: TXT=183610 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3606) 3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool. M. Leech. September 2003. (Format: TXT=14526 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3607) 3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration. D. Willis, B. Hoeneisen. October 2003. (Format: TXT=35628 bytes) (Updated by RFC5630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3608) 3609 Tracing Requirements for Generic Tunnels. R. Bonica, K. Kompella, D. Meyer. September 2003. (Format: TXT=17859 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3609) 3610 Counter with CBC-MAC (CCM). D. Whiting, R. Housley, N. Ferguson. September 2003. (Format: TXT=64509 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3610) 3611 RTP Control Protocol Extended Reports (RTCP XR). T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed.. November 2003. (Format: TXT=126736 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3611) 3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP). A. Farrel. September 2003. (Format: TXT=35677 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3612) 3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE). R. Morgan, K. Hazelton. October 2003. (Format: TXT=14296 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3613) 3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG). J. Smith. September 2003. (Format: TXT=10457 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3614) 3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging. J. Gustin, A. Goyens. September 2003. (Format: TXT=7352 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3615) 3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA). F. Bellifemine, I. Constantinescu, S. Willmott. September 2003. (Format: TXT=13352 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3616) 3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP). E. Lear. October 2003. (Format: TXT=11848 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3617) 3618 Multicast Source Discovery Protocol (MSDP). B. Fenner, Ed., D. Meyer, Ed.. October 2003. (Format: TXT=42238 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3618) 3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1. S. Shah, M. Yip. October 2003. (Format: TXT=14440 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3619) 3620 The TUNNEL Profile. D. New. October 2003. (Format: TXT=35365 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3620) 3621 Power Ethernet MIB. A. Berger, D. Romascanu. December 2003. (Format: TXT=37294 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3621) 3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project. M. Mealling. February 2004. (Format: TXT=11432 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3622) 3623 Graceful OSPF Restart. J. Moy, P. Pillay-Esnault, A. Lindem. November 2003. (Format: TXT=38757 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3623) 3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package. B. Foster, D. Auerbach, F. Andreasen. November 2003. (Format: TXT=34391 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3624) 3625 The QCP File Format and Media Types for Speech Data. R. Gellens, H. Garudadri. September 2003. (Format: TXT=28603 bytes) (Updates RFC3555) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3625) 3626 Optimized Link State Routing Protocol (OLSR). T. Clausen, Ed., P. Jacquet, Ed.. October 2003. (Format: TXT=161265 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3626) 3627 Use of /127 Prefix Length Between Routers Considered Harmful. P. Savola. September 2003. (Format: TXT=12436 bytes) (Obsoleted by RFC6547) (Status: HISTORIC) (DOI: 10.17487/RFC3627) 3628 Policy Requirements for Time-Stamping Authorities (TSAs). D. Pinkas, N. Pope, J. Ross. November 2003. (Format: TXT=92941 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3628) 3629 UTF-8, a transformation format of ISO 10646. F. Yergeau. November 2003. (Format: TXT=33856 bytes) (Obsoletes RFC2279) (Also STD0063) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3629) 3630 Traffic Engineering (TE) Extensions to OSPF Version 2. D. Katz, K. Kompella, D. Yeung. September 2003. (Format: TXT=27717 bytes) (Updates RFC2370) (Updated by RFC4203, RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3630) 3631 Security Mechanisms for the Internet. S. Bellovin, Ed., J. Schiller, Ed., C. Kaufman, Ed.. December 2003. (Format: TXT=47064 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3631) 3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0. S. Hollenbeck, S. Veeramachaneni, S. Yalamanchilli. November 2003. (Format: TXT=13490 bytes) (Updates RFC2832) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3632) 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6. O. Troan, R. Droms. December 2003. (Format: TXT=45308 bytes) (Updated by RFC6603, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3633) 3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option. K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust. December 2003. (Format: TXT=13163 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3634) 3635 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick. September 2003. (Format: TXT=154476 bytes) (Obsoletes RFC2665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3635) 3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). J. Flick. September 2003. (Format: TXT=139990 bytes) (Obsoletes RFC2668, RFC1515) (Obsoleted by RFC4836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3636) 3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer. C.M. Heard, Ed.. September 2003. (Format: TXT=78785 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3637) 3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status. J. Flick, C. M. Heard. September 2003. (Format: TXT=8676 bytes) (Obsoletes RFC1643) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3638) 3639 Considerations on the use of a Service Identifier in Packet Headers. M. St. Johns, Ed., G. Huston, Ed., IAB. October 2003. (Format: TXT=15389 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3639) 3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams. J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric. November 2003. (Format: TXT=102606 bytes) (Updated by RFC5691) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3640) 3641 Generic String Encoding Rules (GSER) for ASN.1 Types. S. Legg. October 2003. (Format: TXT=34207 bytes) (Updated by RFC4792) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3641) 3642 Common Elements of Generic String Encoding Rules (GSER) Encodings. S. Legg. October 2003. (Format: TXT=27774 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3642) 3643 Fibre Channel (FC) Frame Encapsulation. R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar. December 2003. (Format: TXT=39980 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3643) 3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format: TXT=170150 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644) 3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG). S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall. October 2003. (Format: TXT=56162 bytes) (Updates RFC2845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3645) 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed.. December 2003. (Format: TXT=13312 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3646) 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. November 2003. (Format: TXT=228124 bytes) (Obsoletes RFC2527) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3647) 3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol. J. Whitehead, J. Reschke, Ed.. December 2003. (Format: TXT=57147 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3648) 3649 HighSpeed TCP for Large Congestion Windows. S. Floyd. December 2003. (Format: TXT=79801 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3649) 3650 Handle System Overview. S. Sun, L. Lannom, B. Boesch. November 2003. (Format: TXT=54927 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3650) 3651 Handle System Namespace and Service Definition. S. Sun, S. Reilly, L. Lannom. November 2003. (Format: TXT=104479 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3651) 3652 Handle System Protocol (ver 2.1) Specification. S. Sun, S. Reilly, L. Lannom, J. Petrone. November 2003. (Format: TXT=124380 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3652) 3653 XML-Signature XPath Filter 2.0. J. Boyer, M. Hughes, J. Reagle. December 2003. (Format: TXT=32258 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3653) 3654 Requirements for Separation of IP Control and Forwarding. H. Khosravi, Ed., T. Anderson, Ed.. November 2003. (Format: TXT=40418 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3654) 3655 Redefinition of DNS Authenticated Data (AD) bit. B. Wellington, O. Gudmundsson. November 2003. (Format: TXT=15646 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3655) 3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol. R. Siemborski. December 2003. (Format: TXT=35509 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3656) 3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS). S. Moriai, A. Kato. January 2004. (Format: TXT=26282 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3657) 3658 Delegation Signer (DS) Resource Record (RR). O. Gudmundsson. December 2003. (Format: TXT=42120 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3090, RFC3008, RFC2535, RFC1035) (Updated by RFC3755) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3658) 3659 Extensions to FTP. P. Hethmon. March 2007. (Format: TXT=137962 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3659) 3660 Basic Media Gateway Control Protocol (MGCP) Packages. B. Foster, F. Andreasen. December 2003. (Format: TXT=145147 bytes) (Updates RFC2705) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3660) 3661 Media Gateway Control Protocol (MGCP) Return Code Usage. B. Foster, C. Sivachelvan. December 2003. (Format: TXT=49898 bytes) (Updates RFC3435) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3661) 3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services. R. Bless, K. Nichols, K. Wehrle. December 2003. (Format: TXT=39029 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3662) 3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP). A. Newton. December 2003. (Format: TXT=42260 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3663) 3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE). P. Hoffman. January 2004. (Format: TXT=6711 bytes) (Obsoleted by RFC4434) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3664) 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT=163159 bytes) (Also BCP0075) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3665) 3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT=200478 bytes) (Also BCP0076) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3666) 3667 IETF Rights in Contributions. S. Bradner. February 2004. (Format: TXT=43297 bytes) (Obsoleted by RFC3978) (Updates RFC2026) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3667) 3668 Intellectual Property Rights in IETF Technology. S. Bradner. February 2004. (Format: TXT=41365 bytes) (Obsoleted by RFC3979) (Updates RFC2026, RFC2028) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3668) 3669 Guidelines for Working Groups on Intellectual Property Issues. S. Brim. February 2004. (Format: TXT=40946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3669) 3670 Information Model for Describing Network Device QoS Datapath Mechanisms. B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss. January 2004. (Format: TXT=221687 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3670) 3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT=17912 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3671) 3672 Subentries in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT=24447 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3672) 3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes. K. Zeilenga. December 2003. (Format: TXT=10003 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3673) 3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT=10282 bytes) (Obsoleted by RFC4512) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3674) 3675 .sex Considered Dangerous. D. Eastlake 3rd. February 2004. (Format: TXT=53211 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3675) 3676 The Text/Plain Format and DelSp Parameters. R. Gellens. February 2004. (Format: TXT=42441 bytes) (Obsoletes RFC2646) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3676) 3677 IETF ISOC Board of Trustee Appointment Procedures. L. Daigle, Ed., Internet Architecture Board. December 2003. (Format: TXT=13008 bytes) (Also BCP0077) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3677) 3678 Socket Interface Extensions for Multicast Source Filters. D. Thaler, B. Fenner, B. Quinn. January 2004. (Format: TXT=36320 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3678) 3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes. R. Droms. January 2004. (Format: TXT=13804 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3679) 3680 A Session Initiation Protocol (SIP) Event Package for Registrations. J. Rosenberg. March 2004. (Format: TXT=35403 bytes) (Updated by RFC6140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3680) 3681 Delegation of E.F.F.3.IP6.ARPA. R. Bush, R. Fink. January 2004. (Format: TXT=7137 bytes) (Also BCP0080) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3681) 3682 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer. February 2004. (Format: TXT=23321 bytes) (Obsoleted by RFC5082) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3682) 3683 A Practice for Revoking Posting Rights to IETF Mailing Lists. M. Rose. March 2004. (Format: TXT=15698 bytes) (Also BCP0083) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3683) 3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). R. Ogier, F. Templin, M. Lewis. February 2004. (Format: TXT=107963 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3684) 3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C. Daboo. February 2004. (Format: TXT=17436 bytes) (Obsoleted by RFC5235) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3685) 3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). R. Housley. January 2004. (Format: TXT=43777 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3686) 3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules. S. Legg. February 2004. (Format: TXT=96256 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3687) 3688 The IETF XML Registry. M. Mealling. January 2004. (Format: TXT=17325 bytes) (Also BCP0081) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3688) 3689 General Requirements for Emergency Telecommunication Service (ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT=21680 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3689) 3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT=13919 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3690) 3691 Internet Message Access Protocol (IMAP) UNSELECT command. A. Melnikov. February 2004. (Format: TXT=8436 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3691) 3692 Assigning Experimental and Testing Numbers Considered Useful. T. Narten. January 2004. (Format: TXT=15054 bytes) (Updates RFC2434) (Also BCP0082) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3692) 3693 Geopriv Requirements. J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. February 2004. (Format: TXT=68881 bytes) (Updated by RFC6280, RFC7459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3693) 3694 Threat Analysis of the Geopriv Protocol. M. Danley, D. Mulligan, J. Morris, J. Peterson. February 2004. (Format: TXT=44364 bytes) (Updated by RFC6280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3694) 3695 Compact Forward Error Correction (FEC) Schemes. M. Luby, L. Vicisano. February 2004. (Format: TXT=32012 bytes) (Obsoleted by RFC5445) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3695) 3696 Application Techniques for Checking and Transformation of Names. J. Klensin. February 2004. (Format: TXT=39238 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3696) 3697 IPv6 Flow Label Specification. J. Rajahalme, A. Conta, B. Carpenter, S. Deering. March 2004. (Format: TXT=21296 bytes) (Obsoleted by RFC6437) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3697) 3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules. K. Zeilenga, Ed.. February 2004. (Format: TXT=17562 bytes) (Updates RFC2798) (Updated by RFC4517) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3698) 3700 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. July 2004. (Format: TXT=148273 bytes) (Obsoletes RFC3600) (Obsoleted by RFC5000) (Status: HISTORIC) (DOI: 10.17487/RFC3700) 3701 6bone (IPv6 Testing Address Allocation) Phaseout. R. Fink, R. Hinden. March 2004. (Format: TXT=12019 bytes) (Obsoletes RFC2471) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3701) 3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP). J. Loughney, G. Camarillo. February 2004. (Format: TXT=31243 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3702) 3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema. J. Strassner, B. Moore, R. Moats, E. Ellesson. February 2004. (Format: TXT=142983 bytes) (Updated by RFC4104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3703) 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also BCP0084) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3704) 3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. B. Ray, R. Abbi. February 2004. (Format: TXT=24158 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3705) 3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers. G. Huang, S. Beaulieu, D. Rochefort. February 2004. (Format: TXT=30196 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3706) 3707 Cross Registry Internet Service Protocol (CRISP) Requirements. A. Newton. February 2004. (Format: TXT=52411 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3707) 3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions. E. Blanton, M. Allman. February 2004. (Format: TXT=20818 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3708) 3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates. S. Santesson, R. Housley, T. Freeman. February 2004. (Format: TXT=46453 bytes) (Updated by RFC6170) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3709) 3710 An IESG charter. H. Alvestrand. February 2004. (Format: TXT=24912 bytes) (Updated by RFC3932, RFC5742) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3710) 3711 The Secure Real-time Transport Protocol (SRTP). M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. March 2004. (Format: TXT=134270 bytes) (Updated by RFC5506, RFC6904) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3711) 3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services. P. Fleming, I. McDonald. February 2004. (Format: TXT=62301 bytes) (Obsoleted by RFC7612) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3712) 3713 A Description of the Camellia Encryption Algorithm. M. Matsui, J. Nakajima, S. Moriai. April 2004. (Format: TXT=25031 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3713) 3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet. S. Floyd, Ed., J. Kempf, Ed.. March 2004. (Format: TXT=81368 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3714) 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements. B. Aboba, W. Dixon. March 2004. (Format: TXT=43476 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3715) 3716 The IETF in the Large: Administration and Execution. IAB Advisory Committee. March 2004. (Format: TXT=91326 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3716) 3717 IP over Optical Networks: A Framework. B. Rajagopalan, J. Luciani, D. Awduche. March 2004. (Format: TXT=124421 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3717) 3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access. R. McGowan. February 2004. (Format: TXT=25865 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3718) 3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. February 2004. (Format: TXT=33941 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3719) 3720 Internet Small Computer Systems Interface (iSCSI). J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner. April 2004. (Format: TXT=578468 bytes) (Obsoleted by RFC7143) (Updated by RFC3980, RFC4850, RFC5048, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3720) 3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery. M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. April 2004. (Format: TXT=47564 bytes) (Updated by RFC7143) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3721) 3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names. M. Bakke. April 2004. (Format: TXT=14702 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3722) 3723 Securing Block Storage Protocols over IP. B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino. April 2004. (Format: TXT=171673 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3723) 3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture. J. Kempf, Ed., R. Austein, Ed., IAB. March 2004. (Format: TXT=37206 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3724) 3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP). J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo. April 2004. (Format: TXT=77308 bytes) (Also BCP0085) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3725) 3726 Requirements for Signaling Protocols. M. Brunner, Ed.. April 2004. (Format: TXT=98020 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3726) 3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules. S. Legg. February 2004. (Format: TXT=8297 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3727) 3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL). B. Ray, R. Abbi. February 2004. (Format: TXT=147232 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3728) 3729 Application Performance Measurement MIB. S. Waldbusser. March 2004. (Format: TXT=131354 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3729) 3730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. March 2004. (Format: TXT=134337 bytes) (Obsoleted by RFC4930) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3730) 3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. March 2004. (Format: TXT=92527 bytes) (Obsoleted by RFC4931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3731) 3732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. March 2004. (Format: TXT=57082 bytes) (Obsoleted by RFC4932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3732) 3733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. March 2004. (Format: TXT=83091 bytes) (Obsoleted by RFC4933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3733) 3734 Extensible Provisioning Protocol (EPP) Transport Over TCP. S. Hollenbeck. March 2004. (Format: TXT=19550 bytes) (Obsoleted by RFC4934) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3734) 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP). S. Hollenbeck. March 2004. (Format: TXT=27326 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3735) 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT=18510 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3736) 3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules. B. Wijnen, A. Bierman. April 2004. (Format: TXT=13127 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3737) 3738 Wave and Equation Based Rate Control (WEBRC) Building Block. M. Luby, V. Goyal. April 2004. (Format: TXT=82584 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3738) 3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile. S. Santesson, M. Nystrom, T. Polk. March 2004. (Format: TXT=67436 bytes) (Obsoletes RFC3039) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3739) 3740 The Multicast Group Security Architecture. T. Hardjono, B. Weis. March 2004. (Format: TXT=65531 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3740) 3741 Exclusive XML Canonicalization, Version 1.0. J. Boyer, D. Eastlake 3rd, J. Reagle. March 2004. (Format: TXT=35403 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3741) 3742 Limited Slow-Start for TCP with Large Congestion Windows. S. Floyd. March 2004. (Format: TXT=14840 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3742) 3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean. K. Konishi, K. Huang, H. Qian, Y. Ko. April 2004. (Format: TXT=74963 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3743) 3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol. G. Clemm, J. Reschke, E. Sedlar, J. Whitehead. May 2004. (Format: TXT=146623 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3744) 3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444). D. Singer, R. Clark, D. Lee. April 2004. (Format: TXT=31224 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3745) 3746 Forwarding and Control Element Separation (ForCES) Framework. L. Yang, R. Dantu, T. Anderson, R. Gopal. April 2004. (Format: TXT=98660 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3746) 3747 The Differentiated Services Configuration MIB. H. Hazewinkel, Ed., D. Partain, Ed.. April 2004. (Format: TXT=51659 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3747) 3748 Extensible Authentication Protocol (EAP). B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed.. June 2004. (Format: TXT=157994 bytes) (Obsoletes RFC2284) (Updated by RFC5247, RFC7057) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3748) 3749 Transport Layer Security Protocol Compression Methods. S. Hollenbeck. May 2004. (Format: TXT=16411 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3749) 3750 Unmanaged Networks IPv6 Transition Scenarios. C. Huitema, R. Austein, S. Satapati, R. van der Pol. April 2004. (Format: TXT=48153 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3750) 3751 Omniscience Protocol Requirements. S. Bradner. April 2004. (Format: TXT=20771 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3751) 3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios. A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno. April 2004. (Format: TXT=29481 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3752) 3753 Mobility Related Terminology. J. Manner, Ed., M. Kojo, Ed.. June 2004. (Format: TXT=74143 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3753) 3754 IP Multicast in Differentiated Services (DS) Networks. R. Bless, K. Wehrle. April 2004. (Format: TXT=86533 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3754) 3755 Legacy Resolver Compatibility for Delegation Signer (DS). S. Weiler. May 2004. (Format: TXT=19812 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3658, RFC2535) (Updated by RFC3757, RFC3845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3755) 3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats. P. Nikander, Ed., J. Kempf, E. Nordmark. May 2004. (Format: TXT=56674 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3756) 3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag. O. Kolkman, J. Schlyter, E. Lewis. April 2004. (Format: TXT=16868 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3755, RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3757) 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension. R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad. May 2004. (Format: TXT=50999 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3758) 3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples. L-E. Jonsson. April 2004. (Format: TXT=50168 bytes) (Updates RFC3095) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3759) 3760 Securely Available Credentials (SACRED) - Credential Server Framework. D. Gustafson, M. Just, M. Nystrom. April 2004. (Format: TXT=49910 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3760) 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM). P. Faltstrom, M. Mealling. April 2004. (Format: TXT=41559 bytes) (Obsoletes RFC2916) (Obsoleted by RFC6116, RFC6117) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3761) 3762 Telephone Number Mapping (ENUM) Service Registration for H.323. O. Levin. April 2004. (Format: TXT=8450 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3762) 3763 One-way Active Measurement Protocol (OWAMP) Requirements. S. Shalunov, B. Teitelbaum. April 2004. (Format: TXT=23360 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3763) 3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record. J. Peterson. April 2004. (Format: TXT=17604 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3764) 3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control. G. Huston. April 2004. (Format: TXT=16500 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3765) 3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys. H. Orman, P. Hoffman. April 2004. (Format: TXT=55939 bytes) (Also BCP0086) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3766) 3767 Securely Available Credentials Protocol. S. Farrell, Ed.. June 2004. (Format: TXT=49552 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3767) 3768 Virtual Router Redundancy Protocol (VRRP). R. Hinden, Ed.. April 2004. (Format: TXT=59969 bytes) (Obsoletes RFC2338) (Obsoleted by RFC5798) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3768) 3769 Requirements for IPv6 Prefix Delegation. S. Miyakawa, R. Droms. June 2004. (Format: TXT=10287 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3769) 3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN). R. Housley, T. Moore. May 2004. (Format: TXT=18635 bytes) (Obsoleted by RFC4334) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3770) 3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message. R. Harrison, K. Zeilenga. April 2004. (Format: TXT=17114 bytes) (Obsoleted by RFC4511, RFC4510) (Updates RFC2251) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3771) 3772 Point-to-Point Protocol (PPP) Vendor Protocol. J. Carlson, R. Winslow. May 2004. (Format: TXT=19846 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3772) 3773 High-Level Requirements for Internet Voice Mail. E. Candell. June 2004. (Format: TXT=19156 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3773) 3774 IETF Problem Statement. E. Davies, Ed.. May 2004. (Format: TXT=55172 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3774) 3775 Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT=393514 bytes) (Obsoleted by RFC6275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3775) 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. J. Arkko, V. Devarapalli, F. Dupont. June 2004. (Format: TXT=87076 bytes) (Updated by RFC4877) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3776) 3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin, Ed.. June 2004. (Format: TXT=76395 bytes) (Obsoletes RFC2727) (Obsoleted by RFC7437) (Updated by RFC5078, RFC5633, RFC5680, RFC6859) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3777) 3778 The application/pdf Media Type. E. Taft, J. Pravetz, S. Zilles, L. Masinter. May 2004. (Format: TXT=29891 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3778) 3779 X.509 Extensions for IP Addresses and AS Identifiers. C. Lynn, S. Kent, K. Seo. June 2004. (Format: TXT=60732 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3779) 3780 SMIng - Next Generation Structure of Management Information. F. Strauss, J. Schoenwaelder. May 2004. (Format: TXT=141049 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3780) 3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP). F. Strauss, J. Schoenwaelder. May 2004. (Format: TXT=112267 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3781) 3782 The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T. Henderson, A. Gurtov. April 2004. (Format: TXT=49603 bytes) (Obsoletes RFC2582) (Obsoleted by RFC6582) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3782) 3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI. M. Chadalapaka, R. Elliott. May 2004. (Format: TXT=32358 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3783) 3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE). H. Smit, T. Li. June 2004. (Format: TXT=27422 bytes) (Obsoleted by RFC5305) (Updated by RFC4205) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3784) 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric. F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp. May 2004. (Format: TXT=17475 bytes) (Also BCP0087) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3785) 3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit. A. Hermelin, S. Previdi, M. Shand. May 2004. (Format: TXT=29164 bytes) (Obsoleted by RFC5311) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3786) 3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. May 2004. (Format: TXT=25426 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3787) 3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols. J. Loughney, M. Tuexen, Ed., J. Pastor-Balbas. June 2004. (Format: TXT=27125 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3788) 3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT=22842 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3789) 3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents. C. Mickles, Ed., P. Nesser, II. June 2004. (Format: TXT=102694 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3790) 3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents. C. Olvera, P. Nesser, II. June 2004. (Format: TXT=27567 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3791) 3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT=46398 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3792) 3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT=11624 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3793) 3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT=60001 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3794) 3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents. R. Sofia, P. Nesser, II. June 2004. (Format: TXT=92584 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3795) 3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT=78400 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3796) 3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection. D. Eastlake 3rd. June 2004. (Format: TXT=39883 bytes) (Obsoletes RFC2777) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3797) 3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil, Ed.. May 2004. (Format: TXT=64049 bytes) (Obsoletes RFC2298) (Updates RFC3461, RFC2046) (Updated by RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3798) 3801 Voice Profile for Internet Mail - version 2 (VPIMv2). G. Vaudreuil, G. Parsons. June 2004. (Format: TXT=118122 bytes) (Obsoletes RFC2421, RFC2423) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3801) 3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration. G. Vaudreuil, G. Parsons. June 2004. (Format: TXT=11686 bytes) (Obsoletes RFC2422) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3802) 3803 Content Duration MIME Header Definition. G. Vaudreuil, G. Parsons. June 2004. (Format: TXT=8213 bytes) (Obsoletes RFC2424) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3803) 3804 Voice Profile for Internet Mail (VPIM) Addressing. G. Parsons. June 2004. (Format: TXT=26122 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3804) 3805 Printer MIB v2. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT=366952 bytes) (Obsoletes RFC1759) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3805) 3806 Printer Finishing MIB. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT=109654 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3806) 3807 V5.2-User Adaptation Layer (V5UA). E. Weilandt, N. Khanchandani, S. Rao. June 2004. (Format: TXT=49748 bytes) (Updates RFC3057) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3807) 3808 IANA Charset MIB. I. McDonald. June 2004. (Format: TXT=25245 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3808) 3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN). A. Nagarajan, Ed.. June 2004. (Format: TXT=60576 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3809) 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. (Format: TXT=153579 bytes) (Updates RFC2710) (Updated by RFC4604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3810) 3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management. T. Nadeau, Ed., J. Cucchiara, Ed.. June 2004. (Format: TXT=40353 bytes) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3811) 3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004. (Format: TXT=136475 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3812) 3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004. (Format: TXT=116120 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3813) 3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB). T. Nadeau, C. Srinivasan, A. Viswanathan. June 2004. (Format: TXT=87518 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3814) 3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP). J. Cucchiara, H. Sjostrand, J. Luciani. June 2004. (Format: TXT=215916 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3815) 3816 Definitions of Managed Objects for RObust Header Compression (ROHC). J. Quittek, M. Stiemerling, H. Hartenstein. June 2004. (Format: TXT=104947 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3816) 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE). W. Townsley, R. da Silva. June 2004. (Format: TXT=37765 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3817) 3818 IANA Considerations for the Point-to-Point Protocol (PPP). V. Schryver. June 2004. (Format: TXT=6321 bytes) (Also BCP0088) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3818) 3819 Advice for Internet Subnetwork Designers. P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. July 2004. (Format: TXT=152174 bytes) (Also BCP0089) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3819) 3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. June 2004. (Format: TXT=86374 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3820) 3821 Fibre Channel Over TCP/IP (FCIP). M. Rajagopal, E. Rodriguez, R. Weber. July 2004. (Format: TXT=165907 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3821) 3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2). D. Peterson. July 2004. (Format: TXT=22859 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3822) 3823 MIME Media Type for the Systems Biology Markup Language (SBML). B. Kovitz. June 2004. (Format: TXT=14577 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3823) 3824 Using E.164 numbers with the Session Initiation Protocol (SIP). J. Peterson, H. Liu, J. Yu, B. Campbell. June 2004. (Format: TXT=36535 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3824) 3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information. J. Polk, J. Schnizlein, M. Linsner. July 2004. (Format: TXT=31715 bytes) (Obsoleted by RFC6225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3825) 3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model. U. Blumenthal, F. Maino, K. McCloghrie. June 2004. (Format: TXT=32821 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3826) 3827 Additional Snoop Datalink Types. K. Sarcar. June 2004. (Format: TXT=6344 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3827) 3828 The Lightweight User Datagram Protocol (UDP-Lite). L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed.. July 2004. (Format: TXT=27193 bytes) (Updated by RFC6335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3828) 3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls. R. Weltman, M. Smith, M. Wahl. July 2004. (Format: TXT=11986 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3829) 3830 MIKEY: Multimedia Internet KEYing. J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman. August 2004. (Format: TXT=145238 bytes) (Updated by RFC4738, RFC6309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3830) 3831 Transmission of IPv6 Packets over Fibre Channel. C. DeSanti. July 2004. (Format: TXT=53328 bytes) (Obsoleted by RFC4338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3831) 3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV. W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. July 2004. (Format: TXT=15602 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3832) 3833 Threat Analysis of the Domain Name System (DNS). D. Atkins, R. Austein. August 2004. (Format: TXT=39303 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3833) 3834 Recommendations for Automatic Responses to Electronic Mail. K. Moore. August 2004. (Format: TXT=53119 bytes) (Updated by RFC5436) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3834) 3835 An Architecture for Open Pluggable Edge Services (OPES). A. Barbir, R. Penno, R. Chen, M. Hofmann, H. Orman. August 2004. (Format: TXT=36113 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3835) 3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols. A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis. August 2004. (Format: TXT=28438 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3836) 3837 Security Threats and Risks for Open Pluggable Edge Services (OPES). A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, H. Orman. August 2004. (Format: TXT=31883 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3837) 3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES). A. Barbir, O. Batuner, A. Beck, T. Chan, H. Orman. August 2004. (Format: TXT=38739 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3838) 3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files. R. Castagno, D. Singer. July 2004. (Format: TXT=15645 bytes) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3839) 3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, P. Kyzivat. August 2004. (Format: TXT=81360 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3840) 3841 Caller Preferences for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, P. Kyzivat. August 2004. (Format: TXT=61382 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3841) 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP). R. Mahy. August 2004. (Format: TXT=36877 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3842) 3843 RObust Header Compression (ROHC): A Compression Profile for IP. L-E. Jonsson, G. Pelletier. June 2004. (Format: TXT=33549 bytes) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3843) 3844 IETF Problem Resolution Process. E. Davies, Ed., J. Hofmann, Ed.. August 2004. (Format: TXT=44841 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3844) 3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. J. Schlyter, Ed.. August 2004. (Format: TXT=14793 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3755, RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3845) 3846 Mobile IPv4 Extension for Carrying Network Access Identifiers. F. Johansson, T. Johansson. June 2004. (Format: TXT=16834 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3846) 3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS). M. Shand, L. Ginsberg. July 2004. (Format: TXT=50023 bytes) (Obsoleted by RFC5306) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3847) 3848 ESMTP and LMTP Transmission Types Registration. C. Newman. July 2004. (Format: TXT=7916 bytes) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3848) 3849 IPv6 Address Prefix Reserved for Documentation. G. Huston, A. Lord, P. Smith. July 2004. (Format: TXT=7872 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3849) 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling. B. Ramsdell, Ed.. July 2004. (Format: TXT=37446 bytes) (Obsoletes RFC2632) (Obsoleted by RFC5750) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3850) 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. July 2004. (Format: TXT=53328 bytes) (Obsoletes RFC2633) (Obsoleted by RFC5751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3851) 3852 Cryptographic Message Syntax (CMS). R. Housley. July 2004. (Format: TXT=15541 bytes) (Obsoletes RFC3369) (Obsoleted by RFC5652) (Updated by RFC4853, RFC5083) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3852) 3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP). J. Peterson. July 2004. (Format: TXT=10687 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3853) 3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME). P. Hoffman, C. Bonatti, A. Eggen. July 2004. (Format: TXT=32801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3854) 3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400. P. Hoffman, C. Bonatti. July 2004. (Format: TXT=25774 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3855) 3856 A Presence Event Package for the Session Initiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT=62956 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3856) 3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT=46221 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3857) 3858 An Extensible Markup Language (XML) Based Format for Watcher Information. J. Rosenberg. August 2004. (Format: TXT=26416 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3858) 3859 Common Profile for Presence (CPP). J. Peterson. August 2004. (Format: TXT=30537 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3859) 3860 Common Profile for Instant Messaging (CPIM). J. Peterson. August 2004. (Format: TXT=26486 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3860) 3861 Address Resolution for Instant Messaging and Presence. J. Peterson. August 2004. (Format: TXT=15764 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3861) 3862 Common Presence and Instant Messaging (CPIM): Message Format. G. Klyne, D. Atkins. August 2004. (Format: TXT=56133 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3862) 3863 Presence Information Data Format (PIDF). H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson. August 2004. (Format: TXT=56956 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3863) 3864 Registration Procedures for Message Header Fields. G. Klyne, M. Nottingham, J. Mogul. September 2004. (Format: TXT=36231 bytes) (Also BCP0090) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3864) 3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension. C. Malamud. September 2004. (Format: TXT=40717 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3865) 3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga, Ed.. July 2004. (Format: TXT=31501 bytes) (Obsoletes RFC2596) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3866) 3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP). Y. Kawatsura, M. Hiroya, H. Beykirch. November 2004. (Format: TXT=234572 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3867) 3868 Signalling Connection Control Part User Adaptation Layer (SUA). J. Loughney, Ed., G. Sidebottom, L. Coene, G. Verwimp, J. Keller, B. Bidulock. October 2004. (Format: TXT=294116 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3868) 3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution. R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board. August 2004. (Format: TXT=78250 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3869) 3870 application/rdf+xml Media Type Registration. A. Swartz. September 2004. (Format: TXT=14195 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3870) 3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. September 2004. (Format: TXT=151101 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3871) 3872 Management Information Base for Telephony Routing over IP (TRIP). D. Zinman, D. Walker, J. Jiang. September 2004. (Format: TXT=98614 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3872) 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB). J. Pastor, M. Belinchon. September 2004. (Format: TXT=82403 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3873) 3874 A 224-bit One-way Hash Function: SHA-224. R. Housley. September 2004. (Format: TXT=11600 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3874) 3875 The Common Gateway Interface (CGI) Version 1.1. D. Robinson, K. Coar. October 2004. (Format: TXT=80728, PDF=121026 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3875) 3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3). D. Chadwick, S. Mullan. September 2004. (Format: TXT=24233 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3876) 3877 Alarm Management Information Base (MIB). S. Chisholm, D. Romascanu. September 2004. (Format: TXT=149783 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3877) 3878 Alarm Reporting Control Management Information Base (MIB). H. Lam, A. Huynh, D. Perkins. September 2004. (Format: TXT=31093 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3878) 3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. September 2004. (Format: TXT=24142 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3879) 3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services. J. Lennox, X. Wu, H. Schulzrinne. October 2004. (Format: TXT=154991 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3880) 3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications. G. Marshall. September 2004. (Format: TXT=86130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3881) 3882 Configuring BGP to Block Denial-of-Service Attacks. D. Turk. September 2004. (Format: TXT=19637 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3882) 3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC). S. Rao, A. Zinin, A. Roy. October 2004. (Format: TXT=13100 bytes) (Updates RFC1793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3883) 3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L. Eggert, Y. Wang. September 2004. (Format: TXT=59437 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3884) 3885 SMTP Service Extension for Message Tracking. E. Allman, T. Hansen. September 2004. (Format: TXT=17458 bytes) (Updates RFC3461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3885) 3886 An Extensible Message Format for Message Tracking Responses. E. Allman. September 2004. (Format: TXT=21746 bytes) (Updates RFC3463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3886) 3887 Message Tracking Query Protocol. T. Hansen. September 2004. (Format: TXT=42763 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3887) 3888 Message Tracking Model and Requirements. T. Hansen. September 2004. (Format: TXT=20950 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3888) 3889 Not Issued. 3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP). M. Westerlund. September 2004. (Format: TXT=49894 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3890) 3891 The Session Initiation Protocol (SIP) "Replaces" Header. R. Mahy, B. Biggs, R. Dean. September 2004. (Format: TXT=34180 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3891) 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism. R. Sparks. September 2004. (Format: TXT=52441 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3892) 3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format. J. Peterson. September 2004. (Format: TXT=28500 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3893) 3894 Sieve Extension: Copying Without Side Effects. J. Degener. October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3894) 3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types. O. Nicklass, Ed.. September 2004. (Format: TXT=163841 bytes) (Obsoletes RFC2495) (Obsoleted by RFC4805) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3895) 3896 Definitions of Managed Objects for the DS3/E3 Interface Type. O. Nicklass, Ed.. September 2004. (Format: TXT=129547 bytes) (Obsoletes RFC2496) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3896) 3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication. A. Barbir. September 2004. (Format: TXT=33890 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3897) 3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). V. Kalusivalingam. October 2004. (Format: TXT=13955 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3898) 3901 DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT=10025 bytes) (Also BCP0091) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3901) 3902 The "application/soap+xml" media type. M. Baker, M. Nottingham. September 2004. (Format: TXT=10575 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3902) 3903 Session Initiation Protocol (SIP) Extension for Event State Publication. A. Niemi, Ed.. October 2004. (Format: TXT=72062 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3903) 3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks. C. Huitema, R. Austein, S. Satapati, R. van der Pol. September 2004. (Format: TXT=46844 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3904) 3905 A Template for IETF Patent Disclosures and Licensing Declarations. V. See, Ed.. September 2004. (Format: TXT=16110 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3905) 3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels. N. Shen, H. Smit. October 2004. (Format: TXT=18410 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3906) 3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation. K. Zeilenga. October 2004. (Format: TXT=13423 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3909) 3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol. V. Gurbani, Ed., A. Brusilovsky, I. Faynberg, J. Gato, H. Lu, M. Unmehopa. October 2004. (Format: TXT=110515 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3910) 3911 The Session Initiation Protocol (SIP) "Join" Header. R. Mahy, D. Petrie. October 2004. (Format: TXT=35373 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3911) 3912 WHOIS Protocol Specification. L. Daigle. September 2004. (Format: TXT=7770 bytes) (Obsoletes RFC0954, RFC0812) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3912) 3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification. D. Thaler. September 2004. (Format: TXT=97443 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC3913) 3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations. A. Barbir, A. Rousskov. October 2004. (Format: TXT=37411 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3914) 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. September 2004. (Format: TXT=45467 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3915) 3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3). X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed.. September 2004. (Format: TXT=43856 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3916) 3917 Requirements for IP Flow Information Export (IPFIX). J. Quittek, T. Zseby, B. Claise, S. Zander. October 2004. (Format: TXT=81615 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3917) 3918 Methodology for IP Multicast Benchmarking. D. Stopp, B. Hickman. October 2004. (Format: TXT=64652 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3918) 3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS). E. Stephan, J. Palet. October 2004. (Format: TXT=14228 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3919) 3920 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre, Ed.. October 2004. (Format: TXT=194313 bytes) (Obsoleted by RFC6120) (Updated by RFC6122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3920) 3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. P. Saint-Andre, Ed.. October 2004. (Format: TXT=217527 bytes) (Obsoleted by RFC6121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3921) 3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM). P. Saint-Andre. October 2004. (Format: TXT=70790 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3922) 3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. October 2004. (Format: TXT=51828 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3923) 3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker, B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3924) 3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4). J. Littlefield. October 2004. (Format: TXT=17999 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3925) 3926 FLUTE - File Delivery over Unidirectional Transport. T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh. October 2004. (Format: TXT=81224 bytes) (Obsoleted by RFC6726) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3926) 3927 Dynamic Configuration of IPv4 Link-Local Addresses. S. Cheshire, B. Aboba, E. Guttman. May 2005. (Format: TXT=83102 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3927) 3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). R. Megginson, Ed., M. Smith, O. Natkovich, J. Parham. October 2004. (Format: TXT=36892 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3928) 3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF. T. Hardie. October 2004. (Format: TXT=26493 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3929) 3930 The Protocol versus Document Points of View in Computer Protocols. D. Eastlake 3rd. October 2004. (Format: TXT=36892 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3930) 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3). J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed.. March 2005. (Format: TXT=214407 bytes) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3931) 3932 The IESG and RFC Editor Documents: Procedures. H. Alvestrand. October 2004. (Format: TXT=17093 bytes) (Obsoleted by RFC5742) (Updates RFC2026, RFC3710) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3932) 3933 A Model for IETF Process Experiments. J. Klensin, S. Dawkins. November 2004. (Format: TXT=14409 bytes) (Also BCP0093) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3933) 3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists. M. Wasserman. October 2004. (Format: TXT=8488 bytes) (Updates RFC2418) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3934) 3935 A Mission Statement for the IETF. H. Alvestrand. October 2004. (Format: TXT=16639 bytes) (Also BCP0095) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3935) 3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP). K. Kompella, J. Lang. October 2004. (Format: TXT=15314 bytes) (Updates RFC3209, RFC2205) (Also BCP0096) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3936) 3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC). M. Steidl. October 2004. (Format: TXT=15458 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3937) 3938 Video-Message Message-Context. T. Hansen. October 2004. (Format: TXT=6224 bytes) (Updates RFC3458) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3938) 3939 Calling Line Identification for Voice Mail Messages. G. Parsons, J. Maruszak. December 2004. (Format: TXT=22739 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3939) 3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2004. (Format: TXT=220549 bytes) (Obsoleted by RFC5740) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3940) 3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2004. (Format: TXT=92785 bytes) (Obsoleted by RFC5401) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3941) 3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options. B. Volz. November 2004. (Format: TXT=13996 bytes) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3942) 3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS). R. Friend. November 2004. (Format: TXT=28942 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3943) 3944 H.350 Directory Services. T. Johnson, S. Okubo, S. Campos. December 2004. (Format: TXT=61160 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3944) 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture. E. Mannie, Ed.. October 2004. (Format: TXT=166700 bytes) (Updated by RFC6002) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3945) 3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. E. Mannie, D. Papadimitriou. October 2004. (Format: TXT=52205 bytes) (Obsoleted by RFC4606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3946) 3947 Negotiation of NAT-Traversal in the IKE. T. Kivinen, B. Swander, A. Huttunen, V. Volpe. January 2005. (Format: TXT=34759 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3947) 3948 UDP Encapsulation of IPsec ESP Packets. A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg. January 2005. (Format: TXT=30366 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3948) 3949 File Format for Internet Fax. R. Buckley, D. Venable, L. McIntyre, G. Parsons, J. Rafferty. February 2005. (Format: TXT=204903 bytes) (Obsoletes RFC2301) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3949) 3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration. L. McIntyre, G. Parsons, J. Rafferty. February 2005. (Format: TXT=13884 bytes) (Obsoletes RFC3250) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3950) 3951 Internet Low Bit Rate Codec (iLBC). S. Andersen, A. Duric, H. Astrom, R. Hagen, W. Kleijn, J. Linden. December 2004. (Format: TXT=373442 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3951) 3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech. A. Duric, S. Andersen. December 2004. (Format: TXT=28655 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3952) 3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services. J. Peterson. January 2005. (Format: TXT=13875 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3953) 3954 Cisco Systems NetFlow Services Export Version 9. B. Claise, Ed.. October 2004. (Format: TXT=76360 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3954) 3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX). S. Leinen. October 2004. (Format: TXT=55143 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3955) 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. (Format: TXT=40136 bytes) (Updates RFC3306) (Updated by RFC7371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3956) 3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4. C. Perkins, P. Calhoun. March 2005. (Format: TXT=63576 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3957) 3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS). L. Daigle, A. Newton. January 2005. (Format: TXT=54568 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3958) 3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT=22160 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3959) 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP). G. Camarillo, H. Schulzrinne. December 2004. (Format: TXT=31692 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3960) 3961 Encryption and Checksum Specifications for Kerberos 5. K. Raeburn. February 2005. (Format: TXT=111865 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3961) 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5. K. Raeburn. February 2005. (Format: TXT=32844 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3962) 3963 Network Mobility (NEMO) Basic Support Protocol. V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. January 2005. (Format: TXT=75955 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3963) 3964 Security Considerations for 6to4. P. Savola, C. Patel. December 2004. (Format: TXT=83360 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3964) 3965 A Simple Mode of Facsimile Using Internet Mail. K. Toyoda, H. Ohno, J. Murai, D. Wing. December 2004. (Format: TXT=28157 bytes) (Obsoletes RFC2305) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3965) 3966 The tel URI for Telephone Numbers. H. Schulzrinne. December 2004. (Format: TXT=40783 bytes) (Obsoletes RFC2806) (Updated by RFC5341) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3966) 3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level. R. Bush, T. Narten. December 2004. (Format: TXT=12251 bytes) (Updated by RFC4897) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3967) 3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT=20615 bytes) (Updates RFC3427) (Also BCP0098) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3968) 3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT=12119 bytes) (Updates RFC3427) (Updated by RFC5727) (Also BCP0099) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3969) 3970 A Traffic Engineering (TE) MIB. K. Kompella. January 2005. (Format: TXT=88833 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3970) 3971 SEcure Neighbor Discovery (SEND). J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander. March 2005. (Format: TXT=123372 bytes) (Updated by RFC6494, RFC6495, RFC6980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3971) 3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005. (Format: TXT=51473 bytes) (Updated by RFC4581, RFC4982) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3972) 3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). A. Adams, J. Nicholas, W. Siadak. January 2005. (Format: TXT=136708 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3973) 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments. M. Nakamura, J. Hagino. January 2005. (Format: TXT=22729 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3974) 3975 OMA-IETF Standardization Collaboration. G. Huston, Ed., I. Leuca, Ed.. January 2005. (Format: TXT=16926 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3975) 3976 Interworking SIP and Intelligent Network (IN) Applications. V. K. Gurbani, F. Haerens, V. Rastogi. January 2005. (Format: TXT=60191 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3976) 3977 Network News Transfer Protocol (NNTP). C. Feather. October 2006. (Format: TXT=247440 bytes) (Obsoletes RFC0977) (Updates RFC2980) (Updated by RFC6048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3977) 3978 IETF Rights in Contributions. S. Bradner, Ed.. March 2005. (Format: TXT=43574 bytes) (Obsoletes RFC3667) (Obsoleted by RFC5378) (Updates RFC2026) (Updated by RFC4748) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3978) 3979 Intellectual Property Rights in IETF Technology. S. Bradner, Ed.. March 2005. (Format: TXT=41366 bytes) (Obsoletes RFC3668) (Updates RFC2026, RFC2028) (Updated by RFC4879) (Also BCP0079) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3979) 3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names. M. Krueger, M. Chadalapaka, R. Elliott. February 2005. (Format: TXT=14056 bytes) (Obsoleted by RFC7143) (Updates RFC3720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3980) 3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol. A. Newton, M. Sanz. January 2005. (Format: TXT=101359 bytes) (Updated by RFC4992) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3981) 3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS). A. Newton, M. Sanz. January 2005. (Format: TXT=90901 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3982) 3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP). A. Newton, M. Sanz. January 2005. (Format: TXT=23466 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3983) 3984 RTP Payload Format for H.264 Video. S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer. February 2005. (Format: TXT=205093 bytes) (Obsoleted by RFC6184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3984) 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. S. Bryant, Ed., P. Pate, Ed.. March 2005. (Format: TXT=95062 bytes) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3985) 3986 Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. January 2005. (Format: TXT=141811 bytes) (Obsoletes RFC2732, RFC2396, RFC1808) (Updates RFC1738) (Updated by RFC6874, RFC7320) (Also STD0066) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3986) 3987 Internationalized Resource Identifiers (IRIs). M. Duerst, M. Suignard. January 2005. (Format: TXT=111190 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3987) 3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol. B. Black, K. Kompella. January 2005. (Format: TXT=18841 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3988) 3989 Middlebox Communications (MIDCOM) Protocol Semantics. M. Stiemerling, J. Quittek, T. Taylor. February 2005. (Format: TXT=160606 bytes) (Obsoleted by RFC5189) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3989) 3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement. B. O'Hara, P. Calhoun, J. Kempf. February 2005. (Format: TXT=11854 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3990) 3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package. B. Foster, F. Andreasen. February 2005. (Format: TXT=22951 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3991) 3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism. B. Foster, F. Andreasen. February 2005. (Format: TXT=9718 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3992) 3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. R. Johnson, T. Palaniappan, M. Stapp. March 2005. (Format: TXT=13938 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3993) 3994 Indication of Message Composition for Instant Messaging. H. Schulzrinne. January 2005. (Format: TXT=27472 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3994) 3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions. R. Herriot, T. Hastings. March 2005. (Format: TXT=223294 bytes) (Updates RFC2911, RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3995) 3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications. R. Herriot, T. Hastings, H. Lewis. March 2005. (Format: TXT=73638 bytes) (Updates RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3996) 3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications. T. Hastings, Ed., R. K. deBry, H. Lewis. March 2005. (Format: TXT=38185 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3997) 3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations. C. Kugler, H. Lewis, T. Hastings, Ed.. March 2005. (Format: TXT=109658 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3998) 4001 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. February 2005. (Format: TXT=45836 bytes) (Obsoletes RFC3291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4001) 4002 IANA Registration for Enumservice 'web' and 'ft'. R. Brandner, L. Conroy, R. Stastny. February 2005. (Format: TXT=18072 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4002) 4003 GMPLS Signaling Procedure for Egress Control. L. Berger. February 2005. (Format: TXT=10306 bytes) (Updates RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4003) 4004 Diameter Mobile IPv4 Application. P. Calhoun, T. Johansson, C. Perkins, T. Hiller, Ed., P. McCann. August 2005. (Format: TXT=128210 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4004) 4005 Diameter Network Access Server Application. P. Calhoun, G. Zorn, D. Spence, D. Mitton. August 2005. (Format: TXT=198871 bytes) (Obsoleted by RFC7155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4005) 4006 Diameter Credit-Control Application. H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney. August 2005. (Format: TXT=288794 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4006) 4007 IPv6 Scoped Address Architecture. S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. March 2005. (Format: TXT=53555 bytes) (Updated by RFC7346) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4007) 4008 Definitions of Managed Objects for Network Address Translators (NAT). R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, C. Wang. March 2005. (Format: TXT=125696 bytes) (Obsoleted by RFC7658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4008) 4009 The SEED Encryption Algorithm. J. Park, S. Lee, J. Kim, J. Lee. February 2005. (Format: TXT=32552 bytes) (Obsoleted by RFC4269) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4009) 4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Park, S. Lee, J. Kim, J. Lee. February 2005. (Format: TXT=22403 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4010) 4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal. March 2005. (Format: TXT=265942 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4011) 4012 Routing Policy Specification Language next generation (RPSLng). L. Blunk, J. Damas, F. Parent, A. Robachevsky. March 2005. (Format: TXT=35217 bytes) (Updates RFC2725, RFC2622) (Updated by RFC7909) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4012) 4013 SASLprep: Stringprep Profile for User Names and Passwords. K. Zeilenga. February 2005. (Format: TXT=13051 bytes) (Obsoleted by RFC7613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4013) 4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option. R. Droms, J. Schnizlein. February 2005. (Format: TXT=15416 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4014) 4015 The Eifel Response Algorithm for TCP. R. Ludwig, A. Gurtov. February 2005. (Format: TXT=31512 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4015) 4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements. M. Parthasarathy. March 2005. (Format: TXT=36104 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4016) 4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs. D. Stanley, J. Walker, B. Aboba. March 2005. (Format: TXT=22183 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4017) 4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2). M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry. April 2005. (Format: TXT=48498 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4018) 4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite. G. Pelletier. April 2005. (Format: TXT=46896 bytes) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4019) 4020 Early IANA Allocation of Standards Track Code Points. K. Kompella, A. Zinin. February 2005. (Format: TXT=13706 bytes) (Obsoleted by RFC7120) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4020) 4021 Registration of Mail and MIME Header Fields. G. Klyne, J. Palme. March 2005. (Format: TXT=75452 bytes) (Updated by RFC5322) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4021) 4022 Management Information Base for the Transmission Control Protocol (TCP). R. Raghunarayan, Ed.. March 2005. (Format: TXT=47360 bytes) (Obsoletes RFC2452, RFC2012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4022) 4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE). T. Worster, Y. Rekhter, E. Rosen, Ed.. March 2005. (Format: TXT=31696 bytes) (Updated by RFC5332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4023) 4024 Voice Messaging Client Behaviour. G. Parsons, J. Maruszak. July 2005. (Format: TXT=18560 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4024) 4025 A Method for Storing IPsec Keying Material in DNS. M. Richardson. March 2005. (Format: TXT=25408 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4025) 4026 Provider Provisioned Virtual Private Network (VPN) Terminology. L. Andersson, T. Madsen. March 2005. (Format: TXT=42124 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4026) 4027 Domain Name System Media Types. S. Josefsson. April 2005. (Format: TXT=11676 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4027) 4028 Session Timers in the Session Initiation Protocol (SIP). S. Donovan, J. Rosenberg. April 2005. (Format: TXT=65363 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4028) 4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks. M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. March 2005. (Format: TXT=64388 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4029) 4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. M. Stapp, T. Lemon. March 2005. (Format: TXT=34332 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4030) 4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). M. Carugi, Ed., D. McDysan, Ed.. April 2005. (Format: TXT=118568 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4031) 4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework. G. Camarillo, P. Kyzivat. March 2005. (Format: TXT=20492 bytes) (Updates RFC3312) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4032) 4033 DNS Security Introduction and Requirements. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=52445 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC6014, RFC6840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4033) 4034 Resource Records for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=63879 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC4470, RFC6014, RFC6840, RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4034) 4035 Protocol Modifications for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=130589 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC4470, RFC6014, RFC6840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4035) 4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management. W. Sawyer. April 2005. (Format: TXT=57946 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4036) 4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core. A. Rousskov. March 2005. (Format: TXT=131487 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4037) 4038 Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. March 2005. (Format: TXT=69727 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4038) 4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4). S. Park, P. Kim, B. Volz. March 2005. (Format: TXT=22297 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4039) 4040 RTP Payload Format for a 64 kbit/s Transparent Call. R. Kreuter. April 2005. (Format: TXT=15363 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4040) 4041 Requirements for Morality Sections in Routing Area Drafts. A. Farrel. April 2005. (Format: TXT=15249 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4041) 4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode. M. Crispin. April 2005. (Format: TXT=19123 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4042) 4043 Internet X.509 Public Key Infrastructure Permanent Identifier. D. Pinkas, T. Gindin. May 2005. (Format: TXT=30092 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4043) 4044 Fibre Channel Management MIB. K. McCloghrie. May 2005. (Format: TXT=127148 bytes) (Obsoletes RFC2837) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4044) 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP). G. Bourdon. April 2005. (Format: TXT=59140 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4045) 4046 Multicast Security (MSEC) Group Key Management Architecture. M. Baugher, R. Canetti, L. Dondeti, F. Lindholm. April 2005. (Format: TXT=97885 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4046) 4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS). S. Allen, D. Wells. April 2005. (Format: TXT=53737 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4047) 4048 RFC 1888 Is Obsolete. B. Carpenter. April 2005. (Format: TXT=7394 bytes) (Obsoletes RFC1888) (Updated by RFC4548) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4048) 4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1. R. Housley. April 2005. (Format: TXT=12302 bytes) (Obsoleted by RFC6019) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4049) 4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures. S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang. April 2005. (Format: TXT=35327 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4050) 4051 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2005. (Format: TXT=33368 bytes) (Obsoleted by RFC6931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4051) 4052 IAB Processes for Management of IETF Liaison Relationships. L. Daigle, Ed., Internet Architecture Board. April 2005. (Format: TXT=18360 bytes) (Also BCP0102) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4052) 4053 Procedures for Handling Liaison Statements to and from the IETF. S. Trowbridge, S. Bradner, F. Baker. April 2005. (Format: TXT=38816 bytes) (Also BCP0103) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4053) 4054 Impairments and Other Constraints on Optical Layer Routing. J. Strand, Ed., A. Chiu, Ed.. May 2005. (Format: TXT=73327 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4054) 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. J. Schaad, B. Kaliski, R. Housley. June 2005. (Format: TXT=57479 bytes) (Updates RFC3279) (Updated by RFC5756) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4055) 4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. June 2005. (Format: TXT=11514 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4056) 4057 IPv6 Enterprise Network Scenarios. J. Bound, Ed.. June 2005. (Format: TXT=33454 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4057) 4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements. A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang. May 2005. (Format: TXT=41957 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4058) 4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension. D. Linsenbardt, S. Pontius, A. Sturgeon. May 2005. (Format: TXT=17904 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4059) 4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding. Q. Xie, D. Pearce. May 2005. (Format: TXT=39654 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4060) 4061 Benchmarking Basic OSPF Single Router Control Plane Convergence. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT=32706 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4061) 4062 OSPF Benchmarking Terminology and Concepts. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT=15784 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4062) 4063 Considerations When Using Basic OSPF Convergence Benchmarks. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT=23401 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4063) 4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4. A. Patel, K. Leung. May 2005. (Format: TXT=20748 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4064) 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations. J. Kempf. July 2005. (Format: TXT=16179 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4065) 4066 Candidate Access Router Discovery (CARD). M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim. July 2005. (Format: TXT=116733 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4066) 4067 Context Transfer Protocol (CXTP). J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli. July 2005. (Format: TXT=77718 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4067) 4068 Fast Handovers for Mobile IPv6. R. Koodli, Ed.. July 2005. (Format: TXT=93591 bytes) (Obsoleted by RFC5268) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4068) 4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding. M. Dodge, B. Ray. May 2005. (Format: TXT=35712 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4069) 4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding. M. Dodge, B. Ray. May 2005. (Format: TXT=48561 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4070) 4071 Structure of the IETF Administrative Support Activity (IASA). R. Austein, Ed., B. Wijnen, Ed.. April 2005. (Format: TXT=48614 bytes) (Updated by RFC4371, RFC7691) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4071) 4072 Diameter Extensible Authentication Protocol (EAP) Application. P. Eronen, Ed., T. Hiller, G. Zorn. August 2005. (Format: TXT=79965 bytes) (Updated by RFC7268) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4072) 4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS). R. Housley. May 2005. (Format: TXT=17103 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4073) 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses. Y. Morishita, T. Jinmei. May 2005. (Format: TXT=13073 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4074) 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6. V. Kalusivalingam. May 2005. (Format: TXT=9424 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4075) 4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). T. Chown, S. Venaas, A. Vijayabhaskar. May 2005. (Format: TXT=15745 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4076) 4077 A Negative Acknowledgement Mechanism for Signaling Compression. A.B. Roach. May 2005. (Format: TXT=34250 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4077) 4078 The TV-Anytime Content Reference Identifier (CRID). N. Earnshaw, S. Aoki, A. Ashley, W. Kameyama. May 2005. (Format: TXT=21433 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4078) 4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects. J. Peterson. July 2005. (Format: TXT=16718 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4079) 4080 Next Steps in Signaling (NSIS): Framework. R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. June 2005. (Format: TXT=122470 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4080) 4081 Security Threats for Next Steps in Signaling (NSIS). H. Tschofenig, D. Kroeselberg. June 2005. (Format: TXT=67786 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4081) 4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction. A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. June 2005. (Format: TXT=54316 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4082) 4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP). M. Garcia-Martin. May 2005. (Format: TXT=80203 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4083) 4084 Terminology for Describing Internet Connectivity. J. Klensin. May 2005. (Format: TXT=24522 bytes) (Also BCP0104) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4084) 4085 Embedding Globally-Routable Internet Addresses Considered Harmful. D. Plonka. June 2005. (Format: TXT=22656 bytes) (Also BCP0105) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4085) 4086 Randomness Requirements for Security. D. Eastlake 3rd, J. Schiller, S. Crocker. June 2005. (Format: TXT=114321 bytes) (Obsoletes RFC1750) (Also BCP0106) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4086) 4087 IP Tunnel MIB. D. Thaler. June 2005. (Format: TXT=53206 bytes) (Obsoletes RFC2667) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4087) 4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP). D. Black, K. McCloghrie, J. Schoenwaelder. June 2005. (Format: TXT=43019 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4088) 4089 IAB and IESG Recommendation for IETF Administrative Restructuring. S. Hollenbeck, Ed., IAB and IESG. May 2005. (Format: TXT=128660 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4089) 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels. P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed.. May 2005. (Format: TXT=83965 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4090) 4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework. G. Camarillo, J. Rosenberg. June 2005. (Format: TXT=12931 bytes) (Obsoleted by RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4091) 4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP). G. Camarillo, J. Rosenberg. June 2005. (Format: TXT=12624 bytes) (Obsoleted by RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4092) 4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways. F. Adrangi, Ed., H. Levkowetz, Ed.. August 2005. (Format: TXT=44082 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4093) 4094 Analysis of Existing Quality-of-Service Signaling Protocols. J. Manner, X. Fu. May 2005. (Format: TXT=103146 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4094) 4095 Attaching Meaning to Solicitation Class Keywords. C. Malamud. May 2005. (Format: TXT=23539 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4095) 4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best. C. Malamud. May 2005. (Format: TXT=31618 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4096) 4097 Middlebox Communications (MIDCOM) Protocol Evaluation. M. Barnes, Ed.. June 2005. (Format: TXT=99303 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4097) 4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane. H. Berkowitz, E. Davies, Ed., S. Hares, P. Krishnaswamy, M. Lepp. June 2005. (Format: TXT=66845 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4098) 4101 Writing Protocol Models. E. Rescorla, IAB. June 2005. (Format: TXT=47287 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4101) 4102 Registration of the text/red MIME Sub-Type. P. Jones. June 2005. (Format: TXT=11337 bytes) (Updated by RFC6354) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4102) 4103 RTP Payload for Text Conversation. G. Hellstrom, P. Jones. June 2005. (Format: TXT=44246 bytes) (Obsoletes RFC2793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4103) 4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner. June 2005. (Format: TXT=190951 bytes) (Updates RFC3703) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4104) 4105 Requirements for Inter-Area MPLS Traffic Engineering. J.-L. Le Roux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed.. June 2005. (Format: TXT=50111 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4105) 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP). J. Viega, D. McGrew. June 2005. (Format: TXT=23399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4106) 4107 Guidelines for Cryptographic Key Management. S. Bellovin, R. Housley. June 2005. (Format: TXT=14752 bytes) (Also BCP0107) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4107) 4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages. R. Housley. August 2005. (Format: TXT=142060 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4108) 4109 Algorithms for Internet Key Exchange version 1 (IKEv1). P. Hoffman. May 2005. (Format: TXT=9491 bytes) (Updates RFC2409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4109) 4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). R. Callon, M. Suzuki. July 2005. (Format: TXT=204159 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4110) 4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs). L. Fang, Ed.. July 2005. (Format: TXT=106626 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4111) 4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification. D. Eastlake 3rd. June 2005. (Format: TXT=72537 bytes) (Updates RFC3106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4112) 4113 Management Information Base for the User Datagram Protocol (UDP). B. Fenner, J. Flick. June 2005. (Format: TXT=40323 bytes) (Obsoletes RFC2454, RFC2013) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4113) 4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. June 2005. (Format: TXT=31490 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4114) 4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic. O. Aboul-Magd, S. Rabie. July 2005. (Format: TXT=12131 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4115) 4116 IPv4 Multihoming Practices and Limitations. J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill. July 2005. (Format: TXT=26598 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4116) 4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc). G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk. June 2005. (Format: TXT=37951 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4117) 4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP). L. Yang, P. Zerfos, E. Sadot. June 2005. (Format: TXT=93695 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4118) 4119 A Presence-based GEOPRIV Location Object Format. J. Peterson. December 2005. (Format: TXT=53522 bytes) (Updated by RFC5139, RFC5491, RFC7459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4119) 4120 The Kerberos Network Authentication Service (V5). C. Neuman, T. Yu, S. Hartman, K. Raeburn. July 2005. (Format: TXT=340314 bytes) (Obsoletes RFC1510) (Updated by RFC4537, RFC5021, RFC5896, RFC6111, RFC6112, RFC6113, RFC6649, RFC6806, RFC7751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4120) 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. L. Zhu, K. Jaganathan, S. Hartman. July 2005. (Format: TXT=340314 bytes) (Updates RFC1964) (Updated by RFC6112, RFC6542, RFC6649) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4121) 4122 A Universally Unique IDentifier (UUID) URN Namespace. P. Leach, M. Mealling, R. Salz. July 2005. (Format: TXT=59319 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4122) 4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements. H. Schulzrinne, C. Agboh. July 2005. (Format: TXT=29244 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4123) 4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT=79265 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4124) 4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, W. Lai. June 2005. (Format: TXT=22585 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4125) 4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons. J. Ash. June 2005. (Format: TXT=51232 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4126) 4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT=23694 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4127) 4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation. W. Lai. June 2005. (Format: TXT=58691, PDF=201138 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4128) 4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol. R. Mukundan, K. Morneault, N. Mangalpally. September 2005. (Format: TXT=29034 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4129) 4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2). D. Moberg, R. Drummond. July 2005. (Format: TXT=99857 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4130) 4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus. S. Green, K. Ozawa, E. Cardona, Ed., A. Katsnelson. September 2005. (Format: TXT=183091 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4131) 4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS). S. Moriai, A. Kato, M. Kanda. July 2005. (Format: TXT=13590 bytes) (Obsoleted by RFC5932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4132) 4133 Entity MIB (Version 3). A. Bierman, K. McCloghrie. August 2005. (Format: TXT=136711 bytes) (Obsoletes RFC2737) (Obsoleted by RFC6933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4133) 4134 Examples of S/MIME Messages. P. Hoffman, Ed.. July 2005. (Format: TXT=325865 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4134) 4135 Goals of Detecting Network Attachment in IPv6. JH. Choi, G. Daley. August 2005. (Format: TXT=20518 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4135) 4136 OSPF Refresh and Flooding Reduction in Stable Topologies. P. Pillay-Esnault. July 2005. (Format: TXT=8534 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4136) 4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator. J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba. August 2005. (Format: TXT=105781, PDF=107470 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4137) 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP). P. Sarolahti, M. Kojo. August 2005. (Format: TXT=55538 bytes) (Updated by RFC5682) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4138) 4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON). D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong. July 2005. (Format: TXT=36660 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4139) 4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6). H. Soliman, C. Castelluccia, K. El Malki, L. Bellier. August 2005. (Format: TXT=71503 bytes) (Obsoleted by RFC5380) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4140) 4141 SMTP and MIME Extensions for Content Conversion. K. Toyoda, D. Crocker. November 2005. (Format: TXT=55606 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4141) 4142 Full-mode Fax Profile for Internet Mail (FFPIM). D. Crocker, G. Klyne. November 2005. (Format: TXT=16791 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4142) 4143 Facsimile Using Internet Mail (IFAX) Service of ENUM. K. Toyoda, D. Crocker. November 2005. (Format: TXT=8642 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4143) 4144 How to Gain Prominence and Influence in Standards Organizations. D. Eastlake 3rd. September 2005. (Format: TXT=19529 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4144) 4145 TCP-Based Media Transport in the Session Description Protocol (SDP). D. Yon, G. Camarillo. September 2005. (Format: TXT=30225 bytes) (Updated by RFC4572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4145) 4146 Simple New Mail Notification. R. Gellens. August 2005. (Format: TXT=8561 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4146) 4147 Proposed Changes to the Format of the IANA IPv6 Registry. G. Huston. August 2005. (Format: TXT=21196 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4147) 4148 IP Performance Metrics (IPPM) Metrics Registry. E. Stephan. August 2005. (Format: TXT=23074 bytes) (Obsoleted by RFC6248) (Also BCP0108) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4148) 4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms. C. Kalbfleisch, R. Cole, D. Romascanu. August 2005. (Format: TXT=78560 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4149) 4150 Transport Performance Metrics MIB. R. Dietz, R. Cole. August 2005. (Format: TXT=123144 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4150) 4151 The 'tag' URI Scheme. T. Kindberg, S. Hawke. October 2005. (Format: TXT=22555 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4151) 4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code. K. Tesink, R. Fox. August 2005. (Format: TXT=12228 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4152) 4153 XML Voucher: Generic Voucher Language. K. Fujimura, M. Terada, D. Eastlake 3rd. September 2005. (Format: TXT=41941 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4153) 4154 Voucher Trading System Application Programming Interface (VTS-API). M. Terada, K. Fujimura. September 2005. (Format: TXT=61629 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4154) 4155 The application/mbox Media Type. E. Hall. September 2005. (Format: TXT=19645 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4155) 4156 The wais URI Scheme. P. Hoffman. August 2005. (Format: TXT=6564 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4156) 4157 The prospero URI Scheme. P. Hoffman. August 2005. (Format: TXT=7096 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4157) 4158 Internet X.509 Public Key Infrastructure: Certification Path Building. M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas. September 2005. (Format: TXT=199297 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4158) 4159 Deprecation of "ip6.int". G. Huston. August 2005. (Format: TXT=5353 bytes) (Also BCP0109) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4159) 4160 Internet Fax Gateway Requirements. K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, C. Allocchio. August 2005. (Format: TXT=24930 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4160) 4161 Guidelines for Optional Services for Internet Fax Gateways. K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide. August 2005. (Format: TXT=23189 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4161) 4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS). H.J. Lee, J.H. Yoon, J.I. Lee. August 2005. (Format: TXT=10578 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4162) 4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression. L-E. Jonsson. August 2005. (Format: TXT=20587 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4163) 4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles. G. Pelletier. August 2005. (Format: TXT=47088 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4164) 4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA). T. George, B. Bidulock, R. Dantu, H. Schwarzbauer, K. Morneault. September 2005. (Format: TXT=114669 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4165) 4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement. L. Coene, J. Pastor-Balbas. February 2006. (Format: TXT=46659 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4166) 4167 Graceful OSPF Restart Implementation Report. A. Lindem. October 2005. (Format: TXT=11780 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4167) 4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, G. Camarillo. October 2005. (Format: TXT=21079 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4168) 4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2. V. Torvinen, J. Arkko, M. Naslund. November 2005. (Format: TXT=26429 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4169) 4170 Tunneling Multiplexed Compressed RTP (TCRTP). B. Thompson, T. Koren, D. Wing. November 2005. (Format: TXT=48990 bytes) (Also BCP0110) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4170) 4171 Internet Storage Name Service (iSNS). J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. Souza. September 2005. (Format: TXT=310636 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4171) 4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking. C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards. September 2005. (Format: TXT=241908 bytes) (Updated by RFC6172, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4172) 4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol. P. Sarkar, D. Missimer, C. Sapuntzakis. September 2005. (Format: TXT=27105 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4173) 4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service. C. Monia, J. Tseng, K. Gibbons. September 2005. (Format: TXT=29485 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4174) 4175 RTP Payload Format for Uncompressed Video. L. Gharai, C. Perkins. September 2005. (Format: TXT=39431 bytes) (Updated by RFC4421) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4175) 4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management. Y. El Mghazli, Ed., T. Nadeau, M. Boucadair, K. Chan, A. Gonguet. October 2005. (Format: TXT=46348 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4176) 4177 Architectural Approaches to Multi-homing for IPv6. G. Huston. September 2005. (Format: TXT=95374 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4177) 4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism. L. Zhu, P. Leach, K. Jaganathan, W. Ingersoll. October 2005. (Format: TXT=46485 bytes) (Obsoletes RFC2478) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4178) 4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN). S. Kang. October 2005. (Format: TXT=12935 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4179) 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files. Y. Shafranovich. October 2005. (Format: TXT=12931 bytes) (Updated by RFC7111) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4180) 4181 Guidelines for Authors and Reviewers of MIB Documents. C. Heard, Ed.. September 2005. (Format: TXT=102521 bytes) (Updated by RFC4841) (Also BCP0111) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4181) 4182 Removing a Restriction on the use of MPLS Explicit NULL. E. Rosen. September 2005. (Format: TXT=14087 bytes) (Updates RFC3032) (Updated by RFC5462, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4182) 4183 A Suggested Scheme for DNS Resolution of Networks and Gateways. E. Warnicke. September 2005. (Format: TXT=18357 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4183) 4184 RTP Payload Format for AC-3 Audio. B. Link, T. Hager, J. Flaks. October 2005. (Format: TXT=25202 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4184) 4185 National and Local Characters for DNS Top Level Domain (TLD) Names. J. Klensin. October 2005. (Format: TXT=50926 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4185) 4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM). H. Haverinen, Ed., J. Salowey, Ed.. January 2006. (Format: TXT=220807 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4186) 4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). J. Arkko, H. Haverinen. January 2006. (Format: TXT=194958 bytes) (Updated by RFC5448) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4187) 4188 Definitions of Managed Objects for Bridges. K. Norseth, Ed., E. Bell, Ed.. September 2005. (Format: TXT=86877 bytes) (Obsoletes RFC1493) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4188) 4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP). K. Ono, S. Tachimoto. October 2005. (Format: TXT=25842 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4189) 4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony. K. Carlberg, I. Brown, C. Beard. November 2005. (Format: TXT=69447 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4190) 4191 Default Router Preferences and More-Specific Routes. R. Draves, D. Thaler. November 2005. (Format: TXT=34672 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4191) 4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110 bytes) (Updates RFC2072) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4192) 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4193) 4194 The S Hexdump Format. J. Strombergson, L. Walleij, P. Faltstrom. October 2005. (Format: TXT=25727 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4194) 4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum. W. Kameyama. October 2005. (Format: TXT=10066 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4195) 4196 The SEED Cipher Algorithm and Its Use with IPsec. H.J. Lee, J.H. Yoon, S.L. Lee, J.I. Lee. October 2005. (Format: TXT=22587 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4196) 4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks. M. Riegel, Ed.. October 2005. (Format: TXT=47937 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4197) 4198 A Uniform Resource Name (URN) Namespace for Federated Content. D. Tessman. November 2005. (Format: TXT=12134 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4198) 4201 Link Bundling in MPLS Traffic Engineering (TE). K. Kompella, Y. Rekhter, L. Berger. October 2005. (Format: TXT=27033 bytes) (Updates RFC3471, RFC3472, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4201) 4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT=57333 bytes) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4202) 4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT=23130 bytes) (Updates RFC3630) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4203) 4204 Link Management Protocol (LMP). J. Lang, Ed.. October 2005. (Format: TXT=186515 bytes) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4204) 4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT=22323 bytes) (Obsoleted by RFC5307) (Updates RFC3784) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4205) 4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE). K. Kompella, Y. Rekhter. October 2005. (Format: TXT=31965 bytes) (Updated by RFC6001, RFC6107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4206) 4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages. J. Lang, D. Papadimitriou. October 2005. (Format: TXT=29390 bytes) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4207) 4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model. G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter. October 2005. (Format: TXT=28693 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4208) 4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems. A. Fredette, Ed., J. Lang, Ed.. October 2005. (Format: TXT=33906 bytes) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4209) 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP). C. Adams, S. Farrell, T. Kause, T. Mononen. September 2005. (Format: TXT=212013 bytes) (Obsoletes RFC2510) (Updated by RFC6712) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4210) 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF). J. Schaad. September 2005. (Format: TXT=86136 bytes) (Obsoletes RFC2511) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4211) 4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols. M. Blinov, C. Adams. October 2005. (Format: TXT=41757 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4212) 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4213) 4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin, T. Gleeson, M. Talwar, D. Thaler. October 2005. (Format: TXT=27811 bytes) (Obsoleted by RFC5214) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4214) 4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT=52903 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4215) 4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements. R. Zhang, Ed., J.-P. Vasseur, Ed.. November 2005. (Format: TXT=64640 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4216) 4217 Securing FTP with TLS. P. Ford-Hutchinson. October 2005. (Format: TXT=61180 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4217) 4218 Threats Relating to IPv6 Multihoming Solutions. E. Nordmark, T. Li. October 2005. (Format: TXT=75969 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4218) 4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About. E. Lear. October 2005. (Format: TXT=25141 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4219) 4220 Traffic Engineering Link Management Information Base. M. Dubuc, T. Nadeau, J. Lang. November 2005. (Format: TXT=104566 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4220) 4221 Multiprotocol Label Switching (MPLS) Management Overview. T. Nadeau, C. Srinivasan, A. Farrel. November 2005. (Format: TXT=70291 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4221) 4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance. G. Choudhury, Ed.. October 2005. (Format: TXT=34132 bytes) (Also BCP0112) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4222) 4223 Reclassification of RFC 1863 to Historic. P. Savola. October 2005. (Format: TXT=5123 bytes) (Obsoletes RFC1863) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4223) 4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets. G. Pelletier, L-E. Jonsson, K. Sandlund. January 2006. (Format: TXT=49416 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4224) 4225 Mobile IP Version 6 Route Optimization Security Design Background. P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark. December 2005. (Format: TXT=98584 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4225) 4226 HOTP: An HMAC-Based One-Time Password Algorithm. D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen. December 2005. (Format: TXT=77117 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4226) 4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP). E. O'Tuathail, M. Rose. January 2006. (Format: TXT=39112 bytes) (Obsoletes RFC3288) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4227) 4228 Requirements for an IETF Draft Submission Toolset. A. Rousskov. December 2005. (Format: TXT=76952 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4228) 4229 HTTP Header Field Registrations. M. Nottingham, J. Mogul. December 2005. (Format: TXT=70879 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4229) 4230 RSVP Security Properties. H. Tschofenig, R. Graveman. December 2005. (Format: TXT=121030 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4230) 4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. M. Nystrom. December 2005. (Format: TXT=17725 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4231) 4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. January 2006. (Format: TXT=157857 bytes) (Obsoletes RFC3057) (Updated by RFC5133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4233) 4234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. October 2005. (Format: TXT=26351 bytes) (Obsoletes RFC2234) (Obsoleted by RFC5234) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4234) 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, R. Mahy, Ed.. November 2005. (Format: TXT=83268 bytes) (Updated by RFC7463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4235) 4236 HTTP Adaptation with Open Pluggable Edge Services (OPES). A. Rousskov, M. Stecher. November 2005. (Format: TXT=53512 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4236) 4237 Voice Messaging Directory Service. G. Vaudreuil. October 2005. (Format: TXT=26093 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4237) 4238 Voice Message Routing Service. G. Vaudreuil. October 2005. (Format: TXT=18902 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4238) 4239 Internet Voice Messaging (IVM). S. McRae, G. Parsons. November 2005. (Format: TXT=24867 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4239) 4240 Basic Network Media Services with SIP. E. Burger, Ed., J. Van Dyke, A. Spitzer. December 2005. (Format: TXT=54976 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4240) 4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service. Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi. December 2005. (Format: TXT=20580 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4241) 4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). S. Venaas, T. Chown, B. Volz. November 2005. (Format: TXT=14759 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4242) 4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. M. Stapp, R. Johnson, T. Palaniappan. December 2005. (Format: TXT=14342 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4243) 4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information. M. Barnes, Ed.. November 2005. (Format: TXT=98992 bytes) (Obsoleted by RFC7044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4244) 4245 High-Level Requirements for Tightly Coupled SIP Conferencing. O. Levin, R. Even. November 2005. (Format: TXT=24415 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4245) 4246 International Standard Audiovisual Number (ISAN) URN Definition. M. Dolan. February 2006. (Format: TXT=10312 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4246) 4247 Requirements for Header Compression over MPLS. J. Ash, B. Goode, J. Hand, R. Zhang. November 2005. (Format: TXT=25127 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4247) 4248 The telnet URI Scheme. P. Hoffman. October 2005. (Format: TXT=7292 bytes) (Obsoletes RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4248) 4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components. B. Lilly. January 2006. (Format: TXT=28731 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4249) 4250 The Secure Shell (SSH) Protocol Assigned Numbers. S. Lehtinen, C. Lonvick, Ed.. January 2006. (Format: TXT=44010 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4250) 4251 The Secure Shell (SSH) Protocol Architecture. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT=71750 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4251) 4252 The Secure Shell (SSH) Authentication Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT=34268 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4252) 4253 The Secure Shell (SSH) Transport Layer Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT=68263 bytes) (Updated by RFC6668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4253) 4254 The Secure Shell (SSH) Connection Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT=50338 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4254) 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints. J. Schlyter, W. Griffin. January 2006. (Format: TXT=18399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4255) 4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH). F. Cusack, M. Forssen. January 2006. (Format: TXT=24728 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4256) 4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks. G. Bernstein, E. Mannie, V. Sharma, E. Gray. December 2005. (Format: TXT=86974 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4257) 4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON). D. Brungard, Ed.. November 2005. (Format: TXT=48558 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4258) 4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks. M.-J. Montpetit, G. Fairhurst, H. Clausen, B. Collini-Nocker, H. Linder. November 2005. (Format: TXT=100423 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4259) 4260 Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format: TXT=35276 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4260) 4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS). J. Walker, A. Kulkarni, Ed.. December 2005. (Format: TXT=28662 bytes) (Updates RFC2748) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4261) 4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities. S. Santesson. December 2005. (Format: TXT=9801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4262) 4263 Media Subtype Registration for Media Type text/troff. B. Lilly. January 2006. (Format: TXT=33371 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4263) 4264 BGP Wedgies. T. Griffin, G. Huston. November 2005. (Format: TXT=24139 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4264) 4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management. B. Schliesser, T. Nadeau. November 2005. (Format: TXT=10976 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4265) 4266 The gopher URI Scheme. P. Hoffman. November 2005. (Format: TXT=12083 bytes) (Obsoletes RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4266) 4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml. M. Froumentin. November 2005. (Format: TXT=17753 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4267) 4268 Entity State MIB. S. Chisholm, D. Perkins. November 2005. (Format: TXT=40348 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4268) 4269 The SEED Encryption Algorithm. H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee. December 2005. (Format: TXT=34390 bytes) (Obsoletes RFC4009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4269) 4270 Attacks on Cryptographic Hashes in Internet Protocols. P. Hoffman, B. Schneier. November 2005. (Format: TXT=26641 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4270) 4271 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.. January 2006. (Format: TXT=222702 bytes) (Obsoletes RFC1771) (Updated by RFC6286, RFC6608, RFC6793, RFC7606, RFC7607, RFC7705) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4271) 4272 BGP Security Vulnerabilities Analysis. S. Murphy. January 2006. (Format: TXT=53119 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4272) 4273 Definitions of Managed Objects for BGP-4. J. Haas, Ed., S. Hares, Ed.. January 2006. (Format: TXT=65629 bytes) (Obsoletes RFC1269, RFC1657) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4273) 4274 BGP-4 Protocol Analysis. D. Meyer, K. Patel. January 2006. (Format: TXT=38200 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4274) 4275 BGP-4 MIB Implementation Survey. S. Hares, D. Hares. January 2006. (Format: TXT=77598 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4275) 4276 BGP-4 Implementation Report. S. Hares, A. Retana. January 2006. (Format: TXT=132864 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4276) 4277 Experience with the BGP-4 Protocol. D. McPherson, K. Patel. January 2006. (Format: TXT=45117 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4277) 4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification. S. Bellovin, A. Zinin. January 2006. (Format: TXT=14483 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4278) 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4279) 4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers. K. Chowdhury, P. Yegani, L. Madour. November 2005. (Format: TXT=23001 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4280) 4281 The Codecs Parameter for "Bucket" Media Types. R. Gellens, D. Singer, P. Frojdh. November 2005. (Format: TXT=25529 bytes) (Obsoleted by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4281) 4282 The Network Access Identifier. B. Aboba, M. Beadles, J. Arkko, P. Eronen. December 2005. (Format: TXT=34421 bytes) (Obsoletes RFC2486) (Obsoleted by RFC7542) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4282) 4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT=14653 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4283) 4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP). F. Adrangi, V. Lortz, F. Bari, P. Eronen. January 2006. (Format: TXT=30322 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4284) 4285 Authentication Protocol for Mobile IPv6. A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. January 2006. (Format: TXT=40874 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4285) 4286 Multicast Router Discovery. B. Haberman, J. Martin. December 2005. (Format: TXT=35540 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4286) 4287 The Atom Syndication Format. M. Nottingham, Ed., R. Sayre, Ed.. December 2005. (Format: TXT=81922 bytes) (Updated by RFC5988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4287) 4288 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT=52667 bytes) (Obsoletes RFC2048) (Obsoleted by RFC6838) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4288) 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT=21502 bytes) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4289) 4290 Suggested Practices for Registration of Internationalized Domain Names (IDN). J. Klensin. December 2005. (Format: TXT=71115 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4290) 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Updated by RFC5952, RFC6052, RFC7136, RFC7346, RFC7371) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4291) 4292 IP Forwarding Table MIB. B. Haberman. April 2006. (Format: TXT=69321 bytes) (Obsoletes RFC2096) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4292) 4293 Management Information Base for the Internet Protocol (IP). S. Routhier, Ed.. April 2006. (Format: TXT=242243 bytes) (Obsoletes RFC2011, RFC2465, RFC2466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4293) 4294 IPv6 Node Requirements. J. Loughney, Ed.. April 2006. (Format: TXT=39125 bytes) (Obsoleted by RFC6434) (Updated by RFC5095) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4294) 4295 Mobile IPv6 Management Information Base. G. Keeni, K. Koide, K. Nagami, S. Gundavelli. April 2006. (Format: TXT=209038 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4295) 4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols. S. Bailey, T. Talpey. December 2005. (Format: TXT=43907 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4296) 4297 Remote Direct Memory Access (RDMA) over IP Problem Statement. A. Romanow, J. Mogul, T. Talpey, S. Bailey. December 2005. (Format: TXT=48514 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4297) 4298 RTP Payload Format for BroadVoice Speech Codecs. J.-H. Chen, W. Lee, J. Thyssen. December 2005. (Format: TXT=30099 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4298) 4301 Security Architecture for the Internet Protocol. S. Kent, K. Seo. December 2005. (Format: TXT=262123 bytes) (Obsoletes RFC2401) (Updates RFC3168) (Updated by RFC6040, RFC7619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4301) 4302 IP Authentication Header. S. Kent. December 2005. (Format: TXT=82328 bytes) (Obsoletes RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4302) 4303 IP Encapsulating Security Payload (ESP). S. Kent. December 2005. (Format: TXT=114315 bytes) (Obsoletes RFC2406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4303) 4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP). S. Kent. December 2005. (Format: TXT=9243 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4304) 4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). D. Eastlake 3rd. December 2005. (Format: TXT=17991 bytes) (Obsoletes RFC2402, RFC2406) (Obsoleted by RFC4835) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4305) 4306 Internet Key Exchange (IKEv2) Protocol. C. Kaufman, Ed.. December 2005. (Format: TXT=250941 bytes) (Obsoletes RFC2407, RFC2408, RFC2409) (Obsoleted by RFC5996) (Updated by RFC5282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4306) 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). J. Schiller. December 2005. (Format: TXT=12985 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4307) 4308 Cryptographic Suites for IPsec. P. Hoffman. December 2005. (Format: TXT=13127 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4308) 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP). R. Housley. December 2005. (Format: TXT=28998 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4309) 4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. December 2005. (Format: TXT=46326 bytes) (Obsoleted by RFC5910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4310) 4311 IPv6 Host-to-Router Load Sharing. R. Hinden, D. Thaler. November 2005. (Format: TXT=10156 bytes) (Updates RFC2461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4311) 4312 The Camellia Cipher Algorithm and Its Use With IPsec. A. Kato, S. Moriai, M. Kanda. December 2005. (Format: TXT=15980 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4312) 4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources. D. Oran. December 2005. (Format: TXT=46875 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4313) 4314 IMAP4 Access Control List (ACL) Extension. A. Melnikov. December 2005. (Format: TXT=56599 bytes) (Obsoletes RFC2086) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4314) 4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension. M. Crispin. December 2005. (Format: TXT=16629 bytes) (Obsoletes RFC2359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4315) 4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties. J. Reschke. December 2005. (Format: TXT=20352 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4316) 4317 Session Description Protocol (SDP) Offer/Answer Examples. A. Johnston, R. Sparks. December 2005. (Format: TXT=32262 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4317) 4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol. D. Levi, D. Harrington. December 2005. (Format: TXT=28124 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4318) 4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines. C. Sikes, B. Ray, R. Abbi. December 2005. (Format: TXT=146995 bytes) (Obsoletes RFC3276) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4319) 4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction. R. Sparks. January 2006. (Format: TXT=13853 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4320) 4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction. R. Sparks. January 2006. (Format: TXT=22708 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4321) 4322 Opportunistic Encryption using the Internet Key Exchange (IKE). M. Richardson, D.H. Redelmeier. December 2005. (Format: TXT=95453 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4322) 4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB). M. Patrick, W. Murwin. January 2006. (Format: TXT=197285 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4323) 4324 Calendar Access Protocol (CAP). D. Royer, G. Babics, S. Mansour. December 2005. (Format: TXT=254638 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4324) 4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension. S. Santesson, R. Housley. December 2005. (Format: TXT=14449 bytes) (Obsoleted by RFC5280) (Updates RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4325) 4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS). G. Fairhurst, B. Collini-Nocker. December 2005. (Format: TXT=95422 bytes) (Updated by RFC7280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4326) 4327 Link Management Protocol (LMP) Management Information Base (MIB). M. Dubuc, T. Nadeau, J. Lang, E. McGinnis. January 2006. (Format: TXT=150509 bytes) (Obsoleted by RFC4631) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4327) 4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control. D. Papadimitriou, Ed.. January 2006. (Format: TXT=52145 bytes) (Updates RFC3471) (Updated by RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4328) 4329 Scripting Media Types. B. Hoehrmann. April 2006. (Format: TXT=30230 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4329) 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. January 2006. (Format: TXT=67930 bytes) (Obsoletes RFC2030, RFC1769) (Obsoleted by RFC5905) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4330) 4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections. B. Korver, L. Dusseault. February 2006. (Format: TXT=19706 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4331) 4332 Cisco's Mobile IPv4 Host Configuration Extensions. K. Leung, A. Patel, G. Tsirtsis, E. Klovning. December 2005. (Format: TXT=19788 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4332) 4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process. G. Huston, Ed., B. Wijnen, Ed.. December 2005. (Format: TXT=15396 bytes) (Also BCP0113) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4333) 4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN). R. Housley, T. Moore. February 2006. (Format: TXT=20739 bytes) (Obsoletes RFC3770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4334) 4335 The Secure Shell (SSH) Session Channel Break Extension. J. Galbraith, P. Remaker. January 2006. (Format: TXT=11370 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4335) 4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP). S. Floyd, M. Handley, E. Kohler. March 2006. (Format: TXT=53585 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4336) 4337 MIME Type Registration for MPEG-4. Y Lim, D. Singer. March 2006. (Format: TXT=17290 bytes) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4337) 4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel. C. DeSanti, C. Carlson, R. Nixon. January 2006. (Format: TXT=75541 bytes) (Obsoletes RFC3831, RFC2625) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4338) 4339 IPv6 Host Configuration of DNS Server Information Approaches. J. Jeong, Ed.. February 2006. (Format: TXT=60803 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4339) 4340 Datagram Congestion Control Protocol (DCCP). E. Kohler, M. Handley, S. Floyd. March 2006. (Format: TXT=318830 bytes) (Updated by RFC5595, RFC5596, RFC6335, RFC6773) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4340) 4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control. S. Floyd, E. Kohler. March 2006. (Format: TXT=47868 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4341) 4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC). S. Floyd, E. Kohler, J. Padhye. March 2006. (Format: TXT=83054 bytes) (Updated by RFC5348, RFC6323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4342) 4343 Domain Name System (DNS) Case Insensitivity Clarification. D. Eastlake 3rd. January 2006. (Format: TXT=22899 bytes) (Updates RFC1034, RFC1035, RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4343) 4344 The Secure Shell (SSH) Transport Layer Encryption Modes. M. Bellare, T. Kohno, C. Namprempre. January 2006. (Format: TXT=27521 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4344) 4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol. B. Harris. January 2006. (Format: TXT=8967 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4345) 4346 The Transport Layer Security (TLS) Protocol Version 1.1. T. Dierks, E. Rescorla. April 2006. (Format: TXT=187041 bytes) (Obsoletes RFC2246) (Obsoleted by RFC5246) (Updated by RFC4366, RFC4680, RFC4681, RFC5746, RFC6176, RFC7465, RFC7507, RFC7919) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4346) 4347 Datagram Transport Layer Security. E. Rescorla, N. Modadugu. April 2006. (Format: TXT=56014 bytes) (Obsoleted by RFC6347) (Updated by RFC5746, RFC7507) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4347) 4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec. S. Ahmadi. January 2006. (Format: TXT=73528 bytes) (Updated by RFC4424) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4348) 4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3). C. Pignataro, M. Townsley. February 2006. (Format: TXT=22888 bytes) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4349) 4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government. F. Hendrikx, C. Wallis. February 2006. (Format: TXT=21111 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4350) 4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream. G. Hellstrom, P. Jones. January 2006. (Format: TXT=44405 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4351) 4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec. J. Sjoberg, M. Westerlund, A. Lakaniemi, S. Wenger. January 2006. (Format: TXT=91297 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4352) 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP). J. Rosenberg. February 2006. (Format: TXT=67405 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4353) 4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service. M. Garcia-Martin. January 2006. (Format: TXT=46847 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4354) 4355 IANA Registration for Enumservices email, fax, mms, ems, and sms. R. Brandner, L. Conroy, R. Stastny. January 2006. (Format: TXT=30218 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4355) 4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail. R. Gellens. January 2006. (Format: TXT=69427 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4356) 4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms. V. Popov, I. Kurepkin, S. Leontiev. January 2006. (Format: TXT=114564 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4357) 4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA). D. Smith. January 2006. (Format: TXT=11562 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4358) 4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH). B. Weis. January 2006. (Format: TXT=26989 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4359) 4360 BGP Extended Communities Attribute. S. Sangli, D. Tappan, Y. Rekhter. February 2006. (Format: TXT=24145 bytes) (Updated by RFC7153, RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4360) 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). T. Lemon, B. Sommerfeld. February 2006. (Format: TXT=28009 bytes) (Updates RFC2131, RFC2132, RFC3315) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4361) 4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP. L-E. Jonsson, G. Pelletier, K. Sandlund. January 2006. (Format: TXT=53926 bytes) (Obsoletes RFC3242) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4362) 4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions. D. Levi, D. Harrington. January 2006. (Format: TXT=188981 bytes) (Obsoletes RFC2674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4363) 4364 BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, Y. Rekhter. February 2006. (Format: TXT=116446 bytes) (Obsoletes RFC2547) (Updated by RFC4577, RFC4684, RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4364) 4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen. February 2006. (Format: TXT=77924 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4365) 4366 Transport Layer Security (TLS) Extensions. S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. April 2006. (Format: TXT=66344 bytes) (Obsoletes RFC3546) (Obsoleted by RFC5246, RFC6066) (Updates RFC4346) (Updated by RFC5746) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4366) 4367 What's in a Name: False Assumptions about DNS Names. J. Rosenberg, Ed., IAB. February 2006. (Format: TXT=41724 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4367) 4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition. T. Nadeau, S. Hegde. January 2006. (Format: TXT=43315 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4368) 4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP). K. Gibbons, C. Monia, J. Tseng, F. Travostino. January 2006. (Format: TXT=59354 bytes) (Obsoleted by RFC6173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4369) 4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control. R. Weltman. February 2006. (Format: TXT=10624 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4370) 4371 BCP 101 Update for IPR Trust. B. Carpenter, Ed., L. Lynch, Ed.. January 2006. (Format: TXT=6901 bytes) (Updates RFC4071) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4371) 4372 Chargeable User Identity. F. Adrangi, A. Lior, J. Korhonen, J. Loughney. January 2006. (Format: TXT=21555 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4372) 4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP). R. Harrison, J. Sermersheim, Y. Dong. January 2006. (Format: TXT=31091 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4373) 4374 The application/xv+xml Media Type. G. McCobb. January 2006. (Format: TXT=10308 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4374) 4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain. K. Carlberg. January 2006. (Format: TXT=17037 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4375) 4376 Requirements for Floor Control Protocols. P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu. February 2006. (Format: TXT=30021 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4376) 4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks. T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. Matsushima. February 2006. (Format: TXT=31889 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4377) 4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM). D. Allan, Ed., T. Nadeau, Ed.. February 2006. (Format: TXT=23640 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4378) 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. K. Kompella, G. Swallow. February 2006. (Format: TXT=116872 bytes) (Updates RFC1122) (Updated by RFC5462, RFC6424, RFC6425, RFC6426, RFC6829, RFC7506, RFC7537, RFC7743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4379) 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). C. Huitema. February 2006. (Format: TXT=132607 bytes) (Updated by RFC5991, RFC6081) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4380) 4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs). M. Behringer. February 2006. (Format: TXT=55200 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4381) 4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base. T. Nadeau, Ed., H. van der Linde, Ed.. February 2006. (Format: TXT=85594 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4382) 4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP). M. Baugher, E. Carrara. February 2006. (Format: TXT=41766 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4383) 4384 BGP Communities for Data Collection. D. Meyer. February 2006. (Format: TXT=26078 bytes) (Also BCP0114) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4384) 4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN. S. Bryant, G. Swallow, L. Martini, D. McPherson. February 2006. (Format: TXT=22440 bytes) (Updated by RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4385) 4386 Internet X.509 Public Key Infrastructure Repository Locator Service. S. Boeyen, P. Hallam-Baker. February 2006. (Format: TXT=11330 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4386) 4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP. P. Gutmann, Ed.. February 2006. (Format: TXT=63182 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4387) 4388 Dynamic Host Configuration Protocol (DHCP) Leasequery. R. Woundy, K. Kinnear. February 2006. (Format: TXT=63914 bytes) (Updated by RFC6148) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4388) 4389 Neighbor Discovery Proxies (ND Proxy). D. Thaler, M. Talwar, C. Patel. April 2006. (Format: TXT=38124 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4389) 4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand. V. Kashyap. April 2006. (Format: TXT=10754 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4390) 4391 Transmission of IP over InfiniBand (IPoIB). J. Chu, V. Kashyap. April 2006. (Format: TXT=45858 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4391) 4392 IP over InfiniBand (IPoIB) Architecture. V. Kashyap. April 2006. (Format: TXT=53506 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4392) 4393 MIME Type Registrations for 3GPP2 Multimedia Files. H. Garudadri. March 2006. (Format: TXT=14369 bytes) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4393) 4394 A Transport Network View of the Link Management Protocol (LMP). D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou. February 2006. (Format: TXT=40812 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4394) 4395 Guidelines and Registration Procedures for New URI Schemes. T. Hansen, T. Hardie, L. Masinter. February 2006. (Format: TXT=31933 bytes) (Obsoletes RFC2717, RFC2718) (Obsoleted by RFC7595) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4395) 4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text. J. Rey, Y. Matsui. February 2006. (Format: TXT=155421 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4396) 4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture. I. Bryskin, A. Farrel. February 2006. (Format: TXT=40331 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4397) 4398 Storing Certificates in the Domain Name System (DNS). S. Josefsson. March 2006. (Format: TXT=35652 bytes) (Obsoletes RFC2538) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4398) 4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API). N. Williams. February 2006. (Format: TXT=15272 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4401) 4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism. N. Williams. February 2006. (Format: TXT=9549 bytes) (Obsoleted by RFC7802) (Status: HISTORIC) (DOI: 10.17487/RFC4402) 4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3). B. Bergeson, K. Boogert, V. Nanjundaswamy. February 2006. (Format: TXT=78747 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4403) 4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP). R. Natarajan, A. Rijhsinghani. February 2006. (Format: TXT=60475 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4404) 4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message. E. Allman, H. Katz. April 2006. (Format: TXT=29429 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4405) 4406 Sender ID: Authenticating E-Mail. J. Lyon, M. Wong. April 2006. (Format: TXT=40428 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4406) 4407 Purported Responsible Address in E-Mail Messages. J. Lyon. April 2006. (Format: TXT=14387 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4407) 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1. M. Wong, W. Schlitt. April 2006. (Format: TXT=105009 bytes) (Obsoleted by RFC7208) (Updated by RFC6652) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4408) 4409 Message Submission for Mail. R. Gellens, J. Klensin. April 2006. (Format: TXT=34911 bytes) (Obsoletes RFC2476) (Obsoleted by RFC6409) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4409) 4410 Selectively Reliable Multicast Protocol (SRMP). M. Pullen, F. Zhao, D. Cohen. February 2006. (Format: TXT=65877 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4410) 4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events. J. Polk. February 2006. (Format: TXT=49260 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4411) 4412 Communications Resource Priority for the Session Initiation Protocol (SIP). H. Schulzrinne, J. Polk. February 2006. (Format: TXT=79193 bytes) (Updated by RFC7134) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4412) 4413 TCP/IP Field Behavior. M. West, S. McCann. March 2006. (Format: TXT=28435 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4413) 4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS). A. Newton. February 2006. (Format: TXT=89985 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4414) 4415 IANA Registration for Enumservice Voice. R. Brandner, L. Conroy, R. Stastny. February 2006. (Format: TXT=15956 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4415) 4416 Goals for Internet Messaging to Support Diverse Service Environments. J. Wong, Ed.. February 2006. (Format: TXT=93676 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4416) 4417 Report of the 2004 IAB Messaging Workshop. P. Resnick, Ed., P. Saint-Andre, Ed.. February 2006. (Format: TXT=47201 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4417) 4418 UMAC: Message Authentication Code using Universal Hashing. T. Krovetz, Ed.. March 2006. (Format: TXT=51304 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4418) 4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol. M. Friedl, N. Provos, W. Simpson. March 2006. (Format: TXT=18356 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4419) 4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). A. Farrel, Ed., D. Papadimitriou, J.-P. Vasseur, A. Ayyangar. February 2006. (Format: TXT=47235 bytes) (Obsoleted by RFC5420) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4420) 4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes. C. Perkins. February 2006. (Format: TXT=8000 bytes) (Updates RFC4175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4421) 4422 Simple Authentication and Security Layer (SASL). A. Melnikov, Ed., K. Zeilenga, Ed.. June 2006. (Format: TXT=73206 bytes) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4422) 4423 Host Identity Protocol (HIP) Architecture. R. Moskowitz, P. Nikander. May 2006. (Format: TXT=61049 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4423) 4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec. S. Ahmadi. February 2006. (Format: TXT=16331 bytes) (Updates RFC4348) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4424) 4425 RTP Payload Format for Video Codec 1 (VC-1). A. Klemets. February 2006. (Format: TXT=84335 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4425) 4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification. J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed.. March 2006. (Format: TXT=55820 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4426) 4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS). E. Mannie, Ed., D. Papadimitriou, Ed.. March 2006. (Format: TXT=43842 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4427) 4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration). D. Papadimitriou, Ed., E. Mannie, Ed.. March 2006. (Format: TXT=118749 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4428) 4429 Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format: TXT=33123 bytes) (Updated by RFC7527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4429) 4430 Kerberized Internet Negotiation of Keys (KINK). S. Sakane, K. Kamada, M. Thomas, J. Vilhuber. March 2006. (Format: TXT=91261 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4430) 4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record. M. Andrews, S. Weiler. February 2006. (Format: TXT=7861 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4431) 4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol. B. Harris. March 2006. (Format: TXT=16077 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4432) 4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment. M. Kulkarni, A. Patel, K. Leung. March 2006. (Format: TXT=55636 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4433) 4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE). P. Hoffman. February 2006. (Format: TXT=9384 bytes) (Obsoletes RFC3664) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4434) 4435 A Framework for the Usage of Internet Media Guides (IMGs). Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne. April 2006. (Format: TXT=51687 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4435) 4436 Detecting Network Attachment in IPv4 (DNAv4). B. Aboba, J. Carlson, S. Cheshire. March 2006. (Format: TXT=35991 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4436) 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources. J. Whitehead, G. Clemm, J. Reschke, Ed.. March 2006. (Format: TXT=49932 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4437) 4438 Fibre-Channel Name Server MIB. C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai. April 2006. (Format: TXT=70156 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4438) 4439 Fibre Channel Fabric Address Manager MIB. C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. March 2006. (Format: TXT=77153 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4439) 4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF). S. Floyd, Ed., V. Paxson, Ed., A. Falk, Ed., IAB. March 2006. (Format: TXT=29063 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4440) 4441 The IEEE 802/IETF Relationship. B. Aboba, Ed.. March 2006. (Format: TXT=49624 bytes) (Obsoleted by RFC7241) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4441) 4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA). S. Fries, H. Tschofenig. March 2006. (Format: TXT=37345 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4442) 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT=48969 bytes) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4443) 4444 Management Information Base for Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. April 2006. (Format: TXT=181968 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4444) 4445 A Proposed Media Delivery Index (MDI). J. Welch, J. Clark. April 2006. (Format: TXT=24171 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4445) 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3). L. Martini. April 2006. (Format: TXT=19782 bytes) (Also BCP0116) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4446) 4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). L. Martini, Ed., E. Rosen, N. El-Aawar, T. Smith, G. Heron. April 2006. (Format: TXT=76204 bytes) (Updated by RFC6723, RFC6870, RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4447) 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks. L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron. April 2006. (Format: TXT=49012 bytes) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4448) 4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key. C. Perkins. June 2006. (Format: TXT=15080 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4449) 4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents. E. Lear, H. Alvestrand. March 2006. (Format: TXT=23822 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4450) 4451 BGP MULTI_EXIT_DISC (MED) Considerations. D. McPherson, V. Gill. March 2006. (Format: TXT=28435 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4451) 4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces. H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel. April 2006. (Format: TXT=36408 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4452) 4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP). J. Rosenberg, G. Camarillo, Ed., D. Willis. April 2006. (Format: TXT=16833 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4453) 4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3). S. Singh, M. Townsley, C. Pignataro. May 2006. (Format: TXT=58281 bytes) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4454) 4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities. M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie. April 2006. (Format: TXT=178947 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4455) 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP). T. Bates, E. Chen, R. Chandra. April 2006. (Format: TXT=23209 bytes) (Obsoletes RFC2796, RFC1966) (Updated by RFC7606) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4456) 4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header). G. Camarillo, G. Blanco. April 2006. (Format: TXT=15884 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4457) 4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR). C. Jennings, F. Audet, J. Elwell. April 2006. (Format: TXT=41378 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4458) 4459 MTU and Fragmentation Issues with In-the-Network Tunneling. P. Savola. April 2006. (Format: TXT=32051 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4459) 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues. R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. April 2006. (Format: TXT=215405 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4460) 4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs). S. Yasukawa, Ed.. April 2006. (Format: TXT=64542 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4461) 4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol. J. Hutzelman, J. Salowey, J. Galbraith, V. Welch. May 2006. (Format: TXT=65280 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4462) 4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks. S. Shanmugham, P. Monaco, B. Eberman. April 2006. (Format: TXT=176385 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4463) 4464 Signaling Compression (SigComp) Users' Guide. A. Surtees, M. West. May 2006. (Format: TXT=79643 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4464) 4465 Signaling Compression (SigComp) Torture Tests. A. Surtees, M. West. June 2006. (Format: TXT=118772 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4465) 4466 Collected Extensions to IMAP4 ABNF. A. Melnikov, C. Daboo. April 2006. (Format: TXT=33752 bytes) (Updates RFC2088, RFC2342, RFC3501, RFC3502, RFC3516) (Updated by RFC6237, RFC7377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4466) 4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension. M. Crispin. May 2006. (Format: TXT=36714 bytes) (Updated by RFC5092, RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4467) 4468 Message Submission BURL Extension. C. Newman. May 2006. (Format: TXT=28614 bytes) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4468) 4469 Internet Message Access Protocol (IMAP) CATENATE Extension. P. Resnick. April 2006. (Format: TXT=21822 bytes) (Updates RFC3501, RFC3502) (Updated by RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4469) 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing. S. Weiler, J. Ihren. April 2006. (Format: TXT=17471 bytes) (Updates RFC4035, RFC4034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4470) 4471 Derivation of DNS Name Predecessor and Successor. G. Sisson, B. Laurie. September 2006. (Format: TXT=42430 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4471) 4472 Operational Considerations and Issues with IPv6 DNS. A. Durand, J. Ihren, P. Savola. April 2006. (Format: TXT=68882 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4472) 4473 Requirements for Internet Media Guides (IMGs). Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne. May 2006. (Format: TXT=53864 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4473) 4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP). J. Peterson, C. Jennings. August 2006. (Format: TXT=104952 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4474) 4475 Session Initiation Protocol (SIP) Torture Test Messages. R. Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H. Schulzrinne. May 2006. (Format: TXT=93276 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4475) 4476 Attribute Certificate (AC) Policies Extension. C. Francis, D. Pinkas. May 2006. (Format: TXT=20229 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4476) 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues. T. Chown, S. Venaas, C. Strauf. May 2006. (Format: TXT=30440 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4477) 4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol. Y. Nir. April 2006. (Format: TXT=10714 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4478) 4479 A Data Model for Presence. J. Rosenberg. July 2006. (Format: TXT=88399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4479) 4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF). H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg. July 2006. (Format: TXT=74026 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4480) 4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals. H. Schulzrinne. July 2006. (Format: TXT=15549 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4481) 4482 CIPID: Contact Information for the Presence Information Data Format. H. Schulzrinne. July 2006. (Format: TXT=22157 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4482) 4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages. E. Burger, Ed.. May 2006. (Format: TXT=36794 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4483) 4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP). J. Peterson, J. Polk, D. Sicker, H. Tschofenig. August 2006. (Format: TXT=37169 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4484) 4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne. May 2006. (Format: TXT=57278 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4485) 4486 Subcodes for BGP Cease Notification Message. E. Chen, V. Gillet. April 2006. (Format: TXT=10254 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4486) 4487 Mobile IPv6 and Firewalls: Problem Statement. F. Le, S. Faccin, B. Patil, H. Tschofenig. May 2006. (Format: TXT=32022 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4487) 4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription. O. Levin. May 2006. (Format: TXT=17264 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4488) 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses. J-S. Park, M-K. Shin, H-J. Kim. April 2006. (Format: TXT=12224 bytes) (Updates RFC3306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4489) 4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS). S. Leontiev, Ed., G. Chudov, Ed.. May 2006. (Format: TXT=54912 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4490) 4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S. Leontiev, Ed., D. Shefanovski, Ed.. May 2006. (Format: TXT=39095 bytes) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4491) 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS). S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller. May 2006. (Format: TXT=72231 bytes) (Updated by RFC5246, RFC7027, RFC7919) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4492) 4493 The AES-CMAC Algorithm. JH. Song, R. Poovendran, J. Lee, T. Iwata. June 2006. (Format: TXT=38751 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4493) 4494 The AES-CMAC-96 Algorithm and Its Use with IPsec. JH. Song, R. Poovendran, J. Lee. June 2006. (Format: TXT=14992 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4494) 4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow. J. Polk, S. Dhesikan. May 2006. (Format: TXT=44983 bytes) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4495) 4496 Open Pluggable Edge Services (OPES) SMTP Use Cases. M. Stecher, A. Barbir. May 2006. (Format: TXT=27403 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4496) 4497 Interworking between the Session Initiation Protocol (SIP) and QSIG. J. Elwell, F. Derks, P. Mourot, O. Rousseau. May 2006. (Format: TXT=149992 bytes) (Also BCP0117) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4497) 4498 The Managed Object Aggregation MIB. G. Keeni. May 2006. (Format: TXT=59214 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4498) 4501 Domain Name System Uniform Resource Identifiers. S. Josefsson. May 2006. (Format: TXT=20990 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4501) 4502 Remote Network Monitoring Management Information Base Version 2. S. Waldbusser. May 2006. (Format: TXT=290816 bytes) (Obsoletes RFC2021) (Updates RFC3273) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4502) 4503 A Description of the Rabbit Stream Cipher Algorithm. M. Boesgaard, M. Vesterager, E. Zenner. May 2006. (Format: TXT=22308 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4503) 4504 SIP Telephony Device Requirements and Configuration. H. Sinnreich, Ed., S. Lass, C. Stredicke. May 2006. (Format: TXT=84849 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4504) 4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga. June 2006. (Format: TXT=16599 bytes) (Obsoletes RFC2245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4505) 4506 XDR: External Data Representation Standard. M. Eisler, Ed.. May 2006. (Format: TXT=55477 bytes) (Obsoletes RFC1832) (Also STD0067) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4506) 4507 Transport Layer Security (TLS) Session Resumption without Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. May 2006. (Format: TXT=35329 bytes) (Obsoleted by RFC5077) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4507) 4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method. O. Levin, A. Johnston. May 2006. (Format: TXT=11338 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4508) 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs). W. Hardaker. May 2006. (Format: TXT=14155 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4509) 4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map. K. Zeilenga, Ed.. June 2006. (Format: TXT=12354 bytes) (Obsoletes RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830, RFC3377, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4510) 4511 Lightweight Directory Access Protocol (LDAP): The Protocol. J. Sermersheim, Ed.. June 2006. (Format: TXT=150116 bytes) (Obsoletes RFC2251, RFC2830, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4511) 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models. K. Zeilenga, Ed.. June 2006. (Format: TXT=108377 bytes) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4512) 4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms. R. Harrison, Ed.. June 2006. (Format: TXT=80546 bytes) (Obsoletes RFC2251, RFC2829, RFC2830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4513) 4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names. K. Zeilenga, Ed.. June 2006. (Format: TXT=31859 bytes) (Obsoletes RFC2253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4514) 4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters. M. Smith, Ed., T. Howes. June 2006. (Format: TXT=23885 bytes) (Obsoletes RFC2254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4515) 4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator. M. Smith, Ed., T. Howes. June 2006. (Format: TXT=30562 bytes) (Obsoletes RFC2255) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4516) 4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules. S. Legg, Ed.. June 2006. (Format: TXT=114285 bytes) (Obsoletes RFC2252, RFC2256) (Updates RFC3698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4517) 4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation. K. Zeilenga. June 2006. (Format: TXT=28166 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4518) 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications. A. Sciberras, Ed.. June 2006. (Format: TXT=64996 bytes) (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4519) 4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. June 2006. (Format: TXT=34298 bytes) (Obsoletes RFC3383) (Also BCP0064) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4520) 4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions. K. Zeilenga. June 2006. (Format: TXT=34585 bytes) (Also BCP0118) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4521) 4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option. S. Legg. June 2006. (Format: TXT=16276 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4522) 4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates. K. Zeilenga. June 2006. (Format: TXT=43753 bytes) (Obsoletes RFC2252, RFC2256, RFC2587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4523) 4524 COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format: TXT=11245 bytes) (Obsoletes RFC1274) (Updates RFC2247, RFC2798) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4524) 4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension. K. Zeilenga. June 2006. (Format: TXT=11251 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4525) 4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters. K. Zeilenga. June 2006. (Format: TXT=10097 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4526) 4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls. K. Zeilenga. June 2006. (Format: TXT=15987 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4527) 4528 Lightweight Directory Access Protocol (LDAP) Assertion Control. K. Zeilenga. June 2006. (Format: TXT=12539 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4528) 4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol. K. Zeilenga. June 2006. (Format: TXT=11927 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4529) 4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute. K. Zeilenga. June 2006. (Format: TXT=15191 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4530) 4531 Lightweight Directory Access Protocol (LDAP) Turn Operation. K. Zeilenga. June 2006. (Format: TXT=18986 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4531) 4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation. K. Zeilenga. June 2006. (Format: TXT=14247 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4532) 4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. K. Zeilenga, J.H. Choi. June 2006. (Format: TXT=73895 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4533) 4534 Group Security Policy Token v1. A Colegrove, H Harney. June 2006. (Format: TXT=54157 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4534) 4535 GSAKMP: Group Secure Association Key Management Protocol. H. Harney, U. Meth, A. Colegrove, G. Gross. June 2006. (Format: TXT=240863 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4535) 4536 The application/smil and application/smil+xml Media Types. P. Hoschka. July 2006. (Format: TXT=13747 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4536) 4537 Kerberos Cryptosystem Negotiation Extension. L. Zhu, P. Leach, K. Jaganathan. June 2006. (Format: TXT=11166 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4537) 4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP). J. Rosenberg. June 2006. (Format: TXT=36089 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4538) 4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). T. Edwards. May 2006. (Format: TXT=11950 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4539) 4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0. M. Stiemerling, J. Quittek, C. Cadar. May 2006. (Format: TXT=152685 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4540) 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches. M. Christensen, K. Kimball, F. Solensky. May 2006. (Format: TXT=38555 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4541) 4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite. F. Baker, J. Polk. May 2006. (Format: TXT=99770 bytes) (Updated by RFC5865) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4542) 4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH. D. McGrew, J. Viega. May 2006. (Format: TXT=29818 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4543) 4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI). M. Bakke, M. Krueger, T. McSweeney, J. Muchow. May 2006. (Format: TXT=156541 bytes) (Obsoleted by RFC7147) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4544) 4545 Definitions of Managed Objects for IP Storage User Identity Authorization. M. Bakke, J. Muchow. May 2006. (Format: TXT=87345 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4545) 4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces. D. Raftus, E. Cardona. June 2006. (Format: TXT=300844 bytes) (Obsoletes RFC2670) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4546) 4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems. A. Ahmad, G. Nakanishi. June 2006. (Format: TXT=83917 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4547) 4548 Internet Code Point (ICP) Assignments for NSAP Addresses. E. Gray, J. Rutemiller, G. Swallow. May 2006. (Format: TXT=17950 bytes) (Updates RFC1888, RFC4048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4548) 4549 Synchronization Operations for Disconnected IMAP4 Clients. A. Melnikov, Ed.. June 2006. (Format: TXT=75417 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4549) 4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile. S. Maes, A. Melnikov. June 2006. (Format: TXT=48790 bytes) (Obsoleted by RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4550) 4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization. A. Melnikov, S. Hole. June 2006. (Format: TXT=50265 bytes) (Obsoleted by RFC7162) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4551) 4552 Authentication/Confidentiality for OSPFv3. M. Gupta, N. Melam. June 2006. (Format: TXT=31540 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4552) 4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP). A. Vainshtein, Ed., YJ. Stein, Ed.. June 2006. (Format: TXT=58141 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4553) 4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks. T. Chown. June 2006. (Format: TXT=23355 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4554) 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE). P. Eronen. June 2006. (Format: TXT=78698 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4555) 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, B. Tung. June 2006. (Format: TXT=100339 bytes) (Updated by RFC6112) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4556) 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, K. Jaganathan, N. Williams. June 2006. (Format: TXT=11593 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4557) 4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement. Z. Ali, R. Rahman, D. Prairie, D. Papadimitriou. June 2006. (Format: TXT=14185 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4558) 4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. June 2006. (Format: TXT=16088 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4559) 4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. J. Quittek, Ed., K. White, Ed.. June 2006. (Format: TXT=207956 bytes) (Obsoletes RFC2925) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4560) 4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object. J.-P. Vasseur, Ed., Z. Ali, S. Sivabalan. June 2006. (Format: TXT=19362 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4561) 4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network. T. Melsen, S. Blake. June 2006. (Format: TXT=30332 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4562) 4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY). E. Carrara, V. Lehtovirta, K. Norrman. June 2006. (Format: TXT=20464 bytes) (Updated by RFC6309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4563) 4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP). S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang. July 2006. (Format: TXT=64576 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4564) 4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols. D. Loher, D. Nelson, O. Volinsky, B. Sarikaya. July 2006. (Format: TXT=62929 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4565) 4566 SDP: Session Description Protocol. M. Handley, V. Jacobson, C. Perkins. July 2006. (Format: TXT=108820 bytes) (Obsoletes RFC2327, RFC3266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4566) 4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP). J. Arkko, F. Lindholm, M. Naslund, K. Norrman, E. Carrara. July 2006. (Format: TXT=67693 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4567) 4568 Session Description Protocol (SDP) Security Descriptions for Media Streams. F. Andreasen, M. Baugher, D. Wing. July 2006. (Format: TXT=107881 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4568) 4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag. G. Camarillo. July 2006. (Format: TXT=6920 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4569) 4570 Session Description Protocol (SDP) Source Filters. B. Quinn, R. Finlayson. July 2006. (Format: TXT=28601 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4570) 4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport. J. Lazzaro. July 2006. (Format: TXT=18751 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4571) 4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP). J. Lennox. July 2006. (Format: TXT=38658 bytes) (Updates RFC4145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4572) 4573 MIME Type Registration for RTP Payload Format for H.224. R. Even, A. Lochbaum. July 2006. (Format: TXT=13587 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4573) 4574 The Session Description Protocol (SDP) Label Attribute. O. Levin, G. Camarillo. August 2006. (Format: TXT=13484 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4574) 4575 A Session Initiation Protocol (SIP) Event Package for Conference State. J. Rosenberg, H. Schulzrinne, O. Levin, Ed.. August 2006. (Format: TXT=97484 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4575) 4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P. Psenak, P. Pillay-Esnault. June 2006. (Format: TXT=15149 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4576) 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P. Psenak, P. Pillay-Esnault. June 2006. (Format: TXT=61515 bytes) (Updates RFC4364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4577) 4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE). M. Johnston, S. Venaas, Ed.. November 2006. (Format: TXT=13238 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4578) 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents. A. Johnston, O. Levin. August 2006. (Format: TXT=96506 bytes) (Also BCP0119) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4579) 4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option. B. Volz. June 2006. (Format: TXT=10937 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4580) 4581 Cryptographically Generated Addresses (CGA) Extension Field Format. M. Bagnulo, J. Arkko. October 2006. (Format: TXT=7636 bytes) (Updates RFC3972) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4581) 4582 The Binary Floor Control Protocol (BFCP). G. Camarillo, J. Ott, K. Drage. November 2006. (Format: TXT=154497 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4582) 4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams. G. Camarillo. November 2006. (Format: TXT=24150 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4583) 4584 Extension to Sockets API for Mobile IPv6. S. Chakrabarti, E. Nordmark. July 2006. (Format: TXT=53995 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4584) 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF). J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey. July 2006. (Format: TXT=117762 bytes) (Updated by RFC5506) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4585) 4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations. C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga. July 2006. (Format: TXT=66759 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4586) 4587 RTP Payload Format for H.261 Video Streams. R. Even. August 2006. (Format: TXT=37477 bytes) (Obsoletes RFC2032) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4587) 4588 RTP Retransmission Payload Format. J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg. July 2006. (Format: TXT=76630 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4588) 4589 Location Types Registry. H. Schulzrinne, H. Tschofenig. July 2006. (Format: TXT=24037 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4589) 4590 RADIUS Extension for Digest Authentication. B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. July 2006. (Format: TXT=67181 bytes) (Obsoleted by RFC5090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4590) 4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3). M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau. August 2006. (Format: TXT=28232 bytes) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4591) 4592 The Role of Wildcards in the Domain Name System. E. Lewis. July 2006. (Format: TXT=43991 bytes) (Updates RFC1034, RFC2672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4592) 4593 Generic Threats to Routing Protocols. A. Barbir, S. Murphy, Y. Yang. October 2006. (Format: TXT=48292 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4593) 4594 Configuration Guidelines for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes) (Updated by RFC5865) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4594) 4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol. F. Maino, D. Black. July 2006. (Format: TXT=32268 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4595) 4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension. J. Rosenberg, P. Kyzivat. July 2006. (Format: TXT=82954 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4596) 4597 Conferencing Scenarios. R. Even, N. Ismail. August 2006. (Format: TXT=38428 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4597) 4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio. B. Link. July 2006. (Format: TXT=39811 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4598) 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. August 2006. (Format: TXT=340632, PDF=304538 bytes) (Obsoletes RFC2362) (Obsoleted by RFC7761) (Updated by RFC5059, RFC5796, RFC6226) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4601) 4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis. T. Pusateri. August 2006. (Format: TXT=15310 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4602) 4603 Additional Values for the NAS-Port-Type Attribute. G. Zorn, G. Weber, R. Foltak. July 2006. (Format: TXT=7354 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4603) 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast. H. Holbrook, B. Cain, B. Haberman. August 2006. (Format: TXT=23370 bytes) (Updates RFC3376, RFC3810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4604) 4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"). B. Fenner, H. He, B. Haberman, H. Sandick. August 2006. (Format: TXT=25558 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4605) 4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. E. Mannie, D. Papadimitriou. August 2006. (Format: TXT=53492 bytes) (Obsoletes RFC3946) (Updated by RFC6344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4606) 4607 Source-Specific Multicast for IP. H. Holbrook, B. Cain. August 2006. (Format: TXT=42990 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4607) 4608 Source-Specific Protocol Independent Multicast in 232/8. D. Meyer, R. Rockell, G. Shepherd. August 2006. (Format: TXT=15030 bytes) (Also BCP0120) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4608) 4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements. P. Savola, R. Lehtonen, D. Meyer. October 2006. (Format: TXT=49812 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4609) 4610 Anycast-RP Using Protocol Independent Multicast (PIM). D. Farinacci, Y. Cai. August 2006. (Format: TXT=22490 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4610) 4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios. M. McBride, J. Meylor, D. Meyer. August 2006. (Format: TXT=33230 bytes) (Also BCP0121) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4611) 4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration. P. Jones, H. Tamura. August 2006. (Format: TXT=15675 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4612) 4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI). P. Frojdh, U. Lindgren, M. Westerlund. September 2006. (Format: TXT=12263 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4613) 4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents. M. Duke, R. Braden, W. Eddy, E. Blanton. September 2006. (Format: TXT=75645 bytes) (Obsoleted by RFC7414) (Updated by RFC6247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4614) 4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE). J. Song, R. Poovendran, J. Lee, T. Iwata. August 2006. (Format: TXT=13312 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4615) 4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga, Ed.. August 2006. (Format: TXT=20270 bytes) (Updates RFC2595) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4616) 4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project. J. Kornijenko. August 2006. (Format: TXT=12934 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4617) 4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks. L. Martini, E. Rosen, G. Heron, A. Malis. September 2006. (Format: TXT=33141 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4618) 4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks. L. Martini, Ed., C. Kawa, Ed., A. Malis, Ed.. September 2006. (Format: TXT=38193 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4619) 4620 IPv6 Node Information Queries. M. Crawford, B. Haberman, Ed.. August 2006. (Format: TXT=31134 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4620) 4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol. T. Kivinen, H. Tschofenig. August 2006. (Format: TXT=73070 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4621) 4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. July 2006. (Format: TXT=49968 bytes) (Obsoleted by RFC5122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4622) 4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly. A. Malis, M. Townsley. August 2006. (Format: TXT=36369 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4623) 4624 Multicast Source Discovery Protocol (MSDP) MIB. B. Fenner, D. Thaler. October 2006. (Format: TXT=58759 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4624) 4625 Fibre Channel Routing Information MIB. C. DeSanti, K. McCloghrie, S. Kode, S. Gai. September 2006. (Format: TXT=41278 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4625) 4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol. C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. September 2006. (Format: TXT=67953 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4626) 4627 The application/json Media Type for JavaScript Object Notation (JSON). D. Crockford. July 2006. (Format: TXT=16319 bytes) (Obsoleted by RFC7159) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4627) 4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status. R. Even. January 2007. (Format: TXT=8084 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4628) 4629 RTP Payload Format for ITU-T Rec. H.263 Video. J. Ott, C. Bormann, G. Sullivan, S. Wenger, R. Even, Ed.. January 2007. (Format: TXT=67231 bytes) (Obsoletes RFC2429) (Updates RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4629) 4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, S. Santesson. August 2006. (Format: TXT=12539 bytes) (Obsoleted by RFC5280) (Updates RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4630) 4631 Link Management Protocol (LMP) Management Information Base (MIB). M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel. September 2006. (Format: TXT=152560 bytes) (Obsoletes RFC4327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4631) 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT=66944 bytes) (Obsoletes RFC1519) (Also BCP0122) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4632) 4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists. S. Hartman. August 2006. (Format: TXT=14979 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4633) 4634 US Secure Hash Algorithms (SHA and HMAC-SHA). D. Eastlake 3rd, T. Hansen. July 2006. (Format: TXT=197147 bytes) (Obsoleted by RFC6234) (Updates RFC3174) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4634) 4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers. D. Eastlake 3rd. August 2006. (Format: TXT=16533 bytes) (Updates RFC2845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4635) 4636 Foreign Agent Error Extension for Mobile IPv4. C. Perkins. October 2006. (Format: TXT=11663 bytes) (Updates RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4636) 4637 Not Issued. 4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE). P. Arberg, D. Kourkouzelis, M. Duckett, T. Anschutz, J. Moisand. September 2006. (Format: TXT=18984 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4638) 4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems. R. Woundy, K. Marez. December 2006. (Format: TXT=188220 bytes) (Obsoletes RFC2669) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4639) 4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6). A. Patel, Ed., G. Giaretta, Ed.. September 2006. (Format: TXT=49926 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4640) 4641 DNSSEC Operational Practices. O. Kolkman, R. Gieben. September 2006. (Format: TXT=79894 bytes) (Obsoletes RFC2541) (Obsoleted by RFC6781) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4641) 4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP). K. Murchison, J. Vinocur, C. Newman. October 2006. (Format: TXT=29366 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4642) 4643 Network News Transfer Protocol (NNTP) Extension for Authentication. J. Vinocur, K. Murchison. October 2006. (Format: TXT=51411 bytes) (Updates RFC2980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4643) 4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds. J. Vinocur, K. Murchison. October 2006. (Format: TXT=26439 bytes) (Updates RFC2980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4644) 4645 Initial Language Subtag Registry. D. Ewell. September 2006. (Format: TXT=15517 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4645) 4646 Tags for Identifying Languages. A. Phillips, M. Davis. September 2006. (Format: TXT=135810 bytes) (Obsoletes RFC3066) (Obsoleted by RFC5646) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4646) 4647 Matching of Language Tags. A. Phillips, M. Davis. September 2006. (Format: TXT=45595 bytes) (Obsoletes RFC3066) (Also BCP0047) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4647) 4648 The Base16, Base32, and Base64 Data Encodings. S. Josefsson. October 2006. (Format: TXT=35491 bytes) (Obsoletes RFC3548) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4648) 4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option. B. Volz. August 2006. (Format: TXT=10940 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4649) 4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY). M. Euchner. September 2006. (Format: TXT=63016 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4650) 4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization. C. Vogt, J. Arkko. February 2007. (Format: TXT=79226 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4651) 4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements. D. Papadimitriou, Ed., L.Ong, J. Sadler, S. Shew, D. Ward. October 2006. (Format: TXT=47179 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4652) 4653 Improving the Robustness of TCP to Non-Congestion Events. S. Bhandarkar, A. L. N. Reddy, M. Allman, E. Blanton. August 2006. (Format: TXT=42268 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4653) 4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification. J. Widmer, M. Handley. August 2006. (Format: TXT=72190 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4654) 4655 A Path Computation Element (PCE)-Based Architecture. A. Farrel, J.-P. Vasseur, J. Ash. August 2006. (Format: TXT=97561 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4655) 4656 A One-way Active Measurement Protocol (OWAMP). S. Shalunov, B. Teitelbaum, A. Karp, J. Boote, M. Zekauskas. September 2006. (Format: TXT=132303 bytes) (Updated by RFC7717, RFC7718) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4656) 4657 Path Computation Element (PCE) Communication Protocol Generic Requirements. J. Ash, Ed., J.L. Le Roux, Ed.. September 2006. (Format: TXT=45284 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4657) 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN. J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. September 2006. (Format: TXT=42090 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4659) 4660 Functional Description of Event Notification Filtering. H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. September 2006. (Format: TXT=63886 bytes) (Updated by RFC6665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4660) 4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering. H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. September 2006. (Format: TXT=48890 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4661) 4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists. A. B. Roach, B. Campbell, J. Rosenberg. August 2006. (Format: TXT=82778 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4662) 4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG. D. Harrington. September 2006. (Format: TXT=47973 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4663) 4664 Framework for Layer 2 Virtual Private Networks (L2VPNs). L. Andersson, Ed., E. Rosen, Ed.. September 2006. (Format: TXT=97768 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4664) 4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks. W. Augustyn, Ed., Y. Serbest, Ed.. September 2006. (Format: TXT=68972 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4665) 4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA). K. Morneault, Ed., J. Pastor-Balbas, Ed.. September 2006. (Format: TXT=292991 bytes) (Obsoletes RFC3332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4666) 4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP). W. Luo. September 2006. (Format: TXT=33166 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4667) 4668 RADIUS Authentication Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT=48252 bytes) (Obsoletes RFC2618) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4668) 4669 RADIUS Authentication Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT=50525 bytes) (Obsoletes RFC2619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4669) 4670 RADIUS Accounting Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT=44667 bytes) (Obsoletes RFC2620) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4670) 4671 RADIUS Accounting Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT=47694 bytes) (Obsoletes RFC2621) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4671) 4672 RADIUS Dynamic Authorization Client MIB. S. De Cnodder, N. Jonnala, M. Chiba. September 2006. (Format: TXT=50817 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4672) 4673 RADIUS Dynamic Authorization Server MIB. S. De Cnodder, N. Jonnala, M. Chiba. September 2006. (Format: TXT=47635 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4673) 4674 Requirements for Path Computation Element (PCE) Discovery. J.L. Le Roux, Ed.. October 2006. (Format: TXT=40321 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4674) 4675 RADIUS Attributes for Virtual LAN and Priority Support. P. Congdon, M. Sanchez, B. Aboba. September 2006. (Format: TXT=29751 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4675) 4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. October 2006. (Format: TXT=45208 bytes) (Obsoleted by RFC4776) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4676) 4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force. P. Hoffman, S. Harris. September 2006. (Format: TXT=127383 bytes) (Obsoletes RFC3160) (Obsoleted by RFC6722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4677) 4678 Server/Application State Protocol v1. A. Bivens. September 2006. (Format: TXT=102713 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4678) 4679 DSL Forum Vendor-Specific RADIUS Attributes. V. Mammoliti, G. Zorn, P. Arberg, R. Rennison. September 2006. (Format: TXT=42743 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4679) 4680 TLS Handshake Message for Supplemental Data. S. Santesson. October 2006. (Format: TXT=15602 bytes) (Updates RFC4346) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4680) 4681 TLS User Mapping Extension. S. Santesson, A. Medvinsky, J. Ball. October 2006. (Format: TXT=20682 bytes) (Updates RFC4346) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4681) 4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices. E. Nechamkin, J-F. Mule. December 2006. (Format: TXT=137373 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4682) 4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM). J. Park, J. Lee, H.. Lee, S. Park, T. Polk. October 2006. (Format: TXT=41285 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4683) 4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs). P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. November 2006. (Format: TXT=28474 bytes) (Updates RFC4364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4684) 4685 Atom Threading Extensions. J. Snell. September 2006. (Format: TXT=24403 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4685) 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM). J. Fenton. September 2006. (Format: TXT=70382 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4686) 4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks. S. Yasukawa, A. Farrel, D. King, T. Nadeau. September 2006. (Format: TXT=30486 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4687) 4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. S. Rushing. October 2006. (Format: TXT=13255 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4688) 4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms. S. Poretsky, J. Perser, S. Erramilli, S. Khurana. October 2006. (Format: TXT=62369 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4689) 4690 Review and Recommendations for Internationalized Domain Names (IDNs). J. Klensin, P. Faltstrom, C. Karp, IAB. September 2006. (Format: TXT=100929 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4690) 4691 Guidelines for Acting as an IETF Liaison to Another Organization. L. Andersson, Ed.. October 2006. (Format: TXT=33888 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4691) 4692 Considerations on the IPv6 Host Density Metric. G. Huston. October 2006. (Format: TXT=41357 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4692) 4693 IETF Operational Notes. H. Alvestrand. October 2006. (Format: TXT=19268 bytes) (Obsoleted by RFC6393) (Status: HISTORIC) (DOI: 10.17487/RFC4693) 4694 Number Portability Parameters for the "tel" URI. J. Yu. October 2006. (Format: TXT=36910 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4694) 4695 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT=403808 bytes) (Obsoleted by RFC6295) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4695) 4696 An Implementation Guide for RTP MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT=83827 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4696) 4697 Observed DNS Resolution Misbehavior. M. Larson, P. Barber. October 2006. (Format: TXT=45187 bytes) (Also BCP0123) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4697) 4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service. E. Gunduz, A. Newton, S. Kerr. October 2006. (Format: TXT=89932 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4698) 4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR). M. Stapp, T. Lemon, A. Gustafsson. October 2006. (Format: TXT=24570 bytes) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4701) 4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option. M. Stapp, B. Volz, Y. Rekhter. October 2006. (Format: TXT=37534 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4702) 4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients. M. Stapp, B. Volz. October 2006. (Format: TXT=29690 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4703) 4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option. B. Volz. October 2006. (Format: TXT=32359 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4704) 4705 GigaBeam High-Speed Radio Link Encryption. R. Housley, A. Corry. October 2006. (Format: TXT=30926 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4705) 4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2). M. Morgenstern, M. Dodge, S. Baillie, U. Bonollo. November 2006. (Format: TXT=347648 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4706) 4707 Netnews Administration System (NAS). P. Grau, V. Heinau, H. Schlichting, R. Schuettler. October 2006. (Format: TXT=86510 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4707) 4708 CellML Media Type. A. Miller. October 2006. (Format: TXT=13217 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4708) 4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers. J. Reschke. October 2006. (Format: TXT=23672 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4709) 4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework. A. Siddiqui, D. Romascanu, E. Golovinsky. October 2006. (Format: TXT=86403 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4710) 4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB. A. Siddiqui, D. Romascanu, E. Golovinsky. October 2006. (Format: TXT=77341 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4711) 4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU). A. Siddiqui, D. Romascanu, E. Golovinsky, M. Rahman,Y. Kim. October 2006. (Format: TXT=109407 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4712) 4713 Registration and Administration Recommendations for Chinese Domain Names. X. Lee, W. Mao, E. Chen, N. Hsu, J. Klensin. October 2006. (Format: TXT=18883 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4713) 4714 Requirements for IETF Technical Publication Service. A. Mankin, S. Hayes. October 2006. (Format: TXT=53988 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4714) 4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI. M. Munakata, S. Schubert, T. Ohba. November 2006. (Format: TXT=28910 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4715) 4716 The Secure Shell (SSH) Public Key File Format. J. Galbraith, R. Thayer. November 2006. (Format: TXT=18395 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4716) 4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks. L. Martini, J. Jayakumar, M. Bocci, N. El-Aawar, J. Brayley, G. Koleyni. December 2006. (Format: TXT=86173 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4717) 4718 IKEv2 Clarifications and Implementation Guidelines. P. Eronen, P. Hoffman. October 2006. (Format: TXT=129982 bytes) (Obsoleted by RFC5996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4718) 4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3). R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.. November 2006. (Format: TXT=30764 bytes) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4719) 4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention. A. Malis, D. Allan, N. Del Regno. November 2006. (Format: TXT=18248 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4720) 4721 Mobile IPv4 Challenge/Response Extensions (Revised). C. Perkins, P. Calhoun, J. Bharatia. January 2007. (Format: TXT=60386 bytes) (Obsoletes RFC3012) (Updates RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4721) 4722 Media Server Control Markup Language (MSCML) and Protocol. J. Van Dyke, E. Burger, Ed., A. Spitzer. November 2006. (Format: TXT=184055 bytes) (Obsoleted by RFC5022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4722) 4723 Registration of Media Type audio/mobile-xmf. T. Kosonen, T. White. December 2006. (Format: TXT=12652 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4723) 4724 Graceful Restart Mechanism for BGP. S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter. January 2007. (Format: TXT=32343 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4724) 4725 ENUM Validation Architecture. A. Mayrhofer, B. Hoeneisen. November 2006. (Format: TXT=33216 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4725) 4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. A. Farrel, J.-P. Vasseur, A. Ayyangar. November 2006. (Format: TXT=53076 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4726) 4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. B. Fenner. November 2006. (Format: TXT=19745 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4727) 4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4. D. Johnson, Y. Hu, D. Maltz. February 2007. (Format: TXT=265706 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4728) 4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum. M. Abel. November 2006. (Format: TXT=13423 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4729) 4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML). E. Burger, M. Dolly. November 2006. (Format: TXT=120186 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4730) 4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned. A. Melnikov, D. Cridland. November 2006. (Format: TXT=15431 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4731) 4732 Internet Denial-of-Service Considerations. M. Handley, Ed., E. Rescorla, Ed., IAB. December 2006. (Format: TXT=91844 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4732) 4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. H. Schulzrinne, T. Taylor. December 2006. (Format: TXT=115614 bytes) (Obsoletes RFC2833) (Updated by RFC4734, RFC5244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4733) 4734 Definition of Events for Modem, Fax, and Text Telephony Signals. H. Schulzrinne, T. Taylor. December 2006. (Format: TXT=116810 bytes) (Obsoletes RFC2833) (Updates RFC4733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4734) 4735 Example Media Types for Use in Documentation. T. Taylor. October 2006. (Format: TXT=9951 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4735) 4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP). JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. November 2006. (Format: TXT=28850 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4736) 4737 Packet Reordering Metrics. A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser. November 2006. (Format: TXT=94699 bytes) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4737) 4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). D. Ignjatic, L. Dondeti, F. Audet, P. Lin. November 2006. (Format: TXT=43015 bytes) (Updates RFC3830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4738) 4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol. P. Eronen, J. Korhonen. November 2006. (Format: TXT=22704 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4739) 4740 Diameter Session Initiation Protocol (SIP) Application. M. Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi. November 2006. (Format: TXT=174175 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4740) 4741 NETCONF Configuration Protocol. R. Enns, Ed.. December 2006. (Format: TXT=173914 bytes) (Obsoleted by RFC6241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4741) 4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH). M. Wasserman, T. Goddard. December 2006. (Format: TXT=17807 bytes) (Obsoleted by RFC6242) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4742) 4743 Using NETCONF over the Simple Object Access Protocol (SOAP). T. Goddard. December 2006. (Format: TXT=39734 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4743) 4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP). E. Lear, K. Crozier. December 2006. (Format: TXT=19287 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4744) 4745 Common Policy: A Document Format for Expressing Privacy Preferences. H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, J. Rosenberg. February 2007. (Format: TXT=63602 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4745) 4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange. T. Clancy, W. Arbaugh. November 2006. (Format: TXT=63471 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4746) 4747 The Virtual Fabrics MIB. S. Kipp, G. Ramkumar, K. McCloghrie. November 2006. (Format: TXT=39034 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4747) 4748 RFC 3978 Update to Recognize the IETF Trust. S. Bradner, Ed.. October 2006. (Format: TXT=7284 bytes) (Obsoleted by RFC5378) (Updates RFC3978) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4748) 4749 RTP Payload Format for the G.729.1 Audio Codec. A. Sollaud. October 2006. (Format: TXT=28838 bytes) (Updated by RFC5459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4749) 4750 OSPF Version 2 Management Information Base. D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. Baker. December 2006. (Format: TXT=222459 bytes) (Obsoletes RFC1850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4750) 4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism. A. Melnikov, Ed.. November 2006. (Format: TXT=22133 bytes) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4752) 4753 ECP Groups For IKE and IKEv2. D. Fu, J. Solinas. January 2007. (Format: TXT=28760 bytes) (Obsoleted by RFC5903) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4753) 4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA). D. Fu, J. Solinas. January 2007. (Format: TXT=27948 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4754) 4755 IP over InfiniBand: Connected Mode. V. Kashyap. December 2006. (Format: TXT=26314 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4755) 4756 Forward Error Correction Grouping Semantics in Session Description Protocol. A. Li. November 2006. (Format: TXT=12743 bytes) (Obsoleted by RFC5956) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4756) 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. December 2006. (Format: TXT=36562 bytes) (Updated by RFC6649) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4757) 4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1. M. Nystroem. November 2006. (Format: TXT=110657 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4758) 4759 The ENUM Dip Indicator Parameter for the "tel" URI. R. Stastny, R. Shockey, L. Conroy. December 2006. (Format: TXT=15062 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4759) 4760 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. Katz, Y. Rekhter. January 2007. (Format: TXT=24542 bytes) (Obsoletes RFC2858) (Updated by RFC7606) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4760) 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling. K. Kompella, Ed., Y. Rekhter, Ed.. January 2007. (Format: TXT=65219 bytes) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4761) 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling. M. Lasserre, Ed., V. Kompella, Ed.. January 2007. (Format: TXT=82778 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4762) 4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE). M. Vanderveen, H. Soliman. November 2006. (Format: TXT=96027 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4763) 4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method. F. Bersani, H. Tschofenig. January 2007. (Format: TXT=133990 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4764) 4765 The Intrusion Detection Message Exchange Format (IDMEF). H. Debar, D. Curry, B. Feinstein. March 2007. (Format: TXT=307966 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4765) 4766 Intrusion Detection Message Exchange Requirements. M. Wood, M. Erlinger. March 2007. (Format: TXT=50816 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4766) 4767 The Intrusion Detection Exchange Protocol (IDXP). B. Feinstein, G. Matthews. March 2007. (Format: TXT=56048 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4767) 4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming. S. Hartman. December 2006. (Format: TXT=27205 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4768) 4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information. J. Livingood, R. Shockey. November 2006. (Format: TXT=24945 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4769) 4770 vCard Extensions for Instant Messaging (IM). C. Jennings, J. Reschke, Ed.. January 2007. (Format: TXT=11077 bytes) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4770) 4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP). V. Lehtovirta, M. Naslund, K. Norrman. January 2007. (Format: TXT=27945 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4771) 4772 Security Implications of Using the Data Encryption Standard (DES). S. Kelly. December 2006. (Format: TXT=68524 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4772) 4773 Administration of the IANA Special Purpose IPv6 Address Block. G. Huston. December 2006. (Format: TXT=10580 bytes) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4773) 4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field. S. Floyd. November 2006. (Format: TXT=37144 bytes) (Updated by RFC6040) (Also BCP0124) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4774) 4775 Procedures for Protocol Extensions and Variations. S. Bradner, B. Carpenter, Ed., T. Narten. December 2006. (Format: TXT=32797 bytes) (Also BCP0125) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4775) 4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. November 2006. (Format: TXT=45495 bytes) (Obsoletes RFC4676) (Updated by RFC5774, RFC6848) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4776) 4777 IBM's iSeries Telnet Enhancements. T. Murphy Jr., P. Rieth, J. Stevens. November 2006. (Format: TXT=104243 bytes) (Obsoletes RFC2877) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4777) 4778 Operational Security Current Practices in Internet Service Provider Environments. M. Kaeo. January 2007. (Format: TXT=88344 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4778) 4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks. S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January 2007. (Format: TXT=188511 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4779) 4780 Management Information Base for the Session Initiation Protocol (SIP). K. Lingle, J-F. Mule, J. Maeng, D. Walker. April 2007. (Format: TXT=160460 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4780) 4781 Graceful Restart Mechanism for BGP with MPLS. Y. Rekhter, R. Aggarwal. January 2007. (Format: TXT=23249 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4781) 4782 Quick-Start for TCP and IP. S. Floyd, M. Allman, A. Jain, P. Sarolahti. January 2007. (Format: TXT=214489 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4782) 4783 GMPLS - Communication of Alarm Information. L. Berger, Ed.. December 2006. (Format: TXT=42068 bytes) (Updates RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4783) 4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks. C. Carroll, F. Quick. June 2007. (Format: TXT=102856 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4784) 4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS). U. Blumenthal, P. Goel. January 2007. (Format: TXT=9550 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4785) 4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT=56818 bytes) (Also BCP0126) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4786) 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. F. Audet, Ed., C. Jennings. January 2007. (Format: TXT=68693 bytes) (Updated by RFC6888, RFC7857) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4787) 4788 Enhancements to RTP Payload Formats for EVRC Family Codecs. Q. Xie, R. Kapoor. January 2007. (Format: TXT=42216 bytes) (Updates RFC3558) (Updated by RFC5188) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4788) 4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks. J. Schoenwaelder, T. Jeffree. November 2006. (Format: TXT=17839 bytes) (Obsoletes RFC1089) (Updates RFC3417) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4789) 4790 Internet Application Protocol Collation Registry. C. Newman, M. Duerst, A. Gulbrandsen. March 2007. (Format: TXT=55591 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4790) 4791 Calendaring Extensions to WebDAV (CalDAV). C. Daboo, B. Desruisseaux, L. Dusseault. March 2007. (Format: TXT=206801 bytes) (Updated by RFC5689, RFC6638, RFC6764, RFC7809, RFC7953) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4791) 4792 Encoding Instructions for the Generic String Encoding Rules (GSER). S. Legg. January 2007. (Format: TXT=17637 bytes) (Updates RFC3641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4792) 4793 The EAP Protected One-Time Password Protocol (EAP-POTP). M. Nystroem. February 2007. (Format: TXT=172575 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4793) 4794 RFC 1264 Is Obsolete. B. Fenner. December 2006. (Format: TXT=7554 bytes) (Obsoletes RFC1264) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4794) 4795 Link-local Multicast Name Resolution (LLMNR). B. Aboba, D. Thaler, L. Esibov. January 2007. (Format: TXT=71969 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4795) 4796 The Session Description Protocol (SDP) Content Attribute. J. Hautakorpi, G. Camarillo. February 2007. (Format: TXT=22886 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4796) 4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks. Y. Rekhter, R. Bonica, E. Rosen. January 2007. (Format: TXT=18985 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4797) 4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE). J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. February 2007. (Format: TXT=31381 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4798) 4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT=16347 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4801) 4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT=118164 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4802) 4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT=79925 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4803) 4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels. F. Le Faucheur, Ed.. February 2007. (Format: TXT=69473 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4804) 4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types. O. Nicklass, Ed.. March 2007. (Format: TXT=189927 bytes) (Obsoletes RFC3895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4805) 4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2. M. Myers, H. Tschofenig. February 2007. (Format: TXT=21991 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4806) 4807 IPsec Security Policy Database Configuration MIB. M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang. March 2007. (Format: TXT=136747 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4807) 4808 Key Change Strategies for TCP-MD5. S. Bellovin. March 2007. (Format: TXT=14939 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4808) 4809 Requirements for an IPsec Certificate Management Profile. C. Bonatti, Ed., S. Turner, Ed., G. Lebovitz, Ed.. February 2007. (Format: TXT=98400 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4809) 4810 Long-Term Archive Service Requirements. C. Wallace, U. Pordesch, R. Brandner. March 2007. (Format: TXT=35690 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4810) 4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization. L. Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT=18976 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4811) 4812 OSPF Restart Signaling. L. Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT=12111 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4812) 4813 OSPF Link-Local Signaling. B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin. March 2007. (Format: TXT=19687 bytes) (Obsoleted by RFC5613) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4813) 4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking. D. Newman, T. Player. March 2007. (Format: TXT=59272 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4814) 4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095. L-E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer. February 2007. (Format: TXT=74819 bytes) (Updates RFC3095, RFC3241, RFC3843, RFC4019, RFC4362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4815) 4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service. A. Malis, L. Martini, J. Brayley, T. Walsh. February 2007. (Format: TXT=10269 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4816) 4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3. M. Townsley, C. Pignataro, S. Wainner, T. Seely, J. Young. March 2007. (Format: TXT=26538 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4817) 4818 RADIUS Delegated-IPv6-Prefix Attribute. J. Salowey, R. Droms. April 2007. (Format: TXT=12993 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4818) 4819 Secure Shell Public Key Subsystem. J. Galbraith, J. Van Dyke, J. Bright. March 2007. (Format: TXT=32794 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4819) 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Stewart, P. Lei. March 2007. (Format: TXT=11597 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4820) 4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner. March 2007. (Format: TXT=75665 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4821) 4822 RIPv2 Cryptographic Authentication. R. Atkinson, M. Fanto. February 2007. (Format: TXT=53828 bytes) (Obsoletes RFC2082) (Updates RFC2453) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4822) 4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet. T. Harding, R. Scott. April 2007. (Format: TXT=80992 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4823) 4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS). J. Hofmueller, Ed., A. Bachmann, Ed., IO. zmoelnig, Ed.. April 2007. (Format: TXT=25521 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4824) 4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). J. Rosenberg. May 2007. (Format: TXT=166627 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4825) 4826 Extensible Markup Language (XML) Formats for Representing Resource Lists. J. Rosenberg. May 2007. (Format: TXT=68850 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4826) 4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents. M. Isomaki, E. Leppanen. May 2007. (Format: TXT=22896 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4827) 4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant. S. Floyd, E. Kohler. April 2007. (Format: TXT=116808 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4828) 4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering. J. de Oliveira, Ed., JP. Vasseur, Ed., L. Chen, C. Scoglio. April 2007. (Format: TXT=43892 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4829) 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT=29815 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4830) 4831 Goals for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT=35232 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4831) 4832 Security Threats to Network-Based Localized Mobility Management (NETLMM). C. Vogt, J. Kempf. April 2007. (Format: TXT=31467 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4832) 4833 Timezone Options for DHCP. E. Lear, P. Eggert. April 2007. (Format: TXT=19573 bytes) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4833) 4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). T. Morin, Ed.. April 2007. (Format: TXT=80341 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4834) 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). V. Manral. April 2007. (Format: TXT=21492 bytes) (Obsoletes RFC4305) (Obsoleted by RFC7321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4835) 4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). E. Beili. April 2007. (Format: TXT=151012 bytes) (Obsoletes RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4836) 4837 Managed Objects of Ethernet Passive Optical Networks (EPON). L. Khermosh. July 2007. (Format: TXT=206726 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4837) 4838 Delay-Tolerant Networking Architecture. V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss. April 2007. (Format: TXT=89265 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4838) 4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF). G. Conboy, J. Rivlin, J. Ferraiolo. April 2007. (Format: TXT=7851 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4839) 4840 Multiple Encapsulation Methods Considered Harmful. B. Aboba, Ed., E. Davies, D. Thaler. April 2007. (Format: TXT=65287 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4840) 4841 RFC 4181 Update to Recognize the IETF Trust. C. Heard, Ed.. March 2007. (Format: TXT=4414 bytes) (Updates RFC4181) (Also BCP0111) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4841) 4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP). A. Malis, P. Pate, R. Cohen, Ed., D. Zelig. April 2007. (Format: TXT=96719 bytes) (Obsoletes RFC5143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4842) 4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). P. Nikander, J. Laganier, F. Dupont. April 2007. (Format: TXT=32483 bytes) (Obsoleted by RFC7343) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4843) 4844 The RFC Series and RFC Editor. L. Daigle, Ed., Internet Architecture Board. July 2007. (Format: TXT=38752 bytes) (Updated by RFC5741) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4844) 4845 Process for Publication of IAB RFCs. L. Daigle, Ed., Internet Architecture Board. July 2007. (Format: TXT=9228 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4845) 4846 Independent Submissions to the RFC Editor. J. Klensin, Ed., D. Thaler, Ed.. July 2007. (Format: TXT=36562 bytes) (Updated by RFC5744) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4846) 4847 Framework and Requirements for Layer 1 Virtual Private Networks. T. Takeda, Ed.. April 2007. (Format: TXT=85807 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4847) 4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS). L. Daigle. April 2007. (Format: TXT=19341 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4848) 4849 RADIUS Filter Rule Attribute. P. Congdon, M. Sanchez, B. Aboba. April 2007. (Format: TXT=18162 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4849) 4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture. D. Wysochanski. April 2007. (Format: TXT=16430 bytes) (Obsoleted by RFC7143) (Updates RFC3720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4850) 4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST). N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. May 2007. (Format: TXT=131460 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4851) 4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. April 2007. (Format: TXT=76199 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4852) 4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification. R. Housley. April 2007. (Format: TXT=10146 bytes) (Updates RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4853) 4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. April 2007. (Format: TXT=15911 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4854) 4855 Media Type Registration of RTP Payload Formats. S. Casner. February 2007. (Format: TXT=24404 bytes) (Obsoletes RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4855) 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences. S. Casner. February 2007. (Format: TXT=45881 bytes) (Obsoletes RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4856) 4857 Mobile IPv4 Regional Registration. E. Fogelstroem, A. Jonsson, C. Perkins. June 2007. (Format: TXT=79939 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4857) 4858 Document Shepherding from Working Group Last Call to Publication. H. Levkowetz, D. Meyer, L. Eggert, A. Mankin. May 2007. (Format: TXT=48572 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4858) 4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object. A. Farrel. April 2007. (Format: TXT=7511 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4859) 4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations. F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. Davenport. May 2007. (Format: TXT=73010 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4860) 4861 Neighbor Discovery for IP version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. (Format: TXT=235106 bytes) (Obsoletes RFC2461) (Updated by RFC5942, RFC6980, RFC7048, RFC7527, RFC7559, RFC8028) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4861) 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes RFC2462) (Updated by RFC7527) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4862) 4863 Wildcard Pseudowire Type. L. Martini, G. Swallow. May 2007. (Format: TXT=11321 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4863) 4864 Local Network Protection for IPv6. G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT=95448 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4864) 4865 SMTP Submission Service Extension for Future Message Release. G. White, G. Vaudreuil. May 2007. (Format: TXT=21495 bytes) (Updates RFC3463, RFC3464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4865) 4866 Enhanced Route Optimization for Mobile IPv6. J. Arkko, C. Vogt, W. Haddad. May 2007. (Format: TXT=145757 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4866) 4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. April 2007. (Format: TXT=139584 bytes) (Obsoletes RFC3267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4867) 4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec. S. Kelly, S. Frankel. May 2007. (Format: TXT=41432 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4868) 4869 Suite B Cryptographic Suites for IPsec. L. Law, J. Solinas. May 2007. (Format: TXT=17043 bytes) (Obsoleted by RFC6379) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4869) 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys). M. Delany. May 2007. (Format: TXT=87378 bytes) (Obsoleted by RFC4871) (Status: HISTORIC) (DOI: 10.17487/RFC4870) 4871 DomainKeys Identified Mail (DKIM) Signatures. E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. May 2007. (Format: TXT=166054 bytes) (Obsoletes RFC4870) (Obsoleted by RFC6376) (Updated by RFC5672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4871) 4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery. J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed.. May 2007. (Format: TXT=111882 bytes) (Updates RFC3471) (Updated by RFC4873, RFC6780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4872) 4873 GMPLS Segment Recovery. L. Berger, I. Bryskin, D. Papadimitriou, A. Farrel. May 2007. (Format: TXT=56919 bytes) (Updates RFC3473, RFC4872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4873) 4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). CY. Lee, A. Farrel, S. De Cnodder. April 2007. (Format: TXT=59569 bytes) (Updates RFC3209, RFC3473) (Updated by RFC6001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4874) 4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs). R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007. (Format: TXT=125394 bytes) (Updated by RFC6510) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4875) 4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents. B. Neal-Joslin, Ed., L. Howard, M. Ansari. May 2007. (Format: TXT=73468 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4876) 4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. V. Devarapalli, F. Dupont. April 2007. (Format: TXT=57941 bytes) (Updates RFC3776) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4877) 4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces. M. Squire. June 2007. (Format: TXT=130067 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4878) 4879 Clarification of the Third Party Disclosure Procedure in RFC 3979. T. Narten. April 2007. (Format: TXT=5570 bytes) (Updates RFC3979) (Also BCP0079) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4879) 4880 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer. November 2007. (Format: TXT=203706 bytes) (Obsoletes RFC1991, RFC2440) (Updated by RFC5581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4880) 4881 Low-Latency Handoffs in Mobile IPv4. K. El Malki, Ed.. June 2007. (Format: TXT=151124 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4881) 4882 IP Address Location Privacy and Mobile IPv6: Problem Statement. R. Koodli. May 2007. (Format: TXT=24987 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4882) 4883 Benchmarking Terminology for Resource Reservation Capable Routers. G. Feher, K. Nemeth, A. Korn, I. Cselenyi. July 2007. (Format: TXT=54205 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4883) 4884 Extended ICMP to Support Multi-Part Messages. R. Bonica, D. Gan, D. Tappan, C. Pignataro. April 2007. (Format: TXT=42169 bytes) (Updates RFC0792, RFC4443) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4884) 4885 Network Mobility Support Terminology. T. Ernst, H-Y. Lach. July 2007. (Format: TXT=37967 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4885) 4886 Network Mobility Support Goals and Requirements. T. Ernst. July 2007. (Format: TXT=29083 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4886) 4887 Network Mobility Home Network Models. P. Thubert, R. Wakikawa, V. Devarapalli. July 2007. (Format: TXT=40372 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4887) 4888 Network Mobility Route Optimization Problem Statement. C. Ng, P. Thubert, M. Watari, F. Zhao. July 2007. (Format: TXT=56756 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4888) 4889 Network Mobility Route Optimization Solution Space Analysis. C. Ng, F. Zhao, M. Watari, P. Thubert. July 2007. (Format: TXT=95880 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4889) 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E. Davies, J. Mohacsi. May 2007. (Format: TXT=83479 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4890) 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. May 2007. (Format: TXT=46635 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4891) 4892 Requirements for a Mechanism Identifying a Name Server Instance. S. Woolf, D. Conrad. June 2007. (Format: TXT=17605 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4892) 4893 BGP Support for Four-octet AS Number Space. Q. Vohra, E. Chen. May 2007. (Format: TXT=21520 bytes) (Obsoleted by RFC6793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4893) 4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec. P. Hoffman. May 2007. (Format: TXT=22899 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4894) 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Stewart, P. Lei, E. Rescorla. August 2007. (Format: TXT=42507 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4895) 4896 Signaling Compression (SigComp) Corrections and Clarifications. A. Surtees, M. West, A.B. Roach. June 2007. (Format: TXT=58435 bytes) (Updates RFC3320, RFC3321, RFC3485) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4896) 4897 Handling Normative References to Standards-Track Documents. J. Klensin, S. Hartman. June 2007. (Format: TXT=13023 bytes) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4897) 4898 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4898) 4901 Protocol Extensions for Header Compression over MPLS. J. Ash, Ed., J. Hand, Ed., A. Malis, Ed.. June 2007. (Format: TXT=78801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4901) 4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP. M. Stecher. May 2007. (Format: TXT=30120 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4902) 4903 Multi-Link Subnet Issues. D. Thaler. June 2007. (Format: TXT=39671 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4903) 4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs). V. Gurbani, C. Jennings. June 2007. (Format: TXT=41027 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4904) 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks. L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed.. June 2007. (Format: TXT=40020 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4905) 4906 Transport of Layer 2 Frames Over MPLS. L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed.. June 2007. (Format: TXT=47403 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC4906) 4907 Architectural Implications of Link Indications. B. Aboba, Ed.. June 2007. (Format: TXT=160604 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4907) 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO. K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi. June 2007. (Format: TXT=20230 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4908) 4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport. L. Dondeti, Ed., D. Castleford, F. Hartung. June 2007. (Format: TXT=12228 bytes) (Obsoleted by RFC5410, RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4909) 4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1). S. Legg, D. Prager. July 2007. (Format: TXT=182175 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4910) 4911 Encoding Instructions for the Robust XML Encoding Rules (RXER). S. Legg. July 2007. (Format: TXT=178977 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4911) 4912 Abstract Syntax Notation X (ASN.X). S. Legg. July 2007. (Format: TXT=325190 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4912) 4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER). S. Legg. July 2007. (Format: TXT=17194 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4913) 4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER). S. Legg. July 2007. (Format: TXT=71526 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4914) 4915 Multi-Topology (MT) Routing in OSPF. P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-Esnault. June 2007. (Format: TXT=43115 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4915) 4916 Connected Identity in the Session Initiation Protocol (SIP). J. Elwell. June 2007. (Format: TXT=42924 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4916) 4917 Mobile IPv4 Message String Extension. V. Sastry, K. Leung, A. Patel. June 2007. (Format: TXT=13302 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4917) 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). L. Dusseault, Ed.. June 2007. (Format: TXT=276352 bytes) (Obsoletes RFC2518) (Updated by RFC5689) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4918) 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. N. Kushalnagar, G. Montenegro, C. Schumacher. August 2007. (Format: TXT=27650 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4919) 4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE. A. Farrel, Ed., A. Satyanarayana, A. Iwata, N. Fujita, G. Ash. July 2007. (Format: TXT=88679 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4920) 4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network. F. Baker, P. Bose. August 2007. (Format: TXT=92632 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4923) 4924 Reflections on Internet Transparency. B. Aboba, Ed., E. Davies. July 2007. (Format: TXT=35040 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4924) 4925 Softwire Problem Statement. X. Li, Ed., S. Dawkins, Ed., D. Ward, Ed., A. Durand, Ed.. July 2007. (Format: TXT=49299 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4925) 4926 A URN Namespace for GEANT. T.Kalin, M.Molina. July 2007. (Format: TXT=16672 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4926) 4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering. J.-L. Le Roux, Ed.. June 2007. (Format: TXT=25016 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4927) 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks. G. Swallow, S. Bryant, L. Andersson. June 2007. (Format: TXT=18376 bytes) (Updated by RFC7274) (Also BCP0128) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4928) 4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures. L. Andersson, Ed., A. Farrel, Ed.. June 2007. (Format: TXT=56742 bytes) (Also BCP0129) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4929) 4930 Extensible Provisioning Protocol (EPP). S. Hollenbeck. May 2007. (Format: TXT=135648 bytes) (Obsoletes RFC3730) (Obsoleted by RFC5730) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4930) 4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. May 2007. (Format: TXT=88729 bytes) (Obsoletes RFC3731) (Obsoleted by RFC5731) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4931) 4932 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. May 2007. (Format: TXT=57623 bytes) (Obsoletes RFC3732) (Obsoleted by RFC5732) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4932) 4933 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. May 2007. (Format: TXT=82254 bytes) (Obsoletes RFC3733) (Obsoleted by RFC5733) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4933) 4934 Extensible Provisioning Protocol (EPP) Transport Over TCP. S. Hollenbeck. May 2007. (Format: TXT=22914 bytes) (Obsoletes RFC3734) (Obsoleted by RFC5734) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4934) 4935 Fibre Channel Fabric Configuration Server MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT=97345 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4935) 4936 Fibre Channel Zone Server MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT=170801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4936) 4937 IANA Considerations for PPP over Ethernet (PPPoE). P. Arberg, V. Mammoliti. June 2007. (Format: TXT=11070 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4937) 4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics. B. Berry, H. Holgate. June 2007. (Format: TXT=38288 bytes) (Obsoleted by RFC5578) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4938) 4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service). K. Gibbons, G. Ramkumar, S. Kipp. July 2007. (Format: TXT=165381 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4939) 4940 IANA Considerations for OSPF. K. Kompella, B. Fenner. July 2007. (Format: TXT=27595 bytes) (Also BCP0130) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4940) 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4941) 4942 IPv6 Transition/Co-existence Security Considerations. E. Davies, S. Krishnan, P. Savola. September 2007. (Format: TXT=102878 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4942) 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful. S. Roy, A. Durand, J. Paugh. September 2007. (Format: TXT=16719 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4943) 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. September 2007. (Format: TXT=67232 bytes) (Updated by RFC6282, RFC6775, RFC8025) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4944) 4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX. B. Korver. August 2007. (Format: TXT=101495 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4945) 4946 Atom License Extension. J. Snell. July 2007. (Format: TXT=14602 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4946) 4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks. G. Fairhurst, M. Montpetit. July 2007. (Format: TXT=102717 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4947) 4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006. L. Andersson, E. Davies, L. Zhang. August 2007. (Format: TXT=106199 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4948) 4949 Internet Security Glossary, Version 2. R. Shirey. August 2007. (Format: TXT=867626 bytes) (Obsoletes RFC2828) (Also FYI0036) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4949) 4950 ICMP Extensions for Multiprotocol Label Switching. R. Bonica, D. Gan, D. Tappan, C. Pignataro. August 2007. (Format: TXT=15091 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4950) 4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover". V. Jain, Ed.. August 2007. (Format: TXT=53659 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4951) 4952 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. July 2007. (Format: TXT=48409 bytes) (Obsoleted by RFC6530) (Updated by RFC5336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4952) 4953 Defending TCP Against Spoofing Attacks. J. Touch. July 2007. (Format: TXT=72756 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4953) 4954 SMTP Service Extension for Authentication. R. Siemborski, Ed., A. Melnikov, Ed.. July 2007. (Format: TXT=43493 bytes) (Obsoletes RFC2554) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4954) 4955 DNS Security (DNSSEC) Experiments. D. Blacka. July 2007. (Format: TXT=15417 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4955) 4956 DNS Security (DNSSEC) Opt-In. R. Arends, M. Kosters, D. Blacka. July 2007. (Format: TXT=32033 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4956) 4957 Link-Layer Event Notifications for Detecting Network Attachments. S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin, Ed.. August 2007. (Format: TXT=41840 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4957) 4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain. K. Carlberg. July 2007. (Format: TXT=44008 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4958) 4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response. R. Siemborski, A. Gulbrandsen. September 2007. (Format: TXT=12284 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4959) 4960 Stream Control Transmission Protocol. R. Stewart, Ed.. September 2007. (Format: TXT=346022 bytes) (Obsoletes RFC2960, RFC3309) (Updated by RFC6096, RFC6335, RFC7053) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4960) 4961 Symmetric RTP / RTP Control Protocol (RTCP). D. Wing. July 2007. (Format: TXT=12539 bytes) (Also BCP0131) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4961) 4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management. R. Housley, B. Aboba. July 2007. (Format: TXT=54927 bytes) (Also BCP0132) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4962) 4963 IPv4 Reassembly Errors at High Data Rates. J. Heffner, M. Mathis, B. Chandler. July 2007. (Format: TXT=22399 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4963) 4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular. A. Allen, Ed., J. Holm, T. Hallin. September 2007. (Format: TXT=67505 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4964) 4965 CableLabs - IETF Standardization Collaboration. J-F. Mule, W. Townsley. September 2007. (Format: TXT=20885 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4965) 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status. C. Aoun, E. Davies. July 2007. (Format: TXT=60284 bytes) (Obsoletes RFC2766) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4966) 4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier. B. Rosen. July 2007. (Format: TXT=12659 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4967) 4968 Analysis of IPv6 Link Models for 802.16 Based Networks. S. Madanapalli, Ed.. August 2007. (Format: TXT=34536 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4968) 4969 IANA Registration for vCard Enumservice. A. Mayrhofer. August 2007. (Format: TXT=14038 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4969) 4970 Extensions to OSPF for Advertising Optional Router Capabilities. A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. July 2007. (Format: TXT=26416 bytes) (Obsoleted by RFC7770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4970) 4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information. JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed.. July 2007. (Format: TXT=18541 bytes) (Obsoleted by RFC7981) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4971) 4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership. JP. Vasseur, Ed., JL. Leroux, Ed., S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey. July 2007. (Format: TXT=32044 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4972) 4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering. P. Srisuresh, P. Joseph. July 2007. (Format: TXT=115361 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4973) 4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls. D. Papadimitriou, A. Farrel. August 2007. (Format: TXT=72000 bytes) (Updates RFC3473) (Updated by RFC6001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4974) 4975 The Message Session Relay Protocol (MSRP). B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed.. September 2007. (Format: TXT=144254 bytes) (Updated by RFC7977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4975) 4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP). C. Jennings, R. Mahy, A. B. Roach. September 2007. (Format: TXT=84244 bytes) (Updated by RFC7977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4976) 4977 Problem Statement: Dual Stack Mobility. G. Tsirtsis, H. Soliman. August 2007. (Format: TXT=16758 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4977) 4978 The IMAP COMPRESS Extension. A. Gulbrandsen. August 2007. (Format: TXT=17554 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4978) 4979 IANA Registration for Enumservice 'XMPP'. A. Mayrhofer. August 2007. (Format: TXT=11719 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4979) 4980 Analysis of Multihoming in Network Mobility Support. C. Ng, T. Ernst, E. Paik, M. Bagnulo. October 2007. (Format: TXT=88572 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4980) 4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods. J. Risson, T. Moors. September 2007. (Format: TXT=239752 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4981) 4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs). M. Bagnulo, J. Arkko. July 2007. (Format: TXT=20961 bytes) (Updates RFC3972) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4982) 4983 Fibre Channel Registered State Change Notification (RSCN) MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT=56049 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4983) 4984 Report from the IAB Workshop on Routing and Addressing. D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed.. September 2007. (Format: TXT=96153 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4984) 4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name. S. Santesson. August 2007. (Format: TXT=17868 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4985) 4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover. H. Eland, R. Mundy, S. Crocker, S. Krishnaswamy. August 2007. (Format: TXT=22647 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4986) 4987 TCP SYN Flooding Attacks and Common Mitigations. W. Eddy. August 2007. (Format: TXT=48753 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4987) 4988 Mobile IPv4 Fast Handovers. R. Koodli, C. Perkins. October 2007. (Format: TXT=57921 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4988) 4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks. K. Shiomoto, R. Papneja, R. Rabbat. September 2007. (Format: TXT=50908 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4990) 4991 A Common Schema for Internet Registry Information Service Transfer Protocols. A. Newton. August 2007. (Format: TXT=24418 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4991) 4992 XML Pipelining with Chunks for the Internet Registry Information Service. A. Newton. August 2007. (Format: TXT=55848 bytes) (Updates RFC3981) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4992) 4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service. A. Newton. August 2007. (Format: TXT=34383 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4993) 4994 DHCPv6 Relay Agent Echo Request Option. S. Zeng, B. Volz, K. Kinnear, J. Brzozowski. September 2007. (Format: TXT=10978 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4994) 4995 The RObust Header Compression (ROHC) Framework. L-E. Jonsson, G. Pelletier, K. Sandlund. July 2007. (Format: TXT=87198 bytes) (Obsoleted by RFC5795) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4995) 4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP). G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. July 2007. (Format: TXT=183113 bytes) (Obsoleted by RFC6846) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4996) 4997 Formal Notation for RObust Header Compression (ROHC-FN). R. Finking, G. Pelletier. July 2007. (Format: TXT=131231 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4997) 4998 Evidence Record Syntax (ERS). T. Gondrom, R. Brandner, U. Pordesch. August 2007. (Format: TXT=66888 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4998) 5000 Internet Official Protocol Standards. RFC Editor. May 2008. (Format: TXT=222566 bytes) (Obsoletes RFC3700) (Obsoleted by RFC7100) (Status: HISTORIC) (DOI: 10.17487/RFC5000) 5001 DNS Name Server Identifier (NSID) Option. R. Austein. August 2007. (Format: TXT=23754 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5001) 5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header). G. Camarillo, G. Blanco. August 2007. (Format: TXT=15137 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5002) 5003 Attachment Individual Identifier (AII) Types for Aggregation. C. Metz, L. Martini, F. Balus, J. Sugimoto. September 2007. (Format: TXT=14559 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5003) 5004 Avoid BGP Best Path Transitions from One External to Another. E. Chen, S. Sangli. September 2007. (Format: TXT=11437 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5004) 5005 Feed Paging and Archiving. M. Nottingham. September 2007. (Format: TXT=28937 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5005) 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: TXT=26136 bytes) (Obsoleted by RFC6106) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5006) 5007 DHCPv6 Leasequery. J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. September 2007. (Format: TXT=47186 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5007) 5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME). R. Housley, J. Solinas. September 2007. (Format: TXT=32869 bytes) (Obsoleted by RFC6318) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5008) 5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media. R. Ejza. September 2007. (Format: TXT=36092 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5009) 5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption. K. Kinnear, M. Normoyle, M. Stapp. September 2007. (Format: TXT=13834 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5010) 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors. M. StJohns. September 2007. (Format: TXT=30138 bytes) (Also STD0074) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5011) 5012 Requirements for Emergency Context Resolution with Internet Technologies. H. Schulzrinne, R. Marshall, Ed.. January 2008. (Format: TXT=54599 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5012) 5013 The Dublin Core Metadata Element Set. J. Kunze, T. Baker. August 2007. (Format: TXT=17776 bytes) (Obsoletes RFC2413) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5013) 5014 IPv6 Socket API for Source Address Selection. E. Nordmark, S. Chakrabarti, J. Laganier. September 2007. (Format: TXT=53601 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5014) 5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM). M. Handley, I. Kouvelas, T. Speakman, L. Vicisano. October 2007. (Format: TXT=96431 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5015) 5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol. M. Thomas. October 2007. (Format: TXT=33710 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5016) 5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs). D. McWalter, Ed.. September 2007. (Format: TXT=14826 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5017) 5018 Connection Establishment in the Binary Floor Control Protocol (BFCP). G. Camarillo. September 2007. (Format: TXT=20244 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5018) 5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, R. Hurst. September 2007. (Format: TXT=46371 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5019) 5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute. K. Zeilenga. August 2007. (Format: TXT=8607 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5020) 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP. S. Josefsson. August 2007. (Format: TXT=13431 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5021) 5022 Media Server Control Markup Language (MSCML) and Protocol. J. Van Dyke, E. Burger, Ed., A. Spitzer. September 2007. (Format: TXT=184482 bytes) (Obsoletes RFC4722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5022) 5023 The Atom Publishing Protocol. J. Gregorio, Ed., B. de hOra, Ed.. October 2007. (Format: TXT=102274 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5023) 5024 ODETTE File Transfer Protocol 2.0. I. Friend. November 2007. (Format: TXT=276953 bytes) (Obsoletes RFC2204) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5024) 5025 Presence Authorization Rules. J. Rosenberg. December 2007. (Format: TXT=65880 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5025) 5026 Mobile IPv6 Bootstrapping in Split Scenario. G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. October 2007. (Format: TXT=63138 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5026) 5027 Security Preconditions for Session Description Protocol (SDP) Media Streams. F. Andreasen, D. Wing. October 2007. (Format: TXT=37229 bytes) (Updates RFC3312) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5027) 5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services. R. Mahy. October 2007. (Format: TXT=9804 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5028) 5029 Definition of an IS-IS Link Attribute Sub-TLV. JP. Vasseur, S. Previdi. September 2007. (Format: TXT=9887 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5029) 5030 Mobile IPv4 RADIUS Requirements. M. Nakhjiri, Ed., K. Chowdhury, A. Lior, K. Leung. October 2007. (Format: TXT=20319 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5030) 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services. H. Schulzrinne. January 2008. (Format: TXT=32960 bytes) (Updated by RFC7163) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5031) 5032 WITHIN Search Extension to the IMAP Protocol. E. Burger, Ed.. September 2007. (Format: TXT=8921 bytes) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5032) 5033 Specifying New Congestion Control Algorithms. S. Floyd, M. Allman. August 2007. (Format: TXT=23469 bytes) (Also BCP0133) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5033) 5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism. R. Siemborski, A. Menon-Sen. July 2007. (Format: TXT=24170 bytes) (Obsoletes RFC1734) (Updates RFC2449) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5034) 5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility. J. Schaad. August 2007. (Format: TXT=32674 bytes) (Updates RFC2634) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5035) 5036 LDP Specification. L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. October 2007. (Format: TXT=287101 bytes) (Obsoletes RFC3036) (Updated by RFC6720, RFC6790, RFC7358, RFC7552) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5036) 5037 Experience with the Label Distribution Protocol (LDP). L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. October 2007. (Format: TXT=13886 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5037) 5038 The Label Distribution Protocol (LDP) Implementation Survey Results. B. Thomas, L. Andersson. October 2007. (Format: TXT=46890 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5038) 5039 The Session Initiation Protocol (SIP) and Spam. J. Rosenberg, C. Jennings. January 2008. (Format: TXT=73341 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5039) 5040 A Remote Direct Memory Access Protocol Specification. R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia. October 2007. (Format: TXT=142247 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5040) 5041 Direct Data Placement over Reliable Transports. H. Shah, J. Pinkerton, R. Recio, P. Culley. October 2007. (Format: TXT=84642 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5041) 5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security. J. Pinkerton, E. Deleganes. October 2007. (Format: TXT=127453 bytes) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5042) 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation. C. Bestler, Ed., R. Stewart, Ed.. October 2007. (Format: TXT=38740 bytes) (Updated by RFC6581, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5043) 5044 Marker PDU Aligned Framing for TCP Specification. P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier. October 2007. (Format: TXT=168918 bytes) (Updated by RFC6581, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5044) 5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP). C. Bestler, Ed., L. Coene. October 2007. (Format: TXT=51749 bytes) (Updated by RFC7146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5045) 5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA). M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler. October 2007. (Format: TXT=202216 bytes) (Obsoleted by RFC7145) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5046) 5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI). M. Chadalapaka, J. Hufferd, J. Satran, H. Shah. October 2007. (Format: TXT=107970 bytes) (Updated by RFC7146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5047) 5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications. M. Chadalapaka, Ed.. October 2007. (Format: TXT=80149 bytes) (Obsoleted by RFC7143) (Updates RFC3720) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5048) 5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP). C. Bormann, Z. Liu, R. Price, G. Camarillo, Ed.. December 2007. (Format: TXT=47891 bytes) (Updates RFC3486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5049) 5050 Bundle Protocol Specification. K. Scott, S. Burleigh. November 2007. (Format: TXT=120435 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5050) 5051 i;unicode-casemap - Simple Unicode Collation Algorithm. M. Crispin. October 2007. (Format: TXT=14965 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5051) 5052 Forward Error Correction (FEC) Building Block. M. Watson, M. Luby, L. Vicisano. August 2007. (Format: TXT=57754 bytes) (Obsoletes RFC3452) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5052) 5053 Raptor Forward Error Correction Scheme for Object Delivery. M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer. October 2007. (Format: TXT=113743 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5053) 5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication. D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin. November 2007. (Format: TXT=44445 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5054) 5055 Server-Based Certificate Validation Protocol (SCVP). T. Freeman, R. Housley, A. Malpani, D. Cooper, W. Polk. December 2007. (Format: TXT=198764 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5055) 5056 On the Use of Channel Bindings to Secure Channels. N. Williams. November 2007. (Format: TXT=49995 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5056) 5057 Multiple Dialog Usages in the Session Initiation Protocol. R. Sparks. November 2007. (Format: TXT=62654 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5057) 5058 Explicit Multicast (Xcast) Concepts and Options. R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms. November 2007. (Format: TXT=80072 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5058) 5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM). N. Bhaskar, A. Gall, J. Lingard, S. Venaas. January 2008. (Format: TXT=100749, PDF=85519 bytes) (Obsoletes RFC2362) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5059) 5060 Protocol Independent Multicast MIB. R. Sivaramu, J. Lingard, D. McWalter, B. Joshi, A. Kessler. January 2008. (Format: TXT=170123 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5060) 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration. R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M. Kozuka. September 2007. (Format: TXT=91851 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5061) 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures. R. Stewart, M. Tuexen, G. Camarillo. September 2007. (Format: TXT=29704 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5062) 5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart. A. Satyanarayana, Ed., R. Rahman, Ed.. October 2007. (Format: TXT=58542 bytes) (Updates RFC2961, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5063) 5064 The Archived-At Message Header Field. M. Duerst. December 2007. (Format: TXT=20863 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5064) 5065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. August 2007. (Format: TXT=28732 bytes) (Obsoletes RFC3065) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5065) 5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB. E. Beili. November 2007. (Format: TXT=193465 bytes) (Updated by RFC7124) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5066) 5067 Infrastructure ENUM Requirements. S. Lind, P. Pfautz. November 2007. (Format: TXT=14311 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5067) 5068 Email Submission Operations: Access and Accountability Requirements. C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. November 2007. (Format: TXT=24481 bytes) (Also BCP0134) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5068) 5069 Security Threats and Requirements for Emergency Call Marking and Mapping. T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam. January 2008. (Format: TXT=26230 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5069) 5070 The Incident Object Description Exchange Format. R. Danyliw, J. Meijer, Y. Demchenko. December 2007. (Format: TXT=171529 bytes) (Obsoleted by RFC7970) (Updated by RFC6685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5070) 5071 Dynamic Host Configuration Protocol Options Used by PXELINUX. D. Hankins. December 2007. (Format: TXT=26777 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5071) 5072 IP Version 6 over PPP. S. Varada, Ed., D. Haskins, E. Allen. September 2007. (Format: TXT=33910 bytes) (Obsoletes RFC2472) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5072) 5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities. J.P. Vasseur, Ed., J.L. Le Roux, Ed.. December 2007. (Format: TXT=27004 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5073) 5074 DNSSEC Lookaside Validation (DLV). S. Weiler. November 2007. (Format: TXT=23375 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5074) 5075 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. November 2007. (Format: TXT=12499 bytes) (Obsoleted by RFC5175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5075) 5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol. B. Hoeneisen. December 2007. (Format: TXT=44679 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5076) 5077 Transport Layer Security (TLS) Session Resumption without Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. January 2008. (Format: TXT=41989 bytes) (Obsoletes RFC4507) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5077) 5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline. S. Dawkins. October 2007. (Format: TXT=19870 bytes) (Obsoleted by RFC7437) (Updates RFC3777) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5078) 5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP). J. Rosenberg. December 2007. (Format: TXT=15670 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5079) 5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes. D. Nelson, A. DeKok. December 2007. (Format: TXT=64138 bytes) (Updates RFC2865, RFC2866, RFC2869, RFC3579) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5080) 5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication. N. Mavrogiannopoulos. November 2007. (Format: TXT=15300 bytes) (Obsoleted by RFC6091) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5081) 5082 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. October 2007. (Format: TXT=36579 bytes) (Obsoletes RFC3682) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5082) 5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type. R. Housley. November 2007. (Format: TXT=22810 bytes) (Updates RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5083) 5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS). R. Housley. November 2007. (Format: TXT=21821 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5084) 5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires. T. Nadeau, Ed., C. Pignataro, Ed.. December 2007. (Format: TXT=67847 bytes) (Updated by RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5085) 5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN). A. Vainshtein, Ed., I. Sasson, E. Metz, T. Frost, P. Pate. December 2007. (Format: TXT=83233 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5086) 5087 Time Division Multiplexing over IP (TDMoIP). Y(J). Stein, R. Shashoua, R. Insler, M. Anavi. December 2007. (Format: TXT=113071 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5087) 5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery. JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. January 2008. (Format: TXT=40936 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5088) 5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery. JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. January 2008. (Format: TXT=34257 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5089) 5090 RADIUS Extension for Digest Authentication. B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. February 2008. (Format: TXT=68299 bytes) (Obsoletes RFC4590) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5090) 5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems. X. Boyen, L. Martin. December 2007. (Format: TXT=103464 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5091) 5092 IMAP URL Scheme. A. Melnikov, Ed., C. Newman. November 2007. (Format: TXT=65197 bytes) (Obsoletes RFC2192) (Updates RFC4467) (Updated by RFC5593) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5092) 5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ). G. Hunt. December 2007. (Format: TXT=15110 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5093) 5094 Mobile IPv6 Vendor Specific Option. V. Devarapalli, A. Patel, K. Leung. December 2007. (Format: TXT=11430 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5094) 5095 Deprecation of Type 0 Routing Headers in IPv6. J. Abley, P. Savola, G. Neville-Neil. December 2007. (Format: TXT=13423 bytes) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5095) 5096 Mobile IPv6 Experimental Messages. V. Devarapalli. December 2007. (Format: TXT=13669 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5096) 5097 MIB for the UDP-Lite protocol. G. Renker, G. Fairhurst. January 2008. (Format: TXT=48944 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5097) 5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs). G. Beacham, S. Kumar, S. Channabasappa. February 2008. (Format: TXT=159415 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5098) 5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. B. Claise, Ed.. January 2008. (Format: TXT=147196 bytes) (Obsoleted by RFC7011) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5101) 5102 Information Model for IP Flow Information Export. J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. January 2008. (Format: TXT=335617 bytes) (Obsoleted by RFC7012) (Updated by RFC6313) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5102) 5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX). B. Trammell, E. Boschi. January 2008. (Format: TXT=53534 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5103) 5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF). S. Wenger, U. Chandra, M. Westerlund, B. Burman. February 2008. (Format: TXT=158098 bytes) (Updated by RFC7728) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5104) 5105 ENUM Validation Token Format Definition. O. Lendl. December 2007. (Format: TXT=33057 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5105) 5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method. H. Tschofenig, D. Kroeselberg, A. Pashalidis, Y. Ohba, F. Bersani. February 2008. (Format: TXT=76645 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5106) 5107 DHCP Server Identifier Override Suboption. R. Johnson, J. Kumarasamy, K. Kinnear, M. Stapp. February 2008. (Format: TXT=14837 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5107) 5109 RTP Payload Format for Generic Forward Error Correction. A. Li, Ed.. December 2007. (Format: TXT=100538 bytes) (Obsoletes RFC2733, RFC3009) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5109) 5110 Overview of the Internet Multicast Routing Architecture. P. Savola. January 2008. (Format: TXT=56217 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5110) 5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF). B. Aboba, L. Dondeti. January 2008. (Format: TXT=16740 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5111) 5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp). M. Garcia-Martin. January 2008. (Format: TXT=67257 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5112) 5113 Network Discovery and Selection Problem. J. Arkko, B. Aboba, J. Korhonen, Ed., F. Bari. January 2008. (Format: TXT=93250 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5113) 5114 Additional Diffie-Hellman Groups for Use with IETF Standards. M. Lepinski, S. Kent. January 2008. (Format: TXT=49565 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5114) 5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority. K. Carlberg, P. O'Hanlon. January 2008. (Format: TXT=17194 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5115) 5116 An Interface and Algorithms for Authenticated Encryption. D. McGrew. January 2008. (Format: TXT=50539 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5116) 5117 RTP Topologies. M. Westerlund, S. Wenger. January 2008. (Format: TXT=50293 bytes) (Obsoleted by RFC7667) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5117) 5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6). V. Gurbani, C. Boulton, R. Sparks. February 2008. (Format: TXT=31829 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5118) 5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE). T. Edwards. February 2008. (Format: TXT=17024 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5119) 5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs). T. Przygienda, N. Shen, N. Sheth. February 2008. (Format: TXT=30318 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5120) 5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks. B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. February 2008. (Format: TXT=50092 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5121) 5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. February 2008. (Format: TXT=55566 bytes) (Obsoletes RFC4622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5122) 5123 Considerations in Validating the Path in BGP. R. White, B. Akyol. February 2008. (Format: TXT=39948 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5123) 5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF). J. Ott, E. Carrara. February 2008. (Format: TXT=37856 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5124) 5125 Reclassification of RFC 3525 to Historic. T. Taylor. February 2008. (Format: TXT=6646 bytes) (Obsoletes RFC3525) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5125) 5126 CMS Advanced Electronic Signatures (CAdES). D. Pinkas, N. Pope, J. Ross. March 2008. (Format: TXT=309173 bytes) (Obsoletes RFC3126) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5126) 5127 Aggregation of Diffserv Service Classes. K. Chan, J. Babiarz, F. Baker. February 2008. (Format: TXT=43751 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5127) 5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs). P. Srisuresh, B. Ford, D. Kegel. March 2008. (Format: TXT=81008 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5128) 5129 Explicit Congestion Marking in MPLS. B. Davie, B. Briscoe, J. Tay. January 2008. (Format: TXT=49496 bytes) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5129) 5130 A Policy Control Mechanism in IS-IS Using Administrative Tags. S. Previdi, M. Shand, Ed., C. Martin. February 2008. (Format: TXT=16284 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5130) 5131 A MIB Textual Convention for Language Tags. D. McWalter, Ed.. December 2007. (Format: TXT=11119 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5131) 5132 IP Multicast MIB. D. McWalter, D. Thaler, A. Kessler. December 2007. (Format: TXT=120340 bytes) (Obsoletes RFC2932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5132) 5133 Terminal Endpoint Identifier (TEI) Query Request Number Change. M. Tuexen, K. Morneault. December 2007. (Format: TXT=7279 bytes) (Updates RFC4233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5133) 5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards. M. Mealling. January 2008. (Format: TXT=18352 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5134) 5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT). D. Wing, T. Eckert. February 2008. (Format: TXT=36528 bytes) (Also BCP0135) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5135) 5136 Defining Network Capacity. P. Chimento, J. Ishac. February 2008. (Format: TXT=30682 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5136) 5137 ASCII Escaping of Unicode Characters. J. Klensin. February 2008. (Format: TXT=27742 bytes) (Also BCP0137) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5137) 5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI). S. Cox. February 2008. (Format: TXT=15005 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5138) 5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO). M. Thomson, J. Winterbottom. February 2008. (Format: TXT=27470 bytes) (Updates RFC4119) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5139) 5140 A Telephony Gateway REgistration Protocol (TGREP). M. Bangalore, R. Kumar, J. Rosenberg, H. Salama, D.N. Shah. March 2008. (Format: TXT=59511 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5140) 5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO). J. Goodwin, H. Apel. March 2008. (Format: TXT=57820 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5141) 5142 Mobility Header Home Agent Switch Message. B. Haley, V. Devarapalli, H. Deng, J. Kempf. January 2008. (Format: TXT=27460 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5142) 5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation. A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang. February 2008. (Format: TXT=52534 bytes) (Obsoleted by RFC4842) (Status: HISTORIC) (DOI: 10.17487/RFC5143) 5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS). A. Newton, M. Sanz. February 2008. (Format: TXT=30063 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5144) 5145 Framework for MPLS-TE to GMPLS Migration. K. Shiomoto, Ed.. March 2008. (Format: TXT=44646 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5145) 5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks. K. Kumaki, Ed.. March 2008. (Format: TXT=31624 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5146) 5147 URI Fragment Identifiers for the text/plain Media Type. E. Wilde, M. Duerst. April 2008. (Format: TXT=37422 bytes) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5147) 5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs). T. Clausen, C. Dearlove, B. Adamson. February 2008. (Format: TXT=26379 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5148) 5149 Service Selection for Mobile IPv6. J. Korhonen, U. Nilsson, V. Devarapalli. February 2008. (Format: TXT=18746 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5149) 5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE). A. Ayyangar, K. Kompella, JP. Vasseur, A. Farrel. February 2008. (Format: TXT=47099 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5150) 5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions. A. Farrel, Ed., A. Ayyangar, JP. Vasseur. February 2008. (Format: TXT=56663 bytes) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5151) 5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs). JP. Vasseur, Ed., A. Ayyangar, Ed., R. Zhang. February 2008. (Format: TXT=50563 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5152) 5153 IP Flow Information Export (IPFIX) Implementation Guidelines. E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken. April 2008. (Format: TXT=82845 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5153) 5154 IP over IEEE 802.16 Problem Statement and Goals. J. Jee, Ed., S. Madanapalli, J. Mandin. April 2008. (Format: TXT=29853 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5154) 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, G. Sisson, R. Arends, D. Blacka. March 2008. (Format: TXT=112338 bytes) (Updated by RFC6840, RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5155) 5156 Special-Use IPv6 Addresses. M. Blanchet. April 2008. (Format: TXT=11931 bytes) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5156) 5157 IPv6 Implications for Network Scanning. T. Chown. March 2008. (Format: TXT=29054 bytes) (Obsoleted by RFC7707) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5157) 5158 6to4 Reverse DNS Delegation Specification. G. Huston. March 2008. (Format: TXT=25536 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5158) 5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection. L. Dondeti, Ed., A. Jerichow. March 2008. (Format: TXT=13921 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5159) 5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS). P. Levis, M. Boucadair. March 2008. (Format: TXT=44317 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5160) 5161 The IMAP ENABLE Extension. A. Gulbrandsen, Ed., A. Melnikov, Ed.. March 2008. (Format: TXT=12220 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5161) 5162 IMAP4 Extensions for Quick Mailbox Resynchronization. A. Melnikov, D. Cridland, C. Wilson. March 2008. (Format: TXT=51620 bytes) (Obsoleted by RFC7162) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5162) 5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE). G. Fairhurst, B. Collini-Nocker. April 2008. (Format: TXT=42935 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5163) 5164 Mobility Services Transport: Problem Statement. T. Melia, Ed.. March 2008. (Format: TXT=33726 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5164) 5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC). C. Reed. April 2008. (Format: TXT=14681 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5165) 5166 Metrics for the Evaluation of Congestion Control Mechanisms. S. Floyd, Ed.. March 2008. (Format: TXT=53609 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5166) 5167 Media Server Control Protocol Requirements. M. Dolly, R. Even. March 2008. (Format: TXT=17147 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5167) 5168 XML Schema for Media Control. O. Levin, R. Even, P. Hagendorf. March 2008. (Format: TXT=17845 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5168) 5169 Handover Key Management and Re-Authentication Problem Statement. T. Clancy, M. Nakhjiri, V. Narayanan, L. Dondeti. March 2008. (Format: TXT=34082 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5169) 5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes. V. Roca, C. Neumann, D. Furodet. June 2008. (Format: TXT=68567 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5170) 5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol. M. Foschiano. April 2008. (Format: TXT=28149 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5171) 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol. S. Varada, Ed.. March 2008. (Format: TXT=14646 bytes) (Obsoletes RFC2472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5172) 5173 Sieve Email Filtering: Body Extension. J. Degener, P. Guenther. April 2008. (Format: TXT=17429 bytes) (Updates RFC5229) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5173) 5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU). J-P. Evain. May 2008. (Format: TXT=13732 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5174) 5175 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. March 2008. (Format: TXT=12463 bytes) (Obsoletes RFC5075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5175) 5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. January 2008. (Format: TXT=79541 bytes) (Obsoletes RFC3576) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5176) 5177 Network Mobility (NEMO) Extensions for Mobile IPv4. K. Leung, G. Dommety, V. Narayanan, A. Petrescu. April 2008. (Format: TXT=56094 bytes) (Updated by RFC6626) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5177) 5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type. N. Williams, A. Melnikov. May 2008. (Format: TXT=17262 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5178) 5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism. N. Williams. May 2008. (Format: TXT=8017 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5179) 5180 IPv6 Benchmarking Methodology for Network Interconnect Devices. C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. May 2008. (Format: TXT=41712 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5180) 5181 IPv6 Deployment Scenarios in 802.16 Networks. M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. May 2008. (Format: TXT=36671 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5181) 5182 IMAP Extension for Referencing the Last SEARCH Result. A. Melnikov. March 2008. (Format: TXT=24520 bytes) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5182) 5183 Sieve Email Filtering: Environment Extension. N. Freed. May 2008. (Format: TXT=16950 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5183) 5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover. F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani. May 2008. (Format: TXT=64137 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5184) 5185 OSPF Multi-Area Adjacency. S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal. May 2008. (Format: TXT=18698 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5185) 5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction. B. Haberman, J. Martin. May 2008. (Format: TXT=12403 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5186) 5187 OSPFv3 Graceful Restart. P. Pillay-Esnault, A. Lindem. June 2008. (Format: TXT=14860 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5187) 5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec. H. Desineni, Q. Xie. February 2008. (Format: TXT=44821 bytes) (Updates RFC4788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5188) 5189 Middlebox Communication (MIDCOM) Protocol Semantics. M. Stiemerling, J. Quittek, T. Taylor. March 2008. (Format: TXT=161167 bytes) (Obsoletes RFC3989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5189) 5190 Definitions of Managed Objects for Middlebox Communication. J. Quittek, M. Stiemerling, P. Srisuresh. March 2008. (Format: TXT=204929 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5190) 5191 Protocol for Carrying Authentication for Network Access (PANA). D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin. May 2008. (Format: TXT=96716 bytes) (Updated by RFC5872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5191) 5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents. L. Morand, A. Yegin, S. Kumar, S. Madanapalli. May 2008. (Format: TXT=14986 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5192) 5193 Protocol for Carrying Authentication for Network Access (PANA) Framework. P. Jayaraman, R. Lopez, Y. Ohba, Ed., M. Parthasarathy, A. Yegin. May 2008. (Format: TXT=24474 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5193) 5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). A. van Wijk, Ed., G. Gybels, Ed.. June 2008. (Format: TXT=68636 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5194) 5195 BGP-Based Auto-Discovery for Layer-1 VPNs. H. Ould-Brahim, D. Fedyk, Y. Rekhter. June 2008. (Format: TXT=21480 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5195) 5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF). M. Lonnfors, K. Kiss. September 2008. (Format: TXT=58488 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5196) 5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions. S. Fries, D. Ignjatic. June 2008. (Format: TXT=76848 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5197) 5198 Unicode Format for Network Interchange. J. Klensin, M. Padlipsky. March 2008. (Format: TXT=45708 bytes) (Obsoletes RFC0698) (Updates RFC0854) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5198) 5201 Host Identity Protocol. R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. April 2008. (Format: TXT=240492 bytes) (Obsoleted by RFC7401) (Updated by RFC6253) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5201) 5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, P. Nikander. April 2008. (Format: TXT=68195 bytes) (Obsoleted by RFC7402) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5202) 5203 Host Identity Protocol (HIP) Registration Extension. J. Laganier, T. Koponen, L. Eggert. April 2008. (Format: TXT=26620 bytes) (Obsoleted by RFC8003) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5203) 5204 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. April 2008. (Format: TXT=30233 bytes) (Obsoleted by RFC8004) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5204) 5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions. P. Nikander, J. Laganier. April 2008. (Format: TXT=34799 bytes) (Obsoleted by RFC8005) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5205) 5206 End-Host Mobility and Multihoming with the Host Identity Protocol. P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. April 2008. (Format: TXT=99430 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5206) 5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication. M. Stiemerling, J. Quittek, L. Eggert. April 2008. (Format: TXT=27873 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5207) 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2. B. Kaliski. May 2008. (Format: TXT=12063 bytes) (Obsoleted by RFC5958) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5208) 5209 Network Endpoint Assessment (NEA): Overview and Requirements. P. Sangster, H. Khosravi, M. Mani, K. Narayan, J. Tardo. June 2008. (Format: TXT=132227 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5209) 5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience. J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams. June 2008. (Format: TXT=58363 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5210) 5211 An Internet Transition Plan. J. Curran. July 2008. (Format: TXT=17158 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5211) 5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN). K. Shiomoto, D. Papadimitriou, JL. Le Roux, M. Vigoureux, D. Brungard. July 2008. (Format: TXT=70286 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5212) 5213 Proxy Mobile IPv6. S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. August 2008. (Format: TXT=226902 bytes) (Updated by RFC6543, RFC7864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5213) 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin, T. Gleeson, D. Thaler. March 2008. (Format: TXT=30126 bytes) (Obsoletes RFC4214) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5214) 5215 RTP Payload Format for Vorbis Encoded Audio. L. Barbato. August 2008. (Format: TXT=54327 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5215) 5216 The EAP-TLS Authentication Protocol. D. Simon, B. Aboba, R. Hurst. March 2008. (Format: TXT=71599 bytes) (Obsoletes RFC2716) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5216) 5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability. M. Shimaoka, Ed., N. Hastings, R. Nielsen. July 2008. (Format: TXT=64814 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5217) 5218 What Makes For a Successful Protocol?. D. Thaler, B. Aboba. July 2008. (Format: TXT=58409 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5218) 5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. February 2008. (Format: TXT=42830 bytes) (Obsoletes RFC3119) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5219) 5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules. A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT=33661 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5220) 5221 Requirements for Address Selection Mechanisms. A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT=13732 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5221) 5222 LoST: A Location-to-Service Translation Protocol. T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig. August 2008. (Format: TXT=123252 bytes) (Updated by RFC6848) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5222) 5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP). H. Schulzrinne, J. Polk, H. Tschofenig. August 2008. (Format: TXT=14936 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5223) 5224 Diameter Policy Processing Application. M. Brenner. March 2008. (Format: TXT=10283 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5224) 5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite. G. Pelletier, K. Sandlund. April 2008. (Format: TXT=246120 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5225) 5226 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. May 2008. (Format: TXT=66160 bytes) (Obsoletes RFC2434) (Also BCP0026) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5226) 5227 IPv4 Address Conflict Detection. S. Cheshire. July 2008. (Format: TXT=53548 bytes) (Updates RFC0826) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5227) 5228 Sieve: An Email Filtering Language. P. Guenther, Ed., T. Showalter, Ed.. January 2008. (Format: TXT=87531 bytes) (Obsoletes RFC3028) (Updated by RFC5229, RFC5429, RFC6785) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5228) 5229 Sieve Email Filtering: Variables Extension. K. Homme. January 2008. (Format: TXT=20023 bytes) (Updates RFC5228) (Updated by RFC5173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5229) 5230 Sieve Email Filtering: Vacation Extension. T. Showalter, N. Freed, Ed.. January 2008. (Format: TXT=29822 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5230) 5231 Sieve Email Filtering: Relational Extension. W. Segmuller, B. Leiba. January 2008. (Format: TXT=15243 bytes) (Obsoletes RFC3431) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5231) 5232 Sieve Email Filtering: Imap4flags Extension. A. Melnikov. January 2008. (Format: TXT=21964 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5232) 5233 Sieve Email Filtering: Subaddress Extension. K. Murchison. January 2008. (Format: TXT=12448 bytes) (Obsoletes RFC3598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5233) 5234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. January 2008. (Format: TXT=26359 bytes) (Obsoletes RFC4234) (Updated by RFC7405) (Also STD0068) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5234) 5235 Sieve Email Filtering: Spamtest and Virustest Extensions. C. Daboo. January 2008. (Format: TXT=25957 bytes) (Obsoletes RFC3685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5235) 5236 Improved Packet Reordering Metrics. A. Jayasumana, N. Piratla, T. Banka, A. Bare, R. Whitner. June 2008. (Format: TXT=57805 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5236) 5237 IANA Allocation Guidelines for the Protocol Field. J. Arkko, S. Bradner. February 2008. (Format: TXT=9303 bytes) (Updates RFC2780) (Also BCP0037) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5237) 5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). T. Phelan. May 2008. (Format: TXT=24394 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5238) 5239 A Framework for Centralized Conferencing. M. Barnes, C. Boulton, O. Levin. June 2008. (Format: TXT=146927 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5239) 5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB. B. Joshi, R. Bijlani. June 2008. (Format: TXT=42636 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5240) 5241 Naming Rights in IETF Protocols. A. Falk, S. Bradner. April 2008. (Format: TXT=25304 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5241) 5242 A Generalized Unified Character Code: Western European and CJK Sections. J. Klensin, H. Alvestrand. April 2008. (Format: TXT=31314 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5242) 5243 OSPF Database Exchange Summary List Optimization. R. Ogier. May 2008. (Format: TXT=11029 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5243) 5244 Definition of Events for Channel-Oriented Telephony Signalling. H. Schulzrinne, T. Taylor. June 2008. (Format: TXT=55321 bytes) (Updates RFC4733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5244) 5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. J. Rosenberg. April 2010. (Format: TXT=285120 bytes) (Obsoletes RFC4091, RFC4092) (Updated by RFC6336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5245) 5246 The Transport Layer Security (TLS) Protocol Version 1.2. T. Dierks, E. Rescorla. August 2008. (Format: TXT=222395 bytes) (Obsoletes RFC3268, RFC4346, RFC4366) (Updates RFC4492) (Updated by RFC5746, RFC5878, RFC6176, RFC7465, RFC7507, RFC7568, RFC7627, RFC7685, RFC7905, RFC7919) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5246) 5247 Extensible Authentication Protocol (EAP) Key Management Framework. B. Aboba, D. Simon, P. Eronen. August 2008. (Format: TXT=193535 bytes) (Updates RFC3748) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5247) 5248 A Registry for SMTP Enhanced Mail System Status Codes. T. Hansen, J. Klensin. June 2008. (Format: TXT=23845 bytes) (Updates RFC3463, RFC4468, RFC4954) (Also BCP0138) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5248) 5249 Templates for Internet-Drafts Containing MIB Modules. D. Harrington, Ed.. July 2008. (Format: TXT=7362 bytes) (Also BCP0139) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5249) 5250 The OSPF Opaque LSA Option. L. Berger, I. Bryskin, A. Zinin, R. Coltun. July 2008. (Format: TXT=37657 bytes) (Obsoletes RFC2370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5250) 5251 Layer 1 VPN Basic Mode. D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, R. Rabbat, L. Berger. July 2008. (Format: TXT=57599 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5251) 5252 OSPF-Based Layer 1 VPN Auto-Discovery. I. Bryskin, L. Berger. July 2008. (Format: TXT=23232 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5252) 5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode. T. Takeda, Ed.. July 2008. (Format: TXT=42675 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5253) 5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3). N. Bitar, Ed., M. Bocci, Ed., L. Martini, Ed.. October 2008. (Format: TXT=64584 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5254) 5255 Internet Message Access Protocol Internationalization. C. Newman, A. Gulbrandsen, A. Melnikov. June 2008. (Format: TXT=41403 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5255) 5256 Internet Message Access Protocol - SORT and THREAD Extensions. M. Crispin, K. Murchison. June 2008. (Format: TXT=40779 bytes) (Updated by RFC5957) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5256) 5257 Internet Message Access Protocol - ANNOTATE Extension. C. Daboo, R. Gellens. June 2008. (Format: TXT=58786 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5257) 5258 Internet Message Access Protocol version 4 - LIST Command Extensions. B. Leiba, A. Melnikov. June 2008. (Format: TXT=65074 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5258) 5259 Internet Message Access Protocol - CONVERT Extension. A. Melnikov, Ed., P. Coates, Ed.. July 2008. (Format: TXT=63831 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5259) 5260 Sieve Email Filtering: Date and Index Extensions. N. Freed. July 2008. (Format: TXT=25735 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5260) 5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors. J. Urpalainen. September 2008. (Format: TXT=78036 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5261) 5262 Presence Information Data Format (PIDF) Extension for Partial Presence. M. Lonnfors, E. Leppanen, H. Khartabil, J. Urpalainen. September 2008. (Format: TXT=28527 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5262) 5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information. M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil. September 2008. (Format: TXT=32556 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5263) 5264 Publication of Partial Presence Information. A. Niemi, M. Lonnfors, E. Leppanen. September 2008. (Format: TXT=30594 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5264) 5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways. S. Vaarala, E. Klovning. June 2008. (Format: TXT=86254 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5265) 5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE). V. Devarapalli, P. Eronen. June 2008. (Format: TXT=33186 bytes) (Also BCP0136) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5266) 5267 Contexts for IMAP4. D. Cridland, C. King. July 2008. (Format: TXT=36709 bytes) (Updated by RFC5465) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5267) 5268 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. June 2008. (Format: TXT=113090 bytes) (Obsoletes RFC4068) (Obsoleted by RFC5568) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5268) 5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND). J. Kempf, R. Koodli. June 2008. (Format: TXT=32742 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5269) 5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks. H. Jang, J. Jee, Y. Han, S. Park, J. Cha. June 2008. (Format: TXT=42358 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5270) 5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G. Dommety. June 2008. (Format: TXT=49316 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5271) 5272 Certificate Management over CMS (CMC). J. Schaad, M. Myers. June 2008. (Format: TXT=167138 bytes) (Obsoletes RFC2797) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5272) 5273 Certificate Management over CMS (CMC): Transport Protocols. J. Schaad, M. Myers. June 2008. (Format: TXT=14030 bytes) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5273) 5274 Certificate Management Messages over CMS (CMC): Compliance Requirements. J. Schaad, M. Myers. June 2008. (Format: TXT=27380 bytes) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5274) 5275 CMS Symmetric Key Management and Distribution. S. Turner. June 2008. (Format: TXT=207920 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5275) 5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records. C. Wallace. August 2008. (Format: TXT=27422 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5276) 5277 NETCONF Event Notifications. S. Chisholm, H. Trevino. July 2008. (Format: TXT=70878 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5277) 5278 IANA Registration of Enumservices for Voice and Video Messaging. J. Livingood, D. Troshynski. July 2008. (Format: TXT=39745 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5278) 5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP). A. Monrad, S. Loreto. July 2008. (Format: TXT=11582 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5279) 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. May 2008. (Format: TXT=352580 bytes) (Obsoletes RFC3280, RFC4325, RFC4630) (Updated by RFC6818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5280) 5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0). P. Funk, S. Blake-Wilson. August 2008. (Format: TXT=117059 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5281) 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol. D. Black, D. McGrew. August 2008. (Format: TXT=42137 bytes) (Updates RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5282) 5283 LDP Extension for Inter-Area Label Switched Paths (LSPs). B. Decraene, JL. Le Roux, I. Minei. July 2008. (Format: TXT=26534 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5283) 5284 User-Defined Errors for RSVP. G. Swallow, A. Farrel. August 2008. (Format: TXT=17452 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5284) 5285 A General Mechanism for RTP Header Extensions. D. Singer, H. Desineni. July 2008. (Format: TXT=36844 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5285) 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates. A. Atlas, Ed., A. Zinin, Ed.. September 2008. (Format: TXT=71027 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5286) 5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks. A. Vainshtein, Y(J). Stein. August 2008. (Format: TXT=33070 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5287) 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS. J. Salowey, A. Choudhury, D. McGrew. August 2008. (Format: TXT=16468 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5288) 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM). E. Rescorla. August 2008. (Format: TXT=12195 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5289) 5290 Comments on the Usefulness of Simple Best-Effort Traffic. S. Floyd, M. Allman. July 2008. (Format: TXT=48612 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5290) 5291 Outbound Route Filtering Capability for BGP-4. E. Chen, Y. Rekhter. August 2008. (Format: TXT=23949 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5291) 5292 Address-Prefix-Based Outbound Route Filter for BGP-4. E. Chen, S. Sangli. August 2008. (Format: TXT=10429 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5292) 5293 Sieve Email Filtering: Editheader Extension. J. Degener, P. Guenther. August 2008. (Format: TXT=17674 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5293) 5294 Host Threats to Protocol Independent Multicast (PIM). P. Savola, J. Lingard. August 2008. (Format: TXT=26525 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5294) 5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK). J. Salowey, L. Dondeti, V. Narayanan, M. Nakhjiri. August 2008. (Format: TXT=45622 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5295) 5296 EAP Extensions for EAP Re-authentication Protocol (ERP). V. Narayanan, L. Dondeti. August 2008. (Format: TXT=98264 bytes) (Obsoleted by RFC6696) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5296) 5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES). D. Harkins. October 2008. (Format: TXT=50374 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5297) 5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery. T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur. August 2008. (Format: TXT=59894 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5298) 5301 Dynamic Hostname Exchange Mechanism for IS-IS. D. McPherson, N. Shen. October 2008. (Format: TXT=11740 bytes) (Obsoletes RFC2763) (Updated by RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5301) 5302 Domain-Wide Prefix Distribution with Two-Level IS-IS. T. Li, H. Smit, T. Przygienda. October 2008. (Format: TXT=36742 bytes) (Obsoletes RFC2966) (Updates RFC1195) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5302) 5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies. D. Katz, R. Saluja, D. Eastlake 3rd. October 2008. (Format: TXT=23203 bytes) (Obsoletes RFC3373) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5303) 5304 IS-IS Cryptographic Authentication. T. Li, R. Atkinson. October 2008. (Format: TXT=24131 bytes) (Obsoletes RFC3567) (Updates RFC1195) (Updated by RFC6233, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5304) 5305 IS-IS Extensions for Traffic Engineering. T. Li, H. Smit. October 2008. (Format: TXT=35313 bytes) (Obsoletes RFC3784) (Updated by RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5305) 5306 Restart Signaling for IS-IS. M. Shand, L. Ginsberg. October 2008. (Format: TXT=51234 bytes) (Obsoletes RFC3847) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5306) 5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2008. (Format: TXT=22619 bytes) (Obsoletes RFC4205) (Updates RFC5305) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5307) 5308 Routing IPv6 with IS-IS. C. Hopps. October 2008. (Format: TXT=13324 bytes) (Updated by RFC7775) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5308) 5309 Point-to-Point Operation over LAN in Link State Routing Protocols. N. Shen, Ed., A. Zinin, Ed.. October 2008. (Format: TXT=21287 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5309) 5310 IS-IS Generic Cryptographic Authentication. M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto. February 2009. (Format: TXT=24521 bytes) (Updated by RFC6233, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5310) 5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS. D. McPherson, Ed., L. Ginsberg, S. Previdi, M. Shand. February 2009. (Format: TXT=23886 bytes) (Obsoletes RFC3786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5311) 5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering. M. Chen, R. Zhang, X. Duan. December 2008. (Format: TXT=45408 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5316) 5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile. S. Bryant, Ed., L. Andersson, Ed.. February 2009. (Format: TXT=18367, PDF=1411313 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5317) 5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). J. Hautakorpi, G. Camarillo. December 2008. (Format: TXT=24589 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5318) 5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL). F. Templin, Ed.. February 2010. (Format: TXT=67712 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5320) 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Updated by RFC7504) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5321) 5322 Internet Message Format. P. Resnick, Ed.. October 2008. (Format: TXT=122322 bytes) (Obsoletes RFC2822) (Updates RFC4021) (Updated by RFC6854) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5322) 5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH. J. Reschke, Ed., S. Reddy, J. Davis, A. Babich. November 2008. (Format: TXT=91077 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5323) 5324 MIB for Fibre-Channel Security Protocols (FC-SP). C. DeSanti, F. Maino, K. McCloghrie. September 2008. (Format: TXT=449246 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5324) 5325 Licklider Transmission Protocol - Motivation. S. Burleigh, M. Ramadas, S. Farrell. September 2008. (Format: TXT=57016 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5325) 5326 Licklider Transmission Protocol - Specification. M. Ramadas, S. Burleigh, S. Farrell. September 2008. (Format: TXT=120567 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5326) 5327 Licklider Transmission Protocol - Security Extensions. S. Farrell, M. Ramadas, S. Burleigh. September 2008. (Format: TXT=23269 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5327) 5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB). A. Adolf, P. MacAvock. September 2008. (Format: TXT=26369 bytes) (Updated by RFC7354) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5328) 5329 Traffic Engineering Extensions to OSPF Version 3. K. Ishiguro, V. Manral, A. Davey, A. Lindem, Ed.. September 2008. (Format: TXT=25864 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5329) 5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link. JP. Vasseur, Ed., M. Meyer, K. Kumaki, A. Bonda. October 2008. (Format: TXT=15730 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5330) 5331 MPLS Upstream Label Assignment and Context-Specific Label Space. R. Aggarwal, Y. Rekhter, E. Rosen. August 2008. (Format: TXT=30779 bytes) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5331) 5332 MPLS Multicast Encapsulations. T. Eckert, E. Rosen, Ed., R. Aggarwal, Y. Rekhter. August 2008. (Format: TXT=22887 bytes) (Updates RFC3032, RFC4023) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5332) 5333 IANA Registration of Enumservices for Internet Calendaring. R. Mahy, B. Hoeneisen. October 2009. (Format: TXT=13945 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5333) 5334 Ogg Media Types. I. Goncalves, S. Pfeiffer, C. Montgomery. September 2008. (Format: TXT=27018 bytes) (Obsoletes RFC3534) (Updated by RFC7845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5334) 5335 Internationalized Email Headers. A. Yang, Ed.. September 2008. (Format: TXT=27945 bytes) (Obsoleted by RFC6532) (Updates RFC2045, RFC2822) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5335) 5336 SMTP Extension for Internationalized Email Addresses. J. Yao, Ed., W. Mao, Ed.. September 2008. (Format: TXT=48110 bytes) (Obsoleted by RFC6531) (Updates RFC2821, RFC2822, RFC4952) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5336) 5337 Internationalized Delivery Status and Disposition Notifications. C. Newman, A. Melnikov, Ed.. September 2008. (Format: TXT=36324 bytes) (Obsoleted by RFC6533) (Updates RFC3461, RFC3462, RFC3464, RFC3798) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5337) 5338 Using the Host Identity Protocol with Legacy Applications. T. Henderson, P. Nikander, M. Komu. September 2008. (Format: TXT=34882 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5338) 5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN). JL. Le Roux, Ed., D. Papadimitriou, Ed.. September 2008. (Format: TXT=53998 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5339) 5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July 2008. (Format: TXT=225664 bytes) (Obsoletes RFC2740) (Updated by RFC6845, RFC6860, RFC7503) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5340) 5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry. C. Jennings, V. Gurbani. September 2008. (Format: TXT=13944 bytes) (Updates RFC3966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5341) 5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters. D. Eastlake 3rd. September 2008. (Format: TXT=42800 bytes) (Obsoleted by RFC7042) (Updates RFC2153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5342) 5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery. J. Schoenwaelder. September 2008. (Format: TXT=19938 bytes) (Updates RFC3411) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5343) 5344 Presence and Instant Messaging Peering Use Cases. A. Houri, E. Aoki, S. Parameswar. October 2008. (Format: TXT=18389 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5344) 5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats. J. Schoenwaelder. October 2008. (Format: TXT=52411 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5345) 5346 Operational Requirements for ENUM-Based Softswitch Use. J. Lim, W. Kim, C. Park, L. Conroy. October 2008. (Format: TXT=31050 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5346) 5347 Media Gateway Control Protocol Fax Package. F. Andreasen, D. Hancock. October 2008. (Format: TXT=86532 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5347) 5348 TCP Friendly Rate Control (TFRC): Protocol Specification. S. Floyd, M. Handley, J. Padhye, J. Widmer. September 2008. (Format: TXT=133185 bytes) (Obsoletes RFC3448) (Updates RFC4342) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5348) 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, K. Jaganathan, K. Lauter. September 2008. (Format: TXT=19706 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5349) 5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options. J. Manner, A. McDonald. September 2008. (Format: TXT=17812 bytes) (Updates RFC2113, RFC3175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5350) 5351 An Overview of Reliable Server Pooling Protocols. P. Lei, L. Ong, M. Tuexen, T. Dreibholz. September 2008. (Format: TXT=33062 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5351) 5352 Aggregate Server Access Protocol (ASAP). R. Stewart, Q. Xie, M. Stillman, M. Tuexen. September 2008. (Format: TXT=118712 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5352) 5353 Endpoint Handlespace Redundancy Protocol (ENRP). Q. Xie, R. Stewart, M. Stillman, M. Tuexen, A. Silverton. September 2008. (Format: TXT=83657 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5353) 5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters. R. Stewart, Q. Xie, M. Stillman, M. Tuexen. September 2008. (Format: TXT=50217 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5354) 5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats. M. Stillman, Ed., R. Gopal, E. Guttman, S. Sengodan, M. Holdrege. September 2008. (Format: TXT=38042 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5355) 5356 Reliable Server Pooling Policies. T. Dreibholz, M. Tuexen. September 2008. (Format: TXT=33394 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5356) 5357 A Two-Way Active Measurement Protocol (TWAMP). K. Hedayat, R. Krzanowski, A. Morton, K. Yum, J. Babiarz. October 2008. (Format: TXT=61960 bytes) (Updated by RFC5618, RFC5938, RFC6038, RFC7717, RFC7750) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5357) 5358 Preventing Use of Recursive Nameservers in Reflector Attacks. J. Damas, F. Neves. October 2008. (Format: TXT=14957 bytes) (Also BCP0140) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5358) 5359 Session Initiation Protocol Service Examples. A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. October 2008. (Format: TXT=289446 bytes) (Also BCP0144) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5359) 5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP). J. Rosenberg, G. Camarillo, Ed., D. Willis. October 2008. (Format: TXT=70658 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5360) 5361 A Document Format for Requesting Consent. G. Camarillo. October 2008. (Format: TXT=28256 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5361) 5362 The Session Initiation Protocol (SIP) Pending Additions Event Package. G. Camarillo. October 2008. (Format: TXT=32137 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5362) 5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services. G. Camarillo, A.B. Roach. October 2008. (Format: TXT=22912 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5363) 5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists. M. Garcia-Martin, G. Camarillo. October 2008. (Format: TXT=40497 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5364) 5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP). M. Garcia-Martin, G. Camarillo. October 2008. (Format: TXT=41393 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5365) 5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP). G. Camarillo, A. Johnston. October 2008. (Format: TXT=28369 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5366) 5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP). G. Camarillo, A.B. Roach, O. Levin. October 2008. (Format: TXT=18329 bytes) (Updates RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5367) 5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP). G. Camarillo, A. Niemi, M. Isomaki, M. Garcia-Martin, H. Khartabil. October 2008. (Format: TXT=29389 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5368) 5369 Framework for Transcoding with the Session Initiation Protocol (SIP). G. Camarillo. October 2008. (Format: TXT=20428 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5369) 5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model. G. Camarillo. October 2008. (Format: TXT=23184 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5370) 5371 RTP Payload Format for JPEG 2000 Video Streams. S. Futemma, E. Itakura, A. Leung. October 2008. (Format: TXT=62655 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5371) 5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery. A. Leung, S. Futemma, E. Itakura. October 2008. (Format: TXT=53150 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5372) 5373 Requesting Answering Modes for the Session Initiation Protocol (SIP). D. Willis, Ed., A. Allen. November 2008. (Format: TXT=59839 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5373) 5374 Multicast Extensions to the Security Architecture for the Internet Protocol. B. Weis, G. Gross, D. Ignjatic. November 2008. (Format: TXT=87729 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5374) 5375 IPv6 Unicast Address Assignment Considerations. G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. December 2008. (Format: TXT=83809 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5375) 5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP). N. Bitar, R. Zhang, K. Kumaki. November 2008. (Format: TXT=33114 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5376) 5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents. J. Halpern, Ed.. November 2008. (Format: TXT=17843 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5377) 5378 Rights Contributors Provide to the IETF Trust. S. Bradner, Ed., J. Contreras, Ed.. November 2008. (Format: TXT=37980 bytes) (Obsoletes RFC3978, RFC4748) (Updates RFC2026) (Also BCP0078) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5378) 5379 Guidelines for Using the Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. February 2010. (Format: TXT=52595 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5379) 5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management. H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier. October 2008. (Format: TXT=58330 bytes) (Obsoletes RFC4140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5380) 5381 Experience of Implementing NETCONF over SOAP. T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita. October 2008. (Format: TXT=47724 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5381) 5382 NAT Behavioral Requirements for TCP. S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. October 2008. (Format: TXT=50306 bytes) (Updated by RFC7857) (Also BCP0142) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5382) 5383 Deployment Considerations for Lemonade-Compliant Mobile Email. R. Gellens. October 2008. (Format: TXT=28290 bytes) (Also BCP0143) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5383) 5384 The Protocol Independent Multicast (PIM) Join Attribute Format. A. Boers, I. Wijnands, E. Rosen. November 2008. (Format: TXT=22330 bytes) (Updated by RFC7887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5384) 5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs. J. Touch. February 2010. (Format: TXT=38421 bytes) (Obsoletes RFC3285) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5385) 5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec. N. Williams, M. Richardson. November 2008. (Format: TXT=23103 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5386) 5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS). J. Touch, D. Black, Y. Wang. November 2008. (Format: TXT=71707 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5387) 5388 Information Model and XML Data Model for Traceroute Measurements. S. Niccolini, S. Tartarelli, J. Quittek, T. Dietz, M. Swany. December 2008. (Format: TXT=156801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5388) 5389 Session Traversal Utilities for NAT (STUN). J. Rosenberg, R. Mahy, P. Matthews, D. Wing. October 2008. (Format: TXT=125650 bytes) (Obsoletes RFC3489) (Updated by RFC7350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5389) 5390 Requirements for Management of Overload in the Session Initiation Protocol. J. Rosenberg. December 2008. (Format: TXT=32851 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5390) 5391 RTP Payload Format for ITU-T Recommendation G.711.1. A. Sollaud. November 2008. (Format: TXT=26304 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5391) 5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering. M. Chen, R. Zhang, X. Duan. January 2009. (Format: TXT=38690 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5392) 5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. R. Sparks, Ed., S. Lawrence, A. Hawrylyshen, B. Campen. December 2008. (Format: TXT=48722 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5393) 5394 Policy-Enabled Path Computation Framework. I. Bryskin, D. Papadimitriou, L. Berger, J. Ash. December 2008. (Format: TXT=82226 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5394) 5395 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. November 2008. (Format: TXT=33725 bytes) (Obsoletes RFC2929) (Obsoleted by RFC6195) (Updates RFC1183, RFC3597) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5395) 5396 Textual Representation of Autonomous System (AS) Numbers. G. Huston, G. Michaelson. December 2008. (Format: TXT=5373 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5396) 5397 WebDAV Current Principal Extension. W. Sanchez, C. Daboo. December 2008. (Format: TXT=8828 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5397) 5398 Autonomous System (AS) Number Reservation for Documentation Use. G. Huston. December 2008. (Format: TXT=5433 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5398) 5401 Multicast Negative-Acknowledgment (NACK) Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2008. (Format: TXT=109312 bytes) (Obsoletes RFC3941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5401) 5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message. T. Harding, Ed.. February 2010. (Format: TXT=14469 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5402) 5403 RPCSEC_GSS Version 2. M. Eisler. February 2009. (Format: TXT=30812 bytes) (Updates RFC2203) (Updated by RFC7861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5403) 5404 RTP Payload Format for G.719. M. Westerlund, I. Johansson. January 2009. (Format: TXT=64644 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5404) 5405 Unicast UDP Usage Guidelines for Application Designers. L. Eggert, G. Fairhurst. November 2008. (Format: TXT=69607 bytes) (Also BCP0145) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5405) 5406 Guidelines for Specifying the Use of IPsec Version 2. S. Bellovin. February 2009. (Format: TXT=30393 bytes) (Also BCP0146) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5406) 5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP). M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat. December 2008. (Format: TXT=120005 bytes) (Also BCP0147) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5407) 5408 Identity-Based Encryption Architecture and Supporting Data Structures. G. Appenzeller, L. Martin, M. Schertler. January 2009. (Format: TXT=62160 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5408) 5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS). L. Martin, M. Schertler. January 2009. (Format: TXT=25481 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5409) 5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0. A. Jerichow, Ed., L. Piron. January 2009. (Format: TXT=12444 bytes) (Obsoletes RFC4909) (Updated by RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5410) 5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP). J. Rosenberg. February 2009. (Format: TXT=96538 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5411) 5412 Lightweight Access Point Protocol. P. Calhoun, R. Suri, N. Cam-Winget, M. Williams, S. Hares, B. O'Hara, S. Kelly. February 2010. (Format: TXT=262297 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC5412) 5413 SLAPP: Secure Light Access Point Protocol. P. Narasimhan, D. Harkins, S. Ponnuswamy. February 2010. (Format: TXT=147426 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC5413) 5414 Wireless LAN Control Protocol (WiCoP). S. Iino, S. Govindan, M. Sugiura, H. Cheng. February 2010. (Format: TXT=118969 bytes) (Obsoleted by RFC5415) (Status: HISTORIC) (DOI: 10.17487/RFC5414) 5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification. P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. March 2009. (Format: TXT=345381 bytes) (Obsoletes RFC5414) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5415) 5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11. P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. March 2009. (Format: TXT=175870 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5416) 5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option. P. Calhoun. March 2009. (Format: TXT=11551 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5417) 5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments. S. Kelly, T. Clancy. March 2009. (Format: TXT=74169 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5418) 5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6). B. Patil, G. Dommety. January 2009. (Format: TXT=45178 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5419) 5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE). A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangarps. February 2009. (Format: TXT=47668 bytes) (Obsoletes RFC4420) (Updates RFC3209, RFC3473) (Updated by RFC6510) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5420) 5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST). N. Cam-Winget, H. Zhou. March 2009. (Format: TXT=22345 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5421) 5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST). N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. March 2009. (Format: TXT=85200 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5422) 5423 Internet Message Store Events. R. Gellens, C. Newman. March 2009. (Format: TXT=34800 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5423) 5424 The Syslog Protocol. R. Gerhards. March 2009. (Format: TXT=85162 bytes) (Obsoletes RFC3164) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5424) 5425 Transport Layer Security (TLS) Transport Mapping for Syslog. F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed.. March 2009. (Format: TXT=28159 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5425) 5426 Transmission of Syslog Messages over UDP. A. Okmianski. March 2009. (Format: TXT=19354 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5426) 5427 Textual Conventions for Syslog Management. G. Keeni. March 2009. (Format: TXT=17829 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5427) 5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices. S. Channabasappa, W. De Ketelaere, E. Nechamkin. April 2009. (Format: TXT=78139 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5428) 5429 Sieve Email Filtering: Reject and Extended Reject Extensions. A. Stone, Ed.. March 2009. (Format: TXT=28822 bytes) (Obsoletes RFC3028) (Updates RFC5228) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5429) 5430 Suite B Profile for Transport Layer Security (TLS). M. Salter, E. Rescorla, R. Housley. March 2009. (Format: TXT=27586 bytes) (Obsoleted by RFC6460) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5430) 5431 Diameter ITU-T Rw Policy Enforcement Interface Application. D. Sun. March 2009. (Format: TXT=10412 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5431) 5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP). J. Polk, S. Dhesikan, G. Camarillo. March 2009. (Format: TXT=17614 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5432) 5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method. T. Clancy, H. Tschofenig. February 2009. (Format: TXT=80452 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5433) 5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session. T. Narten. February 2009. (Format: TXT=33887 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5434) 5435 Sieve Email Filtering: Extension for Notifications. A. Melnikov, Ed., B. Leiba, Ed., W. Segmuller, T. Martin. January 2009. (Format: TXT=36181 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5435) 5436 Sieve Notification Mechanism: mailto. B. Leiba, M. Haardt. January 2009. (Format: TXT=26519 bytes) (Updates RFC3834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5436) 5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, A. Melnikov. January 2009. (Format: TXT=28448 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5437) 5438 Instant Message Disposition Notification (IMDN). E. Burger, H. Khartabil. February 2009. (Format: TXT=83723 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5438) 5439 An Analysis of Scaling Issues in MPLS-TE Core Networks. S. Yasukawa, A. Farrel, O. Komolafe. February 2009. (Format: TXT=93845 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5439) 5440 Path Computation Element (PCE) Communication Protocol (PCEP). JP. Vasseur, Ed., JL. Le Roux, Ed.. March 2009. (Format: TXT=190529 bytes) (Updated by RFC7896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5440) 5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths. JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux. April 2009. (Format: TXT=39936 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5441) 5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail. E. Burger, G. Parsons. March 2009. (Format: TXT=28758 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5442) 5443 LDP IGP Synchronization. M. Jork, A. Atlas, L. Fang. March 2009. (Format: TXT=15475 bytes) (Updated by RFC6138) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5443) 5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format. T. Clausen, C. Dearlove, J. Dean, C. Adjih. February 2009. (Format: TXT=139048 bytes) (Updated by RFC7631) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5444) 5445 Basic Forward Error Correction (FEC) Schemes. M. Watson. March 2009. (Format: TXT=41713 bytes) (Obsoletes RFC3452, RFC3695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5445) 5446 Service Selection for Mobile IPv4. J. Korhonen, U. Nilsson. February 2009. (Format: TXT=19089 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5446) 5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury. February 2009. (Format: TXT=38656 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5447) 5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA'). J. Arkko, V. Lehtovirta, P. Eronen. May 2009. (Format: TXT=60641 bytes) (Updates RFC4187) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5448) 5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks. E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen. February 2009. (Format: TXT=67216 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5449) 5450 Transmission Time Offsets in RTP Streams. D. Singer, H. Desineni. March 2009. (Format: TXT=17073 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5450) 5451 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. April 2009. (Format: TXT=97404 bytes) (Obsoleted by RFC7001) (Updated by RFC6577) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5451) 5452 Measures for Making DNS More Resilient against Forged Answers. A. Hubert, R. van Mook. January 2009. (Format: TXT=37432 bytes) (Updates RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5452) 5453 Reserved IPv6 Interface Identifiers. S. Krishnan. February 2009. (Format: TXT=11754 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5453) 5454 Dual-Stack Mobile IPv4. G. Tsirtsis, V. Park, H. Soliman. March 2009. (Format: TXT=38606 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5454) 5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol. S. Sivabalan, Ed., J. Parker, S. Boutros, K. Kumaki. March 2009. (Format: TXT=16780 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5455) 5456 IAX: Inter-Asterisk eXchange Version 2. M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard. February 2010. (Format: TXT=226083 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5456) 5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2. E. Guy, Ed.. February 2010. (Format: TXT=50952 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5457) 5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol. H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar. March 2009. (Format: TXT=58733 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5458) 5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support. A. Sollaud. January 2009. (Format: TXT=14671 bytes) (Updates RFC4749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5459) 5460 DHCPv6 Bulk Leasequery. M. Stapp. February 2009. (Format: TXT=40629 bytes) (Updated by RFC7653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5460) 5461 TCP's Reaction to Soft Errors. F. Gont. February 2009. (Format: TXT=31749 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5461) 5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field. L. Andersson, R. Asati. February 2009. (Format: TXT=19372 bytes) (Updates RFC3032, RFC3270, RFC3272, RFC3443, RFC3469, RFC3564, RFC3985, RFC4182, RFC4364, RFC4379, RFC4448, RFC4761, RFC5129) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5462) 5463 Sieve Email Filtering: Ihave Extension. N. Freed. March 2009. (Format: TXT=12481 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5463) 5464 The IMAP METADATA Extension. C. Daboo. February 2009. (Format: TXT=39425 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5464) 5465 The IMAP NOTIFY Extension. A. Gulbrandsen, C. King, A. Melnikov. February 2009. (Format: TXT=46208 bytes) (Updates RFC5267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5465) 5466 IMAP4 Extension for Named Searches (Filters). A. Melnikov, C. King. February 2009. (Format: TXT=19415 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5466) 5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric. March 2009. (Format: TXT=29335 bytes) (Obsoleted by RFC6387) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5467) 5468 Performance Analysis of Inter-Domain Path Computation Methodologies. S. Dasgupta, J. de Oliveira, JP. Vasseur. April 2009. (Format: TXT=24151 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5468) 5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS). P. Eronen, Ed.. February 2009. (Format: TXT=8558 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5469) 5470 Architecture for IP Flow Information Export. G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. March 2009. (Format: TXT=65717 bytes) (Updated by RFC6183) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5470) 5471 Guidelines for IP Flow Information Export (IPFIX) Testing. C. Schmoll, P. Aitken, B. Claise. March 2009. (Format: TXT=69313 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5471) 5472 IP Flow Information Export (IPFIX) Applicability. T. Zseby, E. Boschi, N. Brownlee, B. Claise. March 2009. (Format: TXT=71379 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5472) 5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports. E. Boschi, L. Mark, B. Claise. March 2009. (Format: TXT=64654 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5473) 5474 A Framework for Packet Selection and Reporting. N. Duffield, Ed., D. Chiou, B. Claise, A. Greenberg, M. Grossglauser, J. Rexford. March 2009. (Format: TXT=86080 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5474) 5475 Sampling and Filtering Techniques for IP Packet Selection. T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall. March 2009. (Format: TXT=101260 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5475) 5476 Packet Sampling (PSAMP) Protocol Specifications. B. Claise, Ed., A. Johnson, J. Quittek. March 2009. (Format: TXT=101620 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5476) 5477 Information Model for Packet Sampling Exports. T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle. March 2009. (Format: TXT=84673 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5477) 5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces. J. Polk. March 2009. (Format: TXT=12810 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5478) 5479 Requirements and Analysis of Media Security Management Protocols. D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet. April 2009. (Format: TXT=99096 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5479) 5480 Elliptic Curve Cryptography Subject Public Key Information. S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. March 2009. (Format: TXT=36209 bytes) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5480) 5481 Packet Delay Variation Applicability Statement. A. Morton, B. Claise. March 2009. (Format: TXT=92218 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5481) 5482 TCP User Timeout Option. L. Eggert, F. Gont. March 2009. (Format: TXT=33568 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5482) 5483 ENUM Implementation Issues and Experiences. L. Conroy, K. Fujiwara. March 2009. (Format: TXT=72780 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5483) 5484 Associating Time-Codes with RTP Streams. D. Singer. March 2009. (Format: TXT=25408 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5484) 5485 Digital Signatures on Internet-Draft Documents. R. Housley. March 2009. (Format: TXT=29582 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5485) 5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology. D. Malas, Ed., D. Meyer, Ed.. March 2009. (Format: TXT=22036 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5486) 5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode. M. Badra. March 2009. (Format: TXT=15537 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5487) 5488 Network Mobility (NEMO) Management Information Base. S. Gundavelli, G. Keeni, K. Koide, K. Nagami. April 2009. (Format: TXT=87041 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5488) 5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS). M. Badra, I. Hajjeh. March 2009. (Format: TXT=14194 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5489) 5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata. A. Melnikov. March 2009. (Format: TXT=16065 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5490) 5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations. J. Winterbottom, M. Thomson, H. Tschofenig. March 2009. (Format: TXT=51681 bytes) (Updates RFC4119) (Updated by RFC7459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5491) 5492 Capabilities Advertisement with BGP-4. J. Scudder, R. Chandra. February 2009. (Format: TXT=13581 bytes) (Obsoletes RFC3392) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5492) 5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network. D. Caviglia, D. Bramanti, D. Li, D. McDysan. April 2009. (Format: TXT=21991 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5493) 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP). J. Arkko, C. Pignataro. April 2009. (Format: TXT=11894 bytes) (Updates RFC0826, RFC0951, RFC1044, RFC1329, RFC2131, RFC2132, RFC2176, RFC2225, RFC2834, RFC2835, RFC3315, RFC4338, RFC4361, RFC4701) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5494) 5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures. D. Li, J. Gao, A. Satyanarayana, S. Bardalai. March 2009. (Format: TXT=39325 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5495) 5496 The Reverse Path Forwarding (RPF) Vector TLV. IJ. Wijnands, A. Boers, E. Rosen. March 2009. (Format: TXT=16754 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5496) 5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs). T. Clausen, C. Dearlove. March 2009. (Format: TXT=30653 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5497) 5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols. I. Chakeres. March 2009. (Format: TXT=8399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5498) 5501 Requirements for Multicast Support in Virtual Private LAN Services. Y. Kamite, Ed., Y. Wada, Y. Serbest, T. Morin, L. Fang. March 2009. (Format: TXT=71507 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5501) 5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem. J. van Elburg. April 2009. (Format: TXT=33553 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5502) 5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture. F. Andreasen, B. McKibben, B. Marshall. March 2009. (Format: TXT=80201 bytes) (Obsoletes RFC3603) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5503) 5504 Downgrading Mechanism for Email Address Internationalization. K. Fujiwara, Ed., Y. Yoneya, Ed.. March 2009. (Format: TXT=48894 bytes) (Obsoleted by RFC6530) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5504) 5505 Principles of Internet Host Configuration. B. Aboba, D. Thaler, L. Andersson, S. Cheshire. May 2009. (Format: TXT=57340 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5505) 5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences. I. Johansson, M. Westerlund. April 2009. (Format: TXT=41011 bytes) (Updates RFC3550, RFC3711, RFC4585) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5506) 5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT=44045 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5507) 5508 NAT Behavioral Requirements for ICMP. P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. April 2009. (Format: TXT=67985 bytes) (Updated by RFC7857) (Also BCP0148) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5508) 5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP). S. Loreto. April 2009. (Format: TXT=10053 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5509) 5510 Reed-Solomon Forward Error Correction (FEC) Schemes. J. Lacan, V. Roca, J. Peltotalo, S. Peltotalo. April 2009. (Format: TXT=57493 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5510) 5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications. A. Farrel. April 2009. (Format: TXT=27026 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5511) 5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute. P. Mohapatra, E. Rosen. April 2009. (Format: TXT=30554 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5512) 5513 IANA Considerations for Three Letter Acronyms. A. Farrel. April 2009. (Format: TXT=13931 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5513) 5514 IPv6 over Social Networks. E. Vyncke. April 2009. (Format: TXT=10127 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5514) 5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions. V. Mammoliti, C. Pignataro, P. Arberg, J. Gibbons, P. Howard. May 2009. (Format: TXT=60768 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5515) 5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). M. Jones, L. Morand. April 2009. (Format: TXT=9105 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5516) 5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment. S. HomChaudhuri, M. Foschiano. February 2010. (Format: TXT=28405 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5517) 5518 Vouch By Reference. P. Hoffman, J. Levine, A. Hathcock. April 2009. (Format: TXT=23730 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5518) 5519 Multicast Group Membership Discovery MIB. J. Chesterfield, B. Haberman, Ed.. April 2009. (Format: TXT=76260 bytes) (Obsoletes RFC2933, RFC3019) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5519) 5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism. R. Bradford, Ed., JP. Vasseur, A. Farrel. April 2009. (Format: TXT=43125 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5520) 5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions. E. Oki, T. Takeda, A. Farrel. April 2009. (Format: TXT=36294 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5521) 5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks. W. Eddy, W. Ivancic, T. Davis. October 2009. (Format: TXT=79570 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5522) 5523 OSPFv3-Based Layer 1 VPN Auto-Discovery. L. Berger. April 2009. (Format: TXT=23473 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5523) 5524 Extended URLFETCH for Binary and Converted Parts. D. Cridland. May 2009. (Format: TXT=15915 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5524) 5525 Reliable Server Pooling MIB Module Definition. T. Dreibholz, J. Mulik. April 2009. (Format: TXT=85897 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5525) 5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM. J. Livingood, P. Pfautz, R. Stastny. April 2009. (Format: TXT=9624 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5526) 5527 Combined User and Infrastructure ENUM in the e164.arpa Tree. M. Haberler, O. Lendl, R. Stastny. May 2009. (Format: TXT=20733 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5527) 5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms. A. Kato, M. Kanda, S. Kanno. April 2009. (Format: TXT=56134 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5528) 5529 Modes of Operation for Camellia for Use with IPsec. A. Kato, M. Kanda, S. Kanno. April 2009. (Format: TXT=13030 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5529) 5530 IMAP Response Codes. A. Gulbrandsen. May 2009. (Format: TXT=17169 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5530) 5531 RPC: Remote Procedure Call Protocol Specification Version 2. R. Thurlow. May 2009. (Format: TXT=161720 bytes) (Obsoletes RFC1831) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5531) 5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement. T. Talpey, C. Juszczak. May 2009. (Format: TXT=36746 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5532) 5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6. E. Nordmark, M. Bagnulo. June 2009. (Format: TXT=299931 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5533) 5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming. J. Arkko, I. van Beijnum. June 2009. (Format: TXT=88152 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5534) 5535 Hash-Based Addresses (HBA). M. Bagnulo. June 2009. (Format: TXT=63994 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5535) 5536 Netnews Article Format. K. Murchison, Ed., C. Lindsey, D. Kohn. November 2009. (Format: TXT=71817 bytes) (Obsoletes RFC1036, RFC1849) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5536) 5537 Netnews Architecture and Protocols. R. Allbery, Ed., C. Lindsey. November 2009. (Format: TXT=120366 bytes) (Obsoletes RFC1036, RFC1849) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5537) 5538 The 'news' and 'nntp' URI Schemes. F. Ellermann. April 2010. (Format: TXT=29470 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5538) 5539 NETCONF over Transport Layer Security (TLS). M. Badra. May 2009. (Format: TXT=16073 bytes) (Obsoleted by RFC7589) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5539) 5540 40 Years of RFCs. RFC Editor. April 2009. (Format: TXT=5579 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5540) 5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP). JL. Le Roux, JP. Vasseur, Y. Lee. June 2009. (Format: TXT=45589 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5541) 5542 Definitions of Textual Conventions for Pseudowire (PW) Management. T. Nadeau, Ed., D. Zelig, Ed., O. Nicklass, Ed.. May 2009. (Format: TXT=19948 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5542) 5543 BGP Traffic Engineering Attribute. H. Ould-Brahim, D. Fedyk, Y. Rekhter. May 2009. (Format: TXT=11883 bytes) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5543) 5544 Syntax for Binding Documents with Time-Stamps. A. Santoni. February 2010. (Format: TXT=26534 bytes) (Updated by RFC5955) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5544) 5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar). B. Desruisseaux, Ed.. September 2009. (Format: TXT=345537 bytes) (Obsoletes RFC2445) (Updated by RFC5546, RFC6868, RFC7529, RFC7953, RFC7986) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5545) 5546 iCalendar Transport-Independent Interoperability Protocol (iTIP). C. Daboo, Ed.. December 2009. (Format: TXT=318143 bytes) (Obsoletes RFC2446) (Updates RFC5545) (Updated by RFC6638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5546) 5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer. M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat. May 2009. (Format: TXT=112625 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5547) 5548 Routing Requirements for Urban Low-Power and Lossy Networks. M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. May 2009. (Format: TXT=47759 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5548) 5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. F. Le Faucheur, E. Rosen. May 2009. (Format: TXT=23637 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5549) 5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile. D. Cridland, Ed., A. Melnikov, Ed., S. Maes, Ed.. August 2009. (Format: TXT=84862 bytes) (Obsoletes RFC4550) (Updates RFC4469, RFC4467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5550) 5551 Lemonade Notifications Architecture. R. Gellens, Ed.. August 2009. (Format: TXT=27542 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5551) 5552 SIP Interface to VoiceXML Media Services. D. Burke, M. Scott. May 2009. (Format: TXT=85063 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5552) 5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support. A. Farrel, Ed., R. Bradford, JP. Vasseur. May 2009. (Format: TXT=30020 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5553) 5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings. N. Williams. May 2009. (Format: TXT=8173 bytes) (Updates RFC2743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5554) 5555 Mobile IPv6 Support for Dual Stack Hosts and Routers. H. Soliman, Ed.. June 2009. (Format: TXT=92387 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5555) 5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement. J. Touch, R. Perlman. May 2009. (Format: TXT=41657 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5556) 5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization. Y. Lee, JL. Le Roux, D. King, E. Oki. July 2009. (Format: TXT=58888 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5557) 5558 Virtual Enterprise Traversal (VET). F. Templin, Ed.. February 2010. (Format: TXT=88504 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5558) 5559 Pre-Congestion Notification (PCN) Architecture. P. Eardley, Ed.. June 2009. (Format: TXT=134827 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5559) 5560 A One-Way Packet Duplication Metric. H. Uijterwaal. May 2009. (Format: TXT=25304 bytes) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5560) 5561 LDP Capabilities. B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux. July 2009. (Format: TXT=27901 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5561) 5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets. A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan. June 2009. (Format: TXT=77110 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5562) 5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4. K. Leung, G. Dommety, P. Yegani, K. Chowdhury. February 2010. (Format: TXT=92438 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5563) 5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains. A. El-Sherbiny, M. Farah, I. Oueichek, A. Al-Zoman. February 2010. (Format: TXT=22850 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5564) 5565 Softwire Mesh Framework. J. Wu, Y. Cui, C. Metz, E. Rosen. June 2009. (Format: TXT=75039 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5565) 5566 BGP IPsec Tunnel Encapsulation Attribute. L. Berger, R. White, E. Rosen. June 2009. (Format: TXT=17416 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5566) 5567 An Architectural Framework for Media Server Control. T. Melanchuk, Ed.. June 2009. (Format: TXT=63384 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5567) 5568 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. July 2009. (Format: TXT=121373 bytes) (Obsoletes RFC5268) (Updated by RFC7411) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5568) 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). R. Despres. January 2010. (Format: TXT=21159 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5569) 5570 Common Architecture Label IPv6 Security Option (CALIPSO). M. StJohns, R. Atkinson, G. Thomas. July 2009. (Format: TXT=128032 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5570) 5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2). B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain, J. Tremblay. June 2009. (Format: TXT=91379 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5571) 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). M. Blanchet, F. Parent. February 2010. (Format: TXT=60017 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5572) 5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP). M. Thomson. June 2009. (Format: TXT=17290 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5573) 5574 RTP Payload Format for the Speex Codec. G. Herlein, J. Valin, A. Heggestad, A. Moizard. June 2009. (Format: TXT=27995 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5574) 5575 Dissemination of Flow Specification Rules. P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. August 2009. (Format: TXT=46473 bytes) (Updated by RFC7674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5575) 5576 Source-Specific Media Attributes in the Session Description Protocol (SDP). J. Lennox, J. Ott, T. Schierl. June 2009. (Format: TXT=40454 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5576) 5577 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi, R. Even. July 2009. (Format: TXT=21705 bytes) (Obsoletes RFC3047) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5577) 5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics. B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams. February 2010. (Format: TXT=54936 bytes) (Obsoletes RFC4938) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5578) 5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces. F. Templin, Ed.. February 2010. (Format: TXT=18998 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5579) 5580 Carrying Location Objects in RADIUS and Diameter. H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba. August 2009. (Format: TXT=119753 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5580) 5581 The Camellia Cipher in OpenPGP. D. Shaw. June 2009. (Format: TXT=5129 bytes) (Updates RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5581) 5582 Location-to-URL Mapping Architecture and Framework. H. Schulzrinne. September 2009. (Format: TXT=42078 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5582) 5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP). T. Schierl, S. Wenger. July 2009. (Format: TXT=40214 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5583) 5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family. M. Hatanaka, J. Matsumoto. July 2009. (Format: TXT=65071 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5584) 5585 DomainKeys Identified Mail (DKIM) Service Overview. T. Hansen, D. Crocker, P. Hallam-Baker. July 2009. (Format: TXT=54110 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5585) 5586 MPLS Generic Associated Channel. M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.. June 2009. (Format: TXT=41482 bytes) (Updates RFC3032, RFC4385, RFC5085) (Updated by RFC6423, RFC7026, RFC7214, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5586) 5587 Extended Generic Security Service Mechanism Inquiry APIs. N. Williams. July 2009. (Format: TXT=32002 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5587) 5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials. N. Williams. July 2009. (Format: TXT=12434 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5588) 5589 Session Initiation Protocol (SIP) Call Control - Transfer. R. Sparks, A. Johnston, Ed., D. Petrie. June 2009. (Format: TXT=119434 bytes) (Also BCP0149) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5589) 5590 Transport Subsystem for the Simple Network Management Protocol (SNMP). D. Harrington, J. Schoenwaelder. June 2009. (Format: TXT=84513 bytes) (Updates RFC3411, RFC3412, RFC3414, RFC3417) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5590) 5591 Transport Security Model for the Simple Network Management Protocol (SNMP). D. Harrington, W. Hardaker. June 2009. (Format: TXT=61747 bytes) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5591) 5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP). D. Harrington, J. Salowey, W. Hardaker. June 2009. (Format: TXT=82822 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5592) 5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension. N. Cook. June 2009. (Format: TXT=18149 bytes) (Updates RFC5092) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5593) 5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008. J. Peterson, A. Cooper. July 2009. (Format: TXT=61652 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5594) 5595 The Datagram Congestion Control Protocol (DCCP) Service Codes. G. Fairhurst. September 2009. (Format: TXT=44803 bytes) (Updates RFC4340) (Updated by RFC6335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5595) 5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal. G. Fairhurst. September 2009. (Format: TXT=57638 bytes) (Updates RFC4340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5596) 5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol. R. Denis-Courmont. September 2009. (Format: TXT=18933 bytes) (Also BCP0150) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5597) 5598 Internet Mail Architecture. D. Crocker. July 2009. (Format: TXT=115741, PDF=342738 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5598) 5601 Pseudowire (PW) Management Information Base (MIB). T. Nadeau, Ed., D. Zelig, Ed.. July 2009. (Format: TXT=129328 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5601) 5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB). D. Zelig, Ed., T. Nadeau, Ed.. July 2009. (Format: TXT=62005 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5602) 5603 Ethernet Pseudowire (PW) Management Information Base (MIB). D. Zelig, Ed., T. Nadeau, Ed.. July 2009. (Format: TXT=44125 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5603) 5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs). O. Nicklass. July 2009. (Format: TXT=80002 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5604) 5605 Managed Objects for ATM over Packet Switched Networks (PSNs). O. Nicklass, T. Nadeau. July 2009. (Format: TXT=69401 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5605) 5606 Implications of 'retransmission-allowed' for SIP Location Conveyance. J. Peterson, T. Hardie, J. Morris. August 2009. (Format: TXT=27960 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5606) 5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management. D. Nelson, G. Weber. July 2009. (Format: TXT=55464 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5607) 5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models. K. Narayan, D. Nelson. August 2009. (Format: TXT=34857 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5608) 5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA). V. Fajardo, Ed., Y. Ohba, R. Marin-Lopez. August 2009. (Format: TXT=63662 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5609) 5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements. E. Boschi, B. Trammell, L. Mark, T. Zseby. July 2009. (Format: TXT=42526 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5610) 5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires. A. Vainshtein, S. Galtzur. August 2009. (Format: TXT=21979 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5611) 5612 Enterprise Number for Documentation Use. P. Eronen, D. Harrington. August 2009. (Format: TXT=6610 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5612) 5613 OSPF Link-Local Signaling. A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung. August 2009. (Format: TXT=23092 bytes) (Obsoletes RFC4813) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5613) 5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding. R. Ogier, P. Spagnolo. August 2009. (Format: TXT=170106 bytes) (Updated by RFC7038) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5614) 5615 H.248/MEGACO Registration Procedures. C. Groves, Y. Lin. August 2009. (Format: TXT=29069 bytes) (Also BCP0151) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5615) 5616 Streaming Internet Messaging Attachments. N. Cook. August 2009. (Format: TXT=65579 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5616) 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). E. Allman, J. Fenton, M. Delany, J. Levine. August 2009. (Format: TXT=43093 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC5617) 5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP). A. Morton, K. Hedayat. August 2009. (Format: TXT=16553 bytes) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5618) 5619 Softwire Security Analysis and Requirements. S. Yamamoto, C. Williams, H. Yokota, F. Parent. August 2009. (Format: TXT=64657 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5619) 5620 RFC Editor Model (Version 1). O. Kolkman, Ed., IAB. August 2009. (Format: TXT=40744 bytes) (Obsoleted by RFC6548, RFC6635) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5620) 5621 Message Body Handling in the Session Initiation Protocol (SIP). G. Camarillo. September 2009. (Format: TXT=43676 bytes) (Updates RFC3204, RFC3261, RFC3459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5621) 5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP). S. Floyd, E. Kohler. August 2009. (Format: TXT=45394 bytes) (Updated by RFC6323) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5622) 5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering. E. Oki, T. Takeda, JL. Le Roux, A. Farrel. September 2009. (Format: TXT=81033 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5623) 5624 Quality of Service Parameters for Usage with Diameter. J. Korhonen, Ed., H. Tschofenig, E. Davies. August 2009. (Format: TXT=23326 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5624) 5625 DNS Proxy Implementation Guidelines. R. Bellis. August 2009. (Format: TXT=24585 bytes) (Also BCP0152) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5625) 5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). C. Jennings, Ed., R. Mahy, Ed., F. Audet, Ed.. October 2009. (Format: TXT=116344 bytes) (Updates RFC3261, RFC3327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5626) 5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP). J. Rosenberg. October 2009. (Format: TXT=94790 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5627) 5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs). P. Kyzivat. October 2009. (Format: TXT=31031 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5628) 5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP). J. Rosenberg. October 2009. (Format: TXT=92959 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5629) 5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP). F. Audet. October 2009. (Format: TXT=114513 bytes) (Updates RFC3261, RFC3608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5630) 5631 Session Initiation Protocol (SIP) Session Mobility. R. Shacham, H. Schulzrinne, S. Thakolsri, W. Kellerer. October 2009. (Format: TXT=89040 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5631) 5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial. C. Griffiths, J. Livingood, L. Popkin, R. Woundy, Y. Yang. September 2009. (Format: TXT=27920 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5632) 5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers. S. Dawkins, Ed.. August 2009. (Format: TXT=11117 bytes) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5633) 5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP). G. Fairhurst, A. Sathiaseelan. August 2009. (Format: TXT=52726 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5634) 5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF). W. Kumari, D. McPherson. August 2009. (Format: TXT=30232 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5635) 5636 Traceable Anonymous Certificate. S. Park, H. Park, Y. Won, J. Lee, S. Kent. August 2009. (Format: TXT=70316 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5636) 5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6. G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez. September 2009. (Format: TXT=23409 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5637) 5638 Simple SIP Usage Scenario for Applications in the Endpoints. H. Sinnreich, Ed., A. Johnston, E. Shim, K. Singh. September 2009. (Format: TXT=45946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5638) 5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation. M. Lochter, J. Merkle. March 2010. (Format: TXT=50566 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5639) 5640 Load-Balancing for Mesh Softwires. C. Filsfils, P. Mohapatra, C. Pignataro. August 2009. (Format: TXT=12250 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5640) 5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values. N. McGill, C. Pignataro. August 2009. (Format: TXT=23133 bytes) (Updates RFC3931, RFC4349, RFC4454, RFC4591, RFC4719) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5641) 5642 Dynamic Hostname Exchange Mechanism for OSPF. S. Venkata, S. Harwani, C. Pignataro, D. McPherson. August 2009. (Format: TXT=19227 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5642) 5643 Management Information Base for OSPFv3. D. Joyal, Ed., V. Manral, Ed.. August 2009. (Format: TXT=192945 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5643) 5644 IP Performance Metrics (IPPM): Spatial and Multicast. E. Stephan, L. Liang, A. Morton. October 2009. (Format: TXT=110407 bytes) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5644) 5645 Update to the Language Subtag Registry. D. Ewell, Ed.. September 2009. (Format: TXT=27902 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5645) 5646 Tags for Identifying Languages. A. Phillips, Ed., M. Davis, Ed.. September 2009. (Format: TXT=208592 bytes) (Obsoletes RFC4646) (Also BCP0047) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5646) 5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol. K. Igoe, J. Solinas. August 2009. (Format: TXT=20990 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5647) 5648 Multiple Care-of Addresses Registration. R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami. October 2009. (Format: TXT=90112 bytes) (Updated by RFC6089) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5648) 5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm. R. Housley, M. Dworkin. September 2009. (Format: TXT=22507 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5649) 5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2). M. Morgenstern, S. Baillie, U. Bonollo. September 2009. (Format: TXT=434687 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5650) 5651 Layered Coding Transport (LCT) Building Block. M. Luby, M. Watson, L. Vicisano. October 2009. (Format: TXT=85751 bytes) (Obsoletes RFC3451) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5651) 5652 Cryptographic Message Syntax (CMS). R. Housley. September 2009. (Format: TXT=126813 bytes) (Obsoletes RFC3852) (Also STD0070) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5652) 5653 Generic Security Service API Version 2: Java Bindings Update. M. Upadhyay, S. Malkani. August 2009. (Format: TXT=209903 bytes) (Obsoletes RFC2853) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5653) 5654 Requirements of an MPLS Transport Profile. B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno. September 2009. (Format: TXT=69999 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5654) 5655 Specification of the IP Flow Information Export (IPFIX) File Format. B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner. October 2009. (Format: TXT=154566 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5655) 5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer. D. Stebila, J. Green. December 2009. (Format: TXT=44259 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5656) 5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard. L. Dusseault, R. Sparks. September 2009. (Format: TXT=29327 bytes) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5657) 5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP). T. Froment, C. Lebel, B. Bonnaerens. October 2009. (Format: TXT=39219 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5658) 5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge. M. Bocci, S. Bryant. October 2009. (Format: TXT=55614 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5659) 5660 IPsec Channels: Connection Latching. N. Williams. October 2009. (Format: TXT=74209 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5660) 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol. S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. January 2010. (Format: TXT=1517771 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5661) 5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description. S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. January 2010. (Format: TXT=126581 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5662) 5663 Parallel NFS (pNFS) Block/Volume Layout. D. Black, S. Fridella, J. Glasgow. January 2010. (Format: TXT=68571 bytes) (Updated by RFC6688) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5663) 5664 Object-Based Parallel NFS (pNFS) Operations. B. Halevy, B. Welch, J. Zelenka. January 2010. (Format: TXT=78200 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5664) 5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats. M. Eisler. January 2010. (Format: TXT=28706 bytes) (Updates RFC1833) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5665) 5666 Remote Direct Memory Access Transport for Remote Procedure Call. T. Talpey, B. Callaghan. January 2010. (Format: TXT=83728 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5666) 5667 Network File System (NFS) Direct Data Placement. T. Talpey, B. Callaghan. January 2010. (Format: TXT=83728 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5667) 5668 4-Octet AS Specific BGP Extended Community. Y. Rekhter, S. Sangli, D. Tappan. October 2009. (Format: TXT=9017 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5668) 5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP). S. Yoon, J. Kim, H. Park, H. Jeong, Y. Won. August 2010. (Format: TXT=24918 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5669) 5670 Metering and Marking Behaviour of PCN-Nodes. P. Eardley, Ed.. November 2009. (Format: TXT=44363 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5670) 5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE). S. Yasukawa, A. Farrel, Ed.. October 2009. (Format: TXT=35176 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5671) 5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update. D. Crocker, Ed.. August 2009. (Format: TXT=29677 bytes) (Obsoleted by RFC6376) (Updates RFC4871) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5672) 5673 Industrial Routing Requirements in Low-Power and Lossy Networks. K. Pister, Ed., P. Thubert, Ed., S. Dwars, T. Phinney. October 2009. (Format: TXT=67934 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5673) 5674 Alarms in Syslog. S. Chisholm, R. Gerhards. October 2009. (Format: TXT=13837 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5674) 5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages. V. Marinov, J. Schoenwaelder. October 2009. (Format: TXT=34379 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5675) 5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications. J. Schoenwaelder, A. Clemm, A. Karmakar. October 2009. (Format: TXT=43160 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5676) 5677 IEEE 802.21 Mobility Services Framework Design (MSFD). T. Melia, Ed., G. Bajko, S. Das, N. Golmie, JC. Zuniga. December 2009. (Format: TXT=57479 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5677) 5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery. G. Bajko, S. Das. December 2009. (Format: TXT=30489 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5678) 5679 Locating IEEE 802.21 Mobility Services Using DNS. G. Bajko. December 2009. (Format: TXT=21127 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5679) 5680 The Nominating Committee Process: Open Disclosure of Willing Nominees. S. Dawkins, Ed.. October 2009. (Format: TXT=14296 bytes) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5680) 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. September 2009. (Format: TXT=44339 bytes) (Obsoletes RFC2581) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5681) 5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP. P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata. September 2009. (Format: TXT=47337 bytes) (Updates RFC4138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5682) 5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange. A. Brusilovsky, I. Faynberg, Z. Zeltsan, S. Patel. February 2010. (Format: TXT=17820 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5683) 5684 Unintended Consequences of NAT Deployments with Overlapping Address Space. P. Srisuresh, B. Ford. February 2010. (Format: TXT=63018 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5684) 5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2). V. Devarapalli, K. Weniger. November 2009. (Format: TXT=35100 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5685) 5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec. Y. Hiwasaki, H. Ohmuro. October 2009. (Format: TXT=44924 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5686) 5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements. H. Tschofenig, H. Schulzrinne. March 2010. (Format: TXT=40880 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5687) 5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes. J. Rosenberg. January 2010. (Format: TXT=15259 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5688) 5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV). C. Daboo. September 2009. (Format: TXT=19838 bytes) (Updates RFC4791, RFC4918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5689) 5690 Adding Acknowledgement Congestion Control to TCP. S. Floyd, A. Arcia, D. Ros, J. Iyengar. February 2010. (Format: TXT=83437 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5690) 5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio. F. de Bont, S. Doehla, M. Schmidt, R. Sperschneider. October 2009. (Format: TXT=26189 bytes) (Updates RFC3640) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5691) 5692 Transmission of IP over Ethernet over IEEE 802.16 Networks. H. Jeon, S. Jeong, M. Riegel. October 2009. (Format: TXT=44724 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5692) 5693 Application-Layer Traffic Optimization (ALTO) Problem Statement. J. Seedorf, E. Burger. October 2009. (Format: TXT=34234 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5693) 5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability. G. Camarillo, Ed., IAB. November 2009. (Format: TXT=68446 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5694) 5695 MPLS Forwarding Benchmarking Methodology for IP Flows. A. Akhter, R. Asati, C. Pignataro. November 2009. (Format: TXT=59976 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5695) 5696 Baseline Encoding and Transport of Pre-Congestion Information. T. Moncaster, B. Briscoe, M. Menth. November 2009. (Format: TXT=33112 bytes) (Obsoleted by RFC6660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5696) 5697 Other Certificates Extension. S. Farrell. November 2009. (Format: TXT=17949 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5697) 5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC). T. Kunz, S. Okunick, U. Pordesch. November 2009. (Format: TXT=76313 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5698) 5701 IPv6 Address Specific BGP Extended Community Attribute. Y. Rekhter. November 2009. (Format: TXT=9626 bytes) (Updated by RFC7153, RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5701) 5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009. (Format: TXT=19425 bytes) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5702) 5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure. T. Hansen, C. Daboo. October 2009. (Format: TXT=34718 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5703) 5704 Uncoordinated Protocol Development Considered Harmful. S. Bryant, Ed., M. Morrow, Ed., IAB. November 2009. (Format: TXT=36383 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5704) 5705 Keying Material Exporters for Transport Layer Security (TLS). E. Rescorla. March 2010. (Format: TXT=16346 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5705) 5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions. D. Harrington. November 2009. (Format: TXT=82165 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5706) 5707 Media Server Markup Language (MSML). A. Saleem, Y. Xin, G. Sharratt. February 2010. (Format: TXT=376984 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5707) 5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System. A. Keromytis. January 2010. (Format: TXT=12529 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5708) 5709 OSPFv2 HMAC-SHA Cryptographic Authentication. M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson. October 2009. (Format: TXT=30221 bytes) (Updates RFC2328) (Updated by RFC7474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5709) 5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes. L. Berger, D. Papadimitriou, JP. Vasseur. January 2010. (Format: TXT=27233 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5710) 5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages. JP. Vasseur, Ed., G. Swallow, I. Minei. January 2010. (Format: TXT=12596 bytes) (Updates RFC3209) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5711) 5712 MPLS Traffic Engineering Soft Preemption. M. Meyer, Ed., JP. Vasseur, Ed.. January 2010. (Format: TXT=27371 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5712) 5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP). H. Moustafa, H. Tschofenig, S. De Cnodder. January 2010. (Format: TXT=39600 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5713) 5714 IP Fast Reroute Framework. M. Shand, S. Bryant. January 2010. (Format: TXT=32854 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5714) 5715 A Framework for Loop-Free Convergence. M. Shand, S. Bryant. January 2010. (Format: TXT=53223 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5715) 5716 Requirements for Federated File Systems. J. Lentini, C. Everhart, D. Ellard, R. Tewari, M. Naik. January 2010. (Format: TXT=58051 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5716) 5717 Partial Lock Remote Procedure Call (RPC) for NETCONF. B. Lengyel, M. Bjorklund. December 2009. (Format: TXT=42529 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5717) 5718 An In-Band Data Communication Network For the MPLS Transport Profile. D. Beller, A. Farrel. January 2010. (Format: TXT=18997 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5718) 5719 Updated IANA Considerations for Diameter Command Code Allocations. D. Romascanu, H. Tschofenig. January 2010. (Format: TXT=11268 bytes) (Obsoleted by RFC6733) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5719) 5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER). F. Templin. February 2010. (Format: TXT=65956 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5720) 5721 POP3 Support for UTF-8. R. Gellens, C. Newman. February 2010. (Format: TXT=26250 bytes) (Obsoleted by RFC6856) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5721) 5722 Handling of Overlapping IPv6 Fragments. S. Krishnan. December 2009. (Format: TXT=11838 bytes) (Updates RFC2460) (Updated by RFC6946) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5722) 5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption. Y. Sheffer, H. Tschofenig. January 2010. (Format: TXT=59201 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5723) 5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS). E. Wilde, A. Vaha-Sipila. January 2010. (Format: TXT=39345 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5724) 5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs). A. Begen, D. Hsu, M. Lague. February 2010. (Format: TXT=18794 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5725) 5726 Mobile IPv6 Location Privacy Solutions. Y. Qiu, F. Zhao, Ed., R. Koodli. February 2010. (Format: TXT=116016 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5726) 5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area. J. Peterson, C. Jennings, R. Sparks. March 2010. (Format: TXT=35033 bytes) (Obsoletes RFC3427) (Updates RFC3265, RFC3969) (Updated by RFC7957) (Also BCP0067) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5727) 5728 The SatLabs Group DVB-RCS MIB. S. Combes, P. Amundsen, M. Lambert, H-P. Lexow. March 2010. (Format: TXT=186132 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5728) 5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm. J. Korhonen, Ed., M. Jones, L. Morand, T. Tsou. December 2009. (Format: TXT=23482 bytes) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5729) 5730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. August 2009. (Format: TXT=134464 bytes) (Obsoletes RFC4930) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5730) 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. August 2009. (Format: TXT=87764 bytes) (Obsoletes RFC4931) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5731) 5732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. August 2009. (Format: TXT=56219 bytes) (Obsoletes RFC4932) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5732) 5733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. August 2009. (Format: TXT=80698 bytes) (Obsoletes RFC4933) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5733) 5734 Extensible Provisioning Protocol (EPP) Transport over TCP. S. Hollenbeck. August 2009. (Format: TXT=27887 bytes) (Obsoletes RFC4934) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5734) 5735 Special Use IPv4 Addresses. M. Cotton, L. Vegoda. January 2010. (Format: TXT=20369 bytes) (Obsoletes RFC3330) (Obsoleted by RFC6890) (Updated by RFC6598) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5735) 5736 IANA IPv4 Special Purpose Address Registry. G. Huston, M. Cotton, L. Vegoda. January 2010. (Format: TXT=10823 bytes) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5736) 5737 IPv4 Address Blocks Reserved for Documentation. J. Arkko, M. Cotton, L. Vegoda. January 2010. (Format: TXT=7036 bytes) (Updates RFC1166) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5737) 5738 IMAP Support for UTF-8. P. Resnick, C. Newman. March 2010. (Format: TXT=32061 bytes) (Obsoleted by RFC6855) (Updates RFC3501) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5738) 5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2). P. Eronen, J. Laganier, C. Madson. February 2010. (Format: TXT=67691 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5739) 5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2009. (Format: TXT=268831 bytes) (Obsoletes RFC3940) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5740) 5741 RFC Streams, Headers, and Boilerplates. L. Daigle, Ed., O. Kolkman, Ed., IAB. December 2009. (Format: TXT=32160 bytes) (Obsoleted by RFC7841) (Updates RFC2223, RFC4844) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5741) 5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions. H. Alvestrand, R. Housley. December 2009. (Format: TXT=21067 bytes) (Obsoletes RFC3932) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5742) 5743 Definition of an Internet Research Task Force (IRTF) Document Stream. A. Falk. December 2009. (Format: TXT=19885 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5743) 5744 Procedures for Rights Handling in the RFC Independent Submission Stream. R. Braden, J. Halpern. December 2009. (Format: TXT=13509 bytes) (Updates RFC4846) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5744) 5745 Procedures for Rights Handling in the RFC IAB Stream. A. Malis, Ed., IAB. December 2009. (Format: TXT=12518 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5745) 5746 Transport Layer Security (TLS) Renegotiation Indication Extension. E. Rescorla, M. Ray, S. Dispensa, N. Oskov. February 2010. (Format: TXT=33790 bytes) (Updates RFC5246, RFC4366, RFC4347, RFC4346, RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5746) 5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions. J. Wu, Y. Cui, X. Li, M. Xu, C. Metz. March 2010. (Format: TXT=33768 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5747) 5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY). S. Yoon, J. Jeong, H. Kim, H. Jeong, Y. Won. August 2010. (Format: TXT=8198 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5748) 5749 Distribution of EAP-Based Keys for Handover and Re-Authentication. K. Hoeper, Ed., M. Nakhjiri, Y. Ohba, Ed.. March 2010. (Format: TXT=27242 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5749) 5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling. B. Ramsdell, S. Turner. January 2010. (Format: TXT=48716 bytes) (Obsoletes RFC3850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5750) 5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification. B. Ramsdell, S. Turner. January 2010. (Format: TXT=98638 bytes) (Obsoletes RFC3851) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5751) 5752 Multiple Signatures in Cryptographic Message Syntax (CMS). S. Turner, J. Schaad. January 2010. (Format: TXT=34502 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5752) 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). S. Turner, D. Brown. January 2010. (Format: TXT=112095 bytes) (Obsoletes RFC3278) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5753) 5754 Using SHA2 Algorithms with Cryptographic Message Syntax. S. Turner. January 2010. (Format: TXT=21543 bytes) (Updates RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5754) 5755 An Internet Attribute Certificate Profile for Authorization. S. Farrell, R. Housley, S. Turner. January 2010. (Format: TXT=101482 bytes) (Obsoletes RFC3281) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5755) 5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters. S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. January 2010. (Format: TXT=12017 bytes) (Updates RFC4055) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5756) 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey. T. Schmidt, M. Waehlisch, G. Fairhurst. February 2010. (Format: TXT=92632 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5757) 5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA. Q. Dang, S. Santesson, K. Moriarty, D. Brown, T. Polk. January 2010. (Format: TXT=15834 bytes) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5758) 5759 Suite B Certificate and Certificate Revocation List (CRL) Profile. J. Solinas, L. Zieglar. January 2010. (Format: TXT=21429 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5759) 5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback. J. Ott, J. Chesterfield, E. Schooler. February 2010. (Format: TXT=160368 bytes) (Updated by RFC6128) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5760) 5761 Multiplexing RTP Data and Control Packets on a Single Port. C. Perkins, M. Westerlund. April 2010. (Format: TXT=31778 bytes) (Updates RFC3550, RFC3551) (Updated by RFC8035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5761) 5762 RTP and the Datagram Congestion Control Protocol (DCCP). C. Perkins. April 2010. (Format: TXT=37537 bytes) (Updated by RFC6773) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5762) 5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS). J. Fischl, H. Tschofenig, E. Rescorla. May 2010. (Format: TXT=81546 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5763) 5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). D. McGrew, E. Rescorla. May 2010. (Format: TXT=60590 bytes) (Updated by RFC7983) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5764) 5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications. H. Schulzrinne, E. Marocco, E. Ivov. February 2010. (Format: TXT=72134 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5765) 5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). R. Mahy, P. Matthews, J. Rosenberg. April 2010. (Format: TXT=172112 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5766) 5767 User-Agent-Driven Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. April 2010. (Format: TXT=23270 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5767) 5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP). J. Rosenberg. April 2010. (Format: TXT=12962 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5768) 5769 Test Vectors for Session Traversal Utilities for NAT (STUN). R. Denis-Courmont. April 2010. (Format: TXT=15407 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5769) 5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators. M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed.. April 2010. (Format: TXT=79767 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5770) 5771 IANA Guidelines for IPv4 Multicast Address Assignments. M. Cotton, L. Vegoda, D. Meyer. March 2010. (Format: TXT=22239 bytes) (Obsoletes RFC3138, RFC3171) (Updates RFC2780) (Also BCP0051) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5771) 5772 A Set of Possible Requirements for a Future Routing Architecture. A. Doria, E. Davies, F. Kastenholz. February 2010. (Format: TXT=158456 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC5772) 5773 Analysis of Inter-Domain Routing Requirements and History. E. Davies, A. Doria. February 2010. (Format: TXT=127384 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC5773) 5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition. K. Wolf, A. Mayrhofer. March 2010. (Format: TXT=68468 bytes) (Updates RFC4776) (Also BCP0154) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5774) 5775 Asynchronous Layered Coding (ALC) Protocol Instantiation. M. Luby, M. Watson, L. Vicisano. April 2010. (Format: TXT=59518 bytes) (Obsoletes RFC3450) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5775) 5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca, A. Francillon, S. Faurite. April 2010. (Format: TXT=135605 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5776) 5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter. J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior. February 2010. (Format: TXT=91305 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5777) 5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction. J. Korhonen, Ed., H. Tschofenig, J. Bournelle, G. Giaretta, M. Nakhjiri. February 2010. (Format: TXT=75444 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5778) 5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server. J. Korhonen, Ed., J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer. February 2010. (Format: TXT=44709 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5779) 5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN). D. MacDonald, B. Lowekamp. May 2010. (Format: TXT=67835 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5780) 5781 The rsync URI Scheme. S. Weiler, D. Ward, R. Housley. February 2010. (Format: TXT=6704 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5781) 5782 DNS Blacklists and Whitelists. J. Levine. February 2010. (Format: TXT=25296 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5782) 5783 Congestion Control in the RFC Series. M. Welzl, W. Eddy. February 2010. (Format: TXT=68231 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5783) 5784 Sieve Email Filtering: Sieves and Display Directives in XML. N. Freed, S. Vedam. March 2010. (Format: TXT=57087 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5784) 5785 Defining Well-Known Uniform Resource Identifiers (URIs). M. Nottingham, E. Hammer-Lahav. April 2010. (Format: TXT=13779 bytes) (Updates RFC2616, RFC2818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5785) 5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions. R. Aggarwal, K. Kompella. March 2010. (Format: TXT=15541 bytes) (Updates RFC3630) (Updated by RFC6827) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5786) 5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing. D. Papadimitriou. March 2010. (Format: TXT=67247 bytes) (Obsoleted by RFC6827) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5787) 5788 IMAP4 Keyword Registry. A. Melnikov, D. Cridland. March 2010. (Format: TXT=22497 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5788) 5789 PATCH Method for HTTP. L. Dusseault, J. Snell. March 2010. (Format: TXT=21706 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5789) 5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols. H. Liu, W. Cao, H. Asaeda. February 2010. (Format: TXT=39394 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5790) 5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete. J. Reschke, J. Kunze. February 2010. (Format: TXT=3658 bytes) (Obsoletes RFC2731) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5791) 5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC). P. Sangster, K. Narayan. March 2010. (Format: TXT=193345 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5792) 5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC). R. Sahita, S. Hanna, R. Hurst, K. Narayan. March 2010. (Format: TXT=169140 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5793) 5794 A Description of the ARIA Encryption Algorithm. J. Lee, J. Lee, J. Kim, D. Kwon, C. Kim. March 2010. (Format: TXT=31049 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5794) 5795 The RObust Header Compression (ROHC) Framework. K. Sandlund, G. Pelletier, L-E. Jonsson. March 2010. (Format: TXT=89850 bytes) (Obsoletes RFC4995) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5795) 5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages. W. Atwood, S. Islam, M. Siami. March 2010. (Format: TXT=45442 bytes) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5796) 5797 FTP Command and Extension Registry. J. Klensin, A. Hoenes. March 2010. (Format: TXT=24535 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5797) 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6. S. Nadas, Ed.. March 2010. (Format: TXT=90322 bytes) (Obsoletes RFC3768) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5798) 5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family. S. Josefsson, N. Williams. July 2010. (Format: TXT=52543 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5801) 5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms. C. Newman, A. Menon-Sen, A. Melnikov, N. Williams. July 2010. (Format: TXT=59049 bytes) (Updated by RFC7677) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5802) 5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets. A. Melnikov. July 2010. (Format: TXT=8195 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5803) 5804 A Protocol for Remotely Managing Sieve Scripts. A. Melnikov, Ed., T. Martin. July 2010. (Format: TXT=103194 bytes) (Updated by RFC7817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5804) 5805 Lightweight Directory Access Protocol (LDAP) Transactions. K. Zeilenga. March 2010. (Format: TXT=21723 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5805) 5806 Diversion Indication in SIP. S. Levy, M. Mohali, Ed.. March 2010. (Format: TXT=107160 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC5806) 5807 Definition of Master Key between PANA Client and Enforcement Point. Y. Ohba, A. Yegin. March 2010. (Format: TXT=13808 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5807) 5808 Requirements for a Location-by-Reference Mechanism. R. Marshall, Ed.. May 2010. (Format: TXT=32475 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5808) 5810 Forwarding and Control Element Separation (ForCES) Protocol Specification. A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern. March 2010. (Format: TXT=239754 bytes) (Updated by RFC7121, RFC7391) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5810) 5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol. J. Hadi Salim, K. Ogawa. March 2010. (Format: TXT=61443 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5811) 5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model. J. Halpern, J. Hadi Salim. March 2010. (Format: TXT=301491 bytes) (Updated by RFC7408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5812) 5813 Forwarding and Control Element Separation (ForCES) MIB. R. Haas. March 2010. (Format: TXT=31353 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5813) 5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks. W. Sun, Ed., G. Zhang, Ed.. March 2010. (Format: TXT=93386 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5814) 5815 Definitions of Managed Objects for IP Flow Information Export. T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. April 2010. (Format: TXT=131258 bytes) (Obsoleted by RFC6615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5815) 5816 ESSCertIDv2 Update for RFC 3161. S. Santesson, N. Pope. April 2010. (Format: TXT=10216 bytes) (Updates RFC3161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5816) 5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks. Z. Ali, JP. Vasseur, A. Zamfir, J. Newton. April 2010. (Format: TXT=24219 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5817) 5818 Data Channel Status Confirmation Extensions for the Link Management Protocol. D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia. April 2010. (Format: TXT=34092 bytes) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5818) 5819 IMAP4 Extension for Returning STATUS Information in Extended LIST. A. Melnikov, T. Sirainen. March 2010. (Format: TXT=10584 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5819) 5820 Extensions to OSPF to Support Mobile Ad Hoc Networking. A. Roy, Ed., M. Chandra, Ed.. March 2010. (Format: TXT=95603 bytes) (Updated by RFC7137) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5820) 5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN. K. Kumaki, Ed., R. Zhang, Y. Kamite. April 2010. (Format: TXT=56102 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5824) 5825 Displaying Downgraded Messages for Email Address Internationalization. K. Fujiwara, B. Leiba. April 2010. (Format: TXT=26314 bytes) (Obsoleted by RFC6530) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5825) 5826 Home Automation Routing Requirements in Low-Power and Lossy Networks. A. Brandt, J. Buron, G. Porcu. April 2010. (Format: TXT=38751 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5826) 5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP). M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig. May 2010. (Format: TXT=35383 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5827) 5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework. D. Fedyk, L. Berger, L. Andersson. March 2010. (Format: TXT=46396 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5828) 5829 Link Relation Types for Simple Version Navigation between Web Resources. A. Brown, G. Clemm, J. Reschke, Ed.. April 2010. (Format: TXT=18649 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5829) 5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms. V. Dolmatov, Ed.. March 2010. (Format: TXT=36234 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5830) 5831 GOST R 34.11-94: Hash Function Algorithm. V. Dolmatov, Ed.. March 2010. (Format: TXT=25844 bytes) (Updated by RFC6986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5831) 5832 GOST R 34.10-2001: Digital Signature Algorithm. V. Dolmatov, Ed.. March 2010. (Format: TXT=38936 bytes) (Updated by RFC7091) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5832) 5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB. Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. May 2010. (Format: TXT=143911 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5833) 5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11. Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. May 2010. (Format: TXT=51144 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5834) 5835 Framework for Metric Composition. A. Morton, Ed., S. Van den Berghe, Ed.. April 2010. (Format: TXT=38138 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5835) 5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement. Y. Ohba, Ed., Q. Wu, Ed., G. Zorn, Ed.. April 2010. (Format: TXT=45912 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5836) 5837 Extending ICMP for Interface and Next-Hop Identification. A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, JR. Rivers. April 2010. (Format: TXT=38109 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5837) 5838 Support of Address Families in OSPFv3. A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal. April 2010. (Format: TXT=26193 bytes) (Updated by RFC6969, RFC7949) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5838) 5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification. A. Niemi, D. Willis, Ed.. May 2010. (Format: TXT=52999 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5839) 5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility. K. Grewal, G. Montenegro, M. Bhatia. April 2010. (Format: TXT=34733 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5840) 5841 TCP Option to Denote Packet Mood. R. Hay, W. Turkal. April 2010. (Format: TXT=15024 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5841) 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV). G. Clemm, J. Crawford, J. Reschke, Ed., J. Whitehead. April 2010. (Format: TXT=91544 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5842) 5843 Additional Hash Algorithms for HTTP Instance Digests. A. Bryan. April 2010. (Format: TXT=6731 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5843) 5844 IPv4 Support for Proxy Mobile IPv6. R. Wakikawa, S. Gundavelli. May 2010. (Format: TXT=116102 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5844) 5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6. A. Muhanna, M. Khalil, S. Gundavelli, K. Leung. June 2010. (Format: TXT=56198 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5845) 5846 Binding Revocation for IPv6 Mobility. A. Muhanna, M. Khalil, S. Gundavelli, K. Chowdhury, P. Yegani. June 2010. (Format: TXT=95467 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5846) 5847 Heartbeat Mechanism for Proxy Mobile IPv6. V. Devarapalli, Ed., R. Koodli, Ed., H. Lim, N. Kant, S. Krishnan, J. Laganier. June 2010. (Format: TXT=23317 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5847) 5848 Signed Syslog Messages. J. Kelsey, J. Callas, A. Clemm. May 2010. (Format: TXT=102805 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5848) 5849 The OAuth 1.0 Protocol. E. Hammer-Lahav, Ed.. April 2010. (Format: TXT=80786 bytes) (Obsoleted by RFC6749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5849) 5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP). R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.. May 2010. (Format: TXT=104361 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5850) 5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks. S. Ooghe, N. Voigt, M. Platnic, T. Haag, S. Wadhwa. May 2010. (Format: TXT=116214 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5851) 5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network. D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai. April 2010. (Format: TXT=49293 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5852) 5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments. J. Hautakorpi, Ed., G. Camarillo, R. Penfield, A. Hawrylyshen, M. Bhatia. April 2010. (Format: TXT=60476 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5853) 5854 The Metalink Download Description Format. A. Bryan, T. Tsujikawa, N. McNab, P. Poeml. June 2010. (Format: TXT=72641 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5854) 5855 Nameservers for IPv4 and IPv6 Reverse Zones. J. Abley, T. Manderson. May 2010. (Format: TXT=23027 bytes) (Also BCP0155) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5855) 5856 Integration of Robust Header Compression over IPsec Security Associations. E. Ertekin, R. Jasani, C. Christou, C. Bormann. May 2010. (Format: TXT=34548 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5856) 5857 IKEv2 Extensions to Support Robust Header Compression over IPsec. E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann. May 2010. (Format: TXT=27063 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5857) 5858 IPsec Extensions to Support Robust Header Compression over IPsec. E. Ertekin, C. Christou, C. Bormann. May 2010. (Format: TXT=31539 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5858) 5859 TFTP Server Address Option for DHCPv4. R. Johnson. June 2010. (Format: TXT=11656 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5859) 5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks. M. Vigoureux, Ed., D. Ward, Ed., M. Betts, Ed.. May 2010. (Format: TXT=36951 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5860) 5861 HTTP Cache-Control Extensions for Stale Content. M. Nottingham. May 2010. (Format: TXT=10359 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5861) 5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE. S. Yasukawa, A. Farrel. June 2010. (Format: TXT=24219 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5862) 5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations. T. Hansen, E. Siegel, P. Hallam-Baker, D. Crocker. May 2010. (Format: TXT=126915 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5863) 5864 DNS SRV Resource Records for AFS. R. Allbery. April 2010. (Format: TXT=23846 bytes) (Updates RFC1183) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5864) 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic. F. Baker, J. Polk, M. Dolly. May 2010. (Format: TXT=33167 bytes) (Updates RFC4542, RFC4594) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5865) 5866 Diameter Quality-of-Service Application. D. Sun, Ed., P. McCann, H. Tschofenig, T. Tsou, A. Doria, G. Zorn, Ed.. May 2010. (Format: TXT=122639 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5866) 5867 Building Automation Routing Requirements in Low-Power and Lossy Networks. J. Martocci, Ed., P. De Mil, N. Riou, W. Vermeylen. June 2010. (Format: TXT=57123 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5867) 5868 Problem Statement on the Cross-Realm Operation of Kerberos. S. Sakane, K. Kamada, S. Zrelli, M. Ishiyama. May 2010. (Format: TXT=30327 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5868) 5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF). H. Krawczyk, P. Eronen. May 2010. (Format: TXT=25854 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5869) 5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI). A. Mayrhofer, C. Spanring. June 2010. (Format: TXT=45943 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5870) 5871 IANA Allocation Guidelines for the IPv6 Routing Header. J. Arkko, S. Bradner. May 2010. (Format: TXT=4000 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5871) 5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA). J. Arkko, A. Yegin. May 2010. (Format: TXT=7999 bytes) (Updates RFC5191) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5872) 5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA). Y. Ohba, A. Yegin. May 2010. (Format: TXT=17137 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5873) 5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources. J. Rosenberg, J. Urpalainen. May 2010. (Format: TXT=49509 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5874) 5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package. J. Urpalainen, D. Willis, Ed.. May 2010. (Format: TXT=58307 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5875) 5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP). J. Elwell. April 2010. (Format: TXT=25860 bytes) (Updates RFC3325) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5876) 5877 The application/pkix-attr-cert Media Type for Attribute Certificates. R. Housley. May 2010. (Format: TXT=6692 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5877) 5878 Transport Layer Security (TLS) Authorization Extensions. M. Brown, R. Housley. May 2010. (Format: TXT=44594 bytes) (Updates RFC5246) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5878) 5879 Heuristics for Detecting ESP-NULL Packets. T. Kivinen, D. McDonald. May 2010. (Format: TXT=72917 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5879) 5880 Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT=110279 bytes) (Updated by RFC7419, RFC7880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5880) 5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop). D. Katz, D. Ward. June 2010. (Format: TXT=14307 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5881) 5882 Generic Application of Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT=40439 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5882) 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths. D. Katz, D. Ward. June 2010. (Format: TXT=11765 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5883) 5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs). R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow. June 2010. (Format: TXT=27734 bytes) (Updates RFC1122) (Updated by RFC7726) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5884) 5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV). T. Nadeau, Ed., C. Pignataro, Ed.. June 2010. (Format: TXT=30866 bytes) (Updated by RFC6478, RFC7885) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5885) 5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture. JP. Vasseur, Ed., JL. Le Roux, Y. Ikejiri. June 2010. (Format: TXT=56554 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5886) 5887 Renumbering Still Needs Work. B. Carpenter, R. Atkinson, H. Flinck. May 2010. (Format: TXT=87131 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5887) 5888 The Session Description Protocol (SDP) Grouping Framework. G. Camarillo, H. Schulzrinne. June 2010. (Format: TXT=43924 bytes) (Obsoletes RFC3388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5888) 5889 IP Addressing Model in Ad Hoc Networks. E. Baccelli, Ed., M. Townsley, Ed.. September 2010. (Format: TXT=14918 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5889) 5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. (Format: TXT=54245 bytes) (Obsoletes RFC3490) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5890) 5891 Internationalized Domain Names in Applications (IDNA): Protocol. J. Klensin. August 2010. (Format: TXT=38105 bytes) (Obsoletes RFC3490, RFC3491) (Updates RFC3492) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5891) 5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA). P. Faltstrom, Ed.. August 2010. (Format: TXT=187370 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5892) 5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA). H. Alvestrand, Ed., C. Karp. August 2010. (Format: TXT=38870 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5893) 5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale. J. Klensin. August 2010. (Format: TXT=115174 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5894) 5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008. P. Resnick, P. Hoffman. September 2010. (Format: TXT=16556 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5895) 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy. L. Hornquist Astrand, S. Hartman. June 2010. (Format: TXT=12846 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5896) 5897 Identification of Communications Services in the Session Initiation Protocol (SIP). J. Rosenberg. June 2010. (Format: TXT=60349 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5897) 5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams. F. Andreasen, G. Camarillo, D. Oran, D. Wing. July 2010. (Format: TXT=38969 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5898) 5901 Extensions to the IODEF-Document Class for Reporting Phishing. P. Cain, D. Jevans. July 2010. (Format: TXT=97325 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5901) 5902 IAB Thoughts on IPv6 Network Address Translation. D. Thaler, L. Zhang, G. Lebovitz. July 2010. (Format: TXT=37224 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5902) 5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2. D. Fu, J. Solinas. June 2010. (Format: TXT=29175 bytes) (Obsoletes RFC4753) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5903) 5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support. G. Zorn. June 2010. (Format: TXT=26879 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5904) 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification. D. Mills, J. Martin, Ed., J. Burbank, W. Kasch. June 2010. (Format: TXT=241096 bytes) (Obsoletes RFC1305, RFC4330) (Updated by RFC7822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5905) 5906 Network Time Protocol Version 4: Autokey Specification. B. Haberman, Ed., D. Mills. June 2010. (Format: TXT=140145 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5906) 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4). H. Gerstung, C. Elliott, B. Haberman, Ed.. June 2010. (Format: TXT=46950 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5907) 5908 Network Time Protocol (NTP) Server Option for DHCPv6. R. Gayraud, B. Lourdelet. June 2010. (Format: TXT=17452 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5908) 5909 Securing Neighbor Discovery Proxy: Problem Statement. J-M. Combes, S. Krishnan, G. Daley. July 2010. (Format: TXT=50433 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5909) 5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP). J. Gould, S. Hollenbeck. May 2010. (Format: TXT=72490 bytes) (Obsoletes RFC4310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5910) 5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME. P. Hoffman, J. Schaad. June 2010. (Format: TXT=101576 bytes) (Updated by RFC6268) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5911) 5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX). P. Hoffman, J. Schaad. June 2010. (Format: TXT=216154 bytes) (Updated by RFC6960) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5912) 5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension. S. Turner, S. Chokhani. June 2010. (Format: TXT=39650 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5913) 5914 Trust Anchor Format. R. Housley, S. Ashmore, C. Wallace. June 2010. (Format: TXT=28393 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5914) 5915 Elliptic Curve Private Key Structure. S. Turner, D. Brown. June 2010. (Format: TXT=13646 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5915) 5916 Device Owner Attribute. S. Turner. June 2010. (Format: TXT=8543 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5916) 5917 Clearance Sponsor Attribute. S. Turner. June 2010. (Format: TXT=11618 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5917) 5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC). R. Asati, I. Minei, B. Thomas. August 2010. (Format: TXT=19414 bytes) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5918) 5919 Signaling LDP Label Advertisement Completion. R. Asati, P. Mohapatra, E. Chen, B. Thomas. August 2010. (Format: TXT=19455 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5919) 5920 Security Framework for MPLS and GMPLS Networks. L. Fang, Ed.. July 2010. (Format: TXT=152830 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5920) 5921 A Framework for MPLS in Transport Networks. M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger. July 2010. (Format: TXT=129318 bytes) (Updated by RFC6215, RFC7274) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5921) 5922 Domain Certificates in the Session Initiation Protocol (SIP). V. Gurbani, S. Lawrence, A. Jeffrey. June 2010. (Format: TXT=37667 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5922) 5923 Connection Reuse in the Session Initiation Protocol (SIP). V. Gurbani, Ed., R. Mahy, B. Tate. June 2010. (Format: TXT=41905 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5923) 5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates. S. Lawrence, V. Gurbani. June 2010. (Format: TXT=16868 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5924) 5925 The TCP Authentication Option. J. Touch, A. Mankin, R. Bonica. June 2010. (Format: TXT=106174 bytes) (Obsoletes RFC2385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5925) 5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO). G. Lebovitz, E. Rescorla. June 2010. (Format: TXT=31010 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5926) 5927 ICMP Attacks against TCP. F. Gont. July 2010. (Format: TXT=87744 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5927) 5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism. M. Petit-Huguenin. August 2010. (Format: TXT=23993 bytes) (Updated by RFC7350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5928) 5929 Channel Bindings for TLS. J. Altman, N. Williams, L. Zhu. July 2010. (Format: TXT=34061 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5929) 5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol. S. Shen, Y. Mao, NSS. Murthy. July 2010. (Format: TXT=12217 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5930) 5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password. D. Harkins, G. Zorn. August 2010. (Format: TXT=90275 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5931) 5932 Camellia Cipher Suites for TLS. A. Kato, M. Kanda, S. Kanno. June 2010. (Format: TXT=11949 bytes) (Obsoletes RFC4132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5932) 5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC. V. Dolmatov, Ed., A. Chuprina, I. Ustinov. July 2010. (Format: TXT=17657 bytes) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5933) 5934 Trust Anchor Management Protocol (TAMP). R. Housley, S. Ashmore, C. Wallace. August 2010. (Format: TXT=196043 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5934) 5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language. M. Ellison, B. Natale. August 2010. (Format: TXT=28164 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5935) 5936 DNS Zone Transfer Protocol (AXFR). E. Lewis, A. Hoenes, Ed.. June 2010. (Format: TXT=66337 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5936) 5937 Using Trust Anchor Constraints during Certification Path Processing. S. Ashmore, C. Wallace. August 2010. (Format: TXT=16900 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5937) 5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP). A. Morton, M. Chiba. August 2010. (Format: TXT=37539 bytes) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5938) 5939 Session Description Protocol (SDP) Capability Negotiation. F. Andreasen. September 2010. (Format: TXT=188116 bytes) (Updated by RFC6871) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5939) 5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices. S. Turner, R. Housley. August 2010. (Format: TXT=15127 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5940) 5941 Sharing Transaction Fraud Data. D. M'Raihi, S. Boeyen, M. Grandcolas, S. Bajaj. August 2010. (Format: TXT=49219 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5941) 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes. H. Singh, W. Beebee, E. Nordmark. July 2010. (Format: TXT=27035 bytes) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5942) 5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing. B. Haberman, Ed.. August 2010. (Format: TXT=9016 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5943) 5944 IP Mobility Support for IPv4, Revised. C. Perkins, Ed.. November 2010. (Format: TXT=239935 bytes) (Obsoletes RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5944) 5945 Resource Reservation Protocol (RSVP) Proxy Approaches. F. Le Faucheur, J. Manner, D. Wing, A. Guillou. October 2010. (Format: TXT=118234 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5945) 5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy. F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, H. Malik. October 2010. (Format: TXT=81414 bytes) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5946) 5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP). J. Elwell, H. Kaplan. September 2010. (Format: TXT=29849 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5947) 5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16. S. Madanapalli, S. Park, S. Chakrabarti, G. Montenegro. August 2010. (Format: TXT=26553 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5948) 5949 Fast Handovers for Proxy Mobile IPv6. H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia. September 2010. (Format: TXT=72722 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5949) 5950 Network Management Framework for MPLS-based Transport Networks. S. Mansfield, Ed., E. Gray, Ed., K. Lam, Ed.. September 2010. (Format: TXT=39502 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5950) 5951 Network Management Requirements for MPLS-based Transport Networks. K. Lam, S. Mansfield, E. Gray. September 2010. (Format: TXT=49993 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5951) 5952 A Recommendation for IPv6 Address Text Representation. S. Kawamura, M. Kawashima. August 2010. (Format: TXT=26570 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5952) 5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP). W. Hardaker. August 2010. (Format: TXT=147393 bytes) (Obsoleted by RFC6353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5953) 5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261. V. Gurbani, Ed., B. Carpenter, Ed., B. Tate, Ed.. August 2010. (Format: TXT=13764 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5954) 5955 The application/timestamped-data Media Type. A. Santoni. August 2010. (Format: TXT=4527 bytes) (Updates RFC5544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5955) 5956 Forward Error Correction Grouping Semantics in the Session Description Protocol. A. Begen. September 2010. (Format: TXT=29530 bytes) (Obsoletes RFC4756) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5956) 5957 Display-Based Address Sorting for the IMAP4 SORT Extension. D. Karp. July 2010. (Format: TXT=8709 bytes) (Updates RFC5256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5957) 5958 Asymmetric Key Packages. S. Turner. August 2010. (Format: TXT=26671 bytes) (Obsoletes RFC5208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5958) 5959 Algorithms for Asymmetric Key Package Content Type. S. Turner. August 2010. (Format: TXT=13983 bytes) (Updated by RFC6162) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5959) 5960 MPLS Transport Profile Data Plane Architecture. D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.. August 2010. (Format: TXT=31764 bytes) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5960) 5961 Improving TCP's Robustness to Blind In-Window Attacks. A. Ramaiah, R. Stewart, M. Dalal. August 2010. (Format: TXT=44717 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5961) 5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO). H. Schulzrinne, V. Singh, H. Tschofenig, M. Thomson. September 2010. (Format: TXT=20109 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5962) 5963 IPv6 Deployment in Internet Exchange Points (IXPs). R. Gagliano. August 2010. (Format: TXT=22786 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5963) 5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries. J. Winterbottom, M. Thomson. August 2010. (Format: TXT=21269 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5964) 5965 An Extensible Format for Email Feedback Reports. Y. Shafranovich, J. Levine, M. Kucherawy. August 2010. (Format: TXT=47452 bytes) (Updated by RFC6650) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5965) 5966 DNS Transport over TCP - Implementation Requirements. R. Bellis. August 2010. (Format: TXT=14970 bytes) (Obsoleted by RFC7766) (Updates RFC1035, RFC1123) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5966) 5967 The application/pkcs10 Media Type. S. Turner. August 2010. (Format: TXT=10928 bytes) (Updates RFC2986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5967) 5968 Guidelines for Extending the RTP Control Protocol (RTCP). J. Ott, C. Perkins. September 2010. (Format: TXT=42541 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5968) 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification. W. Townsley, O. Troan. August 2010. (Format: TXT=45278 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5969) 5970 DHCPv6 Options for Network Boot. T. Huth, J. Freimann, V. Zimmer, D. Thaler. September 2010. (Format: TXT=22660 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5970) 5971 GIST: General Internet Signalling Transport. H. Schulzrinne, R. Hancock. October 2010. (Format: TXT=381127 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5971) 5972 General Internet Signaling Transport (GIST) State Machine. T. Tsenov, H. Tschofenig, X. Fu, Ed., C. Aoun, E. Davies. October 2010. (Format: TXT=53461 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5972) 5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP). M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies. October 2010. (Format: TXT=219962 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5973) 5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling. J. Manner, G. Karagiannis, A. McDonald. October 2010. (Format: TXT=233309 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5974) 5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP). G. Ash, Ed., A. Bader, Ed., C. Kappler, Ed., D. Oran, Ed.. October 2010. (Format: TXT=153418 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5975) 5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes. G. Ash, A. Morton, M. Dolly, P. Tarapore, C. Dvorak, Y. El Mghazli. October 2010. (Format: TXT=42215 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5976) 5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv. A. Bader, L. Westberg, G. Karagiannis, C. Kappler, T. Phelan. October 2010. (Format: TXT=324264 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5977) 5978 Using and Extending the NSIS Protocol Family. J. Manner, R. Bless, J. Loughney, E. Davies, Ed.. October 2010. (Format: TXT=75732 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5978) 5979 NSIS Operation over IP Tunnels. C. Shen, H. Schulzrinne, S. Lee, J. Bang. March 2011. (Format: TXT=69850 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5979) 5980 NSIS Protocol Operation in Mobile Environments. T. Sanda, Ed., X. Fu, S. Jeong, J. Manner, H. Tschofenig. March 2011. (Format: TXT=77323 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5980) 5981 Authorization for NSIS Signaling Layer Protocols. J. Manner, M. Stiemerling, H. Tschofenig, R. Bless, Ed.. February 2011. (Format: TXT=82427 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5981) 5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement. A. Kobayashi, Ed., B. Claise, Ed.. August 2010. (Format: TXT=56005 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5982) 5983 Mailing Lists and Internationalized Email Addresses. R. Gellens. October 2010. (Format: TXT=24462 bytes) (Obsoleted by RFC6783) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5983) 5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding. K-M. Moller. April 2011. (Format: TXT=18055 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5984) 5985 HTTP-Enabled Location Delivery (HELD). M. Barnes, Ed.. September 2010. (Format: TXT=86914 bytes) (Updated by RFC7840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5985) 5986 Discovering the Local Location Information Server (LIS). M. Thomson, J. Winterbottom. September 2010. (Format: TXT=34450 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5986) 5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters. J. Reschke. August 2010. (Format: TXT=20108 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5987) 5988 Web Linking. M. Nottingham. October 2010. (Format: TXT=46834 bytes) (Updates RFC4287) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5988) 5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource. A.B. Roach. October 2010. (Format: TXT=40571 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5989) 5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS). J. Randall, B. Kaliski, J. Brainard, S. Turner. September 2010. (Format: TXT=52579 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5990) 5991 Teredo Security Updates. D. Thaler, S. Krishnan, J. Hoagland. September 2010. (Format: TXT=20847 bytes) (Updates RFC4380) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5991) 5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic. S. Sharikov, D. Miloshevic, J. Klensin. October 2010. (Format: TXT=54378 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5992) 5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR). X. Duan, S. Wang, M. Westerlund, K. Hellwig, I. Johansson. October 2010. (Format: TXT=37824 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5993) 5994 Application of Ethernet Pseudowires to MPLS Transport Networks. S. Bryant, Ed., M. Morrow, G. Swallow, R. Cherukuri, T. Nadeau, N. Harrison, B. Niven-Jenkins. October 2010. (Format: TXT=24394 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5994) 5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections. J. Reschke. September 2010. (Format: TXT=21591 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5995) 5996 Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen. September 2010. (Format: TXT=346466 bytes) (Obsoletes RFC4306, RFC4718) (Obsoleted by RFC7296) (Updated by RFC5998, RFC6989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5996) 5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol. A. DeKok. August 2010. (Format: TXT=55464 bytes) (Updates RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5997) 5998 An Extension for EAP-Only Authentication in IKEv2. P. Eronen, H. Tschofenig, Y. Sheffer. September 2010. (Format: TXT=33477 bytes) (Updates RFC5996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5998) 6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN). D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, JL. Le Roux. October 2010. (Format: TXT=52501 bytes) (Updates RFC4202, RFC4203, RFC4206, RFC4874, RFC4974, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6001) 6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions. L. Berger, D. Fedyk. October 2010. (Format: TXT=23090 bytes) (Updates RFC3471, RFC3473, RFC3945, RFC4202, RFC4203, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6002) 6003 Ethernet Traffic Parameters. D. Papadimitriou. October 2010. (Format: TXT=28232 bytes) (Updates RFC3471, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6003) 6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching. L. Berger, D. Fedyk. October 2010. (Format: TXT=32319 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6004) 6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI). L. Berger, D. Fedyk. October 2010. (Format: TXT=20301 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6005) 6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths. Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric. September 2010. (Format: TXT=68107 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6006) 6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations. I. Nishioka, D. King. September 2010. (Format: TXT=39156 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6007) 6008 Authentication-Results Registration for Differentiating among Cryptographic Results. M. Kucherawy. September 2010. (Format: TXT=14328 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6008) 6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions. N. Freed. October 2010. (Format: TXT=28979 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6009) 6010 Cryptographic Message Syntax (CMS) Content Constraints Extension. R. Housley, S. Ashmore, C. Wallace. September 2010. (Format: TXT=87495 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6010) 6011 Session Initiation Protocol (SIP) User Agent Configuration. S. Lawrence, Ed., J. Elwell. October 2010. (Format: TXT=66205 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6011) 6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. J. Salowey, T. Petch, R. Gerhards, H. Feng. October 2010. (Format: TXT=24475 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6012) 6013 TCP Cookie Transactions (TCPCT). W. Simpson. January 2011. (Format: TXT=76505 bytes) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC6013) 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC. P. Hoffman. November 2010. (Format: TXT=11182 bytes) (Updates RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6014) 6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC). A. Begen. October 2010. (Format: TXT=65399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6015) 6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs. B. Davie, F. Le Faucheur, A. Narayanan. October 2010. (Format: TXT=95185 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6016) 6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field. K. Meadors, Ed.. September 2010. (Format: TXT=8683 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6017) 6018 IPv4 and IPv6 Greynets. F. Baker, W. Harrop, G. Armitage. September 2010. (Format: TXT=21541 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6018) 6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1. R. Housley. September 2010. (Format: TXT=11394 bytes) (Obsoletes RFC4049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6019) 6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF). M. Bjorklund, Ed.. October 2010. (Format: TXT=324178 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6020) 6021 Common YANG Data Types. J. Schoenwaelder, Ed.. October 2010. (Format: TXT=52826 bytes) (Obsoleted by RFC6991) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6021) 6022 YANG Module for NETCONF Monitoring. M. Scott, M. Bjorklund. October 2010. (Format: TXT=46988 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6022) 6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA). Y. Nir, H. Tschofenig, H. Deng, R. Singh. October 2010. (Format: TXT=12560 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6023) 6024 Trust Anchor Management Requirements. R. Reddy, C. Wallace. October 2010. (Format: TXT=33415 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6024) 6025 ASN.1 Translation. C. Wallace, C. Gardiner. October 2010. (Format: TXT=39221 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6025) 6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests. R. Sparks, T. Zourzouvillys. September 2010. (Format: TXT=44035 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6026) 6027 IPsec Cluster Problem Statement. Y. Nir. October 2010. (Format: TXT=27497 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6027) 6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension. G. Camarillo, A. Keranen. October 2010. (Format: TXT=21571 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6028) 6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem. I. Rimac, V. Hilt, M. Tomsu, V. Gurbani, E. Marocco. October 2010. (Format: TXT=48615 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6029) 6030 Portable Symmetric Key Container (PSKC). P. Hoyer, M. Pei, S. Machani. October 2010. (Format: TXT=123974 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6030) 6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type. S. Turner, R. Housley. December 2010. (Format: TXT=56129 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6031) 6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner, R. Housley. December 2010. (Format: TXT=22725 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6032) 6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner. December 2010. (Format: TXT=9818 bytes) (Updated by RFC6161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6033) 6034 Unicast-Prefix-Based IPv4 Multicast Addresses. D. Thaler. October 2010. (Format: TXT=11140 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6034) 6035 Session Initiation Protocol Event Package for Voice Quality Reporting. A. Pendleton, A. Clark, A. Johnston, H. Sinnreich. November 2010. (Format: TXT=84930 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6035) 6036 Emerging Service Provider Scenarios for IPv6 Deployment. B. Carpenter, S. Jiang. October 2010. (Format: TXT=45113 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6036) 6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs. E. Rosen, Ed., Y. Cai, Ed., IJ. Wijnands. October 2010. (Format: TXT=57136 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC6037) 6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features. A. Morton, L. Ciavattone. October 2010. (Format: TXT=41273 bytes) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6038) 6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols. V. Manral, M. Bhatia, J. Jaeggli, R. White. October 2010. (Format: TXT=50788 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6039) 6040 Tunnelling of Explicit Congestion Notification. B. Briscoe. November 2010. (Format: TXT=89412 bytes) (Updates RFC3168, RFC4301, RFC4774) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6040) 6041 Forwarding and Control Element Separation (ForCES) Applicability Statement. A. Crouch, H. Khosravi, A. Doria, Ed., X. Wang, K. Ogawa. October 2010. (Format: TXT=28098 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6041) 6042 Transport Layer Security (TLS) Authorization Using KeyNote. A. Keromytis. October 2010. (Format: TXT=12097 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6042) 6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY). J. Mattsson, T. Tian. March 2011. (Format: TXT=139516 bytes) (Updated by RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6043) 6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP). M. Mohali. October 2010. (Format: TXT=54486 bytes) (Obsoleted by RFC7544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6044) 6045 Real-time Inter-network Defense (RID). K. Moriarty. November 2010. (Format: TXT=172817 bytes) (Obsoleted by RFC6545) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6045) 6046 Transport of Real-time Inter-network Defense (RID) Messages. K. Moriarty, B. Trammell. November 2010. (Format: TXT=14760 bytes) (Obsoleted by RFC6546) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6046) 6047 iCalendar Message-Based Interoperability Protocol (iMIP). A. Melnikov, Ed.. December 2010. (Format: TXT=40697 bytes) (Obsoletes RFC2447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6047) 6048 Network News Transfer Protocol (NNTP) Additions to LIST Command. J. Elie. November 2010. (Format: TXT=50873 bytes) (Updates RFC2980, RFC3977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6048) 6049 Spatial Composition of Metrics. A. Morton, E. Stephan. January 2011. (Format: TXT=57486 bytes) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6049) 6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services. K. Drage. November 2010. (Format: TXT=41021 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6050) 6051 Rapid Synchronisation of RTP Flows. C. Perkins, T. Schierl. November 2010. (Format: TXT=53503 bytes) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6051) 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=41849 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6052) 6053 Implementation Report for Forwarding and Control Element Separation (ForCES). E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim. November 2010. (Format: TXT=72337 bytes) (Updated by RFC6984) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6053) 6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic. D. McGrew, B. Weis. November 2010. (Format: TXT=22672 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6054) 6055 IAB Thoughts on Encodings for Internationalized Domain Names. D. Thaler, J. Klensin, S. Cheshire. February 2011. (Format: TXT=58799 bytes) (Updates RFC2130) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6055) 6056 Recommendations for Transport-Protocol Port Randomization. M. Larsen, F. Gont. January 2011. (Format: TXT=63913 bytes) (Also BCP0156) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6056) 6057 Comcast's Protocol-Agnostic Congestion Management System. C. Bastian, T. Klieber, J. Livingood, J. Mills, R. Woundy. December 2010. (Format: TXT=74685 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6057) 6058 Transient Binding for Proxy Mobile IPv6. M. Liebsch, Ed., A. Muhanna, O. Blume. March 2011. (Format: TXT=90201 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6058) 6059 Simple Procedures for Detecting Network Attachment in IPv6. S. Krishnan, G. Daley. November 2010. (Format: TXT=40655 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6059) 6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE). D. Fedyk, H. Shah, N. Bitar, A. Takacs. March 2011. (Format: TXT=45600 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6060) 6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA). B. Rosen. January 2011. (Format: TXT=14145 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6061) 6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations. S. Perreault, Ed., J. Rosenberg. November 2010. (Format: TXT=28978 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6062) 6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP). A. Doherty, M. Pei, S. Machani, M. Nystrom. December 2010. (Format: TXT=233675 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6063) 6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service. M. Westerlund, P. Frojdh. January 2011. (Format: TXT=44810 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6064) 6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings. K. Narayan, D. Nelson, R. Presuhn, Ed.. December 2010. (Format: TXT=39695 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6065) 6066 Transport Layer Security (TLS) Extensions: Extension Definitions. D. Eastlake 3rd. January 2011. (Format: TXT=55079 bytes) (Obsoletes RFC4366) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6066) 6067 BCP 47 Extension U. M. Davis, A. Phillips, Y. Umaoka. December 2010. (Format: TXT=17012 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6067) 6068 The 'mailto' URI Scheme. M. Duerst, L. Masinter, J. Zawinski. October 2010. (Format: TXT=36683 bytes) (Obsoletes RFC2368) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6068) 6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD). A. Zimmermann, A. Hannemann. December 2010. (Format: TXT=59600 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6069) 6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors. S. Josefsson. January 2011. (Format: TXT=7334 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6070) 6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap. S. Frankel, S. Krishnan. February 2011. (Format: TXT=148655 bytes) (Obsoletes RFC2411) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6071) 6072 Certificate Management Service for the Session Initiation Protocol (SIP). C. Jennings, J. Fischl, Ed.. February 2011. (Format: TXT=69071 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6072) 6073 Segmented Pseudowire. L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui. January 2011. (Format: TXT=102428 bytes) (Updated by RFC6723, RFC7267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6073) 6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs). E. Rosen, B. Davie, V. Radoaca, W. Luo. January 2011. (Format: TXT=76543 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6074) 6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry. D. Cridland. December 2010. (Format: TXT=13088 bytes) (Updates RFC2244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6075) 6076 Basic Telephony SIP End-to-End Performance Metrics. D. Malas, A. Morton. January 2011. (Format: TXT=61559 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6076) 6077 Open Research Issues in Internet Congestion Control. D. Papadimitriou, Ed., M. Welzl, M. Scharf, B. Briscoe. February 2011. (Format: TXT=130169 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6077) 6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS). G. Camarillo, J. Melen. January 2011. (Format: TXT=41482 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6078) 6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE). G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston. January 2011. (Format: TXT=51013 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6079) 6080 A Framework for Session Initiation Protocol User Agent Profile Delivery. D. Petrie, S. Channabasappa, Ed.. March 2011. (Format: TXT=126917 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6080) 6081 Teredo Extensions. D. Thaler. January 2011. (Format: TXT=143419 bytes) (Updates RFC4380) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6081) 6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic. K. Whistler, G. Adams, M. Duerst, R. Presuhn, Ed., J. Klensin. November 2010. (Format: TXT=6633 bytes) (Obsoletes RFC2482) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6082) 6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Seggelmann, E. Rescorla. January 2011. (Format: TXT=16674 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6083) 6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). X. Fu, C. Dickmann, J. Crowcroft. January 2011. (Format: TXT=27040 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6084) 6085 Address Mapping of IPv6 Multicast Packets on Ethernet. S. Gundavelli, M. Townsley, O. Troan, W. Dec. January 2011. (Format: TXT=4968 bytes) (Updates RFC2464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6085) 6086 Session Initiation Protocol (SIP) INFO Method and Package Framework. C. Holmberg, E. Burger, H. Kaplan. January 2011. (Format: TXT=75949 bytes) (Obsoletes RFC2976) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6086) 6087 Guidelines for Authors and Reviewers of YANG Data Model Documents. A. Bierman. January 2011. (Format: TXT=49969 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6087) 6088 Traffic Selectors for Flow Bindings. G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont. January 2011. (Format: TXT=28040 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6088) 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support. G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi. January 2011. (Format: TXT=69353 bytes) (Updates RFC5648) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6089) 6090 Fundamental Elliptic Curve Cryptography Algorithms. D. McGrew, K. Igoe, M. Salter. February 2011. (Format: TXT=75993 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6090) 6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication. N. Mavrogiannopoulos, D. Gillmor. February 2011. (Format: TXT=18529 bytes) (Obsoletes RFC5081) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6091) 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service. J. Woodyatt, Ed.. January 2011. (Format: TXT=91729 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6092) 6093 On the Implementation of the TCP Urgent Mechanism. F. Gont, A. Yourtchenko. January 2011. (Format: TXT=25921 bytes) (Updates RFC0793, RFC1011, RFC1122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6093) 6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols. M. Bhatia, V. Manral. February 2011. (Format: TXT=24583 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6094) 6095 Extending YANG with Language Abstractions. B. Linowski, M. Ersue, S. Kuryla. March 2011. (Format: TXT=140259 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6095) 6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration. M. Tuexen, R. Stewart. January 2011. (Format: TXT=15368 bytes) (Updates RFC4960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6096) 6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6. J. Korhonen, V. Devarapalli. February 2011. (Format: TXT=21682 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6097) 6098 Generic Notification Message for Mobile IPv4. H. Deng, H. Levkowetz, V. Devarapalli, S. Gundavelli, B. Haley. April 2012. (Format: TXT=76848 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6098) 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0. A. Freier, P. Karlton, P. Kocher. August 2011. (Format: TXT=142297 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC6101) 6104 Rogue IPv6 Router Advertisement Problem Statement. T. Chown, S. Venaas. February 2011. (Format: TXT=36518 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6104) 6105 IPv6 Router Advertisement Guard. E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi. February 2011. (Format: TXT=20817 bytes) (Updated by RFC7113) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6105) 6106 IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. November 2010. (Format: TXT=45181 bytes) (Obsoletes RFC5006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6106) 6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths. K. Shiomoto, Ed., A. Farrel, Ed.. February 2011. (Format: TXT=65363 bytes) (Updates RFC3477, RFC4206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6107) 6108 Comcast's Web Notification System Design. C. Chung, A. Kasyanov, J. Livingood, N. Mody, B. Van Lieu. February 2011. (Format: TXT=55329 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6108) 6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail. C. Petrucci, F. Gennai, A. Shahin, A. Vinciarelli. April 2011. (Format: TXT=135569 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6109) 6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content. L. Lhotka, Ed.. February 2011. (Format: TXT=192547 bytes) (Updated by RFC7952) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6110) 6111 Additional Kerberos Naming Constraints. L. Zhu. April 2011. (Format: TXT=14113 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6111) 6112 Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman. April 2011. (Format: TXT=37858 bytes) (Updates RFC4120, RFC4121, RFC4556) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6112) 6113 A Generalized Framework for Kerberos Pre-Authentication. S. Hartman, L. Zhu. April 2011. (Format: TXT=121122 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6113) 6114 The 128-Bit Blockcipher CLEFIA. M. Katagi, S. Moriai. March 2011. (Format: TXT=68618 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6114) 6115 Recommendation for a Routing Architecture. T. Li, Ed.. February 2011. (Format: TXT=178526 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6115) 6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM). S. Bradner, L. Conroy, K. Fujiwara. March 2011. (Format: TXT=52840 bytes) (Obsoletes RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6116) 6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations. B. Hoeneisen, A. Mayrhofer, J. Livingood. March 2011. (Format: TXT=83838 bytes) (Obsoletes RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6117) 6118 Update of Legacy IANA Registrations of Enumservices. B. Hoeneisen, A. Mayrhofer. March 2011. (Format: TXT=115372 bytes) (Updates RFC3762, RFC3764, RFC3953, RFC4143, RFC4002, RFC4238, RFC4355, RFC4415, RFC4769, RFC4969, RFC4979, RFC5028, RFC5278, RFC5333) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6118) 6119 IPv6 Traffic Engineering in IS-IS. J. Harrison, J. Berger, M. Bartlett. February 2011. (Format: TXT=21146 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6119) 6120 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre. March 2011. (Format: TXT=451942 bytes) (Obsoletes RFC3920) (Updated by RFC7590) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6120) 6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. P. Saint-Andre. March 2011. (Format: TXT=244800 bytes) (Obsoletes RFC3921) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6121) 6122 Extensible Messaging and Presence Protocol (XMPP): Address Format. P. Saint-Andre. March 2011. (Format: TXT=50646 bytes) (Obsoleted by RFC7622) (Updates RFC3920) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6122) 6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts. A. Farrel. February 2011. (Format: TXT=28277 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC6123) 6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol. Y. Sheffer, G. Zorn, H. Tschofenig, S. Fluhrer. February 2011. (Format: TXT=71706 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6124) 6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). P. Saint-Andre, J. Hodges. March 2011. (Format: TXT=136507 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6125) 6126 The Babel Routing Protocol. J. Chroboczek. April 2011. (Format: TXT=99833 bytes) (Updated by RFC7298, RFC7557) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6126) 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios. J. Arkko, M. Townsley. May 2011. (Format: TXT=48227 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6127) 6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions. A. Begen. February 2011. (Format: TXT=11544 bytes) (Updates RFC5760) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6128) 6129 The 'application/tei+xml' Media Type. L. Romary, S. Lundberg. February 2011. (Format: TXT=14214 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6129) 6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP). T. Clausen, C. Dearlove, J. Dean. April 2011. (Format: TXT=190678 bytes) (Updated by RFC7183, RFC7188, RFC7466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6130) 6131 Sieve Vacation Extension: "Seconds" Parameter. R. George, B. Leiba. July 2011. (Format: TXT=9407 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6131) 6132 Sieve Notification Using Presence Information. R. George, B. Leiba. July 2011. (Format: TXT=17677 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6132) 6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality. R. George, B. Leiba, A. Melnikov. July 2011. (Format: TXT=17652 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6133) 6134 Sieve Extension: Externally Stored Lists. A. Melnikov, B. Leiba. July 2011. (Format: TXT=37379 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6134) 6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP). C. Holmberg, S. Blau. February 2011. (Format: TXT=17262 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6135) 6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework. A. Sajassi, Ed., D. Mohan, Ed.. March 2011. (Format: TXT=92170 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6136) 6137 The Network Trouble Ticket Data Model (NTTDM). D. Zisiadis, Ed., S. Kopsidas, Ed., M. Tsavli, Ed., G. Cessieux, Ed.. February 2011. (Format: TXT=83462 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6137) 6138 LDP IGP Synchronization for Broadcast Networks. S. Kini, Ed., W. Lu, Ed.. February 2011. (Format: TXT=20161 bytes) (Updates RFC5443) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6138) 6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios. S. Russert, Ed., E. Fleischman, Ed., F. Templin, Ed.. February 2011. (Format: TXT=101101 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6139) 6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP). A.B. Roach. March 2011. (Format: TXT=79372 bytes) (Updates RFC3680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6140) 6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP). G. Camarillo, Ed., C. Holmberg, Y. Gao. March 2011. (Format: TXT=57517 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6141) 6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP. A. Moise, J. Brodkin. March 2011. (Format: TXT=58320 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6142) 6143 The Remote Framebuffer Protocol. T. Richardson, J. Levine. March 2011. (Format: TXT=91737 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6143) 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April 2011. (Format: TXT=67181 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6144) 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April 2011. (Format: TXT=76484 bytes) (Obsoletes RFC2765) (Obsoleted by RFC7915) (Updated by RFC6791, RFC7757) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6145) 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=107954 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6146) 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=75103 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6147) 6148 DHCPv4 Lease Query by Relay Agent Remote ID. P. Kurapati, R. Desetti, B. Joshi. February 2011. (Format: TXT=26185 bytes) (Updates RFC4388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6148) 6149 MD2 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT=14158 bytes) (Obsoletes RFC1319) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6149) 6150 MD4 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT=19583 bytes) (Obsoletes RFC1320) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6150) 6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. S. Turner, L. Chen. March 2011. (Format: TXT=14662 bytes) (Updates RFC1321, RFC2104) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6151) 6152 SMTP Service Extension for 8-bit MIME Transport. J. Klensin, N. Freed, M. Rose, D. Crocker, Ed.. March 2011. (Format: TXT=13034 bytes) (Obsoletes RFC1652) (Also STD0071) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6152) 6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery. S. Das, G. Bajko. February 2011. (Format: TXT=13420 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6153) 6154 IMAP LIST Extension for Special-Use Mailboxes. B. Leiba, J. Nicolson. March 2011. (Format: TXT=25544 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6154) 6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD). J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes. March 2011. (Format: TXT=58542 bytes) (Updated by RFC6915) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6155) 6156 Traversal Using Relays around NAT (TURN) Extension for IPv6. G. Camarillo, O. Novo, S. Perreault, Ed.. April 2011. (Format: TXT=27758 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6156) 6157 IPv6 Transition in the Session Initiation Protocol (SIP). G. Camarillo, K. El Malki, V. Gurbani. April 2011. (Format: TXT=32492 bytes) (Updates RFC3264) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6157) 6158 RADIUS Design Guidelines. A. DeKok, Ed., G. Weber. March 2011. (Format: TXT=89319 bytes) (Updated by RFC6929) (Also BCP0158) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6158) 6159 Session-Specific Explicit Diameter Request Routing. T. Tsou, G. Zorn, T. Taylor, Ed.. April 2011. (Format: TXT=45051 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6159) 6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types. S. Turner. April 2011. (Format: TXT=10115 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6160) 6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner. April 2011. (Format: TXT=5504 bytes) (Updates RFC6033) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6161) 6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type. S. Turner. April 2011. (Format: TXT=6155 bytes) (Updates RFC5959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6162) 6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs). Y. Lee, Ed., G. Bernstein, Ed., W. Imajuku. April 2011. (Format: TXT=115511 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6163) 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links. M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. April 2011. (Format: TXT=16057 bytes) (Updated by RFC6547) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6164) 6165 Extensions to IS-IS for Layer-2 Systems. A. Banerjee, D. Ward. April 2011. (Format: TXT=12266 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6165) 6166 A Registry for PIM Message Types. S. Venaas. April 2011. (Format: TXT=7441 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6166) 6167 URI Scheme for Java(tm) Message Service 1.0. M. Phillips, P. Adams, D. Rokicki, E. Johnson. April 2011. (Format: TXT=44285 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6167) 6168 Requirements for Management of Name Servers for the DNS. W. Hardaker. May 2011. (Format: TXT=36679 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6168) 6169 Security Concerns with IP Tunneling. S. Krishnan, D. Thaler, J. Hoagland. April 2011. (Format: TXT=45018 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6169) 6170 Internet X.509 Public Key Infrastructure -- Certificate Image. S. Santesson, R. Housley, S. Bajaj, L. Rosenthol. May 2011. (Format: TXT=25240 bytes) (Updates RFC3709) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6170) 6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control. K. Zeilenga. March 2011. (Format: TXT=11124 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6171) 6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode. D. Black, D. Peterson. March 2011. (Format: TXT=11625 bytes) (Updates RFC4172) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6172) 6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP). P. Venkatesen, Ed.. March 2011. (Format: TXT=63695 bytes) (Obsoletes RFC4369) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6173) 6174 Definition of IETF Working Group Document States. E. Juskevicius. March 2011. (Format: TXT=56883 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6174) 6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors. E. Juskevicius. March 2011. (Format: TXT=55481 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6175) 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0. S. Turner, T. Polk. March 2011. (Format: TXT=7642 bytes) (Updates RFC2246, RFC4346, RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6176) 6177 IPv6 Address Assignment to End Sites. T. Narten, G. Huston, L. Roberts. March 2011. (Format: TXT=21231 bytes) (Obsoletes RFC3177) (Also BCP0157) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6177) 6178 Label Edge Router Forwarding of IPv4 Option Packets. D. Smith, J. Mullooly, W. Jaeger, T. Scholl. March 2011. (Format: TXT=21645 bytes) (Updates RFC3031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6178) 6179 The Internet Routing Overlay Network (IRON). F. Templin, Ed.. March 2011. (Format: TXT=92638 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6179) 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) 6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses. M. Bagnulo. March 2011. (Format: TXT=44251 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6181) 6182 Architectural Guidelines for Multipath TCP Development. A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar. March 2011. (Format: TXT=68772 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6182) 6183 IP Flow Information Export (IPFIX) Mediation: Framework. A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi. April 2011. (Format: TXT=67997 bytes) (Updates RFC5470) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6183) 6184 RTP Payload Format for H.264 Video. Y.-K. Wang, R. Even, T. Kristensen, R. Jesup. May 2011. (Format: TXT=250627 bytes) (Obsoletes RFC3984) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6184) 6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video. T. Kristensen, P. Luthi. May 2011. (Format: TXT=55562 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6185) 6186 Use of SRV Records for Locating Email Submission/Access Services. C. Daboo. March 2011. (Format: TXT=18895 bytes) (Updates RFC1939, RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6186) 6187 X.509v3 Certificates for Secure Shell Authentication. K. Igoe, D. Stebila. March 2011. (Format: TXT=35208 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6187) 6188 The Use of AES-192 and AES-256 in Secure RTP. D. McGrew. March 2011. (Format: TXT=35973 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6188) 6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP. P. Zimmermann, A. Johnston, Ed., J. Callas. April 2011. (Format: TXT=293784 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6189) 6190 RTP Payload Format for Scalable Video Coding. S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis. May 2011. (Format: TXT=250504 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6190) 6191 Reducing the TIME-WAIT State Using TCP Timestamps. F. Gont. April 2011. (Format: TXT=22953 bytes) (Also BCP0159) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6191) 6192 Protecting the Router Control Plane. D. Dugal, C. Pignataro, R. Dunn. March 2011. (Format: TXT=49422 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6192) 6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP). M. Saito, D. Wing, M. Toyama. April 2011. (Format: TXT=50201 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6193) 6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms. T. Polk, L. Chen, S. Turner, P. Hoffman. March 2011. (Format: TXT=15172 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6194) 6195 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. March 2011. (Format: TXT=33790 bytes) (Obsoletes RFC5395) (Obsoleted by RFC6895) (Updates RFC1183, RFC3597) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6195) 6196 Moving mailserver: URI Scheme to Historic. A. Melnikov. March 2011. (Format: TXT=5679 bytes) (Updates RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6196) 6197 Location-to-Service Translation (LoST) Service List Boundary Extension. K. Wolf. April 2011. (Format: TXT=27562 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6197) 6198 Requirements for the Graceful Shutdown of BGP Sessions. B. Decraene, P. Francois, C. Pelsser, Z. Ahmad, A.J. Elizondo Armengol, T. Takeda. April 2011. (Format: TXT=37906 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6198) 6201 Device Reset Characterization. R. Asati, C. Pignataro, F. Calabria, C. Olvera. March 2011. (Format: TXT=34695 bytes) (Updates RFC1242, RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6201) 6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP. S. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins. April 2011. (Format: TXT=44724 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6202) 6203 IMAP4 Extension for Fuzzy Search. T. Sirainen. March 2011. (Format: TXT=13606 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6203) 6204 Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.. April 2011. (Format: TXT=37026 bytes) (Obsoleted by RFC7084) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6204) 6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers. T. Otani, Ed., D. Li, Ed.. March 2011. (Format: TXT=27749 bytes) (Updates RFC3471) (Updated by RFC7699) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6205) 6206 The Trickle Algorithm. P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko. March 2011. (Format: TXT=30283 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6206) 6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml. R. Denenberg, Ed.. April 2011. (Format: TXT=18090 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6207) 6208 Cloud Data Management Interface (CDMI) Media Types. K. Sankar, Ed., A. Jones. April 2011. (Format: TXT=23187 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6208) 6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS). W. Kim, J. Lee, J. Park, D. Kwon. April 2011. (Format: TXT=19501 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6209) 6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME. J. Schaad. April 2011. (Format: TXT=28339 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6210) 6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute. J. Schaad. April 2011. (Format: TXT=22646 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6211) 6212 Authentication-Results Registration for Vouch by Reference Results. M. Kucherawy. April 2011. (Format: TXT=13199 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6212) 6213 IS-IS BFD-Enabled TLV. C. Hopps, L. Ginsberg. April 2011. (Format: TXT=15527 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6213) 6214 Adaptation of RFC 1149 for IPv6. B. Carpenter, R. Hinden. April 2011. (Format: TXT=15073 bytes) (Updates RFC1149) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6214) 6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces. M. Bocci, L. Levrau, D. Frost. April 2011. (Format: TXT=13619 bytes) (Updates RFC5921) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6215) 6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms. C. Jennings, K. Ono, R. Sparks, B. Hibbard, Ed.. April 2011. (Format: TXT=143891 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6216) 6217 Regional Broadcast Using an Atmospheric Link Layer. T. Ritter. April 2011. (Format: TXT=19546 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6217) 6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material. G. Zorn, T. Zhang, J. Walker, J. Salowey. April 2011. (Format: TXT=34463 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6218) 6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition. X. Li, C. Bao, M. Chen, H. Zhang, J. Wu. May 2011. (Format: TXT=44774 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6219) 6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators. D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed., Internet Architecture Board. April 2011. (Format: TXT=23733 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6220) 6221 Lightweight DHCPv6 Relay Agent. D. Miles, Ed., S. Ooghe, W. Dec, S. Krishnan, A. Kavanagh. May 2011. (Format: TXT=28471 bytes) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6221) 6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). A. Begen, C. Perkins, D. Wing. April 2011. (Format: TXT=20393 bytes) (Obsoleted by RFC7022) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6222) 6223 Indication of Support for Keep-Alive. C. Holmberg. April 2011. (Format: TXT=41439 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6223) 6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains. T. Schmidt, M. Waehlisch, S. Krishnan. April 2011. (Format: TXT=46105 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6224) 6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information. J. Polk, M. Linsner, M. Thomson, B. Aboba, Ed.. July 2011. (Format: TXT=77001 bytes) (Obsoletes RFC3825) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6225) 6226 PIM Group-to-Rendezvous-Point Mapping. B. Joshi, A. Kessler, D. McWalter. May 2011. (Format: TXT=24092 bytes) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6226) 6227 Design Goals for Scalable Internet Routing. T. Li, Ed.. May 2011. (Format: TXT=18418 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6227) 6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog. C. Holmberg. May 2011. (Format: TXT=34311 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6228) 6229 Test Vectors for the Stream Cipher RC4. J. Strombergson, S. Josefsson. May 2011. (Format: TXT=28406 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6229) 6230 Media Control Channel Framework. C. Boulton, T. Melanchuk, S. McGlashan. May 2011. (Format: TXT=112479 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6230) 6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework. S. McGlashan, T. Melanchuk, C. Boulton. May 2011. (Format: TXT=286771 bytes) (Updated by RFC6623) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6231) 6232 Purge Originator Identification TLV for IS-IS. F. Wei, Y. Qin, Z. Li, T. Li, J. Dong. May 2011. (Format: TXT=10234 bytes) (Updates RFC5301, RFC5304, RFC5310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6232) 6233 IS-IS Registry Extension for Purges. T. Li, L. Ginsberg. May 2011. (Format: TXT=8435 bytes) (Updates RFC3563, RFC5304, RFC5310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6233) 6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF). D. Eastlake 3rd, T. Hansen. May 2011. (Format: TXT=236573 bytes) (Obsoletes RFC4634) (Updates RFC3174) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6234) 6235 IP Flow Anonymization Support. E. Boschi, B. Trammell. May 2011. (Format: TXT=112595 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6235) 6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP). I. Johansson, K. Jung. May 2011. (Format: TXT=49356 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6236) 6237 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. May 2011. (Format: TXT=21234 bytes) (Obsoleted by RFC7377) (Updates RFC4466) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6237) 6238 TOTP: Time-Based One-Time Password Algorithm. D. M'Raihi, S. Machani, M. Pei, J. Rydell. May 2011. (Format: TXT=32174 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6238) 6239 Suite B Cryptographic Suites for Secure Shell (SSH). K. Igoe. May 2011. (Format: TXT=28990 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6239) 6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2. D. Zelig, Ed., R. Cohen, Ed., T. Nadeau, Ed.. May 2011. (Format: TXT=129814 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6240) 6241 Network Configuration Protocol (NETCONF). R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.. June 2011. (Format: TXT=209465 bytes) (Obsoletes RFC4741) (Updated by RFC7803) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6241) 6242 Using the NETCONF Protocol over Secure Shell (SSH). M. Wasserman. June 2011. (Format: TXT=22704 bytes) (Obsoletes RFC4742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6242) 6243 With-defaults Capability for NETCONF. A. Bierman, B. Lengyel. June 2011. (Format: TXT=51568 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6243) 6244 An Architecture for Network Management Using NETCONF and YANG. P. Shafer. June 2011. (Format: TXT=63276 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6244) 6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4. P. Yegani, K. Leung, A. Lior, K. Chowdhury, J. Navali. May 2011. (Format: TXT=16823 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6245) 6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges. A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest. June 2011. (Format: TXT=51024 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6246) 6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status. L. Eggert. May 2011. (Format: TXT=6414 bytes) (Obsoletes RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644, RFC1693) (Updates RFC4614) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6247) 6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete. A. Morton. April 2011. (Format: TXT=10192 bytes) (Obsoletes RFC4148) (Updates RFC4737, RFC5560, RFC5644, RFC6049) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6248) 6249 Metalink/HTTP: Mirrors and Hashes. A. Bryan, N. McNab, T. Tsujikawa, P. Poeml, H. Nordstrom. June 2011. (Format: TXT=45303 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6249) 6250 Evolution of the IP Model. D. Thaler. May 2011. (Format: TXT=60778 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6250) 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol. S. Josefsson. May 2011. (Format: TXT=17051 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6251) 6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization. A. Dutta, Ed., V. Fajardo, Y. Ohba, K. Taniuchi, H. Schulzrinne. June 2011. (Format: TXT=149395 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6252) 6253 Host Identity Protocol Certificates. T. Heer, S. Varjonen. May 2011. (Format: TXT=24079 bytes) (Obsoleted by RFC8002) (Updates RFC5201) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6253) 6254 Request to Move RFC 2754 to Historic Status. M. McFadden. May 2011. (Format: TXT=6696 bytes) (Obsoletes RFC2754) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6254) 6255 Delay-Tolerant Networking Bundle Protocol IANA Registries. M. Blanchet. May 2011. (Format: TXT=19606 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6255) 6256 Using Self-Delimiting Numeric Values in Protocols. W. Eddy, E. Davies. May 2011. (Format: TXT=40765 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6256) 6257 Bundle Security Protocol Specification. S. Symington, S. Farrell, H. Weiss, P. Lovell. May 2011. (Format: TXT=142509 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6257) 6258 Delay-Tolerant Networking Metadata Extension Block. S. Symington. May 2011. (Format: TXT=22584 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6258) 6259 Delay-Tolerant Networking Previous-Hop Insertion Block. S. Symington. May 2011. (Format: TXT=23278 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6259) 6260 Compressed Bundle Header Encoding (CBHE). S. Burleigh. May 2011. (Format: TXT=25381 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6260) 6261 Encrypted Signaling Transport Modes for the Host Identity Protocol. A. Keranen. May 2011. (Format: TXT=28354 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6261) 6262 RTP Payload Format for IP-MR Speech Codec. S. Ikonin. August 2011. (Format: TXT=39511 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6262) 6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows. X. Marjou, A. Sollaud. June 2011. (Format: TXT=23345 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6263) 6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition. S. Jiang, D. Guo, B. Carpenter. June 2011. (Format: TXT=31881 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6264) 6265 HTTP State Management Mechanism. A. Barth. April 2011. (Format: TXT=79724 bytes) (Obsoletes RFC2965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6265) 6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP). J. Reschke. June 2011. (Format: TXT=26080 bytes) (Updates RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6266) 6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). V. Cakulev, G. Sundaram. June 2011. (Format: TXT=68031 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6267) 6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX). J. Schaad, S. Turner. July 2011. (Format: TXT=55693 bytes) (Updates RFC5911) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6268) 6269 Issues with IP Address Sharing. M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts. June 2011. (Format: TXT=71660 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6269) 6270 The 'tn3270' URI Scheme. M. Yevstifeyev. June 2011. (Format: TXT=10876 bytes) (Updates RFC2355, RFC1738, RFC1041) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6270) 6271 Requirements for SIP-Based Session Peering. J-F. Mule. June 2011. (Format: TXT=54492 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6271) 6272 Internet Protocols for the Smart Grid. F. Baker, D. Meyer. June 2011. (Format: TXT=162815 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6272) 6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis. A. Kukec, S. Krishnan, S. Jiang. June 2011. (Format: TXT=13100 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6273) 6274 Security Assessment of the Internet Protocol Version 4. F. Gont. July 2011. (Format: TXT=179909 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6274) 6275 Mobility Support in IPv6. C. Perkins, Ed., D. Johnson, J. Arkko. July 2011. (Format: TXT=405488 bytes) (Obsoletes RFC3775) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6275) 6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO). R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos. July 2011. (Format: TXT=30430 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6276) 6277 Online Certificate Status Protocol Algorithm Agility. S. Santesson, P. Hallam-Baker. June 2011. (Format: TXT=21682 bytes) (Obsoleted by RFC6960) (Updates RFC2560) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6277) 6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax. J. Herzog, R. Khazan. June 2011. (Format: TXT=36593 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6278) 6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement. M. Liebsch, Ed., S. Jeong, Q. Wu. June 2011. (Format: TXT=32954 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6279) 6280 An Architecture for Location and Location Privacy in Internet Applications. R. Barnes, M. Lepinski, A. Cooper, J. Morris, H. Tschofenig, H. Schulzrinne. July 2011. (Format: TXT=99801 bytes) (Updates RFC3693, RFC3694) (Also BCP0160) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6280) 6281 Understanding Apple's Back to My Mac (BTMM) Service. S. Cheshire, Z. Zhu, R. Wakikawa, L. Zhang. June 2011. (Format: TXT=39314 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6281) 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. J. Hui, Ed., P. Thubert. September 2011. (Format: TXT=52588 bytes) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6282) 6283 Extensible Markup Language Evidence Record Syntax (XMLERS). A. Jerman Blazic, S. Saljic, T. Gondrom. July 2011. (Format: TXT=99031 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6283) 6284 Port Mapping between Unicast and Multicast RTP Sessions. A. Begen, D. Wing, T. Van Caenegem. June 2011. (Format: TXT=73289 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6284) 6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions. B. Ver Steeg, A. Begen, T. Van Caenegem, Z. Vax. June 2011. (Format: TXT=141497 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6285) 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4. E. Chen, J. Yuan. June 2011. (Format: TXT=7497 bytes) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6286) 6287 OCRA: OATH Challenge-Response Algorithm. D. M'Raihi, J. Rydell, S. Bajaj, S. Machani, D. Naccache. June 2011. (Format: TXT=78076 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6287) 6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG). C. Reed. August 2011. (Format: TXT=16218 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6288) 6289 A Uniform Resource Name (URN) Namespace for CableLabs. E. Cardona, S. Channabasappa, J-F. Mule. June 2011. (Format: TXT=12976 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6289) 6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE). Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi. June 2011. (Format: TXT=48891 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6290) 6291 Guidelines for the Use of the "OAM" Acronym in the IETF. L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. Mansfield. June 2011. (Format: TXT=16696 bytes) (Also BCP0161) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6291) 6292 Requirements for a Working Group Charter Tool. P. Hoffman. June 2011. (Format: TXT=23701 bytes) (Updated by RFC6433) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6292) 6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker. P. Hoffman. June 2011. (Format: TXT=36874 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6293) 6294 Survey of Proposed Use Cases for the IPv6 Flow Label. Q. Hu, B. Carpenter. June 2011. (Format: TXT=43303 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6294) 6295 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. June 2011. (Format: TXT=409730 bytes) (Obsoletes RFC4695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6295) 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6296) 6297 A Survey of Lower-than-Best-Effort Transport Protocols. M. Welzl, D. Ros. June 2011. (Format: TXT=46532 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6297) 6298 Computing TCP's Retransmission Timer. V. Paxson, M. Allman, J. Chu, M. Sargent. June 2011. (Format: TXT=22454 bytes) (Obsoletes RFC2988) (Updates RFC1122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6298) 6301 A Survey of Mobility Support in the Internet. Z. Zhu, R. Wakikawa, L. Zhang. July 2011. (Format: TXT=84861 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6301) 6302 Logging Recommendations for Internet-Facing Servers. A. Durand, I. Gashinsky, D. Lee, S. Sheppard. June 2011. (Format: TXT=10039 bytes) (Also BCP0162) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6302) 6303 Locally Served DNS Zones. M. Andrews. July 2011. (Format: TXT=22503 bytes) (Also BCP0163) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6303) 6304 AS112 Nameserver Operations. J. Abley, W. Maton. July 2011. (Format: TXT=34002 bytes) (Obsoleted by RFC7534) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6304) 6305 I'm Being Attacked by PRISONER.IANA.ORG!. J. Abley, W. Maton. July 2011. (Format: TXT=15287 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6305) 6306 Hierarchical IPv4 Framework. P. Frejborg. July 2011. (Format: TXT=160667 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6306) 6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks. D. Black, Ed., L. Dunbar, Ed., M. Roth, R. Solomon. April 2012. (Format: TXT=49421 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6307) 6308 Overview of the Internet Multicast Addressing Architecture. P. Savola. June 2011. (Format: TXT=30988 bytes) (Obsoletes RFC2908) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6308) 6309 IANA Rules for MIKEY (Multimedia Internet KEYing). J. Arkko, A. Keranen, J. Mattsson. August 2011. (Format: TXT=10706 bytes) (Obsoletes RFC4909) (Updates RFC3830, RFC4563, RFC5410, RFC6043) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6309) 6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping. M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein. July 2011. (Format: TXT=85733 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6310) 6311 Protocol Support for High Availability of IKEv2/IPsec. R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang. July 2011. (Format: TXT=58672 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6311) 6312 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. July 2011. (Format: TXT=45988 bytes) (Obsoleted by RFC6342) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6312) 6313 Export of Structured Data in IP Flow Information Export (IPFIX). B. Claise, G. Dhandapani, P. Aitken, S. Yates. July 2011. (Format: TXT=163360 bytes) (Updates RFC5102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6313) 6314 NAT Traversal Practices for Client-Server SIP. C. Boulton, J. Rosenberg, G. Camarillo, F. Audet. July 2011. (Format: TXT=152998 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6314) 6315 IANA Registration for Enumservice 'iax'. E. Guy, K. Darilion. July 2011. (Format: TXT=11067 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6315) 6316 Sockets Application Program Interface (API) for Multihoming Shim. M. Komu, M. Bagnulo, K. Slavov, S. Sugimoto, Ed.. July 2011. (Format: TXT=93076 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6316) 6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP). M. Komu, T. Henderson. July 2011. (Format: TXT=43970 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6317) 6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME). R. Housley, J. Solinas. June 2011. (Format: TXT=31488 bytes) (Obsoletes RFC5008) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6318) 6319 Issues Associated with Designating Additional Private IPv4 Address Space. M. Azinger, L. Vegoda. July 2011. (Format: TXT=26939 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6319) 6320 Protocol for Access Node Control Mechanism in Broadband Networks. S. Wadhwa, J. Moisand, T. Haag, N. Voigt, T. Taylor, Ed.. October 2011. (Format: TXT=178446 bytes) (Updated by RFC7256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6320) 6321 xCal: The XML Format for iCalendar. C. Daboo, M. Douglass, S. Lees. August 2011. (Format: TXT=79701 bytes) (Updated by RFC6868, RFC7529) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6321) 6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams. P. Hoffman. July 2011. (Format: TXT=24153 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6322) 6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP). G. Renker, G. Fairhurst. July 2011. (Format: TXT=27434 bytes) (Updates RFC4342, RFC5622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6323) 6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations. G. Nakibly, F. Templin. August 2011. (Format: TXT=47385 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6324) 6325 Routing Bridges (RBridges): Base Protocol Specification. R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani. July 2011. (Format: TXT=243158 bytes) (Updated by RFC6327, RFC6439, RFC7172, RFC7177, RFC7357, RFC7179, RFC7180, RFC7455, RFC7780, RFC7783) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6325) 6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS. D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani. July 2011. (Format: TXT=51059 bytes) (Obsoleted by RFC7176) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6326) 6327 Routing Bridges (RBridges): Adjacency. D. Eastlake 3rd, R. Perlman, A. Ghanwani, D. Dutt, V. Manral. July 2011. (Format: TXT=59014 bytes) (Obsoleted by RFC7177) (Updates RFC6325) (Updated by RFC7180) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6327) 6328 IANA Considerations for Network Layer Protocol Identifiers. D. Eastlake 3rd. July 2011. (Format: TXT=16123 bytes) (Also BCP0164) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6328) 6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging. D. Fedyk, Ed., P. Ashwood-Smith, Ed., D. Allan, A. Bragg, P. Unbehagen. April 2012. (Format: TXT=88465 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6329) 6330 RaptorQ Forward Error Correction Scheme for Object Delivery. M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder. August 2011. (Format: TXT=169852 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6330) 6331 Moving DIGEST-MD5 to Historic. A. Melnikov. July 2011. (Format: TXT=14047 bytes) (Obsoletes RFC2831) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6331) 6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs). A. Begen, E. Friedrich. July 2011. (Format: TXT=35217 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6332) 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion. A. Durand, R. Droms, J. Woodyatt, Y. Lee. August 2011. (Format: TXT=65622 bytes) (Updated by RFC7335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6333) 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite. D. Hankins, T. Mrugalski. August 2011. (Format: TXT=14362 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6334) 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire. August 2011. (Format: TXT=79088 bytes) (Updates RFC2780, RFC2782, RFC3828, RFC4340, RFC4960, RFC5595) (Also BCP0165) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6335) 6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options. M. Westerlund, C. Perkins. July 2011. (Format: TXT=8228 bytes) (Updates RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6336) 6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model. S. Okumura, T. Sawada, P. Kyzivat. August 2011. (Format: TXT=76776 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6337) 6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC). V. Giralt, R. McDuff. August 2011. (Format: TXT=21688 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6338) 6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API). S. Josefsson, L. Hornquist Astrand. August 2011. (Format: TXT=13285 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6339) 6340 Textual Conventions for the Representation of Floating-Point Numbers. R. Presuhn. August 2011. (Format: TXT=13811 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6340) 6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC). K. Rehor, Ed., L. Portman, Ed., A. Hutton, R. Jain. August 2011. (Format: TXT=34155 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6341) 6342 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. August 2011. (Format: TXT=46288 bytes) (Obsoletes RFC6312) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6342) 6343 Advisory Guidelines for 6to4 Deployment. B. Carpenter. August 2011. (Format: TXT=51496 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6343) 6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS). G. Bernstein, Ed., D. Caviglia, R. Rabbat, H. van Helvoort. August 2011. (Format: TXT=44897 bytes) (Updates RFC4606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6344) 6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element. P. Duffy, S. Chakrabarti, R. Cragie, Y. Ohba, Ed., A. Yegin. August 2011. (Format: TXT=25128 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6345) 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage. R. Bush, Ed.. August 2011. (Format: TXT=89553 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6346) 6347 Datagram Transport Layer Security Version 1.2. E. Rescorla, N. Modadugu. January 2012. (Format: TXT=73546 bytes) (Obsoletes RFC4347) (Updated by RFC7507, RFC7905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6347) 6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol. JL. Le Roux, Ed., T. Morin, Ed.. September 2011. (Format: TXT=38902 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC6348) 6349 Framework for TCP Throughput Testing. B. Constantine, G. Forget, R. Geib, R. Schrage. August 2011. (Format: TXT=62494 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6349) 6350 vCard Format Specification. S. Perreault. August 2011. (Format: TXT=139895 bytes) (Obsoletes RFC2425, RFC2426, RFC4770) (Updates RFC2739) (Updated by RFC6868) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6350) 6351 xCard: vCard XML Representation. S. Perreault. August 2011. (Format: TXT=34086 bytes) (Updated by RFC6868) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6351) 6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV). C. Daboo. August 2011. (Format: TXT=98548 bytes) (Updated by RFC6764) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6352) 6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP). W. Hardaker. July 2011. (Format: TXT=148571 bytes) (Obsoletes RFC5953) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6353) 6354 Forward-Shifted RTP Redundancy Payload Support. Q. Xie. August 2011. (Format: TXT=26488 bytes) (Updates RFC2198, RFC4102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6354) 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID). T. Narten, J. Johnson. August 2011. (Format: TXT=11453 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6355) 6356 Coupled Congestion Control for Multipath Transport Protocols. C. Raiciu, M. Handley, D. Wischik. October 2011. (Format: TXT=27961 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6356) 6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control. V. Hilt, E. Noel, C. Shen, A. Abdelal. August 2011. (Format: TXT=64252 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6357) 6358 Additional Master Secret Inputs for TLS. P. Hoffman. January 2012. (Format: TXT=9074 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6358) 6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information. S. Ginoza, M. Cotton, A. Morris. September 2011. (Format: TXT=38532 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6359) 6360 Conclusion of FYI RFC Sub-Series. R. Housley. August 2011. (Format: TXT=4729 bytes) (Obsoletes RFC1150) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6360) 6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol. J. Carlson, D. Eastlake 3rd. August 2011. (Format: TXT=17705 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6361) 6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT). K. Meadors, Ed.. August 2011. (Format: TXT=15137 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6362) 6363 Forward Error Correction (FEC) Framework. M. Watson, A. Begen, V. Roca. October 2011. (Format: TXT=98725 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6363) 6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework. A. Begen. October 2011. (Format: TXT=36160 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6364) 6365 Terminology Used in Internationalization in the IETF. P. Hoffman, J. Klensin. September 2011. (Format: TXT=103155 bytes) (Obsoletes RFC3536) (Also BCP0166) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6365) 6366 Requirements for an Internet Audio Codec. J. Valin, K. Vos. August 2011. (Format: TXT=39355 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6366) 6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS). S. Kanno, M. Kanda. September 2011. (Format: TXT=17613 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6367) 6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata. September 2011. (Format: TXT=29938 bytes) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6368) 6369 Forwarding and Control Element Separation (ForCES) Implementation Experience. E. Haleplidis, O. Koufopavlou, S. Denazis. September 2011. (Format: TXT=34236 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6369) 6370 MPLS Transport Profile (MPLS-TP) Identifiers. M. Bocci, G. Swallow, E. Gray. September 2011. (Format: TXT=35294 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6370) 6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks. I. Busi, Ed., D. Allan, Ed.. September 2011. (Format: TXT=142857 bytes) (Updated by RFC6435) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6371) 6372 MPLS Transport Profile (MPLS-TP) Survivability Framework. N. Sprecher, Ed., A. Farrel, Ed.. September 2011. (Format: TXT=142437 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6372) 6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework. L. Andersson, Ed., L. Berger, Ed., L. Fang, Ed., N. Bitar, Ed., E. Gray, Ed.. September 2011. (Format: TXT=144259 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6373) 6374 Packet Loss and Delay Measurement for MPLS Networks. D. Frost, S. Bryant. September 2011. (Format: TXT=123462 bytes) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6374) 6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks. D. Frost, Ed., S. Bryant, Ed.. September 2011. (Format: TXT=10026 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6375) 6376 DomainKeys Identified Mail (DKIM) Signatures. D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.. September 2011. (Format: TXT=176999 bytes) (Obsoletes RFC4871, RFC5672) (Also STD0076) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6376) 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists. M. Kucherawy. September 2011. (Format: TXT=61792 bytes) (Also BCP0167) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6377) 6378 MPLS Transport Profile (MPLS-TP) Linear Protection. Y. Weingarten, Ed., S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Ed.. October 2011. (Format: TXT=99684 bytes) (Updated by RFC7214, RFC7271, RFC7324) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6378) 6379 Suite B Cryptographic Suites for IPsec. L. Law, J. Solinas. October 2011. (Format: TXT=12624 bytes) (Obsoletes RFC4869) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6379) 6380 Suite B Profile for Internet Protocol Security (IPsec). K. Burgin, M. Peck. October 2011. (Format: TXT=21769 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6380) 6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types. R. Gellens, D. Singer, P. Frojdh. August 2011. (Format: TXT=39790 bytes) (Obsoletes RFC4281) (Updates RFC3839, RFC4393, RFC4337) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6381) 6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services. D. McPherson, R. Donnelly, F. Scalzo. October 2011. (Format: TXT=25224 bytes) (Also BCP0169) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6382) 6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE. K. Shiomoto, A. Farrel. September 2011. (Format: TXT=26456 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6383) 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation. I. van Beijnum. October 2011. (Format: TXT=38126 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6384) 6385 General Area Review Team (Gen-ART) Experiences. M. Barnes, A. Doria, H. Alvestrand, B. Carpenter. October 2011. (Format: TXT=53233 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6385) 6386 VP8 Data Format and Decoding Guide. J. Bankoski, J. Koleszar, L. Quillio, J. Salonen, P. Wilkins, Y. Xu. November 2011. (Format: TXT=564613 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6386) 6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). A. Takacs, L. Berger, D. Caviglia, D. Fedyk, J. Meuric. September 2011. (Format: TXT=23329 bytes) (Obsoletes RFC5467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6387) 6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas. November 2011. (Format: TXT=86457 bytes) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6388) 6389 MPLS Upstream Label Assignment for LDP. R. Aggarwal, JL. Le Roux. November 2011. (Format: TXT=30935 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6389) 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also BCP0170) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6390) 6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network. S. Bryant, Ed., C. Filsfils, U. Drafz, V. Kompella, J. Regan, S. Amante. November 2011. (Format: TXT=43848 bytes) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6391) 6392 A Survey of In-Network Storage Systems. R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed.. October 2011. (Format: TXT=90978 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6392) 6393 Moving RFC 4693 to Historic. M. Yevstifeyev. September 2011. (Format: TXT=4252 bytes) (Obsoletes RFC4693) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6393) 6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE). R. Barnes. October 2011. (Format: TXT=29477 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6394) 6395 An Interface Identifier (ID) Hello Option for PIM. S. Gulrajani, S. Venaas. October 2011. (Format: TXT=11469 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6395) 6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format. L. Blunk, M. Karir, C. Labovitz. October 2011. (Format: TXT=73982 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6396) 6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions. T. Manderson. October 2011. (Format: TXT=16864 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6397) 6398 IP Router Alert Considerations and Usage. F. Le Faucheur, Ed.. October 2011. (Format: TXT=44914 bytes) (Updates RFC2113, RFC2711) (Also BCP0168) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6398) 6401 RSVP Extensions for Admission Priority. F. Le Faucheur, J. Polk, K. Carlberg. October 2011. (Format: TXT=72343 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6401) 6402 Certificate Management over CMS (CMC) Updates. J. Schaad. November 2011. (Format: TXT=66722 bytes) (Updates RFC5272, RFC5273, RFC5274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6402) 6403 Suite B Profile of Certificate Management over CMS. L. Zieglar, S. Turner, M. Peck. November 2011. (Format: TXT=36631 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6403) 6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures. J. Seedorf, S. Niccolini, E. Chen, H. Scholz. November 2011. (Format: TXT=54066 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6404) 6405 Voice over IP (VoIP) SIP Peering Use Cases. A. Uzelac, Ed., Y. Lee, Ed.. November 2011. (Format: TXT=51354 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6405) 6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture. D. Malas, Ed., J. Livingood, Ed.. November 2011. (Format: TXT=35032 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6406) 6407 The Group Domain of Interpretation. B. Weis, S. Rowles, T. Hardjono. October 2011. (Format: TXT=147102 bytes) (Obsoletes RFC3547) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6407) 6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage. M. Jones, J. Korhonen, L. Morand. November 2011. (Format: TXT=32490 bytes) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6408) 6409 Message Submission for Mail. R. Gellens, J. Klensin. November 2011. (Format: TXT=40153 bytes) (Obsoletes RFC4409) (Also STD0072) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6409) 6410 Reducing the Standards Track to Two Maturity Levels. R. Housley, D. Crocker, E. Burger. October 2011. (Format: TXT=12619 bytes) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6410) 6411 Applicability of Keying Methods for RSVP Security. M. Behringer, F. Le Faucheur, B. Weis. October 2011. (Format: TXT=46072 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6411) 6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence. S. Poretsky, B. Imhoff, K. Michielsen. November 2011. (Format: TXT=51856 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6412) 6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence. S. Poretsky, B. Imhoff, K. Michielsen. November 2011. (Format: TXT=90935 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6413) 6414 Benchmarking Terminology for Protection Performance. S. Poretsky, R. Papneja, J. Karthik, S. Vapiwala. November 2011. (Format: TXT=55563 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6414) 6415 Web Host Metadata. E. Hammer-Lahav, Ed., B. Cook. October 2011. (Format: TXT=32018 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6415) 6416 RTP Payload Format for MPEG-4 Audio/Visual Streams. M. Schmidt, F. de Bont, S. Doehla, J. Kim. October 2011. (Format: TXT=77031 bytes) (Obsoletes RFC3016) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6416) 6417 How to Contribute Research Results to Internet Standardization. P. Eardley, L. Eggert, M. Bagnulo, R. Winter. November 2011. (Format: TXT=33781 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6417) 6418 Multiple Interfaces and Provisioning Domains Problem Statement. M. Blanchet, P. Seite. November 2011. (Format: TXT=50537 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6418) 6419 Current Practices for Multiple-Interface Hosts. M. Wasserman, P. Seite. November 2011. (Format: TXT=51809 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6419) 6420 PIM Multi-Topology ID (MT-ID) Join Attribute. Y. Cai, H. Ou. November 2011. (Format: TXT=28310 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6420) 6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS). D. Nelson, Ed.. November 2011. (Format: TXT=27028 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6421) 6422 Relay-Supplied DHCP Options. T. Lemon, Q. Wu. December 2011. (Format: TXT=16056 bytes) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6422) 6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP). H. Li, L. Martini, J. He, F. Huang. November 2011. (Format: TXT=9343 bytes) (Updates RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6423) 6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels. N. Bahadur, K. Kompella, G. Swallow. November 2011. (Format: TXT=48270 bytes) (Updates RFC4379) (Updated by RFC7537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6424) 6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping. S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau. November 2011. (Format: TXT=68437 bytes) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6425) 6426 MPLS On-Demand Connectivity Verification and Route Tracing. E. Gray, N. Bahadur, S. Boutros, R. Aggarwal. November 2011. (Format: TXT=46539 bytes) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6426) 6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM). G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward. November 2011. (Format: TXT=34069 bytes) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6427) 6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile. D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed.. November 2011. (Format: TXT=44293 bytes) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6428) 6429 TCP Sender Clarification for Persist Condition. M. Bashyam, M. Jethanandani, A. Ramaiah. December 2011. (Format: TXT=14280 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6429) 6430 Email Feedback Report Type Value: not-spam. K. Li, B. Leiba. November 2011. (Format: TXT=12678 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6430) 6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP). M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou. November 2011. (Format: TXT=33981 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6431) 6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses. R. Jesske, L. Liess. November 2011. (Format: TXT=7487 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6432) 6433 Requirements for a Working Group Milestones Tool. P. Hoffman. November 2011. (Format: TXT=15423 bytes) (Updates RFC6292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6433) 6434 IPv6 Node Requirements. E. Jankiewicz, J. Loughney, T. Narten. December 2011. (Format: TXT=64407 bytes) (Obsoletes RFC4294) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6434) 6435 MPLS Transport Profile Lock Instruct and Loopback Functions. S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed.. November 2011. (Format: TXT=23862 bytes) (Updates RFC6371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6435) 6436 Rationale for Update to the IPv6 Flow Label Specification. S. Amante, B. Carpenter, S. Jiang. November 2011. (Format: TXT=28062 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6436) 6437 IPv6 Flow Label Specification. S. Amante, B. Carpenter, S. Jiang, J. Rajahalme. November 2011. (Format: TXT=35269 bytes) (Obsoletes RFC3697) (Updates RFC2205, RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6437) 6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels. B. Carpenter, S. Amante. November 2011. (Format: TXT=20999 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6438) 6439 Routing Bridges (RBridges): Appointed Forwarders. R. Perlman, D. Eastlake, Y. Li, A. Banerjee, F. Hu. November 2011. (Format: TXT=36978 bytes) (Updates RFC6325) (Updated by RFC7180) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6439) 6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option. G. Zorn, Q. Wu, Y. Wang. December 2011. (Format: TXT=10158 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6440) 6441 Time to Remove Filters for Previously Unallocated IPv4 /8s. L. Vegoda. November 2011. (Format: TXT=8646 bytes) (Also BCP0171) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6441) 6442 Location Conveyance for the Session Initiation Protocol. J. Polk, B. Rosen, J. Peterson. December 2011. (Format: TXT=80795 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6442) 6443 Framework for Emergency Calling Using Internet Multimedia. B. Rosen, H. Schulzrinne, J. Polk, A. Newton. December 2011. (Format: TXT=98096 bytes) (Updated by RFC7852) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6443) 6444 Location Hiding: Problem Statement and Requirements. H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett. January 2012. (Format: TXT=18495 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6444) 6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute. T. Nadeau, Ed., A. Koushik, Ed., R. Cetin, Ed.. November 2011. (Format: TXT=101627 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6445) 6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control. A. Niemi, K. Kiss, S. Loreto. January 2012. (Format: TXT=57971 bytes) (Updates RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6446) 6447 Filtering Location Notifications in the Session Initiation Protocol (SIP). R. Mahy, B. Rosen, H. Tschofenig. January 2012. (Format: TXT=36577 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6447) 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message. R. Yount. November 2011. (Format: TXT=8369 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6448) 6449 Complaint Feedback Loop Operational Recommendations. J. Falk, Ed.. November 2011. (Format: TXT=75139 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6449) 6450 Multicast Ping Protocol. S. Venaas. December 2011. (Format: TXT=59420 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6450) 6451 Location-to-Service Translation (LoST) Protocol Extensions. A. Forte, H. Schulzrinne. December 2011. (Format: TXT=45682 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6451) 6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0. P. Faltstrom, Ed., P. Hoffman, Ed.. November 2011. (Format: TXT=6817 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6452) 6453 A URN Namespace for the Open Grid Forum (OGF). F. Dijkstra, R. Hughes-Jones. December 2011. (Format: TXT=16678 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6453) 6454 The Web Origin Concept. A. Barth. December 2011. (Format: TXT=41363 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6454) 6455 The WebSocket Protocol. I. Fette, A. Melnikov. December 2011. (Format: TXT=162067 bytes) (Updated by RFC7936) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6455) 6456 Multi-Segment Pseudowires in Passive Optical Networks. H. Li, R. Zheng, A. Farrel. November 2011. (Format: TXT=27499 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6456) 6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering. T. Takeda, Ed., A. Farrel. December 2011. (Format: TXT=29107 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6457) 6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP). R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich. December 2011. (Format: TXT=237112 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6458) 6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. January 2012. (Format: TXT=84769 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6459) 6460 Suite B Profile for Transport Layer Security (TLS). M. Salter, R. Housley. January 2012. (Format: TXT=31428 bytes) (Obsoletes RFC5430) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6460) 6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements. S. Channabasappa, Ed.. January 2012. (Format: TXT=36435 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6461) 6462 Report from the Internet Privacy Workshop. A. Cooper. January 2012. (Format: TXT=55638 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6462) 6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6. J. Korhonen, Ed., S. Gundavelli, H. Yokota, X. Cui. February 2012. (Format: TXT=50702 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6463) 6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication. J. Lennox, Ed., E. Ivov, E. Marocco. December 2011. (Format: TXT=18809 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6464) 6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication. E. Ivov, Ed., E. Marocco, Ed., J. Lennox. December 2011. (Format: TXT=30154 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6465) 6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP). G. Salgueiro. December 2011. (Format: TXT=11660 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6466) 6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2). T. Kivinen. December 2011. (Format: TXT=21987 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6467) 6468 Sieve Notification Mechanism: SIP MESSAGE. A. Melnikov, B. Leiba, K. Li. February 2012. (Format: TXT=21331 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6468) 6469 RTP Payload Format for DV (IEC 61834) Video. K. Kobayashi, K. Mishima, S. Casner, C. Bormann. December 2011. (Format: TXT=38041 bytes) (Obsoletes RFC3189) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6469) 6470 Network Configuration Protocol (NETCONF) Base Notifications. A. Bierman. February 2012. (Format: TXT=26361 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6470) 6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices. C. Lewis, M. Sergeant. January 2012. (Format: TXT=49264 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6471) 6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP. W. Kumari, K. Sriram. December 2011. (Format: TXT=10673 bytes) (Also BCP0172) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6472) 6473 vCard KIND:application. P. Saint-Andre. December 2011. (Format: TXT=9776 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6473) 6474 vCard Format Extensions: Place of Birth, Place and Date of Death. K. Li, B. Leiba. December 2011. (Format: TXT=8884 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6474) 6475 Proxy Mobile IPv6 Management Information Base. G. Keeni, K. Koide, S. Gundavelli, R. Wakikawa. May 2012. (Format: TXT=132402 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6475) 6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS). P. Gutmann. January 2012. (Format: TXT=33186 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6476) 6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail. A. Melnikov, G. Lunt. January 2012. (Format: TXT=43492 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6477) 6478 Pseudowire Status for Static Pseudowires. L. Martini, G. Swallow, G. Heron, M. Bocci. May 2012. (Format: TXT=28285 bytes) (Updates RFC5885) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6478) 6479 IPsec Anti-Replay Algorithm without Bit Shifting. X. Zhang, T. Tsou. January 2012. (Format: TXT=16619 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6479) 6480 An Infrastructure to Support Secure Internet Routing. M. Lepinski, S. Kent. February 2012. (Format: TXT=62127 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6480) 6481 A Profile for Resource Certificate Repository Structure. G. Huston, R. Loomans, G. Michaelson. February 2012. (Format: TXT=36117 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6481) 6482 A Profile for Route Origin Authorizations (ROAs). M. Lepinski, S. Kent, D. Kong. February 2012. (Format: TXT=15745 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6482) 6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs). G. Huston, G. Michaelson. February 2012. (Format: TXT=19811 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6483) 6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI). S. Kent, D. Kong, K. Seo, R. Watro. February 2012. (Format: TXT=77855 bytes) (Also BCP0173) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6484) 6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI). G. Huston. February 2012. (Format: TXT=11377 bytes) (Obsoleted by RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6485) 6486 Manifests for the Resource Public Key Infrastructure (RPKI). R. Austein, G. Huston, S. Kent, M. Lepinski. February 2012. (Format: TXT=42913 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6486) 6487 A Profile for X.509 PKIX Resource Certificates. G. Huston, G. Michaelson, R. Loomans. February 2012. (Format: TXT=69150 bytes) (Updated by RFC7318) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6487) 6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI). M. Lepinski, A. Chi, S. Kent. February 2012. (Format: TXT=25130 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6488) 6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI). G. Huston, G. Michaelson, S. Kent. February 2012. (Format: TXT=23060 bytes) (Also BCP0174) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6489) 6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent. February 2012. (Format: TXT=15004 bytes) (Obsoleted by RFC7730) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6490) 6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA. T. Manderson, L. Vegoda, S. Kent. February 2012. (Format: TXT=23662 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6491) 6492 A Protocol for Provisioning Resource Certificates. G. Huston, R. Loomans, B. Ellacott, R. Austein. February 2012. (Format: TXT=65896 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6492) 6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record. R. Bush. February 2012. (Format: TXT=15491 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6493) 6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND). R. Gagliano, S. Krishnan, A. Kukec. February 2012. (Format: TXT=26425 bytes) (Updates RFC3971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6494) 6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields. R. Gagliano, S. Krishnan, A. Kukec. February 2012. (Format: TXT=10575 bytes) (Updates RFC3971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6495) 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND). S. Krishnan, J. Laganier, M. Bonola, A. Garcia-Martinez. February 2012. (Format: TXT=57746 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6496) 6497 BCP 47 Extension T - Transformed Content. M. Davis, A. Phillips, Y. Umaoka, C. Falk. February 2012. (Format: TXT=32915 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6497) 6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package. J. Stone, R. Kumar, F. Andreasen. February 2012. (Format: TXT=92301 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6498) 6501 Conference Information Data Model for Centralized Conferencing (XCON). O. Novo, G. Camarillo, D. Morgan, J. Urpalainen. March 2012. (Format: TXT=180210 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6501) 6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON). G. Camarillo, S. Srinivasan, R. Even, J. Urpalainen. March 2012. (Format: TXT=26245 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6502) 6503 Centralized Conferencing Manipulation Protocol. M. Barnes, C. Boulton, S. Romano, H. Schulzrinne. March 2012. (Format: TXT=257058 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6503) 6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples. M. Barnes, L. Miniero, R. Presta, S P. Romano. March 2012. (Format: TXT=186366 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6504) 6505 A Mixer Control Package for the Media Control Channel Framework. S. McGlashan, T. Melanchuk, C. Boulton. March 2012. (Format: TXT=187038 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6505) 6506 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. February 2012. (Format: TXT=41992 bytes) (Obsoleted by RFC7166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6506) 6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI). M. Groves. February 2012. (Format: TXT=36233 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6507) 6508 Sakai-Kasahara Key Encryption (SAKKE). M. Groves. February 2012. (Format: TXT=42700 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6508) 6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY). M. Groves. February 2012. (Format: TXT=47389 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6509) 6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects. L. Berger, G. Swallow. February 2012. (Format: TXT=16650 bytes) (Updates RFC4875, RFC5420) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6510) 6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths. Z. Ali, G. Swallow, R. Aggarwal. February 2012. (Format: TXT=21767 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6511) 6512 Using Multipoint LDP When the Backbone Has No Route to the Root. IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann. February 2012. (Format: TXT=24352 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6512) 6513 Multicast in MPLS/BGP IP VPNs. E. Rosen, Ed., R. Aggarwal, Ed.. February 2012. (Format: TXT=213780 bytes) (Updated by RFC7582, RFC7900, RFC7988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6513) 6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs. R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter. February 2012. (Format: TXT=145112 bytes) (Updated by RFC6515, RFC6625, RFC7385, RFC7441, RFC7582, RFC7899, RFC7900, RFC7902, RFC7988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6514) 6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN. R. Aggarwal, E. Rosen. February 2012. (Format: TXT=17550 bytes) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6515) 6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages. Y. Cai, E. Rosen, Ed., I. Wijnands. February 2012. (Format: TXT=11992 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6516) 6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution. T. Morin, Ed., B. Niven-Jenkins, Ed., Y. Kamite, R. Zhang, N. Leymann, N. Bitar. February 2012. (Format: TXT=102395 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6517) 6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines. G. Lebovitz, M. Bhatia. February 2012. (Format: TXT=76782 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6518) 6519 RADIUS Extensions for Dual-Stack Lite. R. Maglione, A. Durand. February 2012. (Format: TXT=22574 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6519) 6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. R. Seggelmann, M. Tuexen, M. Williams. February 2012. (Format: TXT=16858 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6520) 6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks. A. Makela, J. Korhonen. February 2012. (Format: TXT=123256 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6521) 6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages. M. Kucherawy, Ed.. January 2012. (Format: TXT=15715 bytes) (Obsoletes RFC3462) (Updated by RFC6533) (Also STD0073) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6522) 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration. R. Stewart, M. Tuexen, P. Lei. February 2012. (Format: TXT=72734 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6525) 6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream. B. Claise, P. Aitken, A. Johnson, G. Muenz. March 2012. (Format: TXT=51285 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6526) 6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3). K. Tata. March 2012. (Format: TXT=62639 bytes) (Obsoletes RFC2787) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6527) 6528 Defending against Sequence Number Attacks. F. Gont, S. Bellovin. February 2012. (Format: TXT=26917 bytes) (Obsoletes RFC1948) (Updates RFC0793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6528) 6529 Host/Host Protocol for the ARPA Network. A. McKenzie, S. Crocker. April 2012. (Format: TXT=69527 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC6529) 6530 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. February 2012. (Format: TXT=64371 bytes) (Obsoletes RFC4952, RFC5504, RFC5825) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6530) 6531 SMTP Extension for Internationalized Email. J. Yao, W. Mao. February 2012. (Format: TXT=40977 bytes) (Obsoletes RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6531) 6532 Internationalized Email Headers. A. Yang, S. Steele, N. Freed. February 2012. (Format: TXT=22725 bytes) (Obsoletes RFC5335) (Updates RFC2045) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6532) 6533 Internationalized Delivery Status and Disposition Notifications. T. Hansen, Ed., C. Newman, A. Melnikov. February 2012. (Format: TXT=37990 bytes) (Obsoletes RFC5337) (Updates RFC3461, RFC3464, RFC3798, RFC6522) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6533) 6534 Loss Episode Metrics for IP Performance Metrics (IPPM). N. Duffield, A. Morton, J. Sommers. May 2012. (Format: TXT=45147 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6534) 6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH). B. Huang, H. Deng, T. Savolainen. February 2012. (Format: TXT=54452 bytes) (Obsoletes RFC2767, RFC3338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6535) 6536 Network Configuration Protocol (NETCONF) Access Control Model. A. Bierman, M. Bjorklund. March 2012. (Format: TXT=90803 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6536) 6537 Host Identity Protocol Distributed Hash Table Interface. J. Ahrenholz. February 2012. (Format: TXT=49467 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6537) 6538 The Host Identity Protocol (HIP) Experiment Report. T. Henderson, A. Gurtov. March 2012. (Format: TXT=88376 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6538) 6539 IBAKE: Identity-Based Authenticated Key Exchange. V. Cakulev, G. Sundaram, I. Broustis. March 2012. (Format: TXT=28913 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6539) 6540 IPv6 Support Required for All IP-Capable Nodes. W. George, C. Donley, C. Liljenstolpe, L. Howard. April 2012. (Format: TXT=12883 bytes) (Also BCP0177) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6540) 6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures. M. Kucherawy. February 2012. (Format: TXT=31655 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6541) 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility. S. Emery. March 2012. (Format: TXT=11080 bytes) (Updates RFC4121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6542) 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6. S. Gundavelli. May 2012. (Format: TXT=10565 bytes) (Updates RFC5213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6543) 6544 TCP Candidates with Interactive Connectivity Establishment (ICE). J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach. March 2012. (Format: TXT=72318 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6544) 6545 Real-time Inter-network Defense (RID). K. Moriarty. April 2012. (Format: TXT=203100 bytes) (Obsoletes RFC6045) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6545) 6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS. B. Trammell. April 2012. (Format: TXT=19114 bytes) (Obsoletes RFC6046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6546) 6547 RFC 3627 to Historic Status. W. George. February 2012. (Format: TXT=4917 bytes) (Obsoletes RFC3627) (Updates RFC6164) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6547) 6548 Independent Submission Editor Model. N. Brownlee, Ed., IAB. June 2012. (Format: TXT=9298 bytes) (Obsoletes RFC5620) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6548) 6549 OSPFv2 Multi-Instance Extensions. A. Lindem, A. Roy, S. Mirtorabi. March 2012. (Format: TXT=16639 bytes) (Updates RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6549) 6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander. March 2012. (Format: TXT=360651 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6550) 6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks. JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel. March 2012. (Format: TXT=67707 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6551) 6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL). P. Thubert, Ed.. March 2012. (Format: TXT=30419 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6552) 6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams. J. Hui, JP. Vasseur. March 2012. (Format: TXT=19093 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6553) 6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL). J. Hui, JP. Vasseur, D. Culler, V. Manral. March 2012. (Format: TXT=30270 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6554) 6555 Happy Eyeballs: Success with Dual-Stack Hosts. D. Wing, A. Yourtchenko. April 2012. (Format: TXT=34048 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6555) 6556 Testing Eyeball Happiness. F. Baker. April 2012. (Format: TXT=23727 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6556) 6557 Procedures for Maintaining the Time Zone Database. E. Lear, P. Eggert. February 2012. (Format: TXT=18469 bytes) (Also BCP0175) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6557) 6558 Sieve Extension for Converting Messages before Delivery. A. Melnikov, B. Leiba, K. Li. March 2012. (Format: TXT=17152 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6558) 6559 A Reliable Transport Mechanism for PIM. D. Farinacci, IJ. Wijnands, S. Venaas, M. Napierala. March 2012. (Format: TXT=70159 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6559) 6560 One-Time Password (OTP) Pre-Authentication. G. Richards. April 2012. (Format: TXT=95896 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6560) 6561 Recommendations for the Remediation of Bots in ISP Networks. J. Livingood, N. Mody, M. O'Reirdan. March 2012. (Format: TXT=74562 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6561) 6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP. C. Perkins, JM. Valin. March 2012. (Format: TXT=14288 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6562) 6563 Moving A6 to Historic Status. S. Jiang, D. Conrad, B. Carpenter. March 2012. (Format: TXT=16654 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6563) 6564 A Uniform Format for IPv6 Extension Headers. S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia. April 2012. (Format: TXT=12879 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6564) 6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol. P. Pillay-Esnault, P. Moyer, J. Doyle, E. Ertekin, M. Lundberg. June 2012. (Format: TXT=43217 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6565) 6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments. Y. Lee, Ed., G. Bernstein, Ed., D. Li, G. Martinelli. March 2012. (Format: TXT=68851 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6566) 6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP. A. Johnston, L. Liess. April 2012. (Format: TXT=25981 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6567) 6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). E. Kim, D. Kaspar, JP. Vasseur. April 2012. (Format: TXT=64728 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6568) 6569 Guidelines for Development of an Audio Codec within the IETF. JM. Valin, S. Borilin, K. Vos, C. Montgomery, R. Chen. March 2012. (Format: TXT=33718 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6569) 6570 URI Template. J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard. March 2012. (Format: TXT=79813 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6570) 6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks. C. Filsfils, Ed., P. Francois, Ed., M. Shand, B. Decraene, J. Uttaro, N. Leymann, M. Horneffer. June 2012. (Format: TXT=71363 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6571) 6572 RADIUS Support for Proxy Mobile IPv6. F. Xia, B. Sarikaya, J. Korhonen, Ed., S. Gundavelli, D. Damic. June 2012. (Format: TXT=74903 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6572) 6573 The Item and Collection Link Relations. M. Amundsen. April 2012. (Format: TXT=7492 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6573) 6574 Report from the Smart Object Workshop. H. Tschofenig, J. Arkko. April 2012. (Format: TXT=74281 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6574) 6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs. H. Shah, Ed., E. Rosen, Ed., G. Heron, Ed., V. Kompella, Ed.. June 2012. (Format: TXT=65881 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6575) 6576 IP Performance Metrics (IPPM) Standard Advancement Testing. R. Geib, Ed., A. Morton, R. Fardid, A. Steinmitz. March 2012. (Format: TXT=84447 bytes) (Also BCP0176) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6576) 6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results. M. Kucherawy. March 2012. (Format: TXT=8173 bytes) (Obsoleted by RFC7001) (Updates RFC5451) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6577) 6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV). C. Daboo, A. Quillaud. March 2012. (Format: TXT=55731 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6578) 6579 The 'disclosure' Link Relation Type. M. Yevstifeyev. March 2012. (Format: TXT=7427 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6579) 6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols. M. Ko, D. Black. April 2012. (Format: TXT=17613 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6580) 6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment. A. Kanevsky, Ed., C. Bestler, Ed., R. Sharp, S. Wise. April 2012. (Format: TXT=57766 bytes) (Updates RFC5043, RFC5044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6581) 6582 The NewReno Modification to TCP's Fast Recovery Algorithm. T. Henderson, S. Floyd, A. Gurtov, Y. Nishida. April 2012. (Format: TXT=35413 bytes) (Obsoletes RFC3782) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6582) 6583 Operational Neighbor Discovery Problems. I. Gashinsky, J. Jaeggli, W. Kumari. March 2012. (Format: TXT=29480 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6583) 6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca. April 2012. (Format: TXT=67466 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6584) 6585 Additional HTTP Status Codes. M. Nottingham, R. Fielding. April 2012. (Format: TXT=17164 bytes) (Updates RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6585) 6586 Experiences from an IPv6-Only Network. J. Arkko, A. Keranen. April 2012. (Format: TXT=52062 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6586) 6587 Transmission of Syslog Messages over TCP. R. Gerhards, C. Lonvick. April 2012. (Format: TXT=21006 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC6587) 6588 A URN Namespace for ucode. C. Ishikawa. April 2012. (Format: TXT=14382 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6588) 6589 Considerations for Transitioning Content to IPv6. J. Livingood. April 2012. (Format: TXT=68822 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6589) 6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports. J. Falk, Ed., M. Kucherawy, Ed.. April 2012. (Format: TXT=15927 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6590) 6591 Authentication Failure Reporting Using the Abuse Reporting Format. H. Fontana. April 2012. (Format: TXT=32378 bytes) (Updated by RFC6692) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6591) 6592 The Null Packet. C. Pignataro. April 2012. (Format: TXT=11036 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6592) 6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS). C. Pignataro, J. Clarke, G. Salgueiro. April 2012. (Format: TXT=16752 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6593) 6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records. O. Sury. April 2012. (Format: TXT=17418 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6594) 6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML). K. Wierenga, E. Lear, S. Josefsson. April 2012. (Format: TXT=49522 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6595) 6596 The Canonical Link Relation. M. Ohye, J. Kupke. April 2012. (Format: TXT=13800 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6596) 6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data. J. Downs, Ed., J. Arbeiter, Ed.. April 2012. (Format: TXT=27339 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6597) 6598 IANA-Reserved IPv4 Prefix for Shared Address Space. J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, M. Azinger. April 2012. (Format: TXT=22055 bytes) (Updates RFC5735) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6598) 6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks. G. Ash, Ed., D. McDysan. April 2012. (Format: TXT=82005 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6601) 6602 Bulk Binding Update Support for Proxy Mobile IPv6. F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec. May 2012. (Format: TXT=56348 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6602) 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation. J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan. May 2012. (Format: TXT=19485 bytes) (Updates RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6603) 6604 xNAME RCODE and Status Bits Clarification. D. Eastlake 3rd. April 2012. (Format: TXT=10790 bytes) (Updates RFC1035, RFC2308, RFC2672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6604) 6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC. P. Hoffman, W.C.A. Wijngaards. April 2012. (Format: TXT=14332 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6605) 6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing. E. Kim, D. Kaspar, C. Gomez, C. Bormann. May 2012. (Format: TXT=75436 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6606) 6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6. K. Kinnear, R. Johnson, M. Stapp. April 2012. (Format: TXT=60312 bytes) (Updates RFC3046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6607) 6608 Subcodes for BGP Finite State Machine Error. J. Dong, M. Chen, A. Suryanarayana. May 2012. (Format: TXT=8612 bytes) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6608) 6609 Sieve Email Filtering: Include Extension. C. Daboo, A. Stone. May 2012. (Format: TXT=26142 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6609) 6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6). H. Jang, A. Yegin, K. Chowdhury, J. Choi, T. Lemon. May 2012. (Format: TXT=36878 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6610) 6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario. K. Chowdhury, Ed., A. Yegin. May 2012. (Format: TXT=27152 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6611) 6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues. G. Giaretta, Ed.. May 2012. (Format: TXT=40116 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6612) 6613 RADIUS over TCP. A. DeKok. May 2012. (Format: TXT=37646 bytes) (Updated by RFC7930) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6613) 6614 Transport Layer Security (TLS) Encryption for RADIUS. S. Winter, M. McCauley, S. Venaas, K. Wierenga. May 2012. (Format: TXT=48004 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6614) 6615 Definitions of Managed Objects for IP Flow Information Export. T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. June 2012. (Format: TXT=137274 bytes) (Obsoletes RFC5815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6615) 6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID. E. Lear, H. Tschofenig, H. Mauldin, S. Josefsson. May 2012. (Format: TXT=39323 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6616) 6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE). D. Harkins. June 2012. (Format: TXT=53805 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6617) 6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent. J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg. May 2012. (Format: TXT=87475 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6618) 6619 Scalable Operation of Address Translators with Per-Interface Bindings. J. Arkko, L. Eggert, M. Townsley. June 2012. (Format: TXT=18590 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6619) 6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=84010 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) 6621 Simplified Multicast Forwarding. J. Macker, Ed.. May 2012. (Format: TXT=139674 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6621) 6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs). U. Herberg, T. Clausen. May 2012. (Format: TXT=48083 bytes) (Obsoleted by RFC7182) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6622) 6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package. E. Burger. May 2012. (Format: TXT=15756 bytes) (Updates RFC6231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6623) 6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling. K. Kompella, B. Kothari, R. Cherukuri. May 2012. (Format: TXT=64693 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6624) 6625 Wildcards in Multicast VPN Auto-Discovery Routes. E. Rosen, Ed., Y. Rekhter, Ed., W. Hendrickx, R. Qiu. May 2012. (Format: TXT=35348 bytes) (Updates RFC6514) (Updated by RFC7582, RFC7900) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6625) 6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4). G. Tsirtsis, V. Park, V. Narayanan, K. Leung. May 2012. (Format: TXT=9270 bytes) (Updates RFC5177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6626) 6627 Overview of Pre-Congestion Notification Encoding. G. Karagiannis, K. Chan, T. Moncaster, M. Menth, P. Eardley, B. Briscoe. July 2012. (Format: TXT=47274 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6627) 6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2. S. Shin, K. Kobara. June 2012. (Format: TXT=45831 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6628) 6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6). J. Abley, M. Bagnulo, A. Garcia-Martinez. June 2012. (Format: TXT=70291 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6629) 6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK). Z. Cao, H. Deng, Q. Wu, G. Zorn, Ed.. June 2012. (Format: TXT=40373 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6630) 6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2). D. Kuegler, Y. Sheffer. June 2012. (Format: TXT=53353 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6631) 6632 An Overview of the IETF Network Management Standards. M. Ersue, Ed., B. Claise. June 2012. (Format: TXT=210159 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6632) 6633 Deprecation of ICMP Source Quench Messages. F. Gont. May 2012. (Format: TXT=16367 bytes) (Updates RFC0792, RFC1122, RFC1812) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6633) 6635 RFC Editor Model (Version 2). O. Kolkman, Ed., J. Halpern, Ed., IAB. June 2012. (Format: TXT=48170 bytes) (Obsoletes RFC5620) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6635) 6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks. H. Asaeda, H. Liu, Q. Wu. May 2012. (Format: TXT=30261 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6636) 6637 Elliptic Curve Cryptography (ECC) in OpenPGP. A. Jivsov. June 2012. (Format: TXT=31532 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6637) 6638 Scheduling Extensions to CalDAV. C. Daboo, B. Desruisseaux. June 2012. (Format: TXT=156287 bytes) (Updates RFC4791, RFC5546) (Updated by RFC7953) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6638) 6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview. D. King, Ed., M. Venkatesan, Ed.. June 2012. (Format: TXT=58669 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6639) 6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions. W. George. June 2012. (Format: TXT=27610 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6640) 6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4. C. Everhart, W. Adamson, J. Zhang. June 2012. (Format: TXT=24047 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6641) 6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report. Q. Wu, Ed., F. Xia, R. Even. June 2012. (Format: TXT=29758 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6642) 6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules. J. Schoenwaelder. July 2012. (Format: TXT=69140 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6643) 6644 Rebind Capability in DHCPv6 Reconfigure Messages. D. Evans, R. Droms, S. Jiang. July 2012. (Format: TXT=19176 bytes) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6644) 6645 IP Flow Information Accounting and Export Benchmarking Methodology. J. Novak. July 2012. (Format: TXT=87875 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6645) 6646 DECoupled Application Data Enroute (DECADE) Problem Statement. H. Song, N. Zong, Y. Yang, R. Alimi. July 2012. (Format: TXT=25124 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6646) 6647 Email Greylisting: An Applicability Statement for SMTP. M. Kucherawy, D. Crocker. June 2012. (Format: TXT=38097 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6647) 6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols. P. Saint-Andre, D. Crocker, M. Nottingham. June 2012. (Format: TXT=28393 bytes) (Also BCP0178) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6648) 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos. L. Hornquist Astrand, T. Yu. July 2012. (Format: TXT=13498 bytes) (Obsoletes RFC1510) (Updates RFC1964, RFC4120, RFC4121, RFC4757) (Also BCP0179) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6649) 6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF). J. Falk, M. Kucherawy, Ed.. June 2012. (Format: TXT=35273 bytes) (Updates RFC5965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6650) 6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting. M. Kucherawy. June 2012. (Format: TXT=35028 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6651) 6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format. S. Kitterman. June 2012. (Format: TXT=15373 bytes) (Updates RFC4408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6652) 6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks. B. Sarikaya, F. Xia, T. Lemon. July 2012. (Format: TXT=28755 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6653) 6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd). T. Tsou, C. Zhou, T. Taylor, Q. Chen. July 2012. (Format: TXT=16949 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6654) 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS). D. McGrew, D. Bailey. July 2012. (Format: TXT=17052 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6655) 6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4. R. Johnson, K. Kinnear, M. Stapp. July 2012. (Format: TXT=54971 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6656) 6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types. A. Melnikov, J. Reschke. July 2012. (Format: TXT=10111 bytes) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6657) 6658 Packet Pseudowire Encapsulation over an MPLS PSN. S. Bryant, Ed., L. Martini, G. Swallow, A. Malis. July 2012. (Format: TXT=32164 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6658) 6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method. A. Begen. July 2012. (Format: TXT=24234 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6659) 6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP). B. Briscoe, T. Moncaster, M. Menth. July 2012. (Format: TXT=52230 bytes) (Obsoletes RFC5696) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6660) 6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation. A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor, Ed.. July 2012. (Format: TXT=72258 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6661) 6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation. A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, Ed.. July 2012. (Format: TXT=67000 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6662) 6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain. G. Karagiannis, T. Taylor, K. Chan, M. Menth, P. Eardley. July 2012. (Format: TXT=15316 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6663) 6664 S/MIME Capabilities for Public Key Definitions. J. Schaad. July 2012. (Format: TXT=37926 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6664) 6665 SIP-Specific Event Notification. A.B. Roach. July 2012. (Format: TXT=125556 bytes) (Obsoletes RFC3265) (Updates RFC3261, RFC4660) (Updated by RFC7621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6665) 6666 A Discard Prefix for IPv6. N. Hilliard, D. Freedman. August 2012. (Format: TXT=10658 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6666) 6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements. K. Raza, S. Boutros, C. Pignataro. July 2012. (Format: TXT=17068 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6667) 6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol. D. Bider, M. Baushke. July 2012. (Format: TXT=8710 bytes) (Updates RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6668) 6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks. N. Sprecher, L. Fang. July 2012. (Format: TXT=46171 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6669) 6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). N. Sprecher, KY. Hong. July 2012. (Format: TXT=77266 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6670) 6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM). M. Betts. November 2012. (Format: TXT=8941 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6671) 6672 DNAME Redirection in the DNS. S. Rose, W. Wijngaards. June 2012. (Format: TXT=45704 bytes) (Obsoletes RFC2672) (Updates RFC3363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6672) 6673 Round-Trip Packet Loss Metrics. A. Morton. August 2012. (Format: TXT=28458 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6673) 6674 Gateway-Initiated Dual-Stack Lite Deployment. F. Brockners, S. Gundavelli, S. Speicher, D. Ward. July 2012. (Format: TXT=32731 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6674) 6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP. E. Blanton, M. Allman, L. Wang, I. Jarvinen, M. Kojo, Y. Nishida. August 2012. (Format: TXT=34484 bytes) (Obsoletes RFC3517) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6675) 6676 Multicast Addresses for Documentation. S. Venaas, R. Parekh, G. Van de Velde, T. Chown, M. Eubanks. August 2012. (Format: TXT=14100 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6676) 6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods. S. Hartman, Ed., T. Clancy, K. Hoeper. July 2012. (Format: TXT=79805 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6677) 6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method. K. Hoeper, S. Hanna, H. Zhou, J. Salowey, Ed.. July 2012. (Format: TXT=54446 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6678) 6679 Explicit Congestion Notification (ECN) for RTP over UDP. M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg. August 2012. (Format: TXT=148560 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6679) 6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions. N. Williams, L. Johansson, S. Hartman, S. Josefsson. August 2012. (Format: TXT=37063 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6680) 6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME. M. Watson, T. Stockhammer, M. Luby. August 2012. (Format: TXT=46372 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6681) 6682 RTP Payload Format for Raptor Forward Error Correction (FEC). M. Watson, T. Stockhammer, M. Luby. August 2012. (Format: TXT=35386 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6682) 6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection. A. Begen, T. Stockhammer. August 2012. (Format: TXT=22726 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6683) 6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF). B. Trammell. July 2012. (Format: TXT=23550 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6684) 6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry. B. Trammell. July 2012. (Format: TXT=4363 bytes) (Obsoleted by RFC7970) (Updates RFC5070) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6685) 6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments. M. Kucherawy. July 2012. (Format: TXT=26421 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6686) 6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL). J. Tripathi, Ed., J. de Oliveira, Ed., JP. Vasseur, Ed.. October 2012. (Format: TXT=63624, PDF=589296 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6687) 6688 Parallel NFS (pNFS) Block Disk Protection. D. Black, Ed., J. Glasgow, S. Faibish. July 2012. (Format: TXT=12119 bytes) (Updates RFC5663) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6688) 6689 Usage of the RSVP ASSOCIATION Object. L. Berger. July 2012. (Format: TXT=26037 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6689) 6690 Constrained RESTful Environments (CoRE) Link Format. Z. Shelby. August 2012. (Format: TXT=47720 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6690) 6691 TCP Options and Maximum Segment Size (MSS). D. Borman. July 2012. (Format: TXT=16707 bytes) (Updates RFC0879, RFC2385) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6691) 6692 Source Ports in Abuse Reporting Format (ARF) Reports. R. Clayton, M. Kucherawy. July 2012. (Format: TXT=8053 bytes) (Updates RFC6591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6692) 6693 Probabilistic Routing Protocol for Intermittently Connected Networks. A. Lindgren, A. Doria, E. Davies, S. Grasic. August 2012. (Format: TXT=280908 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6693) 6694 The "about" URI Scheme. S. Moonesamy, Ed.. August 2012. (Format: TXT=11604 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6694) 6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information. R. Asati. August 2012. (Format: TXT=34678 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6695) 6696 EAP Extensions for the EAP Re-authentication Protocol (ERP). Z. Cao, B. He, Y. Shi, Q. Wu, Ed., G. Zorn, Ed.. July 2012. (Format: TXT=103860 bytes) (Obsoletes RFC5296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6696) 6697 Handover Keying (HOKEY) Architecture Design. G. Zorn, Ed., Q. Wu, T. Taylor, Y. Nir, K. Hoeper, S. Decugis. July 2012. (Format: TXT=44243 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6697) 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. P. Hoffman, J. Schlyter. August 2012. (Format: TXT=84034 bytes) (Updated by RFC7218, RFC7671) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6698) 6701 Sanctions Available for Application to Violators of IETF IPR Policy. A. Farrel, P. Resnick. August 2012. (Format: TXT=25078 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6701) 6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules. T. Polk, P. Saint-Andre. August 2012. (Format: TXT=35052 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6702) 6703 Reporting IP Network Performance Metrics: Different Points of View. A. Morton, G. Ramachandran, G. Maguluri. August 2012. (Format: TXT=60152 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6703) 6704 Forcerenew Nonce Authentication. D. Miles, W. Dec, J. Bristow, R. Maglione. August 2012. (Format: TXT=26538 bytes) (Updates RFC3203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6704) 6705 Localized Routing for Proxy Mobile IPv6. S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta. September 2012. (Format: TXT=43309 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6705) 6706 Asymmetric Extended Route Optimization (AERO). F. Templin, Ed.. August 2012. (Format: TXT=77250 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6706) 6707 Content Distribution Network Interconnection (CDNI) Problem Statement. B. Niven-Jenkins, F. Le Faucheur, N. Bitar. September 2012. (Format: TXT=75060 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6707) 6708 Application-Layer Traffic Optimization (ALTO) Requirements. S. Kiesel, Ed., S. Previdi, M. Stiemerling, R. Woundy, Y. Yang. September 2012. (Format: TXT=47549 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6708) 6709 Design Considerations for Protocol Extensions. B. Carpenter, B. Aboba, Ed., S. Cheshire. September 2012. (Format: TXT=103913 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6709) 6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities. A. Melnikov, K. Carlberg. August 2012. (Format: TXT=59966 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6710) 6711 An IANA Registry for Level of Assurance (LoA) Profiles. L. Johansson. August 2012. (Format: TXT=14416 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6711) 6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP). T. Kause, M. Peylo. September 2012. (Format: TXT=21308 bytes) (Updates RFC4210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6712) 6713 The 'application/zlib' and 'application/gzip' Media Types. J. Levine. August 2012. (Format: TXT=6525 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6713) 6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP). C. Holmberg, S. Blau, E. Burger. August 2012. (Format: TXT=50543 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6714) 6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group. D. Cauchie, B. Leiba, K. Li. August 2012. (Format: TXT=18951 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6715) 6716 Definition of the Opus Audio Codec. JM. Valin, K. Vos, T. Terriberry. September 2012. (Format: TXT=977743 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6716) 6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012. H. Hotz, R. Allbery. August 2012. (Format: TXT=29044 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6717) 6718 Pseudowire Redundancy. P. Muley, M. Aissaoui, M. Bocci. August 2012. (Format: TXT=41486 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6718) 6719 The Minimum Rank with Hysteresis Objective Function. O. Gnawali, P. Levis. September 2012. (Format: TXT=29637 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6719) 6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP). C. Pignataro, R. Asati. August 2012. (Format: TXT=17823 bytes) (Updates RFC5036) (Updated by RFC7552) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6720) 6721 The Atom "deleted-entry" Element. J. Snell. September 2012. (Format: TXT=22678 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6721) 6722 Publishing the "Tao of the IETF" as a Web Page. P. Hoffman, Ed.. August 2012. (Format: TXT=6192 bytes) (Obsoletes RFC4677) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6722) 6723 Update of the Pseudowire Control-Word Negotiation Mechanism. L. Jin, Ed., R. Key, Ed., S. Delord, T. Nadeau, S. Boutros. September 2012. (Format: TXT=20307 bytes) (Updates RFC4447, RFC6073) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6723) 6724 Default Address Selection for Internet Protocol Version 6 (IPv6). D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown. September 2012. (Format: TXT=74407 bytes) (Obsoletes RFC3484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6724) 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates. S. Rose. August 2012. (Format: TXT=9236 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6725) 6726 FLUTE - File Delivery over Unidirectional Transport. T. Paila, R. Walsh, M. Luby, V. Roca, R. Lehtonen. November 2012. (Format: TXT=108261 bytes) (Obsoletes RFC3926) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6726) 6727 Definitions of Managed Objects for Packet Sampling. T. Dietz, Ed., B. Claise, J. Quittek. October 2012. (Format: TXT=55441 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6727) 6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols. G. Muenz, B. Claise, P. Aitken. October 2012. (Format: TXT=279937 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6728) 6729 Indicating Email Handling States in Trace Fields. D. Crocker, M. Kucherawy. September 2012. (Format: TXT=24665 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6729) 6730 Requirements for IETF Nominations Committee Tools. S. Krishnan, J. Halpern. September 2012. (Format: TXT=19765 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6730) 6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes. T. Savolainen, J. Kato, T. Lemon. December 2012. (Format: TXT=68882 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6731) 6732 6to4 Provider Managed Tunnels. V. Kuarsingh, Ed., Y. Lee, O. Vautrin. September 2012. (Format: TXT=28156 bytes) (Obsoleted by RFC7526) (Status: HISTORIC) (DOI: 10.17487/RFC6732) 6733 Diameter Base Protocol. V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.. October 2012. (Format: TXT=343760 bytes) (Obsoletes RFC3588, RFC5719) (Updated by RFC7075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6733) 6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport. G. Zorn, Q. Wu, V. Cakulev. October 2012. (Format: TXT=12643 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6734) 6735 Diameter Priority Attribute-Value Pairs. K. Carlberg, Ed., T. Taylor. October 2012. (Format: TXT=21793 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6735) 6736 Diameter Network Address and Port Translation Control Application. F. Brockners, S. Bhandari, V. Singh, V. Fajardo. October 2012. (Format: TXT=138288 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6736) 6737 The Diameter Capabilities Update Application. K. Jiao, G. Zorn. October 2012. (Format: TXT=12380 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6737) 6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers. V. Cakulev, A. Lior, S. Mizikovsky. October 2012. (Format: TXT=35536 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6738) 6739 Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol. H. Schulzrinne, H. Tschofenig. October 2012. (Format: TXT=52011 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6739) 6740 Identifier-Locator Network Protocol (ILNP) Architectural Description. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=126139 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6740) 6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=93512 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6741) 6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti, S. Rose. November 2012. (Format: TXT=42996 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6742) 6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=24972 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6743) 6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=33737 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6744) 6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=25137 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6745) 6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=24866 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6746) 6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=24322 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6747) 6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=86535 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6748) 6749 The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. October 2012. (Format: TXT=163498 bytes) (Obsoletes RFC5849) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6749) 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage. M. Jones, D. Hardt. October 2012. (Format: TXT=38949 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6750) 6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44). R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang. October 2012. (Format: TXT=73468 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6751) 6752 Issues with Private IP Addressing in the Internet. A. Kirkham. September 2012. (Format: TXT=31838 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6752) 6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD). J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson. October 2012. (Format: TXT=49866 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6753) 6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect. Y. Cai, L. Wei, H. Ou, V. Arya, S. Jethwani. October 2012. (Format: TXT=24599 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6754) 6755 An IETF URN Sub-Namespace for OAuth. B. Campbell, H. Tschofenig. October 2012. (Format: TXT=8336 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6755) 6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines. S. Trowbridge, Ed., E. Lear, Ed., G. Fishman, Ed., S. Bradner, Ed.. September 2012. (Format: TXT=33355 bytes) (Obsoletes RFC3356) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6756) 6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6. S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. October 2012. (Format: TXT=43863 bytes) (Updated by RFC7563) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6757) 6758 Tunneling of SMTP Message Transfer Priorities. A. Melnikov, K. Carlberg. October 2012. (Format: TXT=22159 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6758) 6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX). B. Claise, P. Aitken, N. Ben-Dvora. November 2012. (Format: TXT=83584 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6759) 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP). S. Cheshire, M. Krochmal. February 2013. (Format: TXT=38212 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6760) 6761 Special-Use Domain Names. S. Cheshire, M. Krochmal. February 2013. (Format: TXT=28862 bytes) (Updates RFC1918, RFC2606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6761) 6762 Multicast DNS. S. Cheshire, M. Krochmal. February 2013. (Format: TXT=184992 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6762) 6763 DNS-Based Service Discovery. S. Cheshire, M. Krochmal. February 2013. (Format: TXT=125192 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6763) 6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV). C. Daboo. February 2013. (Format: TXT=28361 bytes) (Updates RFC4791, RFC6352) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6764) 6765 xDSL Multi-Pair Bonding (G.Bond) MIB. E. Beili, M. Morgenstern. February 2013. (Format: TXT=154301 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6765) 6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB. E. Beili. February 2013. (Format: TXT=107078 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6766) 6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB. E. Beili, M. Morgenstern. February 2013. (Format: TXT=105415 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6767) 6768 ATM-Based xDSL Bonded Interfaces MIB. E. Beili. February 2013. (Format: TXT=64283 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6768) 6769 Simple Virtual Aggregation (S-VA). R. Raszuk, J. Heitz, A. Lo, L. Zhang, X. Xu. October 2012. (Format: TXT=16565 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6769) 6770 Use Cases for Content Delivery Network Interconnection. G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson. November 2012. (Format: TXT=33281 bytes) (Obsoletes RFC3570) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6770) 6771 Considerations for Having a Successful "Bar BOF" Side Meeting. L. Eggert, G. Camarillo. October 2012. (Format: TXT=24724 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6771) 6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information. H. Schulzrinne, Ed., H. Tschofenig, Ed., J. Cuellar, J. Polk, J. Morris, M. Thomson. January 2013. (Format: TXT=87801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6772) 6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal. T. Phelan, G. Fairhurst, C. Perkins. November 2012. (Format: TXT=45073 bytes) (Updates RFC4340, RFC5762) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6773) 6774 Distribution of Diverse BGP Paths. R. Raszuk, Ed., R. Fernando, K. Patel, D. McPherson, K. Kumaki. November 2012. (Format: TXT=48316 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6774) 6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Z. Shelby, Ed., S. Chakrabarti, E. Nordmark, C. Bormann. November 2012. (Format: TXT=130616 bytes) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6775) 6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block. A. Clark, Q. Wu. October 2012. (Format: TXT=17259 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6776) 6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks. W. Sun, Ed., G. Zhang, Ed., J. Gao, G. Xie, R. Papneja. November 2012. (Format: TXT=57725 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6777) 6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching. R. Sparks. October 2012. (Format: TXT=15396 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6778) 6779 Definition of Managed Objects for the Neighborhood Discovery Protocol. U. Herberg, R. Cole, I. Chakeres. October 2012. (Format: TXT=131403 bytes) (Obsoleted by RFC7939) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6779) 6780 RSVP ASSOCIATION Object Extensions. L. Berger, F. Le Faucheur, A. Narayanan. October 2012. (Format: TXT=41252 bytes) (Updates RFC2205, RFC3209, RFC3473, RFC4872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6780) 6781 DNSSEC Operational Practices, Version 2. O. Kolkman, W. Mekking, R. Gieben. December 2012. (Format: TXT=161581 bytes) (Obsoletes RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6781) 6782 Wireline Incremental IPv6. V. Kuarsingh, Ed., L. Howard. November 2012. (Format: TXT=71197 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6782) 6783 Mailing Lists and Non-ASCII Addresses. J. Levine, R. Gellens. November 2012. (Format: TXT=21960 bytes) (Obsoletes RFC5983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6783) 6784 Kerberos Options for DHCPv6. S. Sakane, M. Ishiyama. November 2012. (Format: TXT=24110 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6784) 6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve. B. Leiba. November 2012. (Format: TXT=42644 bytes) (Updates RFC5228) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6785) 6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs. A. Yegin, R. Cragie. November 2012. (Format: TXT=21361 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6786) 6787 Media Resource Control Protocol Version 2 (MRCPv2). D. Burnett, S. Shanmugham. November 2012. (Format: TXT=496648 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6787) 6788 The Line-Identification Option. S. Krishnan, A. Kavanagh, B. Varga, S. Ooghe, E. Nordmark. November 2012. (Format: TXT=38410 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6788) 6789 Congestion Exposure (ConEx) Concepts and Use Cases. B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed.. December 2012. (Format: TXT=41078 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6789) 6790 The Use of Entropy Labels in MPLS Forwarding. K. Kompella, J. Drake, S. Amante, W. Henderickx, L. Yong. November 2012. (Format: TXT=53837 bytes) (Updates RFC3031, RFC3107, RFC3209, RFC5036) (Updated by RFC7274, RFC7447, RFC8012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6790) 6791 Stateless Source Address Mapping for ICMPv6 Packets. X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston. November 2012. (Format: TXT=11793 bytes) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6791) 6792 Guidelines for Use of the RTP Monitoring Framework. Q. Wu, Ed., G. Hunt, P. Arden. November 2012. (Format: TXT=42473 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6792) 6793 BGP Support for Four-Octet Autonomous System (AS) Number Space. Q. Vohra, E. Chen. December 2012. (Format: TXT=26366 bytes) (Obsoletes RFC4893) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6793) 6794 A Framework for Session Initiation Protocol (SIP) Session Policies. V. Hilt, G. Camarillo, J. Rosenberg. December 2012. (Format: TXT=94464 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6794) 6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies. V. Hilt, G. Camarillo. December 2012. (Format: TXT=42920 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6795) 6796 A User Agent Profile Data Set for Media Policy. V. Hilt, G. Camarillo, J. Rosenberg, D. Worley. December 2012. (Format: TXT=88634 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6796) 6797 HTTP Strict Transport Security (HSTS). J. Hodges, C. Jackson, A. Barth. November 2012. (Format: TXT=103554 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6797) 6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting. A. Clark, Q. Wu. November 2012. (Format: TXT=26901 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6798) 6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework. U. Kozat, A. Begen. November 2012. (Format: TXT=24923 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6801) 6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets. S. Baillargeon, C. Flinta, A. Johnsson. November 2012. (Format: TXT=37309 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6802) 6803 Camellia Encryption for Kerberos 5. G. Hudson. November 2012. (Format: TXT=23516 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6803) 6804 DISCOVER: Supporting Multicast DNS Queries. B. Manning. November 2012. (Format: TXT=19946 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC6804) 6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS. D. King, Ed., A. Farrel, Ed.. November 2012. (Format: TXT=77669 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6805) 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals. S. Hartman, Ed., K. Raeburn, L. Zhu. November 2012. (Format: TXT=47572 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6806) 6807 Population Count Extensions to Protocol Independent Multicast (PIM). D. Farinacci, G. Shepherd, S. Venaas, Y. Cai. December 2012. (Format: TXT=32114 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6807) 6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track. L. Ciavattone, R. Geib, A. Morton, M. Wieser. December 2012. (Format: TXT=62061 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6808) 6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP). C. Holmberg, I. Sedlacek, H. Kaplan. November 2012. (Format: TXT=40053 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6809) 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol. R. Bush, R. Austein. January 2013. (Format: TXT=59714 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6810) 6811 BGP Prefix Origin Validation. P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein. January 2013. (Format: TXT=20082 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6811) 6812 Cisco Service-Level Assurance Protocol. M. Chiba, A. Clemm, S. Medley, J. Salowey, S. Thombare, E. Yedavalli. January 2013. (Format: TXT=68237 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6812) 6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis. J. Salowey, S. Hanna. December 2012. (Format: TXT=15899 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6813) 6814 Formally Deprecating Some IPv4 Options. C. Pignataro, F. Gont. November 2012. (Format: TXT=11327 bytes) (Obsoletes RFC1385, RFC1393, RFC1475, RFC1770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6814) 6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful. S. Bradner, K. Dubray, J. McQuaid, A. Morton. November 2012. (Format: TXT=22308 bytes) (Updates RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6815) 6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME. V. Roca, M. Cunche, J. Lacan. December 2012. (Format: TXT=49938 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6816) 6817 Low Extra Delay Background Transport (LEDBAT). S. Shalunov, G. Hazel, J. Iyengar, M. Kuehlewind. December 2012. (Format: TXT=57813 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6817) 6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. P. Yee. January 2013. (Format: TXT=17439 bytes) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6818) 6819 OAuth 2.0 Threat Model and Security Considerations. T. Lodderstedt, Ed., M. McGloin, P. Hunt. January 2013. (Format: TXT=158332 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6819) 6820 Address Resolution Problems in Large Data Center Networks. T. Narten, M. Karir, I. Foo. January 2013. (Format: TXT=42650 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6820) 6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality. E. Marocco, A. Fusco, I. Rimac, V. Gurbani. December 2012. (Format: TXT=33299 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6821) 6822 IS-IS Multi-Instance. S. Previdi, Ed., L. Ginsberg, M. Shand, A. Roy, D. Ward. December 2012. (Format: TXT=30254 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6822) 6823 Advertising Generic Information in IS-IS. L. Ginsberg, S. Previdi, M. Shand. December 2012. (Format: TXT=22708 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6823) 6824 TCP Extensions for Multipath Operation with Multiple Addresses. A. Ford, C. Raiciu, M. Handley, O. Bonaventure. January 2013. (Format: TXT=164866 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6824) 6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS. M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau. January 2013. (Format: TXT=72765 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6825) 6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala. January 2013. (Format: TXT=23927 bytes) (Updated by RFC7438) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6826) 6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols. A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed.. January 2013. (Format: TXT=73279 bytes) (Obsoletes RFC5787) (Updates RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6827) 6828 Content Splicing for RTP Sessions. J. Xia. January 2013. (Format: TXT=38904 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6828) 6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6. M. Chen, P. Pan, C. Pignataro, R. Asati. January 2013. (Format: TXT=15683 bytes) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6829) 6830 The Locator/ID Separation Protocol (LISP). D. Farinacci, V. Fuller, D. Meyer, D. Lewis. January 2013. (Format: TXT=189977 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6830) 6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments. D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas. January 2013. (Format: TXT=71901 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6831) 6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites. D. Lewis, D. Meyer, D. Farinacci, V. Fuller. January 2013. (Format: TXT=43758 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6832) 6833 Locator/ID Separation Protocol (LISP) Map-Server Interface. V. Fuller, D. Farinacci. January 2013. (Format: TXT=30144 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6833) 6834 Locator/ID Separation Protocol (LISP) Map-Versioning. L. Iannone, D. Saucez, O. Bonaventure. January 2013. (Format: TXT=51447 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6834) 6835 The Locator/ID Separation Protocol Internet Groper (LIG). D. Farinacci, D. Meyer. January 2013. (Format: TXT=26810 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6835) 6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT). V. Fuller, D. Farinacci, D. Meyer, D. Lewis. January 2013. (Format: TXT=62093 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6836) 6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database. E. Lear. January 2013. (Format: TXT=72499 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6837) 6838 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin, T. Hansen. January 2013. (Format: TXT=72942 bytes) (Obsoletes RFC4288) (Also BCP0013) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6838) 6839 Additional Media Type Structured Syntax Suffixes. T. Hansen, A. Melnikov. January 2013. (Format: TXT=26071 bytes) (Updates RFC3023) (Updated by RFC7303) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6839) 6840 Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, Ed., D. Blacka, Ed.. February 2013. (Format: TXT=47283 bytes) (Updates RFC4033, RFC4034, RFC4035, RFC5155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6840) 6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements. F. Ljunggren, AM. Eklund Lowinder, T. Okubo. January 2013. (Format: TXT=57936 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6841) 6842 Client Identifier Option in DHCP Server Replies. N. Swamy, G. Halwasia, P. Jhingran. January 2013. (Format: TXT=10030 bytes) (Updates RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6842) 6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting. A. Clark, K. Gross, Q. Wu. January 2013. (Format: TXT=18354 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6843) 6844 DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, R. Stradling. January 2013. (Format: TXT=36848 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6844) 6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type. N. Sheth, L. Wang, J. Zhang. January 2013. (Format: TXT=17019 bytes) (Updates RFC2328, RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6845) 6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP). G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. January 2013. (Format: TXT=187518 bytes) (Obsoletes RFC4996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6846) 6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL). D. Melman, T. Mizrahi, D. Eastlake 3rd. January 2013. (Format: TXT=28693 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6847) 6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO). J. Winterbottom, M. Thomson, R. Barnes, B. Rosen, R. George. January 2013. (Format: TXT=41081 bytes) (Updates RFC4776, RFC5222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6848) 6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback. H. Kaplan, Ed., K. Hedayat, N. Venna, P. Jones, N. Stratton. February 2013. (Format: TXT=66214 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6849) 6850 Definitions of Managed Objects for Routing Bridges (RBridges). A. Rijhsinghani, K. Zebrose. January 2013. (Format: TXT=104287 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6850) 6851 Internet Message Access Protocol (IMAP) - MOVE Extension. A. Gulbrandsen, N. Freed, Ed.. January 2013. (Format: TXT=15689 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6851) 6852 Affirmation of the Modern Paradigm for Standards. R. Housley, S. Mills, J. Jaffe, B. Aboba, L. St.Amour. January 2013. (Format: TXT=9696 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6852) 6853 DHCPv6 Redundancy Deployment Considerations. J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski. February 2013. (Format: TXT=34209 bytes) (Also BCP0180) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6853) 6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields. B. Leiba. March 2013. (Format: TXT=20190 bytes) (Updates RFC5322) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6854) 6855 IMAP Support for UTF-8. P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.. March 2013. (Format: TXT=24370 bytes) (Obsoletes RFC5738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6855) 6856 Post Office Protocol Version 3 (POP3) Support for UTF-8. R. Gellens, C. Newman, J. Yao, K. Fujiwara. March 2013. (Format: TXT=26790 bytes) (Obsoletes RFC5721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6856) 6857 Post-Delivery Message Downgrading for Internationalized Email Messages. K. Fujiwara. March 2013. (Format: TXT=39255 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6857) 6858 Simplified POP and IMAP Downgrading for Internationalized Email. A. Gulbrandsen. March 2013. (Format: TXT=12169 bytes) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6858) 6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership. B. Leiba. January 2013. (Format: TXT=5619 bytes) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6859) 6860 Hiding Transit-Only Networks in OSPF. Y. Yang, A. Retana, A. Roy. January 2013. (Format: TXT=26368 bytes) (Updates RFC2328, RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6860) 6861 The "create-form" and "edit-form" Link Relations. I. Dzmanashvili. January 2013. (Format: TXT=8191 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6861) 6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements. G. Lebovitz, M. Bhatia, B. Weis. March 2013. (Format: TXT=67802 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6862) 6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide. S. Hartman, D. Zhang. March 2013. (Format: TXT=26996 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6863) 6864 Updated Specification of the IPv4 ID Field. J. Touch. February 2013. (Format: TXT=44418 bytes) (Updates RFC0791, RFC1122, RFC2003) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6864) 6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME. V. Roca, M. Cunche, J. Lacan, A. Bouabdallah, K. Matsuzono. February 2013. (Format: TXT=48493 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6865) 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks. B. Carpenter, S. Jiang. February 2013. (Format: TXT=26524 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6866) 6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP). Y. Nir, Q. Wu. January 2013. (Format: TXT=19322 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6867) 6868 Parameter Value Encoding in iCalendar and vCard. C. Daboo. February 2013. (Format: TXT=11025 bytes) (Updates RFC5545, RFC6321, RFC6350, RFC6351) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6868) 6869 vCard KIND:device. G. Salgueiro, J. Clarke, P. Saint-Andre. February 2013. (Format: TXT=14648 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6869) 6870 Pseudowire Preferential Forwarding Status Bit. P. Muley, Ed., M. Aissaoui, Ed.. February 2013. (Format: TXT=79254 bytes) (Updates RFC4447) (Updated by RFC7771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6870) 6871 Session Description Protocol (SDP) Media Capabilities Negotiation. R. Gilman, R. Even, F. Andreasen. February 2013. (Format: TXT=124829 bytes) (Updates RFC5939) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6871) 6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model. V. Gurbani, Ed., E. Burger, Ed., T. Anjali, H. Abdelnur, O. Festor. February 2013. (Format: TXT=72134 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6872) 6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF). G. Salgueiro, V. Gurbani, A. B. Roach. February 2013. (Format: TXT=63449 bytes) (Updated by RFC7355) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6873) 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. B. Carpenter, S. Cheshire, R. Hinden. February 2013. (Format: TXT=19361 bytes) (Updates RFC3986) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6874) 6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan. S. Kamei, T. Momose, T. Inoue, T. Nishitani. February 2013. (Format: TXT=41572 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6875) 6876 A Posture Transport Protocol over TLS (PT-TLS). P. Sangster, N. Cam-Winget, J. Salowey. February 2013. (Format: TXT=109852 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6876) 6877 464XLAT: Combination of Stateful and Stateless Translation. M. Mawatari, M. Kawashima, C. Byrne. April 2013. (Format: TXT=31382 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6877) 6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field. A.B. Roach. March 2013. (Format: TXT=4688 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6878) 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods. S. Jiang, B. Liu, B. Carpenter. February 2013. (Format: TXT=38833 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6879) 6880 An Information Model for Kerberos Version 5. L. Johansson. March 2013. (Format: TXT=28121 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6880) 6881 Best Current Practice for Communications Services in Support of Emergency Calling. B. Rosen, J. Polk. March 2013. (Format: TXT=63007 bytes) (Updated by RFC7840, RFC7852) (Also BCP0181) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6881) 6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs). K. Kumaki, Ed., T. Murai, D. Cheng, S. Matsushima, P. Jiang. March 2013. (Format: TXT=33125 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6882) 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers. B. Carpenter, S. Jiang. March 2013. (Format: TXT=60430 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6883) 6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Z. Fang. March 2013. (Format: TXT=43207 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6884) 6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS). M. Blanchet, A. Sullivan. March 2013. (Format: TXT=72167 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6885) 6886 NAT Port Mapping Protocol (NAT-PMP). S. Cheshire, M. Krochmal. April 2013. (Format: TXT=87891 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6886) 6887 Port Control Protocol (PCP). D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk. April 2013. (Format: TXT=221314 bytes) (Updated by RFC7488, RFC7652, RFC7843) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6887) 6888 Common Requirements for Carrier-Grade NATs (CGNs). S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida. April 2013. (Format: TXT=32484 bytes) (Updates RFC4787) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6888) 6889 Analysis of Stateful 64 Translation. R. Penno, T. Saxena, M. Boucadair, S. Sivakumar. April 2013. (Format: TXT=33171 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6889) 6890 Special-Purpose IP Address Registries. M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman. April 2013. (Format: TXT=48326 bytes) (Obsoletes RFC4773, RFC5156, RFC5735, RFC5736) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6890) 6891 Extension Mechanisms for DNS (EDNS(0)). J. Damas, M. Graff, P. Vixie. April 2013. (Format: TXT=32856 bytes) (Obsoletes RFC2671, RFC2673) (Also STD0075) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6891) 6892 The 'describes' Link Relation Type. E. Wilde. March 2013. (Format: TXT=10846 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6892) 6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF). P. Higgs, P. Szucs. March 2013. (Format: TXT=12403 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6893) 6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection. R. Papneja, S. Vapiwala, J. Karthik, S. Poretsky, S. Rao, JL. Le Roux. March 2013. (Format: TXT=64597 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6894) 6895 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. April 2013. (Format: TXT=38979 bytes) (Obsoletes RFC6195) (Updates RFC1183, RFC2845, RFC2930, RFC3597) (Also BCP0042) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6895) 6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP. S. Barbato, S. Dorigotti, T. Fossati, Ed.. March 2013. (Format: TXT=44175 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6896) 6897 Multipath TCP (MPTCP) Application Interface Considerations. M. Scharf, A. Ford. March 2013. (Format: TXT=75704 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6897) 6898 Link Management Protocol Behavior Negotiation and Configuration Modifications. D. Li, D. Ceccarelli, L. Berger. March 2013. (Format: TXT=21446 bytes) (Updates RFC4204, RFC4207, RFC4209, RFC5818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6898) 6901 JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed., K. Zyp, M. Nottingham, Ed.. April 2013. (Format: TXT=13037 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6901) 6902 JavaScript Object Notation (JSON) Patch. P. Bryan, Ed., M. Nottingham, Ed.. April 2013. (Format: TXT=26405 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6902) 6903 Additional Link Relation Types. J. Snell. March 2013. (Format: TXT=10452 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6903) 6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP). J. Lennox. April 2013. (Format: TXT=33486 bytes) (Updates RFC3711) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6904) 6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL). T. Senevirathne, D. Bond, S. Aldrin, Y. Li, R. Watve. March 2013. (Format: TXT=24278 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6905) 6906 The 'profile' Link Relation Type. E. Wilde. March 2013. (Format: TXT=18469 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6906) 6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties. T. Manderson, K. Sriram, R. White. March 2013. (Format: TXT=66099 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6907) 6908 Deployment Considerations for Dual-Stack Lite. Y. Lee, R. Maglione, C. Williams, C. Jacquenet, M. Boucadair. March 2013. (Format: TXT=35359 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6908) 6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6. S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli. April 2013. (Format: TXT=34575 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6909) 6910 Completion of Calls for the Session Initiation Protocol (SIP). D. Worley, M. Huelsemann, R. Jesske, D. Alexeitsev. April 2013. (Format: TXT=86166 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6910) 6911 RADIUS Attributes for IPv6 Access Networks. W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet. April 2013. (Format: TXT=28123 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6911) 6912 Principles for Unicode Code Point Inclusion in Labels in the DNS. A. Sullivan, D. Thaler, J. Klensin, O. Kolkman. April 2013. (Format: TXT=27078 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6912) 6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP). D. Hanes, G. Salgueiro, K. Fleming. March 2013. (Format: TXT=18119 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6913) 6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP). J. Rosenberg. April 2013. (Format: TXT=35472 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6914) 6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD). R. Bellis. April 2013. (Format: TXT=14175 bytes) (Updates RFC6155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6915) 6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI). R. Gagliano, S. Kent, S. Turner. April 2013. (Format: TXT=48395 bytes) (Also BCP0182) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6916) 6917 Media Resource Brokering. C. Boulton, L. Miniero, G. Munson. April 2013. (Format: TXT=280399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6917) 6918 Formally Deprecating Some ICMPv4 Message Types. F. Gont, C. Pignataro. April 2013. (Format: TXT=13639 bytes) (Obsoletes RFC1788) (Updates RFC0792, RFC0950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6918) 6919 Further Key Words for Use in RFCs to Indicate Requirement Levels. R. Barnes, S. Kent, E. Rescorla. April 2013. (Format: TXT=11076 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6919) 6920 Naming Things with Hashes. S. Farrell, D. Kutscher, C. Dannewitz, B. Ohlman, A. Keranen, P. Hallam-Baker. April 2013. (Format: TXT=54124 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6920) 6921 Design Considerations for Faster-Than-Light (FTL) Communication. R. Hinden. April 2013. (Format: TXT=15100 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6921) 6922 The application/sql Media Type. Y. Shafranovich. April 2013. (Format: TXT=8453 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6922) 6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions. R. Winter, E. Gray, H. van Helvoort, M. Betts. May 2013. (Format: TXT=23811 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6923) 6924 Registration of Second-Level URN Namespaces under "ietf". B. Leiba. April 2013. (Format: TXT=5952 bytes) (Updates RFC2648) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6924) 6925 The DHCPv4 Relay Agent Identifier Sub-Option. B. Joshi, R. Desetti, M. Stapp. April 2013. (Format: TXT=17664 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6925) 6926 DHCPv4 Bulk Leasequery. K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz. April 2013. (Format: TXT=88215 bytes) (Updated by RFC7724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6926) 6927 Variants in Second-Level Names Registered in Top-Level Domains. J. Levine, P. Hoffman. May 2013. (Format: TXT=39615 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6927) 6928 Increasing TCP's Initial Window. J. Chu, N. Dukkipati, Y. Cheng, M. Mathis. April 2013. (Format: TXT=56523 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6928) 6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions. A. DeKok, A. Lior. April 2013. (Format: TXT=133099 bytes) (Updates RFC2865, RFC3575, RFC6158) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6929) 6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). D. Guo, S. Jiang, Ed., R. Despres, R. Maglione. April 2013. (Format: TXT=23573 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6930) 6931 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2013. (Format: TXT=75220 bytes) (Obsoletes RFC4051) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6931) 6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry. D. Harkins, Ed.. May 2013. (Format: TXT=20785 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6932) 6933 Entity MIB (Version 4). A. Bierman, D. Romascanu, J. Quittek, M. Chandramouli. May 2013. (Format: TXT=165278 bytes) (Obsoletes RFC4133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6933) 6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs). N. Bitar, Ed., S. Wadhwa, Ed., T. Haag, H. Li. June 2013. (Format: TXT=104111 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6934) 6935 IPv6 and UDP Checksums for Tunneled Packets. M. Eubanks, P. Chimento, M. Westerlund. April 2013. (Format: TXT=29055 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6935) 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format: TXT=99557 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6936) 6937 Proportional Rate Reduction for TCP. M. Mathis, N. Dukkipati, Y. Cheng. May 2013. (Format: TXT=39437 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6937) 6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID. J. Scudder. May 2013. (Format: TXT=3875 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6938) 6939 Client Link-Layer Address Option in DHCPv6. G. Halwasia, S. Bhandari, W. Dec. May 2013. (Format: TXT=14739 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6939) 6940 REsource LOcation And Discovery (RELOAD) Base Protocol. C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne. January 2014. (Format: TXT=403862 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6940) 6941 MPLS Transport Profile (MPLS-TP) Security Framework. L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed.. April 2013. (Format: TXT=27119 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6941) 6942 Diameter Support for the EAP Re-authentication Protocol (ERP). J. Bournelle, L. Morand, S. Decugis, Q. Wu, G. Zorn. May 2013. (Format: TXT=35357 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6942) 6943 Issues in Identifier Comparison for Security Purposes. D. Thaler, Ed.. May 2013. (Format: TXT=62676 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6943) 6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status. S. Rose. April 2013. (Format: TXT=13876 bytes) (Updates RFC2536, RFC2539, RFC3110, RFC4034, RFC4398, RFC5155, RFC5702, RFC5933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6944) 6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol. R. Bush, B. Wijnen, K. Patel, M. Baer. May 2013. (Format: TXT=52515 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6945) 6946 Processing of IPv6 "Atomic" Fragments. F. Gont. May 2013. (Format: TXT=18843 bytes) (Updates RFC2460, RFC5722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6946) 6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute. M. Boucadair, H. Kaplan, R. Gilman, S. Veikkolainen. May 2013. (Format: TXT=51910 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6947) 6948 Some Measurements on World IPv6 Day from an End-User Perspective. A. Keranen, J. Arkko. July 2013. (Format: TXT=25416, PDF=114829 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6948) 6949 RFC Series Format Requirements and Future Development. H. Flanagan, N. Brownlee. May 2013. (Format: TXT=29181 bytes) (Updates RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6949) 6950 Architectural Considerations on Application Features in the DNS. J. Peterson, O. Kolkman, H. Tschofenig, B. Aboba. October 2013. (Format: TXT=85548 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6950) 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication. M. Tuexen, R. Stewart. May 2013. (Format: TXT=25676 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6951) 6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide. M. Jethanandani, K. Patel, L. Zheng. May 2013. (Format: TXT=37969 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6952) 6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements. A. Mancuso, Ed., S. Probasco, B. Patil. May 2013. (Format: TXT=53560 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6953) 6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2). J. Merkle, M. Lochter. July 2013. (Format: TXT=20366 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6954) 6955 Diffie-Hellman Proof-of-Possession Algorithms. J. Schaad, H. Prafullchandra. May 2013. (Format: TXT=81491 bytes) (Obsoletes RFC2875) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6955) 6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library. W. Wang, E. Haleplidis, K. Ogawa, C. Li, J. Halpern. June 2013. (Format: TXT=236056 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6956) 6957 Duplicate Address Detection Proxy. F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li. June 2013. (Format: TXT=32537 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6957) 6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting. A. Clark, S. Zhang, J. Zhao, Q. Wu, Ed.. May 2013. (Format: TXT=31057 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6958) 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=62217 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 2013. (Format: TXT=82037 bytes) (Obsoletes RFC2560, RFC6277) (Updates RFC5912) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6960) 6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension. Y. Pettersen. June 2013. (Format: TXT=21473 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6961) 6962 Certificate Transparency. B. Laurie, A. Langley, E. Kasper. June 2013. (Format: TXT=55048 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6962) 6963 A Uniform Resource Name (URN) Namespace for Examples. P. Saint-Andre. May 2013. (Format: TXT=11749 bytes) (Also BCP0183) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6963) 6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin. May 2013. (Format: TXT=49568 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6964) 6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design. L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan. August 2013. (Format: TXT=36728 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6965) 6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments. M. Boucadair, J. Touch, P. Levis, R. Penno. June 2013. (Format: TXT=53498 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6967) 6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca, B. Adamson. July 2013. (Format: TXT=96399 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6968) 6969 OSPFv3 Instance ID Registry Update. A. Retana, D. Cheng. July 2013. (Format: TXT=7959 bytes) (Updates RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6969) 6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). M. Boucadair, R. Penno, D. Wing. July 2013. (Format: TXT=50900 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6970) 6971 Depth-First Forwarding (DFF) in Unreliable Networks. U. Herberg, Ed., A. Cardenas, T. Iwao, M. Dow, S. Cespedes. June 2013. (Format: TXT=95276 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6971) 6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP). Y. Zhang, N. Zong. July 2013. (Format: TXT=53634 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6972) 6973 Privacy Considerations for Internet Protocols. A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith. July 2013. (Format: TXT=89198 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6973) 6974 Applicability of MPLS Transport Profile for Ring Topologies. Y. Weingarten, S. Bryant, D. Ceccarelli, D. Caviglia, F. Fondelli, M. Corsi, B. Wu, X. Dai. July 2013. (Format: TXT=69318 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6974) 6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC). S. Crocker, S. Rose. July 2013. (Format: TXT=18353 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6975) 6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach. M. Shand, S. Bryant, S. Previdi, C. Filsfils, P. Francois, O. Bonaventure. July 2013. (Format: TXT=61011 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6976) 6977 Triggering DHCPv6 Reconfiguration from Relay Agents. M. Boucadair, X. Pougnard. July 2013. (Format: TXT=29769 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6977) 6978 A TCP Authentication Option Extension for NAT Traversal. J. Touch. July 2013. (Format: TXT=11461 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6978) 6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). T. Pornin. August 2013. (Format: TXT=140386 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6979) 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery. F. Gont. August 2013. (Format: TXT=20850 bytes) (Updates RFC3971, RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6980) 6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses. S. Bryant, S. Previdi, M. Shand. August 2013. (Format: TXT=79311 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6981) 6982 Improving Awareness of Running Code: The Implementation Status Section. Y. Sheffer, A. Farrel. July 2013. (Format: TXT=19358 bytes) (Obsoleted by RFC7942) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6982) 6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI). R. van Brandenburg, O. van Deventer, F. Le Faucheur, K. Leung. July 2013. (Format: TXT=107197 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6983) 6984 Interoperability Report for Forwarding and Control Element Separation (ForCES). W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim. August 2013. (Format: TXT=70308 bytes) (Updates RFC6053) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6984) 6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing. A. Morton. July 2013. (Format: TXT=19782 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6985) 6986 GOST R 34.11-2012: Hash Function. V. Dolmatov, Ed., A. Degtyarev. August 2013. (Format: TXT=78975 bytes) (Updates RFC5831) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6986) 6987 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson. September 2013. (Format: TXT=10890 bytes) (Obsoletes RFC3137) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6987) 6988 Requirements for Energy Management. J. Quittek, Ed., M. Chandramouli, R. Winter, T. Dietz, B. Claise. September 2013. (Format: TXT=58116 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6988) 6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Sheffer, S. Fluhrer. July 2013. (Format: TXT=21099 bytes) (Updates RFC5996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6989) 6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting. R. Huang, Q. Wu, H. Asaeda, G. Zorn. August 2013. (Format: TXT=21657 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6990) 6991 Common YANG Data Types. J. Schoenwaelder, Ed.. July 2013. (Format: TXT=60242 bytes) (Obsoletes RFC6021) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6991) 6992 Routing for IPv4-Embedded IPv6 Packets. D. Cheng, M. Boucadair, A. Retana. July 2013. (Format: TXT=34703 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6992) 6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP). P. Saint-Andre. July 2013. (Format: TXT=7431 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6993) 6994 Shared Use of Experimental TCP Options. J. Touch. August 2013. (Format: TXT=25577 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6994) 6996 Autonomous System (AS) Reservation for Private Use. J. Mitchell. July 2013. (Format: TXT=8198 bytes) (Updates RFC1930) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6996) 6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks. M. Goyal, Ed., E. Baccelli, M. Philipp, A. Brandt, J. Martocci. August 2013. (Format: TXT=96596 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6997) 6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network. M. Goyal, Ed., E. Baccelli, A. Brandt, J. Martocci. August 2013. (Format: TXT=68274 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6998) 7001 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. September 2013. (Format: TXT=101316 bytes) (Obsoletes RFC5451, RFC6577) (Obsoleted by RFC7601) (Updated by RFC7410) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7001) 7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting. A. Clark, G. Zorn, Q. Wu. September 2013. (Format: TXT=22523 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7002) 7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting. A. Clark, R. Huang, Q. Wu, Ed.. September 2013. (Format: TXT=25970 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7003) 7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting. G. Zorn, R. Schott, Q. Wu, Ed., R. Huang. September 2013. (Format: TXT=41795 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7004) 7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting. A. Clark, V. Singh, Q. Wu. September 2013. (Format: TXT=27050 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7005) 7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP). M. Garcia-Martin, S. Veikkolainen, R. Gilman. September 2013. (Format: TXT=47133, PDF=163470 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7006) 7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP). T. Terriberry. August 2013. (Format: TXT=6777 bytes) (Updates RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7007) 7008 A Description of the KCipher-2 Encryption Algorithm. S. Kiyomoto, W. Shin. August 2013. (Format: TXT=71051 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7008) 7009 OAuth 2.0 Token Revocation. T. Lodderstedt, Ed., S. Dronia, M. Scurtescu. August 2013. (Format: TXT=23517 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7009) 7010 IPv6 Site Renumbering Gap Analysis. B. Liu, S. Jiang, B. Carpenter, S. Venaas, W. George. September 2013. (Format: TXT=57067 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7010) 7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information. B. Claise, Ed., B. Trammell, Ed., P. Aitken. September 2013. (Format: TXT=170852 bytes) (Obsoletes RFC5101) (Also STD0077) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7011) 7012 Information Model for IP Flow Information Export (IPFIX). B. Claise, Ed., B. Trammell, Ed.. September 2013. (Format: TXT=50237 bytes) (Obsoletes RFC5102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7012) 7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements. B. Trammell, B. Claise. September 2013. (Format: TXT=76406 bytes) (Also BCP0184) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7013) 7014 Flow Selection Techniques. S. D'Antonio, T. Zseby, C. Henke, L. Peluso. September 2013. (Format: TXT=72581 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7014) 7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol. B. Trammell, A. Wagner, B. Claise. September 2013. (Format: TXT=112055 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7015) 7016 Adobe's Secure Real-Time Media Flow Protocol. M. Thornburgh. November 2013. (Format: TXT=236685 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7016) 7017 IMAP Access to IETF Email List Archives. R. Sparks. August 2013. (Format: TXT=9886 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7017) 7018 Auto-Discovery VPN Problem Statement and Requirements. V. Manral, S. Hanna. September 2013. (Format: TXT=27284 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7018) 7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD). J. Buford, M. Kolberg, Ed.. September 2013. (Format: TXT=83788 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7019) 7020 The Internet Numbers Registry System. R. Housley, J. Curran, G. Huston, D. Conrad. August 2013. (Format: TXT=19332 bytes) (Obsoletes RFC2050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7020) 7021 Assessing the Impact of Carrier-Grade NAT on Network Applications. C. Donley, Ed., L. Howard, V. Kuarsingh, J. Berg, J. Doshi. September 2013. (Format: TXT=66150 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7021) 7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). A. Begen, C. Perkins, D. Wing, E. Rescorla. September 2013. (Format: TXT=21717 bytes) (Obsoletes RFC6222) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7022) 7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking. D. Mohan, Ed., N. Bitar, Ed., A. Sajassi, Ed., S. DeLord, P. Niger, R. Qiu. October 2013. (Format: TXT=47621 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7023) 7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs. H. Jeng, J. Uttaro, L. Jalil, B. Decraene, Y. Rekhter, R. Aggarwal. October 2013. (Format: TXT=62926 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7024) 7025 Requirements for GMPLS Applications of PCE. T. Otani, K. Ogaki, D. Caviglia, F. Zhang, C. Margaria. September 2013. (Format: TXT=26498 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7025) 7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel. A. Farrel, S. Bryant. September 2013. (Format: TXT=9297 bytes) (Updates RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7026) 7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS). J. Merkle, M. Lochter. October 2013. (Format: TXT=16366 bytes) (Updates RFC4492) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7027) 7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6. JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim. September 2013. (Format: TXT=63110 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7028) 7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding. S. Hartman, M. Wasserman, D. Zhang. October 2013. (Format: TXT=45360 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7029) 7030 Enrollment over Secure Transport. M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed.. October 2013. (Format: TXT=123989 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7030) 7031 DHCPv6 Failover Requirements. T. Mrugalski, K. Kinnear. September 2013. (Format: TXT=39321 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7031) 7032 LDP Downstream-on-Demand in Seamless MPLS. T. Beckhaus, Ed., B. Decraene, K. Tiruveedhula, M. Konstantynowicz, Ed., L. Martini. October 2013. (Format: TXT=75588 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7032) 7033 WebFinger. P. Jones, G. Salgueiro, M. Jones, J. Smarr. September 2013. (Format: TXT=61552 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7033) 7034 HTTP Header Field X-Frame-Options. D. Ross, T. Gondrom. October 2013. (Format: TXT=27263 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7034) 7035 Relative Location Representation. M. Thomson, B. Rosen, D. Stanley, G. Bajko, A. Thomson. October 2013. (Format: TXT=74709 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7035) 7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group. R. Housley. October 2013. (Format: TXT=14314 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7036) 7037 RADIUS Option for the DHCPv6 Relay Agent. L. Yeh, M. Boucadair. October 2013. (Format: TXT=23356 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7037) 7038 Use of OSPF-MDR in Single-Hop Broadcast Networks. R. Ogier. October 2013. (Format: TXT=15535 bytes) (Updates RFC5614) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7038) 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: TXT=31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) 7040 Public IPv4-over-IPv6 Access Network. Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee. November 2013. (Format: TXT=27273 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7040) 7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging. F. Balus, Ed., A. Sajassi, Ed., N. Bitar, Ed.. November 2013. (Format: TXT=31236 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7041) 7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters. D. Eastlake 3rd, J. Abley. October 2013. (Format: TXT=53488 bytes) (Obsoletes RFC5342) (Updates RFC2153) (Also BCP0141) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7042) 7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS. J. Abley. October 2013. (Format: TXT=15504 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7043) 7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information. M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg. February 2014. (Format: TXT=85068 bytes) (Obsoletes RFC4244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7044) 7045 Transmission and Processing of IPv6 Extension Headers. B. Carpenter, S. Jiang. December 2013. (Format: TXT=21852 bytes) (Updates RFC2460, RFC2780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7045) 7046 A Common API for Transparent Hybrid Multicast. M. Waehlisch, T. Schmidt, S. Venaas. December 2013. (Format: TXT=85861 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7046) 7047 The Open vSwitch Database Management Protocol. B. Pfaff, B. Davie, Ed.. December 2013. (Format: TXT=69446 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7047) 7048 Neighbor Unreachability Detection Is Too Impatient. E. Nordmark, I. Gashinsky. January 2014. (Format: TXT=17946 bytes) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7048) 7049 Concise Binary Object Representation (CBOR). C. Bormann, P. Hoffman. October 2013. (Format: TXT=134062 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7049) 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis. T. Savolainen, J. Korhonen, D. Wing. November 2013. (Format: TXT=50097 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7050) 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix. J. Korhonen, Ed., T. Savolainen, Ed.. November 2013. (Format: TXT=55248 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7051) 7052 Locator/ID Separation Protocol (LISP) MIB. G. Schudel, A. Jain, V. Moreno. October 2013. (Format: TXT=125519 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7052) 7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol. M. Tuexen, I. Ruengeler, R. Stewart. November 2013. (Format: TXT=15773 bytes) (Updates RFC4960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7053) 7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs). A. Farrel, H. Endo, R. Winter, Y. Koike, M. Paul. November 2013. (Format: TXT=25444 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7054) 7055 A GSS-API Mechanism for the Extensible Authentication Protocol. S. Hartman, Ed., J. Howlett. December 2013. (Format: TXT=87564 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7055) 7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism. S. Hartman, J. Howlett. December 2013. (Format: TXT=24622 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7056) 7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB). S. Winter, J. Salowey. December 2013. (Format: TXT=16006 bytes) (Updates RFC3748) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7057) 7058 Media Control Channel Framework (CFW) Call Flow Examples. A. Amirante, T. Castaldi, L. Miniero, S P. Romano. November 2013. (Format: TXT=387335 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7058) 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms. S. Steffann, I. van Beijnum, R. van Rein. November 2013. (Format: TXT=98886 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7059) 7060 Using LDP Multipoint Extensions on Targeted LDP Sessions. M. Napierala, E. Rosen, IJ. Wijnands. November 2013. (Format: TXT=19384 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7060) 7061 eXtensible Access Control Markup Language (XACML) XML Media Type. R. Sinnema, E. Wilde. November 2013. (Format: TXT=14666 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7061) 7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks. F. Zhang, Ed., D. Li, H. Li, S. Belotti, D. Ceccarelli. November 2013. (Format: TXT=56109 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7062) 7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments. L. Zheng, J. Zhang, R. Parekh. December 2013. (Format: TXT=21964 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7063) 7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol. S. Nandakumar, G. Salgueiro, P. Jones, M. Petit-Huguenin. November 2013. (Format: TXT=15045 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7064) 7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers. M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones. November 2013. (Format: TXT=16143 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7065) 7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts. J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan. November 2013. (Format: TXT=44253 bytes) (Obsoletes RFC3316) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7066) 7067 Directory Assistance Problem and High-Level Design Proposal. L. Dunbar, D. Eastlake 3rd, R. Perlman, I. Gashinsky. November 2013. (Format: TXT=34720 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7067) 7068 Diameter Overload Control Requirements. E. McMurry, B. Campbell. November 2013. (Format: TXT=69536 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7068) 7069 DECoupled Application Data Enroute (DECADE). R. Alimi, A. Rahman, D. Kutscher, Y. Yang, H. Song, K. Pentikousis. November 2013. (Format: TXT=81867 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7069) 7070 An Architecture for Reputation Reporting. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT=32262 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7070) 7071 A Media Type for Reputation Interchange. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT=29541 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7071) 7072 A Reputation Query Protocol. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT=17416 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7072) 7073 A Reputation Response Set for Email Identifiers. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT=14857 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7073) 7074 Revised Definition of the GMPLS Switching Capability and Type Fields. L. Berger, J. Meuric. November 2013. (Format: TXT=19376 bytes) (Updates RFC3471, RFC4202, RFC4203, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7074) 7075 Realm-Based Redirection In Diameter. T. Tsou, R. Hao, T. Taylor, Ed.. November 2013. (Format: TXT=21434 bytes) (Updates RFC6733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7075) 7076 P6R's Secure Shell Public Key Subsystem. M. Joseph, J. Susoy. November 2013. (Format: TXT=20430 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7076) 7077 Update Notifications for Proxy Mobile IPv6. S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota, J. Korhonen. November 2013. (Format: TXT=49176 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7077) 7078 Distributing Address Selection Policy Using DHCPv6. A. Matsumoto, T. Fujisaki, T. Chown. January 2014. (Format: TXT=25094 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7078) 7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results. N. Del Regno, Ed., A. Malis, Ed.. November 2013. (Format: TXT=67854 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7079) 7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges. A. Sajassi, S. Salam, N. Bitar, F. Balus. December 2013. (Format: TXT=61560 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7080) 7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). E. Ivov, P. Saint-Andre, E. Marocco. November 2013. (Format: TXT=46772 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7081) 7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP). R. Shekh-Yusef, M. Barnes. December 2013. (Format: TXT=18709 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7082) 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. R. Droms. November 2013. (Format: TXT=14630 bytes) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7083) 7084 Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark. November 2013. (Format: TXT=46569 bytes) (Obsoletes RFC6204) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7084) 7085 Top-Level Domains That Are Already Dotless. J. Levine, P. Hoffman. December 2013. (Format: TXT=11369 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7085) 7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD). A. Keranen, G. Camarillo, J. Maenpaa. January 2014. (Format: TXT=21406 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7086) 7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations. H. van Helvoort, Ed., L. Andersson, Ed., N. Sprecher, Ed.. December 2013. (Format: TXT=43925 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7087) 7088 Session Initiation Protocol Service Example -- Music on Hold. D. Worley. February 2014. (Format: TXT=69311 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7088) 7089 HTTP Framework for Time-Based Access to Resource States -- Memento. H. Van de Sompel, M. Nelson, R. Sanderson. December 2013. (Format: TXT=107130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7089) 7090 Public Safety Answering Point (PSAP) Callback. H. Schulzrinne, H. Tschofenig, C. Holmberg, M. Patel. April 2014. (Format: TXT=37445 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7090) 7091 GOST R 34.10-2012: Digital Signature Algorithm. V. Dolmatov, Ed., A. Degtyarev. December 2013. (Format: TXT=39924 bytes) (Updates RFC5832) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7091) 7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents. H. Kaplan, V. Pascual. December 2013. (Format: TXT=22085 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7092) 7093 Additional Methods for Generating Key Identifiers Values. S. Turner, S. Kent, J. Manger. December 2013. (Format: TXT=7622 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7093) 7094 Architectural Considerations of IP Anycast. D. McPherson, D. Oran, D. Thaler, E. Osterweil. January 2014. (Format: TXT=50246 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7094) 7095 jCard: The JSON Format for vCard. P. Kewisch. January 2014. (Format: TXT=59088 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7095) 7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs). S. Belotti, Ed., P. Grandi, D. Ceccarelli, Ed., D. Caviglia, F. Zhang, D. Li. January 2014. (Format: TXT=50281 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7096) 7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets. J. Ott, V. Singh, Ed., I. Curcio. January 2014. (Format: TXT=20581 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7097) 7098 Using the IPv6 Flow Label for Load Balancing in Server Farms. B. Carpenter, S. Jiang, W. Tarreau. January 2014. (Format: TXT=30884 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7098) 7100 Retirement of the "Internet Official Protocol Standards" Summary Document. P. Resnick. December 2013. (Format: TXT=5365 bytes) (Obsoletes RFC5000) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7100) 7101 List of Internet Official Protocol Standards: Replaced by a Web Page. S. Ginoza. December 2013. (Format: TXT=6922 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7101) 7102 Terms Used in Routing for Low-Power and Lossy Networks. JP. Vasseur. January 2014. (Format: TXT=16444 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7102) 7103 Advice for Safe Handling of Malformed Messages. M. Kucherawy, G. Shapiro, N. Freed. January 2014. (Format: TXT=48387 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7103) 7104 Duplication Grouping Semantics in the Session Description Protocol. A. Begen, Y. Cai, H. Ou. January 2014. (Format: TXT=17719 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7104) 7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols. M. Thomson, J. Winterbottom. January 2014. (Format: TXT=155084 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7105) 7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State. E. Ivov. January 2014. (Format: TXT=11939 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7106) 7107 Object Identifier Registry for the S/MIME Mail Security Working Group. R. Housley. January 2014. (Format: TXT=43898 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7107) 7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes. J. Abley, T. Manderson. January 2014. (Format: TXT=24125 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7108) 7109 Flow Bindings Initiated by Home Agents for Mobile IPv6. H. Yokota, D. Kim, B. Sarikaya, F. Xia. February 2014. (Format: TXT=40637 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7109) 7110 Return Path Specified Label Switched Path (LSP) Ping. M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord. January 2014. (Format: TXT=44625 bytes) (Updated by RFC7737) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7110) 7111 URI Fragment Identifiers for the text/csv Media Type. M. Hausenblas, E. Wilde, J. Tennison. January 2014. (Format: TXT=24818 bytes) (Updates RFC4180) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7111) 7112 Implications of Oversized IPv6 Header Chains. F. Gont, V. Manral, R. Bonica. January 2014. (Format: TXT=15897 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7112) 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard). F. Gont. February 2014. (Format: TXT=29272 bytes) (Updates RFC6105) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7113) 7114 Creation of a Registry for smime-type Parameter Values. B. Leiba. January 2014. (Format: TXT=7176 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7114) 7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI). R. Bush. January 2014. (Format: TXT=26033 bytes) (Also BCP0185) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7115) 7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries. K. Scott, M. Blanchet. February 2014. (Format: TXT=18568 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7116) 7117 Multicast in Virtual Private LAN Service (VPLS). R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya. February 2014. (Format: TXT=126280 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7117) 7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP). I. Baz Castillo, J. Millan Villegas, V. Pascual. January 2014. (Format: TXT=51248 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7118) 7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators. B. Claise, A. Kobayashi, B. Trammell. February 2014. (Format: TXT=74807 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7119) 7120 Early IANA Allocation of Standards Track Code Points. M. Cotton. January 2014. (Format: TXT=17722 bytes) (Obsoletes RFC4020) (Also BCP0100) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7120) 7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element. K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim. February 2014. (Format: TXT=62599 bytes) (Updates RFC5810) (Updated by RFC7391) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7121) 7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP). H. Kruse, S. Jero, S. Ostermann. March 2014. (Format: TXT=25889 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7122) 7123 Security Implications of IPv6 on IPv4 Networks. F. Gont, W. Liu. February 2014. (Format: TXT=42374 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7123) 7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB. E. Beili. February 2014. (Format: TXT=12123 bytes) (Updates RFC5066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7124) 7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element. B. Trammell, P. Aitken. February 2014. (Format: TXT=11679 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7125) 7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options. F. Gont, R. Atkinson, C. Pignataro. February 2014. (Format: TXT=72504 bytes) (Also BCP0186) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7126) 7127 Characterization of Proposed Standards. O. Kolkman, S. Bradner, S. Turner. January 2014. (Format: TXT=9902 bytes) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7127) 7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report. R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch. February 2014. (Format: TXT=19348 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7128) 7129 Authenticated Denial of Existence in the DNS. R. Gieben, W. Mekking. February 2014. (Format: TXT=62936 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7129) 7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces. M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed.. February 2014. (Format: TXT=21291 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7130) 7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples. M. Barnes, F. Audet, S. Schubert, H. van Elburg, C. Holmberg. March 2014. (Format: TXT=93039 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7131) 7132 Threat Model for BGP Path Security. S. Kent, A. Chi. February 2014. (Format: TXT=52539 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7132) 7133 Information Elements for Data Link Layer Traffic Measurement. S. Kashima, A. Kobayashi, Ed., P. Aitken. May 2014. (Format: TXT=76209 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7133) 7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review". B. Rosen. March 2014. (Format: TXT=3565 bytes) (Updates RFC4412) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7134) 7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications. J. Polk. May 2014. (Format: TXT=20749 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7135) 7136 Significance of IPv6 Interface Identifiers. B. Carpenter, S. Jiang. February 2014. (Format: TXT=23172 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7136) 7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks. A. Retana, S. Ratliff. February 2014. (Format: TXT=16017 bytes) (Updates RFC5820) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7137) 7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks. D. Ceccarelli, Ed., F. Zhang, S. Belotti, R. Rao, J. Drake. March 2014. (Format: TXT=77038 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7138) 7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks. F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan. March 2014. (Format: TXT=58382 bytes) (Updates RFC4328) (Updated by RFC7892) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7139) 7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path. L. Jin, F. Jounay, IJ. Wijnands, N. Leymann. March 2014. (Format: TXT=33570 bytes) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7140) 7141 Byte and Packet Congestion Notification. B. Briscoe, J. Manner. February 2014. (Format: TXT=103344 bytes) (Updates RFC2309, RFC2914) (Also BCP0041) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7141) 7142 Reclassification of RFC 1142 to Historic. M. Shand, L. Ginsberg. February 2014. (Format: TXT=5036 bytes) (Obsoletes RFC1142) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7142) 7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated). M. Chadalapaka, J. Satran, K. Meth, D. Black. April 2014. (Format: TXT=655576 bytes) (Obsoletes RFC3720, RFC3980, RFC4850, RFC5048) (Updates RFC3721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7143) 7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update. F. Knight, M. Chadalapaka. April 2014. (Format: TXT=49817 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7144) 7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification. M. Ko, A. Nezhinsky. April 2014. (Format: TXT=214093 bytes) (Obsoletes RFC5046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7145) 7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3. D. Black, P. Koning. April 2014. (Format: TXT=37991 bytes) (Updates RFC3720, RFC3723, RFC3821, RFC3822, RFC4018, RFC4172, RFC4173, RFC4174, RFC5040, RFC5041, RFC5042, RFC5043, RFC5044, RFC5045, RFC5046, RFC5047, RFC5048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7146) 7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI). M. Bakke, P. Venkatesen. April 2014. (Format: TXT=175936 bytes) (Obsoletes RFC4544) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7147) 7148 Prefix Delegation Support for Proxy Mobile IPv6. X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos. March 2014. (Format: TXT=60422 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7148) 7149 Software-Defined Networking: A Perspective from within a Service Provider Environment. M. Boucadair, C. Jacquenet. March 2014. (Format: TXT=47516 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7149) 7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol. F. Zhang, A. Farrel. March 2014. (Format: TXT=24156 bytes) (Obsoleted by RFC7470) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7150) 7151 File Transfer Protocol HOST Command for Virtual Hosts. P. Hethmon, R. McMurray. March 2014. (Format: TXT=54330 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7151) 7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN). R. Key, Ed., S. DeLord, F. Jounay, L. Huang, Z. Liu, M. Paul. March 2014. (Format: TXT=22795 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7152) 7153 IANA Registries for BGP Extended Communities. E. Rosen, Y. Rekhter. March 2014. (Format: TXT=30557 bytes) (Updates RFC4360, RFC5701) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7153) 7154 IETF Guidelines for Conduct. S. Moonesamy, Ed.. March 2014. (Format: TXT=12363 bytes) (Obsoletes RFC3184) (Also BCP0054) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7154) 7155 Diameter Network Access Server Application. G. Zorn, Ed.. April 2014. (Format: TXT=154559 bytes) (Obsoletes RFC4005) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7155) 7156 Diameter Support for Proxy Mobile IPv6 Localized Routing. G. Zorn, Q. Wu, J. Korhonen. April 2014. (Format: TXT=25657 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7156) 7157 IPv6 Multihoming without Network Address Translation. O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing. March 2014. (Format: TXT=49038 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7157) 7158 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. March 2014. (Format: TXT=27451 bytes) (Obsoleted by RFC7159) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7158) 7159 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. March 2014. (Format: TXT=27451 bytes) (Obsoletes RFC4627, RFC7158) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7159) 7160 Support for Multiple Clock Rates in an RTP Session. M. Petit-Huguenin, G. Zorn, Ed.. April 2014. (Format: TXT=25255 bytes) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7160) 7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL). LM. Contreras, CJ. Bernardos, I. Soto. March 2014. (Format: TXT=85916 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7161) 7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC). A. Melnikov, D. Cridland. May 2014. (Format: TXT=111930 bytes) (Obsoletes RFC4551, RFC5162) (Updates RFC2683) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7162) 7163 URN for Country-Specific Emergency Services. C. Holmberg, I. Sedlacek. March 2014. (Format: TXT=7884 bytes) (Updates RFC5031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7163) 7164 RTP and Leap Seconds. K. Gross, R. Brandenburg. March 2014. (Format: TXT=20637 bytes) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7164) 7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). R. Barnes. April 2014. (Format: TXT=58324 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7165) 7166 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. March 2014. (Format: TXT=49533 bytes) (Obsoletes RFC6506) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7166) 7167 A Framework for Point-to-Multipoint MPLS in Transport Networks. D. Frost, S. Bryant, M. Bocci, L. Berger. April 2014. (Format: TXT=23842 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7167) 7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA). I. Nazar. April 2014. (Format: TXT=14490 bytes) (Updates RFC2324) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7168) 7169 The NSA (No Secrecy Afforded) Certificate Extension. S. Turner. April 2014. (Format: TXT=5480 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7169) 7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1. H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna. May 2014. (Format: TXT=205545 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7170) 7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods. N. Cam-Winget, P. Sangster. May 2014. (Format: TXT=45604 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7171) 7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling. D. Eastlake 3rd, M. Zhang, P. Agarwal, R. Perlman, D. Dutt. May 2014. (Format: TXT=61855 bytes) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7172) 7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires. L. Yong, D. Eastlake 3rd, S. Aldrin, J. Hudson. May 2014. (Format: TXT=21280 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7173) 7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework. S. Salam, T. Senevirathne, S. Aldrin, D. Eastlake 3rd. May 2014. (Format: TXT=73464 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7174) 7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support. V. Manral, D. Eastlake 3rd, D. Ward, A. Banerjee. May 2014. (Format: TXT=24954 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7175) 7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS. D. Eastlake 3rd, T. Senevirathne, A. Ghanwani, D. Dutt, A. Banerjee. May 2014. (Format: TXT=98059 bytes) (Obsoletes RFC6326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7176) 7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency. D. Eastlake 3rd, R. Perlman, A. Ghanwani, H. Yang, V. Manral. May 2014. (Format: TXT=77117 bytes) (Obsoletes RFC6327) (Updates RFC6325) (Updated by RFC7780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7177) 7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support. D. Eastlake 3rd, V. Manral, Y. Li, S. Aldrin, D. Ward. May 2014. (Format: TXT=49461 bytes) (Updated by RFC7978) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7178) 7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension. D. Eastlake 3rd, A. Ghanwani, V. Manral, Y. Li, C. Bestler. May 2014. (Format: TXT=25422 bytes) (Updates RFC6325) (Updated by RFC7780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7179) 7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang, A. Ghanwani, V. Manral, A. Banerjee. May 2014. (Format: TXT=56276 bytes) (Obsoleted by RFC7780) (Updates RFC6325, RFC6327, RFC6439) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7180) 7181 The Optimized Link State Routing Protocol Version 2. T. Clausen, C. Dearlove, P. Jacquet, U. Herberg. April 2014. (Format: TXT=253538 bytes) (Updated by RFC7183, RFC7187, RFC7188, RFC7466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7181) 7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs). U. Herberg, T. Clausen, C. Dearlove. April 2014. (Format: TXT=68671 bytes) (Obsoletes RFC6622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7182) 7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2). U. Herberg, C. Dearlove, T. Clausen. April 2014. (Format: TXT=33255 bytes) (Updates RFC6130, RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7183) 7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2. U. Herberg, R. Cole, T. Clausen. April 2014. (Format: TXT=175224 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7184) 7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale. C. Dearlove, T. Clausen, P. Jacquet. April 2014. (Format: TXT=59906 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7185) 7186 Security Threats for the Neighborhood Discovery Protocol (NHDP). J. Yi, U. Herberg, T. Clausen. April 2014. (Format: TXT=45763 bytes) (Updated by RFC7985) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7186) 7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2). C. Dearlove, T. Clausen. April 2014. (Format: TXT=9341 bytes) (Updates RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7187) 7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs. C. Dearlove, T. Clausen. April 2014. (Format: TXT=36174 bytes) (Updates RFC6130, RFC7181) (Updated by RFC7722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7188) 7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP). G. Mirsky. March 2014. (Format: TXT=14254 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7189) 7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP). C. Villamizar. March 2014. (Format: TXT=36633 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7190) 7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types. R. Housley. April 2014. (Format: TXT=53803 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7191) 7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types. S. Turner. April 2014. (Format: TXT=11255 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7192) 7193 The application/cms Media Type. S. Turner, R. Housley, J. Schaad. April 2014. (Format: TXT=23621 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7193) 7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL. R. Hartmann. August 2014. (Format: TXT=9497 bytes) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7194) 7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN). M. Garcia-Martin, S. Veikkolainen. May 2014. (Format: TXT=92699 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7195) 7196 Making Route Flap Damping Usable. C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel. May 2014. (Format: TXT=15202 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7196) 7197 Duplication Delay Attribute in the Session Description Protocol. A. Begen, Y. Cai, H. Ou. April 2014. (Format: TXT=22559 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7197) 7198 Duplicating RTP Streams. A. Begen, C. Perkins. April 2014. (Format: TXT=29317 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7198) 7199 Location Configuration Extensions for Policy Management. R. Barnes, M. Thomson, J. Winterbottom, H. Tschofenig. April 2014. (Format: TXT=41313 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7199) 7200 A Session Initiation Protocol (SIP) Load-Control Event Package. C. Shen, H. Schulzrinne, A. Koike. April 2014. (Format: TXT=98689 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7200) 7201 Options for Securing RTP Sessions. M. Westerlund, C. Perkins. April 2014. (Format: TXT=92462 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7201) 7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution. C. Perkins, M. Westerlund. April 2014. (Format: TXT=23428 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7202) 7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information. T. Takahashi, K. Landfield, Y. Kadobayashi. April 2014. (Format: TXT=57694 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7203) 7204 Requirements for Labeled NFS. T. Haynes. April 2014. (Format: TXT=39350 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7204) 7205 Use Cases for Telepresence Multistreams. A. Romanow, S. Botzko, M. Duckworth, R. Even, Ed.. April 2014. (Format: TXT=42087 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7205) 7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks. P. Jones, G. Salgueiro, J. Polk, L. Liess, H. Kaplan. May 2014. (Format: TXT=28383 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7206) 7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging. M. Ortseifen, G. Dickfeld. April 2014. (Format: TXT=15690 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7207) 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. S. Kitterman. April 2014. (Format: TXT=144189 bytes) (Obsoletes RFC4408) (Updated by RFC7372) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7208) 7209 Requirements for Ethernet VPN (EVPN). A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac. May 2014. (Format: TXT=34040 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7209) 7210 Database of Long-Lived Symmetric Cryptographic Keys. R. Housley, T. Polk, S. Hartman, D. Zhang. April 2014. (Format: TXT=32642 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7210) 7211 Operations Model for Router Keying. S. Hartman, D. Zhang. June 2014. (Format: TXT=47824 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7211) 7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol. D. Frost, S. Bryant, M. Bocci. June 2014. (Format: TXT=52340 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7212) 7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing. D. Frost, S. Bryant, M. Bocci. June 2014. (Format: TXT=20407 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7213) 7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry. L. Andersson, C. Pignataro. May 2014. (Format: TXT=12382 bytes) (Updates RFC5586, RFC6374, RFC6378, RFC6427, RFC6428) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7214) 7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations. L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, D. Lewis. April 2014. (Format: TXT=68686 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7215) 7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS. M. Thomson, R. Bellis. April 2014. (Format: TXT=39389 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7216) 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). F. Gont. April 2014. (Format: TXT=48497 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7217) 7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE). O. Gudmundsson. April 2014. (Format: TXT=8907 bytes) (Updates RFC6698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7218) 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. (Format: TXT=90423 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7219) 7220 Description Option for the Port Control Protocol (PCP). M. Boucadair, R. Penno, D. Wing. May 2014. (Format: TXT=11332 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7220) 7221 Handling of Internet-Drafts by IETF Working Groups. A. Farrel, D. Crocker, Ed.. April 2014. (Format: TXT=31669 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7221) 7222 Quality-of-Service Option for Proxy Mobile IPv6. M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli. May 2014. (Format: TXT=139026 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7222) 7223 A YANG Data Model for Interface Management. M. Bjorklund. May 2014. (Format: TXT=70537 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7223) 7224 IANA Interface Type YANG Module. M. Bjorklund. May 2014. (Format: TXT=51377 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7224) 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP). M. Boucadair. May 2014. (Format: TXT=40239 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7225) 7226 Requirements for Advanced Multipath in MPLS Networks. C. Villamizar, Ed., D. McDysan, Ed., S. Ning, A. Malis, L. Yong. May 2014. (Format: TXT=38581 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7226) 7227 Guidelines for Creating New DHCPv6 Options. D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan. May 2014. (Format: TXT=83694 bytes) (Updates RFC3315) (Also BCP0187) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7227) 7228 Terminology for Constrained-Node Networks. C. Bormann, M. Ersue, A. Keranen. May 2014. (Format: TXT=37635 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7228) 7229 Object Identifiers for Test Certificate Policies. R. Housley. May 2014. (Format: TXT=6589 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7229) 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT=205947 bytes) (Obsoletes RFC2145, RFC2616) (Updates RFC2817, RFC2818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7230) 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT=235053 bytes) (Obsoletes RFC2616) (Updates RFC2817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7231) 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT=56696 bytes) (Obsoletes RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7232) 7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed.. June 2014. (Format: TXT=46933 bytes) (Obsoletes RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7233) 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. June 2014. (Format: TXT=90647 bytes) (Obsoletes RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7234) 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT=38142 bytes) (Obsoletes RFC2616, RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7235) 7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations. J. Reschke. June 2014. (Format: TXT=5770 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7236) 7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations. J. Reschke. June 2014. (Format: TXT=8732 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7237) 7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. June 2014. (Format: TXT=10623 bytes) (Obsoleted by RFC7538) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7238) 7239 Forwarded HTTP Extension. A. Petersson, M. Nilsson. June 2014. (Format: TXT=35003 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7239) 7240 Prefer Header for HTTP. J. Snell. June 2014. (Format: TXT=32796 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7240) 7241 The IEEE 802/IETF Relationship. S. Dawkins, P. Thaler, D. Romascanu, B. Aboba, Ed.. July 2014. (Format: TXT=80378 bytes) (Obsoletes RFC4441) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7241) 7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol. M. Demmer, J. Ott, S. Perreault. June 2014. (Format: TXT=53818 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7242) 7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric. V. Singh, Ed., J. Ott, I. Curcio. May 2014. (Format: TXT=23198 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7243) 7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting. H. Asaeda, Q. Wu, R. Huang. May 2014. (Format: TXT=27341 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7244) 7245 An Architecture for Media Recording Using the Session Initiation Protocol. A. Hutton, Ed., L. Portman, Ed., R. Jain, K. Rehor. May 2014. (Format: TXT=34314 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7245) 7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context. IJ. Wijnands, Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura. June 2014. (Format: TXT=24698 bytes) (Updated by RFC7438) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7246) 7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling. P. Saint-Andre, A. Houri, J. Hildebrand. May 2014. (Format: TXT=57218 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7247) 7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence. P. Saint-Andre, A. Houri, J. Hildebrand. May 2014. (Format: TXT=60875 bytes) (Obsoleted by RFC8048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7248) 7249 Internet Numbers Registries. R. Housley. May 2014. (Format: TXT=10070 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7249) 7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen. June 2014. (Format: TXT=38040 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7250) 7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS. D. McGrew, D. Bailey, M. Campagna, R. Dugal. June 2014. (Format: TXT=18851 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7251) 7252 The Constrained Application Protocol (CoAP). Z. Shelby, K. Hartke, C. Bormann. June 2014. (Format: TXT=258789 bytes) (Updated by RFC7959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7252) 7253 The OCB Authenticated-Encryption Algorithm. T. Krovetz, P. Rogaway. May 2014. (Format: TXT=39712 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7253) 7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI). M. Montemurro, Ed., A. Allen, D. McDonald, P. Gosden. May 2014. (Format: TXT=33488 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7254) 7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID. A. Allen, Ed.. May 2014. (Format: TXT=21606 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7255) 7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP). F. Le Faucheur, R. Maglione, T. Taylor. July 2014. (Format: TXT=234572 bytes) (Updates RFC6320) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7256) 7257 Virtual Private LAN Service (VPLS) Management Information Base. T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed.. July 2014. (Format: TXT=89099 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7257) 7258 Pervasive Monitoring Is an Attack. S. Farrell, H. Tschofenig. May 2014. (Format: TXT=13396 bytes) (Also BCP0188) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7258) 7259 The Jabber-ID Header Field. P. Saint-Andre. May 2014. (Format: TXT=12816 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7259) 7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration. A. Takacs, D. Fedyk, J. He. June 2014. (Format: TXT=58030 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7260) 7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B. M. Perumal, P. Ravindran. May 2014. (Format: TXT=14097 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7261) 7262 Requirements for Telepresence Multistreams. A. Romanow, S. Botzko, M. Barnes. June 2014. (Format: TXT=26403 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7262) 7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing. N. Zong, X. Jiang, R. Even, Y. Zhang. June 2014. (Format: TXT=42104 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7263) 7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing. N. Zong, X. Jiang, R. Even, Y. Zhang. June 2014. (Format: TXT=31995 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7264) 7265 jCal: The JSON Format for iCalendar. P. Kewisch, C. Daboo, M. Douglass. May 2014. (Format: TXT=56274 bytes) (Updated by RFC7529) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7265) 7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting. A. Clark, Q. Wu, R. Schott, G. Zorn. June 2014. (Format: TXT=48110 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7266) 7267 Dynamic Placement of Multi-Segment Pseudowires. L. Martini, Ed., M. Bocci, Ed., F. Balus, Ed.. June 2014. (Format: TXT=49414 bytes) (Updates RFC6073) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7267) 7268 RADIUS Attributes for IEEE 802 Networks. B. Aboba, J. Malinen, P. Congdon, J. Salowey, M. Jones. July 2014. (Format: TXT=56686 bytes) (Updates RFC3580, RFC4072) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7268) 7269 NAT64 Deployment Options and Experience. G. Chen, Z. Cao, C. Xie, D. Binet. June 2014. (Format: TXT=56043 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7269) 7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX). A. Yourtchenko, P. Aitken, B. Claise. June 2014. (Format: TXT=33990 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7270) 7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators. J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne. June 2014. (Format: TXT=87586 bytes) (Updates RFC6378) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7271) 7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP). R. van Brandenburg, H. Stokking, O. van Deventer, F. Boronat, M. Montagud, K. Gross. June 2014. (Format: TXT=56261 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7272) 7273 RTP Clock Source Signalling. A. Williams, K. Gross, R. van Brandenburg, H. Stokking. June 2014. (Format: TXT=63009 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7273) 7274 Allocating and Retiring Special-Purpose MPLS Labels. K. Kompella, L. Andersson, A. Farrel. June 2014. (Format: TXT=23442 bytes) (Updates RFC3032, RFC3038, RFC3209, RFC3811, RFC4182, RFC4928, RFC5331, RFC5586, RFC5921, RFC5960, RFC6391, RFC6478, RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7274) 7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy. L. Martini, S. Salam, A. Sajassi, M. Bocci, S. Matsushima, T. Nadeau. June 2014. (Format: TXT=172294 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7275) 7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools. T. Mizrahi, N. Sprecher, E. Bellagamba, Y. Weingarten. June 2014. (Format: TXT=120925 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7276) 7277 A YANG Data Model for IP Management. M. Bjorklund. June 2014. (Format: TXT=50043 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7277) 7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format: TXT=19965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278) 7279 An Acceptable Use Policy for New ICMP Types and Codes. M. Shore, C. Pignataro. May 2014. (Format: TXT=17829 bytes) (Also BCP0189) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7279) 7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry. G. Fairhurst. June 2014. (Format: TXT=14954 bytes) (Updates RFC4326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7280) 7281 Authentication-Results Registration for S/MIME Signature Verification. A. Melnikov. June 2014. (Format: TXT=23717 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7281) 7282 On Consensus and Humming in the IETF. P. Resnick. June 2014. (Format: TXT=52339 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7282) 7283 Handling Unknown DHCPv6 Messages. Y. Cui, Q. Sun, T. Lemon. July 2014. (Format: TXT=13021 bytes) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7283) 7284 The Profile URI Registry. M. Lanthaler. June 2014. (Format: TXT=8848 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7284) 7285 Application-Layer Traffic Optimization (ALTO) Protocol. R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy. September 2014. (Format: TXT=194499 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7285) 7286 Application-Layer Traffic Optimization (ALTO) Server Discovery. S. Kiesel, M. Stiemerling, N. Schwan, M. Scharf, H. Song. November 2014. (Format: TXT=32830 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7286) 7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains. T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch. June 2014. (Format: TXT=66766 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7287) 7288 Reflections on Host Firewalls. D. Thaler. June 2014. (Format: TXT=28885 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7288) 7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs. V. Kuarsingh, Ed., J. Cianfarani. June 2014. (Format: TXT=45731 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7289) 7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track. L. Ciavattone, R. Geib, A. Morton, M. Wieser. July 2014. (Format: TXT=59898 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7290) 7291 DHCP Options for the Port Control Protocol (PCP). M. Boucadair, R. Penno, D. Wing. July 2014. (Format: TXT=20868 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7291) 7292 PKCS #12: Personal Information Exchange Syntax v1.1. K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott. July 2014. (Format: TXT=58991 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7292) 7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension. W. Mills, M. Kucherawy. July 2014. (Format: TXT=54440 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7293) 7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications. A. Clark, G. Zorn, C. Bi, Q. Wu. July 2014. (Format: TXT=43611 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7294) 7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication. H. Tschofenig, L. Eggert, Z. Sarker. July 2014. (Format: TXT=59655 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7295) 7296 Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen. October 2014. (Format: TXT=354358 bytes) (Obsoletes RFC5996) (Updated by RFC7427, RFC7670) (Also STD0079) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7296) 7297 IP Connectivity Provisioning Profile (CPP). M. Boucadair, C. Jacquenet, N. Wang. July 2014. (Format: TXT=48281 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7297) 7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication. D. Ovsienko. July 2014. (Format: TXT=128503 bytes) (Updates RFC6126) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7298) 7299 Object Identifier Registry for the PKIX Working Group. R. Housley. July 2014. (Format: TXT=65861 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7299) 7300 Reservation of Last Autonomous System (AS) Numbers. J. Haas, J. Mitchell. July 2014. (Format: TXT=7952 bytes) (Updates RFC1930) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7300) 7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. S. Friedl, A. Popov, A. Langley, E. Stephan. July 2014. (Format: TXT=17439 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7301) 7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. July 2014. (Format: TXT=14419 bytes) (Obsoleted by RFC7972) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7302) 7303 XML Media Types. H. Thompson, C. Lilley. July 2014. (Format: TXT=77654 bytes) (Obsoletes RFC3023) (Updates RFC6839) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7303) 7304 A Method for Mitigating Namespace Collisions. W. Kumari. July 2014. (Format: TXT=6626 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7304) 7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT). E. Lear, Ed.. July 2014. (Format: TXT=37799 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7305) 7306 Remote Direct Memory Access (RDMA) Protocol Extensions. H. Shah, F. Marti, W. Noureddine, A. Eiriksson, R. Sharp. June 2014. (Format: TXT=73986 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7306) 7307 LDP Extensions for Multi-Topology. Q. Zhao, K. Raza, C. Zhou, L. Fang, L. Li, D. King. July 2014. (Format: TXT=39530 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7307) 7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE). E. Osborne. July 2014. (Format: TXT=14811 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7308) 7309 Redundancy Mechanism for Inter-domain VPLS Service. Z. Liu, L. Jin, R. Chen, D. Cai, S. Salam. July 2014. (Format: TXT=24644 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7309) 7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs. J. Lindsay, H. Foerster. July 2014. (Format: TXT=32743 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7310) 7311 The Accumulated IGP Metric Attribute for BGP. P. Mohapatra, R. Fernando, E. Rosen, J. Uttaro. August 2014. (Format: TXT=32615 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7311) 7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM). J. Fabini, A. Morton. August 2014. (Format: TXT=41125 bytes) (Updates RFC2330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7312) 7313 Enhanced Route Refresh Capability for BGP-4. K. Patel, E. Chen, B. Venkatachalapathy. July 2014. (Format: TXT=15111 bytes) (Updates RFC2918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7313) 7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option. M. Andrews. July 2014. (Format: TXT=8473 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7314) 7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP. R. Jesske, K. Drage, C. Holmberg. July 2014. (Format: TXT=101144 bytes) (Obsoletes RFC3455) (Updated by RFC7913, RFC7976) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7315) 7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header). J. van Elburg, K. Drage, M. Ohsugi, S. Schubert, K. Arai. July 2014. (Format: TXT=33599 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7316) 7317 A YANG Data Model for System Management. A. Bierman, M. Bjorklund. August 2014. (Format: TXT=60119 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7317) 7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates. A. Newton, G. Huston. July 2014. (Format: TXT=8214 bytes) (Updates RFC6487) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7318) 7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points. D. Eastlake 3rd. July 2014. (Format: TXT=7759 bytes) (Also BCP0191) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7319) 7320 URI Design and Ownership. M. Nottingham. July 2014. (Format: TXT=18275 bytes) (Updates RFC3986) (Also BCP0190) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7320) 7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH). D. McGrew, P. Hoffman. August 2014. (Format: TXT=25724 bytes) (Obsoletes RFC4835) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7321) 7322 RFC Style Guide. H. Flanagan, S. Ginoza. September 2014. (Format: TXT=49915 bytes) (Obsoletes RFC2223) (Updated by RFC7997) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7322) 7323 TCP Extensions for High Performance. D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed.. September 2014. (Format: TXT=106013 bytes) (Obsoletes RFC1323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7323) 7324 Updates to MPLS Transport Profile Linear Protection. E. Osborne. July 2014. (Format: TXT=23687 bytes) (Updates RFC6378) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7324) 7325 MPLS Forwarding Compliance and Performance Requirements. C. Villamizar, Ed., K. Kompella, S. Amante, A. Malis, C. Pignataro. August 2014. (Format: TXT=139536 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7325) 7326 Energy Management Framework. J. Parello, B. Claise, B. Schoening, J. Quittek. September 2014. (Format: TXT=107145 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7326) 7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML. R. Gieben. August 2014. (Format: TXT=17590 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7328) 7329 A Session Identifier for the Session Initiation Protocol (SIP). H. Kaplan. August 2014. (Format: TXT=39057 bytes) (Obsoleted by RFC7989) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7329) 7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management. T. Nadeau, Z. Ali, N. Akiya. August 2014. (Format: TXT=20910 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7330) 7331 Bidirectional Forwarding Detection (BFD) Management Information Base. T. Nadeau, Z. Ali, N. Akiya. August 2014. (Format: TXT=72272 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7331) 7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs). H. Kaplan, V. Pascual. August 2014. (Format: TXT=11157 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7332) 7333 Requirements for Distributed Mobility Management. H. Chan, Ed., D. Liu, P. Seite, H. Yokota, J. Korhonen. August 2014. (Format: TXT=50110 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7333) 7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths. Q. Zhao, D. Dhody, D. King, Z. Ali, R. Casellas. August 2014. (Format: TXT=48897 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7334) 7335 IPv4 Service Continuity Prefix. C. Byrne. August 2014. (Format: TXT=7763 bytes) (Updates RFC6333) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7335) 7336 Framework for Content Distribution Network Interconnection (CDNI). L. Peterson, B. Davie, R. van Brandenburg, Ed.. August 2014. (Format: TXT=145294 bytes) (Obsoletes RFC3466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7336) 7337 Content Distribution Network Interconnection (CDNI) Requirements. K. Leung, Ed., Y. Lee, Ed.. August 2014. (Format: TXT=55208 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7337) 7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks. F. Jounay, Ed., Y. Kamite, Ed., G. Heron, M. Bocci. September 2014. (Format: TXT=36120 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7338) 7339 Session Initiation Protocol (SIP) Overload Control. V. Gurbani, Ed., V. Hilt, H. Schulzrinne. September 2014. (Format: TXT=89898 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7339) 7340 Secure Telephone Identity Problem Statement and Requirements. J. Peterson, H. Schulzrinne, H. Tschofenig. September 2014. (Format: TXT=65026 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7340) 7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport. Q. Sun, Y. Cui, M. Siodelski, S. Krishnan, I. Farrer. August 2014. (Format: TXT=35599 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7341) 7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers. L. Dunbar, W. Kumari, I. Gashinsky. August 2014. (Format: TXT=28413 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7342) 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2). J. Laganier, F. Dupont. September 2014. (Format: TXT=28699 bytes) (Obsoletes RFC4843) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7343) 7344 Automating DNSSEC Delegation Trust Maintenance. W. Kumari, O. Gudmundsson, G. Barwood. September 2014. (Format: TXT=39434 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7344) 7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS). C. Holmberg, I. Sedlacek, G. Salgueiro. August 2014. (Format: TXT=42943 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7345) 7346 IPv6 Multicast Address Scopes. R. Droms. August 2014. (Format: TXT=10831 bytes) (Updates RFC4007, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7346) 7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP). H. van Helvoort, Ed., J. Ryoo, Ed., H. Zhang, F. Huang, H. Li, A. D'Alessandro. September 2014. (Format: TXT=70158, PDF=394963 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7347) 7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks. M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright. August 2014. (Format: TXT=49406 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7348) 7349 LDP Hello Cryptographic Authentication. L. Zheng, M. Chen, M. Bhatia. August 2014. (Format: TXT=32447 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7349) 7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN). M. Petit-Huguenin, G. Salgueiro. August 2014. (Format: TXT=27599 bytes) (Updates RFC5389, RFC5928) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7350) 7351 A Media Type for XML Patch Operations. E. Wilde. August 2014. (Format: TXT=27784 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7351) 7352 Sieve Email Filtering: Detecting Duplicate Deliveries. S. Bosch. September 2014. (Format: TXT=31191 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7352) 7353 Security Requirements for BGP Path Validation. S. Bellovin, R. Bush, D. Ward. August 2014. (Format: TXT=18148 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7353) 7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace. A. Adolf, P. Siebert. September 2014. (Format: TXT=5052 bytes) (Updates RFC5328) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7354) 7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF). G. Salgueiro, V. Pascual, A. Roman, S. Garcia. September 2014. (Format: TXT=16180 bytes) (Updates RFC6873) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7355) 7356 IS-IS Flooding Scope Link State PDUs (LSPs). L. Ginsberg, S. Previdi, Y. Yang. September 2014. (Format: TXT=46089 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7356) 7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol. H. Zhai, F. Hu, R. Perlman, D. Eastlake 3rd, O. Stokes. September 2014. (Format: TXT=72379 bytes) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7357) 7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs). K. Raza, S. Boutros, L. Martini, N. Leymann. October 2014. (Format: TXT=15582 bytes) (Updates RFC3212, RFC4447, RFC5036, RFC5918, RFC6388, RFC7140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7358) 7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks. F. Gont. August 2014. (Format: TXT=26506 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7359) 7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS. A. DeKok. September 2014. (Format: TXT=60007 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7360) 7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS). P. Dutta, F. Balus, O. Stokes, G. Calvignac, D. Fedyk. September 2014. (Format: TXT=62854 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7361) 7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication. E. Ivov, H. Kaplan, D. Wing. September 2014. (Format: TXT=39139 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7362) 7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD). J. Maenpaa, G. Camarillo. September 2014. (Format: TXT=54308 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7363) 7364 Problem Statement: Overlays for Network Virtualization. T. Narten, Ed., E. Gray, Ed., D. Black, L. Fang, L. Kreeger, M. Napierala. October 2014. (Format: TXT=57831 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7364) 7365 Framework for Data Center (DC) Network Virtualization. M. Lasserre, F. Balus, T. Morin, N. Bitar, Y. Rekhter. October 2014. (Format: TXT=57811 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7365) 7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). P. Gutmann. September 2014. (Format: TXT=15775 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7366) 7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process. R. Cole, J. Macker, B. Adamson. October 2014. (Format: TXT=135588 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7367) 7368 IPv6 Home Networking Architecture Principles. T. Chown, Ed., J. Arkko, A. Brandt, O. Troan, J. Weil. October 2014. (Format: TXT=125402 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7368) 7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration. A. Takacs, B. Gero, H. Long. October 2014. (Format: TXT=38843 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7369) 7370 Updates to the IS-IS TLV Codepoints Registry. L. Ginsberg. September 2014. (Format: TXT=12318 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7370) 7371 Updates to the IPv6 Multicast Addressing Architecture. M. Boucadair, S. Venaas. September 2014. (Format: TXT=18327 bytes) (Updates RFC3306, RFC3956, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7371) 7372 Email Authentication Status Codes. M. Kucherawy. September 2014. (Format: TXT=14224 bytes) (Updates RFC7208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7372) 7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types. B. Trammell. September 2014. (Format: TXT=29054 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7373) 7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD). J. Maenpaa, G. Camarillo. October 2014. (Format: TXT=45569 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7374) 7375 Secure Telephone Identity Threat Model. J. Peterson. October 2014. (Format: TXT=31067 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7375) 7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN). T. Reddy, R. Ravindranath, M. Perumal, A. Yegin. September 2014. (Format: TXT=16447 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7376) 7377 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. October 2014. (Format: TXT=24711 bytes) (Obsoletes RFC6237) (Updates RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7377) 7378 Trustworthy Location. H. Tschofenig, H. Schulzrinne, B. Aboba, Ed.. December 2014. (Format: TXT=75402 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7378) 7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge. Y. Li, W. Hao, R. Perlman, J. Hudson, H. Zhai. October 2014. (Format: TXT=26764 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7379) 7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting. J. Tong, C. Bi, Ed., R. Even, Q. Wu, Ed., R. Huang. November 2014. (Format: TXT=22440 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7380) 7381 Enterprise IPv6 Deployment Guidelines. K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke. October 2014. (Format: TXT=90299 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7381) 7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI). S. Kent, D. Kong, K. Seo. April 2015. (Format: TXT=82372 bytes) (Also BCP0173) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7382) 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation. V. Smyslov. November 2014. (Format: TXT=47354 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7383) 7384 Security Requirements of Time Protocols in Packet Switched Networks. T. Mizrahi. October 2014. (Format: TXT=78942 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7384) 7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points. L. Andersson, G. Swallow. October 2014. (Format: TXT=6690 bytes) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7385) 7386 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT=12930 bytes) (Obsoleted by RFC7396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7386) 7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network. R. Key, Ed., L. Yong, Ed., S. Delord, F. Jounay, L. Jin. October 2014. (Format: TXT=28205 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7387) 7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). J. Schoenwaelder, A. Sehgal, T. Tsou, C. Zhou. October 2014. (Format: TXT=53451 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7388) 7389 Separation of Control and User Plane for Proxy Mobile IPv6. R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins. October 2014. (Format: TXT=26217 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7389) 7390 Group Communication for the Constrained Application Protocol (CoAP). A. Rahman, Ed., E. Dijk, Ed.. October 2014. (Format: TXT=106675 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7390) 7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions. J. Hadi Salim. October 2014. (Format: TXT=49481 bytes) (Updates RFC5810, RFC7121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7391) 7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires. P. Dutta, M. Bocci, L. Martini. December 2014. (Format: TXT=20846 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7392) 7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS. X. Deng, M. Boucadair, Q. Zhao, J. Huang, C. Zhou. November 2014. (Format: TXT=30130 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7393) 7394 Definition of Time to Live TLV for LSP-Ping Mechanisms. S. Boutros, S. Sivabalan, G. Swallow, S. Saxena, V. Manral, S. Aldrin. November 2014. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7394) 7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket. L. Stout, Ed., J. Moffitt, E. Cestari. October 2014. (Format: TXT=36795 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7395) 7396 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT=12791 bytes) (Obsoletes RFC7386) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7396) 7397 Report from the Smart Object Security Workshop. J. Gilger, H. Tschofenig. December 2014. (Format: TXT=51259 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7397) 7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance. M. Bagnulo, T. Burbridge, S. Crawford, P. Eardley, A. Morton. February 2015. (Format: TXT=36938 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7398) 7399 Unanswered Questions in the Path Computation Element Architecture. A. Farrel, D. King. October 2014. (Format: TXT=70588 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7399) 7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). C. Bormann. November 2014. (Format: TXT=47533 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7400) 7401 Host Identity Protocol Version 2 (HIPv2). R. Moskowitz, Ed., T. Heer, P. Jokela, T. Henderson. April 2015. (Format: TXT=309319 bytes) (Obsoletes RFC5201) (Updated by RFC8002) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7401) 7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, J. Melen. April 2015. (Format: TXT=88644 bytes) (Obsoletes RFC5202) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7402) 7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP). H. Kaplan. November 2014. (Format: TXT=15108 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7403) 7404 Using Only Link-Local Addressing inside an IPv6 Network. M. Behringer, E. Vyncke. November 2014. (Format: TXT=24444 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7404) 7405 Case-Sensitive String Support in ABNF. P. Kyzivat. December 2014. (Format: TXT=6668 bytes) (Updates RFC5234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7405) 7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices. H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg. December 2014. (Format: TXT=52779 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7406) 7407 A YANG Data Model for SNMP Configuration. M. Bjorklund, J. Schoenwaelder. December 2014. (Format: TXT=155373 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7407) 7408 Forwarding and Control Element Separation (ForCES) Model Extension. E. Haleplidis. November 2014. (Format: TXT=62348 bytes) (Updates RFC5812) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7408) 7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization. E. Haleplidis, J. Halpern. November 2014. (Format: TXT=53906 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7409) 7410 A Property Types Registry for the Authentication-Results Header Field. M. Kucherawy. December 2014. (Format: TXT=9957 bytes) (Obsoleted by RFC7601) (Updates RFC7001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7410) 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers. T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu. November 2014. (Format: TXT=72298 bytes) (Updates RFC5568) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7411) 7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection. Y. Weingarten, S. Aldrin, P. Pan, J. Ryoo, G. Mirsky. December 2014. (Format: TXT=34117 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7412) 7413 TCP Fast Open. Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain. December 2014. (Format: TXT=59945 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7413) 7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents. M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann. February 2015. (Format: TXT=130622 bytes) (Obsoletes RFC4614) (Updated by RFC7805) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7414) 7415 Session Initiation Protocol (SIP) Rate Control. E. Noel, P. Williams. February 2015. (Format: TXT=30456 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7415) 7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, M. Richardson, Ed.. January 2015. (Format: TXT=94452 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7416) 7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains. G. Karagiannis, A. Bhargava. December 2014. (Format: TXT=79227 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7417) 7418 An IRTF Primer for IETF Participants. S. Dawkins, Ed.. December 2014. (Format: TXT=14467 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7418) 7419 Common Interval Support in Bidirectional Forwarding Detection. N. Akiya, M. Binderberger, G. Mirsky. December 2014. (Format: TXT=16944 bytes) (Updates RFC5880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7419) 7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module. A. Koushik, E. Stephan, Q. Zhao, D. King, J. Hardwick. December 2014. (Format: TXT=130964 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7420) 7421 Analysis of the 64-bit Boundary in IPv6 Addressing. B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko. January 2015. (Format: TXT=60469 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7421) 7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments. C. Donley, C. Grundemann, V. Sarawat, K. Sundaresan, O. Vautrin. December 2014. (Format: TXT=33575 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7422) 7423 Diameter Applications Design Guidelines. L. Morand, Ed., V. Fajardo, H. Tschofenig. November 2014. (Format: TXT=67829 bytes) (Also BCP0193) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7423) 7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks. R. Krishnan, L. Yong, A. Ghanwani, N. So, B. Khasnabish. January 2015. (Format: TXT=60733 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7424) 7425 Adobe's RTMFP Profile for Flash Communication. M. Thornburgh. December 2014. (Format: TXT=103979 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7425) 7426 Software-Defined Networking (SDN): Layers and Architecture Terminology. E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, O. Koufopavlou. January 2015. (Format: TXT=85111 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7426) 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2). T. Kivinen, J. Snyder. January 2015. (Format: TXT=39041 bytes) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7427) 7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks. A. Brandt, J. Buron. February 2015. (Format: TXT=42657 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7428) 7429 Distributed Mobility Management: Current Practices and Gap Analysis. D. Liu, Ed., JC. Zuniga, Ed., P. Seite, H. Chan, CJ. Bernardos. January 2015. (Format: TXT=80973 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7429) 7430 Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP). M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu. July 2015. (Format: TXT=41877 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7430) 7431 Multicast-Only Fast Reroute. A. Karan, C. Filsfils, IJ. Wijnands, Ed., B. Decraene. August 2015. (Format: TXT=28906 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7431) 7432 BGP MPLS-Based Ethernet VPN. A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx. February 2015. (Format: TXT=134119 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7432) 7433 A Mechanism for Transporting User-to-User Call Control Information in SIP. A. Johnston, J. Rafferty. January 2015. (Format: TXT=45687 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7433) 7434 Interworking ISDN Call Control User Information with SIP. K. Drage, Ed., A. Johnston. January 2015. (Format: TXT=39276 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7434) 7435 Opportunistic Security: Some Protection Most of the Time. V. Dukhovni. December 2014. (Format: TXT=27451 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7435) 7436 IP-Only LAN Service (IPLS). H. Shah, E. Rosen, F. Le Faucheur, G. Heron. January 2015. (Format: TXT=74340 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC7436) 7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. M. Kucherawy, Ed.. January 2015. (Format: TXT=77786 bytes) (Obsoletes RFC3777, RFC5078, RFC5633, RFC5680, RFC6859) (Updated by RFC7776) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7437) 7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards. IJ. Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura. January 2015. (Format: TXT=36744 bytes) (Updates RFC6826, RFC7246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7438) 7439 Gap Analysis for Operating IPv6-Only MPLS Networks. W. George, Ed., C. Pignataro, Ed.. January 2015. (Format: TXT=64087 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7439) 7440 TFTP Windowsize Option. P. Masotta. January 2015. (Format: TXT=17710 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7440) 7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes. IJ. Wijnands, E. Rosen, U. Joorde. January 2015. (Format: TXT=22839 bytes) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7441) 7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP). Y. Rekhter, R. Aggarwal, N. Leymann, W. Henderickx, Q. Zhao, R. Li. February 2015. (Format: TXT=24020 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7442) 7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages. P. Patil, T. Reddy, G. Salgueiro, M. Petit-Huguenin. January 2015. (Format: TXT=9145 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7443) 7444 Security Labels in Internet Email. K. Zeilenga, A. Melnikov. February 2015. (Format: TXT=32183 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7444) 7445 Analysis of Failure Cases in IPv6 Roaming Scenarios. G. Chen, H. Deng, D. Michaud, J. Korhonen, M. Boucadair. March 2015. (Format: TXT=44466 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7445) 7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks. Y. Lee, Ed., G. Bernstein, Ed., D. Li, W. Imajuku. February 2015. (Format: TXT=48370 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7446) 7447 Deprecation of BGP Entropy Label Capability Attribute. J. Scudder, K. Kompella. February 2015. (Format: TXT=7486 bytes) (Updates RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7447) 7448 MIB Transfer from the IETF to the IEEE 802.3 WG. T. Taylor, Ed., D. Romascanu. February 2015. (Format: TXT=12501 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7448) 7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment. Y. Lee, Ed., G. Bernstein, Ed., J. Martensson, T. Takeda, T. Tsuritani, O. Gonzalez de Dios. February 2015. (Format: TXT=25117 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7449) 7450 Automatic Multicast Tunneling. G. Bumgardner. February 2015. (Format: TXT=188711 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7450) 7451 Extension Registry for the Extensible Provisioning Protocol. S. Hollenbeck. February 2015. (Format: TXT=20373 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7451) 7452 Architectural Considerations in Smart Object Networking. H. Tschofenig, J. Arkko, D. Thaler, D. McPherson. March 2015. (Format: TXT=53504 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7452) 7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB). V. Mahalingam, K. Sampath, S. Aldrin, T. Nadeau. February 2015. (Format: TXT=117910 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7453) 7454 BGP Operations and Security. J. Durand, I. Pepelnjak, G. Doering. February 2015. (Format: TXT=56946 bytes) (Also BCP0194) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7454) 7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management. T. Senevirathne, N. Finn, S. Salam, D. Kumar, D. Eastlake 3rd, S. Aldrin, Y. Li. March 2015. (Format: TXT=126153 bytes) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7455) 7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL). T. Mizrahi, T. Senevirathne, S. Salam, D. Kumar, D. Eastlake 3rd. March 2015. (Format: TXT=66752 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7456) 7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). Y. Sheffer, R. Holz, P. Saint-Andre. February 2015. (Format: TXT=28614 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7457) 7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core. R. Valmikam, R. Koodli. February 2015. (Format: TXT=38925 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7458) 7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO). M. Thomson, J. Winterbottom. February 2015. (Format: TXT=80144 bytes) (Updates RFC3693, RFC4119, RFC5491) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7459) 7460 Monitoring and Control MIB for Power and Energy. M. Chandramouli, B. Claise, B. Schoening, J. Quittek, T. Dietz. March 2015. (Format: TXT=148167 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7460) 7461 Energy Object Context MIB. J. Parello, B. Claise, M. Chandramouli. March 2015. (Format: TXT=67077 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7461) 7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP). L. Liess, Ed., R. Jesske, A. Johnston, D. Worley, P. Kyzivat. March 2015. (Format: TXT=97730 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7462) 7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR). A. Johnston, Ed., M. Soroushnejad, Ed., V. Venkataramanan. March 2015. (Format: TXT=171979 bytes) (Updates RFC3261, RFC4235) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7463) 7464 JavaScript Object Notation (JSON) Text Sequences. N. Williams. February 2015. (Format: TXT=16132 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7464) 7465 Prohibiting RC4 Cipher Suites. A. Popov. February 2015. (Format: TXT=8397 bytes) (Updates RFC5246, RFC4346, RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7465) 7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP). C. Dearlove, T. Clausen. March 2015. (Format: TXT=17949 bytes) (Updates RFC6130, RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7466) 7467 URN Namespace for the North Atlantic Treaty Organization (NATO). A. Murdock. April 2015. (Format: TXT=16675 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7467) 7468 Textual Encodings of PKIX, PKCS, and CMS Structures. S. Josefsson, S. Leonard. April 2015. (Format: TXT=41594 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7468) 7469 Public Key Pinning Extension for HTTP. C. Evans, C. Palmer, R. Sleevi. April 2015. (Format: TXT=61619 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7469) 7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol. F. Zhang, A. Farrel. March 2015. (Format: TXT=28647 bytes) (Obsoletes RFC7150) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7470) 7471 OSPF Traffic Engineering (TE) Metric Extensions. S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi. March 2015. (Format: TXT=38803 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7471) 7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme. I. McDonald, M. Sweet. March 2015. (Format: TXT=37666 bytes) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7472) 7473 Controlling State Advertisements of Non-negotiated LDP Applications. K. Raza, S. Boutros. March 2015. (Format: TXT=36189 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7473) 7474 Security Extension for OSPFv2 When Using Manual Key Management. M. Bhatia, S. Hartman, D. Zhang, A. Lindem, Ed.. April 2015. (Format: TXT=31832 bytes) (Updates RFC2328, RFC5709) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7474) 7475 Increasing the Number of Area Directors in an IETF Area. S. Dawkins. March 2015. (Format: TXT=9350 bytes) (Updates RFC2026, RFC2418) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7475) 7476 Information-Centric Networking: Baseline Scenarios. K. Pentikousis, Ed., B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, S. Eum. March 2015. (Format: TXT=120235 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7476) 7477 Child-to-Parent Synchronization in DNS. W. Hardaker. March 2015. (Format: TXT=34471 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7477) 7478 Web Real-Time Communication Use Cases and Requirements. C. Holmberg, S. Hakansson, G. Eriksson. March 2015. (Format: TXT=64824 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7478) 7479 Using Ed25519 in SSHFP Resource Records. S. Moonesamy. March 2015. (Format: TXT=6440 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7479) 7480 HTTP Usage in the Registration Data Access Protocol (RDAP). A. Newton, B. Ellacott, N. Kong. March 2015. (Format: TXT=34671 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7480) 7481 Security Services for the Registration Data Access Protocol (RDAP). S. Hollenbeck, N. Kong. March 2015. (Format: TXT=29954 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7481) 7482 Registration Data Access Protocol (RDAP) Query Format. A. Newton, S. Hollenbeck. March 2015. (Format: TXT=43429 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7482) 7483 JSON Responses for the Registration Data Access Protocol (RDAP). A. Newton, S. Hollenbeck. March 2015. (Format: TXT=125362 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7483) 7484 Finding the Authoritative Registration Data (RDAP) Service. M. Blanchet. March 2015. (Format: TXT=33947 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7484) 7485 Inventory and Analysis of WHOIS Registration Objects. L. Zhou, N. Kong, S. Shen, S. Sheng, A. Servin. March 2015. (Format: TXT=74392 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7485) 7486 HTTP Origin-Bound Authentication (HOBA). S. Farrell, P. Hoffman, M. Thomas. March 2015. (Format: TXT=64868 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7486) 7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE. E. Bellagamba, A. Takacs, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward. March 2015. (Format: TXT=67217 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7487) 7488 Port Control Protocol (PCP) Server Selection. M. Boucadair, R. Penno, D. Wing, P. Patil, T. Reddy. March 2015. (Format: TXT=22577 bytes) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7488) 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC). M. Kucherawy, Ed., E. Zwicky, Ed.. March 2015. (Format: TXT=162707 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7489) 7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR). S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So. April 2015. (Format: TXT=66207 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7490) 7491 A PCE-Based Architecture for Application-Based Network Operations. D. King, A. Farrel. March 2015. (Format: TXT=163636 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7491) 7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines. M. Bhatia, D. Zhang, M. Jethanandani. March 2015. (Format: TXT=21689 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7492) 7493 The I-JSON Message Format. T. Bray, Ed.. March 2015. (Format: TXT=12849 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7493) 7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP). C. Shao, H. Deng, R. Pazhyannur, F. Bari, R. Zhang, S. Matsushima. April 2015. (Format: TXT=23378 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7494) 7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF). A. Montville, D. Black. March 2015. (Format: TXT=19891 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7495) 7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension. M. Tuexen, R. Seggelmann, R. Stewart, S. Loreto. April 2015. (Format: TXT=21272 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7496) 7497 Rate Measurement Test Protocol Problem Statement and Requirements. A. Morton. April 2015. (Format: TXT=31281 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7497) 7498 Problem Statement for Service Function Chaining. P. Quinn, Ed., T. Nadeau, Ed.. April 2015. (Format: TXT=28970 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7498) 7499 Support of Fragmentation of RADIUS Packets. A. Perez-Mendez, Ed., R. Marin-Lopez, F. Pereniguez-Garcia, G. Lopez-Millan, D. Lopez, A. DeKok. April 2015. (Format: TXT=83448 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7499) 7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries. R. Housley, Ed., O. Kolkman, Ed.. April 2015. (Format: TXT=15720 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7500) 7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration. C. Davids, V. Gurbani, S. Poretsky. April 2015. (Format: TXT=36573 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7501) 7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration. C. Davids, V. Gurbani, S. Poretsky. April 2015. (Format: TXT=41281 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7502) 7503 OSPFv3 Autoconfiguration. A. Lindem, J. Arkko. April 2015. (Format: TXT=33521 bytes) (Updates RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7503) 7504 SMTP 521 and 556 Reply Codes. J. Klensin. June 2015. (Format: TXT=13936 bytes) (Updates RFC1846, RFC5321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7504) 7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail. J. Levine, M. Delany. June 2015. (Format: TXT=12534 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7505) 7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM). K. Raza, N. Akiya, C. Pignataro. April 2015. (Format: TXT=11322 bytes) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7506) 7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. B. Moeller, A. Langley. April 2015. (Format: TXT=17165 bytes) (Updates RFC2246, RFC4346, RFC4347, RFC5246, RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7507) 7508 Securing Header Fields with S/MIME. L. Cailleux, C. Bonatti. April 2015. (Format: TXT=39853 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7508) 7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics. R. Huang, V. Singh. May 2015. (Format: TXT=23350 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7509) 7510 Encapsulating MPLS in UDP. X. Xu, N. Sheth, L. Yong, R. Callon, D. Black. April 2015. (Format: TXT=43208 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7510) 7511 Scenic Routing for IPv6. M. Wilhelm. April 2015. (Format: TXT=14715 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7511) 7512 The PKCS #11 URI Scheme. J. Pechanec, D. Moffat. April 2015. (Format: TXT=48759 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7512) 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J. Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=123735 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) 7514 Really Explicit Congestion Notification (RECN). M. Luckie. April 2015. (Format: TXT=9776 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7514) 7515 JSON Web Signature (JWS). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT=131110 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7515) 7516 JSON Web Encryption (JWE). M. Jones, J. Hildebrand. May 2015. (Format: TXT=108322 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7516) 7517 JSON Web Key (JWK). M. Jones. May 2015. (Format: TXT=93906 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7517) 7518 JSON Web Algorithms (JWA). M. Jones. May 2015. (Format: TXT=155905 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7518) 7519 JSON Web Token (JWT). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT=63039 bytes) (Updated by RFC7797) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7519) 7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE). M. Miller. May 2015. (Format: TXT=198174 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7520) 7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants. B. Campbell, C. Mortimore, M. Jones, Y. Goland. May 2015. (Format: TXT=44458 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7521) 7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants. B. Campbell, C. Mortimore, M. Jones. May 2015. (Format: TXT=33890 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7522) 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. M. Jones, B. Campbell, C. Mortimore. May 2015. (Format: TXT=26459 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7523) 7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs). Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad. May 2015. (Format: TXT=105804 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7524) 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Y. Sheffer, R. Holz, P. Saint-Andre. May 2015. (Format: TXT=60283 bytes) (Also BCP0195) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7525) 7526 Deprecating the Anycast Prefix for 6to4 Relay Routers. O. Troan, B. Carpenter, Ed.. May 2015. (Format: TXT=20894 bytes) (Obsoletes RFC3068, RFC6732) (Also BCP0196) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7526) 7527 Enhanced Duplicate Address Detection. R. Asati, H. Singh, W. Beebee, C. Pignataro, E. Dart, W. George. April 2015. (Format: TXT=24528 bytes) (Updates RFC4429, RFC4861, RFC4862) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7527) 7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association. P. Higgs, J. Piesing. April 2015. (Format: TXT=12921 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7528) 7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar). C. Daboo, G. Yakushev. May 2015. (Format: TXT=43124 bytes) (Updates RFC5545, RFC6321, RFC7265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7529) 7530 Network File System (NFS) Version 4 Protocol. T. Haynes, Ed., D. Noveck, Ed.. March 2015. (Format: TXT=724613 bytes) (Obsoletes RFC3530) (Updated by RFC7931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7530) 7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description. T. Haynes, Ed., D. Noveck, Ed.. March 2015. (Format: TXT=67541 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7531) 7532 Namespace Database (NSDB) Protocol for Federated File Systems. J. Lentini, R. Tewari, C. Lever, Ed.. March 2015. (Format: TXT=127373 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7532) 7533 Administration Protocol for Federated File Systems. J. Lentini, R. Tewari, C. Lever, Ed.. March 2015. (Format: TXT=76429 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7533) 7534 AS112 Nameserver Operations. J. Abley, W. Sotomayor. May 2015. (Format: TXT=47269 bytes) (Obsoletes RFC6304) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7534) 7535 AS112 Redirection Using DNAME. J. Abley, B. Dickson, W. Kumari, G. Michaelson. May 2015. (Format: TXT=31730 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7535) 7536 Large-Scale Broadband Measurement Use Cases. M. Linsner, P. Eardley, T. Burbridge, F. Sorensen. May 2015. (Format: TXT=41039 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7536) 7537 IANA Registries for LSP Ping Code Points. B. Decraene, N. Akiya, C. Pignataro, L. Andersson, S. Aldrin. May 2015. (Format: TXT=11895 bytes) (Updates RFC4379, RFC6424) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7537) 7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. (Format: TXT=11189 bytes) (Obsoletes RFC7238) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7538) 7539 ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley. May 2015. (Format: TXT=88173 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7539) 7540 Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe, R. Peon, M. Thomson, Ed.. May 2015. (Format: TXT=209580 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7540) 7541 HPACK: Header Compression for HTTP/2. R. Peon, H. Ruellan. May 2015. (Format: TXT=117827 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7541) 7542 The Network Access Identifier. A. DeKok. May 2015. (Format: TXT=66596 bytes) (Obsoletes RFC4282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7542) 7543 Covering Prefixes Outbound Route Filter for BGP-4. H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong. May 2015. (Format: TXT=38583 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7543) 7544 Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP). M. Mohali. August 2015. (Format: TXT=68612 bytes) (Obsoletes RFC6044) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7544) 7545 Protocol to Access White-Space (PAWS) Databases. V. Chen, Ed., S. Das, L. Zhu, J. Malyar, P. McCann. May 2015. (Format: TXT=188634 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7545) 7546 Structure of the Generic Security Service (GSS) Negotiation Loop. B. Kaduk. May 2015. (Format: TXT=50075 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7546) 7547 Management of Networks with Constrained Devices: Problem Statement and Requirements. M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, U. Herberg. May 2015. (Format: TXT=87357 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7547) 7548 Management of Networks with Constrained Devices: Use Cases. M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, A. Sehgal. May 2015. (Format: TXT=71103 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7548) 7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter. C. Holmberg, J. Holm, R. Jesske, M. Dolly. May 2015. (Format: TXT=32607 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7549) 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options. O. Troan, B. Volz, M. Siodelski. May 2015. (Format: TXT=54206 bytes) (Updates RFC3315, RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7550) 7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs). F. Zhang, Ed., R. Jing, R. Gandhi, Ed.. May 2015. (Format: TXT=43752 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7551) 7552 Updates to LDP for IPv6. R. Asati, C. Pignataro, K. Raza, V. Manral, R. Papneja. June 2015. (Format: TXT=48801 bytes) (Updates RFC5036, RFC6720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7552) 7553 The Uniform Resource Identifier (URI) DNS Resource Record. P. Faltstrom, O. Kolkman. June 2015. (Format: TXT=28278 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7553) 7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement. T. Watteyne, Ed., M. Palattella, L. Grieco. May 2015. (Format: TXT=50706 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7554) 7555 Proxy MPLS Echo Request. G. Swallow, V. Lim, S. Aldrin. June 2015. (Format: TXT=62109 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7555) 7556 Multiple Provisioning Domain Architecture. D. Anipko, Ed.. June 2015. (Format: TXT=59307 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7556) 7557 Extension Mechanism for the Babel Routing Protocol. J. Chroboczek. May 2015. (Format: TXT=22626 bytes) (Updates RFC6126) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7557) 7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions. K. Lynn, S. Cheshire, M. Blanchet, D. Migault. July 2015. (Format: TXT=30291 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7558) 7559 Packet-Loss Resiliency for Router Solicitations. S. Krishnan, D. Anipko, D. Thaler. May 2015. (Format: TXT=11619 bytes) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7559) 7560 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback. M. Kuehlewind, Ed., R. Scheffenegger, B. Briscoe. August 2015. (Format: TXT=40528 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7560) 7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN. J. Kaippallimalil, R. Pazhyannur, P. Yegani. June 2015. (Format: TXT=50348 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7561) 7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates. D. Thakore. July 2015. (Format: TXT=32576 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7562) 7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option. R. Pazhyannur, S. Speicher, S. Gundavelli, J. Korhonen, J. Kaippallimalil. June 2015. (Format: TXT=27982 bytes) (Updates RFC6757) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7563) 7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols. P. Saint-Andre, M. Blanchet. May 2015. (Format: TXT=93580 bytes) (Obsoletes RFC3454) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7564) 7565 The 'acct' URI Scheme. P. Saint-Andre. May 2015. (Format: TXT=18244 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7565) 7566 Enumservice Registration for 'acct' URI. L. Goix, K. Li. June 2015. (Format: TXT=16874 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7566) 7567 IETF Recommendations Regarding Active Queue Management. F. Baker, Ed., G. Fairhurst, Ed.. July 2015. (Format: TXT=76832 bytes) (Obsoletes RFC2309) (Also BCP0197) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7567) 7568 Deprecating Secure Sockets Layer Version 3.0. R. Barnes, M. Thomson, A. Pironti, A. Langley. June 2015. (Format: TXT=13489 bytes) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7568) 7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats. D. Quigley, J. Lu, T. Haynes. July 2015. (Format: TXT=22406 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7569) 7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO). C. Margaria, Ed., G. Martinelli, S. Balls, B. Wright. July 2015. (Format: TXT=34223 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7570) 7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback. J. Dong, M. Chen, Z. Li, D. Ceccarelli. July 2015. (Format: TXT=19767 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7571) 7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging. P. Saint-Andre, A. Houri, J. Hildebrand. June 2015. (Format: TXT=29027 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7572) 7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions. P. Saint-Andre, S. Loreto. June 2015. (Format: TXT=42607 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7573) 7574 Peer-to-Peer Streaming Peer Protocol (PPSPP). A. Bakker, R. Petrocco, V. Grishchenko. July 2015. (Format: TXT=208360 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7574) 7575 Autonomic Networking: Definitions and Design Goals. M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, L. Ciavaglia. June 2015. (Format: TXT=36838 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7575) 7576 General Gap Analysis for Autonomic Networking. S. Jiang, B. Carpenter, M. Behringer. June 2015. (Format: TXT=42472 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7576) 7577 Definition of Managed Objects for Battery Monitoring. J. Quittek, R. Winter, T. Dietz. July 2015. (Format: TXT=86505 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7577) 7578 Returning Values from Forms: multipart/form-data. L. Masinter. July 2015. (Format: TXT=30240 bytes) (Obsoletes RFC2388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7578) 7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks. G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. June 2015. (Format: TXT=62347 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7579) 7580 OSPF-TE Extensions for General Network Element Constraints. F. Zhang, Y. Lee, J. Han, G. Bernstein, Y. Xu. June 2015. (Format: TXT=25189 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7580) 7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks. G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. June 2015. (Format: TXT=72511 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7581) 7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels. E. Rosen, IJ. Wijnands, Y. Cai, A. Boers. July 2015. (Format: TXT=79244 bytes) (Updates RFC6513, RFC6514, RFC6625) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7582) 7583 DNSSEC Key Rollover Timing Considerations. S. Morris, J. Ihren, J. Dickinson, W. Mekking. October 2015. (Format: TXT=66442 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7583) 7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs). R. Ravindranath, T. Reddy, G. Salgueiro. July 2015. (Format: TXT=32675 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7584) 7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI). S. Winter, M. McCauley. October 2015. (Format: TXT=70699 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7585) 7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers. Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi. June 2015. (Format: TXT=44538 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7586) 7587 RTP Payload Format for the Opus Speech and Audio Codec. J. Spittka, K. Vos, JM. Valin. June 2015. (Format: TXT=41770 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7587) 7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem. R. Bonica, C. Pignataro, J. Touch. July 2015. (Format: TXT=24453 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7588) 7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication. M. Badra, A. Luchuk, J. Schoenwaelder. June 2015. (Format: TXT=22727 bytes) (Obsoletes RFC5539) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7589) 7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, T. Alkemade. June 2015. (Format: TXT=20393 bytes) (Updates RFC6120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7590) 7591 OAuth 2.0 Dynamic Client Registration Protocol. J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt. July 2015. (Format: TXT=87811 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7591) 7592 OAuth 2.0 Dynamic Client Registration Management Protocol. J. Richer, Ed., M. Jones, J. Bradley, M. Machulak. July 2015. (Format: TXT=38044 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7592) 7593 The eduroam Architecture for Network Roaming. K. Wierenga, S. Winter, T. Wolniewicz. September 2015. (Format: TXT=89517 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7593) 7594 A Framework for Large-Scale Measurement of Broadband Performance (LMAP). P. Eardley, A. Morton, M. Bagnulo, T. Burbridge, P. Aitken, A. Akhter. September 2015. (Format: TXT=131972 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7594) 7595 Guidelines and Registration Procedures for URI Schemes. D. Thaler, Ed., T. Hansen, T. Hardie. June 2015. (Format: TXT=42897 bytes) (Obsoletes RFC4395) (Also BCP0035) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7595) 7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. Y. Cui, Q. Sun, M. Boucadair, T. Tsou, Y. Lee, I. Farrer. July 2015. (Format: TXT=47038 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7596) 7597 Mapping of Address and Port with Encapsulation (MAP-E). O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed.. July 2015. (Format: TXT=70507 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7597) 7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients. T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng. July 2015. (Format: TXT=40023 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7598) 7599 Mapping of Address and Port using Translation (MAP-T). X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami. July 2015. (Format: TXT=55548 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7599) 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd). R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen. July 2015. (Format: TXT=96462 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7600) 7601 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. August 2015. (Format: TXT=120736 bytes) (Obsoletes RFC7001, RFC7410) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7601) 7602 IS-IS Extended Sequence Number TLV. U. Chunduri, W. Lu, A. Tian, N. Shen. July 2015. (Format: TXT=23904 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7602) 7603 Energy Management (EMAN) Applicability Statement. B. Schoening, M. Chandramouli, B. Nordman. August 2015. (Format: TXT=62218 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7603) 7604 Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP). M. Westerlund, T. Zeng. September 2015. (Format: TXT=110996 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7604) 7605 Recommendations on Using Assigned Transport Port Numbers. J. Touch. August 2015. (Format: TXT=58012 bytes) (Also BCP0165) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7605) 7606 Revised Error Handling for BGP UPDATE Messages. E. Chen, Ed., J. Scudder, Ed., P. Mohapatra, K. Patel. August 2015. (Format: TXT=42141 bytes) (Updates RFC1997, RFC4271, RFC4360, RFC4456, RFC4760, RFC5543, RFC5701, RFC6368) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7606) 7607 Codification of AS 0 Processing. W. Kumari, R. Bush, H. Schiller, K. Patel. August 2015. (Format: TXT=9113 bytes) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7607) 7608 IPv6 Prefix Length Recommendation for Forwarding. M. Boucadair, A. Petrescu, F. Baker. July 2015. (Format: TXT=10818 bytes) (Also BCP0198) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7608) 7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol. M. Fox, C. Kassimis, J. Stevens. August 2015. (Format: TXT=326888 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7609) 7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers. F. Gont, W. Liu, G. Van de Velde. August 2015. (Format: TXT=26119 bytes) (Also BCP0199) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7610) 7611 BGP ACCEPT_OWN Community Attribute. J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder. August 2015. (Format: TXT=16976 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7611) 7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services. P. Fleming, I. McDonald. June 2015. (Format: TXT=99282 bytes) (Obsoletes RFC3712) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7612) 7613 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords. P. Saint-Andre, A. Melnikov. August 2015. (Format: TXT=59062 bytes) (Obsoletes RFC4013) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7613) 7614 Explicit Subscriptions for the REFER Method. R. Sparks. August 2015. (Format: TXT=32358 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7614) 7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields. J. Reschke. September 2015. (Format: TXT=12239 bytes) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7615) 7616 HTTP Digest Access Authentication. R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer. September 2015. (Format: TXT=71946 bytes) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7616) 7617 The 'Basic' HTTP Authentication Scheme. J. Reschke. September 2015. (Format: TXT=30163 bytes) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7617) 7618 Dynamic Allocation of Shared IPv4 Addresses. Y. Cui, Q. Sun, I. Farrer, Y. Lee, Q. Sun, M. Boucadair. August 2015. (Format: TXT=32576 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7618) 7619 The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2). V. Smyslov, P. Wouters. August 2015. (Format: TXT=24593 bytes) (Updates RFC4301) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7619) 7620 Scenarios with Host Identification Complications. M. Boucadair, Ed., B. Chatras, T. Reddy, B. Williams, B. Sarikaya. August 2015. (Format: TXT=60354 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7620) 7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework. A.B. Roach. August 2015. (Format: TXT=6891 bytes) (Updates RFC6665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7621) 7622 Extensible Messaging and Presence Protocol (XMPP): Address Format. P. Saint-Andre. September 2015. (Format: TXT=60008 bytes) (Obsoletes RFC6122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7622) 7623 Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN). A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W. Henderickx. September 2015. (Format: TXT=52595 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7623) 7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement. R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, D. Borkmann. August 2015. (Format: TXT=62260 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7624) 7625 Architecture of an IP/MPLS Network with Hardened Pipes. J. T. Hao, P. Maheshwari, R. Huang, L. Andersson, M. Chen. August 2015. (Format: TXT=30486 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7625) 7626 DNS Privacy Considerations. S. Bortzmeyer. August 2015. (Format: TXT=43202 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7626) 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension. K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray. September 2015. (Format: TXT=34788 bytes) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7627) 7628 A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth. W. Mills, T. Showalter, H. Tschofenig. August 2015. (Format: TXT=46408 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7628) 7629 Flow-Binding Support for Mobile IP. S. Gundavelli, Ed., K. Leung, G. Tsirtsis, A. Petrescu. August 2015. (Format: TXT=42488 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7629) 7630 HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3. J. Merkle, Ed., M. Lochter. October 2015. (Format: TXT=29324 bytes) (Obsoleted by RFC7860) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7630) 7631 TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format. C. Dearlove, T. Clausen. September 2015. (Format: TXT=34376 bytes) (Updates RFC5444) (Updated by RFC7722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7631) 7632 Endpoint Security Posture Assessment: Enterprise Use Cases. D. Waltermire, D. Harrington. September 2015. (Format: TXT=53853 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7632) 7633 X.509v3 Transport Layer Security (TLS) Feature Extension. P. Hallam-Baker. October 2015. (Format: TXT=21839 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7633) 7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec. Y. Nir. August 2015. (Format: TXT=27513 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7634) 7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization. T. Reddy, P. Patil, R. Ravindranath, J. Uberti. August 2015. (Format: TXT=51753 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7635) 7636 Proof Key for Code Exchange by OAuth Public Clients. N. Sakimura, Ed., J. Bradley, N. Agarwal. September 2015. (Format: TXT=39482 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7636) 7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation. P. Garg, Ed., Y. Wang, Ed.. September 2015. (Format: TXT=40042 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7637) 7638 JSON Web Key (JWK) Thumbprint. M. Jones, N. Sakimura. September 2015. (Format: TXT=27593 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7638) 7639 The ALPN HTTP Header Field. A. Hutton, J. Uberti, M. Thomson. August 2015. (Format: TXT=14455 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7639) 7640 Traffic Management Benchmarking. B. Constantine, R. Krishnan. September 2015. (Format: TXT=107543 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7640) 7641 Observing Resources in the Constrained Application Protocol (CoAP). K. Hartke. September 2015. (Format: TXT=65842 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7641) 7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements. K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan. September 2015. (Format: TXT=38759 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7642) 7643 System for Cross-domain Identity Management: Core Schema. P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore. September 2015. (Format: TXT=180665 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7643) 7644 System for Cross-domain Identity Management: Protocol. P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore. September 2015. (Format: TXT=170460 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7644) 7645 The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis. U. Chunduri, A. Tian, W. Lu. September 2015. (Format: TXT=28986 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7645) 7646 Definition and Use of DNSSEC Negative Trust Anchors. P. Ebersman, W. Kumari, C. Griffiths, J. Livingood, R. Weber. September 2015. (Format: TXT=36117 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7646) 7647 Clarifications for the Use of REFER with RFC 6665. R. Sparks, A.B. Roach. September 2015. (Format: TXT=12596 bytes) (Updates RFC3515) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7647) 7648 Port Control Protocol (PCP) Proxy Function. S. Perreault, M. Boucadair, R. Penno, D. Wing, S. Cheshire. September 2015. (Format: TXT=31233 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7648) 7649 The Jabber Scribe Role at IETF Meetings. P. Saint-Andre, D. York. September 2015. (Format: TXT=27720 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7649) 7650 A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). J. Jimenez, J. Lopez-Vega, J. Maenpaa, G. Camarillo. September 2015. (Format: TXT=37404 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7650) 7651 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2). A. Dodd-Noble, S. Gundavelli, J. Korhonen, F. Baboescu, B. Weis. September 2015. (Format: TXT=18767 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7651) 7652 Port Control Protocol (PCP) Authentication Mechanism. M. Cullen, S. Hartman, D. Zhang, T. Reddy. September 2015. (Format: TXT=78237 bytes) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7652) 7653 DHCPv6 Active Leasequery. D. Raghuvanshi, K. Kinnear, D. Kukrety. October 2015. (Format: TXT=71631 bytes) (Updates RFC5460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7653) 7654 Benchmarking Methodology for In-Service Software Upgrade (ISSU). S. Banks, F. Calabria, G. Czirjak, R. Machat. October 2015. (Format: TXT=36991 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7654) 7655 RTP Payload Format for G.711.0. M. Ramalho, Ed., P. Jones, N. Harada, M. Perumal, L. Miao. November 2015. (Format: TXT=77477 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7655) 7656 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources. J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman, Ed.. November 2015. (Format: TXT=101759 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7656) 7657 Differentiated Services (Diffserv) and Real-Time Communication. D. Black, Ed., P. Jones. November 2015. (Format: TXT=67721 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7657) 7658 Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs). S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. October 2015. (Format: TXT=121658 bytes) (Obsoletes RFC4008) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7658) 7659 Definitions of Managed Objects for Network Address Translators (NATs). S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. October 2015. (Format: TXT=183157 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7659) 7660 Diameter Congestion and Filter Attributes. L. Bertz, S. Manning, B. Hirschman. October 2015. (Format: TXT=18830 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7660) 7661 Updating TCP to Support Rate-Limited Traffic. G. Fairhurst, A. Sathiaseelan, R. Secchi. October 2015. (Format: TXT=51267 bytes) (Obsoletes RFC2861) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7661) 7662 OAuth 2.0 Token Introspection. J. Richer, Ed.. October 2015. (Format: TXT=36591 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7662) 7663 Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI). B. Trammell, Ed., M. Kuehlewind, Ed.. October 2015. (Format: TXT=30588 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7663) 7664 Dragonfly Key Exchange. D. Harkins, Ed.. November 2015. (Format: TXT=37576 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7664) 7665 Service Function Chaining (SFC) Architecture. J. Halpern, Ed., C. Pignataro, Ed.. October 2015. (Format: TXT=74825 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7665) 7666 Management Information Base for Virtual Machines Controlled by a Hypervisor. H. Asai, M. MacFaden, J. Schoenwaelder, K. Shima, T. Tsou. October 2015. (Format: TXT=106260 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7666) 7667 RTP Topologies. M. Westerlund, S. Wenger. November 2015. (Format: TXT=122959 bytes) (Obsoletes RFC5117) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7667) 7668 IPv6 over BLUETOOTH(R) Low Energy. J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez. October 2015. (Format: TXT=52855 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7668) 7669 Assigning Digital Object Identifiers to RFCs. J. Levine. October 2015. (Format: TXT=15726 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7669) 7670 Generic Raw Public-Key Support for IKEv2. T. Kivinen, P. Wouters, H. Tschofenig. January 2016. (Format: TXT=21350 bytes) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7670) 7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. V. Dukhovni, W. Hardaker. October 2015. (Format: TXT=80496 bytes) (Updates RFC6698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7671) 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). V. Dukhovni, W. Hardaker. October 2015. (Format: TXT=87943 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7672) 7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records. T. Finch, M. Miller, P. Saint-Andre. October 2015. (Format: TXT=34193 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7673) 7674 Clarification of the Flowspec Redirect Extended Community. J. Haas, Ed.. October 2015. (Format: TXT=12704 bytes) (Updates RFC5575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7674) 7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness. M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson. October 2015. (Format: TXT=22346 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7675) 7676 IPv6 Support for Generic Routing Encapsulation (GRE). C. Pignataro, R. Bonica, S. Krishnan. October 2015. (Format: TXT=21622 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7676) 7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms. T. Hansen. November 2015. (Format: TXT=15209 bytes) (Updates RFC5802) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7677) 7678 Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions. C. Zhou, T. Taylor, Q. Sun, M. Boucadair. October 2015. (Format: TXT=49074 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7678) 7679 A One-Way Delay Metric for IP Performance Metrics (IPPM). G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. January 2016. (Format: TXT=59852 bytes) (Obsoletes RFC2679) (Also STD0081) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7679) 7680 A One-Way Loss Metric for IP Performance Metrics (IPPM). G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. January 2016. (Format: TXT=47253 bytes) (Obsoletes RFC2680) (Also STD0082) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7680) 7681 Email Exchange of Secondary School Transcripts. J. Davin. October 2015. (Format: TXT=103965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7681) 7682 Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration. D. McPherson, S. Amante, E. Osterweil, L. Blunk, D. Mitchell. December 2015. (Format: TXT=47996 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7682) 7683 Diameter Overload Indication Conveyance. J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand. October 2015. (Format: TXT=96330 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7683) 7684 OSPFv2 Prefix/Link Attribute Advertisement. P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem. November 2015. (Format: TXT=33236 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7684) 7685 A Transport Layer Security (TLS) ClientHello Padding Extension. A. Langley. October 2015. (Format: TXT=7034 bytes) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7685) 7686 The ".onion" Special-Use Domain Name. J. Appelbaum, A. Muffett. October 2015. (Format: TXT=13475 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7686) 7687 Report from the Strengthening the Internet (STRINT) Workshop. S. Farrell, R. Wenning, B. Bos, M. Blanchet, H. Tschofenig. December 2015. (Format: TXT=73006 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7687) 7688 GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks. Y. Lee, Ed., G. Bernstein, Ed.. November 2015. (Format: TXT=25429 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7688) 7689 Signaling Extensions for Wavelength Switched Optical Networks. G. Bernstein, Ed., S. Xu, Y. Lee, Ed., G. Martinelli, H. Harai. November 2015. (Format: TXT=32687 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7689) 7690 Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)). M. Byerly, M. Hite, J. Jaeggli. January 2016. (Format: TXT=19061 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7690) 7691 Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members. S. Bradner, Ed.. November 2015. (Format: TXT=7197 bytes) (Updates RFC4071) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7691) 7692 Compression Extensions for WebSocket. T. Yoshino. December 2015. (Format: TXT=62411 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7692) 7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC). M-J. Saarinen, Ed., J-P. Aumasson. November 2015. (Format: TXT=55532 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7693) 7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding. J. Reschke. November 2015. (Format: TXT=13676 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7694) 7695 Distributed Prefix Assignment Algorithm. P. Pfister, B. Paterson, J. Arkko. November 2015. (Format: TXT=46244 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7695) 7696 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms. R. Housley. November 2015. (Format: TXT=50543 bytes) (Also BCP0201) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7696) 7697 MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB). P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros. January 2016. (Format: TXT=66337 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7697) 7698 Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. O. Gonzalez de Dios, Ed., R. Casellas, Ed., F. Zhang, X. Fu, D. Ceccarelli, I. Hussain. November 2015. (Format: TXT=89787 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7698) 7699 Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers. A. Farrel, D. King, Y. Li, F. Zhang. November 2015. (Format: TXT=30463 bytes) (Updates RFC3471, RFC6205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7699) 7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames. P. Saint-Andre. December 2015. (Format: TXT=22898 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7700) 7701 Multi-party Chat Using the Message Session Relay Protocol (MSRP). A. Niemi, M. Garcia-Martin, G. Sandbakken. December 2015. (Format: TXT=99607 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7701) 7702 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat. P. Saint-Andre, S. Ibarra, S. Loreto. December 2015. (Format: TXT=86457 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7702) 7703 Experience with Testing of Mapping of Address and Port Using Translation (MAP-T). E. Cordeiro, R. Carnier, A. Moreiras. November 2015. (Format: TXT=126481 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7703) 7704 An IETF with Much Diversity and Professional Conduct. D. Crocker, N. Clark. November 2015. (Format: TXT=41359 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7704) 7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute. W. George, S. Amante. November 2015. (Format: TXT=41349 bytes) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7705) 7706 Decreasing Access Time to Root Servers by Running One on Loopback. W. Kumari, P. Hoffman. November 2015. (Format: TXT=24234 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7706) 7707 Network Reconnaissance in IPv6 Networks. F. Gont, T. Chown. March 2016. (Format: TXT=88281 bytes) (Obsoletes RFC5157) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7707) 7708 Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator. T. Nadeau, L. Martini, S. Bryant. November 2015. (Format: TXT=18881 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7708) 7709 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs). A. Malis, Ed., B. Wilson, G. Clapp, V. Shukla. November 2015. (Format: TXT=20022 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7709) 7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs). W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng. December 2015. (Format: TXT=16352 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7710) 7711 PKIX over Secure HTTP (POSH). M. Miller, P. Saint-Andre. November 2015. (Format: TXT=41302 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7711) 7712 Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, M. Miller, P. Hancke. November 2015. (Format: TXT=49879 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7712) 7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements. M. Mathis, B. Briscoe. December 2015. (Format: TXT=76797 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7713) 7714 AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP). D. McGrew, K. Igoe. December 2015. (Format: TXT=95334 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7714) 7715 Multipoint LDP (mLDP) Node Protection. IJ. Wijnands, Ed., K. Raza, A. Atlas, J. Tantsura, Q. Zhao. January 2016. (Format: TXT=39353 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7715) 7716 Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures. J. Zhang, L. Giuliano, E. Rosen, Ed., K. Subramanian, D. Pacella. December 2015. (Format: TXT=52951 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7716) 7717 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP). K. Pentikousis, Ed., E. Zhang, Y. Cui. December 2015. (Format: TXT=34960 bytes) (Updates RFC4656, RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7717) 7718 Registries for the One-Way Active Measurement Protocol (OWAMP). A. Morton. December 2015. (Format: TXT=14719 bytes) (Updates RFC4656) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7718) 7719 DNS Terminology. P. Hoffman, A. Sullivan, K. Fujiwara. December 2015. (Format: TXT=68383 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7719) 7720 DNS Root Name Service Protocol and Deployment Requirements. M. Blanchet, L-J. Liman. December 2015. (Format: TXT=10552 bytes) (Obsoletes RFC2870) (Also BCP0040) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7720) 7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms. A. Cooper, F. Gont, D. Thaler. March 2016. (Format: TXT=43381 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7721) 7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2). C. Dearlove, T. Clausen. December 2015. (Format: TXT=52375 bytes) (Updates RFC7188, RFC7631) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7722) 7723 Port Control Protocol (PCP) Anycast Addresses. S. Kiesel, R. Penno. January 2016. (Format: TXT=20663 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7723) 7724 Active DHCPv4 Lease Query. K. Kinnear, M. Stapp, B. Volz, N. Russell. December 2015. (Format: TXT=66964 bytes) (Updates RFC6926) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7724) 7725 An HTTP Status Code to Report Legal Obstacles. T. Bray. February 2016. (Format: TXT=9309 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7725) 7726 Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs). V. Govindan, K. Rajaraman, G. Mirsky, N. Akiya, S. Aldrin. January 2016. (Format: TXT=13899 bytes) (Updates RFC5884) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7726) 7727 Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP). M. Zhang, H. Wen, J. Hu. January 2016. (Format: TXT=48135 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7727) 7728 RTP Stream Pause and Resume. B. Burman, A. Akram, R. Even, M. Westerlund. February 2016. (Format: TXT=135619 bytes) (Updates RFC5104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7728) 7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management. B. Khasnabish, E. Haleplidis, J. Hadi Salim, Ed.. December 2015. (Format: TXT=40570 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7729) 7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent. January 2016. (Format: TXT=17672 bytes) (Obsoletes RFC6490) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7730) 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL). J. Hui, R. Kelsey. February 2016. (Format: TXT=63216 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7731) 7732 Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL). P. van der Stok, R. Cragie. February 2016. (Format: TXT=34403 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7732) 7733 Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control. A. Brandt, E. Baccelli, R. Cragie, P. van der Stok. February 2016. (Format: TXT=85372 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7733) 7734 Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN). D. Allan, Ed., J. Tantsura, D. Fedyk, A. Sajassi. January 2016. (Format: TXT=23512 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7734) 7735 Tracking Reviews of Documents. R. Sparks, T. Kivinen. January 2016. (Format: TXT=35326 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7735) 7736 Content Delivery Network Interconnection (CDNI) Media Type Registration. K. Ma. December 2015. (Format: TXT=13053 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7736) 7737 Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification. N. Akiya, G. Swallow, C. Pignataro, L. Andersson, M. Chen. January 2016. (Format: TXT=35253 bytes) (Updates RFC7110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7737) 7738 A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS). M. Blanchet, A. Schiltknecht, P. Shames. January 2016. (Format: TXT=14304 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7738) 7739 Security Implications of Predictable Fragment Identification Values. F. Gont. February 2016. (Format: TXT=46433 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7739) 7740 Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication. Z. Zhang, Y. Rekhter, A. Dolganow. January 2016. (Format: TXT=18252 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7740) 7741 RTP Payload Format for VP8 Video. P. Westin, H. Lundin, M. Glover, J. Uberti, F. Galligan. March 2016. (Format: TXT=58399 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7741) 7742 WebRTC Video Processing and Codec Requirements. A.B. Roach. March 2016. (Format: TXT=21184 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7742) 7743 Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping. J. Luo, Ed., L. Jin, Ed., T. Nadeau, Ed., G. Swallow, Ed.. January 2016. (Format: TXT=39321 bytes) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7743) 7744 Use Cases for Authentication and Authorization in Constrained Environments. L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. Kumar. January 2016. (Format: TXT=72630 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7744) 7745 XML Schemas for Reverse DNS Management. T. Manderson. January 2016. (Format: TXT=17788 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7745) 7746 Label Switched Path (LSP) Self-Ping. R. Bonica, I. Minei, M. Conn, D. Pacella, L. Tomotaki. January 2016. (Format: TXT=25146 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7746) 7747 Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence. R. Papneja, B. Parise, S. Hares, D. Lee, I. Varlashkin. April 2016. (Format: TXT=65341 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7747) 7748 Elliptic Curves for Security. A. Langley, M. Hamburg, S. Turner. January 2016. (Format: TXT=39298 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7748) 7749 The "xml2rfc" Version 2 Vocabulary. J. Reschke. February 2016. (Format: TXT=109478 bytes) (Obsoletes RFC2629) (Obsoleted by RFC7991) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7749) 7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP). J. Hedin, G. Mirsky, S. Baillargeon. February 2016. (Format: TXT=24296 bytes) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7750) 7751 Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs). S. Sorce, T. Yu. March 2016. (Format: TXT=23133 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7751) 7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP. H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray. March 2016. (Format: TXT=113130 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7752) 7753 Port Control Protocol (PCP) Extension for Port-Set Allocation. Q. Sun, M. Boucadair, S. Sivakumar, C. Zhou, T. Tsou, S. Perreault. February 2016. (Format: TXT=34550 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7753) 7754 Technical Considerations for Internet Service Blocking and Filtering. R. Barnes, A. Cooper, O. Kolkman, D. Thaler, E. Nordmark. March 2016. (Format: TXT=85046 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7754) 7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments. T. Anderson. February 2016. (Format: TXT=54648 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7755) 7756 Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode. T. Anderson, S. Steffann. February 2016. (Format: TXT=39291 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7756) 7757 Explicit Address Mappings for Stateless IP/ICMP Translation. T. Anderson, A. Leiva Popper. February 2016. (Format: TXT=40938 bytes) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7757) 7758 Time Capability in NETCONF. T. Mizrahi, Y. Moses. February 2016. (Format: TXT=56330 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7758) 7759 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping. E. Bellagamba, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward, J. Drake. February 2016. (Format: TXT=66411 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7759) 7760 Statement of Work for Extensions to the IETF Datatracker for Author Statistics. R. Housley. January 2016. (Format: TXT=16816 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7760) 7761 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng. March 2016. (Format: TXT=295255 bytes) (Obsoletes RFC4601) (Also STD0083) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7761) 7762 Initial Assignment for the Content Security Policy Directives Registry. M. West. January 2016. (Format: TXT=10241 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7762) 7763 The text/markdown Media Type. S. Leonard. March 2016. (Format: TXT=34580 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7763) 7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations. S. Leonard. March 2016. (Format: TXT=50910 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7764) 7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart. P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl. February 2016. (Format: TXT=35361 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7765) 7766 DNS Transport over TCP - Implementation Requirements. J. Dickinson, S. Dickinson, R. Bellis, A. Mankin, D. Wessels. March 2016. (Format: TXT=40616 bytes) (Obsoletes RFC5966) (Updates RFC1035, RFC1123) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7766) 7767 Application-Initiated Check-Pointing via the Port Control Protocol (PCP). S. Vinapamula, S. Sivakumar, M. Boucadair, T. Reddy. February 2016. (Format: TXT=24178 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7767) 7768 Port Management to Reduce Logging in Large-Scale NATs. T. Tsou, W. Li, T. Taylor, J. Huang. January 2016. (Format: TXT=23442 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7768) 7769 Media Access Control (MAC) Address Withdrawal over Static Pseudowire. S. Sivabalan, S. Boutros, H. Shah, S. Aldrin, M. Venkatesan. February 2016. (Format: TXT=20518 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7769) 7770 Extensions to OSPF for Advertising Optional Router Capabilities. A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. February 2016. (Format: TXT=32855 bytes) (Obsoletes RFC4970) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7770) 7771 Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires. A. Malis, Ed., L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro. January 2016. (Format: TXT=19235 bytes) (Updates RFC6870) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7771) 7772 Reducing Energy Consumption of Router Advertisements. A. Yourtchenko, L. Colitti. February 2016. (Format: TXT=12555 bytes) (Also BCP0202) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7772) 7773 Authentication Context Certificate Extension. S. Santesson. March 2016. (Format: TXT=33338 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7773) 7774 Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6. Y. Doi, M. Gillmore. March 2016. (Format: TXT=21758 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7774) 7775 IS-IS Route Preference for Extended IP and IPv6 Reachability. L. Ginsberg, S. Litkowski, S. Previdi. February 2016. (Format: TXT=23624 bytes) (Updates RFC5308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7775) 7776 IETF Anti-Harassment Procedures. P. Resnick, A. Farrel. March 2016. (Format: TXT=42853 bytes) (Updates RFC2418, RFC7437) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7776) 7777 Advertising Node Administrative Tags in OSPF. S. Hegde, R. Shakir, A. Smirnov, Z. Li, B. Decraene. March 2016. (Format: TXT=33684 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7777) 7778 Mobile Communication Congestion Exposure Scenario. D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang, CJ. Bernardos. March 2016. (Format: TXT=56883 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7778) 7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2). H. Rogge, E. Baccelli. April 2016. (Format: TXT=43953 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7779) 7780 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang, R. Perlman, A. Banerjee, A. Ghanwani, S. Gupta. February 2016. (Format: TXT=125037 bytes) (Obsoletes RFC7180) (Updates RFC6325, RFC7177, RFC7179) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7780) 7781 Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access. H. Zhai, T. Senevirathne, R. Perlman, M. Zhang, Y. Li. February 2016. (Format: TXT=79489 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7781) 7782 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments. M. Zhang, R. Perlman, H. Zhai, M. Durrani, S. Gupta. February 2016. (Format: TXT=47989 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7782) 7783 Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL). T. Senevirathne, J. Pathangi, J. Hudson. February 2016. (Format: TXT=36970 bytes) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7783) 7784 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB. D. Kumar, S. Salam, T. Senevirathne. February 2016. (Format: TXT=99471 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7784) 7785 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite. S. Vinapamula, M. Boucadair. February 2016. (Format: TXT=20529 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7785) 7786 TCP Modifications for Congestion Exposure (ConEx). M. Kuehlewind, Ed., R. Scheffenegger. May 2016. (Format: TXT=48439 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7786) 7787 Distributed Node Consensus Protocol. M. Stenberg, S. Barth. April 2016. (Format: TXT=96466 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7787) 7788 Home Networking Control Protocol. M. Stenberg, S. Barth, P. Pfister. April 2016. (Format: TXT=94146 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7788) 7789 Impact of BGP Filtering on Inter-Domain Routing Policies. C. Cardona, P. Francois, P. Lucente. April 2016. (Format: TXT=38047 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7789) 7790 Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS). Y. Yoneya, T. Nemoto. February 2016. (Format: TXT=20806 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7790) 7791 Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2). D. Migault, Ed., V. Smyslov. March 2016. (Format: TXT=32532 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7791) 7792 RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. F. Zhang, X. Zhang, A. Farrel, O. Gonzalez de Dios, D. Ceccarelli. March 2016. (Format: TXT=20801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7792) 7793 Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry. M. Andrews. May 2016. (Format: TXT=7713 bytes) (Also BCP0163) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7793) 7794 IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability. L. Ginsberg, Ed., B. Decraene, S. Previdi, X. Xu, U. Chunduri. March 2016. (Format: TXT=15925 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7794) 7795 Pseudowire Redundancy on the Switching Provider Edge (S-PE). J. Dong, H. Wang. February 2016. (Format: TXT=21064 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7795) 7796 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS). Y. Jiang, Ed., L. Yong, M. Paul. March 2016. (Format: TXT=52579 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7796) 7797 JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. February 2016. (Format: TXT=23108 bytes) (Updates RFC7519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7797) 7798 RTP Payload Format for High Efficiency Video Coding (HEVC). Y.-K. Wang, Y. Sanchez, T. Schierl, S. Wenger, M. M. Hannuksela. March 2016. (Format: TXT=209680 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7798) 7799 Active and Passive Metrics and Methods (with Hybrid Types In-Between). A. Morton. May 2016. (Format: TXT=33717 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7799) 7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs). M. Jones, J. Bradley, H. Tschofenig. April 2016. (Format: TXT=33625 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7800) 7801 GOST R 34.12-2015: Block Cipher "Kuznyechik". V. Dolmatov, Ed.. March 2016. (Format: TXT=25039 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7801) 7802 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism. S. Emery, N. Williams. March 2016. (Format: TXT=14118 bytes) (Obsoletes RFC4402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7802) 7803 Changing the Registration Policy for the NETCONF Capability URNs Registry. B. Leiba. February 2016. (Format: TXT=5133 bytes) (Updates RFC6241) (Also BCP0203) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7803) 7804 Salted Challenge Response HTTP Authentication Mechanism. A. Melnikov. March 2016. (Format: TXT=39440 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7804) 7805 Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status. A. Zimmermann, W. Eddy, L. Eggert. April 2016. (Format: TXT=15754 bytes) (Obsoletes RFC0675, RFC0721, RFC0761, RFC0813, RFC0816, RFC0879, RFC0896, RFC1078, RFC6013) (Updates RFC7414) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7805) 7806 On Queuing, Marking, and Dropping. F. Baker, R. Pan. April 2016. (Format: TXT=37818 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7806) 7807 Problem Details for HTTP APIs. M. Nottingham, E. Wilde. March 2016. (Format: TXT=31210 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7807) 7808 Time Zone Data Distribution Service. M. Douglass, C. Daboo. March 2016. (Format: TXT=113582 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7808) 7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference. C. Daboo. March 2016. (Format: TXT=28902 bytes) (Updates RFC4791) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7809) 7810 IS-IS Traffic Engineering (TE) Metric Extensions. S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. May 2016. (Format: TXT=37563 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7810) 7811 An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR). G. Enyedi, A. Csaszar, A. Atlas, C. Bowers, A. Gopalan. June 2016. (Format: TXT=266847 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7811) 7812 An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR). A. Atlas, C. Bowers, G. Enyedi. June 2016. (Format: TXT=110616 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7812) 7813 IS-IS Path Control and Reservation. J. Farkas, Ed., N. Bragg, P. Unbehagen, G. Parsons, P. Ashwood-Smith, C. Bowers. June 2016. (Format: TXT=77823 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7813) 7814 Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution. X. Xu, C. Jacquenet, R. Raszuk, T. Boyes, B. Fee. March 2016. (Format: TXT=37397 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7814) 7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation. T. Kivinen. March 2016. (Format: TXT=92959 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7815) 7816 DNS Query Name Minimisation to Improve Privacy. S. Bortzmeyer. March 2016. (Format: TXT=23941 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7816) 7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols. A. Melnikov. March 2016. (Format: TXT=29855 bytes) (Updates RFC2595, RFC3207, RFC3501, RFC5804) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7817) 7818 URN Namespace for MEF Documents. M. Jethanandani. March 2016. (Format: TXT=8564 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7818) 7819 Privacy Considerations for DHCP. S. Jiang, S. Krishnan, T. Mrugalski. April 2016. (Format: TXT=32944 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7819) 7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP). T. Mizrahi. March 2016. (Format: TXT=30611 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7820) 7821 UDP Checksum Complement in the Network Time Protocol (NTP). T. Mizrahi. March 2016. (Format: TXT=26007 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7821) 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields. T. Mizrahi, D. Mayer. March 2016. (Format: TXT=15759 bytes) (Updates RFC5905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7822) 7823 Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions. A. Atlas, J. Drake, S. Giacalone, S. Previdi. May 2016. (Format: TXT=23256 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7823) 7824 Privacy Considerations for DHCPv6. S. Krishnan, T. Mrugalski, S. Jiang. May 2016. (Format: TXT=42561 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7824) 7825 A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP). J. Goldberg, M. Westerlund, T. Zeng. December 2016. (Format: TXT=81878 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7825) 7826 Real-Time Streaming Protocol Version 2.0. H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling, Ed.. December 2016. (Format: TXT=746422 bytes) (Obsoletes RFC2326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7826) 7827 The Role of the IRTF Chair. L. Eggert. March 2016. (Format: TXT=16696 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7827) 7828 The edns-tcp-keepalive EDNS0 Option. P. Wouters, J. Abley, S. Dickinson, R. Bellis. April 2016. (Format: TXT=24282 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7828) 7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol. Y. Nishida, P. Natarajan, A. Caro, P. Amer, K. Nielsen. April 2016. (Format: TXT=53922 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7829) 7830 The EDNS(0) Padding Option. A. Mayrhofer. May 2016. (Format: TXT=9520 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7830) 7831 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture. J. Howlett, S. Hartman, H. Tschofenig, J. Schaad. May 2016. (Format: TXT=114076 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7831) 7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases. R. Smith, Ed.. May 2016. (Format: TXT=33640 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7832) 7833 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML). J. Howlett, S. Hartman, A. Perez-Mendez, Ed.. May 2016. (Format: TXT=65341 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7833) 7834 Locator/ID Separation Protocol (LISP) Impact. D. Saucez, L. Iannone, A. Cabellos, F. Coras. April 2016. (Format: TXT=43168 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7834) 7835 Locator/ID Separation Protocol (LISP) Threat Analysis. D. Saucez, L. Iannone, O. Bonaventure. April 2016. (Format: TXT=45107 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7835) 7836 Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012. S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov, S. Leontiev, V. Podobaev, D. Belyavsky. March 2016. (Format: TXT=57463 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7836) 7837 IPv6 Destination Option for Congestion Exposure (ConEx). S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli. May 2016. (Format: TXT=29708 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7837) 7838 HTTP Alternative Services. M. Nottingham, P. McManus, J. Reschke. April 2016. (Format: TXT=42681 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7838) 7839 Access-Network-Identifier Option in DHCP. S. Bhandari, S. Gundavelli, M. Grayson, B. Volz, J. Korhonen. June 2016. (Format: TXT=42942 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7839) 7840 A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol. J. Winterbottom, H. Tschofenig, L. Liess. May 2016. (Format: TXT=30696 bytes) (Updates RFC5985, RFC6881) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7840) 7841 RFC Streams, Headers, and Boilerplates. J. Halpern, Ed., L. Daigle, Ed., O. Kolkman, Ed.. May 2016. (Format: TXT=27950 bytes) (Obsoletes RFC5741) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7841) 7842 Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool. R. Sparks. April 2016. (Format: TXT=13316 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7842) 7843 Port Control Protocol (PCP) Third-Party ID Option. A. Ripke, R. Winter, T. Dietz, J. Quittek, R. da Silva. May 2016. (Format: TXT=30488 bytes) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7843) 7844 Anonymity Profiles for DHCP Clients. C. Huitema, T. Mrugalski, S. Krishnan. May 2016. (Format: TXT=62026 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7844) 7845 Ogg Encapsulation for the Opus Audio Codec. T. Terriberry, R. Lee, R. Giles. April 2016. (Format: TXT=81168 bytes) (Updates RFC5334) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7845) 7846 Peer-to-Peer Streaming Tracker Protocol (PPSTP). R. Cruz, M. Nunes, J. Xia, R. Huang, Ed., J. Taveira, D. Lingli. May 2016. (Format: TXT=120911 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7846) 7847 Logical-Interface Support for IP Hosts with Multi-Access Support. T. Melia, Ed., S. Gundavelli, Ed.. May 2016. (Format: TXT=35657 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7847) 7848 Mark and Signed Mark Objects Mapping. G. Lozano. June 2016. (Format: TXT=46443 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7848) 7849 An IPv6 Profile for 3GPP Mobile Devices. D. Binet, M. Boucadair, A. Vizdal, G. Chen, N. Heatley, R. Chandler, D. Michaud, D. Lopez, W. Haeffner. May 2016. (Format: TXT=51725 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7849) 7850 Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles. S. Nandakumar. April 2016. (Format: TXT=15190 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7850) 7851 Peer-to-Peer (P2P) Overlay Diagnostics. H. Song, X. Jiang, R. Even, D. Bryan, Y. Sun. May 2016. (Format: TXT=70591 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7851) 7852 Additional Data Related to an Emergency Call. R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, J. Winterbottom. July 2016. (Format: TXT=239135 bytes) (Updates RFC6443, RFC6881) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7852) 7853 A URN Namespace for Globus. S. Martin, S. Tuecke, B. McCollam, M. Lidman. May 2016. (Format: TXT=11530 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7853) 7854 BGP Monitoring Protocol (BMP). J. Scudder, Ed., R. Fernando, S. Stuart. June 2016. (Format: TXT=60953 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7854) 7855 Source Packet Routing in Networking (SPRING) Problem Statement and Requirements. S. Previdi, Ed., C. Filsfils, Ed., B. Decraene, S. Litkowski, M. Horneffer, R. Shakir. May 2016. (Format: TXT=38006 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7855) 7856 Softwire Mesh Management Information Base (MIB). Y. Cui, J. Dong, P. Wu, M. Xu, A. Yla-Jaaski. May 2016. (Format: TXT=34767 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7856) 7857 Updates to Network Address Translation (NAT) Behavioral Requirements. R. Penno, S. Perreault, M. Boucadair, Ed., S. Sivakumar, K. Naito. April 2016. (Format: TXT=29255 bytes) (Updates RFC4787, RFC5382, RFC5508) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7857) 7858 Specification for DNS over Transport Layer Security (TLS). Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman. May 2016. (Format: TXT=42138 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7858) 7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols. C. Dearlove. May 2016. (Format: TXT=36651 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7859) 7860 HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3. J. Merkle, Ed., M. Lochter. April 2016. (Format: TXT=29329 bytes) (Obsoletes RFC7630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7860) 7861 Remote Procedure Call (RPC) Security Version 3. A. Adamson, N. Williams. November 2016. (Format: TXT=53813 bytes) (Updates RFC5403) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7861) 7862 Network File System (NFS) Version 4 Minor Version 2 Protocol. T. Haynes. November 2016. (Format: TXT=237870 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7862) 7863 Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description. T. Haynes. November 2016. (Format: TXT=144687 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7863) 7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility. CJ. Bernardos, Ed.. May 2016. (Format: TXT=44225 bytes) (Updates RFC5213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7864) 7865 Session Initiation Protocol (SIP) Recording Metadata. R. Ravindranath, P. Ravindran, P. Kyzivat. May 2016. (Format: TXT=67100 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7865) 7866 Session Recording Protocol. L. Portman, H. Lum, Ed., C. Eckel, A. Johnston, A. Hutton. May 2016. (Format: TXT=104535 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7866) 7867 RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications. R. Huang. July 2016. (Format: TXT=34297 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7867) 7868 Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP). D. Savage, J. Ng, S. Moore, D. Slice, P. Paluch, R. White. May 2016. (Format: TXT=179677 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7868) 7869 The "vnc" URI Scheme. D. Warden, I. Iordanov. May 2016. (Format: TXT=53002 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7869) 7870 Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs). Y. Fu, S. Jiang, J. Dong, Y. Chen. June 2016. (Format: TXT=53247 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7870) 7871 Client Subnet in DNS Queries. C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari. May 2016. (Format: TXT=67651 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7871) 7872 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World. F. Gont, J. Linkova, T. Chown, W. Liu. June 2016. (Format: TXT=30924 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7872) 7873 Domain Name System (DNS) Cookies. D. Eastlake 3rd, M. Andrews. May 2016. (Format: TXT=55356 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7873) 7874 WebRTC Audio Codec and Processing Requirements. JM. Valin, C. Bran. May 2016. (Format: TXT=16160 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7874) 7875 Additional WebRTC Audio Codecs for Interoperability. S. Proust, Ed.. May 2016. (Format: TXT=26626 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7875) 7876 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks. S. Bryant, S. Sivabalan, S. Soni. July 2016. (Format: TXT=21092 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7876) 7877 Session Peering Provisioning Framework (SPPF). K. Cartwright, V. Bhatia, S. Ali, D. Schwartz. August 2016. (Format: TXT=121553 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7877) 7878 Session Peering Provisioning (SPP) Protocol over SOAP. K. Cartwright, V. Bhatia, J-F. Mule, A. Mayrhofer. August 2016. (Format: TXT=145284 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7878) 7879 DTLS-SRTP Handling in SIP Back-to-Back User Agents. R. Ravindranath, T. Reddy, G. Salgueiro, V. Pascual, P. Ravindran. May 2016. (Format: TXT=29648 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7879) 7880 Seamless Bidirectional Forwarding Detection (S-BFD). C. Pignataro, D. Ward, N. Akiya, M. Bhatia, S. Pallagatti. July 2016. (Format: TXT=45987 bytes) (Updates RFC5880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7880) 7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS. C. Pignataro, D. Ward, N. Akiya. July 2016. (Format: TXT=16352 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7881) 7882 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases. S. Aldrin, C. Pignataro, G. Mirsky, N. Kumar. July 2016. (Format: TXT=35774 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7882) 7883 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS. L. Ginsberg, N. Akiya, M. Chen. July 2016. (Format: TXT=9331 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7883) 7884 OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators. C. Pignataro, M. Bhatia, S. Aldrin, T. Ranganath. July 2016. (Format: TXT=13612 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7884) 7885 Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV). V. Govindan, C. Pignataro. July 2016. (Format: TXT=22500 bytes) (Updates RFC5885) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7885) 7886 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3). V. Govindan, C. Pignataro. July 2016. (Format: TXT=10878 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7886) 7887 Hierarchical Join/Prune Attributes. S. Venaas, J. Arango, I. Kouvelas. June 2016. (Format: TXT=17207 bytes) (Updates RFC5384) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7887) 7888 IMAP4 Non-synchronizing Literals. A. Melnikov, Ed.. May 2016. (Format: TXT=17375 bytes) (Obsoletes RFC2088) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7888) 7889 The IMAP APPENDLIMIT Extension. J. SrimushnamBoovaraghamoorthy, N. Bisht. May 2016. (Format: TXT=13801 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7889) 7890 Concepts and Terminology for Peer-to-Peer SIP (P2PSIP). D. Bryan, P. Matthews, E. Shim, D. Willis, S. Dawkins. June 2016. (Format: TXT=45276 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7890) 7891 Explicit Reverse Path Forwarding (RPF) Vector. J. Asghar, IJ. Wijnands, Ed., S. Krishnaswamy, A. Karan, V. Arya. June 2016. (Format: TXT=19067 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7891) 7892 IANA Allocation Procedures for the GMPLS OTN Signal Type Registry. Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. May 2016. (Format: TXT=7019 bytes) (Updates RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7892) 7893 Pseudowire Congestion Considerations. Y(J) Stein, D. Black, B. Briscoe. June 2016. (Format: TXT=54380, PDF=345714 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7893) 7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport. M. Pritikin, C. Wallace. June 2016. (Format: TXT=19712 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7894) 7895 YANG Module Library. A. Bierman, M. Bjorklund, K. Watsen. June 2016. (Format: TXT=24164 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7895) 7896 Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP). D. Dhody. June 2016. (Format: TXT=9966 bytes) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7896) 7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP). D. Dhody, U. Palle, R. Casellas. June 2016. (Format: TXT=71770 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7897) 7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE). D. Dhody, U. Palle, V. Kondreddy, R. Casellas. June 2016. (Format: TXT=34962 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7898) 7899 Multicast VPN State Damping. T. Morin, Ed., S. Litkowski, K. Patel, Z. Zhang, R. Kebler, J. Haas. June 2016. (Format: TXT=41294 bytes) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7899) 7900 Extranet Multicast in BGP/IP MPLS VPNs. Y. Rekhter, Ed., E. Rosen, Ed., R. Aggarwal, Y. Cai, T. Morin. June 2016. (Format: TXT=155704 bytes) (Updates RFC6513, RFC6514, RFC6625) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7900) 7901 CHAIN Query Requests in DNS. P. Wouters. June 2016. (Format: TXT=35252 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7901) 7902 Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags. E. Rosen, T. Morin. June 2016. (Format: TXT=14332 bytes) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7902) 7903 Windows Image Media Types. S. Leonard. September 2016. (Format: TXT=24094 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7903) 7904 A SIP Usage for REsource LOcation And Discovery (RELOAD). C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, T. Schmidt, Ed.. October 2016. (Format: TXT=41978 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7904) 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS). A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson. June 2016. (Format: TXT=15575 bytes) (Updates RFC5246, RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7905) 7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes. P. Timmel, R. Housley, S. Turner. June 2016. (Format: TXT=145888 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7906) 7908 Problem Definition and Classification of BGP Route Leaks. K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson. June 2016. (Format: TXT=25417 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7908) 7909 Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures. R. Kisteleki, B. Haberman. June 2016. (Format: TXT=30493 bytes) (Updates RFC2622, RFC4012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7909) 7910 Interoperability between the Virtual Router Redundancy Protocol and PIM. W. Zhou. June 2016. (Format: TXT=14255 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7910) 7911 Advertisement of Multiple Paths in BGP. D. Walton, A. Retana, E. Chen, J. Scudder. July 2016. (Format: TXT=17537 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7911) 7912 Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure. A. Melnikov. June 2016. (Format: TXT=24086 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7912) 7913 P-Access-Network-Info ABNF Update. C. Holmberg. June 2016. (Format: TXT=7418 bytes) (Updates RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7913) 7914 The scrypt Password-Based Key Derivation Function. C. Percival, S. Josefsson. August 2016. (Format: TXT=29222 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7914) 7915 IP/ICMP Translation Algorithm. C. Bao, X. Li, F. Baker, T. Anderson, F. Gont. June 2016. (Format: TXT=75564 bytes) (Obsoletes RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7915) 7916 Operational Management of Loop-Free Alternates. S. Litkowski, Ed., B. Decraene, C. Filsfils, K. Raza, M. Horneffer, P. Sarkar. July 2016. (Format: TXT=62072 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7916) 7917 Advertising Node Administrative Tags in IS-IS. P. Sarkar, Ed., H. Gredler, S. Hegde, S. Litkowski, B. Decraene. July 2016. (Format: TXT=23344 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7917) 7918 Transport Layer Security (TLS) False Start. A. Langley, N. Modadugu, B. Moeller. August 2016. (Format: TXT=23825 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7918) 7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS). D. Gillmor. August 2016. (Format: TXT=61937 bytes) (Updates RFC2246, RFC4346, RFC4492, RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7919) 7920 Problem Statement for the Interface to the Routing System. A. Atlas, Ed., T. Nadeau, Ed., D. Ward. June 2016. (Format: TXT=28441 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7920) 7921 An Architecture for the Interface to the Routing System. A. Atlas, J. Halpern, S. Hares, D. Ward, T. Nadeau. June 2016. (Format: TXT=100699 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7921) 7922 Interface to the Routing System (I2RS) Traceability: Framework and Information Model. J. Clarke, G. Salgueiro, C. Pignataro. June 2016. (Format: TXT=36070 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7922) 7923 Requirements for Subscription to YANG Datastores. E. Voit, A. Clemm, A. Gonzalez Prieto. June 2016. (Format: TXT=37630 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7923) 7924 Transport Layer Security (TLS) Cached Information Extension. S. Santesson, H. Tschofenig. July 2016. (Format: TXT=35144 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7924) 7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things. H. Tschofenig, Ed., T. Fossati. July 2016. (Format: TXT=141911 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7925) 7926 Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks. A. Farrel, Ed., J. Drake, N. Bitar, G. Swallow, D. Ceccarelli, X. Zhang. July 2016. (Format: TXT=159905 bytes) (Also BCP0206) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7926) 7927 Information-Centric Networking (ICN) Research Challenges. D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch. July 2016. (Format: TXT=97724 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7927) 7928 Characterization Guidelines for Active Queue Management (AQM). N. Kuhn, Ed., P. Natarajan, Ed., N. Khademi, Ed., D. Ros. July 2016. (Format: TXT=90255 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7928) 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. P. Wouters. August 2016. (Format: TXT=44695 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7929) 7930 Larger Packets for RADIUS over TCP. S. Hartman. August 2016. (Format: TXT=22676 bytes) (Updates RFC6613) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7930) 7931 NFSv4.0 Migration: Specification Update. D. Noveck, Ed., P. Shivam, C. Lever, B. Baker. July 2016. (Format: TXT=133838 bytes) (Updates RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7931) 7932 Brotli Compressed Data Format. J. Alakuijala, Z. Szabadka. July 2016. (Format: TXT=389979 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7932) 7933 Adaptive Video Streaming over Information-Centric Networking (ICN). C. Westphal, Ed., S. Lederer, D. Posch, C. Timmerer, A. Azgin, W. Liu, C. Mueller, A. Detti, D. Corujo, J. Wang, M. Montpetit, N. Murray. August 2016. (Format: TXT=104192 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7933) 7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July 2016. (Format: TXT=37124 bytes) (Also BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934) 7935 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure. G. Huston, G. Michaelson, Ed.. August 2016. (Format: TXT=17952 bytes) (Obsoletes RFC6485) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7935) 7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry. T. Hardie. July 2016. (Format: TXT=4873 bytes) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7936) 7937 Content Distribution Network Interconnection (CDNI) Logging Interface. F. Le Faucheur, Ed., G. Bertrand, Ed., I. Oprescu, Ed., R. Peterkofsky. August 2016. (Format: TXT=139040 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7937) 7938 Use of BGP for Routing in Large-Scale Data Centers. P. Lapukhov, A. Premji, J. Mitchell, Ed.. August 2016. (Format: TXT=89682 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7938) 7939 Definition of Managed Objects for the Neighborhood Discovery Protocol. U. Herberg, R. Cole, I. Chakeres, T. Clausen. August 2016. (Format: TXT=140619 bytes) (Obsoletes RFC6779) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7939) 7940 Representing Label Generation Rulesets Using XML. K. Davies, A. Freytag. August 2016. (Format: TXT=170416 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7940) 7941 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items. M. Westerlund, B. Burman, R. Even, M. Zanaty. August 2016. (Format: TXT=39887 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7941) 7942 Improving Awareness of Running Code: The Implementation Status Section. Y. Sheffer, A. Farrel. July 2016. (Format: TXT=17273 bytes) (Obsoletes RFC6982) (Also BCP0205) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7942) 7943 A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). F. Gont, W. Liu. September 2016. (Format: TXT=21161 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7943) 7944 Diameter Routing Message Priority. S. Donovan. August 2016. (Format: TXT=41028 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7944) 7945 Information-Centric Networking: Evaluation and Security Considerations. K. Pentikousis, Ed., B. Ohlman, E. Davies, S. Spirou, G. Boggia. September 2016. (Format: TXT=95970 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7945) 7946 The GeoJSON Format. H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. August 2016. (Format: TXT=49143 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7946) 7947 Internet Exchange BGP Route Server. E. Jasinska, N. Hilliard, R. Raszuk, N. Bakker. September 2016. (Format: TXT=26589 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7947) 7948 Internet Exchange BGP Route Server Operations. N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker. September 2016. (Format: TXT=36787 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7948) 7949 OSPFv3 over IPv4 for IPv6 Transition. I. Chen, A. Lindem, R. Atkinson. August 2016. (Format: TXT=25554 bytes) (Updates RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7949) 7950 The YANG 1.1 Data Modeling Language. M. Bjorklund, Ed.. August 2016. (Format: TXT=393155 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7950) 7951 JSON Encoding of Data Modeled with YANG. L. Lhotka. August 2016. (Format: TXT=32316 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7951) 7952 Defining and Using Metadata with YANG. L. Lhotka. August 2016. (Format: TXT=35394 bytes) (Updates RFC6110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7952) 7953 Calendar Availability. C. Daboo, M. Douglass. August 2016. (Format: TXT=47971 bytes) (Updates RFC4791, RFC5545, RFC6638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7953) 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block. L. Iannone, D. Lewis, D. Meyer, V. Fuller. September 2016. (Format: TXT=26522 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7954) 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block. L. Iannone, R. Jorgensen, D. Conrad, G. Huston. September 2016. (Format: TXT=19607 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7955) 7956 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway. W. Hao, Y. Li, A. Qu, M. Durrani, P. Sivamurugan. September 2016. (Format: TXT=62104 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7956) 7957 DISPATCH-Style Working Groups and the SIP Change Process. B. Campbell, Ed., A. Cooper, B. Leiba. August 2016. (Format: TXT=12097 bytes) (Updates RFC5727) (Also BCP0067) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7957) 7958 DNSSEC Trust Anchor Publication for the Root Zone. J. Abley, J. Schlyter, G. Bailey, P. Hoffman. August 2016. (Format: TXT=26072 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7958) 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP). C. Bormann, Z. Shelby, Ed.. August 2016. (Format: TXT=87515 bytes) (Updates RFC7252) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7959) 7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows. F. Martin, Ed., E. Lear, Ed., T. Draegen. Ed., E. Zwicky, Ed., K. Andersen, Ed.. September 2016. (Format: TXT=58739 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7960) 7961 Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV. D. Eastlake 3rd, L. Yizhou. August 2016. (Format: TXT=50012 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7961) 7962 Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures. J. Saldana, Ed., A. Arcia-Moret, B. Braem, E. Pietrosemoli, A. Sathiaseelan, M. Zennaro. August 2016. (Format: TXT=97574 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7962) 7963 RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs). Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. August 2016. (Format: TXT=8665 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7963) 7964 Solutions for BGP Persistent Route Oscillation. D. Walton, A. Retana, E. Chen, J. Scudder. September 2016. (Format: TXT=19774 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7964) 7965 LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels. M. Chen, W. Cao, A. Takacs, P. Pan. August 2016. (Format: TXT=38557 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7965) 7966 Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements. H. Tschofenig, J. Korhonen, Ed., G. Zorn, K. Pillay. September 2016. (Format: TXT=22186 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7966) 7967 Constrained Application Protocol (CoAP) Option for No Server Response. A. Bhattacharyya, S. Bandyopadhyay, A. Pal, T. Bose. August 2016. (Format: TXT=40314 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7967) 7968 Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data. Y. Li, D. Eastlake 3rd, W. Hao, H. Chen, S. Chatterjee. August 2016. (Format: TXT=47260 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7968) 7969 Customizing DHCP Configuration on the Basis of Network Topology. T. Lemon, T. Mrugalski. October 2016. (Format: TXT=46674 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7969) 7970 The Incident Object Description Exchange Format Version 2. R. Danyliw. November 2016. (Format: TXT=331061 bytes) (Obsoletes RFC5070, RFC6685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7970) 7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations. M. Stiemerling, S. Kiesel, M. Scharf, H. Seidel, S. Previdi. October 2016. (Format: TXT=188372 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7971) 7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. September 2016. (Format: TXT=17603 bytes) (Obsoletes RFC7302) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7972) 7973 Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation. R. Droms, P. Duffy. November 2016. (Format: TXT=8208 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7973) 7974 An Experimental TCP Option for Host Identification. B. Williams, M. Boucadair, D. Wing. October 2016. (Format: TXT=48381 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7974) 7975 Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection. B. Niven-Jenkins, Ed., R. van Brandenburg, Ed.. October 2016. (Format: TXT=75830 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7975) 7976 Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses. C. Holmberg, N. Biondic, G. Salgueiro. September 2016. (Format: TXT=17246 bytes) (Updates RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7976) 7977 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP). P. Dunkley, G. Llewellyn, V. Pascual, G. Salgueiro, R. Ravindranath. September 2016. (Format: TXT=52078 bytes) (Updates RFC4975, RFC4976) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7977) 7978 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension. D. Eastlake 3rd, M. Umair, Y. Li. September 2016. (Format: TXT=54617 bytes) (Updates RFC7178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7978) 7979 Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries. E. Lear, Ed., R. Housley, Ed.. August 2016. (Format: TXT=81587 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7979) 7980 A Framework for Defining Network Complexity. M. Behringer, A. Retana, R. White, G. Huston. October 2016. (Format: TXT=56510 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7980) 7981 IS-IS Extensions for Advertising Router Information. L. Ginsberg, S. Previdi, M. Chen. October 2016. (Format: TXT=20235 bytes) (Obsoletes RFC4971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7981) 7982 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN). P. Martinsen, T. Reddy, D. Wing, V. Singh. September 2016. (Format: TXT=19893 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7982) 7983 Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS). M. Petit-Huguenin, G. Salgueiro. September 2016. (Format: TXT=24894 bytes) (Updates RFC5764) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7983) 7984 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network. O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed.. September 2016. (Format: TXT=21246 bytes) (Updates RFC3263) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7984) 7985 Security Threats to Simplified Multicast Forwarding (SMF). J. Yi, T. Clausen, U. Herberg. November 2016. (Format: TXT=35822 bytes) (Updates RFC7186) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7985) 7986 New Properties for iCalendar. C. Daboo. October 2016. (Format: TXT=45686 bytes) (Updates RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7986) 7987 IS-IS Minimum Remaining Lifetime. L. Ginsberg, P. Wells, B. Decraene, T. Przygienda, H. Gredler. October 2016. (Format: TXT=18295 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7987) 7988 Ingress Replication Tunnels in Multicast VPN. E. Rosen, Ed., K. Subramanian, Z. Zhang. October 2016. (Format: TXT=55979 bytes) (Updates RFC6513, RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7988) 7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks. P. Jones, G. Salgueiro, C. Pearce, P. Giralt. October 2016. (Format: TXT=103241 bytes) (Obsoletes RFC7329) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7989) 7990 RFC Format Framework. H. Flanagan. December 2016. (Format: TXT=34192 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7990) 7991 The "xml2rfc" Version 3 Vocabulary. P. Hoffman. December 2016. (Format: TXT=221812 bytes) (Obsoletes RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7991) 7992 HTML Format for RFCs. J. Hildebrand, Ed., P. Hoffman. December 2016. (Format: TXT=76975 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7992) 7993 Cascading Style Sheets (CSS) Requirements for RFCs. H. Flanagan. December 2016. (Format: TXT=18990 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7993) 7994 Requirements for Plain-Text RFCs. H. Flanagan. December 2016. (Format: TXT=15393 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7994) 7995 PDF Format for RFCs. T. Hansen, Ed., L. Masinter, M. Hardy. December 2016. (Format: TXT=44720 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7995) 7996 SVG Drawings for RFCs: SVG 1.2 RFC. N. Brownlee. December 2016. (Format: TXT=102678 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7996) 7997 The Use of Non-ASCII Characters in RFCs. H. Flanagan, Ed.. December 2016. (Format: TXT=27637, PDF=96351 bytes) (Updates RFC7322) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7997) 7998 "xml2rfc" Version 3 Preparation Tool Description. P. Hoffman, J. Hildebrand. December 2016. (Format: TXT=38779 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7998) 7999 BLACKHOLE Community. T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins. October 2016. (Format: TXT=16794 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7999) 8000 Requirements for NFSv4 Multi-Domain Namespace Deployment. A. Adamson, N. Williams. November 2016. (Format: TXT=39064 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8000) 8001 RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information. F. Zhang, Ed., O. Gonzalez de Dios, Ed., C. Margaria, M. Hartley, Z. Ali. January 2017. (Format: TXT=34732 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8001) 8002 Host Identity Protocol Certificates. T. Heer, S. Varjonen. October 2016. (Format: TXT=26613 bytes) (Obsoletes RFC6253) (Updates RFC7401) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8002) 8003 Host Identity Protocol (HIP) Registration Extension. J. Laganier, L. Eggert. October 2016. (Format: TXT=34717 bytes) (Obsoletes RFC5203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8003) 8004 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. October 2016. (Format: TXT=30487 bytes) (Obsoletes RFC5204) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8004) 8005 Host Identity Protocol (HIP) Domain Name System (DNS) Extension. J. Laganier. October 2016. (Format: TXT=39146 bytes) (Obsoletes RFC5205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8005) 8006 Content Delivery Network Interconnection (CDNI) Metadata. B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma. December 2016. (Format: TXT=126524 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8006) 8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers. R. Murray, B. Niven-Jenkins. December 2016. (Format: TXT=90108 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8007) 8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics. J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K. Ma. December 2016. (Format: TXT=61956 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8008) 8009 AES Encryption with HMAC-SHA2 for Kerberos 5. M. Jenkins, M. Peck, K. Burgin. October 2016. (Format: TXT=34935 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8009) 8010 Internet Printing Protocol/1.1: Encoding and Transport. M. Sweet, I. McDonald. January 2017. (Format: TXT=115605 bytes) (Obsoletes RFC2910, RFC3382) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8010) 8011 Internet Printing Protocol/1.1: Model and Semantics. M. Sweet, I. McDonald. January 2017. (Format: TXT=535490 bytes) (Obsoletes RFC2911, RFC3381, RFC3382) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8011) 8012 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs). N. Akiya, G. Swallow, C. Pignataro, A. Malis, S. Aldrin. November 2016. (Format: TXT=49577 bytes) (Updates RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8012) 8014 An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3). D. Black, J. Hudson, L. Kreeger, M. Lasserre, T. Narten. December 2016. (Format: TXT=89975 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8014) 8015 RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics. V. Singh, C. Perkins, A. Clark, R. Huang. November 2016. (Format: TXT=29547 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8015) 8016 Mobility with Traversal Using Relays around NAT (TURN). T. Reddy, D. Wing, P. Patil, P. Martinsen. November 2016. (Format: TXT=29313 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8016) 8017 PKCS #1: RSA Cryptography Specifications Version 2.2. K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch. November 2016. (Format: TXT=154696 bytes) (Obsoletes RFC3447) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8017) 8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks. Y. Nir, V. Smyslov. November 2016. (Format: TXT=78293 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8019) 8020 NXDOMAIN: There Really Is Nothing Underneath. S. Bortzmeyer, S. Huque. November 2016. (Format: TXT=22301 bytes) (Updates RFC1034, RFC2308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8020) 8021 Generation of IPv6 Atomic Fragments Considered Harmful. F. Gont, W. Liu, T. Anderson. January 2017. (Format: TXT=25686 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8021) 8022 A YANG Data Model for Routing Management. L. Lhotka, A. Lindem. November 2016. (Format: TXT=115083 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8022) 8023 Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions. M. Thomas, A. Mankin, L. Zhang. November 2016. (Format: TXT=41899 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8023) 8024 Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS. Y. Jiang, Ed., Y. Luo, E. Mallette, Ed., Y. Shen, W. Cheng. November 2016. (Format: TXT=33671 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8024) 8025 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch. P. Thubert, Ed., R. Cragie. November 2016. (Format: TXT=16342 bytes) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8025) 8026 Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism. M. Boucadair, I. Farrer. November 2016. (Format: TXT=22857 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8026) 8027 DNSSEC Roadblock Avoidance. W. Hardaker, O. Gudmundsson, S. Krishnaswamy. November 2016. (Format: TXT=40173 bytes) (Also BCP0207) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8027) 8028 First-Hop Router Selection by Hosts in a Multi-Prefix Network. F. Baker, B. Carpenter. November 2016. (Format: TXT=30987 bytes) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8028) 8030 Generic Event Delivery Using HTTP Push. M. Thomson, E. Damaggio, B. Raymor, Ed.. December 2016. (Format: TXT=68069 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8030) 8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement. Y. Nir, S. Josefsson. December 2016. (Format: TXT=14969 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8031) 8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing. C. Holmberg. November 2016. (Format: TXT=11915 bytes) (Updates RFC5761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8035) 8036 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks. N. Cam-Winget, Ed., J. Hui, D. Popa. January 2017. (Format: TXT=58383 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8036) 8039 Multipath Time Synchronization. A. Shpiner, R. Tse, C. Schelp, T. Mizrahi. December 2016. (Format: TXT=39763 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8039) 8041 Use Cases and Operational Experience with Multipath TCP. O. Bonaventure, C. Paasch, G. Detal. January 2017. (Format: TXT=75260 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8041) 8042 OSPF Two-Part Metric. Z. Zhang, L. Wang, A. Lindem. December 2016. (Format: TXT=18496 bytes) (Updates RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8042) 8043 Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space. B. Sarikaya, M. Boucadair. January 2017. (Format: TXT=35213 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8043) 8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence. P. Saint-Andre. December 2016. (Format: TXT=71355 bytes) (Obsoletes RFC7248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8048) 8051 Applicability of a Stateful Path Computation Element (PCE). X. Zhang, Ed., I. Minei, Ed.. January 2017. (Format: TXT=58011 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8051) 8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping. J. Gould. January 2017. (Format: TXT=22084 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8056) 8057 Uniform Resource Name (URN) Namespaces for Broadband Forum. B. Stark, D. Sinicrope, W. Lupton. January 2017. (Format: TXT=17889 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8057) 8058 Signaling One-Click Functionality for List Email Headers. J. Levine, T. Herkula. January 2017. (Format: TXT=18219 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8058) 8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments. J. Arango, S. Venaas, I. Kouvelas, D. Farinacci. January 2017. (Format: TXT=19562 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8059) ./rfc-index.xml0000664000764400076440005405416313041627406012777 0ustar iustyiusty BCP0001 BCP0002 BCP0003 RFC1915 BCP0004 RFC1917 BCP0005 RFC1918 BCP0006 RFC1930 RFC6996 RFC7300 BCP0007 RFC2008 BCP0008 RFC2014 BCP0009 RFC2026 RFC5657 RFC6410 RFC7100 RFC7127 RFC7475 BCP0010 RFC7437 BCP0011 RFC2028 BCP0012 BCP0013 RFC4289 RFC6838 BCP0014 RFC2119 BCP0015 RFC2148 BCP0016 RFC2182 BCP0017 RFC2219 BCP0018 RFC2277 BCP0019 RFC2978 BCP0020 RFC2317 BCP0021 RFC2350 BCP0022 RFC2360 BCP0023 RFC2365 BCP0024 RFC2379 BCP0025 RFC2418 RFC3934 RFC7776 BCP0026 RFC5226 BCP0027 RFC2438 BCP0028 RFC2488 BCP0029 RFC2489 BCP0030 RFC2505 BCP0031 RFC2506 BCP0032 RFC2606 BCP0033 RFC2611 BCP0034 RFC2644 BCP0035 RFC7595 BCP0036 RFC2736 BCP0037 RFC2780 RFC5237 BCP0038 RFC2827 BCP0039 RFC2850 BCP0040 RFC7720 BCP0041 RFC2914 RFC7141 BCP0042 RFC6895 BCP0043 RFC2939 BCP0044 RFC2964 BCP0045 RFC3005 BCP0046 RFC3013 BCP0047 RFC4647 RFC5646 BCP0048 RFC3150 BCP0049 RFC3152 BCP0050 RFC3155 BCP0051 RFC5771 BCP0052 RFC3172 BCP0053 RFC3180 BCP0054 RFC7154 BCP0055 RFC3227 BCP0056 RFC3205 BCP0057 RFC3228 BCP0058 RFC3233 BCP0059 RFC3349 BCP0060 RFC3360 BCP0061 RFC3365 BCP0062 RFC3366 BCP0063 RFC3372 BCP0064 RFC4520 BCP0065 RFC3405 BCP0066 RFC3406 BCP0067 RFC5727 RFC7957 BCP0068 RFC3438 BCP0069 RFC3449 BCP0070 RFC3470 BCP0071 RFC3481 BCP0072 RFC3552 BCP0073 RFC3553 BCP0074 RFC3584 BCP0075 RFC3665 BCP0076 RFC3666 BCP0077 RFC3677 BCP0078 RFC5378 BCP0079 RFC3979 RFC4879 BCP0080 RFC3681 BCP0081 RFC3688 BCP0082 RFC3692 BCP0083 RFC3683 BCP0084 RFC3704 BCP0085 RFC3725 BCP0086 RFC3766 BCP0087 RFC3785 BCP0088 RFC3818 BCP0089 RFC3819 BCP0090 RFC3864 BCP0091 RFC3901 BCP0092 RFC5742 BCP0093 RFC3933 BCP0094 BCP0095 RFC3935 BCP0096 RFC3936 BCP0097 RFC3967 RFC4897 BCP0098 RFC3968 BCP0099 RFC3969 BCP0100 RFC7120 BCP0101 RFC4071 RFC4371 RFC7691 BCP0102 RFC4052 BCP0103 RFC4053 BCP0104 RFC4084 BCP0105 RFC4085 BCP0106 RFC4086 BCP0107 RFC4107 BCP0108 RFC4148 BCP0109 RFC4159 BCP0110 RFC4170 BCP0111 RFC4181 RFC4841 BCP0112 RFC4222 BCP0113 RFC4333 BCP0114 RFC4384 BCP0115 BCP0116 RFC4446 BCP0117 RFC4497 BCP0118 RFC4521 BCP0119 RFC4579 BCP0120 RFC4608 BCP0121 RFC4611 BCP0122 RFC4632 BCP0123 RFC4697 BCP0124 RFC4774 BCP0125 RFC4775 BCP0126 RFC4786 BCP0127 RFC4787 RFC6888 RFC7857 BCP0128 RFC4928 BCP0129 RFC4929 BCP0130 RFC4940 BCP0131 RFC4961 BCP0132 RFC4962 BCP0133 RFC5033 BCP0134 RFC5068 BCP0135 RFC5135 BCP0136 RFC5266 BCP0137 RFC5137 BCP0138 RFC5248 BCP0139 RFC5249 BCP0140 RFC5358 BCP0141 RFC7042 BCP0142 RFC5382 BCP0143 RFC5383 BCP0144 RFC5359 BCP0145 RFC5405 BCP0146 RFC5406 BCP0147 RFC5407 BCP0148 RFC5508 BCP0149 RFC5589 BCP0150 RFC5597 BCP0151 RFC5615 BCP0152 RFC5625 BCP0153 RFC6598 RFC6890 BCP0154 RFC5774 BCP0155 RFC5855 BCP0156 RFC6056 BCP0157 RFC6177 BCP0158 RFC6158 BCP0159 RFC6191 BCP0160 RFC6280 BCP0161 RFC6291 BCP0162 RFC6302 BCP0163 RFC6303 RFC7793 BCP0164 RFC6328 BCP0165 RFC6335 RFC7605 BCP0166 RFC6365 BCP0167 RFC6377 BCP0168 RFC6398 BCP0169 RFC6382 BCP0170 RFC6390 BCP0171 RFC6441 BCP0172 RFC6472 BCP0173 RFC6484 RFC7382 BCP0174 RFC6489 BCP0175 RFC6557 BCP0176 RFC6576 BCP0177 RFC6540 BCP0178 RFC6648 BCP0179 RFC6649 BCP0180 RFC6853 BCP0181 RFC6881 BCP0182 RFC6916 BCP0183 RFC6963 BCP0184 RFC7013 BCP0185 RFC7115 BCP0186 RFC7126 BCP0187 RFC7227 BCP0188 RFC7258 BCP0189 RFC7279 BCP0190 RFC7320 BCP0191 RFC7319 BCP0193 RFC7423 BCP0194 RFC7454 BCP0195 RFC7525 BCP0196 RFC7526 BCP0197 RFC7567 BCP0198 RFC7608 BCP0199 RFC7610 BCP0200 RFC1984 BCP0201 RFC7696 BCP0202 RFC7772 BCP0203 RFC7803 BCP0204 RFC7934 BCP0205 RFC7942 BCP0206 RFC7926 BCP0207 RFC8027 FYI0002 RFC1470 FYI0003 RFC1175 FYI0004 RFC2664 FYI0005 RFC1178 FYI0006 RFC1198 FYI0007 RFC1207 FYI0008 RFC2196 FYI0009 RFC1336 FYI0010 RFC1402 FYI0011 RFC2116 FYI0012 RFC1302 FYI0013 RFC1308 FYI0014 RFC1309 FYI0015 RFC1355 FYI0016 RFC1359 FYI0018 RFC1983 FYI0019 RFC1463 FYI0020 RFC1462 FYI0021 RFC1491 FYI0022 RFC1941 FYI0023 RFC1580 FYI0024 RFC1635 FYI0025 RFC1689 FYI0026 RFC1709 FYI0027 RFC1713 FYI0028 RFC1855 FYI0029 RFC2007 FYI0030 RFC2151 FYI0031 RFC2150 FYI0032 RFC2235 FYI0033 RFC2398 FYI0034 RFC2504 FYI0035 RFC2635 FYI0036 RFC4949 FYI0037 RFC2901 FYI0038 RFC3098 RFC0001 Host Software S. Crocker April 1969 ASCII 21088 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0001 RFC0002 Host software B. Duvall April 1969 ASCII 17145 10 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=2 10.17487/RFC0002 RFC0003 Documentation conventions S.D. Crocker April 1969 ASCII 2323 2 RFC0010 UNKNOWN UNKNOWN Legacy 10.17487/RFC0003 RFC0004 Network timetable E.B. Shapiro March 1969 ASCII 5933 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0004 RFC0005 Decode Encode Language (DEL) J. Rulifson June 1969 ASCII 26408 17 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=5 10.17487/RFC0005 RFC0006 Conversation with Bob Kahn S.D. Crocker April 1969 ASCII 1568 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0006 RFC0007 Host-IMP interface G. Deloche May 1969 ASCII 13408 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0007 RFC0008 ARPA Network Functional Specifications G. Deloche May 1969 PDF 750612 UNKNOWN UNKNOWN Legacy 10.17487/RFC0008 RFC0009 Host Software G. Deloche May 1969 PDF 722638 UNKNOWN UNKNOWN Legacy 10.17487/RFC0009 RFC0010 Documentation conventions S.D. Crocker July 1969 ASCII 3348 3 RFC0003 RFC0016 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0010 RFC0011 Implementation of the Host - Host Software Procedures in GORDO G. Deloche August 1969 ASCII 46971 23 PDF 2186431 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0011 RFC0012 IMP-Host interface flow diagrams M. Wingfield August 1969 ASCII 177 1 PS 1489750 PDF 1163721 UNKNOWN UNKNOWN Legacy 10.17487/RFC0012 RFC0013 Zero Text Length EOF Message V. Cerf August 1969 ASCII 1070 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0013 RFC0014 RFC0015 Network subsystem for time sharing hosts C.S. Carr September 1969 ASCII 10695 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0015 RFC0016 M.I.T S. Crocker August 1969 ASCII 682 1 RFC0010 RFC0024 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0016 RFC0017 Some questions re: Host-IMP Protocol J.E. Kreznar August 1969 ASCII 6065 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0017 RFC0018 IMP-IMP and HOST-HOST Control Links V. Cerf September 1969 ASCII 634 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0018 RFC0019 Two protocol suggestions to reduce congestion at swap bound nodes J.E. Kreznar October 1969 ASCII 3392 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0019 RFC0020 ASCII format for network interchange V.G. Cerf October 1969 ASCII 18504 9 PDF 197096 STD0080 INTERNET STANDARD UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=20 10.17487/RFC0020 RFC0021 Network meeting V.G. Cerf October 1969 ASCII 2143 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0021 RFC0022 Host-host control message formats V.G. Cerf October 1969 ASCII 4606 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0022 RFC0023 Transmission of Multiple Control Messages G. Gregg October 1969 ASCII 690 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0023 RFC0024 Documentation Conventions S.D. Crocker November 1969 ASCII 3460 3 RFC0016 RFC0010 RFC0016 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0024 RFC0025 No High Link Numbers S.D. Crocker October 1969 ASCII 479 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0025 RFC0026 RFC0027 Documentation Conventions S.D. Crocker December 1969 ASCII 3661 3 RFC0010 RFC0016 RFC0024 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0027 RFC0028 Time Standards W.K. English January 1970 ASCII 557 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0028 RFC0029 Response to RFC 28 R.E. Kahn January 1970 ASCII 790 1 RFC0028 UNKNOWN UNKNOWN Legacy 10.17487/RFC0029 RFC0030 Documentation Conventions S.D. Crocker February 1970 ASCII 4041 3 RFC0010 RFC0016 RFC0024 RFC0027 UNKNOWN UNKNOWN Legacy 10.17487/RFC0030 RFC0031 Binary Message Forms in Computer D. Bobrow W.R. Sutherland February 1968 ASCII 11191 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=31 10.17487/RFC0031 RFC0032 Some Thoughts on SRI's Proposed Real Time Clock J. Cole February 1970 ASCII 2216 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0032 RFC0033 New Host-Host Protocol S.D. Crocker February 1970 ASCII 44167 19 RFC0011 RFC0036 RFC0047 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=33 10.17487/RFC0033 RFC0034 Some Brief Preliminary Notes on the Augmentation Research Center Clock W.K. English February 1970 ASCII 2534 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0034 RFC0035 Network Meeting S.D. Crocker March 1970 ASCII 1282 1 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0035 RFC0036 Protocol Notes S.D. Crocker March 1970 ASCII 13893 8 RFC0033 RFC0039 RFC0044 UNKNOWN UNKNOWN Legacy 10.17487/RFC0036 RFC0037 Network Meeting Epilogue, etc S.D. Crocker March 1970 ASCII 9107 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0037 RFC0038 Comments on Network Protocol from NWG/RFC #36 S.M. Wolfe March 1970 ASCII 2536 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0038 RFC0039 Comments on Protocol Re: NWG/RFC #36 E. Harslem J.F. Heafner March 1970 ASCII 4779 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0039 RFC0040 More Comments on the Forthcoming Protocol E. Harslem J.F. Heafner March 1970 ASCII 3825 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0040 RFC0041 IMP-IMP Teletype Communication J.T. Melvin March 1970 ASCII 1038 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0041 RFC0042 Message Data Types E. Ancona March 1970 ASCII 5247 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0042 RFC0043 Proposed Meeting A.G. Nemeth April 1970 ASCII 1600 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0043 RFC0044 Comments on NWG/RFC 33 and 36 A. Shoshani R. Long A. Landsberg April 1970 ASCII 7381 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0044 RFC0045 New Protocol is Coming J. Postel S.D. Crocker April 1970 ASCII 1130 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0045 RFC0046 ARPA Network protocol notes E. Meyer April 1970 ASCII 41338 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0046 RFC0047 BBN's Comments on NWG/RFC #33 J. Postel S. Crocker April 1970 ASCII 5343 4 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0047 RFC0048 Possible protocol plateau J. Postel S.D. Crocker April 1970 ASCII 41696 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0048 RFC0049 Conversations with S. Crocker (UCLA) E. Meyer April 1970 ASCII 12384 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0049 RFC0050 Comments on the Meyer Proposal E. Harslen J. Heafner April 1970 ASCII 4070 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0050 RFC0051 Proposal for a Network Interchange Language M. Elie May 1970 PDF 967411 UNKNOWN UNKNOWN Legacy 10.17487/RFC0051 RFC0052 Updated distribution list J. Postel S.D. Crocker July 1970 ASCII 5088 3 RFC0069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0052 RFC0053 Official protocol mechanism S.D. Crocker June 1970 ASCII 2330 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0053 RFC0054 Official Protocol Proffering S.D. Crocker J. Postel J. Newkirk M. Kraley June 1970 ASCII 20131 9 RFC0057 UNKNOWN UNKNOWN Legacy 10.17487/RFC0054 RFC0055 Prototypical implementation of the NCP J. Newkirk M. Kraley J. Postel S.D. Crocker June 1970 ASCII 48070 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0055 RFC0056 Third Level Protocol: Logger Protocol E. Belove D. Black R. Flegal L.G. Farquar June 1970 ASCII 13066 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0056 RFC0057 Thoughts and Reflections on NWG/RFC 54 M. Kraley J. Newkirk June 1970 ASCII 8360 5 RFC0054 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=57 10.17487/RFC0057 RFC0058 Logical Message Synchronization T.P. Skinner June 1970 ASCII 3767 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0058 RFC0059 Flow Control - Fixed Versus Demand Allocation E. Meyer June 1970 ASCII 17691 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=59 10.17487/RFC0059 RFC0060 A Simplified NCP Protocol R. Kalin July 1970 ASCII 18694 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0060 RFC0061 Note on Interprocess Communication in a Resource Sharing Computer Network D.C. Walden July 1970 ASCII 43946 18 RFC0062 UNKNOWN UNKNOWN Legacy 10.17487/RFC0061 RFC0062 Systems for Interprocess Communication in a Resource Sharing Computer Network D.C. Walden August 1970 ASCII 55784 20 RFC0061 UNKNOWN UNKNOWN Legacy 10.17487/RFC0062 RFC0063 Belated Network Meeting Report V.G. Cerf July 1970 ASCII 2961 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0063 RFC0064 Getting rid of marking M. Elie July 1970 ASCII 7556 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0064 RFC0065 Comments on Host/Host Protocol document #1 D.C. Walden August 1970 ASCII 5628 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0065 RFC0066 NIC - third level ideas and other noise S.D. Crocker August 1970 ASCII 4575 3 RFC0123 RFC0080 RFC0093 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=66 10.17487/RFC0066 RFC0067 Proposed Change to Host/IMP Spec to Eliminate Marking W.R. Crowther January 1970 ASCII 1534 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0067 RFC0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM M. Elie August 1970 ASCII 5041 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0068 RFC0069 Distribution List Change for MIT A.K. Bhushan September 1970 ASCII 841 1 RFC0052 UNKNOWN UNKNOWN Legacy 10.17487/RFC0069 RFC0070 Note on Padding S.D. Crocker October 1970 ASCII 12790 9 RFC0228 UNKNOWN UNKNOWN Legacy 10.17487/RFC0070 RFC0071 Reallocation in Case of Input Error T. Schipper September 1970 ASCII 1265 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0071 RFC0072 Proposed Moratorium on Changes to Network Protocol R.D. Bressler September 1970 ASCII 4047 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0072 RFC0073 Response to NWG/RFC 67 S.D. Crocker September 1970 ASCII 1268 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0073 RFC0074 Specifications for Network Use of the UCSB On-Line System J.E. White October 1970 ASCII 21368 9 PDF 521403 RFC0217 RFC0225 UNKNOWN UNKNOWN Legacy 10.17487/RFC0074 RFC0075 Network Meeting S.D. Crocker October 1970 ASCII 1318 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0075 RFC0076 Connection by name: User oriented protocol J. Bouknight J. Madden G.R. Grossman October 1970 ASCII 26504 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0076 RFC0077 Network meeting report J. Postel November 1970 ASCII 19196 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0077 RFC0078 NCP Status Report: UCSB/Rand E. Harslem J.F. Heafner J.E. White October 1970 ASCII 1303 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0078 RFC0079 Logger Protocol error E. Meyer November 1970 ASCII 1515 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0079 RFC0080 Protocols and Data Formats E. Harslem J.F. Heafner December 1970 ASCII 17620 9 RFC0123 RFC0066 RFC0093 UNKNOWN UNKNOWN Legacy 10.17487/RFC0080 RFC0081 Request for Reference Information J. Bouknight December 1970 ASCII 956 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0081 RFC0082 Network Meeting Notes E. Meyer December 1970 ASCII 38023 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0082 RFC0083 Language-machine for data reconfiguration R.H. Anderson E. Harslem J.F. Heafner December 1970 ASCII 22253 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0083 RFC0084 List of NWG/RFC's 1-80 J.B. North December 1970 ASCII 12613 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0084 RFC0085 Network Working Group meeting S.D. Crocker December 1970 ASCII 1547 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0085 RFC0086 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display S.D. Crocker January 1971 ASCII 7103 6 RFC0125 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=86 10.17487/RFC0086 RFC0087 Topic for Discussion at the Next Network Working Group Meeting A. Vezza January 1971 ASCII 3593 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0087 RFC0088 NETRJS: A third level protocol for Remote Job Entry R.T. Braden S.M. Wolfe January 1971 ASCII 19691 9 RFC0189 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=88 10.17487/RFC0088 RFC0089 Some historic moments in networking R.M. Metcalfe January 1971 ASCII 16832 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=89 10.17487/RFC0089 RFC0090 CCN as a Network Service Center R.T. Braden January 1971 ASCII 11929 6 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=90 10.17487/RFC0090 RFC0091 Proposed User-User Protocol G.H. Mealy December 1970 ASCII 27005 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0091 RFC0092 RFC0093 Initial Connection Protocol A.M. McKenzie January 1971 ASCII 1746 1 RFC0066 RFC0080 UNKNOWN UNKNOWN Legacy 10.17487/RFC0093 RFC0094 Some thoughts on Network Graphics E. Harslem J.F. Heafner February 1971 ASCII 13516 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0094 RFC0095 Distribution of NWG/RFC's through the NIC S. Crocker February 1971 ASCII 8692 5 RFC0155 UNKNOWN UNKNOWN Legacy 10.17487/RFC0095 RFC0096 An Interactive Network Experiment to Study Modes of Access the Network Information Center R.W. Watson February 1971 ASCII 11334 5 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0096 RFC0097 First Cut at a Proposed Telnet Protocol J.T. Melvin R.W. Watson February 1971 ASCII 24034 11 PDF 403375 UNKNOWN UNKNOWN Legacy 10.17487/RFC0097 RFC0098 Logger Protocol Proposal E. Meyer T. Skinner February 1971 ASCII 24536 10 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0098 RFC0099 Network Meeting P.M. Karp February 1971 ASCII 1010 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0099 RFC0100 Categorization and guide to NWG/RFCs P.M. Karp February 1971 ASCII 62473 37 UNKNOWN UNKNOWN Legacy 10.17487/RFC0100 RFC0101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971 R.W. Watson February 1971 ASCII 30343 14 RFC0108 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0101 RFC0102 Output of the Host-Host Protocol glitch cleaning committee S.D. Crocker February 1971 ASCII 8511 4 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0102 RFC0103 Implementation of Interrupt Keys R.B. Kalin February 1971 ASCII 7592 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0103 RFC0104 Link 191 J.B. Postel S.D. Crocker February 1971 ASCII 1017 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0104 RFC0105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB J.E. White March 1971 ASCII 21938 9 RFC0217 UNKNOWN UNKNOWN Legacy 10.17487/RFC0105 RFC0106 User/Server Site Protocol Network Host Questionnaire T.C. O'Sullivan March 1971 ASCII 6946 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0106 RFC0107 Output of the Host-Host Protocol Glitch Cleaning Committee R.D. Bressler S.D. Crocker W.R. Crowther G.R. Grossman R.S. Tomlinson J.E. White March 1971 ASCII 18109 12 RFC0102 RFC0111 RFC0124 RFC0132 RFC0154 RFC0179 UNKNOWN UNKNOWN Legacy 10.17487/RFC0107 RFC0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971 R.W. Watson March 1971 ASCII 1597 2 RFC0101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0108 RFC0109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host J. Winett March 1971 ASCII 27716 12 PDF 645921 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0109 RFC0110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts J. Winett March 1971 ASCII 8586 4 PDF 738470 RFC0135 UNKNOWN UNKNOWN Legacy 10.17487/RFC0110 RFC0111 Pressure from the Chairman S.D. Crocker March 1971 ASCII 2098 2 RFC0107 RFC0130 UNKNOWN UNKNOWN Legacy 10.17487/RFC0111 RFC0112 User/Server Site Protocol: Network Host Questionnaire T.C. O'Sullivan April 1971 ASCII 1465 1 PDF 347370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0112 RFC0113 Network activity report: UCSB Rand E. Harslem J.F. Heafner J.E. White April 1971 ASCII 3442 2 RFC0227 UNKNOWN UNKNOWN Legacy 10.17487/RFC0113 RFC0114 File Transfer Protocol A.K. Bhushan April 1971 ASCII 38981 17 FTP RFC0133 RFC0141 RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0114 RFC0115 Some Network Information Center policies on handling documents R.W. Watson J.B. North April 1971 ASCII 16775 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0115 RFC0116 Structure of the May NWG Meeting S.D. Crocker April 1971 ASCII 2395 1 RFC0099 RFC0131 RFC0156 UNKNOWN UNKNOWN Legacy 10.17487/RFC0116 RFC0117 Some comments on the official protocol J. Wong April 1971 ASCII 7128 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0117 RFC0118 Recommendations for facility documentation R.W. Watson April 1971 ASCII 4573 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0118 RFC0119 Network Fortran Subprograms M. Krilanovich April 1971 ASCII 39140 19 PDF 760848 UNKNOWN UNKNOWN Legacy 10.17487/RFC0119 RFC0120 Network PL1 subprograms M. Krilanovich April 1971 ASCII 37192 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0120 RFC0121 Network on-line operators M. Krilanovich April 1971 ASCII 29419 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0121 RFC0122 Network specifications for UCSB's Simple-Minded File System J.E. White April 1971 ASCII 47638 21 RFC0217 RFC0269 RFC0399 RFC0431 UNKNOWN UNKNOWN Legacy 10.17487/RFC0122 RFC0123 Proffered Official ICP S.D. Crocker April 1971 ASCII 4812 3 RFC0066 RFC0080 RFC0165 RFC0098 RFC0101 RFC0127 RFC0143 RFC0148 UNKNOWN UNKNOWN Legacy 10.17487/RFC0123 RFC0124 Typographical error in RFC 107 J.T. Melvin April 1971 ASCII 659 1 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0124 RFC0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream J. McConnell April 1971 ASCII 8133 4 RFC0086 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0125 RFC0126 Graphics Facilities at Ames Research Center J. McConnell April 1971 ASCII 1974 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0126 RFC0127 Comments on RFC 123 J. Postel April 1971 ASCII 2305 2 RFC0145 RFC0123 RFC0151 UNKNOWN UNKNOWN Legacy 10.17487/RFC0127 RFC0128 Bytes J. Postel April 1971 ASCII 2745 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0128 RFC0129 Request for comments on socket name structure E. Harslem J. Heafner E. Meyer April 1971 ASCII 11175 6 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0129 RFC0130 Response to RFC 111: Pressure from the chairman J.F. Heafner April 1971 ASCII 2580 1 RFC0111 UNKNOWN UNKNOWN Legacy 10.17487/RFC0130 RFC0131 Response to RFC 116: May NWG meeting E. Harslem J.F. Heafner April 1971 ASCII 5375 3 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0131 RFC0132 Typographical Error in RFC 107 J.E. White April 1971 ASCII 1058 1 RFC0154 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0132 RFC0133 File Transfer and Error Recovery R.L. Sunberg April 1971 ASCII 8322 4 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0133 RFC0134 Network Graphics meeting A. Vezza April 1971 ASCII 2684 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0134 RFC0135 Response to NWG/RFC 110 W. Hathaway April 1971 ASCII 5282 3 RFC0110 UNKNOWN UNKNOWN Legacy 10.17487/RFC0135 RFC0136 Host accounting and administrative procedures R.E. Kahn April 1971 ASCII 8016 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0136 RFC0137 Telnet Protocol - a proposed document T.C. O'Sullivan April 1971 ASCII 17606 11 RFC0139 UNKNOWN UNKNOWN Legacy 10.17487/RFC0137 RFC0138 Status report on proposed Data Reconfiguration Service R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood April 1971 ASCII 46641 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0138 RFC0139 Discussion of Telnet Protocol T.C. O'Sullivan May 1971 ASCII 26085 11 RFC0137 RFC0158 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0139 RFC0140 Agenda for the May NWG meeting S.D. Crocker May 1971 ASCII 6934 4 RFC0149 UNKNOWN UNKNOWN Legacy 10.17487/RFC0140 RFC0141 Comments on RFC 114: A File Transfer Protocol E. Harslem J.F. Heafner April 1971 ASCII 3781 2 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0141 RFC0142 Time-Out Mechanism in the Host-Host Protocol C. Kline J. Wong May 1971 ASCII 4372 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0142 RFC0143 Regarding proffered official ICP W. Naylor J. Wong C. Kline J. Postel May 1971 ASCII 6963 4 RFC0165 RFC0123 RFC0145 UNKNOWN UNKNOWN Legacy 10.17487/RFC0143 RFC0144 Data sharing on computer networks A. Shoshani April 1971 ASCII 13744 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0144 RFC0145 Initial Connection Protocol Control Commands J. Postel May 1971 ASCII 2490 2 PS 552114 PDF 15869 RFC0127 RFC0165 RFC0143 UNKNOWN UNKNOWN Legacy 10.17487/RFC0145 RFC0146 Views on issues relevant to data sharing on computer networks P.M. Karp D.B. McKay D.C.M. Wood May 1971 ASCII 9828 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0146 RFC0147 Definition of a socket J.M. Winett May 1971 ASCII 6438 3 RFC0129 UNKNOWN UNKNOWN Legacy 10.17487/RFC0147 RFC0148 Comments on RFC 123 A.K. Bhushan May 1971 ASCII 1149 1 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0148 RFC0149 Best Laid Plans S.D. Crocker May 1971 ASCII 1057 1 RFC0140 UNKNOWN UNKNOWN Legacy 10.17487/RFC0149 RFC0150 Use of IPC Facilities: A Working Paper R.B. Kalin May 1971 ASCII 28163 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0150 RFC0151 Comments on a proffered official ICP: RFCs 123, 127 A. Shoshani May 1971 ASCII 3623 2 RFC0127 UNKNOWN UNKNOWN Legacy 10.17487/RFC0151 RFC0152 SRI Artificial Intelligence status report M. Wilber May 1971 ASCII 2726 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0152 RFC0153 SRI ARC-NIC status J.T. Melvin R.W. Watson May 1971 ASCII 8573 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0153 RFC0154 Exposition Style S.D. Crocker May 1971 ASCII 1293 1 RFC0132 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0154 RFC0155 ARPA Network mailing lists J.B. North May 1971 ASCII 11054 13 RFC0095 RFC0168 UNKNOWN UNKNOWN Legacy 10.17487/RFC0155 RFC0156 Status of the Illinois site: Response to RFC 116 J. Bouknight April 1971 ASCII 1171 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0156 RFC0157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems V.G. Cerf May 1971 ASCII 3159 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0157 RFC0158 Telnet Protocol: A Proposed Document T.C. O'Sullivan May 1971 ASCII 21025 11 PDF 429985 RFC0495 RFC0139 RFC0318 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0158 RFC0159 RFC0160 RFC brief list Network Information Center. Stanford Research Institute May 1971 ASCII 12173 4 RFC0200 RFC0999 NIC6716 UNKNOWN UNKNOWN Legacy 10.17487/RFC0160 RFC0161 Solution to the race condition in the ICP A. Shoshani May 1971 ASCII 2026 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0161 RFC0162 NETBUGGER3 M. Kampe May 1971 ASCII 3153 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0162 RFC0163 Data transfer protocols V.G. Cerf May 1971 ASCII 5465 3 FTP DTP data manager UNKNOWN UNKNOWN Legacy 10.17487/RFC0163 RFC0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71 J.F. Heafner May 1971 ASCII 58597 32 UNKNOWN UNKNOWN Legacy 10.17487/RFC0164 RFC0165 Proffered Official Initial Connection Protocol J. Postel May 1971 ASCII 8488 5 PDF 248876 RFC0145 RFC0143 RFC0123 NIC7101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0165 RFC0166 Data Reconfiguration Service: An implementation specification R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood May 1971 ASCII 42094 20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0166 RFC0167 Socket conventions reconsidered A.K. Bhushan R.M. Metcalfe J.M. Winett May 1971 ASCII 7643 4 RFC0129 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0167 RFC0168 ARPA Network mailing lists J.B. North May 1971 ASCII 13294 7 RFC0155 RFC0211 UNKNOWN UNKNOWN Legacy 10.17487/RFC0168 RFC0169 COMPUTER NETWORKS S.D. Crocker May 1971 ASCII 7061 4 PDF 178823 UNKNOWN UNKNOWN Legacy 10.17487/RFC0169 RFC0170 RFC List by Number Network Information Center. Stanford Research Institute June 1971 ASCII 17670 6 RFC0200 UNKNOWN UNKNOWN Legacy 10.17487/RFC0170 RFC0171 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII 20616 9 FTP DTP RFC0264 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0171 RFC0172 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII 21328 12 FTP RFC0265 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0172 RFC0173 Network Data Management Committee Meeting Announcement P.M. Karp D.B. McKay June 1971 ASCII 4239 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0173 RFC0174 UCLA - Computer Science Graphics Overview J. Postel V.G. Cerf June 1971 ASCII 5037 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0174 RFC0175 Comments on "Socket Conventions Reconsidered" E. Harslem J.F. Heafner June 1971 ASCII 2225 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0175 RFC0176 Comments on "Byte size for connections" A.K. Bhushan R. Kanodia R.M. Metcalfe J. Postel June 1971 ASCII 7269 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0176 RFC0177 Device independent graphical display description J. McConnell June 1971 ASCII 20474 9 RFC0125 RFC0181 UNKNOWN UNKNOWN Legacy 10.17487/RFC0177 RFC0178 Network graphic attention handling I.W. Cotton June 1971 ASCII 24522 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0178 RFC0179 Link Number Assignments A.M. McKenzie June 1971 ASCII 1221 1 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0179 RFC0180 File system questionnaire A.M. McKenzie June 1971 ASCII 8154 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0180 RFC0181 Modifications to RFC 177 J. McConnell July 1971 ASCII 4892 3 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0181 RFC0182 Compilation of list of relevant site reports J.B. North June 1971 ASCII 2565 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0182 RFC0183 EBCDIC Codes and Their Mapping to ASCII J.M. Winett July 1971 ASCII 22256 12 PDF 577092 UNKNOWN UNKNOWN Legacy 10.17487/RFC0183 RFC0184 Proposed graphic display modes K.C. Kelley July 1971 ASCII 18678 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0184 RFC0185 NIC distribution of manuals and handbooks J.B. North July 1971 ASCII 1406 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0185 RFC0186 Network graphics loader J.C. Michener July 1971 ASCII 30557 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0186 RFC0187 Network/440 Protocol Concept D.B. McKay D.P. Karp July 1971 ASCII 25042 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0187 RFC0188 Data management meeting announcement P.M. Karp D.B. McKay January 1971 ASCII 3383 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0188 RFC0189 Interim NETRJS specifications R.T. Braden July 1971 ASCII 41383 19 RFC0088 RFC0599 RFC0283 UNKNOWN UNKNOWN Legacy 10.17487/RFC0189 RFC0190 DEC PDP-10-IMLAC communications system L.P. Deutsch July 1971 ASCII 18752 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0190 RFC0191 Graphics implementation and conceptualization at Augmentation Research Center C.H. Irby July 1971 ASCII 8179 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0191 RFC0192 Some factors which a Network Graphics Protocol must consider R.W. Watson July 1971 ASCII 48540 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0192 RFC0193 NETWORK CHECKOUT E. Harslem J.F. Heafner July 1971 ASCII 3622 2 RFC0198 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0193 RFC0194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes V. Cerf E. Harslem J. Heafner B. Metcalfe J. White July 1971 ASCII 32716 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0194 RFC0195 Data computers-data descriptions and access language G.H. Mealy July 1971 ASCII 8704 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0195 RFC0196 Mail Box Protocol R.W. Watson July 1971 ASCII 7016 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0196 RFC0197 Initial Connection Protocol - Reviewed A. Shoshani E. Harslem July 1971 ASCII 7094 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0197 RFC0198 Site Certification - Lincoln Labs 360/67 J.F. Heafner July 1971 ASCII 855 1 RFC0193 RFC0214 RFC0193 UNKNOWN UNKNOWN Legacy 10.17487/RFC0198 RFC0199 Suggestions for a Network Data-Tablet Graphics Protocol T. Williams July 1971 ASCII 18660 10 PDF 542961 UNKNOWN UNKNOWN Legacy 10.17487/RFC0199 RFC0200 RFC list by number J.B. North August 1971 ASCII 19256 7 RFC0170 RFC0160 NIC7724 UNKNOWN UNKNOWN Legacy 10.17487/RFC0200 RFC0201 RFC0202 Possible Deadlock in ICP S.M. Wolfe J. Postel July 1971 ASCII 2796 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0202 RFC0203 Achieving reliable communication R.B. Kalin August 1971 ASCII 9253 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0203 RFC0204 Sockets in use J. Postel August 1971 ASCII 1379 1 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0204 RFC0205 NETCRT - a character display protocol R.T. Braden August 1971 ASCII 28272 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0205 RFC0206 A User TELNET Description of an Initial Implementation J. White August 1971 ASCII 33152 14 PDF 617017 UNKNOWN UNKNOWN Legacy 10.17487/RFC0206 RFC0207 September Network Working Group meeting A. Vezza August 1971 ASCII 3356 2 RFC0212 UNKNOWN UNKNOWN Legacy 10.17487/RFC0207 RFC0208 Address tables A.M. McKenzie August 1971 ASCII 5858 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0208 RFC0209 Host/IMP interface documentation B. Cosell August 1971 ASCII 2566 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0209 RFC0210 Improvement of Flow Control W. Conrad August 1971 ASCII 3329 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0210 RFC0211 ARPA Network Mailing Lists J.B. North August 1971 ASCII 13205 13 PDF 210300 RFC0168 RFC0300 UNKNOWN UNKNOWN Legacy 10.17487/RFC0211 RFC0212 NWG meeting on network usage Information Sciences Institute University of Southern California August 1971 ASCII 4356 2 RFC0207 RFC0222 UNKNOWN UNKNOWN Legacy 10.17487/RFC0212 RFC0213 IMP System change notification B. Cosell August 1971 ASCII 1589 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0213 RFC0214 Network checkpoint E. Harslem August 1971 ASCII 3047 2 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0214 RFC0215 NCP, ICP, and Telnet: The Terminal IMP implementation A.M. McKenzie August 1971 ASCII 16645 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0215 RFC0216 Telnet Access to UCSB's On-Line System J.E. White September 1971 ASCII 37570 16 PDF 908675 UNKNOWN UNKNOWN Legacy 10.17487/RFC0216 RFC0217 Specifications changes for OLS, RJE/RJOR, and SMFS J.E. White September 1971 ASCII 2956 2 RFC0074 RFC0105 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0217 RFC0218 Changing the IMP status reporting facility B. Cosell September 1971 ASCII 1131 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0218 RFC0219 User's View of the Datacomputer R. Winter September 1971 ASCII 16631 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0219 RFC0220 RFC0221 Mail Box Protocol: Version 2 R.W. Watson August 1971 ASCII 9805 5 RFC0196 RFC0278 UNKNOWN UNKNOWN Legacy 10.17487/RFC0221 RFC0222 Subject: System programmer's workshop R.M. Metcalfe September 1971 ASCII 4023 2 RFC0212 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0222 RFC0223 Network Information Center schedule for network users J.T. Melvin R.W. Watson September 1971 ASCII 5369 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0223 RFC0224 Comments on Mailbox Protocol A.M. McKenzie September 1971 ASCII 3583 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0224 RFC0225 Rand/UCSB network graphics experiment E. Harslem R. Stoughton September 1971 ASCII 13573 5 RFC0074 UNKNOWN UNKNOWN Legacy 10.17487/RFC0225 RFC0226 Standardization of host mnemonics P.M. Karp September 1971 ASCII 2012 1 RFC0247 UNKNOWN UNKNOWN Legacy 10.17487/RFC0226 RFC0227 Data transfer rates (Rand/UCLA) J.F. Heafner E. Harslem September 1971 ASCII 2451 2 RFC0113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0227 RFC0228 Clarification D.C. Walden September 1971 ASCII 715 1 RFC0070 UNKNOWN UNKNOWN Legacy 10.17487/RFC0228 RFC0229 Standard host names J. Postel September 1971 ASCII 3388 3 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0229 RFC0230 Toward reliable operation of minicomputer-based terminals on a TIP T. Pyke September 1971 ASCII 7040 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0230 RFC0231 Service center standards for remote usage: A user's view J.F. Heafner E. Harslem September 1971 ASCII 9692 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0231 RFC0232 Postponement of network graphics meeting A. Vezza September 1971 ASCII 899 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0232 RFC0233 Standardization of host call letters A. Bhushan R. Metcalfe September 1971 ASCII 3206 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0233 RFC0234 Network Working Group meeting schedule A. Vezza October 1971 ASCII 1634 1 RFC0222 RFC0204 UNKNOWN UNKNOWN Legacy 10.17487/RFC0234 RFC0235 Site status E. Westheimer September 1971 ASCII 7994 5 RFC0240 UNKNOWN UNKNOWN Legacy 10.17487/RFC0235 RFC0236 Standard host names J. Postel September 1971 ASCII 5112 2 RFC0229 UNKNOWN UNKNOWN Legacy 10.17487/RFC0236 RFC0237 NIC view of standard host names R.W. Watson October 1971 ASCII 2212 1 RFC0273 UNKNOWN UNKNOWN Legacy 10.17487/RFC0237 RFC0238 Comments on DTP and FTP proposals R.T. Braden September 1971 ASCII 2735 2 FTP RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0238 RFC0239 Host mnemonics proposed in RFC 226 (NIC 7625) R.T. Braden September 1971 ASCII 2236 1 RFC0226 RFC0229 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0239 RFC0240 Site Status A.M. McKenzie September 1971 ASCII 7948 4 RFC0235 RFC0252 UNKNOWN UNKNOWN Legacy 10.17487/RFC0240 RFC0241 Connecting computers to MLC ports A.M. McKenzie September 1971 ASCII 3739 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0241 RFC0242 Data Descriptive Language for Shared Data L. Haibt A.P. Mullery July 1971 ASCII 18151 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0242 RFC0243 Network and data sharing bibliography A.P. Mullery October 1971 ASCII 12432 7 RFC0290 UNKNOWN UNKNOWN Legacy 10.17487/RFC0243 RFC0244 RFC0245 Reservations for Network Group meeting C. Falls October 1971 ASCII 1142 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0245 RFC0246 Network Graphics meeting A. Vezza October 1971 ASCII 856 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0246 RFC0247 Proffered set of standard host names P.M. Karp October 1971 ASCII 7122 4 RFC0226 UNKNOWN UNKNOWN Legacy 10.17487/RFC0247 RFC0248 RFC0249 Coordination of equipment and supplies purchase R.F. Borelli October 1971 ASCII 4561 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0249 RFC0250 Some thoughts on file transfer H. Brodie October 1971 ASCII 2446 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0250 RFC0251 Weather data D. Stern October 1971 ASCII 1907 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0251 RFC0252 Network host status E. Westheimer October 1971 ASCII 5531 3 RFC0240 RFC0255 UNKNOWN UNKNOWN Legacy 10.17487/RFC0252 RFC0253 Second Network Graphics meeting details J.A. Moorer October 1971 ASCII 1981 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0253 RFC0254 Scenarios for using ARPANET computers A. Bhushan October 1971 ASCII 40998 PDF 4903124 UNKNOWN UNKNOWN Legacy 10.17487/RFC0254 RFC0255 Status of network hosts E. Westheimer October 1971 ASCII 4002 2 RFC0252 RFC0266 UNKNOWN UNKNOWN Legacy 10.17487/RFC0255 RFC0256 IMPSYS change notification B. Cosell November 1971 ASCII 1240 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0256 RFC0257 RFC0258 RFC0259 RFC0260 RFC0261 RFC0262 RFC0263 "Very Distant" Host interface A.M. McKenzie December 1971 ASCII 3914 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0263 RFC0264 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize B. Sundberg D. Watson J. White January 1972 ASCII 20907 9 FTP DTP RFC0171 RFC0354 RFC0310 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0264 RFC0265 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White November 1971 ASCII 3914 12 FTP RFC0172 RFC0354 RFC0281 RFC0294 RFC0310 RFC0264 UNKNOWN UNKNOWN Legacy 10.17487/RFC0265 RFC0266 Network host status E. Westheimer November 1971 ASCII 3174 2 RFC0255 RFC0267 UNKNOWN UNKNOWN Legacy 10.17487/RFC0266 RFC0267 Network Host Status E. Westheimer November 1971 ASCII 7862 4 RFC0266 RFC0287 UNKNOWN UNKNOWN Legacy 10.17487/RFC0267 RFC0268 Graphics facilities information J. Postel November 1971 ASCII 1298 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0268 RFC0269 Some Experience with File Transfer H. Brodie December 1971 ASCII 5961 3 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0269 RFC0270 Correction to BBN Report No. 1822 (NIC NO 7958) A.M. McKenzie January 1972 ASCII 1371 1 NIC7959 UNKNOWN UNKNOWN Legacy 10.17487/RFC0270 RFC0271 IMP System change notifications B. Cosell January 1972 ASCII 4022 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0271 RFC0272 RFC0273 More on standard host names R.W. Watson October 1971 ASCII 4589 3 RFC0237 UNKNOWN UNKNOWN Legacy 10.17487/RFC0273 RFC0274 Establishing a local guide for network usage E. Forman November 1971 ASCII 7114 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0274 RFC0275 RFC0276 NIC course R.W. Watson November 1971 ASCII 1183 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0276 RFC0277 RFC0278 Revision of the Mail Box Protocol A.K. Bhushan R.T. Braden E. Harslem J.F. Heafner A.M. McKenzie J.T. Melvin R.L. Sundberg R.W. Watson J.E. White November 1971 ASCII 7526 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0278 RFC0279 RFC0280 A Draft of Host Names R.W. Watson November 1971 ASCII 3629 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0280 RFC0281 Suggested addition to File Transfer Protocol A.M. McKenzie December 1971 ASCII 12006 8 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0281 RFC0282 Graphics meeting report M.A. Padlipsky December 1971 ASCII 18100 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0282 RFC0283 NETRJT: Remote Job Service Protocol for TIPS R.T. Braden December 1971 ASCII 18771 9 RFC0189 UNKNOWN UNKNOWN Legacy 10.17487/RFC0283 RFC0284 RFC0285 Network graphics D. Huff December 1971 ASCII 18076 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0285 RFC0286 Network Library Information System E. Forman December 1971 ASCII 2079 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0286 RFC0287 Status of Network Hosts E. Westheimer December 1971 ASCII 9217 5 RFC0267 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0287 RFC0288 Network host status E. Westheimer January 1972 ASCII 8501 4 RFC0287 RFC0293 RFC0293 UNKNOWN UNKNOWN Legacy 10.17487/RFC0288 RFC0289 What we hope is an official list of host names R.W. Watson December 1971 ASCII 5069 3 RFC0384 UNKNOWN UNKNOWN Legacy 10.17487/RFC0289 RFC0290 Computer networks and data sharing: A bibliography A.P. Mullery January 1972 ASCII 34329 15 RFC0243 UNKNOWN UNKNOWN Legacy 10.17487/RFC0290 RFC0291 Data Management Meeting Announcement D.B. McKay January 1972 ASCII 3375 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0291 RFC0292 Graphics Protocol: Level 0 only J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer January 1972 ASCII 22342 10 RFC0493 UNKNOWN UNKNOWN Legacy 10.17487/RFC0292 RFC0293 Network Host Status E. Westheimer January 1972 ASCII 7639 4 RFC0288 RFC0298 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0293 RFC0294 The Use of "Set Data Type" Transaction in File Transfer Protocol A.K. Bhushan January 1972 ASCII 3924 2 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0294 RFC0295 Report of the Protocol Workshop, 12 October 1971 J. Postel January 1972 ASCII 5432 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0295 RFC0296 DS-1 Display System D.E. Liddle January 1972 ASCII 37921 17 PDF 1560765 UNKNOWN UNKNOWN Legacy 10.17487/RFC0296 RFC0297 TIP Message Buffers D.C. Walden January 1972 ASCII 3517 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0297 RFC0298 Network host status E. Westheimer February 1972 ASCII 8770 4 RFC0293 RFC0306 UNKNOWN UNKNOWN Legacy 10.17487/RFC0298 RFC0299 Information Management System D. Hopkin February 1972 ASCII 1825 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0299 RFC0300 ARPA Network mailing lists J.B. North January 1972 ASCII 16357 9 RFC0211 RFC0303 UNKNOWN UNKNOWN Legacy 10.17487/RFC0300 RFC0301 BBN IMP (#5) and NCC Schedule March 4, 1971 R. Alter February 1972 ASCII 1487 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0301 RFC0302 Exercising The ARPANET R.F. Bryan February 1972 ASCII 5452 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0302 RFC0303 ARPA Network mailing lists Network Information Center. Stanford Research Institute March 1972 ASCII 18193 11 RFC0300 RFC0329 UNKNOWN UNKNOWN Legacy 10.17487/RFC0303 RFC0304 Data Management System Proposal for the ARPA Network D.B. McKay February 1972 ASCII 20446 8 PDF 465564 UNKNOWN UNKNOWN Legacy 10.17487/RFC0304 RFC0305 Unknown Host Numbers R. Alter February 1972 ASCII 1998 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0305 RFC0306 Network host status E. Westheimer February 1972 ASCII 7485 4 RFC0298 RFC0315 UNKNOWN UNKNOWN Legacy 10.17487/RFC0306 RFC0307 Using network Remote Job Entry E. Harslem February 1972 ASCII 12032 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0307 RFC0308 ARPANET host availability data M. Seriff March 1972 ASCII 5948 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0308 RFC0309 Data and File Transfer Workshop Announcement A.K. Bhushan March 1972 ASCII 9404 6 FTP DTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0309 RFC0310 Another Look at Data and File Transfer Protocols A.K. Bhushan April 1972 ASCII 18593 7 FTP RFC0264 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0310 RFC0311 New Console Attachments to the USCB Host R.F. Bryan February 1972 ASCII 3141 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0311 RFC0312 Proposed Change in IMP-to-Host Protocol A.M. McKenzie March 1972 ASCII 3562 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0312 RFC0313 Computer based instruction T.C. O'Sullivan March 1972 ASCII 19880 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0313 RFC0314 Network Graphics Working Group Meeting I.W. Cotton March 1972 ASCII 1836 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0314 RFC0315 Network Host Status E. Westheimer March 1972 ASCII 7818 4 RFC0306 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0315 RFC0316 ARPA Network Data Management Working Group D.B. McKay A.P. Mullery February 1972 ASCII 15494 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0316 RFC0317 Official Host-Host Protocol Modification: Assigned Link Numbers J. Postel March 1972 ASCII 1593 1 RFC0604 UNKNOWN UNKNOWN Legacy 10.17487/RFC0317 RFC0318 Telnet Protocols J. Postel April 1972 ASCII 34928 16 RFC0158 RFC0435 RFC0139 RFC0158 UNKNOWN UNKNOWN Legacy 10.17487/RFC0318 RFC0319 Network Host Status E. Westheimer March 1972 ASCII 8955 4 RFC0315 RFC0326 UNKNOWN UNKNOWN Legacy 10.17487/RFC0319 RFC0320 Workshop on Hard Copy Line Graphics R. Reddy March 1972 ASCII 5600 3 PDF 14422 UNKNOWN UNKNOWN Legacy 10.17487/RFC0320 RFC0321 CBI Networking Activity at MITRE P.M. Karp March 1972 ASCII 20500 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0321 RFC0322 Well known socket numbers V. Cerf J. Postel March 1972 ASCII 1735 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0322 RFC0323 Formation of Network Measurement Group (NMG) V. Cerf March 1972 ASCII 15777 9 RFC0388 UNKNOWN UNKNOWN Legacy 10.17487/RFC0323 RFC0324 RJE Protocol meeting J. Postel April 1972 ASCII 1176 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0324 RFC0325 Network Remote Job Entry program - NETRJS G. Hicks April 1972 ASCII 17499 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0325 RFC0326 Network Host Status E. Westheimer April 1972 ASCII 7944 4 RFC0330 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0326 RFC0327 Data and File Transfer workshop notes A.K. Bhushan April 1972 ASCII 11792 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0327 RFC0328 Suggested Telnet Protocol Changes J. Postel April 1972 ASCII 2685 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0328 RFC0329 ARPA Network Mailing Lists Network Information Center. Stanford Research Institute May 1972 ASCII 23861 13 RFC0303 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0329 RFC0330 Network Host Status E. Westheimer April 1972 ASCII 8085 3 RFC0326 RFC0332 UNKNOWN UNKNOWN Legacy 10.17487/RFC0330 RFC0331 IMP System Change Notification J.M. McQuillan April 1972 ASCII 2339 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0331 RFC0332 Network Host Status E. Westheimer April 1972 ASCII 8427 4 RFC0342 RFC0330 UNKNOWN UNKNOWN Legacy 10.17487/RFC0332 RFC0333 Proposed experiment with a Message Switching Protocol R.D. Bressler D. Murphy D.C. Walden May 1972 ASCII 62507 26 UNKNOWN UNKNOWN Legacy 10.17487/RFC0333 RFC0334 Network Use on May 8 A.M. McKenzie May 1972 ASCII 1376 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0334 RFC0335 New Interface - IMP/360 R.F. Bryan May 1972 ASCII 934 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0335 RFC0336 Level 0 Graphic Input Protocol I.W. Cotton May 1972 ASCII 3787 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0336 RFC0337 RFC0338 EBCDIC/ASCII Mapping for Network RJE R.T. Braden May 1972 ASCII 11494 6 PS 2386987 PDF 1871020 UNKNOWN UNKNOWN Legacy 10.17487/RFC0338 RFC0339 MLTNET: A "Multi Telnet" Subsystem for Tenex R. Thomas May 1972 ASCII 7941 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0339 RFC0340 Proposed Telnet Changes T.C. O'Sullivan May 1972 ASCII 2656 2 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0340 RFC0341 RFC0342 Network Host Status E. Westheimer May 1972 ASCII 8382 4 RFC0332 RFC0344 UNKNOWN UNKNOWN Legacy 10.17487/RFC0342 RFC0343 IMP System change notification A.M. McKenzie May 1972 ASCII 3370 2 RFC0331 RFC0359 UNKNOWN UNKNOWN Legacy 10.17487/RFC0343 RFC0344 Network Host Status E. Westheimer May 1972 ASCII 8221 4 RFC0342 RFC0353 UNKNOWN UNKNOWN Legacy 10.17487/RFC0344 RFC0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN) K.C. Kelley May 1972 ASCII 1999 1 MIP UNKNOWN UNKNOWN Legacy 10.17487/RFC0345 RFC0346 Satellite Considerations J. Postel May 1972 ASCII 2778 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0346 RFC0347 Echo process J. Postel May 1972 ASCII 1377 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0347 RFC0348 Discard Process J. Postel May 1972 ASCII 1181 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0348 RFC0349 Proposed Standard Socket Numbers J. Postel May 1972 ASCII 1663 1 RFC0433 RFC0204 RFC0322 UNKNOWN UNKNOWN Legacy 10.17487/RFC0349 RFC0350 User Accounts for UCSB On-Line System R. Stoughton May 1972 ASCII 5117 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0350 RFC0351 Graphics information form for the ARPANET graphics resources notebook D. Crocker June 1972 ASCII 2150 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0351 RFC0352 TIP Site Information Form D. Crocker June 1972 ASCII 2266 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0352 RFC0353 Network host status E. Westheimer June 1972 ASCII 8747 5 RFC0344 RFC0362 UNKNOWN UNKNOWN Legacy 10.17487/RFC0353 RFC0354 File Transfer Protocol A.K. Bhushan July 1972 ASCII 58074 25 FTP RFC0264 RFC0265 RFC0542 RFC0385 RFC0454 RFC0683 UNKNOWN UNKNOWN Legacy 10.17487/RFC0354 RFC0355 Response to NWG/RFC 346 J. Davidson June 1972 ASCII 3717 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0355 RFC0356 ARPA Network Control Center R. Alter June 1972 ASCII 1963 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0356 RFC0357 Echoing strategy for satellite links J. Davidson June 1972 ASCII 30103 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0357 RFC0358 RFC0359 Status of the Release of the New IMP System (2600) D.C. Walden June 1972 ASCII 2015 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0359 RFC0360 Proposed Remote Job Entry Protocol C. Holland June 1972 ASCII 39473 18 PDF 1187574 RFC0407 UNKNOWN UNKNOWN Legacy 10.17487/RFC0360 RFC0361 Deamon Processes on Host 106 R.D. Bressler July 1972 ASCII 1480 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0361 RFC0362 Network Host Status E. Westheimer June 1972 ASCII 8631 4 RFC0353 RFC0366 UNKNOWN UNKNOWN Legacy 10.17487/RFC0362 RFC0363 ARPA Network mailing lists Network Information Center. Stanford Research Institute August 1972 ASCII 25356 13 RFC0329 RFC0402 UNKNOWN UNKNOWN Legacy 10.17487/RFC0363 RFC0364 Serving remote users on the ARPANET M.D. Abrams July 1972 ASCII 11253 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0364 RFC0365 Letter to All TIP Users D.C. Walden July 1972 ASCII 10331 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0365 RFC0366 Network Host Status E. Westheimer July 1972 ASCII 8278 4 RFC0362 RFC0367 UNKNOWN UNKNOWN Legacy 10.17487/RFC0366 RFC0367 Network host status E. Westheimer July 1972 ASCII 8057 4 RFC0366 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0367 RFC0368 Comments on "Proposed Remote Job Entry Protocol" R.T. Braden July 1972 ASCII 3883 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0368 RFC0369 Evaluation of ARPANET services January-March, 1972 J.R. Pickens July 1972 ASCII 24414 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0369 RFC0370 Network Host Status E. Westheimer July 1972 ASCII 8389 5 RFC0367 RFC0376 UNKNOWN UNKNOWN Legacy 10.17487/RFC0370 RFC0371 Demonstration at International Computer Communications Conference R.E. Kahn July 1972 ASCII 3728 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0371 RFC0372 Notes on a Conversation with Bob Kahn on the ICCC R.W. Watson July 1972 ASCII 6040 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0372 RFC0373 Arbitrary Character Sets J. McCarthy July 1972 ASCII 7783 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0373 RFC0374 IMP System Announcement A.M. McKenzie July 1972 ASCII 3963 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0374 RFC0375 RFC0376 Network Host Status E. Westheimer August 1972 ASCII 8861 5 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0376 RFC0377 Using TSO via ARPA Network Virtual Terminal R.T. Braden August 1972 ASCII 7093 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0377 RFC0378 Traffic statistics (July 1972) A.M. McKenzie August 1972 ASCII 5730 3 RFC0391 UNKNOWN UNKNOWN Legacy 10.17487/RFC0378 RFC0379 Using TSO at CCN R. Braden August 1972 ASCII 8674 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0379 RFC0380 RFC0381 Three aids to improved network operation J.M. McQuillan July 1972 ASCII 9305 4 RFC0394 UNKNOWN UNKNOWN Legacy 10.17487/RFC0381 RFC0382 Mathematical Software on the ARPA Network L. McDaniel August 1972 ASCII 2041 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0382 RFC0383 RFC0384 Official site idents for organizations in the ARPA Network J.B. North August 1972 ASCII 10401 4 RFC0289 UNKNOWN UNKNOWN Legacy 10.17487/RFC0384 RFC0385 Comments on the File Transfer Protocol A.K. Bhushan August 1972 ASCII 13030 6 FTP RFC0354 RFC0414 UNKNOWN UNKNOWN Legacy 10.17487/RFC0385 RFC0386 Letter to TIP users-2 B. Cosell D.C. Walden August 1972 ASCII 12475 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0386 RFC0387 Some experiences in implementing Network Graphics Protocol Level 0 K.C. Kelley J. Meir August 1972 ASCII 9059 5 RFC0401 UNKNOWN UNKNOWN Legacy 10.17487/RFC0387 RFC0388 NCP statistics V. Cerf August 1972 ASCII 8458 5 RFC0323 UNKNOWN UNKNOWN Legacy 10.17487/RFC0388 RFC0389 UCLA Campus Computing Network Liaison Staff for ARPA Network B. Noble August 1972 ASCII 2819 2 RFC0423 UNKNOWN UNKNOWN Legacy 10.17487/RFC0389 RFC0390 TSO Scenario R.T. Braden September 1972 ASCII 6103 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0390 RFC0391 Traffic statistics (August 1972) A.M. McKenzie September 1972 ASCII 4695 3 RFC0378 UNKNOWN UNKNOWN Legacy 10.17487/RFC0391 RFC0392 Measurement of host costs for transmitting network data G. Hicks B.D. Wessler September 1972 ASCII 14462 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0392 RFC0393 Comments on Telnet Protocol Changes J.M. Winett October 1972 ASCII 9435 4 RFC0109 RFC0139 RFC0158 RFC0318 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0393 RFC0394 Two Proposed Changes to the IMP-Host Protocol J.M. McQuillan September 1972 ASCII 5780 3 RFC0381 UNKNOWN UNKNOWN Legacy 10.17487/RFC0394 RFC0395 Switch Settings on IMPs and TIPs J.M. McQuillan October 1972 ASCII 1827 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0395 RFC0396 Network Graphics Working Group Meeting - Second Iteration S. Bunch November 1972 ASCII 2224 1 RFC0474 UNKNOWN UNKNOWN Legacy 10.17487/RFC0396 RFC0397 RFC0398 UCSB Online Graphics J.R. Pickens E. Faeh September 1972 ASCII 3846 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0398 RFC0399 SMFS Login and Logout M. Krilanovich September 1972 ASCII 3024 2 RFC0431 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0399 RFC0400 Traffic Statistics (September 1972) A.M. McKenzie October 1972 ASCII 5435 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0400 RFC0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates J. Hansen October 1972 ASCII 3894 2 RFC0387 UNKNOWN UNKNOWN Legacy 10.17487/RFC0401 RFC0402 ARPA Network Mailing Lists J.B. North October 1972 ASCII 28162 16 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0402 RFC0403 Desirability of a Network 1108 Service G. Hicks January 1973 ASCII 9750 5 PDF 219744 UNKNOWN UNKNOWN Legacy 10.17487/RFC0403 RFC0404 Host Address Changes Involving Rand and ISI A.M. McKenzie October 1972 ASCII 944 1 RFC0405 UNKNOWN UNKNOWN Legacy 10.17487/RFC0404 RFC0405 Correction to RFC 404 A.M. McKenzie October 1972 ASCII 1103 1 RFC0404 UNKNOWN UNKNOWN Legacy 10.17487/RFC0405 RFC0406 Scheduled IMP Software Releases J.M. McQuillan October 1972 ASCII 2468 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0406 RFC0407 Remote Job Entry Protocol R.D. Bressler R. Guida A.M. McKenzie October 1972 ASCII 47556 21 RJE RFC0360 HISTORIC HISTORIC Legacy 10.17487/RFC0407 RFC0408 NETBANK A.D. Owen J. Postel October 1972 ASCII 1645 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0408 RFC0409 Tenex interface to UCSB's Simple-Minded File System J.E. White December 1972 ASCII 14231 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0409 RFC0410 Removal of the 30-Second Delay When Hosts Come Up J.M. McQuillan November 1972 ASCII 3964 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0410 RFC0411 New MULTICS Network Software Features M.A. Padlipsky November 1972 ASCII 3024 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0411 RFC0412 User FTP Documentation G. Hicks November 1972 ASCII 17510 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0412 RFC0413 Traffic statistics (October 1972) A.M. McKenzie November 1972 ASCII 16145 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0413 RFC0414 File Transfer Protocol (FTP) status and further comments A.K. Bhushan December 1972 ASCII 12845 5 RFC0385 UNKNOWN UNKNOWN Legacy 10.17487/RFC0414 RFC0415 Tenex bandwidth H. Murray November 1972 ASCII 3456 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0415 RFC0416 ARC System Will Be Unavailable for Use During Thanksgiving Week J.C. Norton November 1972 ASCII 2205 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0416 RFC0417 Link usage violation J. Postel C. Kline December 1972 ASCII 901 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0417 RFC0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center W. Hathaway November 1972 PDF 1080191 UNKNOWN UNKNOWN Legacy 10.17487/RFC0418 RFC0419 To: Network liaisons and station agents A. Vezza December 1972 ASCII 1252 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0419 RFC0420 CCA ICCC weather demo H. Murray January 1973 ASCII 14752 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0420 RFC0421 Software Consulting Service for Network Users A.M. McKenzie November 1972 ASCII 2483 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0421 RFC0422 Traffic statistics (November 1972) A.M. McKenzie December 1972 ASCII 5494 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0422 RFC0423 UCLA Campus Computing Network Liaison Staff for ARPANET B. Noble December 1972 ASCII 2890 2 RFC0389 UNKNOWN UNKNOWN Legacy 10.17487/RFC0423 RFC0424 RFC0425 "But my NCP costs $500 a day" R.D. Bressler December 1972 ASCII 1763 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0425 RFC0426 Reconnection Protocol R. Thomas January 1973 ASCII 26548 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0426 RFC0427 RFC0428 RFC0429 Character Generator Process J. Postel December 1972 ASCII 1319 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0429 RFC0430 Comments on File Transfer Protocol R.T. Braden February 1973 ASCII 18696 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0430 RFC0431 Update on SMFS Login and Logout M. Krilanovich December 1972 ASCII 4196 3 RFC0399 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0431 RFC0432 Network logical map N. Neigus December 1972 ASCII 1291 1 PDF 148880 PS 1344571 UNKNOWN UNKNOWN Legacy 10.17487/RFC0432 RFC0433 Socket number list J. Postel December 1972 ASCII 6834 5 RFC0349 RFC0503 UNKNOWN UNKNOWN Legacy 10.17487/RFC0433 RFC0434 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII 2242 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0434 RFC0435 Telnet issues B. Cosell D.C. Walden January 1973 ASCII 23019 10 RFC0318 UNKNOWN UNKNOWN Legacy 10.17487/RFC0435 RFC0436 Announcement of RJS at UCSB M. Krilanovich January 1973 ASCII 2579 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0436 RFC0437 Data Reconfiguration Service at UCSB E. Faeh June 1973 ASCII 21562 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0437 RFC0438 FTP server-server interaction R. Thomas R. Clements January 1973 ASCII 6514 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0438 RFC0439 PARRY encounters the DOCTOR V. Cerf January 1973 ASCII 7066 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0439 RFC0440 Scheduled network software maintenance D.C. Walden January 1973 ASCII 1870 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0440 RFC0441 Inter-Entity Communication - an experiment R.D. Bressler R. Thomas January 1973 ASCII 12876 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0441 RFC0442 Current flow-control scheme for IMPSYS V. Cerf January 1973 ASCII 16315 7 RFC0449 UNKNOWN UNKNOWN Legacy 10.17487/RFC0442 RFC0443 Traffic statistics (December 1972) A.M. McKenzie January 1973 ASCII 5664 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0443 RFC0444 RFC0445 IMP/TIP preventive maintenance schedule A.M. McKenzie January 1973 ASCII 2668 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0445 RFC0446 Proposal to consider a network program resource notebook L.P. Deutsch January 1973 ASCII 3053 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0446 RFC0447 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII 2332 2 RFC0434 RFC0476 UNKNOWN UNKNOWN Legacy 10.17487/RFC0447 RFC0448 Print files in FTP R.T. Braden February 1973 ASCII 6838 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0448 RFC0449 Current flow-control scheme for IMPSYS D.C. Walden January 1973 ASCII 1662 1 RFC0442 UNKNOWN UNKNOWN Legacy 10.17487/RFC0449 RFC0450 MULTICS sampling timeout change M.A. Padlipsky February 1973 ASCII 924 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0450 RFC0451 Tentative proposal for a Unified User Level Protocol M.A. Padlipsky February 1973 ASCII 8114 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0451 RFC0452 TELNET Command at Host LL J. Winett February 1973 ASCII 28415 14 PDF 777983 UNKNOWN UNKNOWN Legacy 10.17487/RFC0452 RFC0453 Meeting announcement to discuss a network mail system M.D. Kudlick February 1973 ASCII 4572 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0453 RFC0454 File Transfer Protocol - meeting announcement and a new proposed document A.M. McKenzie February 1973 ASCII 78966 35 FTP RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0454 RFC0455 Traffic statistics (January 1973) A.M. McKenzie February 1973 ASCII 5746 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0455 RFC0456 Memorandum: Date change of mail meeting M.D. Kudlick February 1973 ASCII 950 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0456 RFC0457 TIPUG D.C. Walden February 1973 ASCII 845 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0457 RFC0458 Mail retrieval via FTP R.D. Bressler R. Thomas February 1973 ASCII 2705 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0458 RFC0459 Network questionnaires W. Kantrowitz February 1973 ASCII 1950 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0459 RFC0460 NCP survey C. Kline February 1973 ASCII 10324 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0460 RFC0461 Telnet Protocol meeting announcement A.M. McKenzie February 1973 ASCII 1966 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0461 RFC0462 Responding to user needs J. Iseli D. Crocker February 1973 ASCII 2808 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0462 RFC0463 FTP comments and response to RFC 430 A.K. Bhushan February 1973 ASCII 5729 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0463 RFC0464 Resource notebook framework M.D. Kudlick February 1973 ASCII 3684 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0464 RFC0465 RFC0466 Telnet logger/server for host LL-67 J.M. Winett February 1973 ASCII 17595 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0466 RFC0467 Proposed change to Host-Host Protocol: Resynchronization of connection status J.D. Burchfiel R.S. Tomlinson February 1973 ASCII 14325 7 RFC0492 UNKNOWN UNKNOWN Legacy 10.17487/RFC0467 RFC0468 FTP data compression R.T. Braden March 1973 ASCII 14909 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0468 RFC0469 Network mail meeting summary M.D. Kudlick March 1973 ASCII 17774 10 network mail meeting UNKNOWN UNKNOWN Legacy 10.17487/RFC0469 RFC0470 Change in socket for TIP news facility R. Thomas March 1973 ASCII 1014 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0470 RFC0471 Workshop on multi-site executive programs R. Thomas March 1973 ASCII 3339 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0471 RFC0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925) S. Bunch March 1973 ASCII 4780 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0472 RFC0473 MIX and MIXAL? D.C. Walden February 1973 ASCII 868 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0473 RFC0474 Announcement of NGWG meeting: Call for papers S. Bunch March 1973 ASCII 1170 2 RFC0396 UNKNOWN UNKNOWN Legacy 10.17487/RFC0474 RFC0475 FTP and Network Mail System A.K. Bhushan March 1973 ASCII 21928 5 PDF 600361 UNKNOWN UNKNOWN Legacy 10.17487/RFC0475 RFC0476 IMP/TIP memory retrofit schedule (rev 2) A.M. McKenzie March 1973 ASCII 2281 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0476 RFC0477 Remote Job Service at UCSB M. Krilanovich May 1973 ASCII 40535 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0477 RFC0478 FTP server-server interaction - II R.D. Bressler R. Thomas March 1973 ASCII 4199 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0478 RFC0479 Use of FTP by the NIC Journal J.E. White March 1973 ASCII 11183 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0479 RFC0480 Host-dependent FTP parameters J.E. White March 1973 ASCII 2084 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0480 RFC0481 RFC0482 Traffic statistics (February 1973) A.M. McKenzie March 1973 ASCII 6162 4 RFC0497 UNKNOWN UNKNOWN Legacy 10.17487/RFC0482 RFC0483 Cancellation of the resource notebook framework meeting M.D. Kudlick March 1973 ASCII 1021 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0483 RFC0484 RFC0485 MIX and MIXAL at UCSB J.R. Pickens March 1973 ASCII 2226 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0485 RFC0486 Data transfer revisited R.D. Bressler March 1973 ASCII 4664 2 RJE FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0486 RFC0487 Free file transfer R.D. Bressler April 1973 ASCII 3249 2 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0487 RFC0488 NLS classes at network sites M.F. Auerbach March 1973 ASCII 3806 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0488 RFC0489 Comment on resynchronization of connection status proposal J. Postel March 1973 ASCII 2010 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0489 RFC0490 Surrogate RJS for UCLA-CCN J.R. Pickens March 1973 ASCII 9858 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0490 RFC0491 What is "Free"? M.A. Padlipsky April 1973 ASCII 5872 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0491 RFC0492 Response to RFC 467 E. Meyer April 1973 ASCII 18791 7 RFC0467 UNKNOWN UNKNOWN Legacy 10.17487/RFC0492 RFC0493 GRAPHICS PROTOCOL J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer April 1973 ASCII 67843 28 PDF 1563891 RFC0292 UNKNOWN UNKNOWN Legacy 10.17487/RFC0493 RFC0494 Availability of MIX and MIXAL in the Network D.C. Walden April 1973 ASCII 2007 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0494 RFC0495 Telnet Protocol specifications A.M. McKenzie May 1973 ASCII 4260 2 RFC0158 RFC0562 UNKNOWN UNKNOWN Legacy 10.17487/RFC0495 RFC0496 TNLS quick reference card is available M.F. Auerbach April 1973 ASCII 1110 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0496 RFC0497 Traffic Statistics (March 1973) A.M. McKenzie April 1973 ASCII 6078 4 PDF 191264 RFC0482 UNKNOWN UNKNOWN Legacy 10.17487/RFC0497 RFC0498 On mail service to CCN R.T. Braden April 1973 ASCII 5315 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0498 RFC0499 Harvard's network RJE B.R. Reussow April 1973 ASCII 12584 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0499 RFC0500 Integration of data management systems on a computer network A. Shoshani I. Spiegler April 1973 PDF 3045801 UNKNOWN UNKNOWN Legacy 10.17487/RFC0500 RFC0501 Un-muddling "free file transfer" K.T. Pogran May 1973 ASCII 13177 5 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0501 RFC0502 RFC0503 Socket number list N. Neigus J. Postel April 1973 ASCII 8690 8 RFC0433 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0503 RFC0504 Distributed resources workshop announcement R. Thomas April 1973 ASCII 9061 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0504 RFC0505 Two solutions to a file transfer access problem M.A. Padlipsky June 1973 ASCII 7476 3 FTP free UNKNOWN UNKNOWN Legacy 10.17487/RFC0505 RFC0506 FTP command naming problem M.A. Padlipsky June 1973 ASCII 1974 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0506 RFC0507 RFC0508 Real-time data transmission on the ARPANET L. Pfeifer J. McAfee May 1973 ASCII 25002 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0508 RFC0509 Traffic statistics (April 1973) A.M. McKenzie April 1973 ASCII 6538 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0509 RFC0510 Request for network mailbox addresses J.E. White May 1973 ASCII 4150 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0510 RFC0511 Enterprise phone service to NIC from ARPANET sites J.B. North May 1973 ASCII 4664 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0511 RFC0512 More on lost message detection W. Hathaway May 1973 ASCII 3641 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0512 RFC0513 Comments on the new Telnet specifications W. Hathaway May 1973 ASCII 7980 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0513 RFC0514 Network make-work W. Kantrowitz June 1973 ASCII 8734 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0514 RFC0515 Specifications for Datalanguage, Version 0/9 R. Winter June 1973 ASCII 60557 31 UNKNOWN UNKNOWN Legacy 10.17487/RFC0515 RFC0516 Lost message detection J. Postel May 1973 ASCII 4086 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0516 RFC0517 RFC0518 ARPANET accounts N. Vaughan E.J. Feinler June 1973 ASCII 12880 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0518 RFC0519 Resource Evaluation J.R. Pickens June 1973 ASCII 7750 4 PDF 224969 UNKNOWN UNKNOWN Legacy 10.17487/RFC0519 RFC0520 Memo to FTP group: Proposal for File Access Protocol J.D. Day June 1973 ASCII 16825 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0520 RFC0521 Restricted use of IMP DDT A.M. McKenzie May 1973 ASCII 3724 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0521 RFC0522 Traffic Statistics (May 1973) A.M. McKenzie June 1973 ASCII 6125 4 PDF 163705 RFC0509 UNKNOWN UNKNOWN Legacy 10.17487/RFC0522 RFC0523 SURVEY is in operation again A.K. Bhushan June 1973 ASCII 2852 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0523 RFC0524 Proposed Mail Protocol J.E. White June 1973 ASCII 75385 40 UNKNOWN UNKNOWN Legacy 10.17487/RFC0524 RFC0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing W. Parrish J.R. Pickens June 1973 ASCII 18501 9 PS 304440 PDF 228274 UNKNOWN UNKNOWN Legacy 10.17487/RFC0525 RFC0526 Technical meeting: Digital image processing software systems W.K. Pratt June 1973 ASCII 4062 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0526 RFC0527 ARPAWOCKY R. Merryman May 1973 ASCII 1857 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0527 RFC0528 Software checksumming in the IMP and network reliability J.M. McQuillan June 1973 ASCII 23152 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0528 RFC0529 Note on protocol synch sequences A.M. McKenzie R. Thomas R.S. Tomlinson K.T. Pogran June 1973 ASCII 9068 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0529 RFC0530 Report on the Survey Project A.K. Bhushan June 1973 PDF 408102 RFC0308 RFC0523 UNKNOWN UNKNOWN Legacy 10.17487/RFC0530 RFC0531 Feast or famine? A response to two recent RFC's about network information M.A. Padlipsky June 1973 ASCII 5070 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0531 RFC0532 UCSD-CC Server-FTP facility R.G. Merryman July 1973 ASCII 7298 4 FTP server UNKNOWN UNKNOWN Legacy 10.17487/RFC0532 RFC0533 Message-ID numbers D.C. Walden July 1973 ASCII 2102 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0533 RFC0534 Lost message detection D.C. Walden July 1973 ASCII 3227 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0534 RFC0535 Comments on File Access Protocol R. Thomas July 1973 ASCII 8393 4 PDF 239916 UNKNOWN UNKNOWN Legacy 10.17487/RFC0535 RFC0536 RFC0537 Announcement of NGG meeting July 16-17 S. Bunch June 1973 ASCII 2695 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0537 RFC0538 Traffic statistics (June 1973) A.M. McKenzie July 1973 ASCII 6389 4 RFC0556 UNKNOWN UNKNOWN Legacy 10.17487/RFC0538 RFC0539 Thoughts on the mail protocol proposed in RFC 524 D. Crocker J. Postel July 1973 ASCII 6213 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0539 RFC0540 RFC0541 RFC0542 File Transfer Protocol N. Neigus August 1973 ASCII 100666 40 FTP RFC0354 RFC0765 RFC0614 RFC0640 RFC0454 RFC0495 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=542 10.17487/RFC0542 RFC0543 Network journal submission and delivery N.D. Meyer July 1973 ASCII 15621 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0543 RFC0544 Locating on-line documentation at SRI-ARC N.D. Meyer K. Kelley July 1973 ASCII 1541 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0544 RFC0545 Of what quality be the UCSB resources evaluators? J.R. Pickens July 1973 ASCII 3754 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0545 RFC0546 Tenex load averages for July 1973 R. Thomas August 1973 ASCII 6632 4 PS 356023 PDF 268918 UNKNOWN UNKNOWN Legacy 10.17487/RFC0546 RFC0547 Change to the Very Distant Host specification D.C. Walden August 1973 ASCII 6236 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0547 RFC0548 Hosts using the IMP Going Down message D.C. Walden August 1973 ASCII 1435 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0548 RFC0549 Minutes of Network Graphics Group meeting, 15-17 July 1973 J.C. Michener July 1973 ASCII 23367 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0549 RFC0550 NIC NCP experiment L.P. Deutsch August 1973 ASCII 3688 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0550 RFC0551 NYU, ANL, and LBL Joining the Net Y. Feinroth R. Fink August 1973 ASCII 3020 2 PDF 73188 UNKNOWN UNKNOWN Legacy 10.17487/RFC0551 RFC0552 Single access to standard protocols A.D. Owen July 1973 ASCII 1404 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0552 RFC0553 Draft design for a text/graphics protocol C.H. Irby K. Victor July 1973 ASCII 35414 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0553 RFC0554 RFC0555 Responses to critiques of the proposed mail protocol J.E. White July 1973 ASCII 21521 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0555 RFC0556 Traffic Statistics (July 1973) A.M. McKenzie August 1973 ASCII 6648 4 PDF 142156 RFC0538 UNKNOWN UNKNOWN Legacy 10.17487/RFC0556 RFC0557 REVELATIONS IN NETWORK HOST MEASUREMENTS B.D. Wessler August 1973 ASCII 3167 2 PDF 90256 UNKNOWN UNKNOWN Legacy 10.17487/RFC0557 RFC0558 RFC0559 Comments on The New Telnet Protocol and its Implementation A.K. Bushan August 1973 ASCII 10643 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0559 RFC0560 Remote Controlled Transmission and Echoing Telnet option D. Crocker J. Postel August 1973 ASCII 22686 12 PDF 649235 RFC0581 UNKNOWN UNKNOWN Legacy 10.17487/RFC0560 RFC0561 Standardizing Network Mail Headers A.K. Bhushan K.T. Pogran R.S. Tomlinson J.E. White September 1973 ASCII 6159 3 RFC0680 UNKNOWN UNKNOWN Legacy 10.17487/RFC0561 RFC0562 Modifications to the TELNET Specification A.M. McKenzie August 1973 ASCII 2760 2 PDF 79307 RFC0495 UNKNOWN UNKNOWN Legacy 10.17487/RFC0562 RFC0563 Comments on the RCTE Telnet option J. Davidson August 1973 ASCII 10788 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0563 RFC0564 RFC0565 Storing network survey data at the datacomputer D. Cantor August 1973 ASCII 9307 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0565 RFC0566 Traffic statistics (August 1973) A.M. McKenzie September 1973 ASCII 6674 4 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0566 RFC0567 Cross Country Network Bandwidth L.P. Deutsch September 1973 ASCII 1529 1 RFC0568 UNKNOWN UNKNOWN Legacy 10.17487/RFC0567 RFC0568 Response to RFC 567 - cross country network bandwidth J.M. McQuillan September 1973 ASCII 3244 3 RFC0567 UNKNOWN UNKNOWN Legacy 10.17487/RFC0568 RFC0569 NETED: A Common Editor for the ARPA Network M.A. Padlipsky October 1973 ASCII 17717 6 NETED HISTORIC HISTORIC Legacy 10.17487/RFC0569 RFC0570 Experimental input mapping between NVT ASCII and UCSB On Line System J.R. Pickens October 1973 ASCII 177 1 PS 488023 PDF 375635 UNKNOWN UNKNOWN Legacy 10.17487/RFC0570 RFC0571 TENEX FTP PROBLEM R. Braden November 1973 ASCII 1530 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0571 RFC0572 RFC0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS A. Bhushan September 1973 ASCII 19474 8 PDF 543794 UNKNOWN UNKNOWN Legacy 10.17487/RFC0573 RFC0574 Announcement of a Mail Facility at UCSB M. Krilanovich September 1973 ASCII 1253 1 PDF 40358 UNKNOWN UNKNOWN Legacy 10.17487/RFC0574 RFC0575 RFC0576 Proposal for modifying linking K. Victor September 1973 ASCII 3916 2 PDF 175955 UNKNOWN UNKNOWN Legacy 10.17487/RFC0576 RFC0577 Mail priority D. Crocker October 1973 ASCII 2434 2 PDF 91292 UNKNOWN UNKNOWN Legacy 10.17487/RFC0577 RFC0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle A.K. Bhushan N.D. Ryan October 1973 ASCII 21185 9 PDF 1044808 UNKNOWN UNKNOWN Legacy 10.17487/RFC0578 RFC0579 Traffic statistics (September 1973) A.M. McKenzie November 1973 ASCII 7827 5 PDF 283306 RFC0566 RFC0586 UNKNOWN UNKNOWN Legacy 10.17487/RFC0579 RFC0580 Note to Protocol Designers and Implementers J. Postel October 1973 ASCII 1451 1 RFC0582 UNKNOWN UNKNOWN Legacy 10.17487/RFC0580 RFC0581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option D. Crocker J. Postel November 1973 ASCII 11060 5 PDF 385657 RFC0560 UNKNOWN UNKNOWN Legacy 10.17487/RFC0581 RFC0582 Comments on RFC 580: Machine readable protocols R. Clements November 1973 ASCII 1635 1 RFC0580 UNKNOWN UNKNOWN Legacy 10.17487/RFC0582 RFC0583 RFC0584 Charter for ARPANET Users Interest Working Group J. Iseli D. Crocker N. Neigus November 1973 ASCII 3461 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0584 RFC0585 ARPANET users interest working group meeting D. Crocker N. Neigus E.J. Feinler J. Iseli November 1973 ASCII 18243 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0585 RFC0586 Traffic statistics (October 1973) A.M. McKenzie November 1973 ASCII 7428 5 PDF 231714 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0586 RFC0587 Announcing New Telnet Options J. Postel November 1973 ASCII 832 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0587 RFC0588 London Node Is Now Up A. Stokes October 1973 ASCII 5608 3 PDF 180352 UNKNOWN UNKNOWN Legacy 10.17487/RFC0588 RFC0589 CCN NETRJS server messages to remote user R.T. Braden November 1973 ASCII 7998 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0589 RFC0590 MULTICS address change M.A. Padlipsky November 1973 ASCII 1436 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0590 RFC0591 Addition to the Very Distant Host specifications D.C. Walden November 1973 ASCII 901 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0591 RFC0592 Some thoughts on system design to facilitate resource sharing R.W. Watson November 1973 ASCII 10323 5 PDF 289505 UNKNOWN UNKNOWN Legacy 10.17487/RFC0592 RFC0593 Telnet and FTP implementation schedule change A.M. McKenzie J. Postel November 1973 ASCII 2506 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0593 RFC0594 Speedup of Host-IMP interface J.D. Burchfiel December 1973 ASCII 5855 3 PDF 182977 UNKNOWN UNKNOWN Legacy 10.17487/RFC0594 RFC0595 Second thoughts in defense of the Telnet Go-Ahead W. Hathaway December 1973 ASCII 13507 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0595 RFC0596 Second thoughts on Telnet Go-Ahead E.A. Taft December 1973 ASCII 11919 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0596 RFC0597 Host status N. Neigus E.J. Feinler December 1973 ASCII 11678 6 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0597 RFC0598 RFC index - December 5, 1973 Network Information Center. Stanford Research Institute December 1973 PDF 1078956 UNKNOWN UNKNOWN Legacy 10.17487/RFC0598 RFC0599 Update on NETRJS R.T. Braden December 1973 ASCII 16590 9 RFC0189 RFC0740 UNKNOWN UNKNOWN Legacy 10.17487/RFC0599 RFC0600 Interfacing an Illinois plasma terminal to the ARPANET A. Berggreen November 1973 ASCII 8510 3 PDF 213041

Discusses some unusual interface issues for the Plato terminal.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0600 RFC0601 Traffic statistics (November 1973) A.M. McKenzie December 1973 ASCII 9100 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0601 RFC0602 "The stockings were hung by the chimney with care" R.M. Metcalfe December 1973 ASCII 1988 1 security violations TIP arpanet

Susceptibility of ARPANET to security violations.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0602 RFC0603 Response to RFC 597: Host status J.D. Burchfiel December 1973 ASCII 1482 1

Questions about the ARPANET topology described in RFC 597.

 RFC0597 RFC0613 UNKNOWN UNKNOWN Legacy 10.17487/RFC0603 RFC0604 Assigned link numbers J. Postel December 1973 ASCII 2758 2

Modifies official host-host protocol. Replaces RFC 377.

 RFC0317 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0604 RFC0605 RFC0606 Host names on-line L.P. Deutsch December 1973 ASCII 6855 3 lists names host addresses

Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0606 RFC0607 Comments on the File Transfer Protocol M. Krilanovich G. Gregg January 1974 ASCII 8652 3 solutions weakness ftp

An old version; see RFC 624; see also RFCs 614, 542 and 640.

 RFC0624 RFC0614 UNKNOWN UNKNOWN Legacy 10.17487/RFC0607 RFC0608 Host names on-line M.D. Kudlick January 1974 ASCII 7010 4

Response to RFC 606; see also RFCs 627, 625 and 623.

 RFC0810 UNKNOWN UNKNOWN Legacy 10.17487/RFC0608 RFC0609 Statement of upcoming move of NIC/NLS service B. Ferguson January 1974 ASCII 1260 2

See also RFCs 621 and 620.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0609 RFC0610 Further datalanguage design concepts R. Winter J. Hill W. Greiff December 1973 ASCII 198692 88

Preliminary results of the language design; a model for data languagea semantics; future considerations.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0610 RFC0611 Two changes to the IMP/Host Protocol to improve user/network communications D.C. Walden February 1974 ASCII 7481 4

Expansion of Host-Going-Down and addition of Dead-Host-Status Message.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0611 RFC0612 Traffic statistics (December 1973) A.M. McKenzie January 1974 ASCII 9667 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0612 RFC0613 Network connectivity: A response to RFC 603 A.M. McKenzie January 1974 ASCII 2557 1 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0613 RFC0614 Response to RFC 607: "Comments on the File Transfer Protocol" K.T. Pogran N. Neigus January 1974 ASCII 11409 3 ftp weakness solutions

See also RFCs 624, 542 and 640.

 RFC0542 RFC0607 UNKNOWN UNKNOWN Legacy 10.17487/RFC0614 RFC0615 Proposed Network Standard Data Pathname syntax D. Crocker March 1974 ASCII 9448 4 RFC0645 UNKNOWN UNKNOWN Legacy 10.17487/RFC0615 RFC0616 LATEST NETWORK MAPS D. Walden February 1973 ASCII 848 1 PDF 117083 Network maps UNKNOWN UNKNOWN Legacy 10.17487/RFC0616 RFC0617 Note on socket number assignment E.A. Taft February 1974 ASCII 8062 3 telnet

Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0617 RFC0618 Few observations on NCP statistics E.A. Taft February 1974 ASCII 4929 3

Distribution of NCP and IMP message types by actual measurement.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0618 RFC0619 Mean round-trip times in the ARPANET W. Naylor H. Opderbeck March 1974 ASCII 30946 14

Actual measurements of round-trip times.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0619 RFC0620 Request for monitor host table updates B. Ferguson March 1974 ASCII 1950 1 tenex

In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0620 RFC0621 NIC user directories at SRI ARC M.D. Kudlick March 1974 ASCII 1351 1

See also RFCs 620 and 609.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0621 RFC0622 Scheduling IMP/TIP down time A.M. McKenzie March 1974 ASCII 4367 3

Modification of previous policy.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0622 RFC0623 Comments on on-line host name service M. Krilanovich February 1974 ASCII 3740 2

See also RFCs 627, 625, 608 and 606.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0623 RFC0624 Comments on the File Transfer Protocol M. Krilanovich G. Gregg W. Hathaway J.E. White February 1974 ASCII 10105 3 ftp telnet

Design changes and slight modifications. Replaces RFC 607; see also RFCs 614, 542 and 640.

 RFC0607 UNKNOWN UNKNOWN Legacy 10.17487/RFC0624 RFC0625 On-line hostnames service M.D. Kudlick E.J. Feinler March 1974 ASCII 2172 1

See also RFCs 606, 608, 623 and 627.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0625 RFC0626 On a possible lockup condition in IMP subnet due to message sequencing L. Kleinrock H. Opderbeck March 1974 ASCII 13150 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0626 RFC0627 ASCII text file of hostnames M.D. Kudlick E.J. Feinler March 1974 ASCII 2007 1

See also RFCs 606, 608, 623 and 625.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0627 RFC0628 Status of RFC numbers and a note on pre-assigned journal numbers M.L. Keeney March 1974 ASCII 1036 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0628 RFC0629 Scenario for using the Network Journal J.B. North March 1974 ASCII 4504 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0629 RFC0630 FTP error code usage for more reliable mail service J. Sussman April 1974 ASCII 4070 3

Describes FTP reply-code usage in TENEX mail processing.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0630 RFC0631 International meeting on minicomputers and data communication: Call for papers A. Danthine April 1974 ASCII 2707 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0631 RFC0632 Throughput degradations for single packet messages H. Opderbeck May 1974 ASCII 14563 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0632 RFC0633 IMP/TIP preventive maintenance schedule A.M. McKenzie March 1974 ASCII 3733 4

An old version; see RFC 638.

 RFC0638 UNKNOWN UNKNOWN Legacy 10.17487/RFC0633 RFC0634 Change in network address for Haskins Lab A.M. McKenzie April 1974 ASCII 1098 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0634 RFC0635 Assessment of ARPANET protocols V. Cerf April 1974 ASCII 338 1 PDF 3208268

Theoretical and practical motivation for redesign. Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0635 RFC0636 TIP/Tenex reliability improvements J.D. Burchfiel B. Cosell R.S. Tomlinson D.C. Walden June 1974 ASCII 19914 8

Obtaining/maintaining connections; recovery from lost connections; connection-state changes.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0636 RFC0637 Change of network address for SU-DSL A.M. McKenzie April 1974 ASCII 916 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0637 RFC0638 IMP/TIP preventive maintenance schedule A.M. McKenzie April 1974 ASCII 4088 4

Corrects RFC 633.

 RFC0633 UNKNOWN UNKNOWN Legacy 10.17487/RFC0638 RFC0639 RFC0640 Revised FTP reply codes J. Postel June 1974 ASCII 39670 17

Updates RFC 542.

 RFC0542 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=640 10.17487/RFC0640 RFC0641 RFC0642 Ready line philosophy and implementation J.D. Burchfiel July 1974 ASCII 8414 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0642 RFC0643 Network Debugging Protocol E. Mader July 1974 ASCII 12563 7

To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0643 RFC0644 On the problem of signature authentication for network mail R. Thomas July 1974 ASCII 9501 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0644 RFC0645 Network Standard Data Specification syntax D. Crocker June 1974 ASCII 16561 9 PDF 567325

Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.

 RFC0615 UNKNOWN UNKNOWN Legacy 10.17487/RFC0645 RFC0646 RFC0647 Proposed protocol for connecting host computers to ARPA-like networks via front end processors M.A. Padlipsky November 1974 ASCII 57785 20 PDF 1948940

Approaches to Front-End protocol processing using available hardware and software.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0647 RFC0648 RFC0649 RFC0650 RFC0651 Revised Telnet status option D. Crocker October 1974 ASCII 4360 2 RFC0859 UNKNOWN UNKNOWN Legacy 10.17487/RFC0651 RFC0652 Telnet output carriage-return disposition option D. Crocker October 1974 ASCII 7003 4 TOPT-OCRD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0652 RFC0653 Telnet output horizontal tabstops option D. Crocker October 1974 ASCII 4694 1 TOPT-OHT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0653 RFC0654 Telnet output horizontal tab disposition option D. Crocker October 1974 ASCII 6158 1 TOPT-OHTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0654 RFC0655 Telnet output formfeed disposition option D. Crocker October 1974 ASCII 5991 1 TOPT-OFD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0655 RFC0656 Telnet output vertical tabstops option D. Crocker October 1974 ASCII 4858 1 TOPT-OVT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0656 RFC0657 Telnet output vertical tab disposition option D. Crocker October 1974 ASCII 5759 1 TOPT-OVTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0657 RFC0658 Telnet output linefeed disposition D. Crocker October 1974 ASCII 6484 2 TOPT-OLD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0658 RFC0659 Announcing additional Telnet options J. Postel October 1974 ASCII 2016 1

Options defined in RFCs 651-658.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0659 RFC0660 Some changes to the IMP and the IMP/Host interface D.C. Walden October 1974 ASCII 4991 1

Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0660 RFC0661 Protocol information J. Postel November 1974 ASCII 29534 21 PDF 1071305

An old version; see RFC 694.

 RFC0694 UNKNOWN UNKNOWN Legacy 10.17487/RFC0661 RFC0662 Performance improvement in ARPANET file transfers from Multics R. Kanodia November 1974 ASCII 8872 2

Experimenting with host output buffers to improve throughput.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0662 RFC0663 Lost message detection and recovery protocol R. Kanodia November 1974 ASCII 44702 22 ARPANET Host

Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0663 RFC0664 RFC0665 RFC0666 Specification of the Unified User-Level Protocol M.A. Padlipsky November 1974 ASCII 49024 19

Discusses and proposes a common command language.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0666 RFC0667 Host Ports S.G. Chipman December 1974 ASCII 3244 2 PDF 52660

Approved scheme to connect host ports to the network.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0667 RFC0668 RFC0669 November, 1974, survey of New-Protocol Telnet servers D.W. Dodds December 1974 ASCII 5121 3 PDF 134962

An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679.

 RFC0702 RFC0679 UNKNOWN UNKNOWN Legacy 10.17487/RFC0669 RFC0670 RFC0671 Note on Reconnection Protocol R. Schantz December 1974 ASCII 24125 9 PDF 686491

Experience with implementation in RSEXEC context.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0671 RFC0672 Multi-site data collection facility R. Schantz December 1974 ASCII 25736 9

Applicability of TIP/TENEX protocols beyond TIP accounting.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0672 RFC0673 RFC0674 Procedure call documents: Version 2 J. Postel J.E. White December 1974 ASCII 12178 6

Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0674 RFC0675 Specification of Internet Transmission Control Program V. Cerf Y. Dalal C. Sunshine December 1974 ASCII 156874 70

The first detailed specification of TCP; see RFC 793.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0675 RFC0676 RFC0677 Maintenance of duplicate databases P.R. Johnson R. Thomas January 1975 ASCII 22990 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0677 RFC0678 Standard file formats J. Postel December 1974 ASCII 12393 9

For transmission of documents across different environments.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0678 RFC0679 February, 1975, survey of New-Protocol Telnet servers D.W. Dodds February 1975 ASCII 5263 3 PDF 142853

An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703.

 RFC0669 RFC0703 UNKNOWN UNKNOWN Legacy 10.17487/RFC0679 RFC0680 Message Transmission Protocol T.H. Myer D.A. Henderson April 1975 ASCII 11539 6

Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.

 RFC0561 UNKNOWN UNKNOWN Legacy 10.17487/RFC0680 RFC0681 Network UNIX S. Holmgren March 1975 ASCII 18874 8

Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0681 RFC0682 RFC0683 FTPSRV - Tenex extension for paged files R. Clements April 1975 ASCII 8806 3 FTP paged file transfer Tenex

Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.

 RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0683 RFC0684 Commentary on procedure calling as a network protocol R. Schantz April 1975 ASCII 21164 9

Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0684 RFC0685 Response time in cross network debugging M. Beeler April 1975 ASCII 6914 3

The contribution of ARPANET communication to response time.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0685 RFC0686 Leaving well enough alone B. Harvey May 1975 ASCII 24605 9

Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0686 RFC0687 IMP/Host and Host/IMP Protocol changes D.C. Walden June 1975 ASCII 6013 2

Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.

 RFC0704 RFC0690 UNKNOWN UNKNOWN Legacy 10.17487/RFC0687 RFC0688 Tentative schedule for the new Telnet implementation for the TIP D.C. Walden June 1975 ASCII 1593 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0688 RFC0689 Tenex NCP finite state machine for connections R. Clements May 1975 ASCII 13101 5

Describes the internal states of an NCP connection in the TENEX implementation.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0689 RFC0690 Comments on the proposed Host/IMP Protocol changes J. Postel June 1975 ASCII 7215 3

Comments on suggestions in RFC 687; see also RFCs 692 and 696.

 RFC0687 RFC0692 UNKNOWN UNKNOWN Legacy 10.17487/RFC0690 RFC0691 One more try on the FTP B. Harvey June 1975 ASCII 32821 14

Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0691 RFC0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690) S.M. Wolfe June 1975 ASCII 2681 2

A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.

 RFC0690 UNKNOWN UNKNOWN Legacy 10.17487/RFC0692 RFC0693 RFC0694 Protocol information J. Postel June 1975 ASCII 52961 36 PDF 1457530

References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.

 RFC0661 UNKNOWN UNKNOWN Legacy 10.17487/RFC0694 RFC0695 Official change in Host-Host Protocol M. Krilanovich July 1975 ASCII 3425 3

Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0695 RFC0696 Comments on the IMP/Host and Host/IMP Protocol changes V.G. Cerf July 1975 ASCII 4432 2 PDF 227873

Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0696 RFC0697 CWD command of FTP J. Lieb July 1975 ASCII 3047 2

Discusses FTP login access to "files only" directories.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0697 RFC0698 Telnet extended ASCII option T. Mock July 1975 ASCII 5086 3 TOPT-EXT

Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.

 RFC5198 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0698 RFC0699 Request For Comments summary notes: 600-699 J. Postel J. Vernon November 1982 ASCII 14688 9 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0699 RFC0700 Protocol experiment E. Mader W.W. Plummer R.S. Tomlinson August 1974 ASCII 14600 7 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0700 RFC0701 August, 1974, survey of New-Protocol Telnet servers D.W. Dodds August 1974 ASCII 3549 1 RFC0702 UNKNOWN UNKNOWN Legacy 10.17487/RFC0701 RFC0702 September, 1974, survey of New-Protocol Telnet servers D.W. Dodds September 1974 ASCII 5386 3 RFC0701 RFC0669 UNKNOWN UNKNOWN Legacy 10.17487/RFC0702 RFC0703 July, 1975, survey of New-Protocol Telnet Servers D.W. Dodds July 1975 ASCII 5691 3 RFC0679 UNKNOWN UNKNOWN Legacy 10.17487/RFC0703 RFC0704 IMP/Host and Host/IMP Protocol change P.J. Santos September 1975 ASCII 7504 2 RFC0687 UNKNOWN UNKNOWN Legacy 10.17487/RFC0704 RFC0705 Front-end Protocol B6700 version R.F. Bryan November 1975 ASCII 70998 39 UNKNOWN UNKNOWN Legacy 10.17487/RFC0705 RFC0706 On the junk mail problem J. Postel November 1975 ASCII 2085 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0706 RFC0707 High-level framework for network-based resource sharing J.E. White December 1975 ASCII 57254 29 UNKNOWN UNKNOWN Legacy 10.17487/RFC0707 RFC0708 Elements of a Distributed Programming System J.E. White January 1976 ASCII 57888 30 UNKNOWN UNKNOWN Legacy 10.17487/RFC0708 RFC0709 RFC0710 RFC0711 RFC0712 Distributed Capability Computing System (DCCS) J.E. Donnelley February 1976 ASCII 40127 17 PDF 1201164 UNKNOWN UNKNOWN Legacy 10.17487/RFC0712 RFC0713 MSDTP-Message Services Data Transmission Protocol J. Haverty April 1976 ASCII 41175 21 UNKNOWN UNKNOWN Legacy 10.17487/RFC0713 RFC0714 Host-Host Protocol for an ARPANET-Type Network A.M. McKenzie April 1976 ASCII 56322 22 PDF 1599012 UNKNOWN UNKNOWN Legacy 10.17487/RFC0714 RFC0715 RFC0716 Interim Revision to Appendix F of BBN 1822 D.C. Walden J. Levin May 1976 ASCII 3345 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0716 RFC0717 Assigned Network Numbers J. Postel July 1976 ASCII 2322 1 HISTORIC UNKNOWN Legacy 10.17487/RFC0717 RFC0718 Comments on RCTE from the Tenex Implementation Experience J. Postel June 1976 ASCII 3829 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0718 RFC0719 Discussion on RCTE J. Postel July 1976 ASCII 4708 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0719 RFC0720 Address Specification Syntax for Network Mail D. Crocker August 1976 ASCII 6602 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0720 RFC0721 Out-of-Band Control Signals in a Host-to-Host Protocol L.L. Garlick September 1976 ASCII 13566 7 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0721 RFC0722 Thoughts on Interactions in Distributed Services J. Haverty September 1976 ASCII 29478 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0722 RFC0723 RFC0724 Proposed official standard for the format of ARPA Network messages D. Crocker K.T. Pogran J. Vittal D.A. Henderson May 1977 ASCII 75554 36 RFC0733 UNKNOWN UNKNOWN Legacy 10.17487/RFC0724 RFC0725 RJE protocol for a resource sharing network J.D. Day G.R. Grossman March 1977 ASCII 44025 27 UNKNOWN UNKNOWN Legacy 10.17487/RFC0725 RFC0726 Remote Controlled Transmission and Echoing Telnet option J. Postel D. Crocker March 1977 ASCII 38651 16 TOPT-REM PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0726 RFC0727 Telnet logout option M.R. Crispin April 1977 ASCII 5674 3 TOPT-LOGO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0727 RFC0728 Minor pitfall in the Telnet Protocol J.D. Day April 1977 ASCII 2224 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0728 RFC0729 Telnet byte macro option D. Crocker May 1977 ASCII 6509 3 RFC0735 UNKNOWN UNKNOWN Legacy 10.17487/RFC0729 RFC0730 Extensible field addressing J. Postel May 1977 ASCII 9519 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0730 RFC0731 Telnet Data Entry Terminal option J.D. Day June 1977 ASCII 61648 28 RFC0732 UNKNOWN UNKNOWN Legacy 10.17487/RFC0731 RFC0732 Telnet Data Entry Terminal option J.D. Day September 1977 ASCII 57160 30 RFC0731 RFC1043 UNKNOWN UNKNOWN Legacy 10.17487/RFC0732 RFC0733 Standard for the format of ARPA network text messages D. Crocker J. Vittal K.T. Pogran D.A. Henderson November 1977 ASCII 73006 38 RFC0724 RFC0822 UNKNOWN UNKNOWN Legacy 10.17487/RFC0733 RFC0734 SUPDUP Protocol M.R. Crispin October 1977 ASCII 33256 13 SUPDUP HISTORIC HISTORIC Legacy 10.17487/RFC0734 RFC0735 Revised Telnet byte macro option D. Crocker R.H. Gumpertz November 1977 ASCII 10585 5 TOPT-BYTE RFC0729 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0735 RFC0736 Telnet SUPDUP option M.R. Crispin October 1977 ASCII 3081 1 TOPT-SUP PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0736 RFC0737 FTP extension: XSEN K. Harrenstien October 1977 ASCII 2127 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0737 RFC0738 Time server K. Harrenstien October 1977 ASCII 1851 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0738 RFC0739 Assigned numbers J. Postel November 1977 ASCII 16346 11 RFC0604 RFC0503 RFC0750 HISTORIC UNKNOWN Legacy 10.17487/RFC0739 RFC0740 NETRJS Protocol R.T. Braden November 1977 ASCII 38833 19 NETRJS RFC0599 HISTORIC HISTORIC Legacy 10.17487/RFC0740 RFC0741 Specifications for the Network Voice Protocol (NVP) D. Cohen November 1977 ASCII 57581 34 UNKNOWN UNKNOWN Legacy 10.17487/RFC0741 RFC0742 NAME/FINGER Protocol K. Harrenstien December 1977 ASCII 12321 7 RFC1288 RFC1196 RFC1194 UNKNOWN UNKNOWN Legacy 10.17487/RFC0742 RFC0743 FTP extension: XRSQ/XRCP K. Harrenstien December 1977 ASCII 16249 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0743 RFC0744 MARS - a Message Archiving and Retrieval Service J. Sattley January 1978 ASCII 10984 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0744 RFC0745 JANUS interface specifications M. Beeler March 1978 ASCII 21453 10 JANUS interface specifications UNKNOWN UNKNOWN Legacy 10.17487/RFC0745 RFC0746 SUPDUP graphics extension R. Stallman March 1978 ASCII 30197 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0746 RFC0747 Recent extensions to the SUPDUP Protocol M.R. Crispin March 1978 ASCII 2870 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0747 RFC0748 Telnet randomly-lose option M.R. Crispin April 1 1978 ASCII 2741 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0748 RFC0749 Telnet SUPDUP-Output option B. Greenberg September 1978 ASCII 8933 4 TOPT-SUPO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0749 RFC0750 Assigned numbers J. Postel September 1978 ASCII 19979 12 RFC0739 RFC0755 HISTORIC UNKNOWN Legacy 10.17487/RFC0750 RFC0751 Survey of FTP mail and MLFL P.D. Lebling December 1978 ASCII 10069 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0751 RFC0752 Universal host table M.R. Crispin January 1979 ASCII 33793 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0752 RFC0753 Internet Message Protocol J. Postel March 1979 ASCII 93363 62 UNKNOWN UNKNOWN Legacy 10.17487/RFC0753 RFC0754 Out-of-net host addresses for mail J. Postel April 1979 ASCII 19212 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0754 RFC0755 Assigned numbers J. Postel May 1979 ASCII 22039 12 RFC0750 RFC0758 HISTORIC UNKNOWN Legacy 10.17487/RFC0755 RFC0756 NIC name server - a datagram-based information utility J.R. Pickens E.J. Feinler J.E. Mathis July 1979 ASCII 23491 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0756 RFC0757 Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems D.P. Deutsch September 1979 ASCII 35618 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0757 RFC0758 Assigned numbers J. Postel August 1979 ASCII 22911 12 RFC0755 RFC0762 HISTORIC UNKNOWN Legacy 10.17487/RFC0758 RFC0759 Internet Message Protocol J. Postel August 1980 ASCII 123606 77 MPM HISTORIC HISTORIC Legacy 10.17487/RFC0759 RFC0760 DoD standard Internet Protocol J. Postel January 1980 ASCII 81507 46 IEN123 RFC0791 RFC0777 UNKNOWN UNKNOWN Legacy 10.17487/RFC0760 RFC0761 DoD standard Transmission Control Protocol J. Postel January 1980 ASCII 167049 88 TCP RFC0793 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0761 RFC0762 Assigned numbers J. Postel January 1980 ASCII 24668 13 RFC0758 RFC0770 HISTORIC UNKNOWN Legacy 10.17487/RFC0762 RFC0763 Role mailboxes M.D. Abrams May 1980 ASCII 942 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0763 RFC0764 Telnet Protocol specification J. Postel June 1980 ASCII 40005 15 RFC0854 UNKNOWN UNKNOWN Legacy 10.17487/RFC0764 RFC0765 File Transfer Protocol specification J. Postel June 1980 ASCII 146641 70 RFC0542 RFC0959 UNKNOWN UNKNOWN Legacy 10.17487/RFC0765 RFC0766 Internet Protocol Handbook: Table of contents J. Postel July 1980 ASCII 3465 2 RFC0774 UNKNOWN UNKNOWN Legacy 10.17487/RFC0766 RFC0767 Structured format for transmission of multi-media documents J. Postel August 1980 ASCII 59971 40 UNKNOWN UNKNOWN Legacy 10.17487/RFC0767 RFC0768 User Datagram Protocol J. Postel August 1980 ASCII 5896 3 UDP UDP STD0006 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0768 RFC0769 Rapicom 450 facsimile file format J. Postel September 1980 ASCII 4079 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0769 RFC0770 Assigned numbers J. Postel September 1980 ASCII 26248 15 RFC0762 RFC0776 HISTORIC UNKNOWN Legacy 10.17487/RFC0770 RFC0771 Mail transition plan V.G. Cerf J. Postel September 1980 ASCII 18623 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0771 RFC0772 Mail Transfer Protocol S. Sluizer J. Postel September 1980 ASCII 61061 31 MTP email RFC0780 UNKNOWN UNKNOWN Legacy 10.17487/RFC0772 RFC0773 Comments on NCP/TCP mail service transition strategy V.G. Cerf October 1980 ASCII 22181 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0773 RFC0774 Internet Protocol Handbook: Table of contents J. Postel October 1980 ASCII 3452 3 RFC0766 UNKNOWN UNKNOWN Legacy 10.17487/RFC0774 RFC0775 Directory oriented FTP commands D. Mankins D. Franklin A.D. Owen December 1980 ASCII 9511 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0775 RFC0776 Assigned numbers J. Postel January 1981 ASCII 30311 13 RFC0770 RFC0790 HISTORIC UNKNOWN Legacy 10.17487/RFC0776 RFC0777 Internet Control Message Protocol J. Postel April 1981 ASCII 19407 14 RFC0792 RFC0760 UNKNOWN UNKNOWN Legacy 10.17487/RFC0777 RFC0778 DCNET Internet Clock Service D.L. Mills April 1981 ASCII 9464 4 CLOCK HISTORIC HISTORIC Legacy 10.17487/RFC0778 RFC0779 Telnet send-location option E. Killian April 1981 ASCII 2564 2 TOPT-SNDL PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0779 RFC0780 Mail Transfer Protocol S. Sluizer J. Postel May 1981 ASCII 80352 47 MTP email RFC0772 RFC0788 UNKNOWN UNKNOWN Legacy 10.17487/RFC0780 RFC0781 Specification of the Internet Protocol (IP) timestamp option Z. Su May 1981 ASCII 4002 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0781 RFC0782 Virtual Terminal management model J. Nabielsky A.P. Skelton January 1981 ASCII 43589 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0782 RFC0783 TFTP Protocol (revision 2) K.R. Sollins June 1981 ASCII 23522 18 IEN133 RFC1350 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=783 10.17487/RFC0783 RFC0784 Mail Transfer Protocol: ISI TOPS20 implementation S. Sluizer J. Postel July 1981 ASCII 5856 3 MTP email UNKNOWN UNKNOWN Legacy 10.17487/RFC0784 RFC0785 Mail Transfer Protocol: ISI TOPS20 file definitions S. Sluizer J. Postel July 1981 ASCII 7032 3 MTP email UNKNOWN UNKNOWN Legacy 10.17487/RFC0785 RFC0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface S. Sluizer J. Postel July 1981 ASCII 3129 2 MTP NIMAIL TOPS20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0786 RFC0787 Connectionless data transmission survey/tutorial A.L. Chapin July 1981 ASCII 84265 40 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=787 10.17487/RFC0787 RFC0788 Simple Mail Transfer Protocol J. Postel November 1981 ASCII 109001 64 SMTP email RFC0780 RFC0821 UNKNOWN UNKNOWN Legacy 10.17487/RFC0788 RFC0789 Vulnerabilities of network control protocols: An example E.C. Rosen July 1981 ASCII 25541 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0789 RFC0790 Assigned numbers J. Postel September 1981 ASCII 35316 15 RFC0776 RFC0820 HISTORIC UNKNOWN Legacy 10.17487/RFC0790 RFC0791 Internet Protocol J. Postel September 1981 ASCII 97779 51 IP IPv4 RFC0760 RFC1349 RFC2474 RFC6864 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=791 10.17487/RFC0791 RFC0792 Internet Control Message Protocol J. Postel September 1981 ASCII 30404 21 ICMP RFC0777 RFC0950 RFC4884 RFC6633 RFC6918 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=792 10.17487/RFC0792 RFC0793 Transmission Control Protocol J. Postel September 1981 ASCII 172710 91 TCP TCP RFC0761 RFC1122 RFC3168 RFC6093 RFC6528 STD0007 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=793 10.17487/RFC0793 RFC0794 Pre-emption V.G. Cerf September 1981 ASCII 5906 2 IEN125 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0794 RFC0795 Service mappings J. Postel September 1981 ASCII 5228 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0795 RFC0796 Address mappings J. Postel September 1981 ASCII 11239 7 IEN115 HISTORIC UNKNOWN Legacy 10.17487/RFC0796 RFC0797 Format for Bitmap files A.R. Katz September 1981 ASCII 3067 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0797 RFC0798 Decoding facsimile data from the Rapicom 450 A.R. Katz September 1981 ASCII 38867 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0798 RFC0799 Internet name domains D.L. Mills September 1981 ASCII 13896 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0799 RFC0800 Request For Comments summary notes: 700-799 J. Postel J. Vernon November 1982 ASCII 18354 10

This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0800 RFC0801 NCP/TCP transition plan J. Postel November 1981 ASCII 42041 21

This RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0801 RFC0802 ARPANET 1822L Host Access Protocol A.G. Malis November 1981 ASCII 62470 45

This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851.

 RFC0851 UNKNOWN UNKNOWN Legacy 10.17487/RFC0802 RFC0803 Dacom 450/500 facsimile data transcoding A. Agarwal M.J. O'Connor D.L. Mills November 1981 ASCII 33826 14

The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum. The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0803 RFC0804 CCITT draft recommendation T.4 International Telegraph and Telephone Consultative Committee of the International Telecommunication Union January 1981 ASCII 17025 12

This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=804 10.17487/RFC0804 RFC0805 Computer mail meeting notes J. Postel February 1982 ASCII 12522 6

This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further strutured.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0805 RFC0806 Proposed Federal Information Processing Standard: Specification for message format for computer based message systems National Bureau of Standards September 1981 ASCII 216377 107

This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841.

 RFC0841 UNKNOWN UNKNOWN Legacy 10.17487/RFC0806 RFC0807 Multimedia mail meeting notes J. Postel February 1982 ASCII 11633 6

This RFC consists of notes from a meeting held at USC Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0807 RFC0808 Summary of computer mail services meeting held at BBN on 10 January 1979 J. Postel March 1982 ASCII 15930 8

This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0808 RFC0809 UCL facsimile system T. Chang February 1982 ASCII 171153 99

This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work are reported. Then the disciplines for system design are discussed. Finally, the implementation of the system are described, while detailed description are given as appendices.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0809 RFC0810 DoD Internet host table specification E.J. Feinler K. Harrenstien Z. Su V. White March 1982 ASCII 14196 8

This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.

 RFC0608 RFC0952 UNKNOWN UNKNOWN Legacy 10.17487/RFC0810 RFC0811 Hostnames Server K. Harrenstien V. White E.J. Feinler March 1982 ASCII 7771 4

This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment.

 RFC0953 UNKNOWN UNKNOWN Legacy 10.17487/RFC0811 RFC0812 NICNAME/WHOIS K. Harrenstien V. White March 1982 ASCII 5389 2

This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.

 RFC0954 RFC3912 UNKNOWN UNKNOWN Legacy 10.17487/RFC0812 RFC0813 Window and Acknowledgement Strategy in TCP D.D. Clark July 1982 ASCII 38110 21

This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0813 RFC0814 Name, addresses, ports, and routes D.D. Clark July 1982 ASCII 24663 13

This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0814 RFC0815 IP datagram reassembly algorithms D.D. Clark July 1982 ASCII 14575 8

This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0815 RFC0816 Fault isolation and recovery D.D. Clark July 1982 ASCII 20106 11

This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0816 RFC0817 Modularity and efficiency in protocol implementation D.D. Clark July 1982 ASCII 45931 25

This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0817 RFC0818 Remote User Telnet service J. Postel November 1982 ASCII 3693 2 RTELNET

This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.

 HISTORIC HISTORIC Legacy 10.17487/RFC0818 RFC0819 The Domain Naming Convention for Internet User Applications Z. Su J. Postel August 1982 ASCII 35314 18

This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0819 RFC0820 Assigned numbers J. Postel August 1982 ASCII 54213 22

This RFC is an old version, see RFC 870.

 RFC0790 RFC0870 HISTORIC UNKNOWN Legacy 10.17487/RFC0820 RFC0821 Simple Mail Transfer Protocol J. Postel August 1982 ASCII 124482 72 SMTP

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772.

 RFC0788 RFC2821 STD0010 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0821 RFC0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES D. Crocker August 1982 ASCII 106299 49 MAIL

This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.

 RFC0733 RFC2822 RFC1123 RFC2156 RFC1327 RFC1138 RFC1148 STD0011 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=822 10.17487/RFC0822 RFC0823 DARPA Internet gateway R.M. Hinden A. Sheltzer September 1982 ASCII 62620 45 GGP

This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.

 IEN109 IEN30 HISTORIC HISTORIC Legacy 10.17487/RFC0823 RFC0824 CRONUS Virtual Local Network W.I. MacGregor D.C. Tappan August 1982 ASCII 58732 41

The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0824 RFC0825 Request for comments on Requests For Comments J. Postel November 1982 ASCII 4255 2

This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs.

 RFC1111 RFC1543 RFC2223 UNKNOWN UNKNOWN Legacy 10.17487/RFC0825 RFC0826 Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware D. Plummer November 1982 ASCII 21556 10 ARP

The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard.

 RFC5227 RFC5494 STD0037 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0826 RFC0827 Exterior Gateway Protocol (EGP) E.C. Rosen October 1982 ASCII 68436 46

This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged.

 RFC0904 UNKNOWN UNKNOWN Legacy 10.17487/RFC0827 RFC0828 Data communications: IFIP's international "network" of experts K. Owen August 1982 ASCII 29922 11

This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0828 RFC0829 Packet satellite technology reference sources V.G. Cerf November 1982 ASCII 10919 5

This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0829 RFC0830 Distributed system for Internet name service Z. Su October 1982 ASCII 31597 18

This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0830 RFC0831 Backup access to the European side of SATNET R.T. Braden December 1982 ASCII 11735 6

The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0831 RFC0832 Who talks TCP? D. Smallberg December 1982 ASCII 42751 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.

 RFC0833 UNKNOWN UNKNOWN Legacy 10.17487/RFC0832 RFC0833 Who talks TCP? D. Smallberg December 1982 ASCII 42973 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.

 RFC0832 RFC0834 UNKNOWN UNKNOWN Legacy 10.17487/RFC0833 RFC0834 Who talks TCP? D. Smallberg December 1982 ASCII 42764 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82.

 RFC0833 RFC0835 UNKNOWN UNKNOWN Legacy 10.17487/RFC0834 RFC0835 Who talks TCP? D. Smallberg December 1982 ASCII 42959 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83.

 RFC0834 RFC0836 UNKNOWN UNKNOWN Legacy 10.17487/RFC0835 RFC0836 Who talks TCP? D. Smallberg January 1983 ASCII 43643 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83.

 RFC0835 RFC0837 UNKNOWN UNKNOWN Legacy 10.17487/RFC0836 RFC0837 Who talks TCP? D. Smallberg January 1983 ASCII 44864 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83.

 RFC0836 RFC0838 UNKNOWN UNKNOWN Legacy 10.17487/RFC0837 RFC0838 Who talks TCP? D. Smallberg January 1983 ASCII 45033 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83.

 RFC0837 RFC0839 UNKNOWN UNKNOWN Legacy 10.17487/RFC0838 RFC0839 Who talks TCP? D. Smallberg January 1983 ASCII 45175 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83.

 RFC0838 RFC0842 UNKNOWN UNKNOWN Legacy 10.17487/RFC0839 RFC0840 Official protocols J. Postel April 1983 ASCII 33534 23

This RFC has been revised, see RFC 880.

 RFC0880 HISTORIC UNKNOWN Legacy 10.17487/RFC0840 RFC0841 Specification for message format for Computer Based Message Systems National Bureau of Standards January 1983 ASCII 231871 117

This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. Obsoletes RFC 806.

 RFC0806 UNKNOWN UNKNOWN Legacy 10.17487/RFC0841 RFC0842 Who talks TCP? - survey of 1 February 83 D. Smallberg February 1983 ASCII 45962 12

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.

 RFC0839 RFC0843 UNKNOWN UNKNOWN Legacy 10.17487/RFC0842 RFC0843 Who talks TCP? - survey of 8 February 83 D. Smallberg February 1983 ASCII 46193 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.

 RFC0842 RFC0845 RFC0844 UNKNOWN UNKNOWN Legacy 10.17487/RFC0843 RFC0844 Who talks ICMP, too? - Survey of 18 February 1983 R. Clements February 1983 ASCII 9078 5

This survey determines how many hosts are able to respond to TELENET connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses. The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting TELNET connection. The tests were run on 18-Feb-83.

 RFC0843 UNKNOWN UNKNOWN Legacy 10.17487/RFC0844 RFC0845 Who talks TCP? - survey of 15 February 1983 D. Smallberg February 1983 ASCII 45983 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.

 RFC0843 RFC0846 UNKNOWN UNKNOWN Legacy 10.17487/RFC0845 RFC0846 Who talks TCP? - survey of 22 February 1983 D. Smallberg February 1983 ASCII 45597 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.

 RFC0845 RFC0847 UNKNOWN UNKNOWN Legacy 10.17487/RFC0846 RFC0847 Summary of Smallberg surveys A. Westine D. Smallberg J. Postel February 1983 ASCII 3789 2

This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).

 RFC0846 UNKNOWN UNKNOWN Legacy 10.17487/RFC0847 RFC0848 Who provides the "little" TCP services? D. Smallberg March 1983 ASCII 10985 5

This RFC lists those hosts which provide any of these "little" TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0848 RFC0849 Suggestions for improved host table distribution M.R. Crispin May 1983 ASCII 5178 2

This RFC actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0849 RFC0850 Standard for interchange of USENET messages M.R. Horton June 1983 ASCII 43871 17

This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.

 RFC1036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0850 RFC0851 ARPANET 1822L Host Access Protocol A.G. Malis April 1983 ASCII 72042 47

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802.

 RFC0802 RFC0878 UNKNOWN UNKNOWN Legacy 10.17487/RFC0851 RFC0852 ARPANET short blocking feature A.G. Malis April 1983 ASCII 17151 13

This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0852 RFC0853 RFC0854 Telnet Protocol Specification J. Postel J.K. Reynolds May 1983 ASCII 39371 15 TELNET

This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639.

 RFC0764 RFC5198 STD0008 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=854 10.17487/RFC0854 RFC0855 Telnet Option Specifications J. Postel J.K. Reynolds May 1983 ASCII 6218 3 TELNET

This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.

 NIC18640 STD0008 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0855 RFC0856 Telnet Binary Transmission J. Postel J. Reynolds May 1983 ASCII 8965 4 TOPT-BIN

This Telnet Option enables a binary data mode between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15389.

 NIC15389 STD0027 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0856 RFC0857 Telnet Echo Option J. Postel J. Reynolds May 1983 ASCII 10859 5 TOPT-ECHO

This Telnet Option enables remote echoing by the other Telnet module. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15390.

 NIC15390 STD0028 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0857 RFC0858 Telnet Suppress Go Ahead Option J. Postel J. Reynolds May 1983 ASCII 3712 2 TOPT-SUPP

This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15392.

 NIC15392 STD0029 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0858 RFC0859 Telnet Status Option J. Postel J. Reynolds May 1983 ASCII 4273 3 TOPT-STAT

This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).

 RFC0651 STD0030 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0859 RFC0860 Telnet Timing Mark Option J. Postel J. Reynolds May 1983 ASCII 7881 4 TOPT-TIM

This Telnet Option provides a way to check the roundtrip path between two Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16238.

 NIC16238 STD0031 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0860 RFC0861 Telnet Extended Options: List Option J. Postel J. Reynolds May 1983 ASCII 3068 2 TOPT-EXTOP

This Telnet Option provides a mechanism for extending the set of possible options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16239.

 NIC16239 STD0032 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0861 RFC0862 Echo Protocol J. Postel May 1983 ASCII 1237 1 ECHO

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard. The Echo service simply sends back to the originating source any data it receives.

 STD0020 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0862 RFC0863 Discard Protocol J. Postel May 1983 ASCII 1239 1 DISCARD

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard. The Discard service simply throws away any data it receives.

 STD0021 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0863 RFC0864 Character Generator Protocol J. Postel May 1983 ASCII 6842 3 CHARGEN

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input.

 STD0022 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0864 RFC0865 Quote of the Day Protocol J. Postel May 1983 ASCII 1676 1 QUOTE

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input.

 STD0023 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0865 RFC0866 Active users J. Postel May 1983 ASCII 2029 1 USERS

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard. The Active Users service simply sends a list of the currently active users on the host without regard to the input.

 STD0024 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0866 RFC0867 Daytime Protocol J. Postel May 1983 ASCII 2289 2 DAYTIME

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard. The Daytime service simply sends the current date and time as a character string without regard to the input.

 STD0025 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0867 RFC0868 Time Protocol J. Postel K. Harrenstien May 1983 ASCII 3024 2 TIME

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900.

 STD0026 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=868 10.17487/RFC0868 RFC0869 Host Monitoring Protocol R. Hinden December 1983 ASCII 94550 72 HMP HMP

This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.

 HISTORIC HISTORIC Legacy 10.17487/RFC0869 RFC0870 Assigned numbers J.K. Reynolds J. Postel October 1983 ASCII 56055 26

This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.

 RFC0820 RFC0900 HISTORIC UNKNOWN Legacy 10.17487/RFC0870 RFC0871 Perspective on the ARPANET reference model M.A. Padlipsky September 1982 ASCII 74455 29

This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0871 RFC0872 TCP-on-a-LAN M.A. Padlipsky September 1982 ASCII 22446 10 TCP LAN

This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0872 RFC0873 Illusion of vendor support M.A. Padlipsky September 1982 ASCII 23095 12

This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0873 RFC0874 Critique of X.25 M.A. Padlipsky September 1982 ASCII 36386 17

This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects. The memo also touches on security, and implementation issues. Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0874 RFC0875 Gateways, architectures, and heffalumps M.A. Padlipsky September 1982 ASCII 22816 10

This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0875 RFC0876 Survey of SMTP implementations D. Smallberg September 1983 ASCII 37775 13

This RFC is a survey of implementation status. It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol. It is expected that the status of the hosts reported on will change. This information must be treated as a snapshot of the state of these implemetations.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0876 RFC0877 Standard for the transmission of IP datagrams over public data networks J.T. Korb September 1983 ASCII 3272 2

This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.

 RFC1356 UNKNOWN UNKNOWN Legacy 10.17487/RFC0877 RFC0878 ARPANET 1822L Host Access Protocol A.G. Malis December 1983 ASCII 74774 51

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.

 RFC0851 UNKNOWN UNKNOWN Legacy 10.17487/RFC0878 RFC0879 The TCP Maximum Segment Size and Related Topics J. Postel November 1983 ASCII 22024 11

This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".

 RFC7805 RFC6691 HISTORIC UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=879 10.17487/RFC0879 RFC0880 Official protocols J.K. Reynolds J. Postel October 1983 ASCII 37332 26

This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840.

 RFC0840 RFC0901 HISTORIC UNKNOWN Legacy 10.17487/RFC0880 RFC0881 Domain names plan and schedule J. Postel November 1983 ASCII 23490 10

This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.

 RFC0897 UNKNOWN UNKNOWN Legacy 10.17487/RFC0881 RFC0882 Domain names: Concepts and facilities P.V. Mockapetris November 1983 ASCII 79776 31

This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.

 RFC1034 RFC1035 RFC0973 UNKNOWN UNKNOWN Legacy 10.17487/RFC0882 RFC0883 Domain names: Implementation specification P.V. Mockapetris November 1983 ASCII 175067 74

This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.

 RFC1034 RFC1035 RFC0973 UNKNOWN UNKNOWN Legacy 10.17487/RFC0883 RFC0884 Telnet terminal type option M. Solomon E. Wimmers December 1983 ASCII 7881 5

This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.

 RFC0930 UNKNOWN UNKNOWN Legacy 10.17487/RFC0884 RFC0885 Telnet end of record option J. Postel December 1983 ASCII 3232 2 TOPT-EOR

This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0885 RFC0886 Proposed standard for message header munging M.T. Rose December 1983 ASCII 30566 16

This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0886 RFC0887 Resource Location Protocol M. Accetta December 1983 ASCII 36770 16 RLP

This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0887 RFC0888 "STUB" Exterior Gateway Protocol L. Seamonson E.C. Rosen January 1984 ASCII 53227 39

This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document.

 RFC0904 UNKNOWN UNKNOWN Legacy 10.17487/RFC0888 RFC0889 Internet Delay Experiments D.L. Mills December 1983 ASCII 27128 12

This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0889 RFC0890 Exterior Gateway Protocol implementation schedule J. Postel February 1984 ASCII 5899 3 EGP

This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0890 RFC0891 DCN Local-Network Protocols D.L. Mills December 1983 ASCII 65340 26 IP-DC

This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks.

 STD0044 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0891 RFC0892 ISO Transport Protocol specification International Organization for Standardization December 1983 ASCII 158151 82

This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date.

 RFC0905 UNKNOWN UNKNOWN Legacy 10.17487/RFC0892 RFC0893 Trailer encapsulations S. Leffler M.J. Karels April 1984 ASCII 13353 6

This RFC discusses the motivation for use of "trailer encapsulations" on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA Internet community.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0893 RFC0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks C. Hornig April 1984 ASCII 5697 3 IP-E

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community.

 STD0041 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=894 10.17487/RFC0894 RFC0895 Standard for the transmission of IP datagrams over experimental Ethernet networks J. Postel April 1984 ASCII 4985 3 IP-EE

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA Internet community.

 STD0042 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0895 RFC0896 Congestion Control in IP/TCP Internetworks J. Nagle January 1984 ASCII 26782 9

This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0896 RFC0897 Domain name system implementation schedule J. Postel February 1984 ASCII 15683 8

This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA.

 RFC0881 RFC0921 UNKNOWN UNKNOWN Legacy 10.17487/RFC0897 RFC0898 Gateway special interest group meeting notes R.M. Hinden J. Postel M. Muuss J.K. Reynolds April 1984 ASCII 42112 24

This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0898 RFC0899 Request For Comments summary notes: 800-899 J. Postel A. Westine May 1984 ASCII 39996 18 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0899 RFC0900 Assigned Numbers J.K. Reynolds J. Postel June 1984 ASCII 82116 43

This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.

 RFC0870 RFC0923 HISTORIC UNKNOWN Legacy 10.17487/RFC0900 RFC0901 Official ARPA-Internet protocols J.K. Reynolds J. Postel June 1984 ASCII 41058 28

This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991.

 RFC0880 RFC0924 UNKNOWN UNKNOWN Legacy 10.17487/RFC0901 RFC0902 ARPA Internet Protocol policy J.K. Reynolds J. Postel July 1984 ASCII 11027 5

The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0902 RFC0903 A Reverse Address Resolution Protocol R. Finlayson T. Mann J.C. Mogul M. Theimer June 1984 ASCII 9345 4 RARP

This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.

 STD0038 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0903 RFC0904 Exterior Gateway Protocol formal specification D.L. Mills April 1984 ASCII 65226 30 EGP

RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.

 RFC0827 RFC0888 HISTORIC HISTORIC Legacy 10.17487/RFC0904 RFC0905 ISO Transport Protocol specification ISO DP 8073 ISO April 1984 ASCII 249214 164

This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters.

 RFC0892 UNKNOWN UNKNOWN Legacy 10.17487/RFC0905 RFC0906 Bootstrap loading using TFTP R. Finlayson June 1984 ASCII 10102 4

It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0906 RFC0907 Host Access Protocol specification Bolt Beranek and Newman Laboratories July 1984 ASCII 129985 75 IP-WB

This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel.

 RFC1221 STD0040 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0907 RFC0908 Reliable Data Protocol D. Velten R.M. Hinden J. Sax July 1984 ASCII 97646 62 RDP

The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.

 RFC1151 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0908 RFC0909 Loader Debugger Protocol C. Welles W. Milliken July 1984 ASCII 209813 135 LDP

The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0909 RFC0910 Multimedia mail meeting notes H.C. Forsdick August 1984 ASCII 24915 11

This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0910 RFC0911 EGP Gateway under Berkeley UNIX 4.2 P. Kirton August 1984 ASCII 55908 23

This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion).

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0911 RFC0912 Authentication service M. St. Johns September 1984 ASCII 4544 3

This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.

 RFC0931 UNKNOWN UNKNOWN Legacy 10.17487/RFC0912 RFC0913 Simple File Transfer Protocol M. Lottor September 1984 ASCII 20929 15 SFTP FTP

This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.

 HISTORIC HISTORIC Legacy 10.17487/RFC0913 RFC0914 Thinwire protocol for connecting personal computers to the Internet D.J. Farber G. Delp T.M. Conte September 1984 ASCII 57288 22 THINWIRE

This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.

 HISTORIC HISTORIC Legacy 10.17487/RFC0914 RFC0915 Network mail path service M.A. Elvy R. Nedved December 1984 ASCII 21635 11

This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0915 RFC0916 Reliable Asynchronous Transfer Protocol (RATP) G.G. Finn October 1984 ASCII 110737 54 RATP

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.

 HISTORIC HISTORIC Legacy 10.17487/RFC0916 RFC0917 Internet subnets J.C. Mogul October 1984 ASCII 47072 22

This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=917 10.17487/RFC0917 RFC0918 Post Office Protocol J.K. Reynolds October 1984 ASCII 9876 5

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP.

 RFC0937 UNKNOWN UNKNOWN Legacy 10.17487/RFC0918 RFC0919 Broadcasting Internet Datagrams J.C. Mogul October 1984 ASCII 16382 8

This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0919 RFC0920 Domain requirements J. Postel J.K. Reynolds October 1984 ASCII 27823 14

This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0920 RFC0921 Domain name system implementation schedule - revised J. Postel October 1984 ASCII 23318 13

This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references.

 RFC0897 UNKNOWN UNKNOWN Legacy 10.17487/RFC0921 RFC0922 Broadcasting Internet datagrams in the presence of subnets J.C. Mogul October 1984 ASCII 24147 12

We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0922 RFC0923 Assigned numbers J.K. Reynolds J. Postel October 1984 ASCII 96467 47

This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.

 RFC0900 RFC0943 HISTORIC UNKNOWN Legacy 10.17487/RFC0923 RFC0924 Official ARPA-Internet protocols for connecting personal computers to the Internet J.K. Reynolds J. Postel October 1984 ASCII 48513 35

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

 RFC0901 RFC0944 UNKNOWN UNKNOWN Legacy 10.17487/RFC0924 RFC0925 Multi-LAN address resolution J. Postel October 1984 ASCII 31137 15

The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0925 RFC0926 Protocol for providing the connectionless mode network services International Organization for Standardization December 1984 ASCII 165895 107

This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet.

 RFC0994 UNKNOWN UNKNOWN Legacy 10.17487/RFC0926 RFC0927 TACACS user identification Telnet option B.A. Anderson December 1984 ASCII 5474 4 TOPT-TACACS

The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0927 RFC0928 Introduction to proposed DoD standard H-FP M.A. Padlipsky December 1984 ASCII 60461 21

The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0928 RFC0929 Proposed Host-Front End Protocol J. Lilienkamp R. Mandell M.A. Padlipsky December 1984 ASCII 135042 56 HFEP

The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 HISTORIC HISTORIC Legacy 10.17487/RFC0929 RFC0930 Telnet terminal type option M. Solomon E. Wimmers January 1985 ASCII 6583 4

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.

 RFC0884 RFC1091 UNKNOWN UNKNOWN Legacy 10.17487/RFC0930 RFC0931 Authentication server M. St. Johns January 1985 ASCII 8982 5

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.

 RFC0912 RFC1413 UNKNOWN UNKNOWN Legacy 10.17487/RFC0931 RFC0932 Subnetwork addressing scheme D.D. Clark January 1985 ASCII 9283 4

This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0932 RFC0933 Output marking Telnet option S. Silverman January 1985 ASCII 6715 4 TOPT-OM

This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0933 RFC0934 Proposed standard for message encapsulation M.T. Rose E.A. Stefferud January 1985 ASCII 21770 10

This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0934 RFC0935 Reliable link layer protocols J.G. Robinson January 1985 ASCII 31625 12

This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0935 RFC0936 Another Internet subnet addressing scheme M.J. Karels February 1985 ASCII 10179 4

There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0936 RFC0937 Post Office Protocol: Version 2 M. Butler J. Postel D. Chase J. Goldberger J.K. Reynolds February 1985 ASCII 42370 24 POP2 Post Office Protocol Version 2

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918.

 RFC0918 HISTORIC HISTORIC Legacy 10.17487/RFC0937 RFC0938 Internet Reliable Transaction Protocol functional and interface specification T. Miller February 1985 ASCII 39478 19 IRTP

This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0938 RFC0939 Executive summary of the NRC report on transport protocols for Department of Defense data networks National Research Council February 1985 ASCII 42345 20

This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0939 RFC0940 Toward an Internet standard scheme for subnetting Gateway Algorithms and Data Structures Task Force April 1985 ASCII 6881 3

Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0940 RFC0941 Addendum to the network service definition covering network layer addressing International Organization for Standardization April 1985 ASCII 68733 34

This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0941 RFC0942 Transport protocols for Department of Defense data networks National Research Council February 1985 ASCII 217284 88

This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0942 RFC0943 Assigned numbers J.K. Reynolds J. Postel April 1985 ASCII 105234 50

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

 RFC0923 RFC0960 HISTORIC UNKNOWN Legacy 10.17487/RFC0943 RFC0944 Official ARPA-Internet protocols J.K. Reynolds J. Postel April 1985 ASCII 61373 40

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

 RFC0924 RFC0961 UNKNOWN UNKNOWN Legacy 10.17487/RFC0944 RFC0945 DoD statement on the NRC report J. Postel May 1985 ASCII 5017 2

In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only.

 RFC1039 UNKNOWN UNKNOWN Legacy 10.17487/RFC0945 RFC0946 Telnet terminal location number option R. Nedved May 1985 ASCII 6285 4 TOPT-TLN

Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0946 RFC0947 Multi-network broadcasting within the Internet K. Lebowitz D. Mankins June 1985 ASCII 12569 5

This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0947 RFC0948 Two methods for the transmission of IP datagrams over IEEE 802.3 networks I. Winston June 1985 ASCII 11495 7

This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1042 UNKNOWN UNKNOWN Legacy 10.17487/RFC0948 RFC0949 FTP unique-named store command M.A. Padlipsky July 1985 ASCII 4017 2

There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0949 RFC0950 Internet Standard Subnetting Procedure J.C. Mogul J. Postel August 1985 ASCII 37985 18 Address

This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed.

 RFC0792 RFC6918 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0950 RFC0951 Bootstrap Protocol W.J. Croft J. Gilmore September 1985 ASCII 28354 12 BOOTP

This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1395 RFC1497 RFC1532 RFC1542 RFC5494 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=951 10.17487/RFC0951 RFC0952 DoD Internet host table specification K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII 12388 6

This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date.

 RFC0810 RFC1123 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=952 10.17487/RFC0952 RFC0953 Hostname Server K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII 8305 5 HOSTNAME

This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date.

 RFC0811 HISTORIC HISTORIC Legacy 10.17487/RFC0953 RFC0954 NICNAME/WHOIS K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII 7397 4 NICNAME

This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.

 RFC0812 RFC3912 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC0954 RFC0955 Towards a transport service for transaction processing applications R.T. Braden September 1985 ASCII 22497 10

The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0955 RFC0956 Algorithms for synchronizing network clocks D.L. Mills September 1985 ASCII 67387 26

This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0956 RFC0957 Experiments in network clock synchronization D.L. Mills September 1985 ASCII 68952 27

This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0957 RFC0958 Network Time Protocol (NTP) D.L. Mills September 1985 ASCII 30723 14 NTP time clock synchronization

This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1059 RFC1119 RFC1305 UNKNOWN UNKNOWN Legacy 10.17487/RFC0958 RFC0959 File Transfer Protocol J. Postel J. Reynolds October 1985 ASCII 147316 69 FTP

This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.

 RFC0765 RFC2228 RFC2640 RFC2773 RFC3659 RFC5797 RFC7151 STD0009 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=959 10.17487/RFC0959 RFC0960 Assigned numbers J.K. Reynolds J. Postel December 1985 ASCII 125814 60

This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

 RFC0943 RFC0990 HISTORIC UNKNOWN Legacy 10.17487/RFC0960 RFC0961 Official ARPA-Internet protocols J.K. Reynolds J. Postel December 1985 ASCII 52672 38

This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

 RFC0944 RFC0991 UNKNOWN UNKNOWN Legacy 10.17487/RFC0961 RFC0962 TCP-4 prime M.A. Padlipsky November 1985 ASCII 2773 2

This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0962 RFC0963 Some problems with the specification of the Military Standard Internet Protocol D.P. Sidhu November 1985 ASCII 44019 19

The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0963 RFC0964 Some problems with the specification of the Military Standard Transmission Control Protocol D.P. Sidhu T. Blumer November 1985 ASCII 20972 10

The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0964 RFC0965 Format for a graphical communication protocol L. Aguilar December 1985 ASCII 105456 51

This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0965 RFC0966 Host groups: A multicast extension to the Internet Protocol S.E. Deering D.R. Cheriton December 1985 ASCII 59469 27

This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988.

 RFC0988 UNKNOWN UNKNOWN Legacy 10.17487/RFC0966 RFC0967 All victims together M.A. Padlipsky December 1985 ASCII 4706 2

This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0967 RFC0968 Twas the night before start-up V.G. Cerf December 1985 ASCII 2459 2

This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0968 RFC0969 NETBLT: A bulk data transfer protocol D.D. Clark M.L. Lambert L. Zhang December 1985 ASCII 40040 15

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998.

 RFC0998 UNKNOWN UNKNOWN Legacy 10.17487/RFC0969 RFC0970 On Packet Switches With Infinite Storage J. Nagle December 1985 ASCII 35316 9

The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0970 RFC0971 Survey of data representation standards A.L. DeSchon January 1986 ASCII 22883 9

This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0971 RFC0972 Password Generator Protocol F.J. Wancho January 1986 ASCII 3890 2

This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0972 RFC0973 Domain system changes and observations P.V. Mockapetris January 1986 ASCII 22364 10

This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.

 RFC1034 RFC1035 RFC0882 RFC0883 UNKNOWN UNKNOWN Legacy 10.17487/RFC0973 RFC0974 Mail routing and the domain system C. Partridge January 1986 ASCII 18581 7 DNS-MX

This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.

 RFC2821 STD0010 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC0974 RFC0975 Autonomous confederations D.L. Mills February 1986 ASCII 28010 10

This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0975 RFC0976 UUCP mail interchange format standard M.R. Horton February 1986 ASCII 26814 12

This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone.

 RFC1137 UNKNOWN UNKNOWN Legacy 10.17487/RFC0976 RFC0977 Network News Transfer Protocol B. Kantor P. Lapsley February 1986 ASCII 55062 27 NNTP]

NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC3977 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0977 RFC0978 Voice File Interchange Protocol (VFIP) J.K. Reynolds R. Gillman W.A. Brackenridge A. Witkowski J. Postel February 1986 ASCII 9223 5

The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0978 RFC0979 PSN End-to-End functional specification A.G. Malis March 1986 ASCII 39472 15

This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0979 RFC0980 Protocol document order information O.J. Jacobsen J. Postel March 1986 ASCII 24416 12

This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT).

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0980 RFC0981 Experimental multiple-path routing algorithm D.L. Mills March 1986 ASCII 59069 22

This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0981 RFC0982 Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address H.W. Braun April 1986 ASCII 22595 11

This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0982 RFC0983 ISO transport arrives on top of the TCP D.E. Cass M.T. Rose April 1986 ASCII 59819 27

This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged.

 RFC1006 UNKNOWN UNKNOWN Legacy 10.17487/RFC0983 RFC0984 PCMAIL: A distributed mail system for personal computers D.D. Clark M.L. Lambert May 1986 ASCII 69333 31

This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993.

 RFC0993 UNKNOWN UNKNOWN Legacy 10.17487/RFC0984 RFC0985 Requirements for Internet gateways - draft National Science Foundation Network Technical Advisory Group May 1986 ASCII 59221 23 Requirements Internet gateways

This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification.

 RFC1009 UNKNOWN UNKNOWN Legacy 10.17487/RFC0985 RFC0986 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol R.W. Callon H.W. Braun June 1986 ASCII 13950 7

This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0986 RFC0987 Mapping between X.400 and RFC 822 S.E. Kille June 1986 ASCII 127540 69

The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC2156 RFC1327 RFC1026 RFC1138 RFC1148 UNKNOWN UNKNOWN Legacy 10.17487/RFC0987 RFC0988 Host extensions for IP multicasting S.E. Deering July 1986 ASCII 45220 20 multicast Internet

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.

 RFC0966 RFC1054 RFC1112 UNKNOWN UNKNOWN Legacy 10.17487/RFC0988 RFC0989 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures J. Linn February 1987 ASCII 63934 23

This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.

 RFC1040 RFC1113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0989 RFC0990 Assigned numbers J.K. Reynolds J. Postel November 1986 ASCII 174784 75

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.

 RFC0960 RFC1010 RFC0997 HISTORIC UNKNOWN Legacy 10.17487/RFC0990 RFC0991 Official ARPA-Internet protocols J.K. Reynolds J. Postel November 1986 ASCII 65205 46

This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.

 RFC0961 RFC1011 UNKNOWN UNKNOWN Legacy 10.17487/RFC0991 RFC0992 On communication support for fault tolerant process groups K.P. Birman T.A. Joseph November 1986 ASCII 52313 18

This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0992 RFC0993 PCMAIL: A distributed mail system for personal computers D.D. Clark M.L. Lambert December 1986 ASCII 71725 28

This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984.

 RFC0984 RFC1056 UNKNOWN UNKNOWN Legacy 10.17487/RFC0993 RFC0994 Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service International Organization for Standardization March 1986 ASCII 129006 52

This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).

 RFC0926 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=994 10.17487/RFC0994 RFC0995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 International Organization for Standardization April 1986 ASCII 94069 41

This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0995 RFC0996 Statistics server D.L. Mills February 1987 ASCII 6127 3 STATSRV

This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.

 HISTORIC HISTORIC Legacy 10.17487/RFC0996 RFC0997 Internet numbers J.K. Reynolds J. Postel March 1987 ASCII 123919 42

This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.

 RFC1020 RFC1117 RFC0990 UNKNOWN UNKNOWN Legacy 10.17487/RFC0997 RFC0998 NETBLT: A bulk data transfer protocol D.D. Clark M.L. Lambert L. Zhang March 1987 ASCII 57147 21 NETBLT

This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969.

 RFC0969 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0998 RFC0999 Requests For Comments summary notes: 900-999 A. Westine J. Postel April 1987 ASCII 62877 22 RFC0160 RFC1000 UNKNOWN UNKNOWN Legacy 10.17487/RFC0999 RFC1000 Request For Comments reference guide J.K. Reynolds J. Postel August 1987 ASCII 323960 149

This RFC Reference Guide is intended to provide a historical account by categorizing and summarizing of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. These documents have been crossed referenced to indicate which RFCs are current, obsolete, or revised.

 RFC0999 UNKNOWN UNKNOWN Legacy 10.17487/RFC1000 RFC1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods NetBIOS Working Group in the Defense Advanced Research Projects Agency Internet Activities Board End-to-End Services Task Force March 1987 ASCII 158437 68 NETBIOS

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".

 STD0019 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1001 10.17487/RFC1001 RFC1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications NetBIOS Working Group in the Defense Advanced Research Projects Agency Internet Activities Board End-to-End Services Task Force March 1987 ASCII 170262 84 NETBIOS

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables. A more general overview is found in a companion RFC, "Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods".

 STD0019 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1002 10.17487/RFC1002 RFC1003 Issues in defining an equations representation standard A.R. Katz March 1987 ASCII 19816 7

This memo is intended to identify and explore issues in defining a standard for the exchange of mathematical equations. No attempt is made at a complete definition and more questions are asked than are answered. Questions about the user interface are only addressed to the extent that they affect interchange issues.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1003 RFC1004 Distributed-protocol authentication scheme D.L. Mills April 1987 ASCII 21402 8 COOKIE-JAR

The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1004 RFC1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP) A. Khanna A.G. Malis May 1987 ASCII 69957 34

This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1005 RFC1006 ISO Transport Service on top of the TCP Version: 3 M.T. Rose D.E. Cass May 1987 ASCII 30662 19 TP-TCP

This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible.

 RFC0983 RFC2126 STD0035 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1006 RFC1007 Military supplement to the ISO Transport Protocol W. McCoy June 1987 ASCII 51280 23

This document supplements the Transport Service and Protocol of the International Standards Organization (ISO), IS 8072 and IS 8073, respectively, and their formal descriptions by providing conventions, option selections and parameter values. This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1007 RFC1008 Implementation guide for the ISO Transport Protocol W. McCoy June 1987 ASCII 204664 73

This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1008 RFC1009 Requirements for Internet gateways R.T. Braden J. Postel June 1987 ASCII 128173 54

This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community.

 RFC0985 RFC1812 HISTORIC HISTORIC Legacy 10.17487/RFC1009 RFC1010 Assigned numbers J.K. Reynolds J. Postel May 1987 ASCII 78179 44

This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.

 RFC0990 RFC1060 HISTORIC UNKNOWN Legacy 10.17487/RFC1010 RFC1011 Official Internet protocols J.K. Reynolds J. Postel May 1987 ASCII 74593 52

This memo is an official status report on the protocols used in the Internet community. It identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned.

 RFC0991 RFC6093 UNKNOWN UNKNOWN Legacy 10.17487/RFC1011 RFC1012 Bibliography of Request For Comments 1 through 999 J.K. Reynolds J. Postel June 1987 ASCII 129194 64

This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1012 RFC1013 X Window System Protocol, version 11: Alpha update April 1987 R.W. Scheifler June 1987 ASCII 244905 101

This RFC is distributed to the Internet community for information only. It does not establish an Internet standard. The X window system has been widely reviewed and tested. The Internet community is encouraged to experiment with it.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1013 RFC1014 XDR: External Data Representation standard Sun Microsystems June 1987 ASCII 39316 20

XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures. XDR fits into ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing. This RFC is distributed for information only, it does not establish a Internet standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1014 RFC1015 Implementation plan for interagency research Internet B.M. Leiner July 1987 ASCII 63159 24

This RFC proposes an Interagency Research Internet as the natural outgrowth of the current Internet. This is an "idea paper" and discussion is strongly encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1015 RFC1016 Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID) W. Prue J. Postel July 1987 ASCII 47922 18

The memo is intended to explore the issue of what a host could do with a source quench. The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host. This is a "crazy idea paper" and discussion is essential.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1016 RFC1017 Network requirements for scientific research: Internet task force on scientific computing B.M. Leiner August 1987 ASCII 49512 19

This RFC identifies the requirements on communication networks for supporting scientific research. It proposes some specific areas for near term work, as well as some long term goals. This is an "idea" paper and discussion is strongly encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1017 RFC1018 Some comments on SQuID A.M. McKenzie August 1987 ASCII 7931 3

This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench. This memo introduces the distinction of the cause of congestion in a gateway between the effects of "Funneling" and Mismatch". It is offered in the same spirit as RFC-1016; to stimulate discussion. The opinions offered are personal, not corporate, opinions.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1018 RFC1019 Report of the Workshop on Environments for Computational Mathematics D. Arnon September 1987 ASCII 21151 8

This memo is a report on the discussion of the representation of equations in a workshop at the ACM SIGGRAPH Conference held in Anaheim, California on 30 July 1987.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1019 RFC1020 Internet numbers S. Romano M.K. Stahl November 1987 ASCII 146864 51

This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997.

 RFC0997 RFC1062 RFC1117 RFC1166 UNKNOWN UNKNOWN Legacy 10.17487/RFC1020 RFC1021 High-level Entity Management System (HEMS) C. Partridge G. Trewitt October 1987 ASCII 12993 5 HEMS

This memo provides a general overview of the High-level Entity management system (HEMS). This system is experimental, and is currently being tested in portions of the Internet.

 HISTORIC HISTORIC Legacy 10.17487/RFC1021 RFC1022 High-level Entity Management Protocol (HEMP) C. Partridge G. Trewitt October 1987 ASCII 25348 12

This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines. This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021. This memo also assumes a knowledge of the ISO data encoding standard, ASN.1.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1022 RFC1023 HEMS monitoring and control language G. Trewitt C. Partridge October 1987 ASCII 40992 17

This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1.

 RFC1076 UNKNOWN UNKNOWN Legacy 10.17487/RFC1023 RFC1024 HEMS variable definitions C. Partridge G. Trewitt October 1987 ASCII 126536 74

This memo assigns instruction codes, defines object formats and object semantics for use with the High-Level Monitoring and Control Language, defined in RFC-1023. A general system has been described in previous memos (RFC-1021, RFC-1022). This system is called the High-Level Entity Management System (HEMS). This memo is provisional and the definitions are subject to change. Readers should confirm with the authors that they have the most recent version. This RFC assumes a working knowledge of the ISO data encoding standard, ASN.1, and a general understanding of the IP protocol suite.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1024 RFC1025 TCP and IP bake off J. Postel September 1987 ASCII 11648 6

This memo describes some of the procedures, scoring and tests used in the TCP and IP bake offs held in the early development of these protocols. These procedures and tests may still be of use in testing newly implemented TCP and IP modules.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1025 RFC1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822) S.E. Kille September 1987 ASCII 7117 4

This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.

 RFC2156 RFC1327 RFC0987 RFC1138 RFC1148 UNKNOWN UNKNOWN Legacy 10.17487/RFC1026 RFC1027 Using ARP to implement transparent subnet gateways S. Carl-Mitchell J.S. Quarterman October 1987 ASCII 21297 8

This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of "Proxy ARP".

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1027 10.17487/RFC1027 RFC1028 Simple Gateway Monitoring Protocol J. Davin J.D. Case M. Fedor M.L. Schoffstall November 1987 ASCII 82440 35 SGMP

This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users. This proposal is intended only as an interim response to immediate gateway monitoring needs.

 HISTORIC HISTORIC Legacy 10.17487/RFC1028 RFC1029 More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets G. Parr May 1988 ASCII 44019 17 arp

This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring host address parameters in a Multi-Lan system of Ethernets. The problem is one which is appearing more and more regularly as the interconnected systems grow larger on Campuses and in Commercial Institutions. This RFC suggests a protocol enhancement for the Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1029 RFC1030 On testing the NETBLT Protocol over divers networks M.L. Lambert November 1987 ASCII 40964 16

This memo describes the results gathered from testing NETBLT over three networks of different bandwidths and round-trip delays. The results are not complete, but the information gathered so far has not been promising. The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1030 RFC1031 MILNET name domain transition W.D. Lazear November 1987 ASCII 20137 10

This RFC consolidates information necessary for the implementation of domain style names throughout the DDN/MILNET Internet community. The introduction of domain style names will impact all hosts in the DDN/MILNET Internet. This RFC is designed as an aid to implementors and administrators by providing: 1) an overview of the transition process from host tables to domains, 2) a timetable for the transition, and 3) references to documentation and software relating to the domain system.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1031 RFC1032 Domain administrators guide M.K. Stahl November 1987 ASCII 29454 14

Domains are administrative entities that provide decentralized management of host naming and addressing. The domain-naming system is distributed and hierarchical. This memo describes procedures for registering a domain with the Network Information Center (NIC) of Defense Data Network (DDN), and offers guidelines on the establishment and administration of a domain in accordance with the requirements specified in RFC-920. It is recommended that the guidelines described in this document be used by domain administrators in the establishment and control of second-level domains. The role of the domain administrator (DA) is that of coordinator, manager, and technician. If his domain is established at the second level or lower in the tree, the domain administrator must register by interacting with the management of the domain directly above this.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1032 RFC1033 Domain Administrators Operations Guide M. Lottor November 1987 ASCII 37263 22

This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed (see RFCs 1031, 1032, 1034, and 1035).

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1033 10.17487/RFC1033 RFC1034 Domain names - concepts and facilities P.V. Mockapetris November 1987 ASCII 129180 55 DOMAIN

This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.

 RFC0973 RFC0882 RFC0883 RFC1101 RFC1183 RFC1348 RFC1876 RFC1982 RFC2065 RFC2181 RFC2308 RFC2535 RFC4033 RFC4034 RFC4035 RFC4343 RFC4035 RFC4592 RFC5936 RFC8020 STD0013 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1034 10.17487/RFC1034 RFC1035 Domain names - implementation and specification P.V. Mockapetris November 1987 ASCII 125626 55 DOMAIN DNS

This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.

 RFC0973 RFC0882 RFC0883 RFC1101 RFC1183 RFC1348 RFC1876 RFC1982 RFC1995 RFC1996 RFC2065 RFC2136 RFC2181 RFC2137 RFC2308 RFC2535 RFC2673 RFC2845 RFC3425 RFC3658 RFC4033 RFC4034 RFC4035 RFC4343 RFC5936 RFC5966 RFC6604 RFC7766 STD0013 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1035 10.17487/RFC1035 RFC1036 Standard for interchange of USENET messages M.R. Horton R. Adams December 1987 ASCII 46891 19

This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard.

 RFC0850 RFC5536 RFC5537 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1036 10.17487/RFC1036 RFC1037 NFILE - a file access protocol B. Greenberg S. Keene December 1987 ASCII 197312 86 NFILE

This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE.

 HISTORIC HISTORIC Legacy 10.17487/RFC1037 RFC1038 Draft revised IP security option M. St. Johns January 1988 ASCII 15879 7

This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol".

 RFC1108 UNKNOWN UNKNOWN Legacy 10.17487/RFC1038 RFC1039 DoD statement on Open Systems Interconnection protocols D. Latham January 1988 ASCII 6194 3

This RFC reproduces a memorandum issued on 2-JUL-87 from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC31) to the Director of the Defense Communications Agency (DCA). This memo is distributed for information only.

 RFC0945 UNKNOWN UNKNOWN Legacy 10.17487/RFC1039 RFC1040 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures J. Linn January 1988 ASCII 76276 29

This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.

 RFC0989 RFC1113 UNKNOWN UNKNOWN Legacy 10.17487/RFC1040 RFC1041 Telnet 3270 regime option Y. Rekhter January 1988 ASCII 11608 6 TOPT-3270

This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.

 RFC6270 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1041 RFC1042 Standard for the transmission of IP datagrams over IEEE 802 networks J. Postel J.K. Reynolds February 1988 ASCII 34359 15 IP-IEEE

This RFC specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on IEEE 802 Networks to allow compatible and interoperable implementations. This RFC specifies a protocol standard for the Internet community.

 RFC0948 STD0043 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1042 10.17487/RFC1042 RFC1043 Telnet Data Entry Terminal option: DODIIS implementation A. Yasuda T. Thompson February 1988 ASCII 59478 26 TOPT-DATA

This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged.

 RFC0732 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1043 RFC1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification K. Hardwick J. Lekashman February 1988 ASCII 100836 43 IP-HC

This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols.

 RFC5494 STD0045 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1044 RFC1045 VMTP: Versatile Message Transaction Protocol: Protocol specification D.R. Cheriton February 1988 ASCII 272058 128 VMTP

This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1045 RFC1046 Queuing algorithm to provide type-of-service for IP links W. Prue J. Postel February 1988 ASCII 30106 11

This memo is intended to explore how Type-of-Service might be implemented in the Internet. The proposal describes a method of queuing which can provide the different classes of service. The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service. This is an "idea paper" and discussion is strongly encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1046 RFC1047 Duplicate messages and SMTP C. Partridge February 1988 ASCII 5888 3

An examination of a synchronization problem in the Simple Mail Transfer Protocol (SMTP) is presented. This synchronization problem can cause a message to be delivered multiple times. A method for avoiding this problem is suggested. Nodding familiarity with the SMTP specification, RFC-821, is required.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1047 RFC1048 BOOTP vendor information extensions P.A. Prindeville February 1988 ASCII 15423 7

This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought.

 RFC1084 RFC1395 RFC1497 RFC1533 UNKNOWN UNKNOWN Legacy 10.17487/RFC1048 RFC1049 Content-type header field for Internet messages M.A. Sirbu March 1988 ASCII 18923 8 CONTENT

This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.

 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1049 RFC1050 RPC: Remote Procedure Call Protocol specification Sun Microsystems April 1988 ASCII 51540 24 SUN-RPC

This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time.

 RFC1057 HISTORIC HISTORIC Legacy 10.17487/RFC1050 RFC1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks P.A. Prindeville March 1988 ASCII 7779 4

This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community.

 RFC1201 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1051 RFC1052 IAB recommendations for the development of Internet network management standards V.G. Cerf April 1988 ASCII 30569 14

This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. This memo does NOT, in and of itself, define or propose an Official Internet Protocol. It does reflect, however, the policy of the IAB with respect to further network management development in the short and long term.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1052 RFC1053 Telnet X.3 PAD option S. Levy T. Jacobson April 1988 ASCII 48952 21 TOPT-X.3

This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1053 RFC1054 Host extensions for IP multicasting S.E. Deering May 1988 ASCII 45465 19

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988.

 RFC0988 RFC1112 UNKNOWN UNKNOWN Legacy 10.17487/RFC1054 RFC1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP J.L. Romkey June 1988 ASCII 12578 6 IP-SLIP

The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard.

 STD0047 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1055 10.17487/RFC1055 RFC1056 PCMAIL: A distributed mail system for personal computers M.L. Lambert June 1988 ASCII 85368 38 PCMAIL

This memo is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues.

 RFC0993 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1056 RFC1057 RPC: Remote Procedure Call Protocol specification: Version 2 Sun Microsystems June 1988 ASCII 52462 25 SUN-RPC

This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration. This memo is not an Internet standard at this time.

 RFC1050 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1057 RFC1058 Routing Information Protocol C.L. Hedrick June 1988 ASCII 93285 33 RIP

This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community.

 RFC1388 RFC1723 HISTORIC HISTORIC Legacy 10.17487/RFC1058 RFC1059 Network Time Protocol (version 1) specification and implementation D.L. Mills July 1988 ASCII 140890 58 NTP NTPv1 time clock synchronization

This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol.

 RFC0958 RFC1119 RFC1305 UNKNOWN UNKNOWN Legacy 10.17487/RFC1059 RFC1060 Assigned numbers J.K. Reynolds J. Postel March 1990 ASCII 177923 86

This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.

 RFC1010 RFC1340 RFC1349 HISTORIC UNKNOWN Legacy 10.17487/RFC1060 RFC1061 RFC1062 Internet numbers S. Romano M.K. Stahl M. Recker August 1988 ASCII 198729 65

This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.

 RFC1020 RFC1117 RFC1166 UNKNOWN UNKNOWN Legacy 10.17487/RFC1062 RFC1063 IP MTU discovery options J.C. Mogul C.A. Kent C. Partridge K. McCloghrie July 1988 ASCII 27121 11

A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol.

 RFC1191 UNKNOWN UNKNOWN Legacy 10.17487/RFC1063 RFC1064 Interactive Mail Access Protocol: Version 2 M.R. Crispin July 1988 ASCII 57813 26

This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested.

 RFC1176 RFC1203 UNKNOWN UNKNOWN Legacy 10.17487/RFC1064 RFC1065 Structure and identification of management information for TCP/IP-based internets K. McCloghrie M.T. Rose August 1988 ASCII 38858 21

This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification.

 RFC1155 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1065 10.17487/RFC1065 RFC1066 Management Information Base for network management of TCP/IP-based internets K. McCloghrie M.T. Rose August 1988 ASCII 135177 90

This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

 RFC1156 UNKNOWN UNKNOWN Legacy 10.17487/RFC1066 RFC1067 Simple Network Management Protocol J.D. Case M. Fedor M.L. Schoffstall J. Davin August 1988 ASCII 69592 33

This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

 RFC1098 UNKNOWN UNKNOWN Legacy 10.17487/RFC1067 RFC1068 Background File Transfer Program (BFTP) A.L. DeSchon R.T. Braden August 1988 ASCII 51004 27 FTP

This RFC describes an Internet background file transfer service that is built upon the third-party transfer model of FTP. No new protocols are involved. The purpose of this memo is to stimulate discussions on new Internet service modes.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1068 RFC1069 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol R.W. Callon H.W. Braun February 1989 ASCII 24268 10

This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet. This is a solution to one of the problems inherent in the use of "ISO-grams" in the Internet. This memo is a revision of RFC 986. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

 RFC0986 UNKNOWN UNKNOWN Legacy 10.17487/RFC1069 RFC1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer R.A. Hagens N.E. Hall M.T. Rose February 1989 ASCII 37354 17

This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet and requests discussion and suggestions for improvements to this scenario. This RFC also proposes the creation of an experimental OSI internet. To participate in the experimental OSI internet, a system must abide by the agreements set forth in this RFC.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1070 RFC1071 Computing the Internet checksum R.T. Braden D.A. Borman C. Partridge September 1988 ASCII 54941 24

This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.

 RFC1141 INFORMATIONAL UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1071 10.17487/RFC1071 RFC1072 TCP extensions for long-delay paths V. Jacobson R.T. Braden October 1988 ASCII 36000 16

This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance.

 RFC1323 RFC2018 RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1072 RFC1073 Telnet window size option D. Waitzman October 1988 ASCII 7639 4 TOPT-NAWS

This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1073 RFC1074 NSFNET backbone SPF based Interior Gateway Protocol J. Rekhter October 1988 ASCII 10872 5

This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1074 RFC1075 Distance Vector Multicast Routing Protocol D. Waitzman C. Partridge S.E. Deering November 1988 ASCII 54731 24 IP-DVMRP

This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1075 RFC1076 HEMS monitoring and control language G. Trewitt C. Partridge November 1988 ASCII 98774 42

This RFC specifies a query language for monitoring and control of network entities. This RFC supercedes RFC 1023, extending the query language and providing more discussion of the underlying issues. This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC 1021 and RFC 1022. Readers may wish to consult these RFCs when reading this memo. RFC 1024 contains detailed assignments of numbers and structures used in this system. Portions of RFC 1024 that define query language structures are superceded by definitions in this memo. This memo assumes a knowledge of the ISO data encoding standard, ASN.1.

 RFC1023 UNKNOWN UNKNOWN Legacy 10.17487/RFC1076 RFC1077 Critical issues in high bandwidth networking B.M. Leiner November 1988 ASCII 116464 46

This memo presents the results of a working group on High Bandwidth Networking. This RFC is for your information and you are encouraged to comment on the issues presented.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1077 RFC1078 TCP port service Multiplexer (TCPMUX) M. Lottor November 1988 ASCII 3248 2

This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC1078 RFC1079 Telnet terminal speed option C.L. Hedrick December 1988 ASCII 4942 3 TOPT-TS

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1079 RFC1080 Telnet remote flow control option C.L. Hedrick November 1988 ASCII 6688 4

This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard.

 RFC1372 UNKNOWN UNKNOWN Legacy 10.17487/RFC1080 RFC1081 Post Office Protocol: Version 3 M.T. Rose November 1988 ASCII 37009 16

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

 RFC1225 UNKNOWN UNKNOWN Legacy 10.17487/RFC1081 RFC1082 Post Office Protocol: Version 3: Extended service offerings M.T. Rose November 1988 ASCII 25423 11

This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. All of the extensions described in this memo to the POP3 are OPTIONAL.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1082 RFC1083 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board December 1988 ASCII 27128 12 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.

 RFC1100 HISTORIC UNKNOWN Legacy 10.17487/RFC1083 RFC1084 BOOTP vendor information extensions J.K. Reynolds December 1988 ASCII 16327 8

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought.

 RFC1048 RFC1395 RFC1497 RFC1533 UNKNOWN UNKNOWN Legacy 10.17487/RFC1084 RFC1085 ISO presentation services on top of TCP/IP based internets M.T. Rose December 1988 ASCII 64643 32

RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP/IP. Once this method is applied, one may implement "real" ISO applications on top of TCP/IP-based internets, by simply implementing OSI session, presentation, and application services on top of the transport service access point which is provided on top of the TCP. Although straight-forward, there are some environments in which the richness provided by the OSI application layer is desired, but it is nonetheless impractical to implement the underlying OSI infrastructure (i.e., the presentation, session, and transport services on top of the TCP). This memo describes an approach for providing "stream-lined" support of OSI application services on top of TCP/IP-based internets for such constrained environments. This memo proposes a standard for the Internet community.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1085 RFC1086 ISO-TP0 bridge between TCP and X.25 J.P. Onions M.T. Rose December 1988 ASCII 19934 9

This memo proposes a standard for the Internet community. Hosts on the Internet that choose to implement ISO TP0 transport connectivity between TCP and X.25 based hosts are expected to experiment with this proposal. TCP port 146 is reserved for this proposal.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1086 RFC1087 Ethics and the Internet Defense Advanced Research Projects Agency Internet Activities Board January 1989 ASCII 4582 2 Ethics Internet

This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1087 RFC1088 Standard for the transmission of IP datagrams over NetBIOS networks L.J. McLaughlin February 1989 ASCII 5579 3 IP-NETBIOS

This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.

 STD0048 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1088 RFC1089 SNMP over Ethernet M. Schoffstall C. Davin M. Fedor J. Case February 1989 ASCII 4458 3

This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer.

 RFC4789 UNKNOWN UNKNOWN Legacy 10.17487/RFC1089 RFC1090 SMTP on X.25 R. Ullmann February 1989 ASCII 6141 4

This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1090 RFC1091 Telnet terminal-type option J. VanBokkelen February 1989 ASCII 13439 7 TOPT-TERM

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate

 RFC0930 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1091 RFC1092 EGP and policy based routing in the new NSFNET backbone J. Rekhter February 1989 ASCII 11865 5

This memo discusses implementation decisions for routing issues in the NSFNET, especially in the NSFNET Backbone. Of special concern is the restriction of routing information to advertize the best route as established by a policy decision.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1092 RFC1093 NSFNET routing architecture H.W. Braun February 1989 ASCII 20629 9

This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1093 RFC1094 NFS: Network File System Protocol specification B. Nowicki March 1989 ASCII 51454 27 SUN-NFS

This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.

 RFC1813 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1094 RFC1095 Common Management Information Services and Protocol over TCP/IP (CMOT) U.S. Warrier L. Besaw April 1989 ASCII 157506 67

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet.

 RFC1189 UNKNOWN UNKNOWN Legacy 10.17487/RFC1095 RFC1096 Telnet X display location option G.A. Marcy March 1989 ASCII 4634 3 TOPT-XDL

This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1096 RFC1097 Telnet subliminal-message option B. Miller April 1 1989 ASCII 5490 3

This RFC specifies a standard for the Internet community. Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1097 RFC1098 Simple Network Management Protocol (SNMP) J.D. Case M. Fedor M.L. Schoffstall J. Davin April 1989 ASCII 71563 34

This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.

 RFC1067 RFC1157 UNKNOWN UNKNOWN Legacy 10.17487/RFC1098 RFC1099 Request for Comments Summary: RFC Numbers 1000-1099 J. Reynolds December 1991 ASCII 49108 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1099 RFC1100 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1989 ASCII 30101 14 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89.

 RFC1083 RFC1130 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1100 RFC1101 DNS encoding of network names and other types P.V. Mockapetris April 1989 ASCII 28677 14

This RFC proposes two extensions to the Domain Name System: - A specific method for entering and retrieving RRs which map between network names and numbers. - Ideas for a general method for describing mappings between arbitrary identifiers and numbers. The method for mapping between network names and addresses is a proposed standard, the ideas for a general method are experimental.

 RFC1034 RFC1035 UNKNOWN UNKNOWN Legacy 10.17487/RFC1101 RFC1102 Policy routing in Internet protocols D.D. Clark May 1989 ASCII 59664 22

The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1102 RFC1103 Proposed standard for the transmission of IP datagrams over FDDI Networks D. Katz June 1989 ASCII 19439 9

This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

 RFC1188 UNKNOWN UNKNOWN Legacy 10.17487/RFC1103 RFC1104 Models of policy based routing H.W. Braun June 1989 ASCII 25468 10

The purpose of this RFC is to outline a variety of models for policy based routing. The relative benefits of the different approaches are reviewed. Discussions and comments are explicitly encouraged to move toward the best policy based routing model that scales well within a large internetworking environment.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1104 RFC1105 Border Gateway Protocol (BGP) K. Lougheed Y. Rekhter June 1989 ASCII 37644 17 BGP

This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]

 RFC1163 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1105 RFC1106 TCP big window and NAK options R. Fox June 1989 ASCII 37105 13

This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product. The extensions described in this document have been implemented and shown to work using resources at NASA. This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research.

 RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1106 RFC1107 Plan for Internet directory services K.R. Sollins July 1989 ASCII 51773 19

This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1107 RFC1108 U.S. Department of Defense Security Options for the Internet Protocol S. Kent November 1991 ASCII 41791 17 IPSO

This RFC specifies the U.S. Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038, "Revised IP Security Option", dated January 1988. [STANDARDS-TRACK]

 RFC1038 HISTORIC HISTORIC Legacy 10.17487/RFC1108 RFC1109 Report of the second Ad Hoc Network Management Review Group V.G. Cerf August 1989 ASCII 20642 8

This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet. This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989. The results of the first such meeting were reported in RFC 1052.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1109 RFC1110 Problem with the TCP big window option A.M. McKenzie August 1989 ASCII 5778 3

This memo comments on the TCP Big Window option described in RFC 1106.

 RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1110 RFC1111 Request for comments on Request for Comments: Instructions to RFC authors J. Postel August 1989 ASCII 11793 6

This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.

 RFC0825 RFC1543 RFC2223 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1111 RFC1112 Host extensions for IP multicasting S.E. Deering August 1989 ASCII 39904 17 IGMP multicast

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]

 RFC0988 RFC1054 RFC2236 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1112 RFC1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures J. Linn August 1989 ASCII 89293 34

This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]

 RFC0989 RFC1040 RFC1421 HISTORIC HISTORIC Legacy 10.17487/RFC1113 RFC1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management S.T. Kent J. Linn August 1989 ASCII 69661 25

This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]

 RFC1422 HISTORIC HISTORIC Legacy 10.17487/RFC1114 RFC1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers J. Linn August 1989 ASCII 18226 8

This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]

 RFC1423 HISTORIC HISTORIC Legacy 10.17487/RFC1115 RFC1116 Telnet Linemode option D.A. Borman August 1989 ASCII 47473 21

Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]

 RFC1184 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1116 RFC1117 Internet numbers S. Romano M.K. Stahl M. Recker August 1989 ASCII 324666 109

This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.

 RFC1062 RFC1020 RFC0997 RFC1166 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1117 RFC1118 Hitchhikers guide to the Internet E. Krol September 1989 ASCII 62757 24

This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1118 RFC1119 Network Time Protocol (version 2) specification and implementation D.L. Mills September 1989 ASCII 143 1 PS 518020 PDF 187940 NTP NTPv2 time clock synchronization

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK]

 RFC0958 RFC1059 RFC1305 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1119 RFC1120 Internet Activities Board V. Cerf September 1989 ASCII 26123 11

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard.

 RFC1160 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1120 RFC1121 Act one - the poems J. Postel L. Kleinrock V.G. Cerf B. Boehm September 1989 ASCII 10644 6

This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1121 RFC1122 Requirements for Internet Hosts - Communication Layers R. Braden Editor October 1989 ASCII 295992 116 applicability

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

 RFC0793 RFC1349 RFC4379 RFC5884 RFC6093 RFC6298 RFC6633 RFC6864 STD0003 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1122 10.17487/RFC1122 RFC1123 Requirements for Internet Hosts - Application and Support R. Braden Editor October 1989 ASCII 245503 98 applicability

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

 RFC0822 RFC0952 RFC1349 RFC2181 RFC5321 RFC5966 RFC7766 STD0003 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1123 10.17487/RFC1123 RFC1124 Policy issues in interconnecting networks B.M. Leiner September 1989 ASCII 118 1 PS 315692 PDF 143819

To support the activities of the Federal Research Internet Coordinating Committee (FRICC) in creating an interconnected set of networks to serve the research community, two workshops were held to address the technical support of policy issues that arise when interconnecting such networks. Held under the suspices of the Internet Activities Board at the request of the FRICC, and sponsored by NASA through RIACS, the workshops addressed the required and feasible technologies and architectures that could be used to satisfy the desired policies for interconnection. The purpose of this RFC is to report the results of these workshops.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1124 RFC1125 Policy requirements for inter Administrative Domain routing D. Estrin November 1989 ASCII 55248 21 PS 282123 PDF 289862

The purpose of this memo is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the development and adoption of standards.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1125 RFC1126 Goals and functional requirements for inter-autonomous system routing M. Little October 1989 ASCII 62725 25

This document describes the functional requirements for a routing protocol to be used between autonomous systems. This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols. It is intended that these requirements will form the basis for the future development of a new inter-autonomous systems routing architecture and protocol. This memo does not specify a standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1126 RFC1127 Perspective on the Host Requirements RFCs R.T. Braden October 1989 ASCII 41267 20

This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1127 RFC1128 Measured performance of the Network Time Protocol in the Internet system D.L. Mills October 1989 ASCII 314 1 PS 633742 PDF 197897

This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific. The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119. NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave. In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio. The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications. For those hosts that support NTP, the experiments determine the distribution of errors and other statistics over paths spanning major portions of the globe. Finally, the experiments evaluate the accuracy and reliability of precision timekeeping using NTP and typical Internet paths involving DARPA, NSFNET and other agency networks. The experiments demonstrate that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo does not specify a standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1128 RFC1129 Internet Time Synchronization: The Network Time Protocol D.L. Mills October 1989 ASCII 298 1 PS 551697 PDF 197036 NTP

This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119.

 RFC1119 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1129 RFC1130 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board October 1989 ASCII 33858 17 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).

 RFC1100 RFC1140 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1130 RFC1131 OSPF specification J. Moy October 1989 ASCII 268 1 PS 2293049 PDF 685585

This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]

 RFC1247 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1131 RFC1132 Standard for the transmission of 802.2 packets over IPX networks L.J. McLaughlin November 1989 ASCII 7902 4 IP-IPX

This document specifies a standard method of encapsulating 802.2 packets on networks supporting Novell's Internet Packet Exchange Protocol (IPX). It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks. It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges.

 STD0049 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1132 RFC1133 Routing between the NSFNET and the DDN J.Y. Yu H.W. Braun November 1989 ASCII 23169 10

This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1133 RFC1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links D. Perkins November 1989 ASCII 87352 38

This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. [STANDARDS-TRACK]

 RFC1171 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1134 RFC1135 Helminthiasis of the Internet J.K. Reynolds December 1989 ASCII 77033 33

This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1135 RFC1136 Administrative Domains and Routing Domains: A model for routing in the Internet S. Hares D. Katz December 1989 ASCII 22158 10

This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the "OSI Routeing Framework". This memo does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1136 RFC1137 Mapping between full RFC 822 and RFC 822 with restricted encoding S. Kille December 1989 ASCII 6266 3

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard.

 RFC0976 HISTORIC HISTORIC Legacy 10.17487/RFC1137 RFC1138 Mapping between X.400(1988) / ISO 10021 and RFC 822 S.E. Kille December 1989 ASCII 191029 92

Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026.

 RFC2156 RFC1327 RFC1026 RFC0987 RFC0822 RFC1148 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1138 RFC1139 Echo function for ISO 8473 R.A. Hagens January 1990 ASCII 14229 6

This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item. When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard. This memo is not intended to compete with an ISO standard. [STANDARDS-TRACK]

 RFC1574 RFC1575 PROPOSED STANDARD PROPOSED STANDARD IETF osigen 10.17487/RFC1139 RFC1140 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board May 1990 ASCII 60501 27 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90.

 RFC1130 RFC1200 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1140 RFC1141 Incremental updating of the Internet checksum T. Mallory A. Kullberg January 1990 ASCII 3587 2

This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique.

 RFC1071 RFC1624 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1141 10.17487/RFC1141 RFC1142 OSI IS-IS Intra-domain Routing Protocol D. Oran Editor February 1990 ASCII 425379 517 PS 1440951 PDF 490300 Domain Routing ISO

This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.

 RFC7142 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1142 RFC1143 The Q Method of Implementing TELNET Option Negotiation D.J. Bernstein February 1990 ASCII 23331 10

This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1143 RFC1144 Compressing TCP/IP Headers for Low-Speed Serial Links V. Jacobson February 1990 ASCII 120959 49 PS 534729 PDF 255616 IP-CMPRS

This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1144 RFC1145 TCP alternate checksum options J. Zweig C. Partridge February 1990 ASCII 11052 5

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use.

 RFC1146 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1145 RFC1146 TCP alternate checksum options J. Zweig C. Partridge March 1990 ASCII 10955 5 TCP-ACO

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145.

 RFC1145 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1146 RFC1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices R.H. Stine April 1990 ASCII 336906 177 PS 555225 PDF 308602

The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained.

 RFC1470 INFORMATIONAL INFORMATIONAL IETF noctools 10.17487/RFC1147 RFC1148 Mapping between X.400(1988) / ISO 10021 and RFC 822 S.E. Kille March 1990 ASCII 194292 94

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.

 RFC2156 RFC1327 RFC1026 RFC0987 RFC1138 RFC0822 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1148 RFC1149 Standard for the transmission of IP datagrams on avian carriers D. Waitzman April 1 1990 ASCII 3329 2 avian carrier april fools

This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard.

 RFC2549 RFC6214 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1149 10.17487/RFC1149 RFC1150 FYI on FYI: Introduction to the FYI Notes G.S. Malkin J.K. Reynolds March 1990 ASCII 7867 4

This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.]

 RFC6360 HISTORIC INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1150 10.17487/RFC1150 RFC1151 Version 2 of the Reliable Data Protocol (RDP) C. Partridge R.M. Hinden April 1990 ASCII 8293 4 RDP

This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental.

 RFC0908 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1151 RFC1152 Workshop report: Internet research steering group workshop on very-high-speed networks C. Partridge April 1990 ASCII 64003 23

This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1152 RFC1153 Digest message format F.J. Wancho April 1990 ASCII 6632 4 DMF-MAIL

This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1153 RFC1154 Encoding header field for internet messages D. Robinson R. Ullmann April 1990 ASCII 12214 7

This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).

 RFC1505 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1154 RFC1155 Structure and identification of management information for TCP/IP-based internets M.T. Rose K. McCloghrie May 1990 ASCII 40927 22 SMI

This RFC is a re-release of RFC 1065, with a changed "Status of this Memo", plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK]

 RFC1065 STD0016 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1155 10.17487/RFC1155 RFC1156 Management Information Base for network management of TCP/IP-based internets K. McCloghrie M.T. Rose May 1990 ASCII 138781 91 MIB-I

This RFC is a re-release of RFC 1066, with a changed "Status of this Memo", "IAB Policy Statement", and "Introduction" sections plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK]

 RFC1066 HISTORIC HISTORIC Legacy 10.17487/RFC1156 RFC1157 Simple Network Management Protocol (SNMP) J.D. Case M. Fedor M.L. Schoffstall J. Davin May 1990 ASCII 74894 36 SNMP

This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]

 RFC1098 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1157 RFC1158 Management Information Base for network management of TCP/IP-based internets: MIB-II M.T. Rose May 1990 ASCII 212152 133

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]

 RFC1213 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1158 10.17487/RFC1158 RFC1159 Message Send Protocol R. Nelson June 1990 ASCII 3957 2

This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.

 RFC1312 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1159 RFC1160 Internet Activities Board V. Cerf May 1990 ASCII 28182 11

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.

 RFC1120 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1160 RFC1161 SNMP over OSI M.T. Rose June 1990 ASCII 16036 8

This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,

 RFC1418 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1161 RFC1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base G. Satz June 1990 ASCII 109893 70

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community.

 RFC1238 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1162 RFC1163 Border Gateway Protocol (BGP) K. Lougheed Y. Rekhter June 1990 ASCII 69404 29 BGP

This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1105 RFC1267 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1163 RFC1164 Application of the Border Gateway Protocol in the Internet J.C. Honig D. Katz M. Mathis Y. Rekhter J.Y. Yu June 1990 ASCII 56278 23 BGP

This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1268 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1164 RFC1165 Network Time Protocol (NTP) over the OSI Remote Operations Service J. Crowcroft J.P. Onions June 1990 ASCII 18277 10 NTP-OSI

This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1165 RFC1166 Internet numbers S. Kirkpatrick M.K. Stahl M. Recker July 1990 ASCII 566778 182

This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.

 RFC1117 RFC1062 RFC1020 RFC5737 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1166 RFC1167 Thoughts on the National Research and Education Network V.G. Cerf July 1990 ASCII 20682 8

The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1167 RFC1168 Intermail and Commercial Mail Relay services A. Westine A.L. DeSchon J. Postel C.E. Ward July 1990 ASCII 40306 18 PS 149816 PDF 55890

This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1168 RFC1169 Explaining the role of GOSIP V.G. Cerf K.L. Mills August 1990 ASCII 30255 15

This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1169 RFC1170 Public key standards and licenses R.B. Fougner January 1991 ASCII 3144 2

This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1170 RFC1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links D. Perkins July 1990 ASCII 92321 51

This memo specifies the Point-to-Point Protocol (PPP) as a Draft Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

 RFC1134 RFC1331 DRAFT STANDARD DRAFT STANDARD IETF int ppp 10.17487/RFC1171 RFC1172 Point-to-Point Protocol (PPP) initial configuration options D. Perkins R. Hobby July 1990 ASCII 76132 40

This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

 RFC1331 RFC1332 PROPOSED STANDARD PROPOSED STANDARD IETF int ppp 10.17487/RFC1172 RFC1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet J. VanBokkelen August 1990 ASCII 12527 5

This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1173 RFC1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status V.G. Cerf August 1990 ASCII 21321 9

This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1174 RFC1175 FYI on where to start: A bibliography of internetworking information K.L. Bowers T.L. LaQuey J.K. Reynolds K. Roubicek M.K. Stahl A. Yuan August 1990 ASCII 67330 43

This FYI RFC is a bibliography of information about TCP/IP internetworking, prepared by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 3.]

 FYI0003 INFORMATIONAL INFORMATIONAL IETF userdoc 10.17487/RFC1175 RFC1176 Interactive Mail Access Protocol: Version 2 M.R. Crispin August 1990 ASCII 67330 30 IMAP2

This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 RFC1064 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1176 RFC1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds August 1990 ASCII 52852 24

This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.]

 RFC1206 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1177 RFC1178 Choosing a name for your computer D. Libes August 1990 ASCII 18472 8

This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 5.]

 FYI0005 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1178 RFC1179 Line printer daemon protocol L. McLaughlin August 1990 ASCII 24324 14 LPDP

This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1179 RFC1180 TCP/IP tutorial T.J. Socolofsky C.J. Kale January 1991 ASCII 65494 28

This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1180 10.17487/RFC1180 RFC1181 RIPE Terms of Reference R. Blokzijl September 1990 ASCII 2523 2

This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1181 RFC1182 RFC1183 New DNS RR Definitions C.F. Everhart L.A. Mamakos R. Ullmann P.V. Mockapetris October 1990 ASCII 23788 11 DNS-RR

This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.

 RFC1034 RFC1035 RFC5395 RFC5864 RFC6195 RFC6895 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1183 10.17487/RFC1183 RFC1184 Telnet Linemode Option D.A. Borman October 1990 ASCII 53085 23 TOPT-LINE

This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK]

 RFC1116 DRAFT STANDARD DRAFT STANDARD IETF app telnet 10.17487/RFC1184 RFC1185 TCP Extension for High-Speed Paths V. Jacobson R.T. Braden L. Zhang October 1990 ASCII 49508 21

This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 RFC1323 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1185 RFC1186 MD4 Message Digest Algorithm R.L. Rivest October 1990 ASCII 35391 18

This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.

 RFC1320 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1186 RFC1187 Bulk Table Retrieval with the SNMP M.T. Rose K. McCloghrie J.R. Davin October 1990 ASCII 27220 12 SNMP-BULK

This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1187 RFC1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks D. Katz October 1990 ASCII 22424 11

This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

 RFC1103 DRAFT STANDARD DRAFT STANDARD IETF int fddi 10.17487/RFC1188 RFC1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP) U.S. Warrier L. Besaw L. LaBarre B.D. Handspicker October 1990 ASCII 32928 15 CMOT

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]

 RFC1095 HISTORIC HISTORIC IETF oim 10.17487/RFC1189 RFC1190 Experimental Internet Stream Protocol: Version 2 (ST-II) C. Topolcic October 1990 ASCII 386909 148

This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 IEN119 RFC1819 EXPERIMENTAL EXPERIMENTAL IETF int cip 10.17487/RFC1190 RFC1191 Path MTU discovery J.C. Mogul S.E. Deering November 1990 ASCII 47936 19 IP-MTU

This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]

 RFC1063 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1191 RFC1192 Commercialization of the Internet summary report B. Kahin November 1990 ASCII 35253 13

This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1192 RFC1193 Client requirements for real-time communication services D. Ferrari November 1990 ASCII 61540 24

This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1193 RFC1194 Finger User Information Protocol D.P. Zimmerman November 1990 ASCII 24626 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK]

 RFC0742 RFC1196 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1194 RFC1195 Use of OSI IS-IS for routing in TCP/IP and dual environments R.W. Callon December 1990 ASCII 187866 85 PS 362052 IS-IS

This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]

 RFC1349 RFC5302 RFC5304 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1195 10.17487/RFC1195 RFC1196 Finger User Information Protocol D.P. Zimmerman December 1990 ASCII 24799 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK]

 RFC1194 RFC0742 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1196 RFC1197 Using ODA for translating multimedia information M. Sherman December 1990 ASCII 3620 2

The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1197 RFC1198 FYI on the X window system R.W. Scheifler January 1991 ASCII 3629 3

This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard.

 FYI0006 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1198 RFC1199 Request for Comments Summary Notes: 1100-1199 J. Reynolds December 1991 ASCII 46443 22 Summary RFC INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1199 RFC1200 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1991 ASCII 67069 31 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.

 RFC1140 RFC1250 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1200 RFC1201 Transmitting IP traffic over ARCNET networks D. Provan February 1991 ASCII 16565 7 IP-ARC

This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the "ARCNET Packet Header Definition Standard". [STANDARDS-TRACK]

 RFC1051 STD0046 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1201 RFC1202 Directory Assistance service M.T. Rose February 1991 ASCII 21645 11 DAS

This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1202 RFC1203 Interactive Mail Access Protocol: Version 3 J. Rice February 1991 ASCII 123325 49 IMAP3

This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

 RFC1064 HISTORIC HISTORIC Legacy 10.17487/RFC1203 RFC1204 Message Posting Protocol (MPP) S. Yeh D. Lee February 1991 ASCII 11371 6 MPP

This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1204 RFC1205 5250 Telnet interface P. Chmielewski February 1991 ASCII 27179 12

This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard.

 RFC2877 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1205 RFC1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions G.S. Malkin A.N. Marine February 1991 ASCII 72479 32

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]

 RFC1177 RFC1325 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1206 RFC1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds February 1991 ASCII 33385 15

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard.

 FYI0007 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1207 RFC1208 A Glossary of Networking Terms O.J. Jacobsen D.C. Lynch March 1991 ASCII 41156 18

This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1208 RFC1209 The Transmission of IP Datagrams over the SMDS Service D. Piscitello J. Lawrence March 1991 ASCII 24662 11 IP-SMDS Switched Multi-megabit Data Service

This memo defines a protocol for the transmission of IP and ARP packets over a Switched Multi-megabit Data Service Network configured as a logical IP subnetwork. [STANDARDS-TRACK]

 STD0052 INTERNET STANDARD INTERNET STANDARD IETF int smds 10.17487/RFC1209 RFC1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990 V.G. Cerf P.T. Kirstein B. Randell March 1991 ASCII 79048 36

This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1210 RFC1211 Problems with the maintenance of large mailing lists A. Westine J. Postel March 1991 ASCII 96167 54

This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1211 RFC1212 Concise MIB definitions M.T. Rose K. McCloghrie March 1991 ASCII 43579 19 Concise-MIB

This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. This memo defines a format for producing MIB modules. [STANDARDS-TRACK]

 STD0016 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1212 RFC1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II K. McCloghrie M. Rose March 1991 ASCII 142158 70 MIB-II

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

 RFC1158 RFC2011 RFC2012 RFC2013 STD0017 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1213 RFC1214 OSI internet management: Management Information Base L. LaBarre April 1991 ASCII 172564 83 OIM-MIB-II

This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF oim 10.17487/RFC1214 RFC1215 Convention for defining traps for use with the SNMP M.T. Rose March 1991 ASCII 19336 9 SNMP-TRAPS

This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1215 RFC1216 Gigabit network economics and paradigm shifts P. Richard P. Kynikos April 1 1991 ASCII 8130 4

This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1216 RFC1217 Memo from the Consortium for Slow Commotion Research (CSCR) V.G. Cerf April 1 1991 ASCII 11079 5

This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1217 RFC1218 Naming scheme for c=US North American Directory Forum April 1991 ASCII 42698 23

This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1255 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1218 RFC1219 On the assignment of subnet numbers P.F. Tsuchiya April 1991 ASCII 30609 13 SUBNETASGN

This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1219 RFC1220 Point-to-Point Protocol extensions for bridging F. Baker April 1991 ASCII 38165 18

This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]

 RFC1638 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1220 RFC1221 Host Access Protocol (HAP) specification: Version 2 W. Edmond April 1991 ASCII 152740 68 HAP2

This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC0907 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1221 RFC1222 Advancing the NSFNET routing architecture H.W. Braun Y. Rekhter May 1991 ASCII 15067 6

This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1222 RFC1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel J.M. Halpern May 1991 ASCII 29601 12 OSI-HYPER

The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1223 RFC1224 Techniques for managing asynchronously generated alerts L. Steinberg May 1991 ASCII 54303 22 ALERTS

This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols. This memo specifies an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF alertman 10.17487/RFC1224 RFC1225 Post Office Protocol: Version 3 M.T. Rose May 1991 ASCII 37340 16

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]

 RFC1081 RFC1460 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1225 RFC1226 Internet protocol encapsulation of AX.25 frames B. Kantor May 1991 ASCII 2573 2 IP-AX.25

This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1226 RFC1227 SNMP MUX protocol and MIB M.T. Rose May 1991 ASCII 25868 13 SNMP-MUX

This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 HISTORIC HISTORIC Legacy http://www.rfc-editor.org/errata_search.php?rfc=1227 10.17487/RFC1227 RFC1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface G. Carpenter B. Wijnen May 1991 ASCII 96972 50

This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1592 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1228 RFC1229 Extensions to the generic-interface MIB K. McCloghrie May 1991 ASCII 36022 16

This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS-TRACK]

 RFC1573 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1229 RFC1230 IEEE 802.4 Token Bus MIB K. McCloghrie R. Fox May 1991 ASCII 53100 23 802.4-MIP

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]

 RFC1239 HISTORIC HISTORIC IETF snmp 10.17487/RFC1230 RFC1231 IEEE 802.5 Token Ring MIB K. McCloghrie R. Fox E. Decker May 1991 ASCII 53542 23

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

 RFC1743 RFC1748 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1231 RFC1232 Definitions of managed objects for the DS1 Interface type F. Baker C.P. Kolb May 1991 ASCII 60757 28 RFC1406 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1232 RFC1233 Definitions of managed objects for the DS3 Interface type T.A. Cox K. Tesink May 1991 ASCII 49559 23

This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

 RFC1407 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1233 RFC1234 Tunneling IPX traffic through IP networks D. Provan June 1991 ASCII 12333 6 IPX-IP

This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1234 RFC1235 Coherent File Distribution Protocol J. Ioannidis G. Maguire June 1991 ASCII 29345 12 CFDP

This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1235 RFC1236 IP to X.121 address mapping for DDN L. Morales P. Hasse June 1991 ASCII 12626 7 IP-X.121

This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1236 RFC1237 Guidelines for OSI NSAP Allocation in the Internet R. Colella E. Gardner R. Callon July 1991 ASCII 116989 48 PS 160478 PDF 171423

This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]

 RFC1629 PROPOSED STANDARD PROPOSED STANDARD IETF osinsap 10.17487/RFC1237 RFC1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) G. Satz June 1991 ASCII 65159 32 CLNS-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1162 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1238 RFC1239 Reassignment of experimental MIBs to standard MIBs J.K. Reynolds June 1991 ASCII 3656 2 STD-MIBs

This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]

 RFC1229 RFC1230 RFC1231 RFC1232 RFC1233 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1239 RFC1240 OSI connectionless transport services on top of UDP: Version 1 C. Shue W. Haggerty K. Dobbins June 1991 ASCII 18140 8 OSI-UDP

This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1240 RFC1241 Scheme for an internet encapsulation protocol: Version 1 R.A. Woodburn D.L. Mills July 1991 ASCII 42468 17 PS 128921 PDF 44593 IN-ENCAP

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1241 RFC1242 Benchmarking Terminology for Network Interconnection Devices S. Bradner July 1991 ASCII 22817 12

This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6201 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1242 RFC1243 AppleTalk Management Information Base S. Waldbusser July 1991 ASCII 61985 29

This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]

 RFC1742 PROPOSED STANDARD PROPOSED STANDARD IETF int appleip 10.17487/RFC1243 RFC1244 Site Security Handbook J.P. Holbrook J.K. Reynolds July 1991 ASCII 259129 101

This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8]

 RFC2196 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1244 RFC1245 OSPF Protocol Analysis J. Moy July 1991 ASCII 26160 12 PS 33546 PDF 31723 OSPF SPF routing TOS LSA flooding

This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard.

 RFC1246 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1245 RFC1246 Experience with the OSPF Protocol J. Moy July 1991 ASCII 70441 31 PS 141924 PDF 84633 OSPF SPF routing MIB experience testing

This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard.

 RFC1245 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1246 RFC1247 OSPF Version 2 J. Moy July 1991 ASCII 433332 189 PS 989724 PDF 490300 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]

 RFC1131 RFC1583 RFC1349 RFC1245 RFC1246 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1247 RFC1248 OSPF Version 2 Management Information Base F. Baker R. Coltun July 1991 ASCII 74347 42 OSPF SPF MIB routing network management

This memo defines an experimental 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 OSPF Version 2. [STANDARDS-TRACK]

 RFC1252 RFC1349 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1248 RFC1249 DIXIE Protocol Specification T. Howes M. Smith B. Beecher August 1991 ASCII 20028 10 DIXIE DIXIE protocol directory services X.500 DAP

This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard.

 RFC1202 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1249 RFC1250 IAB Official Protocol Standards J. Postel August 1991 ASCII 62555 28 standards protocol IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1200 RFC2200 RFC1280 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1250 RFC1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin August 1991 ASCII 70383 26 IESG IRSG IAB

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]

 RFC1336 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1251 RFC1252 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII 74471 42 OSPF SPF MIB routing network management

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 OSPF Version 2. [STANDARDS-TRACK]

 RFC1248 RFC1253 RFC1245 RFC1247 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1252 RFC1253 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII 74453 42

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 OSPF Version 2. [STANDARDS-TRACK]

 RFC1252 RFC1850 RFC1245 RFC1246 RFC1247 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1253 RFC1254 Gateway Congestion Control Survey A. Mankin K. Ramakrishnan August 1991 ASCII 67609 25 gateway congestion SQ source quench fiar queueing random drop

The purpose of this paper is to present a review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing.

 INFORMATIONAL INFORMATIONAL IETF int pcc 10.17487/RFC1254 RFC1255 A Naming Scheme for c=US The North American Directory Forum September 1991 ASCII 51103 25 naming NADF X.500 directory services c=us

This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1218 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1255 RFC1256 ICMP Router Discovery Messages S. Deering Editor September 1991 ASCII 43059 19 ICMP-ROUT ICMP router gateway discovery standard protocol

This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int rdisc 10.17487/RFC1256 RFC1257 Isochronous applications do not require jitter-controlled networks C. Partridge September 1991 ASCII 11075 5

This memo argues that jitter control is not required for networks to support isochronous applications. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1257 RFC1258 BSD Rlogin B. Kantor September 1991 ASCII 10763 5

The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1282 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1258 10.17487/RFC1258 RFC1259 Building the open road: The NREN as test-bed for the national public network M. Kapor September 1991 ASCII 61654 23 NREN test-bed network policy

This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1259 RFC1260 RFC1261 Transition of Nic Services S. Williamson L. Nobile September 1991 ASCII 4244 3 NIC transition

This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1261 RFC1262 Guidelines for Internet Measurement Activities V.G. Cerf October 1991 ASCII 6381 3

This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1262 RFC1263 TCP Extensions Considered Harmful S. O'Malley L.L. Peterson October 1991 ASCII 54078 19

This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1263 RFC1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria R.M. Hinden October 1991 ASCII 17016 8

This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.

 RFC4794 HISTORIC INFORMATIONAL IETF IESG 10.17487/RFC1264 RFC1265 BGP Protocol Analysis Y. Rekhter October 1991 ASCII 20728 8

This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1265 RFC1266 Experience with the BGP Protocol Y. Rekhter October 1991 ASCII 21938 9

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1266 RFC1267 Border Gateway Protocol 3 (BGP-3) K. Lougheed Y. Rekhter October 1991 ASCII 80724 35 BGP3

This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1163 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1267 RFC1268 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross October 1991 ASCII 31102 13 BGP3

This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

 RFC1164 RFC1655 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1268 RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 S. Willis J.W. Burruss October 1991 ASCII 25717 13 BGP-MIB

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 the Border Gateway Protocol. [STANDARDS-TRACK]

 RFC4273 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1269 RFC1270 SNMP Communications Services F. Kastenholz October 1991 ASCII 26167 11

This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1270 RFC1271 Remote Network Monitoring Management Information Base S. Waldbusser November 1991 ASCII 184111 81

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 RFC1757 RFC1513 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1271 RFC1272 Internet Accounting: Background C. Mills D. Hirsh G.R. Ruth November 1991 ASCII 46562 19

This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF acct 10.17487/RFC1272 RFC1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations M.F. Schwartz November 1991 ASCII 19949 8

This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1273 RFC1274 The COSINE and Internet X.500 Schema P. Barker S. Kille November 1991 ASCII 92827 60 Naming

This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK]

 RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1274 RFC1275 Replication Requirements to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII 4616 3 PS 83736 PDF 73349

This RFC considers certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services [CCI88]. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1275 RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII 33731 17 PS 217170

Some requirements on extensions to X.500 are described in the RFC[HK91b], in order to build an Internet Directory using X.500(1988). This document specifies a set of solutions to the problems raised. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1276 RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers S.E. Hardcastle-Kille November 1991 ASCII 22254 12 PS 176169 address ISO OSI

This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1277 RFC1278 A string encoding of Presentation Address S.E. Hardcastle-Kille November 1991 ASCII 10256 7 PS 128696 OSI ASN.1

There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1278 RFC1279 X.500 and Domains S.E. Hardcastle-Kille November 1991 ASCII 26669 15 PS 170029 PDF 142776 Domain Name naming

This RFC considers X.500 in relation to Internet and UK Domains. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1279 RFC1280 IAB Official Protocol Standards J. Postel March 1992 ASCII 70458 32

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1250 RFC1360 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1280 RFC1281 Guidelines for the Secure Operation of the Internet R. Pethia S. Crocker B. Fraser November 1991 ASCII 22618 10 security privacy protection guideline

The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF sec spwg 10.17487/RFC1281 RFC1282 BSD Rlogin B. Kantor December 1991 ASCII 10704 5 BSD Login Unix remote-login remote-logon

This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1258 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1282 RFC1283 SNMP over OSI M. Rose December 1991 ASCII 16857 8 ISO Management MIB

This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard.

 RFC1418 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1283 RFC1284 Definitions of Managed Objects for the Ethernet-like Interface Types J. Cook Editor December 1991 ASCII 43225 21 SNMP MIB Management

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 ethernet-like objects. [STANDARDS-TRACK]

 RFC1398 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1284 RFC1285 FDDI Management Information Base J. Case January 1992 ASCII 99747 46 FDDI-MIB standard standards MIB SNMP

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 devices which implement the FDDI. [STANDARDS-TRACK]

 RFC1512 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1285 RFC1286 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie December 1991 ASCII 79104 40 SNMP MIB standard standards

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 bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]

 RFC1493 RFC1525 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC1286 RFC1287 Towards the Future Internet Architecture D. Clark L. Chapin V. Cerf R. Braden R. Hobby December 1991 ASCII 59812 29

This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1287 RFC1288 The Finger User Information Protocol D. Zimmerman December 1991 ASCII 25161 12 FINGER

This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK]

 RFC1196 RFC1194 RFC0742 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1288 RFC1289 DECnet Phase IV MIB Extensions J. Saperia December 1991 ASCII 122272 64 SNMP Management protocol standard standards

This memo is an extension to the SNMP MIB. This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. [STANDARDS-TRACK]

 RFC1559 PROPOSED STANDARD PROPOSED STANDARD IETF decnetiv 10.17487/RFC1289 RFC1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin December 1991 ASCII 46997 27 SIGUCCS User Services Help Internet

This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users. This RFC provides information for the Internet community. It does not specify an Internet standard.

 RFC1402 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1290 RFC1291 Mid-Level Networks Potential Technical Services V. Aggarwal December 1991 ASCII 24314 10 PS 218918 statistics connectivity management

This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. This RFC provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1291 RFC1292 A Catalog of Available X.500 Implementations R. Lang R. Wright January 1992 ASCII 129468 103

The goal of this document is to provide information regarding the availability and capability of implementations of X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1632 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1292 RFC1293 Inverse Address Resolution Protocol T. Bradley C. Brown January 1992 ASCII 11368 6 standard standards ARP DLCI

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

 RFC2390 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1293 RFC1294 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis January 1992 ASCII 54992 28 standard standards

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

 RFC1490 RFC2427 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1294 RFC1295 User Bill of Rights for entries and listings in the Public Directory The North American Directory Forum January 1992 ASCII 3502 2 NADF-265 NADF X.500

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 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1295 RFC1296 Internet Growth (1981-1991) M. Lottor January 1992 ASCII 20103 9 statistics ZONE

This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1296 RFC1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS") D. Johnson January 1992 ASCII 32964 12 problems tracking operations NOC

This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF ucp 10.17487/RFC1297 RFC1298 SNMP over IPX R. Wormley S. Bostock February 1992 ASCII 7878 5

This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1420 INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1298 RFC1299 Summary of 1200-1299 M. Kennedy January 1997 ASCII 36594 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1299 RFC1300 Remembrances of Things Past S. Greenfield February 1992 ASCII 4963 4 poem

Poem. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1300 RFC1301 Multicast Transport Protocol S. Armstrong A. Freier K. Marzullo February 1992 ASCII 91976 38 MTP MTP reliable transport multicast broadcast collaboration networking

This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1301 RFC1302 Building a Network Information Services Infrastructure D. Sitzler P. Smith A. Marine February 1992 ASCII 29135 13 NISI NIC User Services

This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0012 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1302 RFC1303 A Convention for Describing SNMP-based Agents K. McCloghrie M. Rose February 1992 ASCII 22915 12 SNMP MIB Network Management,

This memo suggests a straight-forward approach towards describing SNMP- based agents. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1155 RFC1157 RFC1212 RFC1213 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1303 RFC1304 Definitions of Managed Objects for the SIP Interface Type T. Cox Editor K. Tesink Editor February 1992 ASCII 52491 25 Standard MIB Network Management SMDS

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 SIP (SMDS Interface Protocol) objects. [STANDARDS-TRACK]

 RFC1694 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1304 RFC1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis D. Mills March 1992 ASCII 307085 109 PDF 442493 NTPV3 NTP

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]

 RFC0958 RFC1059 RFC1119 RFC5905 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1305 RFC1306 Experiences Supporting By-Request Circuit-Switched T3 Networks A. Nicholson J. Young March 1992 ASCII 25788 10 WAN Wide Area Net FDDI

This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. This RFC provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1306 RFC1307 Dynamically Switched Link Control Protocol J. Young A. Nicholson March 1992 ASCII 24145 13 DSLCP Experimental Protocol T3 FDDI

This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1307 RFC1308 Executive Introduction to Directory Services Using the X.500 Protocol C. Weider J. Reynolds March 1992 ASCII 9392 4

This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0013 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1308 RFC1309 Technical Overview of Directory Services Using the X.500 Protocol C. Weider J. Reynolds S. Heker March 1992 ASCII 35694 16

This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0014 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1309 RFC1310 The Internet Standards Process L. Chapin March 1992 ASCII 54738 23

This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]

 RFC1602 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1310 RFC1311 Introduction to the STD Notes J. Postel March 1992 ASCII 11308 5 new IAB

The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK]

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1311 RFC1312 Message Send Protocol 2 R. Nelson G. Arnold April 1992 ASCII 18037 8 MSP2 MSP talk

The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.

 RFC1159 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1312 RFC1313 Today's Programming for KRFC AM 1313 Internet Talk Radio C. Partridge April 1 1992 ASCII 5444 3

Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1313 RFC1314 A File Format for the Exchange of Images in the Internet A. Katz D. Cohen April 1992 ASCII 54072 23 NETFAX netfax TIFF facsimile

This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app netfax 10.17487/RFC1314 RFC1315 Management Information Base for Frame Relay DTEs C. Brown F. Baker C. Carvalho April 1992 ASCII 33825 19 MIB

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 Frame Relay. [STANDARDS-TRACK]

 RFC2115 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1315 RFC1316 Definitions of Managed Objects for Character Stream Devices B. Stewart April 1992 ASCII 35143 17 MIB

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 the management of character stream devices. [STANDARDS-TRACK]

 RFC1658 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1316 RFC1317 Definitions of Managed Objects for RS-232-like Hardware Devices B. Stewart April 1992 ASCII 30442 17 MIB

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 the management of RS-232-like devices. [STANDARDS-TRACK]

 RFC1659 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1317 RFC1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices B. Stewart April 1992 ASCII 19570 11 MIB

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 the management of parallel-printer- like devices. [STANDARDS-TRACK]

 RFC1660 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1318 RFC1319 The MD2 Message-Digest Algorithm B. Kaliski April 1992 ASCII 25661 17 security encryption signature

This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6149 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1319 10.17487/RFC1319 RFC1320 The MD4 Message-Digest Algorithm R. Rivest April 1992 ASCII 32407 20 MD4 security encryption signature

This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1186 RFC6150 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1320 10.17487/RFC1320 RFC1321 The MD5 Message-Digest Algorithm R. Rivest April 1992 ASCII 35222 21 security signature eneryption

This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6151 INFORMATIONAL INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1321 10.17487/RFC1321 RFC1322 A Unified Approach to Inter-Domain Routing D. Estrin Y. Rekhter S. Hotz May 1992 ASCII 96934 38 path vector routing source demand routing

This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg bgp http://www.rfc-editor.org/errata_search.php?rfc=1322 10.17487/RFC1322 RFC1323 TCP Extensions for High Performance V. Jacobson R. Braden D. Borman May 1992 ASCII 84558 37 TCP-EXT options PAWS window scale window

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 new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]

 RFC1072 RFC1185 RFC7323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=1323 10.17487/RFC1323 RFC1324 A Discussion on Computer Network Conferencing D. Reed May 1992 ASCII 24988 11 talk real time chat

This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1324 RFC1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions G. Malkin A. Marine May 1992 ASCII 91884 42 documentation help information

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1206 RFC1594 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1325 RFC1326 Mutual Encapsulation Considered Dangerous P. Tsuchiya May 1992 ASCII 11277 5 protocol layering wrapping

This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1326 RFC1327 Mapping between X.400(1988) / ISO 10021 and RFC 822 S. Hardcastle-Kille May 1992 ASCII 228598 113 Electronic-mail,Message handling systems

This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK]

 RFC0987 RFC1026 RFC1138 RFC1148 RFC2156 RFC0822 RFC1495 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1327 RFC1328 X.400 1988 to 1984 downgrading S. Hardcastle-Kille May 1992 ASCII 10006 5 Electronic-mail message handling systems,mail

This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1328 RFC1329 Thoughts on Address Resolution for Dual MAC FDDI Networks P. Kuehn May 1992 ASCII 58150 28

In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1329 RFC1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community ESCC X.500/X.400 Task Force ESnet Site Coordinating Comittee (ESCC) Energy Sciences Network (ESnet) May 1992 ASCII 192925 87

This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1330 RFC1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links W. Simpson May 1992 ASCII 129892 69 serial line IP over serial dial-up

This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

 RFC1171 RFC1172 RFC1548 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1331 RFC1332 The PPP Internet Protocol Control Protocol (IPCP) G. McGregor May 1992 ASCII 17613 14 PPP-IPCP serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]

 RFC1172 RFC3241 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1332 RFC1333 PPP Link Quality Monitoring W. Simpson May 1992 ASCII 29965 17 serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. [STANDARDS-TRACK]

 RFC1989 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1333 RFC1334 PPP Authentication Protocols B. Lloyd W. Simpson October 1992 ASCII 33248 16 point serial line dial-up

This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK]

 RFC1994 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1334 RFC1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion Z. Wang J. Crowcroft May 1992 ASCII 15418 7 internet protocol IP

This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1335 RFC1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin May 1992 ASCII 92119 33 Almquist Braden Braun Callon Cerf Chiappa Chapin Clark Crocker Davin Estrin Hobby Huitema Huizer Kent Lauck Leiner Lynch Piscitello Postel Reynolds Schwartz Stockman Vaudreuil

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify any standard.

 RFC1251 FYI0009 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1336 RFC1337 TIME-WAIT Assassination Hazards in TCP R. Braden May 1992 ASCII 22887 11 TCP protocol protocol state graceful close reset

This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1337 RFC1338 Supernetting: an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan June 1992 ASCII 47975 20 internet address routing

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1519 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1338 RFC1339 Remote Mail Checking Protocol S. Dorner P. Resnick June 1992 ASCII 13115 6 RMCP email remote mail

This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1339 RFC1340 Assigned Numbers J. Reynolds J. Postel July 1992 ASCII 232974 139

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

 RFC1060 RFC1700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1340 10.17487/RFC1340 RFC1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed June 1992 ASCII 211117 80 PS 347082 PDF 192244 EMail Multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]

 RFC1521 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1341 RFC1342 Representation of Non-ASCII Text in Internet Message Headers K. Moore June 1992 ASCII 15845 7 EMail Character Sets

This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC 822 message headers. [STANDARDS-TRACK]

 RFC1522 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1342 RFC1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information N. Borenstein June 1992 ASCII 29295 10 PS 59978 PDF 28495 EMail Multimedia

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1343 RFC1344 Implications of MIME for Internet Mail Gateways N. Borenstein June 1992 ASCII 25872 9 PS 51812 PDF 24430 EMail Forwarding Relaying Fragmentation Multimedia

While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1344 RFC1345 Character Mnemonics and Character Sets K. Simonsen June 1992 ASCII 249737 103

This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=1345 10.17487/RFC1345 RFC1346 Resource Allocation, Control, and Accounting for the Use of Network Resources P. Jones June 1992 ASCII 13084 6

The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1346 RFC1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing R. Callon June 1992 ASCII 26563 8 PS 42398 PDF 22398

This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1347 RFC1348 DNS NSAP RRs B. Manning July 1992 ASCII 6871 4 domain names CLNP resource records

This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.

 RFC1637 RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1348 RFC1349 Type of Service in the Internet Protocol Suite P. Almquist July 1992 ASCII 68949 28 TOS TOS IP

This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]

 RFC2474 RFC1248 RFC1247 RFC1195 RFC1123 RFC1122 RFC1060 RFC0791 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq http://www.rfc-editor.org/errata_search.php?rfc=1349 10.17487/RFC1349 RFC1350 The TFTP Protocol (Revision 2) K. Sollins July 1992 ASCII 24599 11 TFTP trivial file transfer booting

TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]

 RFC0783 RFC1782 RFC1783 RFC1784 RFC1785 RFC2347 RFC2348 RFC2349 STD0033 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1350 10.17487/RFC1350 RFC1351 SNMP Administrative Model J. Davin J. Galvin K. McCloghrie July 1992 ASCII 80721 35 SNMP-ADMIN network management authentication

This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1351 RFC1352 SNMP Security Protocols J. Galvin K. McCloghrie J. Davin July 1992 ASCII 95732 41 SNMP-SEC network management authentication

The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1352 RFC1353 Definitions of Managed Objects for Administration of SNMP Parties K. McCloghrie J. Davin J. Galvin July 1992 ASCII 59556 26 SNMP-PARTY-MIB network management authentication

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 describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet Standard SMI [1]. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1353 RFC1354 IP Forwarding Table MIB F. Baker July 1992 ASCII 24905 12 Network Management Route Table

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 routes in the IP Internet. [STANDARDS-TRACK]

 RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq 10.17487/RFC1354 RFC1355 Privacy and Accuracy Issues in Network Information Center Databases J. Curran A. Marine August 1992 ASCII 8858 4 NIC data privacy accuracy

This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0015 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1355 RFC1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode A. Malis D. Robinson R. Ullmann August 1992 ASCII 32043 14 IP-X.25 IP on X.25

This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards. It is a replacement for RFC 877, "A Standard for the Transmission of IP Datagrams Over Public Data Networks" [1]. [STANDARDS-TRACK]

 RFC0877 DRAFT STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1356 RFC1357 A Format for E-mailing Bibliographic Records D. Cohen July 1992 ASCII 25021 13 library technical reports email services

This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1807 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1357 RFC1358 Charter of the Internet Architecture Board (IAB) L. Chapin August 1992 ASCII 11328 5 ISOC Internet Society IETF IRTF

The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1601 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1358 RFC1359 Connecting to the Internet - What Connecting Institutions Should Anticipate ACM SIGUCCS August 1992 ASCII 53449 25 Internet access

This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0016 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1359 RFC1360 IAB Official Protocol Standards J. Postel September 1992 ASCII 71860 33 proposed draft experimental informational historic full RFC1280 RFC1410 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1360 RFC1361 Simple Network Time Protocol (SNTP) D. Mills August 1992 ASCII 23812 10 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memorandum does not obsolete or update any RFC. This memo provides information for the Internet community. It does not specify an Internet standard. Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization. Finally come pointers to references and contacts for further information. [STANDARDS-TRACK]

 RFC1769 RFC1305 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1361 10.17487/RFC1361 RFC1362 Novell IPX over Various WAN Media (IPXWAN) M. Allen September 1992 ASCII 30219 13 IPX on X.25 IPX on PPP IPX on Frame Relay

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1362 RFC1363 A Proposed Flow Specification C. Partridge September 1992 ASCII 59214 20 flow spec resource reservation stream type of service quality of service INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1363 RFC1364 BGP OSPF Interaction K. Varadhan September 1992 ASCII 32121 14 autonomous system border router open shortest path first routing protocol domain route exchange exporting importing RFC1403 RFC1247 RFC1267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1364 RFC1365 An IP Address Extension Proposal K. Siyan September 1992 ASCII 12790 6 class F addresses INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1365 10.17487/RFC1365 RFC1366 Guidelines for Management of IP Address Space E. Gerich October 1992 ASCII 17793 8 routing tables allocation registry IR IANA

This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specification The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1466 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1366 RFC1367 Schedule for IP Address Space Management Guidelines C. Topolcic October 1992 ASCII 4780 3 routing tables allocation registry IR IANA

This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1467 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1367 RFC1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie October 1992 ASCII 83905 40 MIB hub management

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 IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs". [STANDARDS-TRACK]

 RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1368 RFC1369 Implementation Notes and Experience for the Internet Ethernet MIB F. Kastenholz October 1992 ASCII 13961 7 management

This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL PROPOSED STANDARD IETF ethermib 10.17487/RFC1369 RFC1370 Applicability Statement for OSPF Internet Architecture Board L. Chapin October 1992 ASCII 4303 2 routing open shortest path first

This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1370 RFC1371 Choosing a Common IGP for the IP Internet P. Gross October 1992 ASCII 18168 9 routing recommendation interior gateway protocol

This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single "common IGP" for the IP portions of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1371 RFC1372 Telnet Remote Flow Control Option C. Hedrick D. Borman October 1992 ASCII 11098 6 TOPT-RFC terminal access

This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]

 RFC1080 PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1372 RFC1373 Portable DUAs T. Tignor October 1992 ASCII 19931 12 directory user agents whois de dixie ud doog ISODE X.500

This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1373 RFC1374 IP and ARP on HIPPI J. Renwick A. Nicholson October 1992 ASCII 100903 43

The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. This memo is intended to become an Internet Standard. [STANDARDS-TRACK]

 RFC2834 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1374 RFC1375 Suggestion for New Classes of IP Addresses P. Robinson October 1992 ASCII 16990 7 network numbers

This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1375 RFC1376 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum November 1992 ASCII 12448 6 point DNA DDCMP

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). [STANDARDS-TRACK]

 RFC1762 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1376 RFC1377 The PPP OSI Network Layer Control Protocol (OSINLCP) D. Katz November 1992 ASCII 22109 10 PPP-OSINLCP point open systems interconnection

This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1377 RFC1378 The PPP AppleTalk Control Protocol (ATCP) B. Parker November 1992 ASCII 28496 16 PPP-ATCP point

This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1378 RFC1379 Extending TCP for Transactions -- Concepts R. Braden November 1992 ASCII 91353 38 transmission control protocol

This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6247 RFC1644 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1379 RFC1380 IESG Deliberations on Routing and Addressing P. Gross P. Almquist November 1992 ASCII 49415 22 ROAD

This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1380 RFC1381 SNMP MIB Extension for X.25 LAPB D. Throop F. Baker November 1992 ASCII 71253 33 SNMP-LAPB management

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 the Link Layer of X.25, LAPB. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1381 RFC1382 SNMP MIB Extension for the X.25 Packet Layer D. Throop Editor November 1992 ASCII 153877 69 SNMP-X.25 management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1382 RFC1383 An Experiment in DNS Based IP Routing C. Huitema December 1992 ASCII 32680 14 DNS-IP

Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1383 RFC1384 Naming Guidelines for Directory Pilots P. Barker S.E. Hardcastle-Kille January 1993 ASCII 25870 12 PS 175044 PDF 134487 X.500 Multinational

This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1617 RTR0011 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1384 RFC1385 EIP: The Extended Internet Protocol Z. Wang November 1992 ASCII 39123 17 addressing

EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1385 RFC1386 The US Domain A. Cooper J. Postel December 1992 ASCII 62310 31 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1480 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1386 RFC1387 RIP Version 2 Protocol Analysis G. Malkin January 1993 ASCII 5598 3 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1721 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1387 RFC1388 RIP Version 2 Carrying Additional Information G. Malkin January 1993 ASCII 16227 7 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), as defined in [STANDARDS-TRACK]

 RFC1723 RFC1058 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1388 RFC1389 RIP Version 2 MIB Extensions G. Malkin F. Baker January 1993 ASCII 23569 13 RIP-2 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. [STANDARDS-TRACK]

 RFC1724 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1389 RFC1390 Transmission of IP and ARP over FDDI Networks D. Katz January 1993 ASCII 22077 11 IP-FDDI IEEE 802 MAC

This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

 STD0036 INTERNET STANDARD INTERNET STANDARD IETF int fddi 10.17487/RFC1390 RFC1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force G. Malkin January 1993 ASCII 41892 19 meetings

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1539 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1391 RFC1392 Internet Users' Glossary G. Malkin T. LaQuey Parker January 1993 ASCII 104624 53

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1983 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1392 RFC1393 Traceroute Using an IP Option G. Malkin January 1993 ASCII 13140 7 TRACE-IP ICMP MTU Line Speed

This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. This memo defines an Experimental Protocol for the Internet community.

 RFC6814 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1393 RFC1394 Relationship of Telex Answerback Codes to Internet Domains P. Robinson January 1993 ASCII 43776 15 DNS Country

This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available. It will also list major Internet "Public" E-Mail addresses. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1394 RFC1395 BOOTP Vendor Information Extensions J. Reynolds January 1993 ASCII 16314 8 TAGS

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).

 RFC1084 RFC1048 RFC1497 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1395 RFC1396 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker January 1993 ASCII 22096 10 IAB IESG ISOC

This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1396 RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol D. Haskin January 1993 ASCII 4124 2 BGP

This document speficies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1397 RFC1398 Definitions of Managed Objects for the Ethernet-Like Interface Types F. Kastenholz January 1993 ASCII 36684 17 MIB Management

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 ehternet-like objects. [STANDARDS-TRACK]

 RFC1284 RFC1623 DRAFT STANDARD DRAFT STANDARD IETF ethermib 10.17487/RFC1398 RFC1399 Summary of 1300-1399 J. Elliott January 1997 ASCII 43662 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1399 RFC1400 Transition and Modernization of the Internet Registration Service S. Williamson March 1993 ASCII 13008 7 INTERNIC IR

As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1400 RFC1401 Correspondence between the IAB and DISA on the use of DNS Internet Architecture Board January 1993 ASCII 12528 8 Domain Name Milnet

This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt". This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1401 RFC1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin January 1993 ASCII 71176 39 information introduction SIGUCCS User Services Help

The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer. This RFC provides information for the Internet community. It does not specify an Internet standard.

 RFC1290 FYI0010 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1402 RFC1403 BGP OSPF Interaction K. Varadhan January 1993 ASCII 36173 17 BGP-OSPF border gateway protocol open shortest path first routing

This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

 RFC1364 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1403 RFC1404 A Model for Common Operational Statistics B. Stockman January 1993 ASCII 52814 27 Management Operations

This memo describes a model for operational statistics in the Internet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1857 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1404 RFC1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) C. Allocchio January 1993 ASCII 33885 19 SMTP EMail 822

This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. This memo defines an Experimental Protocol for the Internet community.

 RFC2162 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1405 RFC1406 Definitions of Managed Objects for the DS1 and E1 Interface Types F. Baker Editor J. Watt Editor January 1993 ASCII 97559 50 DS1/E1-MIB T1 MIB Management SNMP

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 DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. [STANDARDS-TRACK]

 RFC1232 RFC2495 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1406 RFC1407 Definitions of Managed Objects for the DS3/E3 Interface Type T. Cox K. Tesink January 1993 ASCII 90682 43 DS3/E3-MIB T3 MIB Management SNMP

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3 Interfaces. [STANDARDS-TRACK]

 RFC1233 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1407 RFC1408 Telnet Environment Option D. Borman Editor January 1993 ASCII 13936 7 TOPT-ENVIR Negotiation

This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK]

 RFC1571 HISTORIC HISTORIC IETF app telnet 10.17487/RFC1408 RFC1409 Telnet Authentication Option D. Borman Editor January 1993 ASCII 13119 7 security

This memo defines an Experimental Protocol for the Internet community.

 RFC1416 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1409 RFC1410 IAB Official Protocol Standards J. Postel Editor March 1993 ASCII 76524 35 proposed draft experimental informational historic full

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).

 RFC1360 RFC1500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1410 RFC1411 Telnet Authentication: Kerberos Version 4 D. Borman Editor January 1993 ASCII 7967 4 TEL-KER Security option

This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1411 RFC1412 Telnet Authentication: SPX K. Alagappan January 1993 ASCII 6952 4 TEL-SPX Security option

This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1412 RFC1413 Identification Protocol M. St. Johns February 1993 ASCII 16291 8 IDENT Authentication

The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]

 RFC0931 PROPOSED STANDARD PROPOSED STANDARD IETF sec ident http://www.rfc-editor.org/errata_search.php?rfc=1413 10.17487/RFC1413 RFC1414 Identification MIB M. St. Johns M. Rose February 1993 ASCII 14165 7 IDENT-MIB Management SNMP

This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec ident 10.17487/RFC1414 RFC1415 FTP-FTAM Gateway Specification J. Mindel R. Slaski January 1993 ASCII 128261 58 FTP FTAM transfer ISO OSI

This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1415 RFC1416 Telnet Authentication Option D. Borman Editor February 1993 ASCII 13270 7 TOPT-AUTH Security

This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community.

 RFC1409 RFC2941 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1416 RFC1417 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1993 ASCII 7270 4 X.500 Directory

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1295 RFC1255 RFC1218 RFC1758 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1417 RFC1418 SNMP over OSI M. Rose March 1993 ASCII 7721 4 SNMP-OSI Management

This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]

 RFC1161 RFC1283 HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1418 RFC1419 SNMP over AppleTalk G. Minshall M. Ritter March 1993 ASCII 16470 7 SNMP-AT Management

This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1419 RFC1420 SNMP over IPX S. Bostock March 1993 ASCII 6762 4 SNMP-IPX Management

This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. [STANDARDS-TRACK]

 RFC1298 PROPOSED STANDARD PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1420 RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures J. Linn February 1993 ASCII 103894 42 PEM-ENC PEM

This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]

 RFC1113 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1421 RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management S. Kent February 1993 ASCII 86085 32 PEM-CKM PEM

This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]

 RFC1114 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1422 RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers D. Balenson February 1993 ASCII 33277 14 PEM-ALG PEM

This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK]

 RFC1115 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1423 RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services B. Kaliski February 1993 ASCII 17537 9 PEM-KEY PEM

This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1424 RFC1425 SMTP Service Extensions J. Klensin WG Chair N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII 20932 10 Mail

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

 RFC1651 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1425 RFC1426 SMTP Service Extension for 8bit-MIMEtransport J. Klensin WG Chair N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII 11661 6 Mail

This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex

 RFC1652 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1426 RFC1427 SMTP Service Extension for Message Size Declaration J. Klensin WG Chair N. Freed Editor K. Moore February 1993 ASCII 17856 8 Mail

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

 RFC1653 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1427 RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME G. Vaudreuil February 1993 ASCII 12064 6 Mail

This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. This RFC provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app smtpext 10.17487/RFC1428 RFC1429 Listserv Distribute Protocol E. Thomas February 1993 ASCII 17759 8 LISTSERV Mail

This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1429 RFC1430 A Strategic Plan for Deploying an Internet X.500 Directory Service S. Hardcastle-Kille E. Huizer V. Cerf R. Hobby S. Kent February 1993 ASCII 47587 20 X.500

This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1430 RFC1431 DUA Metrics (OSI-DS 33 (v2)) P. Barker February 1993 ASCII 42240 19 Directory User Agent Measurement Statistics Survey X.500

This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1431 RFC1432 Recent Internet Books J. Quarterman March 1993 ASCII 27089 15 bibiography

Here is a list of books related to using the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1432 RFC1433 Directed ARP J. Garrett J. Hagan J. Wong March 1993 ASCII 41028 18 DIR-ARP public networks SMDS

Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF int iplpdn 10.17487/RFC1433 RFC1434 Data Link Switching: Switch-to-Switch Protocol R. Dixon D. Kushi March 1993 ASCII 80182 33 PS 292006 PDF 181839 IBM SNA DLS SSP NetBIos

This RFC describes IBM's support of Data Link Switching over TCP/IP. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1795 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1434 RFC1435 IESG Advice from Experience with Path MTU Discovery S. Knowles March 1993 ASCII 2708 2 Maximum Transmission Unit

In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1435 RFC1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol) F. Anklesaria M. McCahill P. Lindner D. Johnson D. Torrey B. Albert March 1993 ASCII 36493 16 GOPHER information locating

This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1436 RFC1437 The Extension of MIME Content-Types to a New Medium N. Borenstein M. Linimon April 1 1993 ASCII 13356 6 life form Matter transport Sentient

This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1437 RFC1438 Internet Engineering Task Force Statements Of Boredom (SOBs) A. Lyman Chapin C. Huitema April 1 1993 ASCII 3044 2 process policy

This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1438 RFC1439 The Uniqueness of Unique Identifiers C. Finseth March 1993 ASCII 20477 11 names

This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1439 RFC1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer R. Troth July 1993 ASCII 17366 9 SIFT UFT Send FTP

This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1440 RFC1441 Introduction to version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 25386 13 SNMPv2 SNMP Management Framework

The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF snmpv2 10.17487/RFC1441 RFC1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 95779 56 SNMP Management Framework SMI

Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]

 RFC1902 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1442 RFC1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 60947 31 SNMP Management Framework

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

 RFC1903 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1443 RFC1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 57744 33 SNMP Management Framework

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

 RFC1904 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1444 RFC1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII 99443 48 SNMP Management Framework

It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1445 RFC1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII 108733 52 SNMP Management Framework

It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1446 RFC1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) K. McCloghrie J. Galvin April 1993 ASCII 80762 50 SNMP Management Framework

The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1447 RFC1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 74224 36 SNMP Management Framework

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

 RFC1905 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1448 RFC1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 41161 25 SNMP Management Framework

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

 RFC1906 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1449 RFC1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 42172 27 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

 RFC1907 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1450 RFC1451 Manager-to-Manager Management Information Base J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 62935 36 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF snmpv2 10.17487/RFC1451 RFC1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 32176 17 SNMP Management Framework

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

 RFC1908 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1452 RFC1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers W. Chimiak April 1993 ASCII 23563 10 XTP

This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1453 RFC1454 Comparison of Proposals for Next Version of IP T. Dixon May 1993 ASCII 35064 15 IPng PIP TUBA SIP

This is a slightly edited reprint of RARE Technical Report (RTC(93)004). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1454 RFC1455 Physical Link Security Type of Service D. Eastlake 3rd May 1993 ASCII 12391 6 TOS-LS TOS

This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community.

 RFC2474 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1455 RFC1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification Vietnamese Standardization Working Group May 1993 ASCII 14775 7 Character Set

This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1456 RFC1457 Security Label Framework for the Internet R. Housley May 1993 ASCII 35802 14

This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1457 RFC1458 Requirements for Multicast Protocols R. Braudes S. Zabele May 1993 ASCII 48106 19 Real-Time

This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1458 RFC1459 Internet Relay Chat Protocol J. Oikarinen D. Reed May 1993 ASCII 138964 65 IRCP IRC

The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. This memo defines an Experimental Protocol for the Internet community.

 RFC2810 RFC2811 RFC2812 RFC2813 RFC7194 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1459 10.17487/RFC1459 RFC1460 Post Office Protocol - Version 3 M. Rose June 1993 ASCII 38827 17 Email

This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]

 RFC1225 RFC1725 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1460 RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 D. Throop May 1993 ASCII 47945 21 X25-MIB

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 Multiprotocol Interconnect (including IP) traffic carried over X.25. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF x25mib 10.17487/RFC1461 RFC1462 FYI on "What is the Internet?" E. Krol E. Hoffman May 1993 ASCII 27811 11 Introduction

This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0020 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1462 RFC1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings E. Hoffman L. Jackson May 1993 ASCII 7116 4

This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0019 INFORMATIONAL INFORMATIONAL IETF userdoc2 10.17487/RFC1463 RFC1464 Using the Domain Name System To Store Arbitrary String Attributes R. Rosenbaum May 1993 ASCII 7953 4 DNS TXT

This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1464 RFC1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing D. Eppenberger May 1993 ASCII 66833 31 X400

This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1465 RFC1466 Guidelines for Management of IP Address Space E. Gerich May 1993 ASCII 22262 10 CIDR

This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1366 RFC2050 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1466 RFC1467 Status of CIDR Deployment in the Internet C. Topolcic August 1993 ASCII 20720 9 routing tables allocation registry IR IANA classless

This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1367 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1467 RFC1468 Japanese Character Encoding for Internet Messages J. Murai M. Crispin E. van der Poel June 1993 ASCII 10970 6 Set

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1468 RFC1469 IP Multicast over Token-Ring Local Area Networks T. Pusateri June 1993 ASCII 8189 4 IP-TR-MC 802.2 802.5

This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1469 RFC1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices R. Enger J. Reynolds June 1993 ASCII 308528 192 NOCTOOLS

The goal of this FYI memo is to provide an update to FYI 2, RFC 1147 [1], which provided practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1147 FYI0002 INFORMATIONAL INFORMATIONAL IETF noctool2 10.17487/RFC1470 RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 53558 25 PPP/LCP MIB Management Framework PPP

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 describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1471 RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 27152 13 PPP/SEC MIB Management Framework PPP

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 describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1472 RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 20484 10 PPP/IP MIB Management Framework PPP

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 describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1473 RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 31846 15 PPP/Bridge Management Framework PPP

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 describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1474 RFC1475 TP/IX: The Next Internet R. Ullmann June 1993 ASCII 77854 35 TP-IX IPv7 IPng

This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC6814 HISTORIC EXPERIMENTAL IETF int tpix 10.17487/RFC1475 RFC1476 RAP: Internet Route Access Protocol R. Ullmann June 1993 ASCII 45560 20 RAP Routing

This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF int tpix 10.17487/RFC1476 RFC1477 IDPR as a Proposed Standard M. Steenstrup July 1993 ASCII 32238 13 Routing Policy

This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1477 RFC1478 An Architecture for Inter-Domain Policy Routing M. Steenstrup June 1993 ASCII 90673 35 IDPR-ARCH IDPR

We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1478 RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 M. Steenstrup July 1993 ASCII 275823 108 IDPR IDPR

We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1479 RFC1480 The US Domain A. Cooper J. Postel June 1993 ASCII 100556 47 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1386 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1480 RFC1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling C. Huitema July 1993 ASCII 3502 2 CIDR

CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1481 RFC1482 Aggregation Support in the NSFNET Policy-Based Routing Database M. Knopper S. Richardson June 1993 ASCII 25330 11 CIDR

This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC INFORMATIONAL IETF bgpdepl 10.17487/RFC1482 RFC1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5 Juha Heinanen July 1993 ASCII 35192 16 ATM-ENCAP IP AAL5 over

This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK]

 RFC2684 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1483 RFC1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)) S. Hardcastle-Kille July 1993 ASCII 48974 25 X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1781 RFC3494 HISTORIC EXPERIMENTAL IETF app osids 10.17487/RFC1484 RFC1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)) S. Hardcastle-Kille July 1993 ASCII 11158 7 X.500 directory names representing names

When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. [STANDARDS-TRACK]

 RFC1779 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1485 RFC1486 An Experiment in Remote Printing M. Rose C. Malamud July 1993 ASCII 26373 14 electronic mail facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1528 RFC1529 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1486 RFC1487 X.500 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille July 1993 ASCII 44947 21 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

 RFC1777 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1487 RFC1488 The X.500 String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins July 1993 ASCII 17182 11 X.500 LDAP lightweight directory protocol

This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. [STANDARDS-TRACK]

 RFC1778 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1488 RFC1489 Registration of a Cyrillic Character Set A. Chernov July 1993 ASCII 7798 5

Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1489 RFC1490 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis July 1993 ASCII 75206 35 standard standards IP over

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU. [STANDARDS-TRACK]

 RFC1294 RFC2427 DRAFT STANDARD DRAFT STANDARD IETF int iplpdn 10.17487/RFC1490 RFC1491 A Survey of Advanced Usages of X.500 C. Weider R. Wright July 1993 ASCII 34883 18 directory

This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0021 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1491 RFC1492 An Access Control Protocol, Sometimes Called TACACS C. Finseth July 1993 ASCII 41880 21 TACACS Terminal Server TAC

This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1492 RFC1493 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie July 1993 ASCII 74493 34 BRIDGE-MIB SNMP MIB standard standards

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 MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. [STANDARDS-TRACK]

 RFC1286 RFC4188 DRAFT STANDARD DRAFT STANDARD IETF ops bridge 10.17487/RFC1493 RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies H. Alvestrand S. Thompson August 1993 ASCII 37273 19 Equiv Mail

This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1494 RFC1495 Mapping between X.400 and RFC-822 Message Bodies H. Alvestrand S. Kille R. Miles M. Rose S. Thompson August 1993 ASCII 20071 11 Mail

Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]

 RFC2156 RFC1327 PROPOSED STANDARD PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1495 RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages H. Alvestrand J. Romaguera K. Jordan August 1993 ASCII 8411 5 HARPOON Mail

This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1496 RFC1497 BOOTP Vendor Information Extensions J. Reynolds August 1993 ASCII 16805 8 TAGS Boot

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).

 RFC1395 RFC1084 RFC1048 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1497 RFC1498 On the Naming and Binding of Network Destinations J. Saltzer August 1993 ASCII 24698 10 NAMES Addresses Routes Objects Nodes Paths

This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1498 RFC1499 Summary of 1400-1499 J. Elliott January 1997 ASCII 40923 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1499 RFC1500 Internet Official Protocol Standards J. Postel August 1993 ASCII 79557 36 IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

 RFC1410 RFC1540 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1500 RFC1501 OS/2 User Group E. Brunsen August 1993 ASCII 3636 2

Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1501 RFC1502 X.400 Use of Extended Character Sets H. Alvestrand August 1993 ASCII 27976 14 Mail

This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1502 RFC1503 Algorithms for Automating Administration in SNMPv2 Managers K. McCloghrie M. Rose August 1993 ASCII 33542 14 Management SNMP

When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1503 RFC1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing A. Oppenheimer August 1993 ASCII 201553 82 AVRP

This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1504 RFC1505 Encoding Header Field for Internet Messages A. Costanzo D. Robinson R. Ullmann August 1993 ASCII 63796 36 EHF-MAIL Mail

This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1154 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1505 RFC1506 A Tutorial on Gatewaying between X.400 and Internet Mail J. Houttuin August 1993 ASCII 85550 39 822 email RTR

This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1506 RFC1507 DASS - Distributed Authentication Security Service C. Kaufman September 1993 ASCII 287809 119 DASS CAT

The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC1507 RFC1508 Generic Security Service Application Program Interface J. Linn September 1993 ASCII 111228 49 CAT,GSS,API

This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

 RFC2078 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1508 RFC1509 Generic Security Service API : C-bindings J. Wray September 1993 ASCII 99608 48 GSSAPI CAT,GSS

This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. [STANDARDS-TRACK]

 RFC2744 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1509 RFC1510 The Kerberos Network Authentication Service (V5) J. Kohl C. Neuman September 1993 ASCII 275395 112 KERBEROS CAT,Security

This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS-TRACK]

 RFC4120 RFC6649 HISTORIC PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=1510 10.17487/RFC1510 RFC1511 Common Authentication Technology Overview J. Linn September 1993 ASCII 4185 2 CAT,Security

This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1511 RFC1512 FDDI Management Information Base J. Case A. Rijsinghani September 1993 ASCII 108589 51 FDDI-MIB MIB SNMP

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 devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee.

 RFC1285 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1512 RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB S. Waldbusser September 1993 ASCII 121974 55 Monitoring SNMP

This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK]

 RFC1271 HISTORIC PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1513 RFC1514 Host Resources MIB P. Grillo S. Waldbusser September 1993 ASCII 63775 33 HOST-MIB Management SNMP

This memo defines a MIB for use with managing host systems. [STANDARDS-TRACK]

 RFC2790 PROPOSED STANDARD PROPOSED STANDARD IETF hostmib 10.17487/RFC1514 RFC1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) D. McMaster K. McCloghrie S. Roberts September 1993 ASCII 52828 25 MIB Management SNMP

This document 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 IEEE 802.3 Medium Attachment Units (MAUs). [STANDARDS-TRACK]

 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1515 RFC1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie September 1993 ASCII 82918 40 Management SNMP

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 IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs." [STANDARDS-TRACK]

 RFC1368 RFC2108 DRAFT STANDARD DRAFT STANDARD IETF ops hubmib 10.17487/RFC1516 RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) Internet Engineering Steering Group R. Hinden September 1993 ASCII 7357 4 CIDR Address

Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF IESG http://www.rfc-editor.org/errata_search.php?rfc=1517 10.17487/RFC1517 RFC1518 An Architecture for IP Address Allocation with CIDR Y. Rekhter T. Li September 1993 ASCII 72609 27 CIDR-ARCH Classless Routing

This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1518 RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan September 1993 ASCII 59998 24 CIDR-STRA]

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK]

 RFC1338 RFC4632 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1519 10.17487/RFC1519 RFC1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Y. Rekhter C. Topolcic September 1993 ASCII 20389 9 Classless Routing

The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1520 RFC1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed September 1993 ASCII 187424 81 PS 393670 PDF 205091 email multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK]

 RFC1341 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext 10.17487/RFC1521 RFC1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text K. Moore September 1993 ASCII 22502 10 email character

This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.

 RFC1342 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 DRAFT STANDARD DRAFT STANDARD IETF app 822ext 10.17487/RFC1522 RFC1523 The text/enriched MIME Content-type N. Borenstein September 1993 ASCII 32691 15 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1563 RFC1896 INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1523 RFC1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information N. Borenstein September 1993 ASCII 26464 12 MIME email mailcap

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1524 10.17487/RFC1524 RFC1525 Definitions of Managed Objects for Source Routing Bridges E. Decker K. McCloghrie P. Langille A. Rijsinghani September 1993 ASCII 38100 18 SRB-MIB MIB Management SNMP

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 source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]

 RFC1286 HISTORIC PROPOSED STANDARD IETF ops bridge 10.17487/RFC1525 RFC1526 Assignment of System Identifiers for TUBA/CLNP Hosts D. Piscitello September 1993 ASCII 16848 8 NSAP Address

This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF int tuba 10.17487/RFC1526 RFC1527 What Should We Plan Given the Dilemma of the Network? G. Cook September 1993 ASCII 46935 17

The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make? This memo is a shortened version of the suggested policy draft. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1527 RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures C. Malamud M. Rose October 1993 ASCII 18576 12 REM-PRINT FAX Facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1486 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1528 RFC1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies C. Malamud M. Rose October 1993 ASCII 11142 5 FAX Facsimile

This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1486 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1529 RFC1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy C. Malamud M. Rose October 1993 ASCII 15031 7 FAX Facsimile

This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1530 RFC1531 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII 96192 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK]

 RFC1541 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1531 10.17487/RFC1531 RFC1532 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII 51545 22 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

 RFC1542 RFC0951 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC1532 RFC1533 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms October 1993 ASCII 50919 30 Dynamic Host Configuration Bootstrap

This document specifies the current set of DHCP options. [STANDARDS-TRACK]

 RFC1497 RFC1395 RFC1084 RFC1048 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1533 10.17487/RFC1533 RFC1534 Interoperation Between DHCP and BOOTP R. Droms October 1993 ASCII 6966 4 DHCP-BOOTP Dynamic Host Configuration Bootstrap

DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK]

 DRAFT STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1534 10.17487/RFC1534 RFC1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software E. Gavron October 1993 ASCII 9722 5 Domain Name System

This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit. This document points out the flaw, a case in point, and a solution. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1535 10.17487/RFC1535 RFC1536 Common DNS Implementation Errors and Suggested Fixes A. Kumar J. Postel C. Neuman P. Danzig S. Miller October 1993 ASCII 25476 12 Domain Name System

This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1536 RFC1537 Common DNS Data File Configuration Errors P. Beertema October 1993 ASCII 19825 9 Domain Name System

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1912 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1537 RFC1538 Advanced SNA/IP : A Simple SNA Transport Protocol W. Behl B. Sterling W. Teskey October 1993 ASCII 21217 10 ADSNA-IP Domain Name System

This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1538 RFC1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force G. Malkin October 1993 ASCII 48199 22 Introduction

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

 RFC1391 RFC1718 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1539 RFC1540 Internet Official Protocol Standards J. Postel October 1993 ASCII 75496 34 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

 RFC1500 RFC1600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1540 RFC1541 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII 96950 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

 RFC1531 RFC2131 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1541 RFC1542 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII 52948 23 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

 RFC1532 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1542 10.17487/RFC1542 RFC1543 Instructions to RFC Authors J. Postel October 1993 ASCII 31383 16 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1111 RFC0825 RFC2223 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1543 RFC1544 The Content-MD5 Header Field M. Rose November 1993 ASCII 6478 3 MIME EMail Integrity MIC Digest

This memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. [STANDARDS-TRACK]

 RFC1864 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1544 RFC1545 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello November 1993 ASCII 8985 5 FTP File Transfer PORT PASV LPRT LPSV

This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). This is a general solution, applicable for all "next generation" IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1639 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1545 RFC1546 Host Anycasting Service C. Partridge T. Mendez W. Milliken November 1993 ASCII 22263 9 Resource Location Multicasting

This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC1546 RFC1547 Requirements for an Internet Standard Point-to-Point Protocol D. Perkins December 1993 ASCII 49810 21 PPP link serial line

This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1547 RFC1548 The Point-to-Point Protocol (PPP) W. Simpson December 1993 ASCII 111638 53 link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

 RFC1331 RFC1661 RFC1570 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1548 RFC1549 PPP in HDLC Framing W. Simpson Editor December 1993 ASCII 36352 18 point link serial line

This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK]

 RFC1662 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1549 RFC1550 IP: Next Generation (IPng) White Paper Solicitation S. Bradner A. Mankin December 1993 ASCII 12472 6

This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1550 RFC1551 Novell IPX Over Various WAN Media (IPXWAN) M. Allen December 1993 ASCII 54210 22 Internetworking Packet Exchange

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1551 RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) W. Simpson December 1993 ASCII 29173 16 IPXCP IPX point serial line link

This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1552 RFC1553 Compressing IPX Headers Over WAN Media (CIPX) S. Mathur M. Lewis December 1993 ASCII 47450 23 CIPX Internetworking Packet Exchange

This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1553 RFC1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP M. Ohta K. Handa December 1993 ASCII 11449 6 Character Set Japanese

This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1554 RFC1555 Hebrew Character Encoding for Internet Messages H. Nussbacher Y. Bourvine December 1993 ASCII 9273 5 Character Set

This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME [RFC1521] and ISO-8859-8. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1555 RFC1556 Handling of Bi-directional Texts in MIME H. Nussbacher December 1993 ASCII 5602 3 Character Set

This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1556 RFC1557 Korean Character Encoding for Internet Messages U. Choi K. Chon H. Park December 1993 ASCII 8736 5 Character Set

This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1557 RFC1558 A String Representation of LDAP Search Filters T. Howes December 1993 ASCII 5239 3 X.500 Directory

The Lightweight Directory Access Protocol (LDAP) defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1960 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1558 RFC1559 DECnet Phase IV MIB Extensions J. Saperia December 1993 ASCII 125427 69 DECNET-MIB Management SNMP

This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]

 RFC1289 DRAFT STANDARD DRAFT STANDARD IETF decnetiv 10.17487/RFC1559 RFC1560 The MultiProtocol Internet B. Leiner Y. Rekhter December 1993 ASCII 16651 7 Architecture Protocol

There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1560 RFC1561 Use of ISO CLNP in TUBA Environments D. Piscitello December 1993 ASCII 55902 25 CLNP-TUBA OSI IP Internet Protocol

This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses. It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1561 RFC1562 Naming Guidelines for the AARNet X.500 Directory Service G. Michaelson M. Prior December 1993 ASCII 6884 4 Australia

This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001). AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1562 RFC1563 The text/enriched MIME Content-type N. Borenstein January 1994 ASCII 32913 16 PS 73543 PDF 37459 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1523 RFC1896 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1563 RFC1564 DSA Metrics (OSI-DS 34 (v3)) P. Barker R. Hedberg January 1994 ASCII 46205 21 x.500 Directory Service Agent

This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1564 RFC1565 Network Services Monitoring MIB S. Kille N. Freed January 1994 ASCII 29761 17 Management Information Base

This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]

 RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1565 RFC1566 Mail Monitoring MIB S. Kille N. Freed January 1994 ASCII 33136 20 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]

 RFC2249 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1566 RFC1567 X.500 Directory Monitoring MIB G. Mansfield S. Kille January 1994 ASCII 33527 18 X500-MIB Management Information Base

This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. [STANDARDS-TRACK]

 RFC2605 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1567 RFC1568 Simple Network Paging Protocol - Version 1(b) A. Gwinn January 1994 ASCII 16558 8 Beeper

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1568 RFC1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose January 1994 ASCII 12597 6 Beeper

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1703 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1569 RFC1570 PPP LCP Extensions W. Simpson Editor January 1994 ASCII 35719 19 PPP-LCP Point-to Point Link Control Protocol serial line

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK]

 RFC1548 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1570 RFC1571 Telnet Environment Option Interoperability Issues D. Borman January 1994 ASCII 8117 4

This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1408 INFORMATIONAL INFORMATIONAL IETF app telnet 10.17487/RFC1571 RFC1572 Telnet Environment Option S. Alexander Editor January 1994 ASCII 14676 7 TOPT-ENVIR

This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1572 RFC1573 Evolution of the Interfaces Group of MIB-II K. McCloghrie F. Kastenholz January 1994 ASCII 123057 55 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK]

 RFC1229 RFC2233 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1573 RFC1574 Essential Tools for the OSI Internet S. Hares C. Wittbrodt February 1994 ASCII 27735 13 Echo Traceroute Routing Table CLNP

This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): ping or OSI Echo function, traceroute function which uses the OSI Echo function, and routing table dump function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1139 INFORMATIONAL INFORMATIONAL IETF noop 10.17487/RFC1574 RFC1575 An Echo Function for CLNP (ISO 8473) S. Hares C. Wittbrodt February 1994 ASCII 22479 9 ISO-TS-ECHO

This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473. [STANDARDS-TRACK]

 RFC1139 DRAFT STANDARD DRAFT STANDARD IETF noop 10.17487/RFC1575 RFC1576 TN3270 Current Practices J. Penner January 1994 ASCII 24477 12 Telnet Option Terminal Type EOR Binary

This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. This memo provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1576 RFC1577 Classical IP and ARP over ATM M. Laubach January 1994 ASCII 41239 17 Internet Protocol Address Resolution Asynchronous Transmission Mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

 RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1577 RFC1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions J. Sellers February 1994 ASCII 113646 53 K12

The goal of this FYI RFC is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 22]

 RFC1941 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1578 RFC1579 Firewall-Friendly FTP S. Bellovin February 1994 ASCII 8806 4 file transfer PORT PASV Security

This memo describes a suggested change to the behavior of FTP client programs. This document provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1579 RFC1580 Guide to Network Resource Tools EARN Staff March 1994 ASCII 235112 107 EARN BITNET Gopher World-Wide Web WWW WAIS Archie Whois X.500 Netfind Trickle BIFTP Listserv Netnews Astra NetServ Mail Base Prospero IRC Relay

The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23]

 FYI0023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1580 RFC1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII 7536 4 routing Protocol

As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1581 RFC1582 Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII 63271 29 RIP-DC routing Protocol

This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1582 RFC1583 OSPF Version 2 J. Moy March 1994 ASCII 532636 216 PS 990794 PDF 465711 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

 RFC1247 RFC2178 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1583 RFC1584 Multicast Extensions to OSPF J. Moy March 1994 ASCII 262463 102 PS 426358 PDF 243185 OSPF-Multi Open Shortest Path First

This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1584 RFC1585 MOSPF: Analysis and Experience J. Moy March 1994 ASCII 29754 13 Multicast Open Shortest Path First OSPF

This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1585 RFC1586 Guidelines for Running OSPF Over Frame Relay Networks O. deSouza M. Rodrigues March 1994 ASCII 14968 6 FR Open Shortest Path First

This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1586 RFC1587 The OSPF NSSA Option R. Coltun V. Fuller March 1994 ASCII 37412 17 OSPF-NSSA Open Shortest Path First not so stubby area routing protocol

This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]

 RFC3101 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1587 RFC1588 White Pages Meeting Report J. Postel C. Anderson February 1994 ASCII 77945 35 X-500 directory

This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1588 RFC1589 A Kernel Model for Precision Timekeeping D. Mills March 1994 ASCII 88129 37 Time NTP Clock

This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1589 RFC1590 Media Type Registration Procedure J. Postel March 1994 ASCII 13044 7 email multimedia

Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1521 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1590 RFC1591 Domain Name System Structure and Delegation J. Postel March 1994 ASCII 16481 7 DNS Policy Top-Level TLD

This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1591 RFC1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0 B. Wijnen G. Carpenter K. Curran A. Sehgal G. Waters March 1994 ASCII 135259 54 SNMP-DPI SNMP DPT IBM

This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1228 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1592 RFC1593 SNA APPN Node MIB W. McKenzie J. Cheng March 1994 ASCII 207882 120 IBM Management

This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1593 RFC1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions A. Marine J. Reynolds G. Malkin March 1994 ASCII 98753 44 documentation help information FAQ

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 4]

 RFC1325 RFC2664 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1594 RFC1595 Definitions of Managed Objects for the SONET/SDH Interface Type T. Brown K. Tesink March 1994 ASCII 121937 59 SONET-MIB MIB Management SNMP RFC2558 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1595 RFC1596 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII 88795 46 FR MIB Management SNMP RFC1604 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC1596 RFC1597 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. de Groot March 1994 ASCII 17430 8 IP Network Number Local

This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1597 RFC1598 PPP in X.25 W. Simpson March 1994 ASCII 13835 8 PPP-X25 point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1598 RFC1599 Summary of 1500-1599 M. Kennedy January 1997 ASCII 43761 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1599 RFC1600 Internet Official Protocol Standards J. Postel March 1994 ASCII 80958 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1540 RFC1610 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1600 RFC1601 Charter of the Internet Architecture Board (IAB) C. Huitema March 1994 ASCII 12424 6 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1358 RFC2850 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1601 RFC1602 The Internet Standards Process -- Revision 2 Internet Architecture Board Internet Engineering Steering Group March 1994 ASCII 88465 37

This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1310 RFC2026 RFC1871 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1602 RFC1603 IETF Working Group Guidelines and Procedures E. Huizer D. Crocker March 1994 ASCII 63900 29 WG

This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2418 RFC1871 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1603 RFC1604 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII 88770 46 FR-MIB MIB Management SNMP Network

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

 RFC1596 RFC2954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1604 RFC1605 SONET to Sonnet Translation W. Shakespeare April 1 1994 ASCII 4451 3 Humor

Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation (SONNET). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1605 RFC1606 A Historical Perspective On The Usage Of IP Version 9 J. Onions April 1 1994 ASCII 8398 4 Humor

This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1606 RFC1607 A VIEW FROM THE 21ST CENTURY V. Cerf April 1 1994 ASCII 28165 14 V. Cerf

This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1607 RFC1608 Representing IP Information in the X.500 Directory T. Johannsen G. Mansfield M. Kosters S. Sataluri March 1994 ASCII 40269 20 X500-DIR Data Structure Schemo

This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1608 RFC1609 Charting Networks in the X.500 Directory G. Mansfield T. Johannsen M. Knopper March 1994 ASCII 30044 15 X500-CHART Data Structure Schemo

This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app osids http://www.rfc-editor.org/errata_search.php?rfc=1609 10.17487/RFC1609 RFC1610 Internet Official Protocol Standards J. Postel July 1994 ASCII 81346 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1600 RFC1720 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1610 RFC1611 DNS Server MIB Extensions R. Austein J. Saperia May 1994 ASCII 58700 30 DNS-S-MIB Domain Name System Management Information Base

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 a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1611 RFC1612 DNS Resolver MIB Extensions R. Austein J. Saperia May 1994 ASCII 61382 32 DNS-R-MIB Domain Name System Management Information Base

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 a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1612 RFC1613 cisco Systems X.25 over TCP (XOT) J. Forster G. Satz G. Glick R. Day May 1994 ASCII 29267 13 Transmission Control Protocol

This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1613 RFC1614 Network Access to Multimedia Information C. Adie May 1994 ASCII 187253 79 RARE Technical Report

This report summarises the requirements of research and academic network users for network access to multimedia information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv imm 10.17487/RFC1614 RFC1615 Migrating from X.400(84) to X.400(88) J. Houttuin J. Craigie May 1994 ASCII 39693 17 RARE Technical Report email

This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1615 RFC1616 X.400(1988) for the Academic and Research Community in Europe RARE WG-MSG Task Force 88 E. Huizer Editor J. Romaguera Editor May 1994 ASCII 107432 44 RARE Technical Report email

The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1616 RFC1617 Naming and Structuring Guidelines for X.500 Directory Pilots P. Barker S. Kille T. Lenggenhager May 1994 ASCII 56739 28 RARE Technical Report White Pages

This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1384 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1617 RFC1618 PPP over ISDN W. Simpson May 1994 ASCII 14896 7 PPP-ISDN Point Integrated Services Digital Network

This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1618 RFC1619 PPP over SONET/SDH W. Simpson May 1994 ASCII 8893 5 PPP-SONET Point Synchronous Optical Network Digital Heirarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS-TRACK]

 RFC2615 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1619 RFC1620 Internet Architecture Extensions for Shared Media B. Braden J. Postel Y. Rekhter May 1994 ASCII 44999 19 Public data networks ARP address resolution protocol

This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1620 RFC1621 Pip Near-term Architecture P. Francis May 1994 ASCII 128905 51 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Header Processing" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pip 10.17487/RFC1621 RFC1622 Pip Header Processing P. Francis May 1994 ASCII 34837 16 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Near-term Architecture" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pip 10.17487/RFC1622 RFC1623 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz May 1994 ASCII 38745 19 MIB Management Information Base

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 ethernet-like objects. [STANDARDS-TRACK]

 RFC1398 RFC1643 HISTORIC INTERNET STANDARD IETF int ifmib 10.17487/RFC1623 RFC1624 Computation of the Internet Checksum via Incremental Update A. Rijsinghani Editor May 1994 ASCII 9836 6

This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1141 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1624 10.17487/RFC1624 RFC1625 WAIS over Z39.50-1988 M. St. Pierre J. Fullton K. Gamiel J. Goldman B. Kahle J. Kunze H. Morris F. Schiettecatte June 1994 ASCII 14694 7 Wide Area Information Servers Library

The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1625 RFC1626 Default IP MTU for use over ATM AAL5 R. Atkinson May 1994 ASCII 11841 5 Maximum Transmission Unit Asynchronous Transfer Mode Adaptation Layer Size Packet

There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]

 RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1626 RFC1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified) E. Lear E. Fair D. Crocker T. Kessler July 1994 ASCII 18823 8 IP Network Number Local

This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1627 RFC1628 UPS Management Information Base J. Case Editor May 1994 ASCII 83439 45 UPS-MIB Uninterruptible Power Supply 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 uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]

 INFORMATIONAL PROPOSED STANDARD IETF ops upsmib http://www.rfc-editor.org/errata_search.php?rfc=1628 10.17487/RFC1628 RFC1629 Guidelines for OSI NSAP Allocation in the Internet R. Colella R. Callon E. Gardner Y. Rekhter May 1994 ASCII 131640 52 OSI-NSAP CLNP Address

This paper provides guidelines for allocating NSAP addresses in the Internet. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK]

 RFC1237 DRAFT STANDARD DRAFT STANDARD IETF osinsap 10.17487/RFC1629 RFC1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web T. Berners-Lee June 1994 ASCII 57601 28 World Wide Web URI

This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1630 RFC1631 The IP Network Address Translator (NAT) K. Egevang P. Francis May 1994 ASCII 22714 10 Internet Protocol

This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3022 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1631 RFC1632 A Revised Catalog of Available X.500 Implementations A. Getchell Editor S. Sataluri Editor May 1994 ASCII 124111 94 Directory White Pages

This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1292 RFC2116 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1632 RFC1633 Integrated Services in the Internet Architecture: an Overview R. Braden D. Clark S. Shenker June 1994 ASCII 89691 33 PS 207016 PDF 201858 real time Multi-media reservations Protocol

This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1633 10.17487/RFC1633 RFC1634 Novell IPX Over Various WAN Media (IPXWAN) M. Allen May 1994 ASCII 55347 23 wide area network

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1551 RFC1362 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1634 RFC1635 How to Use Anonymous FTP P. Deutsch A. Emtage A. Marine May 1994 ASCII 27258 13 File Transfer Protocol

This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0024 INFORMATIONAL INFORMATIONAL IETF iafa 10.17487/RFC1635 RFC1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994 R. Braden D. Clark S. Crocker C. Huitema June 1994 ASCII 130761 52 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1636 RFC1637 DNS NSAP Resource Records B. Manning R. Colella June 1994 ASCII 21768 11 domain Name System ISO OSI Address

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. This memo defines an Experimental Protocol for the Internet community.

 RFC1348 RFC1706 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1637 RFC1638 PPP Bridging Control Protocol (BCP) F. Baker R. Bowen June 1994 ASCII 58477 28 PPP-BCP Point to Point

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

 RFC1220 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1638 RFC1639 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello June 1994 ASCII 10055 5 FOOBAR File Transfer Port

This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a <long-host-port>, which allows for additional address families, variable length network addresses and variable length port numbers. This memo defines an Experimental Protocol for the Internet community.

 RFC1545 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1639 RFC1640 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker June 1994 ASCII 21780 10 IETF IESG IAB ISOC

This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1640 RFC1641 Using Unicode with MIME D. Goldsmith M. Davis July 1994 ASCII 11258 6 PS 20451 PDF 11658 MIME-UNI Multipurpose Internet Mail Extension Character Set

This document specifies the usage of Unicode within MIME. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1641 RFC1642 UTF-7 - A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis July 1994 ASCII 27770 14 PS 50907 PDF 29573 character Set

This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. This memo defines an Experimental Protocol for the Internet community.

 RFC2152 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1642 RFC1643 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz July 1994 ASCII 39008 19 ETHER-MIB MIB Network Management SNMP Ethernet

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 ethernet-like objects. [STANDARDS-TRACK]

 RFC1623 RFC3638 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1643 RFC1644 T/TCP -- TCP Extensions for Transactions Functional Specification R. Braden July 1994 ASCII 87362 38 T/TCP Transmission Control Protocol

This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This memo describes an Experimental Protocol for the Internet community.

 RFC6247 RFC1379 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1644 RFC1645 Simple Network Paging Protocol - Version 2 A. Gwinn July 1994 ASCII 31243 15 Beeper SNPP Mail

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1568 RFC1861 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1645 RFC1646 TN3270 Extensions for LUname and Printer Selection C. Graves T. Butts M. Angel July 1994 ASCII 27564 13 Telnet Option

This document describes protocol extensions to TN3270. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1646 RFC1647 TN3270 Enhancements B. Kelly July 1994 ASCII 84420 34 Telnet Option

This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK]

 RFC2355 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC1647 RFC1648 Postmaster Convention for X.400 Operations A. Cargille July 1994 ASCII 8761 4 Mail

This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1648 RFC1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community R. Hagens A. Hansen July 1994 ASCII 28138 14 Mail Global Open Message Handling System

The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app x400ops 10.17487/RFC1649 RFC1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 F. Kastenholz August 1994 ASCII 40484 20 MIB Management Information Base 802.3

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 ethernet-like objects. [STANDARDS-TRACK]

 RFC2358 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1650 RFC1651 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII 22153 11 Mail Simple Transfer

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

 RFC1425 RFC1869 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1651 RFC1652 SMTP Service Extension for 8bit-MIMEtransport J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII 11842 6 SMTP Mail Simple Transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

 RFC1426 RFC6152 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1652 RFC1653 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore July 1994 ASCII 17883 8 Mail Simple Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

 RFC1427 RFC1870 DRAFT STANDARD DRAFT STANDARD IETF app smtpext 10.17487/RFC1653 RFC1654 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter Editor T. Li Editor July 1994 ASCII 130118 56 routing

This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1771 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1654 RFC1655 Application of the Border Gateway Protocol in the Internet Y. Rekhter Editor P. Gross Editor July 1994 ASCII 43664 19 BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1268 RFC1772 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1655 RFC1656 BGP-4 Protocol Document Roadmap and Implementation Experience P. Traina July 1994 ASCII 7705 4 Border Gateway Protocol Routing

Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1773 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1656 RFC1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 S. Willis J. Burruss J. Chu Editor July 1994 ASCII 45505 21 BGP-4-MIB MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]

 RFC4273 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC1657 RFC1658 Definitions of Managed Objects for Character Stream Devices using SMIv2 B. Stewart July 1994 ASCII 32579 18 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]

 RFC1316 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1658 RFC1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII 36479 21 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

 RFC1317 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1659 RFC1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII 16784 10 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]

 RFC1318 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1660 RFC1661 The Point-to-Point Protocol (PPP) W. Simpson Editor July 1994 ASCII 103026 53 PPP Specification Standard link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

 RFC1548 RFC2153 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1661 10.17487/RFC1661 RFC1662 PPP in HDLC-like Framing W. Simpson Editor July 1994 ASCII 48058 26 PPP-HDLC Point Protocol Specification Standard link serial line

This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK]

 RFC1549 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1662 10.17487/RFC1662 RFC1663 PPP Reliable Transmission D. Rand July 1994 ASCII 17281 8 PPP-TRANS Point Protocol

This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1663 RFC1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables C. Allocchio A. Bonito B. Cole S. Giordano R. Hagens August 1994 ASCII 50783 23 domain Name System X.400 Email

This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. This memo defines an Experimental Protocol for the Internet community.

 RFC2163 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1664 RFC1665 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski Editor D. Kostick Editor K. Shih Editor July 1994 ASCII 133381 67 MIB Management Information Base System Network Architecture Addressable Units

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 the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

 RFC1666 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC1665 RFC1666 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski Editor D. Kostick Editor K. Shih Editor August 1994 ASCII 134385 68 SNANAU-MIB Network Management SNMP MIB Protocol Units Architecture Addressable Information System

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 the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

 RFC1665 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1666 RFC1667 Modeling and Simulation Requirements for IPng S. Symington D. Wood M. Pullen August 1994 ASCII 17291 7 White Paper

This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1667 RFC1668 Unified Routing Requirements for IPng D. Estrin T. Li Y. Rekhter August 1994 ASCII 5106 3 White Paper

The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1668 RFC1669 Market Viability as a IPng Criteria J. Curran August 1994 ASCII 8099 4 White Paper

"Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1669 RFC1670 Input to IPng Engineering Considerations D. Heagerty August 1994 ASCII 5350 3 White Paper

This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition. It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1670 RFC1671 IPng White Paper on Transition and Other Considerations B. Carpenter August 1994 ASCII 17631 8

This white paper outlines some general requirements for IPng in selected areas. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1671 RFC1672 Accounting Requirements for IPng N. Brownlee August 1994 ASCII 6185 3 White Paper

This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1672 RFC1673 Electric Power Research Institute Comments on IPng R. Skelton August 1994 ASCII 7476 4 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1673 RFC1674 A Cellular Industry View of IPng M. Taylor August 1994 ASCII 6157 3 White Paper

This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1674 RFC1675 Security Concerns for IPng S. Bellovin August 1994 ASCII 8290 4 White Paper

A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1675 RFC1676 INFN Requirements for an IPng A. Ghiselli D. Salomoni C. Vistoli August 1994 ASCII 8493 4 White Paper

With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1676 RFC1677 Tactical Radio Frequency Communication Requirements for IPng B. Adamson August 1994 ASCII 24065 9 White Paper

This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1677 RFC1678 IPng Requirements of Large Corporate Networks E. Britton J. Tavs August 1994 ASCII 18650 8 White Paper

This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1678 RFC1679 HPN Working Group Input to the IPng Requirements Solicitation D. Green P. Irey D. Marlow K. O'Donoghue August 1994 ASCII 22974 10 White Paper

The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1679 RFC1680 IPng Support for ATM Services C. Brazdziunas August 1994 ASCII 17846 7 White Paper

This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1680 RFC1681 On Many Addresses per Host S. Bellovin August 1994 ASCII 11964 5 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1681 RFC1682 IPng BSD Host Implementation Analysis J. Bound August 1994 ASCII 22295 10 White Paper Unix

This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1682 RFC1683 Multiprotocol Interoperability In IPng R. Clark M. Ammar K. Calvert August 1994 ASCII 28201 12 White Paper

In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1683 RFC1684 Introduction to White Pages Services based on X.500 P. Jurg August 1994 ASCII 22985 10 Directory

The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1684 RFC1685 Writing X.400 O/R Names H. Alvestrand August 1994 ASCII 21242 11 EMail Mail

There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind.

 RTR0012 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1685 10.17487/RFC1685 RFC1686 IPng Requirements: A Cable Television Industry Viewpoint M. Vecchi August 1994 ASCII 39052 14 White Paper

This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1686 RFC1687 A Large Corporate User's View of IPng E. Fleischman August 1994 ASCII 34120 13 White Paper

The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1687 RFC1688 IPng Mobility Considerations W. Simpson August 1994 ASCII 19151 9 White Paper

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1688 RFC1689 A Status Report on Networked Information Retrieval: Tools and Groups J. Foster Editor August 1994 ASCII 375469 226 NIR

The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0025 INFORMATIONAL INFORMATIONAL IETF nir 10.17487/RFC1689 RFC1690 Introducing the Internet Engineering and Planning Group (IEPG) G. Huston August 1994 ASCII 3013 2 charter

This memo introduces the IEPG to the Internet Community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1690 RFC1691 The Document Architecture for the Cornell Digital Library W. Turner August 1994 ASCII 20438 10

This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1691 RFC1692 Transport Multiplexing Protocol (TMux) P. Cameron D. Crocker D. Cohen J. Postel August 1994 ASCII 26163 12 TMUX Internet Protocol IP

This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1692 RFC1693 An Extension to TCP : Partial Order Service T. Connolly P. Amer P. Conrad November 1994 ASCII 90100 36 TCP-POS Transmission Control Protocol

This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. This memo defines an Experimental Protocol for the Internet community.

 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1693 RFC1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2 T. Brown Editor K. Tesink Editor August 1994 ASCII 70856 35 SIP-MIB Standard,MIB,Network,Management,Switched,Multimegabit,Data,Service,Informatiom,Base,SMDS

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 objects for SMDS access interfaces. [STANDARDS-TRACK]

 RFC1304 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1694 RFC1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 M. Ahmed Editor K. Tesink Editor August 1994 ASCII 175461 73 ATM-MIB MIB Management,Information,Base,Asychronous,Transmission,Mode

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 used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

 RFC2515 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1695 RFC1696 Modem Management Information Base (MIB) using SMIv2 J. Barnes L. Brown R. Royston S. Waldbusser August 1994 ASCII 54054 31 MODEM-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 used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF modemmgt 10.17487/RFC1696 RFC1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 D. Brower Editor B. Purvy A. Daniel M. Sinykin J. Smith August 1994 ASCII 76202 38 RDBMS-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 used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rdbmsmib 10.17487/RFC1697 RFC1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications P. Furniss October 1994 ASCII 67433 29 Protocol Headers

This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF thinosi 10.17487/RFC1698 RFC1699 Summary of 1600-1699 J. Elliott January 1997 ASCII 40674 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1699 RFC1700 Assigned Numbers J. Reynolds J. Postel October 1994 ASCII 458860 230 status procedure index parameters registered allocated

This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

 RFC1340 RFC3232 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1700 RFC1701 Generic Routing Encapsulation (GRE) S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII 15460 8 GRE Internet Protocol IP

This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1701 RFC1702 Generic Routing Encapsulation over IPv4 networks S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII 7288 4 GRE-IPv4 Internet Protocol IP

This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1702 RFC1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose October 1994 ASCII 17985 9 RADIO-PAGE Beepers

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1569 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1703 RFC1704 On Internet Authentication N. Haller R. Atkinson October 1994 ASCII 42269 17 Security Energyption Policy Guidelines

This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1704 RFC1705 Six Virtual Inches to the Left: The Problem with IPng R. Carlson D. Ficarella October 1994 ASCII 65222 27 IPng White paper

This document was submitted to the IETF IPng area in response to RFC 1550. This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1705 RFC1706 DNS NSAP Resource Records B. Manning R. Colella October 1994 ASCII 19721 10 DNS-NSAP Domain Name System ISO OSI Address RR Record Resource

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1637 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1706 RFC1707 CATNIP: Common Architecture for the Internet M. McGovern R. Ullmann October 1994 ASCII 37568 16 IPng White Paper IPv7

This document was submitted to the IETF IPng area in response to RFC 1550. This paper describes a common architecture for the network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1707 RFC1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3 D. Gowin October 1994 ASCII 26523 13

This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1708 RFC1709 K-12 Internetworking Guidelines J. Gargano D. Wasley November 1994 ASCII 66659 26 PS 662030 PDF 134065 school network education connection

The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0026 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1709 RFC1710 Simple Internet Protocol Plus White Paper R. Hinden October 1994 ASCII 56910 23 SIPP IPng

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF sipp 10.17487/RFC1710 RFC1711 Classifications in E-mail Routing J. Houttuin October 1994 ASCII 47584 19 Email Electronic Mail

This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1711 RFC1712 DNS Encoding of Geographical Location C. Farrell M. Schulze S. Pleitner D. Baldoni November 1994 ASCII 13237 7 DNS-ENCODE Domain Names System GPOS

This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1712 10.17487/RFC1712 RFC1713 Tools for DNS debugging A. Romao November 1994 ASCII 33500 13 Domain Names System Host DNSWalk DOC DDT Checker

Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0027 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1713 RFC1714 Referral Whois Protocol (RWhois) S. Williamson M. Kosters November 1994 ASCII 85395 46 PS 204207 PDF 85556 White Pages Directory

This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2167 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1714 RFC1715 The H Ratio for Address Assignment Efficiency C. Huitema November 1994 ASCII 7392 4 IPng White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3194 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1715 RFC1716 Towards Requirements for IP Routers P. Almquist F. Kastenholz November 1994 ASCII 432330 192 Gateway Internet Protocol

The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1812 INFORMATIONAL INFORMATIONAL IETF rtg rreq 10.17487/RFC1716 RFC1717 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr November 1994 ASCII 46264 21 Point

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

 RFC1990 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1717 RFC1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force IETF Secretariat G. Malkin November 1994 ASCII 50458 23 Internet Engineering Task Force Meeting

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

 RFC1539 RFC3160 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1718 RFC1719 A Direction for IPng P. Gross December 1994 ASCII 11118 6 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1719 RFC1720 Internet Official Protocol Standards J. Postel November 1994 ASCII 89063 41 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1610 RFC1780 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1720 RFC1721 RIP Version 2 Protocol Analysis G. Malkin November 1994 ASCII 6680 4 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1387 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1721 RFC1722 RIP Version 2 Protocol Applicability Statement G. Malkin November 1994 ASCII 10236 5 RIP2-APP RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet. This report is a prerequisite to advancing RIP-2 on the standards track. [STANDARDS-TRACK]

 STD0057 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1722 RFC1723 RIP Version 2 - Carrying Additional Information G. Malkin November 1994 ASCII 18597 9 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), o expand the amount of useful information carried in RIP messages and to add a measure of security. This memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" STD 34, RFC 1058. [STANDARDS-TRACK]

 RFC1388 RFC2453 RFC1058 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1723 RFC1724 RIP Version 2 MIB Extension G. Malkin F. Baker November 1994 ASCII 29645 18 RIP2-MIB RIP-2 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 RIP Version 2. [STANDARDS-TRACK]

 RFC1389 DRAFT STANDARD DRAFT STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=1724 10.17487/RFC1724 RFC1725 Post Office Protocol - Version 3 J. Myers M. Rose November 1994 ASCII 35058 18 POP Email Electronic Mail

This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]

 RFC1460 RFC1939 INTERNET STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1725 10.17487/RFC1725 RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng) C. Partridge F. Kastenholz December 1994 ASCII 74109 31 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1726 RFC1727 A Vision of an Integrated Internet Information Service C. Weider P. Deutsch December 1994 ASCII 28468 11 Universal Resource Names

This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1727 RFC1728 Resource Transponders C. Weider December 1994 ASCII 12092 6 Universal Resource Names Location System

This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1728 RFC1729 Using the Z39.50 Information Retrieval Protocol C. Lynch December 1994 ASCII 20927 8 Basic Endcoding Rules ASN1

This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1729 RFC1730 Internet Message Access Protocol - Version 4 M. Crispin December 1994 ASCII 156660 77 IMAP IMAP4 EMail

The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server. [STANDARDS-TRACK]

 RFC2060 RFC2061 PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1730 RFC1731 IMAP4 Authentication Mechanisms J. Myers December 1994 ASCII 11433 6 IMAP4-AUTH Internet Message Access Protocol Email

The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1731 RFC1732 IMAP4 Compatibility with IMAP2 and IMAP2bis M. Crispin December 1994 ASCII 9276 5 Internet Message Access Protocol Email

This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1732 RFC1733 Distributed Electronic Mail Models in IMAP4 M. Crispin December 1994 ASCII 6205 3 Internet Message Access Protocol Email

There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1733 RFC1734 POP3 AUTHentication command J. Myers December 1994 ASCII 8499 5 POP3-AUTH Post Office Protocol Email

This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]

 RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1734 RFC1735 NBMA Address Resolution Protocol (NARP) J. Heinanen R. Govindan December 1994 ASCII 24485 11 NARP Non-Broadcast Multi Access Address Resolution Protocol

This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF rtg rolc 10.17487/RFC1735 RFC1736 Functional Recommendations for Internet Resource Locators J. Kunze February 1995 ASCII 22415 10 Uniform Resource URL

This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1736 RFC1737 Functional Requirements for Uniform Resource Names K. Sollins L. Masinter December 1994 ASCII 16337 7

This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1737 RFC1738 Uniform Resource Locators (URL) T. Berners-Lee L. Masinter M. McCahill December 1994 ASCII 51348 25 URL

This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]

 RFC4248 RFC4266 RFC1808 RFC2368 RFC2396 RFC3986 RFC6196 RFC6270 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1738 10.17487/RFC1738 RFC1739 A Primer On Internet and TCP/IP Tools G. Kessler S. Shepard December 1994 ASCII 102676 46 NSlookup PING FINGER TRACEROUTE FTP TELNET WHOIS NICNAME KNOWBOT NETFIND ARCHIE Gopher Email Mailing Lists USENET

This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2151 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1739 RFC1740 MIME Encapsulation of Macintosh Files - MacMIME P. Faltstrom D. Crocker E. Fair December 1994 ASCII 31297 16 MacMIME Multipurpose Internet Mail Extensions

This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1740 RFC1741 MIME Content Type for BinHex Encoded Files P. Faltstrom D. Crocker E. Fair December 1994 ASCII 10155 6 BINHEX Multipurpose Internet Mail Extensions

This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1741 RFC1742 AppleTalk Management Information Base II S. Waldbusser K. Frisa January 1995 ASCII 168306 84 AT-MIB

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 AppleTalk networks. [STANDARDS-TRACK]

 RFC1243 HISTORIC PROPOSED STANDARD IETF int appleip 10.17487/RFC1742 RFC1743 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII 43224 25 Management Information Base SNMP,

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

 RFC1231 RFC1748 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1743 RFC1744 Observations on the Management of the Internet Address Space G. Huston December 1994 ASCII 32411 12 IP Internet Protocol

This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1744 RFC1745 BGP4/IDRP for IP---OSPF Interaction K. Varadhan S. Hares Y. Rekhter December 1994 ASCII 43675 19 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1745 RFC1746 Ways to Define User Expectations B. Manning D. Perkins December 1994 ASCII 46164 18

This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1746 RFC1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2 J. Hilgeman Chair S. Nix A. Bartky W. Clark Editor January 1995 ASCII 147388 67 SDLCSMIv2

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg snadlc 10.17487/RFC1747 RFC1748 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII 43224 25 802.5-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

 RFC1743 RFC1231 RFC1749 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1748 RFC1749 IEEE 802.5 Station Source Routing MIB using SMIv2 K. McCloghrie F. Baker E. Decker December 1994 ASCII 17563 10 802.5-SSR Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]

 RFC1748 HISTORIC PROPOSED STANDARD IETF int ifmib 10.17487/RFC1749 RFC1750 Randomness Recommendations for Security D. Eastlake 3rd S. Crocker J. Schiller December 1994 ASCII 73842 30 Random Numbers Seed

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC4086 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1750 RFC1751 A Convention for Human-Readable 128-bit Keys D. McDonald December 1994 ASCII 31428 15 Security Password

This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1751 10.17487/RFC1751 RFC1752 The Recommendation for the IP Next Generation Protocol S. Bradner A. Mankin January 1995 ASCII 127784 52 IPNG IPng Internet

This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1752 RFC1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture N. Chiappa December 1994 ASCII 46586 18 IPng White Paper Internet Protocol

This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1753 RFC1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1 M. Laubach January 1995 ASCII 13483 7 Internet Asynchromous Transfer Mode

This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1754 RFC1755 ATM Signaling Support for IP over ATM M. Perez F. Liaw A. Mankin E. Hoffman D. Grossman A. Malis February 1995 ASCII 55209 32 ATM Asynchronous Transfer Mode

This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1755 RFC1756 Remote Write Protocol - Version 1.0 T. Rinne January 1995 ASCII 22078 11 RWP Application

This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1756 RFC1757 Remote Network Monitoring Management Information Base S. Waldbusser February 1995 ASCII 208117 91 RMON-MIB MIB RMON

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 RFC1271 RFC2819 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib 10.17487/RFC1757 RFC1758 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1995 ASCII 7294 4 X.500 North American Directory Forum Public CCITT Providers

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1758 RFC1759 Printer MIB R. Smith F. Wright T. Hastings S. Zilles J. Gyllenskog March 1995 ASCII 239228 113 Print-MIB Management Information Base

A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]

 RFC3805 PROPOSED STANDARD PROPOSED STANDARD IETF app printmib 10.17487/RFC1759 RFC1760 The S/KEY One-Time Password System N. Haller February 1995 ASCII 31124 12 Security

This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1760 RFC1761 Snoop Version 2 Packet Capture File Format B. Callaghan R. Gilligan February 1995 ASCII 10761 6 SNOOP Measurement debugging collecting data

This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1761 RFC1762 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum March 1995 ASCII 12709 7 PPP-DNCP Point Digital Equipment Corporation

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). [STANDARDS-TRACK]

 RFC1376 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1762 RFC1763 The PPP Banyan Vines Control Protocol (BVCP) S. Senum March 1995 ASCII 17817 10 BVCP Point

This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1763 RFC1764 The PPP XNS IDP Control Protocol (XNSCP) S. Senum March 1995 ASCII 9525 5 XNSCP Point Xerox Network Internetwork Datagram Service

This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1764 RFC1765 OSPF Database Overflow J. Moy March 1995 ASCII 21613 9 OSPF-OVFL

This memo details a way of gracefully handling unanticipated database overflows. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC1765 RFC1766 Tags for the Identification of Languages H. Alvestrand March 1995 ASCII 16966 9 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK]

 RFC3066 RFC3282 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1766 RFC1767 MIME Encapsulation of EDI Objects D. Crocker March 1995 ASCII 15293 7 MIME-EDI Electronic Data Interchange Multipurpose Internet Mail Extensions delivery mechanism encapsulation

Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app edi 10.17487/RFC1767 RFC1768 Host Group Extensions for CLNP Multicasting D. Marlow March 1995 ASCII 111499 45 CLNP-MULT ISO OSI

This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1768 RFC1769 Simple Network Time Protocol (SNTP) D. Mills March 1995 ASCII 34454 14 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1361 RFC2030 RFC4330 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1769 RFC1770 IPv4 Option for Sender Directed Multi-Destination Delivery C. Graff March 1995 ASCII 11606 6 SDMD

This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1770 RFC1771 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter T. Li March 1995 ASCII 131903 57 BGP-4 routing

This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1654 RFC4271 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1771 10.17487/RFC1771 RFC1772 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross March 1995 ASCII 43916 19 BGP-4-APP BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

 RFC1655 DRAFT STANDARD DRAFT STANDARD IETF rtg bgp 10.17487/RFC1772 RFC1773 Experience with the BGP-4 protocol P. Traina March 1995 ASCII 19936 9 BGP-4 Border Gateway Protocol Routing

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1656 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1773 RFC1774 BGP-4 Protocol Analysis P. Traina Editor March 1995 ASCII 23823 10 Border Gateway Routing

The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1774 10.17487/RFC1774 RFC1775 To Be "On" the Internet D. Crocker March 1995 ASCII 8454 4 access full Client Mediated Messaging

The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1775 RFC1776 The Address is the Message S. Crocker April 1 1995 ASCII 2051 2 IPng

Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1776 RFC1777 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille March 1995 ASCII 45459 22 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP).This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself. [STANDARDS-TRACK]

 RFC1487 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1777 RFC1778 The String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins March 1995 ASCII 19053 12 X.500 LDAP lightweight directory protocol

The Lightweight Directory Access Protocol (LDAP) requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes. [STANDARDS-TRACK]

 RFC1488 RFC3494 RFC2559 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1778 RFC1779 A String Representation of Distinguished Names S. Kille March 1995 ASCII 12429 8 STR-REP X.500 directory names representing names

The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. [STANDARDS-TRACK]

 RFC1485 RFC2253 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1779 RFC1780 Internet Official Protocol Standards J. Postel Editor March 1995 ASCII 86594 39 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1720 RFC1800 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1780 RFC1781 Using the OSI Directory to Achieve User Friendly Naming S. Kille March 1995 ASCII 47129 26 OSI-Dir X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. [STANDARDS-TRACK]

 RFC1484 RFC3494 HISTORIC PROPOSED STANDARD IETF app asid 10.17487/RFC1781 RFC1782 TFTP Option Extension G. Malkin A. Harkin March 1995 ASCII 11508 6 trivial file transfer booting

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.

 RFC2347 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1782 RFC1783 TFTP Blocksize Option G. Malkin A. Harkin March 1995 ASCII 7814 5 trivial file transfer booting

This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

 RFC2348 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1783 RFC1784 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin March 1995 ASCII 6106 4 trivial file transfer booting

This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. [STANDARDS-TRACK]

 RFC2349 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1784 RFC1785 TFTP Option Negotiation Analysis G. Malkin A. Harkin March 1995 ASCII 3354 2 trivial file transfer booting

This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1350 INFORMATIONAL INFORMATIONAL IETF app tftpexts 10.17487/RFC1785 RFC1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++) T. Bates E. Gerich L. Joncheray J-M. Jouanigot D. Karrenberg M. Terpstra J. Yu March 1995 ASCII 133643 83

This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc. and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1786 RFC1787 Routing in a Multi-provider Internet Y. Rekhter April 1995 ASCII 20754 8 Internet Protocol Architechure Board IAB

This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1787 RFC1788 ICMP Domain Name Messages W. Simpson April 1995 ASCII 11722 7 ICMP-DM Internet Control Message Protocol DNS Service

This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 RFC6918 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1788 RFC1789 INETPhone: Telephone Services and Servers on Internet C. Yang April 1995 ASCII 14186 6

This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1789 RFC1790 An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols V. Cerf April 1995 ASCII 8226 4 ISOC

This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1790 RFC1791 TCP And UDP Over IPX Networks With Fixed Path MTU T. Sung April 1995 ASCII 22347 12 Transmission Control Protocol User Datagram Maxium Unit

TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1791 RFC1792 TCP/IPX Connection Mib Specification T. Sung April 1995 ASCII 16389 9 TCP/IPXMIB Transmission Control Protocol Management Information Base

New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1792 RFC1793 Extending OSPF to Support Demand Circuits J. Moy April 1995 ASCII 78728 32 OSPF-DC Open Shortest Path First

This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". [STANDARDS-TRACK]

 RFC3883 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1793 RFC1794 DNS Support for Load Balancing T. Brisco April 1995 ASCII 15494 7 Domain Name System

This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1794 RFC1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1 L. Wells Chair A. Bartky Editor April 1995 ASCII 214848 91 IBM SNA DLS SSP NetBIos APPN

This RFC describes use of Data Link Switching over TCP/IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1434 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1795 RFC1796 Not All RFCs are Standards C. Huitema J. Postel S. Crocker April 1995 ASCII 7049 4

This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1796 RFC1797 Class A Subnet Experiment Internet Assigned Numbers Authority (IANA) April 1995 ASCII 6779 4 Network Address 39 Number

There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1797 RFC1798 Connection-less Lightweight X.500 Directory Access Protocol A. Young June 1995 ASCII 18548 9 CLDAP CLDAP Presentation Address Application Entity Title

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

 RFC3352 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1798 RFC1799 Request for Comments Summary RFC Numbers 1700-1799 M. Kennedy January 1997 ASCII 42038 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1799 RFC1800 Internet Official Protocol Standards J. Postel Editor July 1995 ASCII 83649 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1780 RFC1880 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1800 RFC1801 MHS use of the X.500 Directory to support MHS Routing S. Kille June 1995 ASCII 156462 73 Routing Mail EMail Message Handling System X.400

The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1801 RFC1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing H. Alvestrand K. Jordan S. Langlois J. Romaguera June 1995 ASCII 24637 11 Mail EMail Message Handling System MHS

This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app mhsds 10.17487/RFC1802 RFC1803 Recommendations for an X.500 Production Directory Service R. Wright A. Getchell T. Howes S. Sataluri P. Yee W. Yeong June 1995 ASCII 14721 8 White Pages DSA Directory User Agent

This document contains a set of basic recommendations for a country- level X.500 DSA. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1803 RFC1804 Schema Publishing in X.500 Directory G. Mansfield P. Rajeev S. Raghavan T. Howes June 1995 ASCII 18268 10

In this document we propose a solution using the existing mechanisms of the directory [1] itself. We present a naming scheme for naming schema objects and a meta-schema for storing schema objects in the directory. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app asid 10.17487/RFC1804 RFC1805 Location-Independent Data/Software Integrity Protocol A. Rubin June 1995 ASCII 13352 6 Betsi Security Cryptography

This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1805 RFC1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header R. Troost S. Dorner June 1995 ASCII 15548 8 MIME EMail Mail

This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community.

 RFC2183 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1806 RFC1807 A Format for Bibliographic Records R. Lasher D. Cohen June 1995 ASCII 29417 15 library technical reports email services

This RFC defines a format for bibliographic records describing technical reports. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1357 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1807 RFC1808 Relative Uniform Resource Locators R. Fielding June 1995 ASCII 34950 16 URL URL syntax semantics

In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative Uniform Resource Locators. [STANDARDS-TRACK]

 RFC3986 RFC1738 RFC2368 RFC2396 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1808 RFC1809 Using the Flow Label Field in IPv6 C. Partridge June 1995 ASCII 13591 6

The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1809 RFC1810 Report on MD5 Performance J. Touch June 1995 ASCII 16607 7 IPv6 Message Digest Algorithm Authentication

This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1810 10.17487/RFC1810 RFC1811 U.S. Government Internet Domain Names Federal Networking Council June 1995 ASCII 6641 3 GOV FNC IANA

This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1811 RFC1812 Requirements for IP Version 4 Routers F. Baker Editor June 1995 ASCII 415740 175 routing IPv4

This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]

 RFC1716 RFC1009 RFC2644 RFC6633 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq http://www.rfc-editor.org/errata_search.php?rfc=1812 10.17487/RFC1812 RFC1813 NFS Version 3 Protocol Specification B. Callaghan B. Pawlowski P. Staubach June 1995 ASCII 229793 126 NFSV3

This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1094 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1813 RFC1814 Unique Addresses are Good E. Gerich June 1995 ASCII 5936 3 Internet Registries Protocol Private Network Numbers

The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1814 RFC1815 Character Sets ISO-10646 and ISO-10646-J-1 M. Ohta July 1995 ASCII 11823 6 Japanese Latin

For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary. This memo provides information on such profiling, along with charset names to each profiled instance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1815 RFC1816 U.S. Government Internet Domain Names Federal Networking Council August 1995 ASCII 17979 8 GOV FNC IANA

This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1811 RFC2146 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1816 RFC1817 CIDR and Classful Routing Y. Rekhter August 1995 ASCII 3416 2 Classless Inter Domain Routing

This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1817 RFC1818 Best Current Practices J. Postel T. Li Y. Rekhter August 1995 ASCII 4114 3 BCP

This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).

 HISTORIC BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1818 10.17487/RFC1818 RFC1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+ L. Delgrossi Editor L. Berger Editor August 1995 ASCII 266875 109 ST2

This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). This memo defines an Experimental Protocol for the Internet community.

 RFC1190 IEN119 EXPERIMENTAL EXPERIMENTAL IETF int st2 10.17487/RFC1819 RFC1820 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII 14672 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1844 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1820 RFC1821 Integration of Real-time Services in an IP-ATM Network Architecture M. Borden E. Crawley B. Davie S. Batsell August 1995 ASCII 64466 24 Asynchronous Transfer Mode

The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1821 RFC1822 A Grant of Rights to Use a Specific IBM patent with Photuris J. Lowe August 1995 ASCII 2664 2 Internet Key Management Protocol IKMP IETF

This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1822 RFC1823 The LDAP Application Program Interface T. Howes M. Smith August 1995 ASCII 41081 22 lightweight directory access protocol API X.500

This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1823 RFC1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4) H. Danisch August 1995 ASCII 45540 21 TESS public keys

This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1824 RFC1825 Security Architecture for the Internet Protocol R. Atkinson August 1995 ASCII 56772 22 IPv4 IPv6 IP-layer ipsec

This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]

 RFC2401 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1825 RFC1826 IP Authentication Header R. Atkinson August 1995 ASCII 27583 13 ipsec IPV6-AH Internet Protocol AH security IPv4 IPv6

This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]

 RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1826 RFC1827 IP Encapsulating Security Payload (ESP) R. Atkinson August 1995 ASCII 30278 12 ESP Internet Protocol IPv4 IPv6 ipsec

This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]

 RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1827 RFC1828 IP Authentication using Keyed MD5 P. Metzger W. Simpson August 1995 ASCII 9800 6 ipsec Internet Protocol Authentication Header AH Message Digest 5 Security

This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1828 RFC1829 The ESP DES-CBC Transform P. Karn P. Metzger W. Simpson August 1995 ASCII 19291 11 Encapsulating Security Payload US Data Encryption Standard Cipher Block Chaining IP Internet Protocol Security ipsec

This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1829 RFC1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil August 1995 ASCII 16555 8 Simple Mail Transfer Multipurpose Mail Extensions

This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community.

 RFC3030 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1830 RFC1831 RPC: Remote Procedure Call Protocol Specification Version 2 R. Srinivasan August 1995 ASCII 37798 18 RPC] ONC Open Network Computing

This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

 RFC5531 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1831 RFC1832 XDR: External Data Representation Standard R. Srinivasan August 1995 ASCII 47418 24 XDR RPC ONC Open Network Computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

 RFC4506 DRAFT STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1832 RFC1833 Binding Protocols for ONC RPC Version 2 R. Srinivasan August 1995 ASCII 24449 14 ONC Open Network Computing

This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]

 RFC5665 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1833 RFC1834 Whois and Network Information Lookup Service, Whois++ J. Gargano K. Weiss August 1995 ASCII 14429 7 nicname TCP Transmission Control Protocol directory service server retrieval

This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF wnils 10.17487/RFC1834 RFC1835 Architecture of the WHOIS++ service P. Deutsch R. Schoultz P. Faltstrom C. Weider August 1995 ASCII 80581 41 WHOIS++ nicname TCP Transmission Control Protocol directory service server retrieval

This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1835 RFC1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille August 1995 ASCII 20175 11 message handling

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This memo defines an Experimental Protocol for the Internet community.

 RFC2294 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1836 RFC1837 Representing Tables and Subtrees in the X.500 Directory S. Kille August 1995 ASCII 10924 7 message handling

This document defines techniques for representing two types of information mapping in the OSI Directory. This memo defines an Experimental Protocol for the Internet community.

 RFC2293 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1837 RFC1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses S. Kille August 1995 ASCII 12216 8 message handling

This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. This memo defines an Experimental Protocol for the Internet community.

 RFC2164 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1838 RFC1839 RFC1840 RFC1841 PPP Network Control Protocol for LAN Extension J. Chapman D. Coli A. Harvey B. Jensen K. Rowett September 1995 ASCII 146206 66 point-to-point local area interface, INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1841 RFC1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages Y. Wei Y. Zhang J. Li J. Ding Y. Jiang August 1995 ASCII 24143 12 electronic mail HZ-GB-2312

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1842 RFC1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters F. Lee August 1995 ASCII 8787 5 GB2312-80 electronic mail

The content of this memo is identical to an article of the same title written by the author on September 4, 1989. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1843 RFC1844 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII 15072 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1820 INFORMATIONAL INFORMATIONAL IETF app mailext 10.17487/RFC1844 RFC1845 SMTP Service Extension for Checkpoint/Restart D. Crocker N. Freed A. Cargille September 1995 ASCII 15399 7 simple mail transfer transaction EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1845 RFC1846 SMTP 521 Reply Code A. Durand F. Dupont September 1995 ASCII 6558 4 simple mail transfer RFC7504 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1846 RFC1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted J. Galvin S. Murphy S. Crocker N. Freed October 1995 ASCII 23679 11 MIME-Encyp mail multipurpose extensions

This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community.

 PROPOSED STANDARD PROPOSED STANDARD IETF sec pem 10.17487/RFC1847 RFC1848 MIME Object Security Services S. Crocker N. Freed J. Galvin S. Murphy October 1995 ASCII 95010 48 MIME-Sec mail multipurpose extensions

This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1848 RFC1849 "Son of 1036": News Article Format and Transmission H. Spencer March 2010 ASCII 259422 106 netnews usenet rfc 1036 usefor historic

By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews.

It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. This document defines a Historic Document for the Internet community.

 draft-spencer-usefor-son-of-1036-01 RFC5536 RFC5537 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC1849 RFC1850 OSPF Version 2 Management Information Base F. Baker R. Coltun November 1995 ASCII 140255 80 OSPF-MIB Open Shortest Path First SPF MIB routing network management

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 the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]

 RFC1253 RFC4750 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1850 RFC1851 The ESP Triple DES Transform P. Karn P. Metzger W. Simpson September 1995 ASCII 20000 11 ESP3DES encryption encapsulating security payload cipher block chaining EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1851 RFC1852 IP Authentication using Keyed SHA P. Metzger W. Simpson September 1995 ASCII 9367 6 encryption secure hash algorithm RFC2841 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1852 RFC1853 IP in IP Tunneling W. Simpson October 1995 ASCII 14803 8 internet protocol payload encapsulation

This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes the use of keyed SHA with the IP Authentication Header. This document defines an Experimental Protocol for the Internet community. This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). This document defines an Experimental Protocol for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1853 RFC1854 SMTP Service Extension for Command Pipelining N. Freed October 1995 ASCII 14097 7 simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

 RFC2197 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1854 RFC1855 Netiquette Guidelines S. Hambridge October 1995 ASCII 46185 21 Network Etiquette

This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0028 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC1855 RFC1856 The Opstat Client-Server Model for Statistics Retrieval H. Clark September 1995 ASCII 29954 17 tools performance utilization INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1856 RFC1857 A Model for Common Operational Statistics M. Lambert October 1995 ASCII 55314 27 metrics measurements polling periods

This memo describes a model for operational statistics in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1404 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1857 RFC1858 Security Considerations for IP Fragment Filtering G. Ziemba D. Reed P. Traina October 1995 ASCII 20468 10 internet protocol tcp transmission control protocol routers hosts

IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3128 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1858 RFC1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension Y. Pouffary October 1995 ASCII 14572 8 International Standard Organizatio

This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1859 RFC1860 Variable Length Subnet Table For IPv4 T. Pummill B. Manning October 1995 ASCII 5694 3 values IPv4 subnets

This document itemizes the potential values for IPv4 subnets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1878 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1860 RFC1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced A. Gwinn October 1995 ASCII 49181 23 SNPP SNPP wireless paging

This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1861 RFC1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994 M. McCahill J. Romkey M. Schwartz K. Sollins T. Verschuren C. Weider November 1995 ASCII 62483 27 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1862 RFC1863 A BGP/IDRP Route Server alternative to a full mesh routing D. Haskin October 1995 ASCII 37426 16 BGP-IDRP border gateway protocol inter-domain routing

This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers. This memo defines an Experimental Protocol for the Internet community.

 RFC4223 HISTORIC EXPERIMENTAL IETF rtg idr 10.17487/RFC1863 RFC1864 The Content-MD5 Header Field J. Myers M. Rose October 1995 ASCII 7216 4 CON-MD5 MIME EMail Integrity MIC Digest

This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]

 RFC1544 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1864 RFC1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet W. Houser J. Griffin C. Hage January 1996 ASCII 98361 41 FAQ

This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app edi 10.17487/RFC1865 RFC1866 Hypertext Markup Language - 2.0 T. Berners-Lee D. Connolly November 1995 ASCII 146904 77 HTML HTML SGML Standard Generalized Language WWW World Wide Web

This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK]

 RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC1866 RFC1867 Form-based File Upload in HTML E. Nebel L. Masinter November 1995 ASCII 26183 13 Hypertext Markup Language MIME Multipurpose Internet Mail Extensions

Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community.

 RFC2854 HISTORIC EXPERIMENTAL IETF app html http://www.rfc-editor.org/errata_search.php?rfc=1867 10.17487/RFC1867 RFC1868 ARP Extension - UNARP G. Malkin November 1995 ASCII 7681 4 UNARP Address Resolution Protocol delete entry

This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1868 RFC1869 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker November 1995 ASCII 23299 11 ESMTP Simple Mail Transfer Protocol

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

 RFC1651 RFC2821 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1869 RFC1870 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore November 1995 ASCII 18226 9 SMTP-SIZE Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

 RFC1653 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1870 RFC1871 Addendum to RFC 1602 -- Variance Procedure J. Postel November 1995 ASCII 7747 4 BCP WG escape clause procedures

This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2026 RFC1602 RFC1603 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC1871 RFC1872 The MIME Multipart/Related Content-type E. Levinson December 1995 ASCII 15565 8 multipurpose Internet Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. This memo defines an Experimental Protocol for the Internet community.

 RFC2112 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1872 RFC1873 Message/External-Body Content-ID Access Type E. Levinson December 1995 ASCII 5878 4 CONT-MT Multipurpose Internet Mail Extensions

The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1873 RFC1874 SGML Media Types E. Levinson December 1995 ASCII 12515 6 SGML-MT Multipurpose Internet Mail Extensions

This document proposes new media sub-types of Text/SGML and Application/SGML. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1874 RFC1875 UNINETT PCA Policy Statements N. Berge December 1995 ASCII 19089 10 Policy Certification Authority Encryption

This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1875 RFC1876 A Means for Expressing Location Information in the Domain Name System C. Davis P. Vixie T. Goodwin I. Dickinson January 1996 ASCII 29631 18 DNS-LOC DNS Resource Record (RR) LOC

This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community.

 RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1876 RFC1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses S. Cobb December 1995 ASCII 10591 6 Point-to-Point Protocol Network Control Domain System NetBIOS

This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1877 RFC1878 Variable Length Subnet Table For IPv4 T. Pummill B. Manning December 1995 ASCII 19414 8 values IPv4 subnets

This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1860 HISTORIC INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1878 10.17487/RFC1878 RFC1879 Class A Subnet Experiment Results and Recommendations B. Manning Editor January 1996 ASCII 10589 6 Internet Registry Operations

This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1879 RFC1880 Internet Official Protocol Standards J. Postel Editor November 1995 ASCII 89153 38 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1800 RFC1920 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1880 RFC1881 IPv6 Address Allocation Management IAB IESG December 1995 ASCII 3215 2 IANA Internet Assigned Numbers Authority

The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1881 RFC1882 The 12-Days of Technology Before Christmas B. Hancock December 1995 ASCII 9130 5

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1882 RFC1883 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1995 ASCII 82089 37 IP Next Generation IPng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1883 RFC1884 IP Version 6 Addressing Architecture R. Hinden Editor S. Deering Editor December 1995 ASCII 37860 18 IPV6-Addr IP Next Generation IPng

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

 RFC2373 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1884 RFC1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) A. Conta S. Deering December 1995 ASCII 32214 20 IP Next Generation IPng Internet Group Management IGMP

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

 RFC2463 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1885 RFC1886 DNS Extensions to support IP version 6 S. Thomson C. Huitema December 1995 ASCII 6424 5 DNS-IPV6 IP Next Generation IPng Domain Name System

This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK]

 RFC3596 RFC2874 RFC3152 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1886 RFC1887 An Architecture for IPv6 Unicast Address Allocation Y. Rekhter Editor T. Li Editor December 1995 ASCII 66066 26 IP Next Generation IPng,

This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC1887 RFC1888 OSI NSAPs and IPv6 J. Bound B. Carpenter D. Harrington J. Houldsworth A. Lloyd August 1996 ASCII 36469 16 Internet Protocol Open Systems Interconnection

This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. This memo defines an Experimental Protocol for the Internet community.

 RFC4048 RFC4548 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC1888 RFC1889 RTP: A Transport Protocol for Real-Time Applications Audio-Video Transport Working Group H. Schulzrinne S. Casner R. Frederick V. Jacobson January 1996 ASCII 188544 75 RTP end-to-end network audio video RTCP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. [STANDARDS-TRACK]

 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1889 RFC1890 RTP Profile for Audio and Video Conferences with Minimal Control Audio-Video Transport Working Group H. Schulzrinne January 1996 ASCII 37509 18 RTP-AV end-to-end network conference

This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. [STANDARDS-TRACK]

 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1890 RFC1891 SMTP Service Extension for Delivery Status Notifications K. Moore January 1996 ASCII 65192 31 SMTP-DSN simple mail transfer protocol

This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

 RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1891 10.17487/RFC1891 RFC1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 1996 ASCII 7800 4 MIME-RPT Multipurpose Internet Mail Extensions

The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]

 RFC3462 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1892 RFC1893 Enhanced Mail System Status Codes G. Vaudreuil January 1996 ASCII 28218 15 EMS-CODE simple mail transfer protocol SMTP

There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]

 RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1893 RFC1894 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 1996 ASCII 77462 39 DSN Multipurpose Internet Mail Extensions Content Type

This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS-TRACK]

 RFC3464 RFC2852 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1894 10.17487/RFC1894 RFC1895 The Application/CALS-1840 Content-type E. Levinson February 1996 ASCII 10576 6 MIL-STD-1840 MIME Multipurpose Internet Mail Extensions

This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, "Automated Interchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1895 RFC1896 The text/enriched MIME Content-type P. Resnick A. Walker February 1996 ASCII 45926 21 PS 81217 MIME Multipurpose Internet Mail Extensions

This document defines one particular type of MIME data, the text/enriched MIME type. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1523 RFC1563 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1896 RFC1897 IPv6 Testing Address Allocation R. Hinden J. Postel January 1996 ASCII 6643 4 Internet Protocol prototype software

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community.

 RFC2471 EXPERIMENTAL EXPERIMENTAL IETF int ipngwg 10.17487/RFC1897 RFC1898 CyberCash Credit Card Protocol Version 0.8 D. Eastlake 3rd B. Boesch S. Crocker M. Yesil February 1996 ASCII 113633 52 general payments system

This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1898 RFC1899 Request for Comments Summary RFC Numbers 1800-1899 J. Elliott January 1997 ASCII 37984 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1899 RFC1900 Renumbering Needs Work B. Carpenter Y. Rekhter February 1996 ASCII 9528 4 IP network number addressing

Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols. A change in such IP addressing information associated with a host or subnet is known as "renumbering". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1900 RFC1901 Introduction to Community-based SNMPv2 J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 15903 8 SNMPV2CB Simple Network Management Protocol Version 2

The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.

 HISTORIC EXPERIMENTAL IETF snmpv2 10.17487/RFC1901 RFC1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 77453 40 Simple Network Management Protocol Version 2

It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

 RFC1442 RFC2578 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1902 RFC1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 52652 23 Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

 RFC1443 RFC2579 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1903 RFC1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 47083 24 Simple Network Management Protocol Version 2

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

 RFC1444 RFC2580 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1904 RFC1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 55526 24 OPS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

 RFC1448 RFC3416 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1905 RFC1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 27465 13 TRANS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

 RFC1449 RFC3417 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1906 RFC1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 34881 20 SNMPv2-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

 RFC1450 RFC3418 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1907 RFC1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 21463 10 COEX-MIB Simple Network Management Protocol Version 2

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

 RFC1452 RFC2576 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1908 RFC1909 An Administrative Infrastructure for SNMPv2 K. McCloghrie Editor February 1996 ASCII 45773 19 SNMPV2AI Simple Network Management Protocol Version 2

It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1909 RFC1910 User-based Security Model for SNMPv2 G. Waters Editor February 1996 ASCII 98252 44 SNMPV2SM Simple Network Management Protocol Version 2

In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1910 RFC1911 Voice Profile for Internet Mail G. Vaudreuil February 1996 ASCII 50242 22 MIME Multipurpose Internet Mail Extensions ESMTP SMTP Service Extensions

The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.

 RFC2421 RFC2422 RFC2423 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1911 RFC1912 Common DNS Operational and Configuration Errors D. Barr February 1996 ASCII 38252 16 Domain Name System

This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1537 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1912 RFC1913 Architecture of the Whois++ Index Service C. Weider J. Fullton S. Spero February 1996 ASCII 33743 16 WHOIS++A Bunyip Information Systems Inc. MCNC Center for Communications

The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1913 RFC1914 How to Interact with a Whois++ Mesh P. Faltstrom R. Schoultz C. Weider February 1996 ASCII 17842 10 WHOIS++M distributed databases directory service

In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1914 RFC1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol F. Kastenholz February 1996 ASCII 14347 7 Point to Point Protocol

The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0003 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1915 10.17487/RFC1915 RFC1916 Enterprise Renumbering: Experience and Information Solicitation H. Berkowitz P. Ferguson W. Leland P. Nesser February 1996 ASCII 16117 8 tools applications

Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC1916 RFC1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA P. Nesser II February 1996 ASCII 23623 10 address space Internet Assigned Numbers Authority IANA

This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0004 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC1917 RFC1918 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. J. de Groot E. Lear February 1996 ASCII 22270 9 TCP/IP network host

This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1627 RFC1597 RFC6761 BCP0005 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd http://www.rfc-editor.org/errata_search.php?rfc=1918 10.17487/RFC1918 RFC1919 Classical versus Transparent IP Proxies M. Chatel March 1996 ASCII 87374 35 firewalls security

This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1919 RFC1920 Internet Official Protocol Standards J. Postel March 1996 ASCII 91936 40 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1880 RFC2000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1920 RFC1921 TNVIP Protocol J. Dujonc March 1996 ASCII 57475 30

The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1921 RFC1922 Chinese Character Encoding for Internet Messages HF. Zhu DY. Hu ZG. Wang TC. Kao WCH. Chang M. Crispin March 1996 ASCII 50995 27 transport electronic mail telnet WWW

This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866]. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1922 RFC1923 RIPv1 Applicability Statement for Historic Status J. Halpern S. Bradner March 1996 ASCII 5560 3 Routing Information Protocol

RIP Version 1 [RFC-1058] has been declared an historic document. This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is the Classful nature of RIPv1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC1923 RFC1924 A Compact Representation of IPv6 Addresses R. Elz April 1 1996 ASCII 10409 6 encoding

This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1924 RFC1925 The Twelve Networking Truths R. Callon April 1 1996 ASCII 4294 3 fundamentals

This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1925 10.17487/RFC1925 RFC1926 An Experimental Encapsulation of IP Datagrams on Top of ATM J. Eriksson April 1 1996 ASCII 2969 2 Acoustical Transmission Media (ATM)

This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1926 RFC1927 Suggested Additional MIME Types for Associating Documents C. Rogers April 1 1996 ASCII 5254 3 media-type

Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1927 10.17487/RFC1927 RFC1928 SOCKS Protocol Version 5 M. Leech M. Ganis Y. Lee R. Kuris D. Koblas L. Jones March 1996 ASCII 19741 9 SOCKSV5 firewalls authentication

This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec aft http://www.rfc-editor.org/errata_search.php?rfc=1928 10.17487/RFC1928 RFC1929 Username/Password Authentication for SOCKS V5 M. Leech March 1996 ASCII 3568 2 AUTH-SOCKS firewalls authentication

The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1929 RFC1930 Guidelines for creation, selection, and registration of an Autonomous System (AS) J. Hawkinson T. Bates March 1996 ASCII 22073 10 routing policy Exterior Gateway Protocol Border Inter-Domain Domain Identifier EGP BGP IDRP

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC6996 RFC7300 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC1930 RFC1931 Dynamic RARP Extensions for Automatic Network Address Acquisition D. Brownell April 1996 ASCII 27544 11 Reverse Address Resolution Protocol

This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1931 RFC1932 IP over ATM: A Framework Document R. Cole D. Shur C. Villamizar April 1996 ASCII 68031 31 end-to-end connectivity

It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ipatm 10.17487/RFC1932 RFC1933 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark April 1996 ASCII 47005 22 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

 RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC1933 RFC1934 Ascend's Multilink Protocol Plus (MP+) K. Smith April 1996 ASCII 87072 47 PPP

This document proposes an extension to the PPP Multilink Protocol (MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1934 RFC1935 What is the Internet, Anyway? J. Quarterman S. Carl-Mitchell April 1996 ASCII 30369 11 information tutorial

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1935 RFC1936 Implementing the Internet Checksum in Hardware J. Touch B. Parham April 1996 ASCII 36618 21 PLD code UDP TCP

This memo presents a techniques for efficiently implementing the Internet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1936 10.17487/RFC1936 RFC1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks Y. Rekhter D. Kandlur May 1996 ASCII 18302 8 IP subnet

This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rolc 10.17487/RFC1937 RFC1938 A One-Time Password System N. Haller C. Metz May 1996 ASCII 44844 18 OTP authentication S/KEY

This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]

 RFC2289 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC1938 RFC1939 Post Office Protocol - Version 3 J. Myers M. Rose May 1996 ASCII 47018 23 POP3 POP3

The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]

 RFC1725 RFC1957 RFC2449 RFC6186 STD0053 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1939 10.17487/RFC1939 RFC1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1) D. Estrin T. Li Y. Rekhter K. Varadhan D. Zappala May 1996 ASCII 60858 27 SDRP

The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg sdr 10.17487/RFC1940 RFC1941 Frequently Asked Questions for Schools J. Sellers J. Robichaux May 1996 ASCII 150980 70 FAQ Internet Education

The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1578 FYI0022 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1941 RFC1942 HTML Tables D. Raggett May 1996 ASCII 68705 30 HTML-TBL HyperText Markup Language SGML

This specification extends HTML to support a wide variety of tables. This memo defines an Experimental Protocol for the Internet community.

 RFC2854 HISTORIC EXPERIMENTAL IETF app html 10.17487/RFC1942 RFC1943 Building an X.500 Directory Service in the US B. Jennings May 1996 ASCII 51266 22 White Pages

This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1943 RFC1944 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid May 1996 ASCII 66061 30 testing performance

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1944 RFC1945 Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee R. Fielding H. Frystyk May 1996 ASCII 137582 60 HTTP-1.0 HTTP World-Wide Web application

The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC1945 RFC1946 Native ATM Support for ST2+ S. Jackowski May 1996 ASCII 50430 21 integrated services ATM Quality of Service QoS

This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: ATM to internet, internet to ATM, and internet to internet across ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1946 RFC1947 Greek Character Encoding for Electronic Mail Messages D. Spinellis May 1996 ASCII 14428 7 character set ISO MIME

This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1947 RFC1948 Defending Against Sequence Number Attacks S. Bellovin May 1996 ASCII 13074 6 crypgraphic authentication spoofing

IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC6528 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1948 10.17487/RFC1948 RFC1949 Scalable Multicast Key Distribution A. Ballardie May 1996 ASCII 41853 18 SMKD MBONE security authentication

This memo provides a scalable solution to the multicast key distribution problem. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC1949 RFC1950 ZLIB Compressed Data Format Specification version 3.3 P. Deutsch J-L. Gailly May 1996 ASCII 20502 11 PS 37768 PDF 36393 ZLIB compressed data format checksum

This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1950 RFC1951 DEFLATE Compressed Data Format Specification version 1.3 P. Deutsch May 1996 ASCII 36944 17 PS 57408 PDF 56620 DEFLATE compressed data format coding

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1951 RFC1952 GZIP file format specification version 4.3 P. Deutsch May 1996 ASCII 25036 12 PS 43337 PDF 43211 GZIP compressed data format redundancy check

This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1952 RFC1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII 43749 20 IFMP IP flow routing information

The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1953 RFC1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII 16075 8 datagrams IFMP

This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1954 RFC1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG R. Hinden June 1996 ASCII 10115 5 IPNG addressing routing

This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1955 RFC1956 Registration in the MIL Domain D. Engebretson R. Plzak June 1996 ASCII 2923 2 DoD Department of Defense

This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1956 RFC1957 Some Observations on Implementations of the Post Office Protocol (POP3) R. Nelson June 1996 ASCII 2325 2 client server

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1939 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1957 RFC1958 Architectural Principles of the Internet B. Carpenter Editor June 1996 ASCII 17345 8 IAB

The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3439 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1958 RFC1959 An LDAP URL Format T. Howes M. Smith June 1996 ASCII 7243 4 LDAP-URL Lightweight Directory Access Protocol Uniform Resource Locator

This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]

 RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=1959 10.17487/RFC1959 RFC1960 A String Representation of LDAP Search Filters T. Howes June 1996 ASCII 5288 3 LDAP-STR Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

 RFC1558 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC1960 RFC1961 GSS-API Authentication Method for SOCKS Version 5 P. McMahon June 1996 ASCII 16036 9 GSSAPI-SOC Generic Security Service Application Program Interface

This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1961 RFC1962 The PPP Compression Control Protocol (CCP) D. Rand June 1996 ASCII 18005 9 PPP-CCP point-to-point protocol data links

This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]

 RFC2153 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1962 RFC1963 PPP Serial Data Transport Protocol (SDTP) K. Schneider S. Venters August 1996 ASCII 38185 20 Point-to-Point Protocol

This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1963 RFC1964 The Kerberos Version 5 GSS-API Mechanism J. Linn June 1996 ASCII 47413 20 GSSAPI-KER Generic Security Service Application Program Interface

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS-TRACK]

 RFC4121 RFC6649 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1964 RFC1965 Autonomous System Confederations for BGP P. Traina June 1996 ASCII 13575 7 BGP-ASC Border Gateway Protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. This memo defines an Experimental Protocol for the Internet community.

 RFC3065 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1965 RFC1966 BGP Route Reflection An alternative to full mesh IBGP T. Bates R. Chandra June 1996 ASCII 14320 7 BGP-RR Border Gateway Protocol autonomous system

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. This memo defines an Experimental Protocol for the Internet community.

 RFC4456 RFC2796 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1966 RFC1967 PPP LZS-DCP Compression Protocol (LZS-DCP) K. Schneider R. Friend August 1996 ASCII 40039 18 Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1967 RFC1968 The PPP Encryption Control Protocol (ECP) G. Meyer June 1996 ASCII 20781 11 PPP-ECP Point-to-Point Protocol data

This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1968 RFC1969 The PPP DES Encryption Protocol (DESE) K. Sklower G. Meyer June 1996 ASCII 20383 10 Point-to-Point Protocol encapsulated packets

This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2419 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1969 RFC1970 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson August 1996 ASCII 197632 82 Internet Protocol

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

 RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1970 RFC1971 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten August 1996 ASCII 56890 23 Internet Protocol link-local address Duplicate Address Detection procedure

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

 RFC2462 PROPOSED STANDARD PROPOSED STANDARD IETF int addrconf 10.17487/RFC1971 RFC1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks M. Crawford August 1996 ASCII 6353 4 IPV6-ETHER Internet Protocol frame format transmission

This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]

 RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1972 RFC1973 PPP in Frame Relay W. Simpson June 1996 ASCII 14780 10 PPP-FRAME Point-to-Point Protocol encapsulated packets

This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1973 RFC1974 PPP Stac LZS Compression Protocol R. Friend W. Simpson August 1996 ASCII 45267 20 PPP-STAC Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1974 RFC1975 PPP Magnalink Variable Resource Compression D. Schremp J. Black J. Weiss August 1996 ASCII 8655 6 PPP-MAG Point-to-Point Protocol MVRCA

The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1975 RFC1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) K. Schneider S. Venters August 1996 ASCII 19781 10 PPP-DCE Point-to-Point Protocol LCP extension

This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1976 RFC1977 PPP BSD Compression Protocol V. Schryver August 1996 ASCII 50747 25 PPP-BSD Point-to-Point Protocol Unix Compress

This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1977 RFC1978 PPP Predictor Compression Protocol D. Rand August 1996 ASCII 17424 9 PPP-PRED Point-to-Point Protocol

This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1978 RFC1979 PPP Deflate Protocol J. Woods August 1996 ASCII 18803 10 PPP-DEFL Point-to-Point Protocol Compression Control

This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1979 10.17487/RFC1979 RFC1980 A Proposed Extension to HTML : Client-Side Image Maps J. Seidman August 1996 ASCII 13448 7 HyperText Markup Language Uniform Identifier URI

The markup language known as "HTML/2.0" provides for image maps. Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client- Side Image Maps," which resolves these limitations.

 RFC2854 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1980 RFC1981 Path MTU Discovery for IP version 6 J. McCann S. Deering J. Mogul August 1996 ASCII 34088 15 MTU-IPV6 Internet Protocol

This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. [STANDARDS-TRACK]

 DRAFT STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=1981 10.17487/RFC1981 RFC1982 Serial Number Arithmetic R. Elz R. Bush August 1996 ASCII 14440 6 SNA domain name system DNS

The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]

 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1982 RFC1983 Internet Users' Glossary G. Malkin Editor August 1996 ASCII 123008 62 basic terms acronyms

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1392 FYI0018 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1983 RFC1984 IAB and IESG Statement on Cryptographic Technology and the Internet IAB IESG August 1996 ASCII 10738 5 security privacy

The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 BCP0200 BEST CURRENT PRACTICE INFORMATIONAL Legacy 10.17487/RFC1984 RFC1985 SMTP Service Extension for Remote Message Queue Starting J. De Winter August 1996 ASCII 14815 7 SMTP-ETRN Simple ETRN Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1985 10.17487/RFC1985 RFC1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) W. Polites W. Wollman D. Woo R. Langan August 1996 ASCII 49772 21 ETFTP TFTP NETBLT

This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1986 RFC1987 Ipsilon's General Switch Management Protocol Specification Version 1.1 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall August 1996 ASCII 105821 44 GSMP ATM switch

The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2297 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1987 RFC1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework G. McAnally D. Gilbert J. Flick August 1996 ASCII 3821 2 HP

This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1988 RFC1989 PPP Link Quality Monitoring W. Simpson August 1996 ASCII 29289 16 PPP-LINK Point-to-Point Protocol

This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK]

 RFC1333 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1989 RFC1990 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr T. Coradetti August 1996 ASCII 53271 24 PPP-MP Point-to-Point Protocol datagrams

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

 RFC1717 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1990 RFC1991 PGP Message Exchange Formats D. Atkins W. Stallings P. Zimmermann August 1996 ASCII 46255 21 PGP-MEF Pretty Good Privacy encryption electronic mail

This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC4880 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1991 RFC1992 The Nimrod Routing Architecture I. Castineyra N. Chiappa M. Steenstrup August 1996 ASCII 59848 27 scalable internetwork

Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork. First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF. In this document, we present a detailed description of this architecture. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC1992 RFC1993 PPP Gandalf FZA Compression Protocol A. Barbir D. Carr W. Simpson August 1996 ASCII 9811 7 Point-to-Point Protocol

This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1993 RFC1994 PPP Challenge Handshake Authentication Protocol (CHAP) W. Simpson August 1996 ASCII 24094 13 PPP-CHAP Point-to-Point Protocol cryptology

This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. [STANDARDS-TRACK]

 RFC1334 RFC2484 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1994 RFC1995 Incremental Zone Transfer in DNS M. Ohta August 1996 ASCII 16810 8 DNS-IZT Domain Name System IXFR

This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]

 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=1995 10.17487/RFC1995 RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) P. Vixie August 1996 ASCII 15247 7 DNS-NOTIFY Domain Name System

This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]

 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1996 RFC1997 BGP Communities Attribute R. Chandra P. Traina T. Li August 1996 ASCII 8275 5 BGP-COMM Border Gateway Protocol

This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]

 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1997 10.17487/RFC1997 RFC1998 An Application of the BGP Community Attribute in Multi-home Routing E. Chen T. Bates August 1996 ASCII 16953 9 Border Gateway Protocol

This document presents an application of the BGP community attribute [2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1998 RFC1999 Request for Comments Summary RFC Numbers 1900-1999 J. Elliott January 1997 ASCII 39819 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1999 RFC2000 Internet Official Protocol Standards J. Postel Editor February 1997 ASCII 121356 56 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.

 RFC1920 RFC2200 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2000 RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms W. Stevens January 1997 ASCII 12981 6 TCPSLOWSRT Transmission Control Protocol

Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]

 RFC2581 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2001 RFC2002 IP Mobility Support C. Perkins Editor October 1996 ASCII 193103 79 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS-TRACK]

 RFC3220 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2002 RFC2003 IP Encapsulation within IP C. Perkins October 1996 ASCII 30291 14 IPENCAPIP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]

 RFC3168 RFC6864 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2003 10.17487/RFC2003 RFC2004 Minimal Encapsulation within IP C. Perkins October 1996 ASCII 12202 6 MINI-IP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2004 10.17487/RFC2004 RFC2005 Applicability Statement for IP Mobility Support J. Solomon October 1996 ASCII 10509 5 Internet Protocol

As required by [RFC 1264], this report discusses the applicability of Mobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2005 RFC2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2 D. Cong M. Hamlen C. Perkins October 1996 ASCII 95030 52 MOBILEIPMIB Mobile Internet Protocol MIB Managed Information Base

This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2006 RFC2007 Catalogue of Network Training Materials J. Foster M. Isaacs M. Prior October 1996 ASCII 78941 55 TRAINMAT IETF TERENA

The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0029 INFORMATIONAL INFORMATIONAL IETF trainmat 10.17487/RFC2007 RFC2008 Implications of Various Address Allocation Policies for Internet Routing Y. Rekhter T. Li October 1996 ASCII 34717 13 IP unicast

The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0007 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC2008 RFC2009 GPS-Based Addressing and Routing T. Imielinski J. Navas November 1996 ASCII 66229 27 GPS-AR domain names geographic

This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2009 RFC2010 Operational Criteria for Root Name Servers B. Manning P. Vixie October 1996 ASCII 14870 7 host hardware

This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2870 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2010 RFC2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII 31168 18 MIB-IP IP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]

 RFC4293 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2011 RFC2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII 16792 10 MIB-TCP TCP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]

 RFC4022 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2012 RFC2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII 9333 6 MIB-UDP] Simple Network Management Protocol MIB UDP

This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]

 RFC4113 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2013 RFC2014 IRTF Research Group Guidelines and Procedures A. Weinrib J. Postel October 1996 ASCII 27507 13 Internet Research Task Force

This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0008 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2014 RFC2015 MIME Security with Pretty Good Privacy (PGP) M. Elkins October 1996 ASCII 14223 8 MIME-PGP Authentication Encryption

This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK]

 RFC3156 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2015 10.17487/RFC2015 RFC2016 Uniform Resource Agents (URAs) L. Daigle P. Deutsch B. Heelan C. Alpaugh M. Maclachlan October 1996 ASCII 38355 21 URAS

This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2016 RFC2017 Definition of the URL MIME External-Body Access-Type N. Freed K. Moore A. Cargille October 1996 ASCII 9000 5 URL-ACC Uniform Resource Locators Multipurpose Internet Message Extensions

This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC2017 RFC2018 TCP Selective Acknowledgment Options M. Mathis J. Mahdavi S. Floyd A. Romanow October 1996 ASCII 25671 12 TCP-ACK Transmission Control Protocol SACK

This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]

 RFC1072 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=2018 10.17487/RFC2018 RFC2019 Transmission of IPv6 Packets Over FDDI M. Crawford October 1996 ASCII 12344 6 IPV6-FDDI frame format Fiber Distributed Data Interface

This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]

 RFC2467 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2019 RFC2020 IEEE 802.12 Interface MIB J. Flick October 1996 ASCII 72135 31 802.12-MIB 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 network interfaces based on IEEE 802.12. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2020 RFC2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2 S. Waldbusser January 1997 ASCII 262223 130 RMON-MIB RMON MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2021 10.17487/RFC2021 RFC2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks G. Armitage November 1996 ASCII 189219 82 MULTI-UNI Asynchronous Transfer Mode

This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC2022 RFC2023 IP Version 6 over PPP D. Haskin E. Allen October 1996 ASCII 20275 10 IPV6-PPP Internet Protocol Point IPv6

This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. [STANDARDS-TRACK]

 RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2023 RFC2024 Definitions of Managed Objects for Data Link Switching using SMIv2 D. Chen Editor P. Gayek S. Nix October 1996 ASCII 173952 90 DLSW-MIB MIB DLSW Management Information Base

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg dlswmib 10.17487/RFC2024 RFC2025 The Simple Public-Key GSS-API Mechanism (SPKM) C. Adams October 1996 ASCII 101692 45 SPKM

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2025 RFC2026 The Internet Standards Process -- Revision 3 S. Bradner October 1996 ASCII 86731 36 Protocols copyrights intellectual property

This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1602 RFC1871 RFC3667 RFC3668 RFC3932 RFC3978 RFC3979 RFC5378 RFC5657 RFC5742 RFC6410 RFC7100 RFC7127 RFC7475 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2026 10.17487/RFC2026 RFC2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin October 1996 ASCII 24207 11 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2282 INFORMATIONAL BEST CURRENT PRACTICE IETF gen poised95 10.17487/RFC2027 RFC2028 The Organizations Involved in the IETF Standards Process R. Hovey S. Bradner October 1996 ASCII 13865 7 Internet Engineering Task Force

This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC3668 RFC3979 BCP0011 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2028 10.17487/RFC2028 RFC2029 RTP Payload Format of Sun's CellB Video Encoding M. Speer D. Hoffman October 1996 ASCII 11216 6 RTP-CELLB Real Time Transport Protocol

This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2029 RFC2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills October 1996 ASCII 48620 18 NTP SNTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1769 RFC4330 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2030 10.17487/RFC2030 RFC2031 IETF-ISOC relationship E. Huizer October 1996 ASCII 8816 4 Internet Society Engineering Task Force

This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF gen poised95 10.17487/RFC2031 RFC2032 RTP Payload Format for H.261 Video Streams T. Turletti C. Huitema October 1996 ASCII 27488 11 RTP-H.261 Real Time Transport Protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]

 RFC4587 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2032 RFC2033 Local Mail Transfer Protocol J. Myers October 1996 ASCII 14711 7 LMTP SMTP Simple Mail Transfer Protocol

SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2033 RFC2034 SMTP Service Extension for Returning Enhanced Error Codes N. Freed October 1996 ASCII 10460 6 SMTP-ENH Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2034 RFC2035 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne October 1996 ASCII 30079 16 RTP-JPEG Real Time Transport Protocol Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. [STANDARDS-TRACK]

 RFC2435 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2035 RFC2036 Observations on the use of Components of the Class A Address Space within the Internet G. Huston October 1996 ASCII 20743 9 Internet Assigned Numbers Authority IANA

This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of the Class A address space to registries, for deployment within the Internet as class-less address blocks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL IETF cidrd 10.17487/RFC2036 RFC2037 Entity MIB using SMIv2 K. McCloghrie A. Bierman October 1996 ASCII 74362 35 ENTITY-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

 RFC2737 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib 10.17487/RFC2037 RFC2038 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal October 1996 ASCII 23266 11 Real Time Transport Protocol

This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. [STANDARDS-TRACK]

 RFC2250 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2038 RFC2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers C. Kalbfleisch November 1996 ASCII 31966 14 Management Information Base HTTP

This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2039 RFC2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms R. Baldwin R. Rivest October 1996 ASCII 54598 29 RC5 Cipher Block Chaining CBC

This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2040 10.17487/RFC2040 RFC2041 Mobile Network Tracing B. Noble G. Nguyen M. Satyanarayanan R. Katz October 1996 ASCII 64688 27 IP Internet Protocol

This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2041 RFC2042 Registering New BGP Attribute Types B. Manning January 1997 ASCII 4001 3 Border Gateway Protocol

This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2042 10.17487/RFC2042 RFC2043 The PPP SNA Control Protocol (SNACP) A. Fuqua October 1996 ASCII 13719 7 PPP-SNACP Point-to-point protocol systems network architecture

This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2043 RFC2044 UTF-8, a transformation format of Unicode and ISO 10646 F. Yergeau October 1996 ASCII 11932 6 UCS Transformation Format

The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2279 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2044 RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed N. Borenstein November 1996 ASCII 72932 31 MIME media types headers

This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 RFC5335 RFC6532 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2045 10.17487/RFC2045 RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed N. Borenstein November 1996 ASCII 105854 44 MIME-MEDIA headers structure

This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 RFC2646 RFC3798 RFC5147 RFC6657 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2046 10.17487/RFC2046 RFC2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996 ASCII 33262 15 MIME-MSG media type

This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2047 10.17487/RFC2047 RFC2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin J. Postel November 1996 ASCII 45033 21 media types external body access content-transfer-encodings

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1521 RFC1522 RFC1590 RFC4288 RFC4289 RFC3023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app 822ext 10.17487/RFC2048 RFC2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed N. Borenstein November 1996 ASCII 51207 24 MIME-CONF media type message formats

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2049 10.17487/RFC2049 RFC2050 Internet Registry IP Allocation Guidelines K. Hubbard M. Kosters D. Conrad D. Karrenberg J. Postel November 1996 ASCII 28975 13 Internet Addresses Network Numbers

This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1466 RFC7020 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC2050 RFC2051 Definitions of Managed Objects for APPC using SMIv2 M. Allen B. Clouston Z. Kielczewski W. Kwan B. Moore October 1996 ASCII 239359 124 SNANAU-APP

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 the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2051 RFC2052 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie October 1996 ASCII 19257 10 DNS-SRV Domain Name System

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). This memo defines an Experimental Protocol for the Internet community.

 RFC2782 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2052 RFC2053 The AM (Armenia) Domain E. Der-Danieliantz October 1996 ASCII 4128 3 Top Level Domain Country Code

The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2053 RFC2054 WebNFS Client Specification B. Callaghan October 1996 ASCII 36354 16 Network Fil System

This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2054 RFC2055 WebNFS Server Specification B. Callaghan October 1996 ASCII 20498 10 Network Fil System

This document describes the specifications for a server of WebNFS clients. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2055 RFC2056 Uniform Resource Locators for Z39.50 R. Denenberg J. Kunze D. Lynch November 1996 ASCII 14204 7 URLZ39.50 URL information retrieval

Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2056 RFC2057 Source Directed Access Control on the Internet S. Bradner November 1996 ASCII 56664 20 content regulation deposition

This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2057 RFC2058 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens January 1997 ASCII 118880 64 encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

 RFC2138 PROPOSED STANDARD PROPOSED STANDARD IETF ops nasreq 10.17487/RFC2058 RFC2059 RADIUS Accounting C. Rigney January 1997 ASCII 44237 25 remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2139 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2059 RFC2060 Internet Message Access Protocol - Version 4rev1 M. Crispin December 1996 ASCII 166513 82 IMAPV4 IMAP electronic mail Internet Message Access Protocol

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]

 RFC1730 RFC3501 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2060 10.17487/RFC2060 RFC2061 IMAP4 Compatibility with IMAP2bis M. Crispin December 1996 ASCII 5867 3 IMAP electronic mail Internet Message Access Protocol

This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1730 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2061 RFC2062 Internet Message Access Protocol - Obsolete Syntax M. Crispin December 1996 ASCII 14222 8 IMAP electronic mail

This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2062 RFC2063 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth January 1997 ASCII 89092 37 TFM-ARCH network data

This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. This memo defines an Experimental Protocol for the Internet community.

 RFC2722 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2063 RFC2064 Traffic Flow Measurement: Meter MIB N. Brownlee January 1997 ASCII 67520 38 METER-MIB Management Information Base Network Data

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. This memo defines an Experimental Protocol for the Internet community.

 RFC2720 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2064 RFC2065 Domain Name System Security Extensions D. Eastlake 3rd C. Kaufman January 1997 ASCII 97718 41 DNS-SEC DNS authentication encryption

The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK]

 RFC2535 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2065 RFC2066 TELNET CHARSET Option R. Gellens January 1997 ASCII 26088 12 TOPT-CHARSET character set application

This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2066 RFC2067 IP over HIPPI J. Renwick January 1997 ASCII 66702 30 IP-HIPPI ANSI High-Performance Parallel Interface Internet Protocol

ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. [STANDARDS-TRACK]

 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2067 RFC2068 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk T. Berners-Lee January 1997 ASCII 378114 162 HTTP-1.1 World Wide Web WWW hypermedia

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]

 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2068 RFC2069 An Extension to HTTP : Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler P. Leach A. Luotonen E. Sink L. Stewart January 1997 ASCII 41733 18 DAA Hypertext Transfer Protocol

The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2069 10.17487/RFC2069 RFC2070 Internationalization of the Hypertext Markup Language F. Yergeau G. Nicol G. Adams M. Duerst January 1997 ASCII 91887 43 HTML-INT HTML WWW World Wide Web

This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. [STANDARDS-TRACK]

 RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC2070 RFC2071 Network Renumbering Overview: Why would I want it and what is it anyway? P. Ferguson H. Berkowitz January 1997 ASCII 33218 14 Internet Enterprise Connecting Routers

This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2071 RFC2072 Router Renumbering Guide H. Berkowitz January 1997 ASCII 110591 48 Internet Enterprise Connecting Routers

Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC4192 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2072 RFC2073 An IPv6 Provider-Based Unicast Address Format Y. Rekhter P. Lothberg R. Hinden S. Deering J. Postel January 1997 ASCII 15549 7 IPV6-UNI

This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]

 RFC2374 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2073 RFC2074 Remote Network Monitoring MIB Protocol Identifiers A. Bierman R. Iddon January 1997 ASCII 81262 43 RMON-MIB RMON Management Information Base

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]

 RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2074 RFC2075 IP Echo Host Service C. Partridge January 1997 ASCII 12536 5 IP-Echo Internet Protocol datagram

This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2075 RFC2076 Common Internet Message Headers J. Palme February 1997 ASCII 47639 27 email

This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app mailext http://www.rfc-editor.org/errata_search.php?rfc=2076 10.17487/RFC2076 RFC2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions S. Nelson C. Parks Mitra January 1997 ASCII 30158 13 MIME-MODEL MIME Media Type Content Type

The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2077 RFC2078 Generic Security Service Application Program Interface, Version 2 J. Linn January 1997 ASCII 185990 85 GSSAP Authentication Cryptology Data integrity

The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

 RFC1508 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2078 RFC2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) M. Smith January 1997 ASCII 8757 5 URI-ATT URL Universal Resource Locators Directory

This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2079 RFC2080 RIPng for IPv6 G. Malkin R. Minnear January 1997 ASCII 47534 19 RIPNG-IPV6 Routing Information Protocol Internet

This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2080 RFC2081 RIPng Protocol Applicability Statement G. Malkin January 1997 ASCII 6821 4 Routing Information Protocol Internet

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC2081 RFC2082 RIP-2 MD5 Authentication F. Baker R. Atkinson January 1997 ASCII 25436 12 RIP2-MD5 Routing Information Protocol Encryption

Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]

 RFC4822 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC2082 RFC2083 PNG (Portable Network Graphics) Specification Version 1.0 T. Boutell March 1997 ASCII 242528 102 PNG file format bitmap

This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2083 RFC2084 Considerations for Web Transaction Security G. Bossert S. Cooper W. Drummond January 1997 ASCII 9022 6 authentication encryption World Wide Web WWW

This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF sec wts 10.17487/RFC2084 RFC2085 HMAC-MD5 IP Authentication with Replay Prevention M. Oehler R. Glenn February 1997 ASCII 13399 6 HMAC-MD5 ipsec Message Digest Security Internet Protocol Encryption

This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2085 RFC2086 IMAP4 ACL extension J. Myers January 1997 ASCII 13925 8 IMAP4-ACL Internet Message Access Protocol Control List

The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

 RFC4314 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2086 RFC2087 IMAP4 QUOTA extension J. Myers January 1997 ASCII 8542 5 IMAP4-QUO Internet Message Access Protocol

The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2087 RFC2088 IMAP4 non-synchronizing literals J. Myers January 1997 ASCII 4052 2 IMAP4-LIT Internet Message Access Protocol

The Internet Message Access Protocol [STANDARDS-TRACK]

 RFC7888 RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2088 RFC2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent B. Wijnen D. Levi January 1997 ASCII 23814 12

The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2576 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2089 RFC2090 TFTP Multicast Option A. Emberson February 1997 ASCII 11857 6 TFTP-MULTI Trivial File Transfer Protocol

This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2090 RFC2091 Triggered Extensions to RIP to Support Demand Circuits G. Meyer S. Sherry January 1997 ASCII 44835 22 RIP-TRIG

This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2091 RFC2092 Protocol Analysis for Triggered RIP S. Sherry G. Meyer January 1997 ASCII 10865 6

As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rip http://www.rfc-editor.org/errata_search.php?rfc=2092 10.17487/RFC2092 RFC2093 Group Key Management Protocol (GKMP) Specification H. Harney C. Muckenhirn July 1997 ASCII 48678 23 GKMP-SPEC

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2093 RFC2094 Group Key Management Protocol (GKMP) Architecture H. Harney C. Muckenhirn July 1997 ASCII 53097 22 GKMP-ARCH

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2094 RFC2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede January 1997 ASCII 10446 5 Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

 RFC2195 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2095 RFC2096 IP Forwarding Table MIB F. Baker January 1997 ASCII 35930 21 TABLE-MIB Management Information Base Internet Protocol

This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]

 RFC1354 RFC4292 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2096 RFC2097 The PPP NetBIOS Frames Control Protocol (NBFCP) G. Pall January 1997 ASCII 27104 13 PPP-NBFCP Point-to-Point Protocol

This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2097 RFC2098 Toshiba's Router Architecture Extensions for ATM : Overview Y. Katsube K. Nagami H. Esaki February 1997 ASCII 43622 18 Asynchronis Transfer Mode datagram IP Internet Protocol

This memo describes a new internetworking architecture which makes better use of the property of ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2098 RFC2099 Request for Comments Summary RFC Numbers 2000-2099 J. Elliott March 1997 ASCII 40763 21 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2099 RFC2100 The Naming of Hosts J. Ashworth April 1 1997 ASCII 4077 3 April Fool's

This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2100 RFC2101 IPv4 Address Behaviour Today B. Carpenter J. Crowcroft Y. Rekhter February 1997 ASCII 31407 13 Internet Protocol Internet Architecture Board

The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2101 RFC2102 Multicast Support for Nimrod : Requirements and Solution Approaches R. Ramanathan February 1997 ASCII 50963 23 scalable routing architecture

Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2102 RFC2103 Mobility Support for Nimrod : Challenges and Solution Approaches R. Ramanathan February 1997 ASCII 41352 17 IP Internet Protocol routing addressing

We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2103 RFC2104 HMAC: Keyed-Hashing for Message Authentication H. Krawczyk M. Bellare R. Canetti February 1997 ASCII 22297 11 ipsec Message Digest Internet Protocol Security encryption

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind

 RFC6151 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2104 10.17487/RFC2104 RFC2105 Cisco Systems' Tag Switching Architecture Overview Y. Rekhter B. Davie D. Katz E. Rosen G. Swallow February 1997 ASCII 33013 13 network layer packet ATM switches

This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2105 RFC2106 Data Link Switching Remote Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII 40819 19 DLSRAP NetBios DLSW

This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2114 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2106 RFC2107 Ascend Tunnel Management Protocol - ATMP K. Hamzeh February 1997 ASCII 44300 21 RADIUS authentication

This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2107 RFC2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie February 1997 ASCII 166336 82 802.3-MIB MIB Management Information Base

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 IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 &

 RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2108 RFC2109 HTTP State Management Mechanism D. Kristol L. Montulli February 1997 ASCII 43469 21 HTTP-STATE Hypertext Transfer Protocol cookie

This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]

 RFC2965 HISTORIC PROPOSED STANDARD IETF app http 10.17487/RFC2109 RFC2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann March 1997 ASCII 41961 19 MHTML Hyper Text Markup Language Multipurpose Internet Mail Extensions

This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK]

 RFC2557 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2110 RFC2111 Content-ID and Message-ID Uniform Resource Locators E. Levinson March 1997 ASCII 9099 5 Hyper Text Markup Language URL MIME

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

 RFC2392 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2111 RFC2112 The MIME Multipart/Related Content-type E. Levinson March 1997 ASCII 17052 9 Hyper Text Markup Language Multipurpose Internet,Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

 RFC1872 RFC2387 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2112 RFC2113 IP Router Alert Option D. Katz February 1997 ASCII 7924 4 ROUT-ALERT

This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]

 RFC5350 RFC6398 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2113 RFC2114 Data Link Switching Client Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII 50872 22 DLSCAP

This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2114 RFC2115 Management Information Base for Frame Relay DTEs Using SMIv2 C. Brown F. Baker September 1997 ASCII 59950 32 FRAME-MIB MIB

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 Frame Relay interfaces on DTEs. [STANDARDS-TRACK]

 RFC1315 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2115 RFC2116 X.500 Implementations Catalog-96 C. Apple K. Rossen April 1997 ASCII 243994 164 Directory Services DSA DUA Agent Interfaces

This document is a revision to [RFC 1632]: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. [RFC 1632] is a revision of [RFC 1292]. This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1632 FYI0011 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2116 RFC2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1997 ASCII 151886 66

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community.

 RFC2362 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2117 RFC2118 Microsoft Point-To-Point Compression (MPPC) Protocol G. Pall March 1997 ASCII 17443 9 Point-to-Point Protocol PPP

This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2118 RFC2119 Key words for use in RFCs to Indicate Requirement Levels S. Bradner March 1997 ASCII 4723 3 Standards Track Documents

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bradner-key-words-03 BCP0014 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2119 10.17487/RFC2119 RFC2120 Managing the X.500 Root Naming Context D. Chadwick March 1997 ASCII 30773 14 X.500-NAME ISO International Standards Organization

This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app ids 10.17487/RFC2120 RFC2121 Issues affecting MARS Cluster Size G. Armitage March 1997 ASCII 26781 12 ATM Asynchronous Transfer Mode Multicast IP Internet Protocol

This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2121 RFC2122 VEMMI URL Specification D. Mavrakis H. Layec K. Kartmann March 1997 ASCII 25043 11 VEMMI-URL Uniform Resource Locator Enhanced Man-Machine Interface Videotex

A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2122 RFC2123 Traffic Flow Measurement: Experiences with NeTraMet N. Brownlee March 1997 ASCII 81874 34 Meter Reader Network

This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2123 RFC2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 P. Amsden J. Amweg P. Calato S. Bensley G. Lyons March 1997 ASCII 47912 21 LFAP

This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2124 RFC2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) C. Richards K. Smith March 1997 ASCII 49213 24 BAP-BACP Point-to-Point datagram multilink

This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2125 RFC2126 ISO Transport Service on top of TCP (ITOT) Y. Pouffary A. Young March 1997 ASCII 51032 25 ITOT International Standards Organization Transmission Control Protocol

This document is a revision to STD35, RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK]

 RFC1006 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2126 10.17487/RFC2126 RFC2127 ISDN Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII 95994 49 ISDN-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib http://www.rfc-editor.org/errata_search.php?rfc=2127 10.17487/RFC2127 RFC2128 Dial Control Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII 66153 34 DC-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing demand access circuits, including ISDN. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib 10.17487/RFC2128 RFC2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification K. Nagami Y. Katsube Y. Shobatake A. Mogi S. Matsuzawa T. Jinmei H. Esaki April 1997 ASCII 41137 19 packet flow datalink mapping

This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2129 RFC2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 C. Weider C. Preston K. Simonsen H. Alvestrand R. Atkinson M. Crispin P. Svanberg April 1997 ASCII 63443 31 Internet Architecture Board interoperability

This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC6055 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2130 RFC2131 Dynamic Host Configuration Protocol R. Droms March 1997 ASCII 113738 45 DHCP DHCPv4

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

 RFC1541 RFC3396 RFC4361 RFC5494 RFC6842 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2131 10.17487/RFC2131 RFC2132 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms March 1997 ASCII 63670 34 DHCP-BOOTP Dynamic Host Configuration Protocol Bootstrap

This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]

 RFC1533 RFC3442 RFC3942 RFC4361 RFC4833 RFC5494 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2132 10.17487/RFC2132 RFC2133 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens April 1997 ASCII 69737 32 application program interface API Internet Protocol addresses

This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2133 RFC2134 Articles of Incorporation of Internet Society ISOC Board of Trustees April 1997 ASCII 9131 5 ISOC

These are the articles of incorporation of the Internet Society. They are published for the information of the IETF community at the request of the poisson working group. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2134 RFC2135 Internet Society By-Laws ISOC Board of Trustees April 1997 ASCII 20467 9 ISOC

These are the by-laws of the Internet Society, as amended, as of June 1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2135 RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE) P. Vixie Editor S. Thomson Y. Rekhter J. Bound April 1997 ASCII 56354 26 DNS-UPDATE database opcode zone

Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]

 RFC1035 RFC3007 RFC4035 RFC4033 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2136 10.17487/RFC2136 RFC2137 Secure Domain Name System Dynamic Update D. Eastlake 3rd April 1997 ASCII 24824 11 SDNSDU DNS digital signatures cryptographic

This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [STANDARDS-TRACK]

 RFC3007 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2137 RFC2138 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens April 1997 ASCII 120407 65 RADIUS encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

 RFC2058 RFC2865 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2138 RFC2139 RADIUS Accounting C. Rigney April 1997 ASCII 44919 25 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2059 RFC2866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2139 RFC2140 TCP Control Block Interdependence J. Touch April 1997 ASCII 26032 11

This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2140 RFC2141 URN Syntax R. Moats May 1997 ASCII 14077 8 URN-SYNTAX Uniform Resource Names

Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2141 10.17487/RFC2141 RFC2142 Mailbox Names for Common Services, Roles and Functions D. Crocker May 1997 ASCII 12195 6 MAIL-SERV email internet addresses

This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2142 10.17487/RFC2142 RFC2143 Encapsulating IP with the Small Computer System Interface B. Elliston May 1997 ASCII 10749 5 IP-SCSI SCSI

This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2143 RFC2144 The CAST-128 Encryption Algorithm C. Adams May 1997 ASCII 37532 15 CAST-128

There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2144 RFC2145 Use and Interpretation of HTTP Version Numbers J. C. Mogul R. Fielding J. Gettys H. Frystyk May 1997 ASCII 13659 7

HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC7230 INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC2145 RFC2146 U.S. Government Internet Domain Names Federal Networking Council May 1997 ASCII 26564 12 Gov FED.US

This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain ".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2146 RFC2147 TCP and UDP over IPv6 Jumbograms D. Borman May 1997 ASCII 1883 3 IPv6-Jumbo User Datagram Protocol Terminal Control Internet

IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]

 RFC2675 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2147 RFC2148 Deployment of the Internet White Pages Service H. Alvestrand P. Jurg September 1997 ASCII 31539 15 X. 500 data structure naming scheme IWPS

This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0015 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2148 RFC2149 Multicast Server Architectures for MARS-based ATM multicasting R. Talpade M. Ammar May 1997 ASCII 42007 18

This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2149 RFC2150 Humanities and Arts: Sharing Center Stage on the Internet J. Max W. Stickle October 1997 ASCII 154037 62 informational infrastructure guide introduction

The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 FYI0031 INFORMATIONAL INFORMATIONAL IETF harts 10.17487/RFC2150 RFC2151 A Primer On Internet and TCP/IP Tools and Utilities G. Kessler S. Shepard June 1997 ASCII 114130 52 resource guide user

This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1739 FYI0030 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2151 RFC2152 UTF-7 A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis May 1997 ASCII 28065 15 UTF-7

This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, "Using Unicode with MIME". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1642 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2152 10.17487/RFC2152 RFC2153 PPP Vendor Extensions W. Simpson May 1997 ASCII 10780 6 PPP-EXT Point-to-Point Protocol

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC1661 RFC1962 RFC5342 RFC7042 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2153 RFC2154 OSPF with Digital Signatures S. Murphy M. Badger B. Wellington June 1997 ASCII 72701 29 OSPF-DIG

This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co-existence with, standard OSPF V2 is described. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2154 10.17487/RFC2154 RFC2155 Definitions of Managed Objects for APPN using SMIv2 B. Clouston B. Moore June 1997 ASCII 213809 124 APPN-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 monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

 RFC2455 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2155 RFC2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME S. Kille January 1998 ASCII 280385 144 MIXER multipurpose internet mail extensions message transfer protocol

This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK]

 RFC0987 RFC1026 RFC1138 RFC1148 RFC1327 RFC1495 RFC0822 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2156 RFC2157 Mapping between X.400 and RFC-822/MIME Message Bodies H. Alvestrand January 1998 ASCII 92554 49 mixer multipurpose internet mail extensions

This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer http://www.rfc-editor.org/errata_search.php?rfc=2157 10.17487/RFC2157 RFC2158 X.400 Image Body Parts H. Alvestrand January 1998 ASCII 5547 4 mixer multipurpose internet mail extensions

This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2158 RFC2159 A MIME Body Part for FAX H. Alvestrand January 1998 ASCII 11471 7 mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2159 RFC2160 Carrying PostScript in X.400 and MIME H. Alvestrand January 1998 ASCII 7059 5 mixer multipurpose internet mail extensions

This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2160 RFC2161 A MIME Body Part for ODA H. Alvestrand January 1998 ASCII 8009 5 MIME-ODA mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2161 RFC2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail C. Allocchio January 1998 ASCII 58553 34 MAP-MAIL mixer multipurpose internet mail extensions mime

The standard referred shortly into this document as "X.400" relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only. This memo defines an Experimental Protocol for the Internet community.

 RFC1405 EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2162 RFC2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) C. Allocchio January 1998 ASCII 58789 26 DNS-MCGAM mime internet enhanced Relay Multipurpose internet mail extensions x.400 mixer

This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]

 RFC1664 RFC3597 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2163 RFC2164 Use of an X.500/LDAP directory to support MIXER address mapping S. Kille January 1998 ASCII 16701 10 lightweight directory access protocol mime internet x,.400 enhanced relay

This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]

 RFC1838 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2164 RFC2165 Service Location Protocol J. Veizades E. Guttman C. Perkins S. Kaplan June 1997 ASCII 169889 72 SLP

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

 RFC2608 RFC2609 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC2165 RFC2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements D. Bryant P. Brittain June 1997 ASCII 75527 34

This document specifies a set of extensions to RFC 1795 designed to improve the scalability of DLSw clarifications to RFC 1795 in the light of the implementation experience to-date. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2166 RFC2167 Referral Whois (RWhois) Protocol V1.5 S. Williamson M. Kosters D. Blacka J. Singh K. Zeilstra June 1997 ASCII 136355 69 RWHOIS

This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1714 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2167 RFC2168 Resolution of Uniform Resource Identifiers using the Domain Name System R. Daniel M. Mealling June 1997 ASCII 46528 20

The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.

 RFC3401 RFC3402 RFC3403 RFC3404 RFC2915 EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2168 RFC2169 A Trivial Convention for using HTTP in URN Resolution R. Daniel June 1997 ASCII 17763 9

This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2169 RFC2170 Application REQuested IP over ATM (AREQUIPA) W. Almesberger J. Le Boudec P. Oechslin July 1997 ASCII 22874 10 Internet Protocol

This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2170 RFC2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1 K. Murakami M. Maruyama June 1997 ASCII 17480 9 MAPOS-SONET

This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2171 RFC2172 MAPOS Version 1 Assigned Numbers M. Maruyama K. Murakami June 1997 ASCII 4857 3

This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2172 RFC2173 A MAPOS version 1 Extension - Node Switch Protocol K. Murakami M. Maruyama June 1997 ASCII 12251 6

This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2173 RFC2174 A MAPOS version 1 Extension - Switch-Switch Protocol K. Murakami M. Maruyama June 1997 ASCII 47967 22

This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2174 RFC2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing K. Murakami M. Maruyama June 1997 ASCII 11677 6

This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2175 RFC2176 IPv4 over MAPOS Version 1 K. Murakami M. Maruyama June 1997 ASCII 12305 6 IPV4-MAPOS

This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2176 RFC2177 IMAP4 IDLE command B. Leiba June 1997 ASCII 6770 4 IMAP4-IDLE

This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2177 RFC2178 OSPF Version 2 J. Moy July 1997 ASCII 495866 211 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree.

OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. [STANDARDS-TRACK]

 RFC1583 RFC2328 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC2178 RFC2179 Network Security For Trade Shows A. Gwinn July 1997 ASCII 20690 10 network system attacks

This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2179 RFC2180 IMAP4 Multi-Accessed Mailbox Practice M. Gahrns July 1997 ASCII 24750 14 Internet Message Access Protocol Client Server

The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2180 RFC2181 Clarifications to the DNS Specification R. Elz R. Bush July 1997 ASCII 36989 14 DNS-CLAR Domain Name System

This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]

 RFC1034 RFC1035 RFC1123 RFC4035 RFC2535 RFC4343 RFC4033 RFC4034 RFC5452 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2181 RFC2182 Selection and Operation of Secondary DNS Servers R. Elz R. Bush S. Bradner M. Patton July 1997 ASCII 27456 11 Domain Name System delegated zone

This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 BCP0016 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2182 10.17487/RFC2182 RFC2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field R. Troost S. Dorner K. Moore Editor August 1997 ASCII 23150 12 inline attachment MIME Mail Multimedia EMail

This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK]

 RFC1806 RFC2184 RFC2231 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2183 10.17487/RFC2183 RFC2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore August 1997 ASCII 17635 9 mail Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]

 RFC2231 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2184 10.17487/RFC2184 RFC2185 Routing Aspects of IPv6 Transition R. Callon D. Haskin September 1997 ASCII 31281 13 address network tunneling

This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers." Readers should be familiar with the transition mechanisms before reading this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2185 RFC2186 Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII 18808 9 ICP www web http hypertext transfer protocol

This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2186 RFC2187 Application of Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII 51662 24 web www url uniform resource identifier

This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2187 RFC2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 M. Banan M. Taylor J. Cheng September 1997 ASCII 118374 57 ESRO RPC Remote Procedure Call Wireless

This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2188 RFC2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- A. Ballardie September 1997 ASCII 52043 23 Inter-Domain-Protocol IDMR

This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2189 RFC2190 RTP Payload Format for H.263 Video Streams C. Zhu September 1997 ASCII 26409 12 real-time transfer

This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rai avt 10.17487/RFC2190 RFC2191 VENUS - Very Extensive Non-Unicast Service G. Armitage September 1997 ASCII 31316 12 multicast IP ATM

This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service" (VENUS), and shows how complex such a service would be. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2191 RFC2192 IMAP URL Scheme C. Newman September 1997 ASCII 31426 16 IMAP-URL Internet Message Access Protocol Uniform Resource Identifiers

This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]

 RFC5092 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2192 10.17487/RFC2192 RFC2193 IMAP4 Mailbox Referrals M. Gahrns September 1997 ASCII 16248 9 IMAP4MAIL Internet Mail Access Protocol messages

Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2193 RFC2194 Review of Roaming Implementations B. Aboba J. Lu J. Alsop J. Ding W. Wang September 1997 ASCII 81533 35 ISP Internet Server Provider

This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2194 RFC2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede September 1997 ASCII 10468 5 IMAPPOPAU Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

 RFC2095 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2195 RFC2196 Site Security Handbook B. Fraser September 1997 ASCII 191772 75

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC1244 FYI0008 INFORMATIONAL INFORMATIONAL IETF ssh http://www.rfc-editor.org/errata_search.php?rfc=2196 10.17487/RFC2196 RFC2197 SMTP Service Extension for Command Pipelining N. Freed September 1997 ASCII 15003 8 SMTP-Pipe simple mail transfer TCP transmission control protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

 RFC1854 RFC2920 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2197 RFC2198 RTP Payload for Redundant Audio Data C. Perkins I. Kouvelas O. Hodson V. Hardman M. Handley J.C. Bolot A. Vega-Garcia S. Fosse-Parisis September 1997 ASCII 25166 11 RTP-RAD

This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]

 RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2198 RFC2199 Request for Comments Summary RFC Numbers 2100-2199 A. Ramos January 1998 ASCII 47664 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2199 RFC2200 Internet Official Protocol Standards J. Postel June 1997 ASCII 94506 39 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

 RFC1250 RFC2000 RFC2300 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2200 RFC2201 Core Based Trees (CBT) Multicast Routing Architecture A. Ballardie September 1997 ASCII 38040 15 IP Internet Protocol IDMR Inter-Domain

CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2201 RFC2202 Test Cases for HMAC-MD5 and HMAC-SHA-1 P. Cheng R. Glenn September 1997 ASCII 11945 9 Hash Message Authentications Codes message digest secure

This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2202 10.17487/RFC2202 RFC2203 RPCSEC_GSS Protocol Specification M. Eisler A. Chiu L. Ling September 1997 ASCII 50937 23 RPCSEC-GSS Remote Procedure Call Generic Security Services API Application Programming Interface

This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). [STANDARDS-TRACK]

 RFC5403 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc http://www.rfc-editor.org/errata_search.php?rfc=2203 10.17487/RFC2203 RFC2204 ODETTE File Transfer Protocol D. Nash September 1997 ASCII 151857 74 ODETTE FTP Internet Motor Industry data exchange

This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC5024 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2204 RFC2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification R. Braden Editor L. Zhang S. Berson S. Herzog S. Jamin September 1997 ASCII 223974 112 RSVP integrated services multicast unicast QoS signaling

This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]

 RFC2750 RFC3936 RFC4495 RFC5946 RFC6437 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2205 10.17487/RFC2205 RFC2206 RSVP Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII 112937 64 RSVP-MIB

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 the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2206 RFC2207 RSVP Extensions for IPSEC Data Flows L. Berger T. O'Malley September 1997 ASCII 30473 14 RSVP-IPSEC resource reservation QoS IP Security

This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2207 RFC2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment A. Mankin Editor F. Baker B. Braden S. Bradner M. O'Dell A. Romanow A. Weinrib L. Zhang September 1997 ASCII 14289 6 RSVP

This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv rsvp 10.17487/RFC2208 RFC2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules R. Braden L. Zhang September 1997 ASCII 51690 25 RSVP-MPR QoS implementation algorithms

This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2209 10.17487/RFC2209 RFC2210 The Use of RSVP with IETF Integrated Services J. Wroclawski September 1997 ASCII 77613 33 RSVP-IS Resource Reservation Controlled Load QOS: Quality of Service

This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2210 RFC2211 Specification of the Controlled-Load Network Element Service J. Wroclawski September 1997 ASCII 46523 19 QOS: Quality of Service integrated services

This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2211 RFC2212 Specification of Guaranteed Quality of Service S. Shenker C. Partridge R. Guerin September 1997 ASCII 52330 20 GQOS QOS quality of service integrated services

This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2212 RFC2213 Integrated Services Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII 36147 21 MIB

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 the the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv http://www.rfc-editor.org/errata_search.php?rfc=2213 10.17487/RFC2213 RFC2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII 15971 9 MIB attributes interface network protocol

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 the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2214 RFC2215 General Characterization Parameters for Integrated Service Network Elements S. Shenker J. Wroclawski September 1997 ASCII 39552 16 QOS Quality of service

This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2215 RFC2216 Network Element Service Specification Template S. Shenker J. Wroclawski September 1997 ASCII 53655 22 QOS Quality of Service Control

This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv intserv 10.17487/RFC2216 RFC2217 Telnet Com Port Control Option G. Clark October 1997 ASCII 31664 14 TOPT-COMPORT remote login host

This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2217 10.17487/RFC2217 RFC2218 A Common Schema for the Internet White Pages Service T. Genovese B. Jennings October 1997 ASCII 16258 8 IWPS information user

This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app ids 10.17487/RFC2218 RFC2219 Use of DNS Aliases for Network Services M. Hamilton R. Wright October 1997 ASCII 17858 8 domain name system symbolic

It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC- 1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0017 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2219 RFC2220 The Application/MARC Content-type R. Guenther October 1997 ASCII 7025 4 APP-MARC media-type machine readable cataloging records

This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2220 RFC2221 IMAP4 Login Referrals M. Gahrns October 1997 ASCII 9251 5 IMAP4LOGIN Internet Message Access Protocol server

When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2221 RFC2222 Simple Authentication and Security Layer (SASL) J. Myers October 1997 ASCII 35010 16 SASL encryption protocol specific

This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]

 RFC4422 RFC4752 RFC2444 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2222 10.17487/RFC2222 RFC2223 Instructions to RFC Authors J. Postel J. Reynolds October 1997 ASCII 37948 20 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1543 RFC1111 RFC0825 RFC7322 RFC5741 RFC6949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2223 RFC2224 NFS URL Scheme B. Callaghan October 1997 ASCII 22726 11 NFS-URL Universal Resource Locators Network File System syntax directories

A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, "Uniform Resource Locators (URL)". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2224 RFC2225 Classical IP and ARP over ATM M. Laubach J. Halpern April 1998 ASCII 65779 28 IP-ATM Internet protocol address resolution asynchronous,transfer mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

 RFC1626 RFC1577 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2225 RFC2226 IP Broadcast over ATM Networks T. Smith G. Armitage October 1997 ASCII 30661 14 Internet Protocol Asynchronous Transfer Mode

This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2226 RFC2227 Simple Hit-Metering and Usage-Limiting for HTTP J. Mogul P. Leach October 1997 ASCII 85127 37 Hypertext Transfer Protocol extension

This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2227 RFC2228 FTP Security Extensions M. Horowitz S. Lunt October 1997 ASCII 58733 27 FTPSECEXT file transfer protocol authentication encoding

This document defines extensions to the FTP specification STD 9, RFC

 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2228 RFC2229 A Dictionary Server Protocol R. Faith B. Martin October 1997 ASCII 59551 30 DSP DICT TCP Transmission Control Protocol database definitions

The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2229 10.17487/RFC2229 RFC2230 Key Exchange Delegation Record for the DNS R. Atkinson November 1997 ASCII 25563 11 KEYX-DNS Domain Name System RR Resource Record KX

This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2230 RFC2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore November 1997 ASCII 19280 10 MIME-EXT Mail Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]

 RFC2184 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2231 10.17487/RFC2231 RFC2232 Definitions of Managed Objects for DLUR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII 37955 21 DLUR-MIB Management Information Base MIB Dependent LU Requester APPN Advanced Peek to Peek Networking

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 monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2232 RFC2233 The Interfaces Group MIB using SMIv2 K. McCloghrie F. Kastenholz November 1997 ASCII 148033 66 INTERGRMIB Management Information Base Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK]

 RFC1573 RFC2863 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2233 RFC2234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell November 1997 ASCII 24265 14 ABNF Augmented Backus-Naur Form electronic mail

In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]

 RFC4234 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2234 10.17487/RFC2234 RFC2235 Hobbes' Internet Timeline R. Zakon November 1997 ASCII 43060 22 events technologies history

This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 FYI0032 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2235 RFC2236 Internet Group Management Protocol, Version 2 W. Fenner November 1997 ASCII 51048 24 IGMP IGMP multicast routing IP Internet Protocol

This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK]

 RFC1112 RFC3376 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2236 10.17487/RFC2236 RFC2237 Japanese Character Encoding for Internet Messages K. Tamaru November 1997 ASCII 11628 6 eletronic mail character set scheme

This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2237 RFC2238 Definitions of Managed Objects for HPR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII 65498 35 HPR-MIB MIB Management Information Base high performance routing

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 monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2238 RFC2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts November 1997 ASCII 80651 43 MAUS-MIB

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. [STANDARDS-TRACK]

 RFC2668 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2239 RFC2240 A Legal Basis for Domain Name Allocation O. Vaughan November 1997 ASCII 13602 7 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2352 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2240 RFC2241 DHCP Options for Novell Directory Services D. Provan November 1997 ASCII 8419 5 DHCP-NDS NDS

This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2241 10.17487/RFC2241 RFC2242 NetWare/IP Domain Name and Information R. Droms K. Fong November 1997 ASCII 10653 6 NETWAREIP DHCP

This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2242 RFC2243 OTP Extended Responses C. Metz November 1997 ASCII 19730 10 OTP-ER One Time Password

This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2243 RFC2244 ACAP -- Application Configuration Access Protocol C. Newman J. G. Myers November 1997 ASCII 154610 71 ACAP URL Uniform Resource Locator

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK]

 RFC6075 PROPOSED STANDARD PROPOSED STANDARD IETF app acap http://www.rfc-editor.org/errata_search.php?rfc=2244 10.17487/RFC2244 RFC2245 Anonymous SASL Mechanism C. Newman November 1997 ASCII 9974 5 SASL-ANON Simple Authentication Security Layer

As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. [STANDARDS-TRACK]

 RFC4505 PROPOSED STANDARD PROPOSED STANDARD IETF app acap 10.17487/RFC2245 RFC2246 The TLS Protocol Version 1.0 T. Dierks C. Allen January 1999 ASCII 170401 80 transport protocol layer authentication privacy

This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

 RFC4346 RFC3546 RFC5746 RFC6176 RFC7465 RFC7507 RFC7919 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2246 10.17487/RFC2246 RFC2247 Using Domains in LDAP/X.500 Distinguished Names S. Kille M. Wahl A. Grimstad R. Huber S. Sataluri January 1998 ASCII 12411 7 lightweight directory access protocol DNS Domain name system

This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]

 RFC4519 RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2247 RFC2248 Network Services Monitoring MIB N. Freed S. Kille January 1998 ASCII 34106 19 NSM-MIB Management Information Base SNMP Simple Network Management Protocol

This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]

 RFC1565 RFC2788 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2248 RFC2249 Mail Monitoring MIB N. Freed S. Kille January 1998 ASCII 52334 28 MAIL-MIB Management Information Base Message Transfer Agents

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [STANDARDS-TRACK]

 RFC1566 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2249 RFC2250 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal M. Civanlar January 1998 ASCII 34293 16 RTP-MPEG Real-Time Transport Protocol Audio System Streams

This memo describes a packetization scheme for MPEG video and audio streams. [STANDARDS-TRACK] The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2038 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2250 10.17487/RFC2250 RFC2251 Lightweight Directory Access Protocol (v3) M. Wahl T. Howes S. Kille December 1997 ASCII 114488 50 LDAPV3 LDAv3 x.500

The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

 RFC4510 RFC4511 RFC4513 RFC4512 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2251 RFC2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions M. Wahl A. Coulbeck T. Howes S. Kille December 1997 ASCII 60204 32 LDAP3-ATD LDAv3 x.500 syntax

This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]

 RFC4510 RFC4517 RFC4523 RFC4512 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2252 10.17487/RFC2252 RFC2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names M. Wahl S. Kille T. Howes December 1997 ASCII 18226 10 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

 RFC1779 RFC4510 RFC4514 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2253 10.17487/RFC2253 RFC2254 The String Representation of LDAP Search Filters T. Howes December 1997 ASCII 13511 8 STR-LDAP LDAPv3 x.500 ASN.1 string format

This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

 RFC1960 RFC4510 RFC4515 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2254 10.17487/RFC2254 RFC2255 The LDAP URL Format T. Howes M. Smith December 1997 ASCII 20685 10 LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]

 RFC1959 RFC4510 RFC4516 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2255 RFC2256 A Summary of the X.500(96) User Schema for use with LDAPv3 M. Wahl December 1997 ASCII 32377 20 Lightweight Directory Access Protocol syntax

This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS-TRACK]

 RFC4517 RFC4519 RFC4523 RFC4512 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2256 RFC2257 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen D. Francisco January 1998 ASCII 177452 80 AGENTX SNMP Simple Network Management Protocol MIB Information Base

This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]

 RFC2741 PROPOSED STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2257 RFC2258 Internet Nomenclator Project J. Ordille January 1998 ASCII 34871 15 Database Server CCSO Computer Communications Services Office

The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2258 RFC2259 Simple Nomenclator Query Protocol (SNQP) J. Elliott J. Ordille January 1998 ASCII 58508 30 SNQP Data Repositories Client Server

The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2259 RFC2260 Scalable Support for Multi-homed Multi-provider Connectivity T. Bates Y. Rekhter January 1998 ASCII 28085 12 ISP Internet Service Provider Routing

This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2260 10.17487/RFC2260 RFC2261 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 128036 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

 RFC2271 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2261 RFC2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 88254 39 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

 RFC2272 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2262 RFC2263 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII 143493 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

 RFC2273 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2263 RFC2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII 168759 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

 RFC2274 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2264 RFC2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII 77807 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

 RFC2275 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2265 RFC2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices J. Flick January 1998 ASCII 134027 56 MIB 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 network repeaters based on IEEE 802.12. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2266 RFC2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie January 1998 ASCII 21032 10 ISP Internet Service Provider Internet Protocol DOS

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2827 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2267 RFC2268 A Description of the RC2(r) Encryption Algorithm R. Rivest March 1998 ASCII 19048 11 RC2-ENCRP encryption secre key rsa

This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2268 10.17487/RFC2268 RFC2269 Using the MARS Model in non-ATM NBMA Networks G. Armitage January 1998 ASCII 12094 6 Asynchronous Transfer Mode Multicast Address Resolution Server IP Internet Protocol

This document is intended to state the obvious equivalences, and explain the less obvious implications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2269 RFC2270 Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart T. Bates R. Chandra E. Chen January 1998 ASCII 12063 6 Autonomous System BGP4 Border Gateway Protocol ISP Internet Service

With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2270 RFC2271 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 128227 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

 RFC2261 RFC2571 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2271 RFC2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 88445 39 SNMPv3 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

 RFC2262 RFC2572 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2272 RFC2273 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII 143754 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

 RFC2263 RFC2573 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2273 RFC2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII 168950 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

 RFC2264 RFC2574 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2274 RFC2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII 77998 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

 RFC2265 RFC2575 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2275 RFC2276 Architectural Principles of Uniform Resource Name Resolution K. Sollins January 1998 ASCII 64811 24 URCs URN URLs Uniform Resource Locators Characteristics

This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC3401 INFORMATIONAL INFORMATIONAL IETF app urn 10.17487/RFC2276 RFC2277 IETF Policy on Character Sets and Languages H. Alvestrand January 1998 ASCII 16622 9 charset

This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0018 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2277 10.17487/RFC2277 RFC2278 IANA Charset Registration Procedures N. Freed J. Postel January 1998 ASCII 18881 10 character set mime multipurpose internet mail extensions

MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2978 INFORMATIONAL BEST CURRENT PRACTICE Legacy 10.17487/RFC2278 RFC2279 UTF-8, a transformation format of ISO 10646 F. Yergeau January 1998 ASCII 21634 10 UTF-8 UCS Transformation Format

UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]

 RFC2044 RFC3629 DRAFT STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2279 RFC2280 Routing Policy Specification Language (RPSL) C. Alaettinoglu T. Bates E. Gerich D. Karrenberg D. Meyer M. Terpstra C. Villamizar January 1998 ASCII 114985 53 RPSL network operator AS autonomous system database

This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

 RFC2622 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2280 RFC2281 Cisco Hot Standby Router Protocol (HSRP) T. Li B. Cole P. Morton D. Li March 1998 ASCII 35161 17 HSRP

The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2281 10.17487/RFC2281 RFC2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 1998 ASCII 29852 14 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2027 RFC2727 INFORMATIONAL BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2282 RFC2283 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter February 1998 ASCII 18946 9 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

 RFC2858 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2283 RFC2284 PPP Extensible Authentication Protocol (EAP) L. Blunk J. Vollbrecht March 1998 ASCII 29452 15 PPP-EAP point-to-point authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. [STANDARDS-TRACK]

 RFC3748 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2284 RFC2285 Benchmarking Terminology for LAN Switching Devices R. Mandeville February 1998 ASCII 43130 25 local area network MAC Medium Access Control layer

This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2285 RFC2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128 J. Kapp February 1998 ASCII 11849 7 has authentication message IP Internet Protocol codes

This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2286 10.17487/RFC2286 RFC2287 Definitions of System-Level Managed Objects for Applications C. Krupczak J. Saperia February 1998 ASCII 98210 44 SLM-APP mib management information base

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 a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2287 RFC2288 Using Existing Bibliographic Identifiers as Uniform Resource Names C. Lynch C. Preston R. Daniel February 1998 ASCII 21628 10 URNs Syntax framework

This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2288 10.17487/RFC2288 RFC2289 A One-Time Password System N. Haller C. Metz P. Nesser M. Straw February 1998 ASCII 56495 25 ONE-PASS authentication OTP replay attach

This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS-TRACK]

 RFC1938 STD0061 INTERNET STANDARD DRAFT STANDARD IETF sec otp 10.17487/RFC2289 RFC2290 Mobile-IPv4 Configuration Option for PPP IPCP J. Solomon S. Glass February 1998 ASCII 39421 17 Internet protocol point-to-point control address

Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. [STANDARDS-TRACK]

 RFC2002 RFC2794 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2290 RFC2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web J. Slein F. Vitali E. Whitehead D. Durand February 1998 ASCII 44036 21 WWW remote editing locking mechanism

This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app webdav 10.17487/RFC2291 RFC2292 Advanced Sockets API for IPv6 W. Stevens M. Thomas February 1998 ASCII 152077 67 application program interface

The current document defines some the "advanced" features of the sockets API that are required for applications to take advantage of additional features of IPv6. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC3542 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2292 RFC2293 Representing Tables and Subtrees in the X.500 Directory S. Kille March 1998 ASCII 12539 8 SUBTABLE mapping distinguished name

This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. [STANDARDS-TRCK]

 RFC1837 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2293 RFC2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille March 1998 ASCII 22059 13 OR-ADD routing mapping dit

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK]

 RFC1836 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2294 RFC2295 Transparent Content Negotiation in HTTP K. Holtman A. Mutz March 1998 ASCII 125130 58 TCN-HTTP Hyper Text Transfer protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2295 RFC2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 K. Holtman A. Mutz March 1998 ASCII 26932 13 HTTP-RVSA Hyper Text Transfer protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2296 10.17487/RFC2296 RFC2297 Ipsilon's General Switch Management Protocol Specification Version 2.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall March 1998 ASCII 280484 109 GSMP gsmp atm asynchronous transfer mode

This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987]. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC1987 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2297 RFC2298 An Extensible Message Format for Message Disposition Notifications R. Fajman March 1998 ASCII 62059 28 EMF-MDN MDN media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK]

 RFC3798 PROPOSED STANDARD PROPOSED STANDARD IETF app receipt 10.17487/RFC2298 RFC2299 Request for Comments Summary A. Ramos January 1999 ASCII 51234 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2299 RFC2300 Internet Official Protocol Standards J. Postel May 1998 ASCII 128322 59 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

 RFC2200 RFC2400 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2300 RFC2301 File Format for Internet Fax L. McIntyre S. Zilles R. Buckley D. Venable G. Parsons J. Rafferty March 1998 ASCII 200525 77 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK]

 RFC3949 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2301 RFC2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty S. Zilles March 1998 ASCII 14375 8 TIFF Multipurpose Internet Mail extensions

This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]

 RFC3302 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2302 RFC2303 Minimal PSTN address format in Internet Mail C. Allocchio March 1998 ASCII 14625 8 MIN-PSTN e-mail service

This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]

 RFC3191 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2303 RFC2304 Minimal FAX address format in Internet Mail C. Allocchio March 1998 ASCII 13236 8 MINFAX-IM encoding facsimile e-mail

This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]

 RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2304 RFC2305 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing March 1998 ASCII 24624 13 SMFAX-IM data file format e-mail

This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]

 RFC3965 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2305 RFC2306 Tag Image File Format (TIFF) - F Profile for Facsimile G. Parsons J. Rafferty March 1998 ASCII 59358 25 file format storage

This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2306 RFC2307 An Approach for Using LDAP as a Network Information Service L. Howard March 1998 ASCII 41396 21 LDAP-NIS lightweight directory access protocol unix mapping

This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2307 10.17487/RFC2307 RFC2308 Negative Caching of DNS Queries (DNS NCACHE) M. Andrews March 1998 ASCII 41428 19 DNS-NCACHE Domain Name System negative

RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]

 RFC1034 RFC1035 RFC4035 RFC4033 RFC4034 RFC6604 RFC8020 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2308 10.17487/RFC2308 RFC2309 Recommendations on Queue Management and Congestion Avoidance in the Internet B. Braden D. Clark J. Crowcroft B. Davie S. Deering D. Estrin S. Floyd V. Jacobson G. Minshall C. Partridge L. Peterson K. Ramakrishnan S. Shenker J. Wroclawski L. Zhang April 1998 ASCII 38079 17 performance router deployment

This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC7567 RFC7141 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2309 RFC2310 The Safe Response Header Field K. Holtman April 1998 ASCII 8091 5 http hyper text transfer protocol

This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2310 RFC2311 S/MIME Version 2 Message Specification S. Dusse P. Hoffman B. Ramsdell L. Lundblade L. Repka March 1998 ASCII 70901 37 SMIME-MSG secure multipurpose internet mail extensions

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2311 RFC2312 S/MIME Version 2 Certificate Handling S. Dusse P. Hoffman B. Ramsdell J. Weinstein March 1998 ASCII 39829 20 SMIME-CERT secure multipurpose internet mail extensions

This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2312 RFC2313 PKCS #1: RSA Encryption Version 1.5 B. Kaliski March 1998 ASCII 37777 19 PKCS-1 data public key cryptosystem

This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2437 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2313 RFC2314 PKCS #10: Certification Request Syntax Version 1.5 B. Kaliski March 1998 ASCII 15814 8 PKCS-10 public key distinguished name encryption data

This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2986 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2314 RFC2315 PKCS #7: Cryptographic Message Syntax Version 1.5 B. Kaliski March 1998 ASCII 69679 32 PKCS-7 data authentication PEM privacy enhanced mail

This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2315 RFC2316 Report of the IAB Security Architecture Workshop S. Bellovin April 1998 ASCII 19733 9 Internet Board protocols tools

On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2316 RFC2317 Classless IN-ADDR.ARPA delegation H. Eidnes G. de Groot P. Vixie March 1998 ASCII 17744 10 routing mapping addresses zone files

This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0020 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2317 10.17487/RFC2317 RFC2318 The text/css Media Type H. Lie B. Bos C. Lilley March 1998 ASCII 7819 5 TEXT-CSS MIME multipurpose Internet mail extension

This memo provides information about the text/css Media Type. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2318 RFC2319 Ukrainian Character Set KOI8-U KOI8-U Working Group April 1998 ASCII 18042 9 KOI8-U encoding mail information resources

This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=2319 10.17487/RFC2319 RFC2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) M. Greene J. Luciani K. White T. Kuo April 1998 ASCII 102116 52 IPOA-MIB management information base internet protocol address resolution asynchronous transfer mode

The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2320 RFC2321 RITA -- The Reliable Internetwork Troubleshooting Agent A. Bressen April 1 1998 ASCII 12302 6 networking environments

A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2321 RFC2322 Management of IP numbers by peg-dhcp K. van den Hout A. Koopal R. van Mook April 1 1998 ASCII 12665 7 Internet Protocol HIP Hacking in progress

This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2322 RFC2323 IETF Identification and Security Guidelines A. Ramos April 1 1998 ASCII 9257 5 facial hairius extremis FHE

This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2323 RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) L. Masinter April 1 1998 ASCII 19610 10 controlling monitoring diagnosing

This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC7168 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2324 10.17487/RFC2324 RFC2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 M. Slavitch April 1 1998 ASCII 12726 8 MIB management information base coffee brewing

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2325 10.17487/RFC2325 RFC2326 Real Time Streaming Protocol (RTSP) H. Schulzrinne A. Rao R. Lanphier April 1998 ASCII 195010 92 RTSP audio video data delivery application level,

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over 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. [STANDARDS-TRACK]

 RFC7826 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2326 10.17487/RFC2326 RFC2327 SDP: Session Description Protocol M. Handley V. Jacobson April 1998 ASCII 87096 42 SDP mbone internet multicast backbone multimedia

This document 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. [STANDARDS-TRACK]

 RFC4566 RFC3266 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2327 10.17487/RFC2327 RFC2328 OSPF Version 2 J. Moy April 1998 ASCII 447367 244 OSPF2 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

 RFC2178 RFC5709 RFC6549 RFC6845 RFC6860 RFC7474 RFC8042 STD0054 INTERNET STANDARD INTERNET STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2328 10.17487/RFC2328 RFC2329 OSPF Standardization Report J. Moy April 1998 ASCII 15130 9 open shortest path first

This memo documents how the requirements for advancing a routing protocol to Full Standard have been met for OSPFv2. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC2329 RFC2330 Framework for IP Performance Metrics V. Paxson G. Almes J. Mahdavi M. Mathis May 1998 ASCII 94387 40 Internet Protocol measurement statistics

The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC7312 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC2330 RFC2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update M. Maher April 1998 ASCII 61119 26 UNI-SIG asynchronous transfer mode internet protocol

This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 to support IP over ATM environments as described in RFC 2225 and in RFC 2332. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2331 RFC2332 NBMA Next Hop Resolution Protocol (NHRP) J. Luciani D. Katz D. Piscitello B. Cole N. Doraswamy April 1998 ASCII 126978 52 NHRP internetworking layer address subnetwork multiprotocol non-broadcast multiple access

This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2332 RFC2333 NHRP Protocol Applicability Statement D. Cansever April 1998 ASCII 20164 9 next hop resolution protocol routing internet protocol

As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2333 RFC2334 Server Cache Synchronization Protocol (SCSP) J. Luciani G. Armitage J. Halpern N. Doraswamy April 1998 ASCII 98161 40 SCSP cache synchronization replication NBMA non broadcast multiple access

This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2334 10.17487/RFC2334 RFC2335 A Distributed NHRP Service Using SCSP J. Luciani April 1998 ASCII 14007 7 NHRP-SCSP next hop resolution protocol server cache sychronization protocol

This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2335 RFC2336 Classical IP and ARP over ATM to NHRP Transition J. Luciani July 1998 ASCII 10500 5

This document describes methods and procedures for the graceful transition from an ATMARP LIS to an NHRP LIS network model over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2336 RFC2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM D. Farinacci D. Meyer Y. Rekhter April 1998 ASCII 16357 8 internet protocol asynchronous transfer mode

This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2337 RFC2338 Virtual Router Redundancy Protocol S. Knight D. Weaver D. Whipple R. Hinden D. Mitzel P. Hunt P. Higginson M. Shand A. Lindem April 1998 ASCII 59871 27 VRRP vrrp lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]

 RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2338 RFC2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols The Internet Society Sun Microsystems May 1998 ASCII 10745 5 ISOC network file system internet engineering task force

This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2339 RFC2340 Nortel's Virtual Network Switching (VNS) Overview B. Jamoussi D. Jamieson D. Williston S. Gabe May 1998 ASCII 30731 14 routing packet switching multi-protocol

This document provides an overview of Virtual Network Switching (VNS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2340 RFC2341 Cisco Layer Two Forwarding (Protocol) "L2F" A. Valencia M. Littlewood T. Kolar May 1998 ASCII 66592 29 L2F tunneling dial-up network

This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind.

 HISTORIC HISTORIC Legacy 10.17487/RFC2341 RFC2342 IMAP4 Namespace M. Gahrns C. Newman May 1998 ASCII 19489 10 IMAP4NAME internet message access protocol mailbox

This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]

 RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2342 RFC2343 RTP Payload Format for Bundled MPEG M. Civanlar G. Cash B. Haskell May 1998 ASCII 16557 8 RTP-MPEG real-time transport protocol audio video

This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2343 RFC2344 Reverse Tunneling for Mobile IP G. Montenegro Editor May 1998 ASCII 39468 19 MOBILIPREV internet protocol extensions home foreign agent encapsulating delivery style

This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS-TRACK]

 RFC3024 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2344 RFC2345 Domain Names and Company Name Retrieval J. Klensin T. Wolf G. Oglesby May 1998 ASCII 29707 14 URL mapping service whois dns

This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2345 RFC2346 Making Postscript and PDF International J. Palme May 1998 ASCII 12382 6 portable document format document

Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world. North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2346 RFC2347 TFTP Option Extension G. Malkin A. Harkin May 1998 ASCII 13060 7 TFTP-Ext trivial file transfer booting client server

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. [STANDARDS-TRACK]

 RFC1782 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2347 10.17487/RFC2347 RFC2348 TFTP Blocksize Option G. Malkin A. Harkin May 1998 ASCII 9515 5 TFTP-Blk trivial file transfer booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

 RFC1783 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2348 RFC2349 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin May 1998 ASCII 7848 5 TFTP-Opt trivial file transfer booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes two TFTP options. [STANDARDS-TRACK]

 RFC1784 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2349 RFC2350 Expectations for Computer Security Incident Response N. Brownlee E. Guttman June 1998 ASCII 86545 38 CSIRT guidelines user BCP0021 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip http://www.rfc-editor.org/errata_search.php?rfc=2350 10.17487/RFC2350 RFC2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP A. Robert May 1998 ASCII 43440 23 internet protocol encapsulation transactional traffic messaging

This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2351 RFC2352 A Convention For Using Legal Names as Domain Names O. Vaughan May 1998 ASCII 16354 8 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2240 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2352 RFC2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document G. Dudley May 1998 ASCII 116972 48 internet protocol advanced peer-to-peer networking high performance routing

This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2353 RFC2354 Options for Repair of Streaming Media C. Perkins O. Hodson June 1998 ASCII 28876 12 packets UDP user datagram protocol

This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC2354 RFC2355 TN3270 Enhancements B. Kelly June 1998 ASCII 89394 38 TN3270E Telnet option client

This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK]

 RFC1647 RFC6270 DRAFT STANDARD DRAFT STANDARD IETF app tn3270e 10.17487/RFC2355 RFC2356 Sun's SKIP Firewall Traversal for Mobile IP G. Montenegro V. Gupta June 1998 ASCII 53198 24 Internet Protocol security traffic

The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2356 RFC2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols A. Mankin A. Romanow S. Bradner V. Paxson June 1998 ASCII 24130 11 internet engineering task force rmtp procedures

This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2357 RFC2358 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson June 1998 ASCII 87891 39 MIB Management Information Base 802.3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK]

 RFC1650 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2358 RFC2359 IMAP4 UIDPLUS extension J. Myers June 1998 ASCII 10862 6 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]

 RFC4315 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2359 RFC2360 Guide for Internet Standards Writers G. Scott June 1998 ASCII 47280 20 specification multiple implementations

This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0022 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF stdguide 10.17487/RFC2360 RFC2361 WAVE and AVI Codec Registries E. Fleischman June 1998 ASCII 97796 71 multimedia parameter audio video microsoft

The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2361 10.17487/RFC2361 RFC2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1998 ASCII 159833 66 PIM-SM] routing message type timers flags

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 RFC2117 RFC4601 RFC5059 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2362 10.17487/RFC2362 RFC2363 PPP Over FUNI G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII 22576 12 PPP-FUNI point-to-point protocol atm synchronous transfer mode frame user network interface

This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2363 RFC2364 PPP Over AAL5 G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII 23539 12 PPP-AAL point-to-point protocol link control network-layer authentication compression

This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2364 RFC2365 Administratively Scoped IP Multicast D. Meyer July 1998 ASCII 17770 8 internet protocol IPv4 ipv6 address classes

This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC2365 RFC2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene July 1998 ASCII 134312 76 MIB management information base asynchronous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks'. [STANDARDS-TRACK]

 RFC2417 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2366 RFC2367 PF_KEY Key Management API, Version 2 D. McDonald C. Metz B. Phan July 1998 ASCII 146754 68 IP internet protocol security application programming interface

A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2367 RFC2368 The mailto URL scheme P. Hoffman L. Masinter J. Zawinski July 1998 ASCII 16502 10 URLMAILTO uniform resource locator electronic mail addresses

This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]

 RFC6068 RFC1738 RFC1808 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2368 RFC2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields G. Neufeld J. Baer July 1998 ASCII 30853 15 uniform resource locator email header fields

The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2369 RFC2370 The OSPF Opaque LSA Option R. Coltun July 1998 ASCII 33789 15 OSPF-LSA] open shortest path first link state advertisement

This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]

 RFC5250 RFC3630 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2370 RFC2371 Transaction Internet Protocol Version 3.0 J. Lyon K. Evans J. Klein July 1998 ASCII 71399 31 TIPV3 TIP commit protocol electronic commerce

In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app tip 10.17487/RFC2371 RFC2372 Transaction Internet Protocol - Requirements and Supplemental Information K. Evans J. Klein J. Lyon July 1998 ASCII 53699 24 TIP commit protocol electronic commerce

This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app tip 10.17487/RFC2372 RFC2373 IP Version 6 Addressing Architecture R. Hinden S. Deering July 1998 ASCII 52526 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

 RFC1884 RFC3513 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2373 10.17487/RFC2373 RFC2374 An IPv6 Aggregatable Global Unicast Address Format R. Hinden M. O'Dell S. Deering July 1998 ASCII 25068 12 internet protocol architecture routing

This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]

 RFC2073 RFC3587 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2374 RFC2375 IPv6 Multicast Address Assignments R. Hinden S. Deering July 1998 ASCII 14356 8 internet protocol multicast scope value

This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2375 RFC2376 XML Media Types E. Whitehead M. Murata July 1998 ASCII 32143 15 extensible markup language web authority hypertext transfer protocol

This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC3023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2376 RFC2377 Naming Plan for Internet Directory-Enabled Applications A. Grimstad R. Huber S. Sataluri M. Wahl September 1998 ASCII 38274 18 x.500 applications iwps white pages service

Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC4519 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2377 RFC2378 The CCSO Nameserver (Ph) Architecture R. Hedberg P. Pomes September 1998 ASCII 38960 22 computing communications services office database

The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2378 RFC2379 RSVP over ATM Implementation Guidelines L. Berger August 1998 ASCII 15174 8 asynchronous transfer mode resource reservation protocol switched circuits

This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0024 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv issll 10.17487/RFC2379 RFC2380 RSVP over ATM Implementation Requirements L. Berger August 1998 ASCII 31234 14 resource reservation protocol asynchronous transfer mode switched circuits

This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2380 RFC2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM M. Garrett M. Borden August 1998 ASCII 107299 43 asynchronous transfer mode mapping traffic parameters

This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2381 RFC2382 A Framework for Integrated Services and RSVP over ATM E. Crawley Editor L. Berger S. Berson F. Baker M. Borden J. Krawczyk August 1998 ASCII 73865 30

This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2382 RFC2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version M. Suzuki August 1998 ASCII 99889 50 asynchronous transfer mode stream resource reservation

This document specifies an ATM-based protocol for communication between ST2+ agents. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2383 RFC2384 POP URL Scheme R. Gellens August 1998 ASCII 13649 8 POP-URL post office protocol uniform resource identifier string encapsulation

This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2384 10.17487/RFC2384 RFC2385 Protection of BGP Sessions via the TCP MD5 Signature Option A. Heffernan August 1998 ASCII 12315 6 border gateway protocol transmission control message digest algorithm

This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]

 RFC5925 RFC6691 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2385 10.17487/RFC2385 RFC2386 A Framework for QoS-based Routing in the Internet E. Crawley R. Nair B. Rajagopalan H. Sandick August 1998 ASCII 93459 37 quality of service interdomain intradomain

This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg qosr 10.17487/RFC2386 RFC2387 The MIME Multipart/Related Content-type E. Levinson August 1998 ASCII 18864 10 MIME-RELAT multipurpose internet mail extensions body parts media-type

This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

 RFC2112 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2387 10.17487/RFC2387 RFC2388 Returning Values from Forms: multipart/form-data L. Masinter August 1998 ASCII 16531 9 media-type multipurpose internet mail extensions

This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]

 RFC7578 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2388 10.17487/RFC2388 RFC2389 Feature negotiation mechanism for the File Transfer Protocol P. Hethmon R. Elz August 1998 ASCII 18536 9 FTP catalogue

This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. [STANDARDS-TRACK]

 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2389 RFC2390 Inverse Address Resolution Protocol T. Bradley C. Brown A. Malis September 1998 ASCII 20849 10 IARP iarp hardware frame relay

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

 RFC1293 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2390 RFC2391 Load Sharing using IP Network Address Translation (LSNAT) P. Srisuresh D. Gan August 1998 ASCII 44884 18 internet protocol datagram server

In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2391 10.17487/RFC2391 RFC2392 Content-ID and Message-ID Uniform Resource Locators E. Levinson August 1998 ASCII 11141 6 CIDMID-URL Hyper Text Markup Language URL MIME

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

 RFC2111 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2392 10.17487/RFC2392 RFC2393 IP Payload Compression Protocol (IPComp) A. Shacham R. Monsour R. Pereira M. Thomas December 1998 ASCII 20757 10 IPCOMP internet protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

 RFC3173 PROPOSED STANDARD PROPOSED STANDARD IETF int ippcp 10.17487/RFC2393 RFC2394 IP Payload Compression Using DEFLATE R. Pereira December 1998 ASCII 11053 6 internet protocol algorithm datagram format

This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ippcp 10.17487/RFC2394 RFC2395 IP Payload Compression Using LZS R. Friend R. Monsour December 1998 ASCII 14882 9 internet protocol algorithm datagram lossless

This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ippcp http://www.rfc-editor.org/errata_search.php?rfc=2395 10.17487/RFC2395 RFC2396 Uniform Resource Identifiers (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter August 1998 ASCII 83639 40 URI-GEN characters string absolute relative

This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK]

 RFC3986 RFC1808 RFC1738 RFC2732 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2396 10.17487/RFC2396 RFC2397 The "data" URL scheme L. Masinter August 1998 ASCII 9514 5 DATA-URL uniform resource identifiers media type

A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2397 10.17487/RFC2397 RFC2398 Some Testing Tools for TCP Implementors S. Parker C. Schmechel August 1998 ASCII 24107 15 transmission control protocol catalogue

This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 FYI0033 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2398 RFC2399 Request for Comments Summary A. Ramos January 1999 ASCII 45853 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2399 RFC2400 Internet Official Protocol Standards J. Postel J. Reynolds September 1998 ASCII 110969 47 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]

 RFC2300 RFC2500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2400 RFC2401 Security Architecture for the Internet Protocol S. Kent R. Atkinson November 1998 ASCII 168162 66 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer

This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]

 RFC1825 RFC4301 RFC3168 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2401 RFC2402 IP Authentication Header S. Kent R. Atkinson November 1998 ASCII 52831 22 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK]

 RFC1826 RFC4302 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2402 RFC2403 The Use of HMAC-MD5-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII 13578 7 ipsec authentication mechanism header security architecture

This memo describes the use of the HMAC algorithm in conjunction with the MD5 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2403 RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII 13089 7 ipsec authentication mechanism header security architecture payload

This memo describes the use of the HMAC algorithm in conjunction with the SHA-1 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2404 RFC2405 The ESP DES-CBC Cipher Algorithm With Explicit IV C. Madson N. Doraswamy November 1998 ASCII 20208 10 ESPDES-CBC ipsec payload security architecture encryption

This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2405 RFC2406 IP Encapsulating Security Payload (ESP) S. Kent R. Atkinson November 1998 ASCII 54202 22 ESP ipsec internet protocol encapsulating security ipv4 ipv6

The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]

 RFC1827 RFC4303 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2406 RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP D. Piper November 1998 ASCII 67878 32 ISAKMPSEC ipsec internet protocol security association key management

This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]

 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2407 10.17487/RFC2407 RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) D. Maughan M. Schertler M. Schneider J. Turner November 1998 ASCII 209175 86 ISAKMP ipsec cryptography authentication

This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK]

 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2408 RFC2409 The Internet Key Exchange (IKE) D. Harkins D. Carrel November 1998 ASCII 94949 41 IKE ipsec oakley authentication isakmp internet security key management

This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]

 RFC4306 RFC4109 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2409 RFC2410 The NULL Encryption Algorithm and Its Use With IPsec R. Glenn S. Kent November 1998 ASCII 11239 6 ipsec internet protocol security esp encapsulating payload

This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2410 10.17487/RFC2410 RFC2411 IP Security Document Roadmap R. Thayer N. Doraswamy R. Glenn November 1998 ASCII 22983 11 ipsec internet protocol privacy authentication

This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol. This memo provides information for the Internet community.

 RFC6071 INFORMATIONAL INFORMATIONAL IETF sec ipsec 10.17487/RFC2411 RFC2412 The OAKLEY Key Determination Protocol H. Orman November 1998 ASCII 118649 55 ipsec authentication crytographic secure scalable

This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2412 10.17487/RFC2412 RFC2413 Dublin Core Metadata for Resource Discovery S. Weibel J. Kunze C. Lagoze M. Wolf September 1998 ASCII 15501 8 workshop electronic librarians network

This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community.

 RFC5013 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2413 RFC2414 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge September 1998 ASCII 32019 14 TCP-WIN transmission control protocol

This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This memo defines an Experimental Protocol for the Internet community.

 RFC3390 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2414 RFC2415 Simulation Studies of Increased Initial TCP Window Size K. Poduri K. Nichols September 1998 ASCII 24205 11 transmission control protocol file transfer

This document covers some simulation studies of the effects of increasing the initial window size of TCP. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2415 RFC2416 When TCP Starts Up With Four Packets Into Only Three Buffers T. Shepard C. Partridge September 1998 ASCII 12663 7 transmission control protocol performance

This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2416 RFC2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene September 1998 ASCII 134862 76 MIB management information base asynchronous transfer mode

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. [STANDARDS-TRACK]

 RFC2366 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2417 10.17487/RFC2417 RFC2418 IETF Working Group Guidelines and Procedures S. Bradner September 1998 ASCII 62857 26 BCP WG escape clause procedures

This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1603 RFC3934 RFC7475 RFC7776 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson http://www.rfc-editor.org/errata_search.php?rfc=2418 10.17487/RFC2418 RFC2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis) K. Sklower G. Meyer September 1998 ASCII 24414 12 DESE-bis point-to-point protocol ecp control

This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

 RFC1969 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2419 RFC2420 The PPP Triple-DES Encryption Protocol (3DESE) H. Kummert September 1998 ASCII 16729 8 3DESE point-to-point protocol ecp control

This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2420 RFC2421 Voice Profile for Internet Mail - version 2 G. Vaudreuil G. Parsons September 1998 ASCII 123663 56 MIME-VP2 vpim messaging

This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]

 RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2421 10.17487/RFC2421 RFC2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII 10157 6 MIME-ADPCM multipurpose internet mail extensions audio

This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]

 RFC1911 RFC3802 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2422 RFC2423 VPIM Voice Message MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII 10729 6 MIME-VPIM multipurpose internet mail extensions profiles

This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]

 RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2423 RFC2424 Content Duration MIME Header Definition G. Vaudreuil G. Parsons September 1998 ASCII 7116 4 CONT-DUR multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]

 RFC3803 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2424 RFC2425 A MIME Content-Type for Directory Information T. Howes M. Smith F. Dawson September 1998 ASCII 64478 33 TXT-DIR multipurpose internet mail extensions profiles

This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]

 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2425 RFC2426 vCard MIME Directory Profile F. Dawson T. Howes September 1998 ASCII 74646 42 MIME-VCARD multipurpose internet mail extensions white-pages electronic business card

This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]

 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2426 10.17487/RFC2426 RFC2427 Multiprotocol Interconnect over Frame Relay C. Brown A. Malis September 1998 ASCII 74671 34 IP-FR standard standards IP over

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

 RFC1490 RFC1294 STD0055 INTERNET STANDARD INTERNET STANDARD IETF int ion 10.17487/RFC2427 RFC2428 FTP Extensions for IPv6 and NATs M. Allman S. Ostermann C. Metz September 1998 ASCII 16028 8 file transfer protocol internet network address translators

This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2428 RFC2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) C. Bormann L. Cline G. Deisher T. Gardos C. Maciocco D. Newell J. Ott G. Sullivan S. Wenger C. Zhu October 1998 ASCII 43166 17 real time transport protocol multicast unicast

This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]

 RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2429 RFC2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) T. Li Y. Rekhter October 1998 ASCII 40148 16 isp internet service provider packet flow multiprotocol label switching mpls resource reservation protocol rsvp

This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2430 RFC2431 RTP Payload Format for BT.656 Video Encoding D. Tynan October 1998 ASCII 22323 10 real time transport protocol itu multicast unicast

This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2431 RFC2432 Terminology for IP Multicast Benchmarking K. Dubray October 1998 ASCII 29758 16 internet protocol network forwarding devices

The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2432 RFC2433 Microsoft PPP CHAP Extensions G. Zorn S. Cobb October 1998 ASCII 34502 20 point to point protocol challenge handshake authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2433 RFC2434 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand October 1998 ASCII 25092 11 internet assigned numbers authority values implementations

This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC5226 RFC3692 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2434 RFC2435 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne P. Stewart October 1998 ASCII 54173 27 Real Time Transport Protocol Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK]

 RFC2035 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2435 10.17487/RFC2435 RFC2436 Collaboration between ISOC/IETF and ITU-T R. Brett S. Bradner G. Parsons October 1998 ASCII 31154 14 internet society engineering task force

This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.

 RFC3356 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2436 RFC2437 PKCS #1: RSA Cryptography Specifications Version 2.0 B. Kaliski J. Staddon October 1998 ASCII 73529 39 data public key cryptosystem

This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.

 RFC2313 RFC3447 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2437 RFC2438 Advancement of MIB specifications on the IETF Standards Track M. O'Dell H. Alvestrand B. Wijnen S. Bradner October 1998 ASCII 13633 7 management information base internet engineering task force

This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0027 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2438 RFC2439 BGP Route Flap Damping C. Villamizar R. Chandra R. Govindan November 1998 ASCII 86376 37 Border Gateway Protocol IDRP Internet-Domain Routing

A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2439 10.17487/RFC2439 RFC2440 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney R. Thayer November 1998 ASCII 141371 65 pretty good privacy encryption authentication

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]

 RFC4880 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp 10.17487/RFC2440 RFC2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998 D. Cohen November 1998 ASCII 11992 6 Jonathan B Postel

This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2441 RFC2442 The Batch SMTP Media Type N. Freed D. Newman J. Belissent M. Hoy November 1998 ASCII 18384 9 simple transfer protocol mime multipurpose internet mail extensions tunneling

This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport. This memo provides information for the Internet community

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2442 RFC2443 A Distributed MARS Service Using SCSP J. Luciani A. Gallo November 1998 ASCII 41451 18 MARS-SCSP server cache syncronization protocol atm asynchronous transfer mode

This document describes a method for distributing a MARS service within a LIS. This method uses the Server Cache Synchronization Protocol (SCSP) to synchronize the MARS Server databases within a LIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). [STANDARDS-TRACK]

 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2443 RFC2444 The One-Time-Password SASL Mechanism C. Newman October 1998 ASCII 13408 7 OTP-SASL otp simple authentication security layer

OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK]

 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2444 RFC2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar) F. Dawson D. Stenerson November 1998 ASCII 291838 148 ICALENDAR internet interoperable mime multipurpose mail extensions

This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]

 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2445 10.17487/RFC2445 RFC2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries S. Silverberg S. Mansour F. Dawson R. Hopson November 1998 ASCII 225964 109 ITIP internet systems interoperability

This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK]

 RFC5546 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2446 10.17487/RFC2446 RFC2447 iCalendar Message-Based Interoperability Protocol (iMIP) F. Dawson S. Mansour S. Silverberg November 1998 ASCII 33480 18 IMIP internet electronic mail transport

This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]

 RFC6047 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch 10.17487/RFC2447 RFC2448 AT&T's Error Resilient Video Transmission Technique M. Civanlar G. Cash B. Haskell November 1998 ASCII 14655 7 packets network bitstreams

This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2448 RFC2449 POP3 Extension Mechanism R. Gellens C. Newman L. Lundblade November 1998 ASCII 36017 19 POP3-EXT post office protocol server

This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]

 RFC1939 RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2449 RFC2450 Proposed TLA and NLA Assignment Rule R. Hinden December 1998 ASCII 24486 11 top-level aggregation identifiers next-level ipv6 internet protocols addresses

This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2450 RFC2451 The ESP CBC-Mode Cipher Algorithms R. Pereira R. Adams November 1998 ASCII 26400 14 ipsec encapsulating security payload

This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2451 RFC2452 IP Version 6 Management Information Base for the Transmission Control Protocol M. Daniele December 1998 ASCII 19066 10 mib internet protocol tcp ipv6

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

 RFC4022 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2452 RFC2453 RIP Version 2 G. Malkin November 1998 ASCII 98462 39 RIP2 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]

 RFC1723 RFC4822 STD0056 INTERNET STANDARD INTERNET STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=2453 10.17487/RFC2453 RFC2454 IP Version 6 Management Information Base for the User Datagram Protocol M. Daniele December 1998 ASCII 15862 9 mib internet protocol udp ipv6

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

 RFC4113 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2454 RFC2455 Definitions of Managed Objects for APPN B. Clouston B. Moore November 1998 ASCII 251061 140 APPN-MIB mib management information base advanced peer-to-peer networking

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 monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

 RFC2155 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2455 RFC2456 Definitions of Managed Objects for APPN TRAPS B. Clouston B. Moore November 1998 ASCII 44023 21 mib management information base advanced peer-to-peer networking

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 receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2456 RFC2457 Definitions of Managed Objects for Extended Border Node B. Clouston B. Moore November 1998 ASCII 54380 28 EBN-MIB mib management information base ebn

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 monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2457 RFC2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations H. Lu M. Krishnaswamy L. Conroy S. Bellovin F. Burg A. DeSimone K. Tewani P. Davidson H. Schulzrinne K. Vishwanathan November 1998 ASCII 139100 60

This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF tsv pint 10.17487/RFC2458 RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile R. Housley W. Ford W. Polk D. Solo January 1999 ASCII 278438 129 digital signatures encryption authentication

This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]

 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2459 10.17487/RFC2459 RFC2460 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1998 ASCII 85490 39 IPV6 internet protocol next generation ipng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

 draft-ietf-ipngwg-ipv6-spec-v2-02 RFC1883 RFC5095 RFC5722 RFC5871 RFC6437 RFC6564 RFC6935 RFC6946 RFC7045 RFC7112 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2460 10.17487/RFC2460 RFC2461 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson December 1998 ASCII 222516 93 IPV6-ND internet protocol link-layer

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

 RFC1970 RFC4861 RFC4311 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2461 RFC2462 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten December 1998 ASCII 61210 25 IPV6-AUTO internet protocol host link-local

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

 RFC1971 RFC4862 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2462 10.17487/RFC2462 RFC2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering December 1998 ASCII 34190 18 ICMPv6 internet protocol link-local autoconfigured addresses

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

 RFC1885 RFC4443 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2463 RFC2464 Transmission of IPv6 Packets over Ethernet Networks M. Crawford December 1998 ASCII 12725 7 internet protocol link-local autoconfigured addresses

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]

 RFC1972 RFC6085 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2464 10.17487/RFC2464 RFC2465 Management Information Base for IP Version 6: Textual Conventions and General Group D. Haskin S. Onishi December 1998 ASCII 77339 38 mib internet protocol ipv6

This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. [STANDARDS-TRACK]

 RFC4293 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2465 RFC2466 Management Information Base for IP Version 6: ICMPv6 Group D. Haskin S. Onishi December 1998 ASCII 27547 16 ICMPv6-MIB mib internet protocol ipv6

This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. [STANDARDS-TRACK]

 RFC4293 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2466 RFC2467 Transmission of IPv6 Packets over FDDI Networks M. Crawford December 1998 ASCII 16028 9 internet protocol link-local addresses autoconfiguration

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS-TRACK]

 RFC2019 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2467 RFC2468 I REMEMBER IANA V. Cerf October 1998 ASCII 8543 4 jonathan b postel

A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2468 RFC2469 A Caution On The Canonical Ordering Of Link-Layer Addresses T. Narten C. Burton December 1998 ASCII 9948 5 address resolution protocol data fields

Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2469 RFC2470 Transmission of IPv6 Packets over Token Ring Networks M. Crawford T. Narten S. Thomas December 1998 ASCII 21677 11 internet protocol frame format link-local addresses

This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2470 RFC2471 IPv6 Testing Address Allocation R. Hinden R. Fink J. Postel December 1998 ASCII 8031 5 internet protocol protocotype software architecture

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community.

 RFC1897 RFC3701 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC2471 RFC2472 IP Version 6 over PPP D. Haskin E. Allen December 1998 ASCII 29696 14 IPv6-PPP internet protocol point-to-point ipv6

This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. [STANDARDS-TRACK]

 draft-ietf-ipngwg-ipv6-over-ppp-06 RFC2023 RFC5072 RFC5172 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2472 RFC2473 Generic Packet Tunneling in IPv6 Specification A. Conta S. Deering December 1998 ASCII 77956 36 internet protocol encapsulation

This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2473 RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers K. Nichols S. Blake F. Baker D. Black December 1998 ASCII 50576 20 internet protocol network nodes

This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]

 RFC1455 RFC1349 RFC0791 RFC3168 RFC3260 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2474 10.17487/RFC2474 RFC2475 An Architecture for Differentiated Services S. Blake D. Black M. Carlson E. Davies Z. Wang W. Weiss December 1998 ASCII 94786 36 DIFFSRV] scalability IP internet protocol

This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.

 RFC3260 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2475 RFC2476 Message Submission R. Gellens J. Klensin December 1998 ASCII 30050 15 smtp simple mail transfer protocol user agent

This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]

 RFC4409 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2476 RFC2477 Criteria for Evaluating Roaming Protocols B. Aboba G. Zorn January 1999 ASCII 23530 12 ISP internet service providers operations

This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2477 RFC2478 The Simple and Protected GSS-API Negotiation Mechanism E. Baize D. Pinkas December 1998 ASCII 35581 18 generic service application security program interface

This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS-TRACK]

 RFC4178 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2478 RFC2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) C. Adams December 1998 ASCII 156070 70 data unit authentication

The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF sec cat 10.17487/RFC2479 RFC2480 Gateways and MIME Security Multiparts N. Freed January 1999 ASCII 11751 6 mutltipurpose internet mail extensions

This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2480 RFC2481 A Proposal to add Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd January 1999 ASCII 64559 25 ECN-IP internet protocol tcp transmission control transport

This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community.

 RFC3168 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2481 RFC2482 Language Tagging in Unicode Plain Text K. Whistler G. Adams January 1999 ASCII 27800 14 characters strings ASCII

This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.

 RFC6082 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2482 RFC2483 URI Resolution Services Necessary for URN Resolution M. Mealling R. Daniel January 1999 ASCII 30518 16 uniform resource identifier names locators characteristics

Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2483 RFC2484 PPP LCP Internationalization Configuration Option G. Zorn January 1999 ASCII 8330 5 point-to-point protocol link control authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]

 RFC2284 RFC1994 RFC1570 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2484 RFC2485 DHCP Option for The Open Group's User Authentication Protocol S. Drach January 1999 ASCII 7205 4 dynamic host configuration UAP

This document defines a DHCP option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2485 RFC2486 The Network Access Identifier B. Aboba M. Beadles January 1999 ASCII 14261 8 NAI tunneling roaming

This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]

 RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops http://www.rfc-editor.org/errata_search.php?rfc=2486 10.17487/RFC2486 RFC2487 SMTP Service Extension for Secure SMTP over TLS P. Hoffman January 1999 ASCII 15120 8 simple mail transfer protocol transport layer security ssl

This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

 RFC3207 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2487 RFC2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms M. Allman D. Glover L. Sanchez January 1999 ASCII 47857 19 transmission control protocol network

The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpsat 10.17487/RFC2488 RFC2489 Procedure for Defining New DHCP Options R. Droms January 1999 ASCII 10484 5 mutipurpose internet mail extensions

This document describes the procedure for defining new DHCP options. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2939 BCP0029 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2489 10.17487/RFC2489 RFC2490 A Simulation Model for IP Multicast with RSVP M. Pullen R. Malghan L. Lavu G. Duan J. Ma H. Nah January 1999 ASCII 74936 31 PS 1956365 PDF 135368 internet protocol resource reservation ipv4

This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2490 RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks G. Armitage P. Schulter M. Jork G. Harter January 1999 ASCII 100782 44 IPv6-NBMA internet protocol routing host

This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2491 RFC2492 IPv6 over ATM Networks G. Armitage P. Schulter M. Jork January 1999 ASCII 21199 12 IPv6ATMNET internet protocol asynchronous transfer mode host

This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2492 10.17487/RFC2492 RFC2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor January 1999 ASCII 18749 9 management information base data

This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. [STANDARDS-TRACK]

 RFC3593 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2493 RFC2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type D. Fowler Editor January 1999 ASCII 47208 25 management information base

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 used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2494 RFC2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types D. Fowler Editor January 1999 ASCII 155560 75 management information base

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 used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

 RFC1406 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2495 RFC2496 Definitions of Managed Object for the DS3/E3 Interface Type D. Fowler Editor January 1999 ASCII 124251 60 DS3-E3-MIB management information base

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 used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS1/E1/DS2/E2 (RFC 2495), and the work in progress SONET/SDH Interface Types. [STANDARDS-TRACK]

 RFC1407 RFC3896 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2496 RFC2497 Transmission of IPv6 Packets over ARCnet Networks I. Souvatzis January 1999 ASCII 10304 6 internet protocol frame format link-local

This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]

 draft-souvatzis-ipv6-arcnet-05 RFC1201 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2497 RFC2498 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson January 1999 ASCII 17869 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.

 RFC2678 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2498 RFC2499 Request for Comments Summary A. Ramos July 1999 ASCII 43431 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2499 RFC2500 Internet Official Protocol Standards J. Reynolds R. Braden June 1999 ASCII 78845 28 IAB official protocol standards

This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]

 RFC2400 RFC2600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2500 RFC2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations S. Corson J. Macker January 1999 ASCII 28912 12 MANET packet network hardwire wireless

This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC2501 RFC2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment M. Pullen M. Myjak C. Bouwens February 1999 ASCII 28190 11 IP DIS distributed applications

This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2502 RFC2503 MIME Types for Use with the ISO ILL Protocol R. Moulton M. Needleman February 1999 ASCII 9078 6 multipurpose mail internet extensions media type interlibrary loan

This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2503 RFC2504 Users' Security Handbook E. Guttman L. Leong G. Malkin February 1999 ASCII 74036 33 encryption networks systems

The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. This memo provides information for the Internet community.

 FYI0034 INFORMATIONAL INFORMATIONAL IETF ssh 10.17487/RFC2504 RFC2505 Anti-Spam Recommendations for SMTP MTAs G. Lindberg February 1999 ASCII 53597 24 simple mail transfer protocol agents sendmail

This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-lindberg-anti-spam-mta-08 BCP0030 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2505 RFC2506 Media Feature Tag Registration Procedure K. Holtman A. Mutz T. Hardie March 1999 ASCII 24892 12 data formats vocabulary negotiation mechanism

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-conneg-feature-reg-03 BCP0031 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app conneg 10.17487/RFC2506 RFC2507 IP Header Compression M. Degermark B. Nordgren S. Pink February 1999 ASCII 106292 47 internet protocol tcp transmission control bandwidth

This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2507 RFC2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links S. Casner V. Jacobson February 1999 ASCII 60474 24 internet protocol user datagram real-timetransport interoperability

This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2508 RFC2509 IP Header Compression over PPP M. Engan S. Casner C. Bormann February 1999 ASCII 18676 10 IPCOM-PPP internet protocol point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol. It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

 RFC3544 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2509 RFC2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols C. Adams S. Farrell March 1999 ASCII 158178 72 PKICMP pki security cryptographic authentication

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]

 draft-ietf-pkix-ipki3cmp-09 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2510 RFC2511 Internet X.509 Certificate Request Message Format M. Myers C. Adams D. Solo D. Kemp March 1999 ASCII 48278 25 X.509-CRMF crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]

 draft-ietf-pkix-crmf-01 RFC4211 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2511 RFC2512 Accounting Information for ATM Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII 29119 15 mib management information base autonomous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]

 draft-ietf-atommib-atmacct-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2512 RFC2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII 60789 29 mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]

 draft-ietf-atommib-acct-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2513 RFC2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management M. Noto E. Spiegel K. Tesink February 1999 ASCII 37583 20 ATM-TC-OID asynchronous transfer mode MIB management information base

This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

 draft-ietf-atommib-atm2TC-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2514 RFC2515 Definitions of Managed Objects for ATM Management K. Tesink Ed February 1999 ASCII 179993 87 ATM-MIBMAN asynchronous transfer mode MIB management information base

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 used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

 draft-ietf-atommib-atm1ng-06 RFC1695 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2515 RFC2516 A Method for Transmitting PPP Over Ethernet (PPPoE) L. Mamakos K. Lidl J. Evarts D. Carrel D. Simone R. Wheeler February 1999 ASCII 32537 17 PPPOE point-to-point protocol link control network layer

This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2516 10.17487/RFC2516 RFC2517 Building Directories from DNS: Experiences from WWWSeeker R. Moats R. Huber February 1999 ASCII 14001 7 domain name system internet world wide web

This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2517 RFC2518 HTTP Extensions for Distributed Authoring -- WEBDAV Y. Goland E. Whitehead A. Faizi S. Carter D. Jensen February 1999 ASCII 202829 94 WEBDAV hypertext transfer protocol web content

This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]

 RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=2518 10.17487/RFC2518 RFC2519 A Framework for Inter-Domain Route Aggregation E. Chen J. Stewart February 1999 ASCII 25394 13 IDRA bgp border gateway protocol address ip internet

This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This memo provides information for the Internet community

 draft-ietf-idr-aggregation-framework-04 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2519 RFC2520 NHRP with Mobile NHCs J. Luciani H. Suzuki N. Doraswamy D. Horton February 1999 ASCII 16763 8 NHRP-MNHCS next hop resolution protocol authentication extension

is document describes an extension to NHRP which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ion-nhrp-mobile-nhc-01 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2520 RFC2521 ICMP Security Failures Messages P. Karn W. Simpson March 1999 ASCII 14637 9 ICMP-SEC internet control message protocol ip

This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). This document defines an Experimental Protocol for the Internet community.

 draft-simpson-icmp-ipsec-fail-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2521 RFC2522 Photuris: Session-Key Management Protocol P. Karn W. Simpson March 1999 ASCII 157224 80 PHOTURIS-S ip internet protocol ah esp

This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.

 draft-simpson-photuris-18 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2522 RFC2523 Photuris: Extended Schemes and Attributes P. Karn W. Simpson March 1999 ASCII 38166 21 PHOTURIS-E ip internet protocol security

Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. This document defines an Experimental Protocol for the Internet community.

 draft-simpson-photuris-schemes-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2523 RFC2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3 M. Banan February 1999 ASCII 153171 83 EMSD wireless IP internet protocol

This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2524 RFC2525 Known TCP Implementation Problems V. Paxson M. Allman S. Dawson W. Fenner J. Griner I. Heavens K. Lahey J. Semke B. Volz March 1999 ASCII 137201 61 transmission control protocol

This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community.

 draft-ietf-tcpimpl-prob-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2525 RFC2526 Reserved IPv6 Subnet Anycast Addresses D. Johnson S. Deering March 1999 ASCII 14555 7 internet protocol routing architecture

This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. [STANDARDS-TRACK]

 draft-ietf-ipngwg-resv-anycast-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2526 RFC2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford March 1999 ASCII 91860 45 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. This memo provides information for the Internet community.

 draft-ietf-pkix-ipki-part4-03 RFC3647 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2527 10.17487/RFC2527 RFC2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates R. Housley W. Polk March 1999 ASCII 18273 9 security authentication cryptology

This specification contains guidance on the use of the Internet Public Key Infrastructure certificates to convey Key Exchange Algorithm (KEA) keys. This memo provides information for the Internet community.

 draft-ietf-pkix-ipki-kea-02 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC2528 RFC2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels B. Carpenter C. Jung March 1999 ASCII 21049 10 link-local link local addresses internet protocol ip

This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]

 draft-ietf-ipngwg-6over4-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2529 RFC2530 Indicating Supported Media Features Using Extensions to DSN and MDN D. Wing March 1999 ASCII 7824 5 message disposition notification delivery status

This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]

 draft-ietf-fax-reporting-extensions-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2530 RFC2531 Content Feature Schema for Internet Fax G. Klyne L. McIntyre March 1999 ASCII 88295 51 media features mechanism

This document defines a content feature schema that is a profile of the media feature registration mechanisms for use in performing capability identification between extended Internet fax systems. [STANDARDS-TRACK]

 draft-ietf-fax-feature-schema-05 RFC2879 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2531 RFC2532 Extended Facsimile Using Internet Mail L. Masinter D. Wing March 1999 ASCII 22717 12 mail user fax

This document describes extensions to "Simple Mode of Facsimile Using Internet Mail", and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK]

 draft-ietf-fax-eifax-12 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2532 RFC2533 A Syntax for Describing Media Feature Sets G. Klyne March 1999 ASCII 79057 37 message senders recipients file format

This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-syntax-04 RFC2738 RFC2938 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2533 RFC2534 Media Features for Display, Print, and Fax L. Masinter D. Wing A. Mutz K. Holtman March 1999 ASCII 15466 9 data format vocabulary negotiation mechanisms

This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. [STANDARDS-TRACK]

 draft-ietf-conneg-media-features-05 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2534 RFC2535 Domain Name System Security Extensions D. Eastlake 3rd March 1999 ASCII 110958 47 DNS-SECEXT dns authentication

This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]

 draft-ietf-dnssec-secext2-07 RFC2065 RFC4033 RFC4034 RFC4035 RFC2181 RFC1035 RFC1034 RFC2931 RFC3007 RFC3008 RFC3090 RFC3226 RFC3445 RFC3597 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2535 RFC2536 DSA KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII 11121 6 digital signature algorithm signatures cryptology

A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

 draft-ietf-dnssec-dss-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2536 RFC2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII 10810 6 message digest signatures cryptology security

A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

 draft-ietf-dnssec-rsa-01 RFC3110 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2537 RFC2538 Storing Certificates in the Domain Name System (DNS) D. Eastlake 3rd O. Gudmundsson March 1999 ASCII 19857 10 SC-DNS cryptology authenticity

Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

 draft-ietf-dnssec-certs-04 RFC4398 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2538 RFC2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII 21049 7 DHK-DNS cryptology authentication security signatures digital

A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK]

 draft-ietf-dnssec-dhk-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2539 RFC2540 Detached Domain Name System (DNS) Information D. Eastlake 3rd March 1999 ASCII 12546 6 DNS-INFO security digital signatures authentication

A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnssec-ddi-06 EXPERIMENTAL EXPERIMENTAL IETF sec dnssec 10.17487/RFC2540 RFC2541 DNS Security Operational Considerations D. Eastlake 3rd March 1999 ASCII 14498 7 DNS-SOC domain name system cryptology resource records rrs

This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. This memo provides information for the Internet community.

 draft-ietf-dnssec-secops-02 RFC4641 INFORMATIONAL INFORMATIONAL IETF sec dnssec 10.17487/RFC2541 RFC2542 Terminology and Goals for Internet Fax L. Masinter March 1999 ASCII 46372 20 real-time real time session store forward

This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. This memo provides information for the Internet community.

 draft-ietf-fax-goals-04 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2542 RFC2543 SIP: Session Initiation Protocol M. Handley H. Schulzrinne E. Schooler J. Rosenberg March 1999 ASCII 338861 151 SIP application-layer application layer multimedia multicast unicast

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. [STANDARDS-TRACK]

 draft-ietf-mmusic-sip-12 RFC3261 RFC3262 RFC3263 RFC3264 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC2543 RFC2544 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid March 1999 ASCII 66688 31 testing performance

This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community.

 RFC1944 RFC6201 RFC6815 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2544 10.17487/RFC2544 RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing P. Marques F. Dupont March 1999 ASCII 10209 5 border gateway protocol idr internet routing

BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2545 RFC2546 6Bone Routing Practice A. Durand B. Buclin March 1999 ASCII 17844 10 IPv6 internet protocol

This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community.

 draft-ietf-ngtrans-6bone-routing-01 RFC2772 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2546 RFC2547 BGP/MPLS VPNs E. Rosen Y. Rekhter March 1999 ASCII 63270 25 border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. This memo provides information for the Internet community.

 RFC4364 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2547 RFC2548 Microsoft Vendor-specific RADIUS Attributes G. Zorn March 1999 ASCII 80763 41 attributes remote access dialin user service dial-in

This document describes the set of Microsoft vendor-specific RADIUS attributes. This memo provides information for the Internet community.

 draft-ietf-radius-ms-vsa-01 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2548 10.17487/RFC2548 RFC2549 IP over Avian Carriers with Quality of Service D. Waitzman April 1 1999 ASCII 9519 6 avian carrier april fools qos

This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. This memo defines an Experimental Protocol for the Internet community.

 RFC1149 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2549 10.17487/RFC2549 RFC2550 Y10K and Beyond S. Glassman M. Manasse J. Mogul April 1 1999 ASCII 28011 14 years dates formats april fools

This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2550 RFC2551 The Roman Standards Process -- Revision III S. Bradner April 1 1999 ASCII 28054 37 numerals protocols procedures april fools

This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2551 RFC2552 Architecture for the Information Brokerage in the ACTS Project GAIA M. Blinov M. Bessonov C. Clissmann April 1999 ASCII 65172 30 electronic systems products

This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2552 RFC2553 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens March 1999 ASCII 89215 41 internet protocol api application program interface tcp transmission control

TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. This memo provides information for the Internet community.

 draft-ietf-ipngwg-bsd-api-new-06 RFC2133 RFC3493 RFC3152 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2553 RFC2554 SMTP Service Extension for Authentication J. Myers March 1999 ASCII 20534 11 simple mail transfer protocol security layer sasl

This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]

 draft-myers-smtp-auth-12 RFC4954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2554 RFC2555 30 Years of RFCs RFC Editor et al. April 1999 ASCII 42902 18 request for comments series documents publication

The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2555 RFC2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status S. Bradner March 1999 ASCII 5864 4 user datagram protocol ISO international organization for standardization

RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility This memo provides information for the Internet community.

 draft-bradner-1240.his-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2556 RFC2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann N. Shelness March 1999 ASCII 61854 28 MHTML multipurpose internet mail extensions multimedia uri uniform resource identifiers

This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK]

 draft-ietf-mhtml-rev-07 RFC2110 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2557 10.17487/RFC2557 RFC2558 Definitions of Managed Objects for the SONET/SDH Interface Type K. Tesink March 1999 ASCII 138550 74 MIB Management SNMP

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 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]

 draft-ietf-atommib-sonetng-05 RFC1595 RFC3592 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2558 RFC2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 S. Boeyen T. Howes P. Richard April 1999 ASCII 22889 13 X.500 LDAP lightweight directory protocol

Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]

 draft-ietf-pkix-ipki2opp-08 RFC3494 RFC1778 HISTORIC PROPOSED STANDARD IETF sec pkix 10.17487/RFC2559 RFC2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 1999 ASCII 43243 23 PKIX digital security

This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]

 draft-ietf-pkix-ocsp-07 RFC6960 RFC6277 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2560 10.17487/RFC2560 RFC2561 Base Definitions of Managed Objects for TN3270E Using SMIv2 K. White R. Moore April 1999 ASCII 113705 56 MIB management information base structure telnet

This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. [STANDARDS-TRACK]

 draft-ietf-tn3270e-tn3270-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2561 RFC2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) K. White R. Moore April 1999 ASCII 110633 49 TN2370E-RT-MIB MIB management information base structure telnet

This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. [STANDARDS-TRACK]

 draft-ietf-tn3270e-rt-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2562 RFC2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients R. Troll May 1999 ASCII 17838 9 dynamic host configuration protocol internet address

This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. [STANDARDS-TRACK]

 draft-ietf-dhc-autoconfig-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2563 RFC2564 Application Management MIB C. Kalbfleisch C. Krupczak R. Presuhn J. Saperia May 1999 ASCII 183314 86 APP-MIB management information base

This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. [STANDARDS-TRACK]

 draft-ietf-applmib-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2564 RFC2565 Internet Printing Protocol/1.0: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner April 1999 ASCII 80439 37 IPP-E-T IPP application media-type media type

This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines an Experimental protocol for the Internet community.

 draft-ietf-ipp-protocol-07 RFC2910 EXPERIMENTAL EXPERIMENTAL IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2565 10.17487/RFC2565 RFC2566 Internet Printing Protocol/1.0: Model and Semantics R. deBry T. Hastings R. Herriot S. Isaacson P. Powell April 1999 ASCII 438887 173 IPP-M-S IPP application media-type job

This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. This document also addresses security, internationalization, and directory issues. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-model-11 RFC2911 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2566 RFC2567 Design Goals for an Internet Printing Protocol F. Wright April 1999 ASCII 90260 43 IPP-DG IPP application media-type media type

This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-req-03 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2567 RFC2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol S. Zilles April 1999 ASCII 23547 10 IPP-RAT IPP application media-type media type

This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-rat-04 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2568 RFC2569 Mapping between LPD and IPP Protocols R. Herriot Editor T. Hastings N. Jacobs J. Martin April 1999 ASCII 57886 28 application media-type media type internet printing protocol line printer daemon

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-lpd-ipp-map-05 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2569 RFC2570 Introduction to Version 3 of the Internet-standard Network Management Framework J. Case R. Mundy D. Partain B. Stewart April 1999 ASCII 50381 23 snmp simple protocol

The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This memo provides information for the Internet community.

 draft-ietf-snmpv3-intro-04 RFC3410 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 10.17487/RFC2570 RFC2571 An Architecture for Describing SNMP Management Frameworks B. Wijnen D. Harrington R. Presuhn April 1999 ASCII 139260 62 ARCH-SNMP simple protocol network management

This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK]

 draft-ietf-snmpv3-arch-05 RFC2271 RFC3411 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2571 RFC2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen April 1999 ASCII 96035 44 MPD-SNMP processing models multiple

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

 RFC2272 RFC3412 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2572 RFC2573 SNMP Applications D. Levi P. Meyer B. Stewart April 1999 ASCII 150427 72 SNMP-APP simple network management protocol proxy operations command

This memo describes five types of SNMP applications which make use of an SNMP engine. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy fowarding. [STANDARDS-TRACK]

 draft-ietf-snmpv3-appl-v2-03 RFC2273 RFC3413 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2573 RFC2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen April 1999 ASCII 190755 86 USM-SNMPV3 message level mib information base

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

 draft-ietf-snmpv3-usm-v2-05 RFC2274 RFC3414 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2574 RFC2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie April 1999 ASCII 79642 38 VACM-SNMP mib information base

This document describes the View-based Access Control Model for use in the SNMP architecture (RFC2571). It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

 draft-ietf-snmpv3-vacm-04 RFC2275 RFC3415 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2575 RFC2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen March 2000 ASCII 98589 44 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

 draft-ietf-snmpv3-coex-08 RFC1908 RFC2089 RFC3584 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=2576 10.17487/RFC2576 RFC2577 FTP Security Considerations M. Allman S. Ostermann May 1999 ASCII 17870 8 FTP-SEC file transfer protocol bounce attack password server

This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. This memo provides information for the Internet community.

 draft-ietf-ftpext-sec-consider-02 INFORMATIONAL INFORMATIONAL IETF app ftpext 10.17487/RFC2577 RFC2578 Structure of Management Information Version 2 (SMIv2) K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII 89712 42 SMIv2 Simple Network Management Protocol Version 2

It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

 draft-ops-smiv2-smi-01 RFC1902 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2578 RFC2579 Textual Conventions for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII 59039 25 CONV-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

 draft-ops-smiv2-tc-01 RFC1903 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2579 10.17487/RFC2579 RFC2580 Conformance Statements for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII 54253 29 CONF-MIB simple Network Management Protocol Version 2

Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

 draft-ops-smiv2-conf-01 RFC1904 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2580 RFC2581 TCP Congestion Control M. Allman V. Paxson W. Stevens April 1999 ASCII 31351 14 TCP-CC

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. [STANDARDS-TRACK]

 draft-ietf-tcpimpl-cong-control-05 RFC2001 RFC5681 RFC3390 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpimpl http://www.rfc-editor.org/errata_search.php?rfc=2581 10.17487/RFC2581 RFC2582 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson April 1999 ASCII 29393 12 Transmission Control Protocol

This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpimpl-newreno-02 RFC3782 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2582 RFC2583 Guidelines for Next Hop Client (NHC) Developers R. Carlson L. Winkler May 1999 ASCII 21338 9 NHRP resolution protocol IP internet

This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community.

 draft-carlson-nhrp-03 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2583 RFC2584 Definitions of Managed Objects for APPN/HPR in IP Networks B. Clouston B. Moore May 1999 ASCII 40187 21 internet protocol MIB management information base high performance routing

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 monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. [STANDARDS-TRACK]

 draft-ietf-snanau-hpripmib-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2584 RFC2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP R. Housley P. Hoffman May 1999 ASCII 14813 8 file transfer hypertext PKI

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK]

 draft-ietf-pkix-opp-ftp-http-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2585 10.17487/RFC2585 RFC2586 The Audio/L16 MIME content type J. Salsman H. Alvestrand May 1999 ASCII 8694 5 AUDIO/L16 media-type application multipurpose internet mail extensions

This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community.

 draft-alvestrand-audio-l16-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2586 RFC2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema S. Boeyen T. Howes P. Richard June 1999 ASCII 15102 8 lightweight directory access protocol pkix

The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]

 draft-ietf-pkix-ldapv2-schema-02 RFC4523 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2587 RFC2588 IP Multicast and Firewalls R. Finlayson May 1999 ASCII 28622 12 Internet Protocol security gateway traffic

In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.

 draft-ietf-mboned-mcast-firewall-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC2588 RFC2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services Y. Yaacovi M. Wahl T. Genovese May 1999 ASCII 26855 12 LDAPv3 request response operations

This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]

 draft-ietf-asid-ldapv3-dynamic-08 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2589 RFC2590 Transmission of IPv6 Packets over Frame Relay Networks Specification A. Conta A. Malis M. Mueller May 1999 ASCII 41817 19 internet Protocol format link-local

This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]

 draft-ietf-ion-ipv6-fr-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2590 RFC2591 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder May 1999 ASCII 52920 25 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-disman-schedule-mib-06 RFC3231 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2591 RFC2592 Definitions of Managed Objects for the Delegation of Management Script D. Levi J. Schoenwaelder May 1999 ASCII 110629 53 mib information base

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 a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

 draft-ietf-disman-script-mib-08 RFC3165 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2592 RFC2593 Script MIB Extensibility Protocol Version 1.0 J. Schoenwaelder J. Quittek May 1999 ASCII 49663 22 management information base smx language specific

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. This memo defines an Experimental Protocol for the Internet community.

 draft-schoenw-smx-00 RFC3179 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2593 RFC2594 Definitions of Managed Objects for WWW Services H. Hazewinkel C. Kalbfleisch J. Schoenwaelder May 1999 ASCII 88876 43 management information base mib world wide web

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 a set of objects for managing World Wide Web (WWW) services. [STANDARDS-TRACK]

 draft-ietf-applmib-wwwmib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2594 RFC2595 Using TLS with IMAP, POP3 and ACAP C. Newman June 1999 ASCII 32440 15 application configuration access protocol post office internet message transport layer security

Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]

 draft-newman-tls-imappop-09 RFC4616 RFC7817 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2595 10.17487/RFC2595 RFC2596 Use of Language Codes in LDAP M. Wahl T. Howes May 1999 ASCII 17413 9 lightweight directory access protocol servers

This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]

 draft-ietf-ldapext-lang-01 RFC3866 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2596 RFC2597 Assured Forwarding PHB Group J. Heinanen F. Baker W. Weiss J. Wroclawski June 1999 ASCII 24068 11 per-hop-behaviour differentiated services af assumed forwarding

This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]

 draft-ietf-diffserv-af-06 RFC3260 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2597 10.17487/RFC2597 RFC2598 An Expedited Forwarding PHB V. Jacobson K. Nichols K. Poduri June 1999 ASCII 23656 11 per-hop-forwarding behavior differentiated services ef

The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. [STANDARDS-TRACK]

 draft-ietf-diffserv-phb-ef-02 RFC3246 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2598 10.17487/RFC2598 RFC2599 Request for Comments Summary RFC Numbers 2500-2599 A. DeLaCruz March 2000 ASCII 45845 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2599 RFC2600 Internet Official Protocol Standards J. Reynolds R. Braden March 2000 ASCII 86139 31 IAB official protocol standards

This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]

 RFC2500 RFC2700 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2600 RFC2601 ILMI-Based Server Discovery for ATMARP M. Davison June 1999 ASCII 11820 6 integrated local management interface asynchronous transfer mode address resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. [STANDARDS-TRACK]

 draft-ietf-ion-discov-atmarp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2601 RFC2602 ILMI-Based Server Discovery for MARS M. Davison June 1999 ASCII 12031 6 integrated local management interface asynchronous transfer mode address resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. [STANDARDS-TRACK]

 draft-ietf-ion-discov-mars-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2602 RFC2603 ILMI-Based Server Discovery for NHRP M. Davison June 1999 ASCII 11865 6 integrated local management interface next hop resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. [STANDARDS-TRACK]

 draft-ietf-ion-discov-nhrp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2603 RFC2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens June 1999 ASCII 65329 29 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

 draft-gellens-otasp-acap-01 RFC2636 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2604 RFC2605 Directory Server Monitoring MIB G. Mansfield S. Kille June 1999 ASCII 49166 26 management information base network services

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-madman-dsa-mib-1 RFC1567 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2605 RFC2606 Reserved Top Level DNS Names D. Eastlake 3rd A. Panitz June 1999 ASCII 8008 5 domain name system private

To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsind-test-tlds-13 RFC6761 BCP0032 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind 10.17487/RFC2606 RFC2607 Proxy Chaining and Policy Implementation in Roaming B. Aboba J. Vollbrecht June 1999 ASCII 33271 15 network access server identifier radius

This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community.

 draft-ietf-roamops-auth-10 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2607 RFC2608 Service Location Protocol, Version 2 E. Guttman C. Perkins J. Veizades M. Day June 1999 ASCII 129475 54 SLP network services

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

 draft-ietf-svrloc-protocol-v2-15 RFC2165 RFC3224 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc http://www.rfc-editor.org/errata_search.php?rfc=2608 10.17487/RFC2608 RFC2609 Service Templates and Service: Schemes E. Guttman C. Perkins J. Kempf June 1999 ASCII 72842 33 service location protocol slp url universal resource locator

This document describes a formal procedure for defining and standardizing new service types and attributes for use with the "service:" scheme. [STANDARDS-TRACK]

 draft-ietf-svrloc-service-scheme-14 RFC2165 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC2609 RFC2610 DHCP Options for Service Location Protocol C. Perkins E. Guttman June 1999 ASCII 10859 6 slp dynamic host configuration protocol

The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. [STANDARDS-TRACK]

 draft-ietf-dhc-slp-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2610 RFC2611 URN Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Faltstrom June 1999 ASCII 26916 14 uniform resource names namespaces syntax

This document lays out general definitions of and mechanisms for establishing URN "namespaces". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urn-nid-req-08 RFC3406 BCP0033 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn 10.17487/RFC2611 RFC2612 The CAST-256 Encryption Algorithm C. Adams J. Gilchrist June 1999 ASCII 37468 19 security cryptology

This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). This memo provides information for the Internet community.

 draft-adams-cast-256-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2612 RFC2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 R. Waterman B. Lahaye D. Romascanu S. Waldbusser June 1999 ASCII 88701 44 smon 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 remote network monitoring devices in switched networks environments. [STANDARDS-TRACK]

 draft-ietf-rmonmib-smon-07 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2613 RFC2614 An API for Service Location J. Kempf E. Guttman June 1999 ASCII 164002 91 slp application program interface

This document describes standardized APIs for SLP in C and Java. This memo provides information for the Internet community.

 draft-ietf-svrloc-api-09 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2614 RFC2615 PPP over SONET/SDH A. Malis W. Simpson June 1999 ASCII 18708 10 point-to-point protocol synchronous optical network digital heirarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS-TRACK]

 draft-ietf-pppext-pppoversonet-update-04 RFC1619 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2615 RFC2616 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach T. Berners-Lee June 1999 ASCII 422317 176 PS 5529857 PDF 550558 HTTP World Wide Web WWW hypermedia

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]

 draft-ietf-http-v11-spec-rev-06 RFC2068 RFC7230 RFC7231 RFC7232 RFC7233 RFC7234 RFC7235 RFC2817 RFC5785 RFC6266 RFC6585 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2616 10.17487/RFC2616 RFC2617 HTTP Authentication: Basic and Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler S. Lawrence P. Leach A. Luotonen L. Stewart June 1999 ASCII 77638 34 security encryption hypertext transfer protocol

This document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

 draft-ietf-http-authentication-03 RFC2069 RFC7235 RFC7615 RFC7616 RFC7617 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2617 10.17487/RFC2617 RFC2618 RADIUS Authentication Client MIB B. Aboba G. Zorn June 1999 ASCII 26889 14 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK]

 draft-ietf-radius-auth-clientmib-05 RFC4668 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2618 RFC2619 RADIUS Authentication Server MIB G. Zorn B. Aboba June 1999 ASCII 30464 16 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK]

 draft-ietf-radius-auth-servmib-05 RFC4669 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2619 RFC2620 RADIUS Accounting Client MIB B. Aboba G. Zorn June 1999 ASCII 23960 13 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS accounting client functions. This memo provides information for the Internet community.

 draft-ietf-radius-acc-clientmib-05 RFC4670 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2620 RFC2621 RADIUS Accounting Server MIB G. Zorn B. Aboba June 1999 ASCII 27768 15 management information base security remote access,dialin user service

This memo defines a set of extensions which instrument RADIUS accounting server functions. This memo provides information for the Internet community.

 draft-ietf-radius-acc-servmib-05 RFC4671 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2621 RFC2622 Routing Policy Specification Language (RPSL) C. Alaettinoglu C. Villamizar E. Gerich D. Kessens D. Meyer T. Bates D. Karrenberg M. Terpstra June 1999 ASCII 140811 69 RPSL internet policy hierarchy network configuration

RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

 draft-ietf-rps-rpsl-v2-03 RFC2280 RFC4012 RFC7909 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2622 RFC2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 M. Eisler June 1999 ASCII 42521 19 network file system remote procedure call architecture

This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. [STANDARDS-TRACK]

 draft-ietf-nfsv4-nfssec-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC2623 RFC2624 NFS Version 4 Design Considerations S. Shepler June 1999 ASCII 52891 22 network file system

This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. This memo provides information for the Internet community.

 draft-ietf-nfsv4-designconsider-03 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC2624 RFC2625 IP and ARP over Fibre Channel M. Rajagopal R. Bhagwat W. Rickard June 1999 ASCII 137741 63 internet protocal address resolution

The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK]

 draft-ietf-ipfc-fibre-channel-06 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc http://www.rfc-editor.org/errata_search.php?rfc=2625 10.17487/RFC2625 RFC2626 The Internet and the Millennium Problem (Year 2000) P. Nesser II June 1999 ASCII 547560 275 Y2K

The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. This memo provides information for the Internet community.

 draft-ietf-2000-issue-06 INFORMATIONAL INFORMATIONAL IETF ops 2000 http://www.rfc-editor.org/errata_search.php?rfc=2626 10.17487/RFC2626 RFC2627 Key Management for Multicast: Issues and Architectures D. Wallner E. Harder R. Agee June 1999 ASCII 59263 23 communication sessions net key rekey

This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.

 draft-wallner-key-arch-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2627 RFC2628 Simple Cryptographic Program Interface (Crypto API) V. Smyslov June 1999 ASCII 60070 30 application security

This document describes a simple Application Program Interface to cryptographic functions. This memo provides information for the Internet community.

 draft-smyslov-crypto-api-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2628 RFC2629 Writing I-Ds and RFCs using XML M. Rose June 1999 ASCII 48677 31 internet-drafts extensible markup language source format

This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.

 draft-mrose-writing-rfcs-02 RFC7749 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2629 RFC2630 Cryptographic Message Syntax R. Housley June 1999 ASCII 128599 60 encryption certificate key management

This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]

 draft-ietf-smime-cms-13 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2630 10.17487/RFC2630 RFC2631 Diffie-Hellman Key Agreement Method E. Rescorla June 1999 ASCII 25932 13 encryption management certificate

This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]

 draft-ietf-smime-x942-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2631 10.17487/RFC2631 RFC2632 S/MIME Version 3 Certificate Handling B. Ramsdell Editor June 1999 ASCII 27925 13 encryption certificate multipurpose internet mail extensions secure

S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]

 draft-ietf-smime-cert-08 RFC3850 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2632 RFC2633 S/MIME Version 3 Message Specification B. Ramsdell Editor June 1999 ASCII 67870 32 secure multipurpose internet mail extensions encryption

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]

 draft-ietf-smime-msg-08 RFC3851 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2633 10.17487/RFC2633 RFC2634 Enhanced Security Services for S/MIME P. Hoffman Editor June 1999 ASCII 131153 58 secure multipurpose internet mail extensions encryption

This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]

 draft-ietf-smime-ess-12 RFC5035 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2634 RFC2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) S. Hambridge A. Lunde June 1999 ASCII 44669 18 electronic mail email users administrators managers

This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. This memo provides information for the Internet community.

 draft-ietf-run-spew-08 FYI0035 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC2635 RFC2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens July 1999 ASCII 65288 29 PS 1120860 PDF 173655 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

 RFC2604 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2636 RFC2637 Point-to-Point Tunneling Protocol (PPTP) K. Hamzeh G. Pall W. Verthein J. Taarud W. Little G. Zorn July 1999 ASCII 132565 57 IP tunnel encapsulation

This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.

 draft-ietf-pppext-pptp-10 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2637 10.17487/RFC2637 RFC2638 A Two-bit Differentiated Services Architecture for the Internet K. Nichols V. Jacobson L. Zhang July 1999 ASCII 72785 26 PS 1610846 PDF 315195 IP internet protocol header packets

This document presents a differentiated services architecture for the internet. This memo provides information for the Internet community.

 draft-nichols-diff-svc-arch-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2638 RFC2639 Internet Printing Protocol/1.0: Implementer's Guide T. Hastings C. Manros July 1999 ASCII 145086 64 IPP client object

This document contains information that supplements the IPP Model and Semantics and the IPP Transport and Encoding documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. This memo provides information for the Internet community.

 draft-ietf-ipp-implementers-guide-01 RFC3196 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC2639 RFC2640 Internationalization of the File Transfer Protocol B. Curtin July 1999 ASCII 57204 27 ftp character sets languages

This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. [STANDARDS-TRACK]

 draft-ietf-ftpext-intl-ftp-06 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2640 RFC2641 Cabletron's VlanHello Protocol Specification Version 4 D. Hamilton D. Ruffen August 1999 ASCII 34686 17 ISMP inter switch message protocol switches

The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2641 RFC2642 Cabletron's VLS Protocol Specification L. Kane August 1999 ASCII 204347 95 Virtual LAN link ISMP inter switch message routing

VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2642 RFC2643 Cabletron's SecureFast VLAN Operational Model D. Ruffen T. Len J. Yanacek August 1999 ASCII 121786 60 SFVLAN switching data packets vitrual LANs

Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC2643 RFC2644 Changing the Default for Directed Broadcasts in Routers D. Senie August 1999 ASCII 6820 4 smurf amplifiers denial of service

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

 draft-senie-directed-broadcast-03 RFC1812 BCP0034 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2644 RFC2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses R. Gellens August 1999 ASCII 16302 9 ODMR-SMTP simple mail transfer protocol internet

This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]

 draft-gellens-on-demand-07 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2645 10.17487/RFC2645 RFC2646 The Text/Plain Format Parameter R. Gellens Editor August 1999 ASCII 29175 14 media type mime multipurpose internet mail extension

This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]

 draft-gellens-format-06 RFC3676 RFC2046 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2646 RFC2647 Benchmarking Terminology for Firewall Performance D. Newman August 1999 ASCII 45374 26 routers switches measurement

This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]

 draft-ietf-bmwg-secperf-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2647 RFC2648 A URN Namespace for IETF Documents R. Moats August 1999 ASCII 46826 30 uniform resource names internet engineering task force

This document proposes the "ietf" namespace, which consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor and the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences. [STANDARDS-TRACK]

 draft-ietf-urn-ietf-09 RFC6924 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2648 10.17487/RFC2648 RFC2649 An LDAP Control and Schema for Holding Operation Signatures B. Greenblatt P. Richard August 1999 ASCII 20470 10 lightweight directory access protocol client server

This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ldapext-sigops-04 EXPERIMENTAL EXPERIMENTAL IETF app ldapext 10.17487/RFC2649 RFC2650 Using RPSL in Practice D. Meyer J. Schmitz C. Orange M. Prior C. Alaettinoglu August 1999 ASCII 55272 26 routing policy specification language IRR internet routing registry configurations

This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). This memo provides information for the Internet community.

 draft-ietf-rps-appl-rpsl-06 INFORMATIONAL INFORMATIONAL IETF ops rps 10.17487/RFC2650 RFC2651 The Architecture of the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII 41933 19 CIP query routing database servers

This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK]

 draft-ietf-find-cip-arch-02 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2651 RFC2652 MIME Object Definitions for the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII 42464 22 multipurpose internet mail extensions database

This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK]

 draft-ietf-find-cip-mime-03 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2652 RFC2653 CIP Transport Protocols J. Allen P. Leach R. Hedberg August 1999 ASCII 22999 11 common indexing message formats

This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK]

 draft-ietf-find-cip-trans-01 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2653 RFC2654 A Tagged Index Object for use in the Common Indexing Protocol R. Hedberg B. Greenblatt R. Moats M. Wahl August 1999 ASCII 46739 24 CIP information servers database

This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-cip-tagged-07 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2654 RFC2655 CIP Index Object Format for SOIF Objects T. Hardie M. Bowman D. Hardy M. Schwartz D. Wessels August 1999 ASCII 34285 17 summary object interchange format common indexing protocol

This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-cip-soif-02 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2655 10.17487/RFC2655 RFC2656 Registration Procedures for SOIF Template Types T. Hardie August 1999 ASCII 17409 9 summary object interchange format stream

The registration procedure described in this document is specific to SOIF template types. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-soif-registry-00 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2656 10.17487/RFC2656 RFC2657 LDAPv2 Client vs. the Index Mesh R. Hedberg August 1999 ASCII 19251 12 lightweight directory access protocol CIP common indexing

LDAPv2 clients as implemented according to RFC 1777 have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-cip-ldapv2-02 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2657 RFC2658 RTP Payload Format for PureVoice(tm) Audio K. McKay August 1999 ASCII 21895 10 real-time transport protocol packet end-to-end

This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]

 draft-mckay-qcelp-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2658 RFC2659 Security Extensions For HTML E. Rescorla A. Schiffman August 1999 ASCII 8134 4 hyper-text markup language cryptology

This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-wts-shtml-05 EXPERIMENTAL EXPERIMENTAL IETF sec wts 10.17487/RFC2659 RFC2660 The Secure HyperText Transfer Protocol E. Rescorla A. Schiffman August 1999 ASCII 95645 45 WWW world wide web http authentication

This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-wts-shttp-06 EXPERIMENTAL EXPERIMENTAL IETF sec wts 10.17487/RFC2660 RFC2661 Layer Two Tunneling Protocol "L2TP" W. Townsley A. Valencia A. Rubens G. Pall G. Zorn B. Palter August 1999 ASCII 168150 80 L2TP ppp point-to-point protocol packets

This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]

 draft-ietf-pppext-l2tp-16 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2661 10.17487/RFC2661 RFC2662 Definitions of Managed Objects for the ADSL Lines G. Bathrick F. Ly August 1999 ASCII 247122 115 MIB management information base

This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]

 draft-ietf-adslmib-adsllinemib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC2662 RFC2663 IP Network Address Translator (NAT) Terminology and Considerations P. Srisuresh M. Holdrege August 1999 ASCII 72265 30 network address translator IP internet protocol addresses

This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community.

 draft-ietf-nat-terminology-03 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2663 10.17487/RFC2663 RFC2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions R. Plzak A. Wells E. Krol August 1999 ASCII 23640 11 documentation help information FAQ

This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. This memo provides information for the Internet community.

 draft-ietf-uswg-fyi4-bis-01 RFC1594 FYI0004 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC2664 RFC2665 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson August 1999 ASCII 110038 47 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-hubmib-etherif-mib-v2-04 RFC2358 RFC3635 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2665 RFC2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets J. Flick August 1999 ASCII 37699 18 mib management information base

This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. This memo provides information for the Internet community.

 draft-ietf-hubmib-ether-chipsets-02 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC2666 RFC2667 IP Tunnel MIB D. Thaler August 1999 ASCII 32770 16 internet protocol management information base

This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]

 draft-ietf-ifmib-tunnel-mib-06 RFC4087 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2667 RFC2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) A. Smith J. Flick K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts August 1999 ASCII 121843 56 MAU-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-hubmib-mau-mib-v2-04 RFC2239 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2668 RFC2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems M. St. Johns Editor August 1999 ASCII 112880 55 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

 draft-ietf-ipcdn-cable-device-mib-08 RFC4639 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2669 RFC2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces M. St. Johns Editor August 1999 ASCII 141077 72 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 a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. [STANDARDS-TRACK]

 draft-ietf-ipcdn-rf-interface-mib-07 RFC4546 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2670 RFC2671 Extension Mechanisms for DNS (EDNS0) P. Vixie August 1999 ASCII 15257 7 EDNS0 domain name system resource records opt

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]

 draft-ietf-dnsind-edns0-02 RFC6891 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2671 RFC2672 Non-Terminal DNS Name Redirection M. Crawford August 1999 ASCII 18321 9 domain name system dname resource records

This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]

 draft-ietf-dnsind-dname-03 RFC6672 RFC4592 RFC6604 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2672 RFC2673 Binary Labels in the Domain Name System M. Crawford August 1999 ASCII 12379 7 DNS data

This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]

 draft-ietf-dnsind-binary-labels-05 RFC6891 RFC1035 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2673 10.17487/RFC2673 RFC2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions E. Bell A. Smith P. Langille A. Rijhsinghani K. McCloghrie August 1999 ASCII 159971 86 MIB management information base local area network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK]

 draft-ietf-bridge-bridgemib-06 RFC4363 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC2674 RFC2675 IPv6 Jumbograms D. Borman S. Deering R. Hinden August 1999 ASCII 17320 9 internet protocol packet payload link

This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]

 draft-ietf-ipngwg-jumbograms-01 RFC2147 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2675 10.17487/RFC2675 RFC2676 QoS Routing Mechanisms and OSPF Extensions G. Apostolopoulos S. Kama D. Williams R. Guerin A. Orda T. Przygienda August 1999 ASCII 124563 50 quality of service open shortest path first routing

This memo describes extensions to the OSPF protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. This memo defines an Experimental Protocol for the Internet community.

 draft-guerin-qos-routing-ospf-05 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2676 10.17487/RFC2676 RFC2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) M. Greene J. Cucchiara J. Luciani August 1999 ASCII 129699 67 NHRP-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-ion-nhrp-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2677 RFC2678 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson September 1999 ASCII 18087 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]

 RFC2498 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2678 RFC2679 A One-way Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII 43542 20 internet protocol performance metrics packets

This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]

 draft-ietf-ippm-delay-07 RFC7679 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2679 10.17487/RFC2679 RFC2680 A One-way Packet Loss Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII 32266 15 internet protocol performance metrics

This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]

 draft-ietf-ippm-loss-07 RFC7680 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2680 10.17487/RFC2680 RFC2681 A Round-trip Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII 44357 20 internet protocol performance metrics packets

This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]

 draft-ietf-ippm-rt-delay-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2681 10.17487/RFC2681 RFC2682 Performance Issues in VC-Merge Capable ATM LSRs I. Widjaja A. Elwalid September 1999 ASCII 29491 12 asynchronous transfer mode routing

This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. This memo provides information for the Internet community.

 draft-widjaja-mpls-vc-merge-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2682 RFC2683 IMAP4 Implementation Recommendations B. Leiba September 1999 ASCII 56300 23 internet message access protocol clients servers

The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.

 draft-leiba-imap-implement-guide-10 RFC7162 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2683 10.17487/RFC2683 RFC2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 D. Grossman J. Heinanen September 1999 ASCII 51390 23 asynchronous,transfer mode multiplexing

This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK]

 draft-ietf-ion-multiprotocol-atm-04 RFC1483 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2684 RFC2685 Virtual Private Networks Identifier B. Fox B. Gleeson September 1999 ASCII 11168 6 VPNI IP internet protocol VPN

This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK]

 draft-ietf-ion-vpn-id-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2685 RFC2686 The Multi-Class Extension to Multi-Link PPP C. Bormann September 1999 ASCII 24192 11 point-to-point protocol encapsulation

This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

 draft-ietf-issll-isslow-mcml-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2686 RFC2687 PPP in a Real-time Oriented HDLC-like Framing C. Bormann September 1999 ASCII 28699 13 point-to-point protocol encapsulation high-level data link control

This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

 draft-ietf-issll-isslow-rtf-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2687 RFC2688 Integrated Services Mappings for Low Speed Networks S. Jackowski D. Putzolu E. Crawley B. Davie September 1999 ASCII 36685 16 controlled load guaranteed services

This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK]

 draft-ietf-issll-isslow-svcmap-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2688 RFC2689 Providing Integrated Services over Low-bitrate Links C. Bormann September 1999 ASCII 34345 14 asynchronous synchronous real-time

This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. This memo provides information for the Internet community.

 draft-ietf-issll-isslow-06 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2689 RFC2690 A Proposal for an MOU-Based ICANN Protocol Support Organization S. Bradner September 1999 ASCII 14221 8 pso memorandum of understanding internet corporation for assigned names and numbers

This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community.

 draft-ietf-poisson-mou-pso-00 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2690 RFC2691 A Memorandum of Understanding for an ICANN Protocol Support Organization S. Bradner September 1999 ASCII 18940 9 mou pso internet corporation for assigned names and numbers

This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers (ICANN). This memo provides information for the Internet community.

 draft-ietf-poisson-pso-mou-01 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2691 RFC2692 SPKI Requirements C. Ellison September 1999 ASCII 29569 14 SPKI simple public key infrastructure authentication

The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-spki-cert-req-03 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2692 RFC2693 SPKI Certificate Theory C. Ellison B. Frantz B. Lampson R. Rivest B. Thomas T. Ylonen September 1999 ASCII 96699 43 SPKI simple public key infrastructure authentication

This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-spki-cert-theory-05 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2693 RFC2694 DNS extensions to Network Address Translators (DNS_ALG) P. Srisuresh G. Tsirtsis P. Akkiraju A. Heffernan September 1999 ASCII 67720 29 domain name system NATs mapping

This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need. This memo provides information for the Internet community.

 draft-ietf-nat-dns-alg-04 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2694 RFC2695 Authentication Mechanisms for ONC RPC A. Chiu September 1999 ASCII 39286 18 remote procedure call open network computing

This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community.

 draft-ietf-oncrpc-auth-06 INFORMATIONAL INFORMATIONAL IETF tsv oncrpc 10.17487/RFC2695 RFC2696 LDAP Control Extension for Simple Paged Results Manipulation C. Weider A. Herron A. Anantha T. Howes September 1999 ASCII 12809 7 lightweight directory access protocol client server

This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community.

 draft-ietf-asid-ldapv3-simplepaged-03 INFORMATIONAL INFORMATIONAL IETF app ldapext 10.17487/RFC2696 RFC2697 A Single Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII 10309 6 srtcm stream ip internet protocol packet

This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

 draft-heinanen-diffserv-srtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2697 RFC2698 A Two Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII 9368 5 trTCM stream ip internet protocol packet

This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

 draft-heinanen-diffserv-trtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2698 RFC2699 Request for Comments Summary RFC Numbers 2600-2699 S. Ginoza May 2000 ASCII 42462 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2699 RFC2700 Internet Official Protocol Standards J. Reynolds R. Braden August 2000 ASCII 90213 32

This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS-TRACK]

 RFC2600 RFC2800 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2700 10.17487/RFC2700 RFC2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol G. Malkin September 1999 ASCII 17571 9 point-to-point POP presence RAS remote access server

This document specifies a standard way for Multi-link PPP to operate across multiple nodes. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2701 RFC2702 Requirements for Traffic Engineering Over MPLS D. Awduche J. Malcolm J. Agogbua M. O'Dell J. McManus September 1999 ASCII 68386 29 multiprotocol label switching

This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community.

 draft-ietf-mpls-traffic-eng-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=2702 10.17487/RFC2702 RFC2703 Protocol-independent Content Negotiation Framework G. Klyne September 1999 ASCII 42071 20 feature resource media syntax

This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. This memo provides information for the Internet community.

 draft-ietf-conneg-requirements-02 INFORMATIONAL INFORMATIONAL IETF app conneg 10.17487/RFC2703 RFC2704 The KeyNote Trust-Management System Version 2 M. Blaze J. Feigenbaum J. Ioannidis A. Keromytis September 1999 ASCII 79998 37 security policy maker system credentials

This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. This memo provides information for the Internet community.

 draft-blaze-ietf-trustmgt-keynote-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2704 RFC2705 Media Gateway Control Protocol (MGCP) Version 1.0 M. Arango A. Dugan I. Elliott C. Huitema S. Pickett October 1999 ASCII 304056 134 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. This memo provides information for the Internet community.

 draft-huitema-megaco-mgcp-v1-00 RFC3435 RFC3660 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2705 RFC2706 ECML v1: Field Names for E-Commerce D. Eastlake 3rd T. Goldstein October 1999 ASCII 26135 13 electronic commerce modeling language merchant site. web

A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. This memo provides information for the Internet community.

 draft-eastlake-ecom-fields-01 RFC3106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2706 RFC2707 Job Monitoring MIB - V1.0 R. Bergman T. Hastings S. Isaacson H. Lewis November 1999 ASCII 255685 114 management information base

This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This memo provides information for the Internet community.

 draft-ietf-printmib-job-monitor-08 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2707 RFC2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB R. Bergman November 1999 ASCII 57489 26 management information base

This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. This memo provides information for the Internet community.

 draft-ietf-printmib-job-protomap-04 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2708 RFC2709 Security Model with Tunnel-mode IPsec for NAT Domains P. Srisuresh October 1999 ASCII 24552 11 internet protocol network address translator

This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. This memo provides information for the Internet community.

 draft-ietf-nat-security-02 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2709 RFC2710 Multicast Listener Discovery (MLD) for IPv6 S. Deering W. Fenner B. Haberman October 1999 ASCII 46838 22 MLD-IPv6 internet protocol routher packets

This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]

 draft-ietf-ipngwg-mld-02 RFC3590 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2710 RFC2711 IPv6 Router Alert Option C. Partridge A. Jackson October 1999 ASCII 11973 6 internet protocol datagram routher hop-by-hop

This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]

 draft-ietf-ipngwg-ipv6router-alert-06 RFC6398 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2711 RFC2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) A. Medvinsky M. Hur October 1999 ASCII 13763 7 TLS authentication cryptography

This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS-TRACK]

 draft-ietf-tls-kerb-cipher-suites-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC2712 RFC2713 Schema for Representing Java(tm) Objects in an LDAP Directory V. Ryan S. Seligman R. Lee October 1999 ASCII 40745 21 lightweight directory access protocol

This document defines the schema for representing Java(tm) objects in an LDAP directory. This memo provides information for the Internet community.

 draft-ryan-java-schema-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2713 RFC2714 Schema for Representing CORBA Object References in an LDAP Directory V. Ryan R. Lee S. Seligman October 1999 ASCII 14709 10 lightweight directory access protocol

This document defines the schema for representing CORBA object references in an LDAP directory. This memo provides information for the Internet community.

 draft-ryan-corba-schema-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2714 RFC2715 Interoperability Rules for Multicast Routing Protocols D. Thaler October 1999 ASCII 49638 22 border router MBRs autonomous

The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. This memo provides information for the Internet community.

 draft-thaler-multicast-interop-03 INFORMATIONAL INFORMATIONAL IETF rtg idmr 10.17487/RFC2715 RFC2716 PPP EAP TLS Authentication Protocol B. Aboba D. Simon October 1999 ASCII 50108 24 point-to-point link control compression extensible transport level security

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pppext-eaptls-06 RFC5216 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2716 RFC2717 Registration Procedures for URL Scheme Names R. Petke I. King November 1999 ASCII 19780 10 uniform resource locator syntax semantics

This document defines the process by which new URL scheme names are registered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urlreg-procedures-08 RFC4395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urlreg 10.17487/RFC2717 RFC2718 Guidelines for new URL Schemes L. Masinter H. Alvestrand D. Zigmond R. Petke November 1999 ASCII 19208 10 uniform resource locator syntax semantics

This document provides guidelines for the definition of new URL schemes. This memo provides information for the Internet community.

 draft-ietf-urlreg-guide-05 RFC4395 INFORMATIONAL INFORMATIONAL IETF app urlreg 10.17487/RFC2718 RFC2719 Framework Architecture for Signaling Transport L. Ong I. Rytina M. Garcia H. Schwarzbauer L. Coene H. Lin I. Juhasz M. Holdrege C. Sharp October 1999 ASCII 48646 24 IP Internet Protocol gateway media circuit

This document defines an architecture framework and functional requirements for transport of signaling information over IP. This memo provides information for the Internet community.

 draft-ietf-sigtran-framework-arch-03 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC2719 RFC2720 Traffic Flow Measurement: Meter MIB N. Brownlee October 1999 ASCII 103781 55 management information base

This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. [STANDARDS-TRACK]

 draft-ietf-rtfm-meter-mib-11 RFC2064 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rtfm 10.17487/RFC2720 RFC2721 RTFM: Applicability Statement N. Brownlee October 1999 ASCII 21200 10 real-time traffic flow measurement

This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. This memo provides information for the Internet community.

 draft-ietf-rtfm-applicability-statement-04 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2721 RFC2722 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth October 1999 ASCII 114064 48 network meters data

This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. This memo provides information for the Internet community.

 draft-ietf-rtfm-architecture-08 RFC2063 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2722 RFC2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups N. Brownlee October 1999 ASCII 44406 22 simple ruleset RTFM real-time network measurement

This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. This memo provides information for the Internet community.

 draft-ietf-rtfm-ruleset-language-07 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2723 RFC2724 RTFM: New Attributes for Traffic Flow Measurement S. Handelman S. Stibler N. Brownlee G. Ruth October 1999 ASCII 37951 18 real-time network

This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rtfm-new-traffic-flow-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2724 RFC2725 Routing Policy System Security C. Villamizar C. Alaettinoglu D. Meyer S. Murphy December 1999 ASCII 101649 41 RPSL database registry authentication

The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. [STANDARDS-TRACK]

 draft-ietf-rps-auth-04 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2725 RFC2726 PGP Authentication for RIPE Database Updates J. Zsako December 1999 ASCII 22594 11 pretty good privacy security digital signatures

This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS-TRACK]

 draft-ietf-rps-dbsec-pgp-authent-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2726 RFC2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 2000 ASCII 33396 15 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-poisson-nomcom-v2-01 RFC2282 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2727 RFC2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal R. Panabaker S. Wegerif D. Zigmond November 1999 ASCII 49099 23 internet protocol IPVBI

This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS-TRACK]

 draft-ietf-ipvbi-nabts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipvbi 10.17487/RFC2728 RFC2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications P. Bagnall R. Briscoe A. Poppitt December 1999 ASCII 53322 27 LSMA dynamic protocol mapping

The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). This memo provides information for the Internet community.

 draft-ietf-lsma-requirements-04 INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2729 RFC2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) S. Hanna B. Patel M. Shah December 1999 ASCII 120341 53 MADCAP client server scope zone host

This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK]

 draft-ietf-malloc-madcap-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2730 RFC2731 Encoding Dublin Core Metadata in HTML J. Kunze December 1999 ASCII 42450 23 hypertext markup language xml extensible

The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.

 draft-kunze-dchtml-02 RFC5791 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2731 10.17487/RFC2731 RFC2732 Format for Literal IPv6 Addresses in URL's R. Hinden B. Carpenter L. Masinter December 1999 ASCII 7984 5 Internet protocol uniform resource identifier www world wide web

This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK]

 draft-ietf-ipngwg-url-literal-04 RFC3986 RFC2396 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2732 10.17487/RFC2732 RFC2733 An RTP Payload Format for Generic Forward Error Correction J. Rosenberg H. Schulzrinne December 1999 ASCII 53120 26 FEC real-time protocol stream

This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS-TRACK]

 draft-ietf-avt-fec-08 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2733 RFC2734 IPv4 over IEEE 1394 P. Johansson December 1999 ASCII 69314 29 internet protocol datagrams packet encapsulation ARP address resolution multicast

This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS-TRACK]

 draft-ietf-ip1394-ipv4-19 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2734 RFC2735 NHRP Support for Virtual Private Networks B. Fox B. Petri December 1999 ASCII 26451 12 next hop resolution protocol VPN addresses

The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address. This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. [STANDARDS-TRACK]

 draft-ietf-ion-nhrp-vpn-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2735 RFC2736 Guidelines for Writers of RTP Payload Format Specifications M. Handley C. Perkins December 1999 ASCII 24143 10 real-time transport protocol data types audio video codecs

This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-avt-rtp-format-guidelines-04 BCP0036 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC2736 RFC2737 Entity MIB (Version 2) K. McCloghrie A. Bierman December 1999 ASCII 125141 56 management information base SNMP simple network protocol

This memo defines a portion of the Management Information Base (M for use with network management protocols in the Internet communi In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

 draft-ietf-entmib-v2-06 RFC2037 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=2737 10.17487/RFC2737 RFC2738 Corrections to "A Syntax for Describing Media Feature Sets" G. Klyne December 1999 ASCII 8353 5 FEC real-time protocol stream

In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-syntax-er-00 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2738 RFC2739 Calendar Attributes for vCard and LDAP T. Small D. Hennessy F. Dawson January 2000 ASCII 25892 16 lightweight directory access protocol

This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]

 draft-ietf-calsch-locating-03 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch 10.17487/RFC2739 RFC2740 OSPF for IPv6 R. Coltun D. Ferguson J. Moy December 1999 ASCII 189810 80 internet protocol open shortest path first

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv6-08 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2740 10.17487/RFC2740 RFC2741 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen M. Ellison D. Francisco January 2000 ASCII 199867 91 SNMP simple network management

This memo defines a standardized framework for extensible SNMP agents. [STANDARDS-TRACK]

 draft-ietf-agentx-rfc-update-03 RFC2257 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2741 RFC2742 Definitions of Managed Objects for Extensible SNMP Agents L. Heintz S. Gudur M. Ellison January 2000 ASCII 36644 20 SNMP management information base simple network 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 describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. [STANDARDS-TRACK]

 draft-ietf-agentx-mib-05 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2742 RFC2743 Generic Security Service Application Program Interface Version 2, Update 1 J. Linn January 2000 ASCII 229418 101 GSS-API portability application authentication cryptology

This memo obsoletes [STANDARDS-TRACK]

 draft-ietf-cat-rfc2078bis-08 RFC2078 RFC5554 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2743 10.17487/RFC2743 RFC2744 Generic Security Service API Version 2 : C-bindings J. Wray January 2000 ASCII 218572 101 GSS-API cryptology authentication

This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC 2743. [STANDARDS-TRACK]

 draft-ietf-cat-gssv2-cbind-09 RFC1509 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2744 10.17487/RFC2744 RFC2745 RSVP Diagnostic Messages A. Terzis B. Braden S. Vincent L. Zhang January 2000 ASCII 52256 23 resource reservation protocol network management

This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]

 draft-ietf-rsvp-diagnostic-msgs-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2745 RFC2746 RSVP Operation Over IP Tunnels A. Terzis J. Krawczyk J. Wroclawski L. Zhang January 2000 ASCII 58094 25 resource reservation protocol internet

This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS-TRACK]

 draft-ietf-rsvp-tunnel-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2746 RFC2747 RSVP Cryptographic Authentication F. Baker B. Lindell M. Talwar January 2000 ASCII 49477 21 resource reservation protocol security

This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]

 draft-ietf-rsvp-md5-08 RFC3097 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2747 10.17487/RFC2747 RFC2748 The COPS (Common Open Policy Service) Protocol D. Durham Editor J. Boyle R. Cohen S. Herzog R. Rajan A. Sastry January 2000 ASCII 90906 38 COPS qos quality of service signaling

This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS-TRACK]

 draft-ietf-rap-cops-08 RFC4261 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2748 RFC2749 COPS usage for RSVP S. Herzog Editor J. Boyle R. Cohen D. Durham R. Rajan A. Sastry January 2000 ASCII 33477 17 common open policy resource reservation protocol

This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS-TRACK]

 draft-ietf-rap-cops-rsvp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2749 RFC2750 RSVP Extensions for Policy Control S. Herzog January 2000 ASCII 26379 13 resource reservation protocol admission

This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-ext-06 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2750 RFC2751 Signaled Preemption Priority Policy Element S. Herzog January 2000 ASCII 21451 12 RSVP COPS resource reservation protocol common open service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS-TRACK]

 draft-ietf-rap-signaled-priority-04 RFC3181 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2751 RFC2752 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog January 2000 ASCII 33954 17 resource reservation protocol admission authentication

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-identity-05 RFC3182 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2752 RFC2753 A Framework for Policy-based Admission Control R. Yavatkar D. Pendarakis R. Guerin January 2000 ASCII 49763 20

This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community.

 draft-ietf-rap-framework-03 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC2753 RFC2754 RPS IANA Issues C. Alaettinoglu C. Villamizar R. Govindan January 2000 ASCII 11582 7 internet assigned numbers authority routing policy specification system security

RPS Security requires certain RPSL objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA. This memo provides information for the Internet community.

 draft-ietf-rps-iana-02 RFC6254 HISTORIC INFORMATIONAL IETF ops rps 10.17487/RFC2754 RFC2755 Security Negotiation for WebNFS A. Chiu M. Eisler B. Callaghan January 2000 ASCII 23493 12 RSVP QOS resource reservation protocol quality of service

This document describes a protocol for a WebNFS client (RFC2054) to negotiate the desired security mechanism with a WebNFS server (RFC2055) before the WebNFS client falls back to the MOUNT v3 protocol (RFC1813). This document is provided so that people can write compatible implementations. This memo provides information for the Internet community.

 draft-chiu-network-wnfs-sec-nego-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2755 RFC2756 Hyper Text Caching Protocol (HTCP/0.0) P. Vixie D. Wessels January 2000 ASCII 32176 15 HTCP hypertext transfer protocol caches data

This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. This memo defines an Experimental Protocol for the Internet community.

 draft-vixie-htcp-proto-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2756 RFC2757 Long Thin Networks G. Montenegro S. Dawkins M. Kojo V. Magret N. Vaidya January 2000 ASCII 112988 46 wireless WAN wide area networks TCP transmission control protocol

Our goal is to identify a TCP that works for all users, including users of long thin networks. This memo provides information for the Internet community.

 draft-montenegro-pilc-ltn-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2757 RFC2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring K. White February 2000 ASCII 145581 71 MIB management information base SLAs

This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. This memo defines an Experimental Protocol for the Internet community.

 draft-white-slapm-mib-06 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2758 RFC2759 Microsoft PPP CHAP Extensions, Version 2 G. Zorn January 2000 ASCII 34178 20 point-to-point protocol challenge handshake authentication

This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1). This memo provides information for the Internet community.

 draft-ietf-pppext-mschap-v2-04 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2759 10.17487/RFC2759 RFC2760 Ongoing TCP Research Related to Satellites M. Allman Editor S. Dawkins D. Glover J. Griner D. Tran T. Henderson J. Heidemann J. Touch H. Kruse S. Ostermann K. Scott J. Semke February 2000 ASCII 111141 46 transmission control protocol bandwidth network links

This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. This memo provides information for the Internet community.

 draft-ietf-tcpsat-res-issues-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpsat 10.17487/RFC2760 RFC2761 Terminology for ATM Benchmarking J. Dunn C. Martin February 2000 ASCII 61219 32 asynchronous transfer mode performance

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. This memo provides information for the Internet community.

 draft-ietf-bmwg-atm-term-00 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2761 RFC2762 Sampling of the Group Membership in RTP J. Rosenberg H. Schulzrinne February 2000 ASCII 25796 12 real-time transport protocol packets

This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-avt-rtpsample-06 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2762 RFC2763 Dynamic Hostname Exchange Mechanism for IS-IS N. Shen H. Smit February 2000 ASCII 8593 5 intermediate system routers TLV

This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. This memo provides information for the Internet community.

 draft-ietf-isis-dyname-02 RFC5301 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=2763 10.17487/RFC2763 RFC2764 A Framework for IP Based Virtual Private Networks B. Gleeson A. Lin J. Heinanen G. Armitage A. Malis February 2000 ASCII 163215 62 VPN internet protocol backbone

This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.

 draft-gleeson-vpn-framework-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2764 10.17487/RFC2764 RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT) E. Nordmark February 2000 ASCII 59465 26 SIIT internet protocol control message IPv4 IPv6

This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS-TRACK]

 draft-ietf-ngtrans-siit-08 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2765 RFC2766 Network Address Translation - Protocol Translation (NAT-PT) G. Tsirtsis P. Srisuresh February 2000 ASCII 49836 21 NAT-PT IPv4 IPv6 internet

This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS-TRACK]

 draft-ietf-ngtrans-natpt-07 RFC4966 RFC3152 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2766 RFC2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) K. Tsuchiya H. Higuchi Y. Atarashi February 2000 ASCII 26402 13 IPv4 IPv6 internet protocol applications

This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. This memo provides information for the Internet community.

 draft-ietf-ngtrans-bis-00 RFC6535 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2767 RFC2768 Network Policy and Services: A Report of a Workshop on Middleware B. Aiken J. Strassner B. Carpenter I. Foster C. Lynch J. Mambretti R. Moore B. Teitelbaum February 2000 ASCII 81034 29 protocols internet applications

An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. This memo provides information for the Internet community.

 draft-aiken-middleware-reqndef-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2768 RFC2769 Routing Policy System Replication C. Villamizar C. Alaettinoglu R. Govindan D. Meyer February 2000 ASCII 95255 42 RPSL database language

This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. [STANDARDS-TRACK]

 draft-ietf-rps-dist-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2769 RFC2770 GLOP Addressing in 233/8 D. Meyer P. Lothberg February 2000 ASCII 8988 5 multicast allocation global

This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mboned-glop-addressing-02 RFC3180 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC2770 RFC2771 An Abstract API for Multicast Address Allocation R. Finlayson February 2000 ASCII 20954 11 application programming interfaces service

This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. This memo provides information for the Internet community.

 draft-ietf-malloc-api-07 INFORMATIONAL INFORMATIONAL IETF tsv malloc 10.17487/RFC2771 RFC2772 6Bone Backbone Routing Guidelines R. Rockell R. Fink February 2000 ASCII 28565 14 IP internet protocol routing

This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. This memo provides information for the Internet community.

 draft-ietf-ngtrans-harden-04 RFC2546 RFC3152 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2772 RFC2773 Encryption using KEA and SKIPJACK R. Housley P. Yee W. Nace February 2000 ASCII 20008 9 key exchange algorithm symmetric

This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October

 draft-ietf-cat-ftpkeasj-01 RFC0959 EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC2773 RFC2774 An HTTP Extension Framework H. Nielsen P. Leach S. Lawrence February 2000 ASCII 39719 20 hyper-text transfer protocol

This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. This memo defines an Experimental Protocol for the Internet community.

 draft-frystyk-http-extensions-03 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2774 RFC2775 Internet Transparency B. Carpenter February 2000 ASCII 42956 18 end-to-end network layer connectivity

This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.

 draft-carpenter-transparency-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2775 RFC2776 Multicast-Scope Zone Announcement Protocol (MZAP) M. Handley D. Thaler R. Kermode February 2000 ASCII 61628 27 MZAP packets addresses service location

This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. [STANDARDS-TRACK]

 draft-ietf-mboned-mzap-06 HISTORIC PROPOSED STANDARD IETF ops mboned 10.17487/RFC2776 RFC2777 Publicly Verifiable Nomcom Random Selection D. Eastlake 3rd February 2000 ASCII 30064 16 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. This memo provides information for the Internet community.

 draft-eastlake-selection-04 RFC3797 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2777 RFC2778 A Model for Presence and Instant Messaging M. Day J. Rosenberg H. Sugano February 2000 ASCII 35153 17 service users MIME multipurpose Internet mail extensions

This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. This memo provides information for the Internet community.

 draft-ietf-impp-model-03 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2778 RFC2779 Instant Messaging / Presence Protocol Requirements M. Day S. Aggarwal G. Mohr J. Vincent February 2000 ASCII 47420 26 MIME multipurpose Internet mail extensions service users

This document defines a minimal set of requirements that IMPP must meet. This memo provides information for the Internet community.

 draft-ietf-impp-reqts-04 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2779 RFC2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers S. Bradner V. Paxson March 2000 ASCII 18954 10 internet assigned numbers authority IP

This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bradner-iana-allocation-05 RFC4443 RFC5237 RFC5771 RFC6335 RFC7045 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2780 RFC2781 UTF-16, an encoding of ISO 10646 P. Hoffman F. Yergeau February 2000 ASCII 29870 14 unicode character data code point

This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community.

 draft-hoffman-utf16-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2781 RFC2782 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie L. Esibov February 2000 ASCII 24013 12 DNS-SRV domain name system resource record

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]

 draft-ietf-dnsind-rfc2052bis-05 RFC2052 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=2782 10.17487/RFC2782 RFC2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 J. Mogul D. Mills J. Brittenson J. Stone U. Windl March 2000 ASCII 61421 31 NTP time clock synchronization

RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. This memo provides information for the Internet community.

 draft-mogul-pps-api-06 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2783 RFC2784 Generic Routing Encapsulation (GRE) D. Farinacci T. Li S. Hanks D. Meyer P. Traina March 2000 ASCII 16627 9 GRE packet size payload

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]

 draft-meyer-gre-update-03 RFC2890 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2784 10.17487/RFC2784 RFC2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME R. Zuccherato March 2000 ASCII 24415 11 security multipurpose internet mail extensions

This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community.

 draft-ietf-smime-small-subgroup-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC2785 RFC2786 Diffie-Helman USM Key Management Information Base and Textual Convention M. St. Johns March 2000 ASCII 43280 20 mib security user-based model Hellman

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community.

 draft-stjohns-snmpv3-dhkeychange-mib-02 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2786 10.17487/RFC2786 RFC2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol B. Jewell D. Chuang March 2000 ASCII 56672 31 management information base

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP). [STANDARDS-TRACK]

 draft-ietf-vrrp-mib-09 RFC6527 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2787 RFC2788 Network Services Monitoring MIB N. Freed S. Kille March 2000 ASCII 43906 22 management information base

This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS-TRACK]

 draft-ietf-madman-netsm-mib-07 RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2788 RFC2789 Mail Monitoring MIB N. Freed S. Kille March 2000 ASCII 65671 33 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [STANDARDS-TRACK]

 draft-ietf-madman-email-mib-06 RFC2249 RFC1566 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2789 RFC2790 Host Resources MIB S. Waldbusser P. Grillo March 2000 ASCII 95807 50 management information base

This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]

 draft-ops-hostmib-01 RFC1514 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2790 RFC2791 Scalable Routing Design Principles J. Yu July 2000 ASCII 63416 26 network packets

This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. This memo provides information for the Internet community.

 draft-yu-routing-scaling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2791 RFC2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System M. Blaze J. Ioannidis A. Keromytis March 2000 ASCII 13461 7 cryptology digial signatures

This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community.

 draft-angelos-keynote-dsa-rsa-encoding-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2792 RFC2793 RTP Payload for Text Conversation G. Hellstrom May 2000 ASCII 20674 10 real-time applications video audio packets

This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-text-05 RFC4103 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2793 RFC2794 Mobile IP Network Access Identifier Extension for IPv4 P. Calhoun C. Perkins March 2000 ASCII 16960 9 internet protocol NAI

Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. [STANDARDS-TRACK]

 draft-ietf-mobileip-mn-nai-07 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2794 RFC2795 The Infinite Monkey Protocol Suite (IMPS) S. Christey April 1 2000 ASCII 42902 20 control packet client

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. This memo provides information for the Internet community.

 draft-christey-imps-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2795 RFC2796 BGP Route Reflection - An Alternative to Full Mesh IBGP T. Bates R. Chandra E. Chen April 2000 ASCII 20174 11 border gateway protocol

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. [STANDARDS-TRACK]

 draft-ietf-idr-route-reflect-v2-03 RFC4456 RFC1966 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2796 RFC2797 Certificate Management Messages over CMS M. Myers X. Liu J. Schaad J. Weinstein April 2000 ASCII 103357 47 certificate management protocol cryptology syntax

This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS-TRACK]

 draft-ietf-pkix-cmc-05 RFC5272 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2797 10.17487/RFC2797 RFC2798 Definition of the inetOrgPerson LDAP Object Class M. Smith April 2000 ASCII 32929 20 lightweight directory access protocol directory services

We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. This memo provides information for the Internet community.

 draft-smith-ldap-inetorgperson-03 RFC3698 RFC4519 RFC4524 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2798 RFC2799 Request for Comments Summary RFC Numbers 2700-2799 S. Ginoza September 2000 ASCII 42622 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2799 RFC2800 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza May 2001 ASCII 101648 38

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS-TRACK]

 RFC2700 RFC2900 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2800 RFC2801 Internet Open Trading Protocol - IOTP Version 1.0 D. Burdett April 2000 ASCII 598794 290 commerce payment system merchant

This document discusses the Internet Open Trading Protocol (IOTP) and its provision of an interoperable framework for Internet commerce. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-protocol-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2801 RFC2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) K. Davidson Y. Kawatsura April 2000 ASCII 52756 29 commerce payment system xml extensible markup language security

This document describes the syntax and procedures for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-dsig-05 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=2802 10.17487/RFC2802 RFC2803 Digest Values for DOM (DOMHASH) H. Maruyama K. Tamura N. Uramoto April 2000 ASCII 22552 11 xml extensible markup language secruity

This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This memo provides information for the Internet community.

 draft-ietf-trade-hiroshi-dom-hash-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2803 RFC2804 IETF Policy on Wiretapping IAB IESG May 2000 ASCII 18934 10 internet engineering task force

This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. This memo provides information for the Internet community.

 draft-iab-raven-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2804 10.17487/RFC2804 RFC2805 Media Gateway Control Protocol Architecture and Requirements N. Greene M. Ramalho B. Rosen April 2000 ASCII 88190 45 MG mapping transcoding network

This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway. This memo provides information for the Internet community.

 draft-ietf-megaco-reqs-10 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC2805 RFC2806 URLs for Telephone Calls A. Vaha-Sipila April 2000 ASCII 50647 21 uniform resource locator schemes

This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS-TRACK]

 draft-antti-telephony-url-12 RFC3966 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2806 RFC2807 XML Signature Requirements J. Reagle July 2000 ASCII 21973 9 digital extensible markup language

This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. This memo provides information for the Internet community.

 draft-ietf-xmldsig-requirements-03 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC2807 RFC2808 The SecurID(r) SASL Mechanism M. Nystrom April 2000 ASCII 20342 11 simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments. This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo provides information for the Internet community.

 draft-nystrom-securid-sasl-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2808 RFC2809 Implementation of L2TP Compulsory Tunneling via RADIUS B. Aboba G. Zorn April 2000 ASCII 47259 23 remote authentication dial-in user service layer two

This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP (Layer Two Tunneling Protocol) protocol. This memo provides information for the Internet community.

 draft-ietf-radius-tunnel-imp-05 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2809 RFC2810 Internet Relay Chat: Architecture C. Kalt April 2000 ASCII 19087 10 IRC text based conferencing

This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. This memo provides information for the Internet community.

 draft-kalt-irc-arch-00 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2810 10.17487/RFC2810 RFC2811 Internet Relay Chat: Channel Management C. Kalt April 2000 ASCII 40788 19 IRC text based conferencing

This document specifies how channels, their characteristics and properties are managed by IRC servers. This memo provides information for the Internet community.

 draft-kalt-irc-chan-01 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2811 RFC2812 Internet Relay Chat: Client Protocol C. Kalt April 2000 ASCII 122637 63 IRC text based conferencing

This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture. This memo provides information for the Internet community.

 draft-kalt-irc-client-03 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2812 10.17487/RFC2812 RFC2813 Internet Relay Chat: Server Protocol C. Kalt April 2000 ASCII 56681 26 IRC text based conferencing

This document defines the protocol used by servers to talk to each other. This memo provides information for the Internet community.

 draft-kalt-irc-server-02 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2813 10.17487/RFC2813 RFC2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks R. Yavatkar D. Hoffman Y. Bernet F. Baker M. Speer May 2000 ASCII 141886 60 LAN local area resource reservation

This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS-TRACK]

 draft-ietf-issll-is802-sbm-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2814 RFC2815 Integrated Service Mappings on IEEE 802 Networks M. Seaman A. Smith E. Crawley J. Wroclawski May 2000 ASCII 42403 17 LAN local area resource reservation

This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). [STANDARDS-TRACK]

 draft-ietf-issll-is802-svc-mapping-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2815 RFC2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies A. Ghanwani J. Pace V. Srinivasan A. Smith M. Seaman May 2000 ASCII 119043 47 LAN local area network parameter switches

This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. This memo provides information for the Internet community.

 draft-ietf-issll-is802-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2816 RFC2817 Upgrading to TLS Within HTTP/1.1 R. Khare S. Lawrence May 2000 ASCII 27598 13 hypertext transfer protocol transport layer security

This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]

 draft-ietf-tls-http-upgrade-05 RFC2616 RFC7230 RFC7231 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2817 10.17487/RFC2817 RFC2818 HTTP Over TLS E. Rescorla May 2000 ASCII 15170 7 hypertext transfer protocol transport layer security

This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.

 draft-ietf-tls-https-04 RFC5785 RFC7230 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2818 10.17487/RFC2818 RFC2819 Remote Network Monitoring Management Information Base S. Waldbusser May 2000 ASCII 198676 98 RMON-MIB MIB RMON

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmonfull-02 RFC1757 STD0059 INTERNET STANDARD INTERNET STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2819 10.17487/RFC2819 RFC2820 Access Control Requirements for LDAP E. Stokes D. Byrne B. Blakley P. Behera May 2000 ASCII 18172 9 lightweight directory access protocol

This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. This memo provides information for the Internet community.

 draft-ietf-ldapext-acl-reqts-03 INFORMATIONAL INFORMATIONAL IETF app ldapext http://www.rfc-editor.org/errata_search.php?rfc=2820 10.17487/RFC2820 RFC2821 Simple Mail Transfer Protocol J. Klensin Editor April 2001 ASCII 192504 79 SMTP

This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS-TRACK]

 draft-ietf-drums-smtpupd-13 RFC0821 RFC0974 RFC1869 RFC5321 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2821 10.17487/RFC2821 RFC2822 Internet Message Format P. Resnick Editor April 2001 ASCII 110695 51 MAIL

This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]

 draft-ietf-drums-msg-fmt-09 RFC0822 RFC5322 RFC5335 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2822 10.17487/RFC2822 RFC2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing J. Carlson P. Langner E. Hernandez-Valencia J. Manchester May 2000 ASCII 60049 28 PPP-SDL point-to-point protocol synchronous optical network digital hierarchy data link simple

This document extends methods found in the Point-to-Point Protocol (PPP) and RFCs 1662 and 2615 to include a new encapsulation for PPP called Simple Data Link (SDL). SDL provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pppext-sdl-06 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2823 RFC2824 Call Processing Language Framework and Requirements J. Lennox H. Schulzrinne May 2000 ASCII 58711 25 CPL-F telephony signalling network devices

This document describes an architectural framework we call a processing language, as a simple and standardized way for implementing and deploying Internet telephony. A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. It also outlines requirements for such a language. This memo provides information for the Internet community.

 draft-ietf-iptel-cpl-framework-02 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2824 RFC2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols IAB L. Daigle Editor May 2000 ASCII 15612 7 character sets e-commerce interoperability

This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. This memo provides information for the Internet community.

 draft-iab-i18n-dns-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2825 10.17487/RFC2825 RFC2826 IAB Technical Comment on the Unique DNS Root Internet Architecture Board May 2000 ASCII 13400 6 Internet Architecture Board domain name system

This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community.

 draft-iab-unique-dns-root-00 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2826 10.17487/RFC2826 RFC2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie May 2000 ASCII 21258 10 ISP Internet Service Provider Internet Protocol DOS

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2267 RFC3704 BCP0038 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2827 10.17487/RFC2827 RFC2828 Internet Security Glossary R. Shirey May 2000 ASCII 489292 212 information system ISD internet standard documents

This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology. This memo provides information for the Internet community.

 draft-shirey-security-glossary-02 RFC4949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2828 RFC2829 Authentication Methods for LDAP M. Wahl H. Alvestrand J. Hodges R. Morgan May 2000 ASCII 33471 16 lightweight directory access protocol security

This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS-TRACK]

 draft-ietf-ldapext-authmeth-04 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2829 RFC2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security J. Hodges R. Morgan M. Wahl May 2000 ASCII 24469 12 LDAP TLS

This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS-TRACK]

 draft-ietf-ldapext-ldapv3-tls-06 RFC4511 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2830 RFC2831 Using Digest Authentication as a SASL Mechanism P. Leach C. Newman May 2000 ASCII 58124 27 http hypertext transfer protocol security simple layer

This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS-TRACK]

 draft-leach-digest-sasl-05 RFC6331 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC2831 RFC2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0 S. Hollenbeck M. Srivastava May 2000 ASCII 77057 39 RRP shared registration system gLTD ccTLD top level domain

This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This memo provides information for the Internet community.

 draft-hollenbeck-rrp-01 RFC3632 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2832 RFC2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals H. Schulzrinne S. Petrack May 2000 ASCII 68786 30 real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS-TRACK]

 draft-ietf-avt-tones-07 RFC4733 RFC4734 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2833 RFC2834 ARP and IP Broadcast over HIPPI-800 J.-M. Pittet May 2000 ASCII 76243 34 address resolution protocol internet high-performance internface parallel

This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP (hardware addresses). This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC 2067 "IP over HIPPI") obsoletes RFC 1374. [STANDARDS-TRACK]

 draft-pittet-hippiarp-05 RFC1374 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2834 10.17487/RFC2834 RFC2835 IP and ARP over HIPPI-6400 (GSN) J.-M. Pittet May 2000 ASCII 74178 33 GSN address resolution protocol internet high-performance internface parallel

This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore, it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. [STANDARDS-TRACK]

 draft-pittet-gsnlan-04 RFC5494 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2835 RFC2836 Per Hop Behavior Identification Codes S. Brim B. Carpenter F. Le Faucheur May 2000 ASCII 13399 7 PHB differentiated services codepoint DSCP

This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS-TRACK]

 draft-ietf-diffserv-phbid-00 RFC3140 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC2836 RFC2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard K. Teow May 2000 ASCII 87860 48 MIB management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. [STANDARDS-TRACK]

 draft-ietf-ipfc-fabric-element-mib-07 RFC4044 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc 10.17487/RFC2837 RFC2838 Uniform Resource Identifiers for Television Broadcasts D. Zigmond M. Vickers May 2000 ASCII 11405 6 URI TV WWW world wide web

This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community.

 draft-zigmond-tv-url-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2838 RFC2839 Internet Kermit Service F. da Cruz J. Altman May 2000 ASCII 42726 20 file transfer management service

This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community.

 draft-columbia-kermit-service-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2839 10.17487/RFC2839 RFC2840 TELNET KERMIT OPTION J. Altman F. da Cruz May 2000 ASCII 22519 12 file transfer management service

This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community.

 draft-altman-telnet-kermit-server-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2840 RFC2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC) P. Metzger W. Simpson November 2000 ASCII 14139 9 IP-MAC encryption secure hash algorithm

This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header. This memo defines a Historic Document for the Internet community.

 draft-simpson-ah-sha-kdp-00 RFC1852 HISTORIC HISTORIC Legacy 10.17487/RFC2841 RFC2842 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder May 2000 ASCII 8366 5 border gateway protocol

This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-cap-neg-06 RFC3392 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2842 RFC2843 Proxy-PAR P. Droz T. Przygienda May 2000 ASCII 27891 13 PNNI augmented Routing ATM asynchronous transfer mode

The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS-TRACK]

 draft-ietf-ion-proxypar-arch-02 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2843 RFC2844 OSPF over ATM and Proxy-PAR T. Przygienda P. Droz R. Haas May 2000 ASCII 32146 14 PNNI augmented Routing asynchronous transfer mode open shortest-path first

This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC (Permanent Virtual Connections) and SVC (Switched Virtual Circuit) meshes with the presence of Proxy-PAR (PNNI Augmented Routing). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ospf-atm-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC2844 RFC2845 Secret Key Transaction Authentication for DNS (TSIG) P. Vixie O. Gudmundsson D. Eastlake 3rd B. Wellington May 2000 ASCII 32272 15 TSIG domain name system transaction signature

This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK]

 draft-ietf-dnsext-tsig-00 RFC1035 RFC3645 RFC4635 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2845 RFC2846 GSTN Address Element Extensions in E-mail Services C. Allocchio June 2000 ASCII 54316 35 global switched telephone network

This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS-TRACK]

 draft-ietf-fax-fulladdr-06 RFC3191 RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=2846 10.17487/RFC2846 RFC2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM M. Eisler June 2000 ASCII 50045 22 LIPKEY client server simple pubilc key mechanism authentication

This memorandum describes a method whereby one can use GSS-API (Generic Security Service Application Program Interface) to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. [STANDARDS-TRACK]

 draft-ietf-cat-lipkey-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2847 RFC2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services S. Petrack L. Conroy June 2000 ASCII 168851 73 session initiation protocol internet description

This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. [STANDARDS-TRACK]

 draft-ietf-pint-protocol-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pint 10.17487/RFC2848 RFC2849 The LDAP Data Interchange Format (LDIF) - Technical Specification G. Good June 2000 ASCII 26017 14 LDIF lightweight directory access protocol file

This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS-TRACK]

 draft-good-ldap-ldif-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2849 10.17487/RFC2849 RFC2850 Charter of the Internet Architecture Board (IAB) Internet Architecture Board B. Carpenter Editor May 2000 ASCII 15984 8 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-rfc1601bis-04 RFC1601 BCP0039 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC2850 RFC2851 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder June 2000 ASCII 32587 16 layer management information base inet address mib

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]

 draft-ops-endpoint-mib-08 RFC3291 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2851 RFC2852 Deliver By SMTP Service Extension D. Newman June 2000 ASCII 29285 13 simple mail transfer protocol client server

This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS-TRACK]

 draft-newman-deliver-03 RFC1894 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2852 10.17487/RFC2852 RFC2853 Generic Security Service API Version 2 : Java Bindings J. Kabat M. Upadhyay June 2000 ASCII 199512 96 GSI application program interface

This document specifies the Java bindings for GSS-API (Generic Security Service Application Program Interface) which is described at a language independent conceptual level in RFC 2743. [STANDARDS-TRACK]

 draft-ietf-cat-gssv2-javabind-05 RFC5653 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2853 RFC2854 The 'text/html' Media Type D. Connolly L. Masinter June 2000 ASCII 16135 8 HTML-INT HTML WWW World Wide Web

This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.

 draft-connolly-text-html-02 RFC2070 RFC1980 RFC1942 RFC1867 RFC1866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2854 RFC2855 DHCP for IEEE 1394 K. Fujisawa June 2000 ASCII 8070 5 dynamic host configuration protocol high performance serial bus

This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages. IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. [STANDARDS-TRACK]

 draft-ietf-ip1394-dhcp-04 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2855 RFC2856 Textual Conventions for Additional High Capacity Data Types A. Bierman K. McCloghrie R. Presuhn June 2000 ASCII 20954 10 SNMP simple network management protocol

This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS-TRACK]

 draft-kzm-hcdata-types-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2856 RFC2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH A. Keromytis N. Provos June 2000 ASCII 13544 7 ipsec encapsulating security payload authentication

This memo describes the use of the HMAC algorithm in conjunction with the RIPEMD-160 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload (ESP) and the revised IPSEC Authentication Header (AH). [STANDARDS-TRACK]

 draft-ietf-ipsec-auth-hmac-ripemd-160-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2857 RFC2858 Multiprotocol Extensions for BGP-4 T. Bates Y. Rekhter R. Chandra D. Katz June 2000 ASCII 23305 11 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-multiprotocol-v2-05 RFC2283 RFC4760 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2858 10.17487/RFC2858 RFC2859 A Time Sliding Window Three Colour Marker (TSWTCM) W. Fang N. Seddigh B. Nandy June 2000 ASCII 19203 9 TSWTCM packets traffic stream routers

This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner. This memo defines an Experimental Protocol for the Internet community.

 draft-fang-diffserv-tc-tswtcm-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2859 RFC2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority B. Carpenter F. Baker M. Roberts June 2000 ASCII 12361 7 mou iana ietf icann engineering task force corporation names

This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.

 draft-iab-iana-mou-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2860 RFC2861 TCP Congestion Window Validation M. Handley J. Padhye S. Floyd June 2000 ASCII 26993 11 transmission control protocol

This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. This memo defines an Experimental Protocol for the Internet community.

 draft-handley-tcp-cwv-02 RFC7661 HISTORIC EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2861 10.17487/RFC2861 RFC2862 RTP Payload Format for Real-Time Pointers M. Civanlar G. Cash June 2000 ASCII 12031 7 view graphs resolution audio video signals

This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS-TRACK]

 draft-ietf-avt-pointer-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2862 RFC2863 The Interfaces Group MIB K. McCloghrie F. Kastenholz June 2000 ASCII 155014 69 INTERGRMIB Management Information Base Network

This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK]

 draft-ietf-ifmib-ifmib2-03 RFC2233 DRAFT STANDARD DRAFT STANDARD IETF int ifmib http://www.rfc-editor.org/errata_search.php?rfc=2863 10.17487/RFC2863 RFC2864 The Inverted Stack Table Extension to the Interfaces Group MIB K. McCloghrie G. Hanson June 2000 ASCII 21445 11 management information base

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 which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS-TRACK]

 draft-ietf-ifmib-invstackmib-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2864 RFC2865 Remote Authentication Dial In User Service (RADIUS) C. Rigney S. Willens A. Rubens W. Simpson June 2000 ASCII 146456 76 RADIUS encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

 draft-ietf-radius-radius-v2-06 RFC2138 RFC2868 RFC3575 RFC5080 RFC6929 DRAFT STANDARD DRAFT STANDARD IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2865 10.17487/RFC2865 RFC2866 RADIUS Accounting C. Rigney June 2000 ASCII 51135 28 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community.

 draft-ietf-radius-accounting-v2-05 RFC2139 RFC2867 RFC5080 RFC5997 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2866 10.17487/RFC2866 RFC2867 RADIUS Accounting Modifications for Tunnel Protocol Support G. Zorn B. Aboba D. Mitton June 2000 ASCII 51135 11 RADIUS] encryption NAS Network Access Server

This document defines new RADIUS (Remote Authentication Dial In User Service) accounting Attributes and new values for the existing Acct- Status-Type Attribute designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

 draft-ietf-radius-tunnel-acct-05 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2867 10.17487/RFC2867 RFC2868 RADIUS Attributes for Tunnel Protocol Support G. Zorn D. Leifer A. Rubens J. Shriver M. Holdrege I. Goyret June 2000 ASCII 42609 20 RADIUS encryption NAS Network Access Server

This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

 draft-ietf-radius-tunnel-auth-09 RFC2865 RFC3575 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2868 10.17487/RFC2868 RFC2869 RADIUS Extensions C. Rigney W. Willats P. Calhoun June 2000 ASCII 96854 47 RADIUS encryption NAS Network Access Server

This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community.

 draft-ietf-radius-ext-07 RFC3579 RFC5080 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2869 RFC2870 Root Name Server Operational Requirements R. Bush D. Karrenberg M. Kosters R. Plzak June 2000 ASCII 21133 10 infrastructure domain names security

The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-root-opreq-05 RFC2010 RFC7720 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC2870 RFC2871 A Framework for Telephony Routing over IP J. Rosenberg H. Schulzrinne June 2000 ASCII 60664 25 internet protocol TRIP gateway

This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. This memo provides information for the Internet community.

 draft-ietf-iptel-gwloc-framework-06 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2871 RFC2872 Application and Sub Application Identity Policy Element for Use with RSVP Y. Bernet R. Pabbati June 2000 ASCII 10933 6 resource reservation protocol

RSVP signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-appid-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2872 RFC2873 TCP Processing of the IPv4 Precedence Field X. Xiao A. Hannan V. Paxson E. Crabbe June 2000 ASCII 15565 8 transmission control protocol internet

This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]

 draft-xiao-tcp-prec-03 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2873 10.17487/RFC2873 RFC2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering M. Crawford C. Huitema July 2000 ASCII 44204 20 internet protocol domain name system

This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]

 draft-ietf-ipngwg-dns-lookups-08 RFC1886 RFC3152 RFC3226 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2874 RFC2875 Diffie-Hellman Proof-of-Possession Algorithms H. Prafullchandra J. Schaad July 2000 ASCII 45231 23 certificate security encryption

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS-TRACK]

 draft-ietf-pkix-dhpop-03 RFC6955 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2875 RFC2876 Use of the KEA and SKIPJACK Algorithms in CMS J. Pawling July 2000 ASCII 29265 13 encryption cryptographic message syntax

This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. This memo provides information for the Internet community.

 draft-ietf-smime-cmskea-05 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2876 10.17487/RFC2876 RFC2877 5250 Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens July 2000 ASCII 83369 36 client server printer

This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. This memo provides information for the Internet community.

 draft-ietf-tn3270e-tn5250e-05 RFC4777 RFC1205 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC2877 RFC2878 PPP Bridging Control Protocol (BCP) M. Higashiyama F. Baker July 2000 ASCII 79527 38 PPP-BCP point-to-point datagrams network

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

 draft-ietf-pppext-bcp-04 RFC1638 RFC3518 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2878 RFC2879 Content Feature Schema for Internet Fax (V2) G. Klyne L. McIntyre August 2000 ASCII 104032 58 media features mechanism

This document defines a content media feature schema for Internet fax. [STANDARDS-TRACK]

 draft-ietf-fax-feature-schema-v2-01 RFC2531 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2879 RFC2880 Internet Fax T.30 Feature Mapping L. McIntyre G. Klyne August 2000 ASCII 75973 37 schema media tags

This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in "Content feature schema for Internet fax". This memo provides information for the Internet community.

 draft-ietf-fax-feature-T30-mapping-03 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2880 RFC2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model D. Mitton M. Beadles July 2000 ASCII 45029 20 RADIUS remote authentication dial-up user service

This document describes the terminology and gives a model of typical Network Access Server (NAS). This memo provides information for the Internet community.

 draft-ietf-nasreq-nasmodel-02 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2881 RFC2882 Network Access Servers Requirements: Extended RADIUS Practices D. Mitton July 2000 ASCII 31426 16 NAS remote authentication dial-in user service

This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS (Remote Authentication Dial In User Service) RFCs 2138, 2139. This memo provides information for the Internet community.

 draft-ietf-nasreq-ext-radiuspract-03 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2882 RFC2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP S. Floyd J. Mahdavi M. Mathis M. Podolsky July 2000 ASCII 35794 17 SACK transmission control protocol packets sender receiver

This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]

 draft-floyd-sack-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2883 10.17487/RFC2883 RFC2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks J. Hadi Salim U. Ahmed July 2000 ASCII 44647 18 internet protocol end-to-end TCP transmission control

This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community.

 draft-hadi-jhsua-ecnperf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2884 RFC2885 Megaco Protocol version 0.8 F. Cuervo N. Greene C. Huitema A. Rayhan B. Rosen J. Segers August 2000 ASCII 344871 170 H.248 media gateway control

This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. [STANDARDS-TRACK]

 draft-ietf-megaco-protocol-08 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2885 RFC2886 Megaco Errata T. Taylor August 2000 ASCII 41311 21 H.248 media gateway control

This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS-TRACK]

 draft-ietf-megaco-errata-03 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2886 RFC2887 The Reliable Multicast Design Space for Bulk Data Transfer M. Handley S. Floyd B. Whetten R. Kermode L. Vicisano M. Luby August 2000 ASCII 51135 22 application RM congestion control data

This document provides an overview of the design space and the ways in which application constraints affect possible solutions. This memo provides information for the Internet community.

 draft-ietf-rmt-design-space-01 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC2887 RFC2888 Secure Remote Access with L2TP P. Srisuresh August 2000 ASCII 41255 19 layer two tunneling protocol

The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This memo provides information for the Internet community.

 draft-srisuresh-secure-ra-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2888 RFC2889 Benchmarking Methodology for LAN Switching Devices R. Mandeville J. Perser August 2000 ASCII 73251 35 local area network MAC medium access control

This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community.

 draft-ietf-bmwg-mswitch-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2889 RFC2890 Key and Sequence Number Extensions to GRE G. Dommety September 2000 ASCII 14503 7 generic routing encapsulation

This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]

 draft-dommety-gre-ext-04 RFC2784 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2890 RFC2891 LDAP Control Extension for Server Side Sorting of Search Results T. Howes M. Wahl A. Anantha August 2000 ASCII 15833 8 lightweight directory access protocol

This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. [STANDARDS-TRACK]

 draft-ietf-ldapext-sorting-03 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2891 RFC2892 The Cisco SRP MAC Layer Protocol D. Tsiang G. Suwala August 2000 ASCII 107645 52 spatial reuse

This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). This memo provides information for the Internet community.

 draft-tsiang-srp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2892 RFC2893 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark August 2000 ASCII 62731 29 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

 draft-ietf-ngtrans-mech-06 RFC1933 RFC4213 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2893 RFC2894 Router Renumbering for IPv6 M. Crawford August 2000 ASCII 69135 32 internet protocol operations scalability applicability

This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. [STANDARDS-TRACK]

 draft-ietf-ipngwg-router-renum-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2894 RFC2895 Remote Network Monitoring MIB Protocol Identifier Reference A. Bierman C. Bucci R. Iddon August 2000 ASCII 88094 42 RMON-MIB management information base

This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding ``INDEX`` values for the protocolDirTable, found in the RMON-2 MIB. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmonprot-ref-01 RFC2074 RFC3395 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2895 RFC2896 Remote Network Monitoring MIB Protocol Identifier Macros A. Bierman C. Bucci R. Iddon August 2000 ASCII 135768 84 RMON management information base

This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB and the RMON Protocol Identifier Reference. This memo provides information for the Internet community.

 draft-ietf-rmonmib-rmonprot-mac-02 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC2896 RFC2897 Proposal for an MGCP Advanced Audio Package D. Cromwell August 2000 ASCII 67459 34 media gateway control protocol IVR interactive voice response

This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This memo provides information for the Internet community.

 draft-cromwell-mgcp-advanced-audio-pkg-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2897 RFC2898 PKCS #5: Password-Based Cryptography Specification Version 2.0 B. Kaliski September 2000 ASCII 68692 34 public-key authentication encryption

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.

 draft-kaliski-pkcs5-v2-04 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2898 10.17487/RFC2898 RFC2899 Request for Comments Summary RFC Numbers 2800-2899 S. Ginoza May 2001 ASCII 43805 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2899 RFC2900 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza August 2001 ASCII 112809 42

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. This memo is an Internet Standard.

 RFC2800 RFC3000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2900 RFC2901 Guide to Administrative Procedures of the Internet Infrastructure Z. Wenzel J. Klensin R. Bush S. Huter August 2000 ASCII 63680 31 address space routing database domain name registration

This document describes the administrative procedures for networks seeking to connect to the global Internet. This memo provides information for the Internet community.

 draft-wenzel-nsrc-02 FYI0037 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2901 RFC2902 Overview of the 1998 IAB Routing Workshop S. Deering S. Hares C. Perkins R. Perlman August 2000 ASCII 32773 16 internet architecture board

This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. This memo provides information for the Internet community.

 draft-iab-rtrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2902 RFC2903 Generic AAA Architecture C. de Laat G. Gross L. Gommans J. Vollbrecht D. Spence August 2000 ASCII 60627 26 authentication authorization accounting

This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-aaaarch-generic-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2903 RFC2904 AAA Authorization Framework J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII 78098 35 authentication authorization accounting

This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community.

 draft-irtf-aaaarch-authorization-framework-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2904 RFC2905 AAA Authorization Application Examples J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII 118645 53 authentication authorization accounting

This memo describes several examples of applications requiring authorization. This memo provides information for the Internet community.

 draft-irtf-aaaarch-authorization-apps-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2905 RFC2906 AAA Authorization Requirements S. Farrell J. Vollbrecht P. Calhoun L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII 48618 23 authentication authorization accounting

This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. This memo provides information for the Internet community.

 draft-irtf-aaaarch-authorization-reqs-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2906 RFC2907 MADCAP Multicast Scope Nesting State Option R. Kermode September 2000 ASCII 27572 13 address dynamic allocation client protocol

This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS-TRACK]

 draft-ietf-malloc-madcap-nest-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2907 RFC2908 The Internet Multicast Address Allocation Architecture D. Thaler M. Handley D. Estrin September 2000 ASCII 30515 13 MALLOC host server intra-domain inter-domain

This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community.

 draft-ietf-malloc-arch-05 RFC6308 HISTORIC INFORMATIONAL IETF tsv malloc 10.17487/RFC2908 RFC2909 The Multicast Address-Set Claim (MASC) Protocol P. Radoslavov D. Estrin R. Govindan M. Handley S. Kumar D. Thaler September 2000 ASCII 127278 56 MASC inter-domain router

This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-malloc-masc-06 HISTORIC EXPERIMENTAL IETF tsv malloc 10.17487/RFC2909 RFC2910 Internet Printing Protocol/1.1: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner J. Wenn September 2000 ASCII 100599 46 IPP-E-T IPP application media-type media type

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

 draft-ietf-ipp-protocol-v11-06 RFC2565 RFC8010 RFC3380 RFC3381 RFC3382 RFC3510 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2910 10.17487/RFC2910 RFC2911 Internet Printing Protocol/1.1: Model and Semantics T. Hastings Editor R. Herriot R. deBry S. Isaacson P. Powell September 2000 ASCII 575805 224 IPP-M-S IPP application media-type job

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

 draft-ietf-ipp-model-v11-07 RFC2566 RFC8011 RFC3380 RFC3382 RFC3996 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2911 10.17487/RFC2911 RFC2912 Indicating Media Features for MIME Content G. Klyne September 2000 ASCII 20618 11 multipurpose mail extensions tag format

This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS-TRACK]

 draft-ietf-conneg-content-features-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2912 RFC2913 MIME Content Types in Media Feature Expressions G. Klyne September 2000 ASCII 16095 9 multipurpose mail extensions tag format

This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-type-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2913 RFC2914 Congestion Control Principles S. Floyd September 2000 ASCII 43823 17 end-to-end

The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-floyd-cong-04 RFC7141 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ecm 10.17487/RFC2914 RFC2915 The Naming Authority Pointer (NAPTR) DNS Resource Record M. Mealling R. Daniel September 2000 ASCII 41521 18 NAPTR domain name system RR

This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). [STANDARDS-TRACK]

 draft-ietf-urn-naptr-rr-04 RFC3401 RFC3402 RFC3403 RFC3404 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn 10.17487/RFC2915 RFC2916 E.164 number and DNS P. Faltstrom September 2000 ASCII 18159 10 domain name system

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]

 draft-ietf-enum-e164-dns-03 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=2916 10.17487/RFC2916 RFC2917 A Core MPLS IP VPN Architecture K. Muthukrishnan A. Malis September 2000 ASCII 35352 16 internet protocol virtual private networks multiprotocol label switching

This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This memo provides information for the Internet community.

 draft-muthukrishnan-mpls-corevpn-arch-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2917 RFC2918 Route Refresh Capability for BGP-4 E. Chen September 2000 ASCII 7354 4 border gateway protocol

This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-route-refresh-01 RFC7313 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2918 RFC2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists R. Chandhok G. Wenger March 2001 ASCII 18480 9 server clients user agents

Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK]

 draft-chandhok-listid-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2919 10.17487/RFC2919 RFC2920 SMTP Service Extension for Command Pipelining N. Freed September 2000 ASCII 17065 9 SMTP-Pipe simple mail transfer protocol TCP transmission control protocol

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK]

 draft-freed-smtp-pipe-01 RFC2197 STD0060 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2920 RFC2921 6BONE pTLA and pNLA Formats (pTLA) B. Fink September 2000 ASCII 14218 7 IPv6 internet protocol pseudo top-level next-level aggregation identifiers

This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). This memo provides information for the Internet community.

 draft-ietf-ngtrans-6bone-ptla-00 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2921 RFC2922 Physical Topology MIB A. Bierman K. Jones September 2000 ASCII 66830 32 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. This memo provides information for the Internet community.

 draft-ietf-ptopomib-mib-05 INFORMATIONAL INFORMATIONAL IETF ops ptopomib 10.17487/RFC2922 RFC2923 TCP Problems with Path MTU Discovery K. Lahey September 2000 ASCII 30976 15 transmission control protocol maximum unit

This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This memo provides information for the Internet community.

 draft-ietf-tcpimpl-pmtud-04 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2923 RFC2924 Accounting Attributes and Record Formats N. Brownlee A. Blount September 2000 ASCII 75561 36 data transport integrated

This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. This memo provides information for the Internet community.

 draft-ietf-aaa-accounting-attributes-04 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2924 RFC2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations K. White September 2000 ASCII 150691 77 mib management information base

This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS-TRACK]

 draft-ietf-disman-remops-mib-08 RFC4560 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2925 10.17487/RFC2925 RFC2926 Conversion of LDAP Schemas to and from SLP Templates J. Kempf R. Moats P. St. Pierre September 2000 ASCII 55365 27 service location protocol lightweight directory access

This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. This memo provides information for the Internet community.

 draft-ietf-svrloc-template-conversion-08 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2926 RFC2927 MIME Directory Profile for LDAP Schema M. Wahl September 2000 ASCII 16122 10 lightweight directory access protocol multipurpose internet mail extensions

This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema. This memo provides information for the Internet community.

 draft-ietf-schema-ldap-01 INFORMATIONAL INFORMATIONAL IETF app schema http://www.rfc-editor.org/errata_search.php?rfc=2927 10.17487/RFC2927 RFC2928 Initial IPv6 Sub-TLA ID Assignments R. Hinden S. Deering R. Fink T. Hain September 2000 ASCII 11882 7 internet protocol sub-top-level aggregation identifiers address registries

This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. This memo provides information for the Internet community.

 draft-ietf-ipngwg-iana-tla-03 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2928 RFC2929 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd E. Brunner-Williams B. Manning September 2000 ASCII 22454 12 internet assigned numbers authority resource records RRs

This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsext-iana-dns-01 RFC5395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC2929 RFC2930 Secret Key Establishment for DNS (TKEY RR) D. Eastlake 3rd September 2000 ASCII 34894 16 TKEY-RR domain name system resource record transaction key

This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS-TRACK]

 draft-ietf-dnsext-tkey-04 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2930 RFC2931 DNS Request and Transaction Signatures ( SIG(0)s ) D. Eastlake 3rd September 2000 ASCII 19073 10 domain name system data security

This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]

 draft-ietf-dnsext-sig-zero-02 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2931 RFC2932 IPv4 Multicast Routing MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII 50430 27 internet protocol management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. [STANDARDS-TRACK]

 draft-ietf-idmr-multicast-routmib-13 RFC5132 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2932 RFC2933 Internet Group Management Protocol MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII 33406 19 igmp management information base

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 used for managing the Internet Group Management Protocol (IGMP). [STANDARDS-TRACK]

 draft-ietf-idmr-igmp-mib-14 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2933 RFC2934 Protocol Independent Multicast MIB for IPv4 K. McCloghrie D. Farinacci D. Thaler B. Fenner October 2000 ASCII 48379 27 internet protocol management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-idmr-pim-mib-11 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2934 RFC2935 Internet Open Trading Protocol (IOTP) HTTP Supplement D. Eastlake 3rd C. Smith September 2000 ASCII 16168 8 IOTP-HTTP hypertext XML extensible markup language transfer

The goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. [STANDARDS-TRACK]

 draft-ietf-trade-iotp-http-07 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC2935 RFC2936 HTTP MIME Type Handler Detection D. Eastlake 3rd C. Smith D. Soroka September 2000 ASCII 25238 13 multipurpose internet mail extensions hypertext transfer protocol

Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. This memo provides information for the Internet community.

 draft-ietf-trade-mime-detector-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2936 RFC2937 The Name Service Search Option for DHCP C. Smith September 2000 ASCII 8368 5 dynamic host configuration protocol

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. [STANDARDS-TRACK]

 draft-ietf-dhc-nsso-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2937 RFC2938 Identifying Composite Media Features G. Klyne L. Masinter September 2000 ASCII 34451 18 tags expression hash

This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-hash-05 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg http://www.rfc-editor.org/errata_search.php?rfc=2938 10.17487/RFC2938 RFC2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types R. Droms September 2000 ASCII 13631 7 dynamic host configuration protocol internet assigned numbers authority

This document describes the procedure for defining new DHCP options and message types. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dhc-new-opt-msg-02 RFC2489 BCP0043 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2939 10.17487/RFC2939 RFC2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients A. Smith D. Partain J. Seligson October 2000 ASCII 52427 27 cops mib 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 a client of the Common Open Policy Service (COPS) protocol. [STANDARDS-TRACK]

 draft-ietf-rap-cops-client-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2940 RFC2941 Telnet Authentication Option T. Ts'o Editor J. Altman September 2000 ASCII 52427 15 TOPT-AUTH encryption Security

This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS-TRACK]

 draft-tso-telnet-auth-enc-05 RFC1416 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2941 RFC2942 Telnet Authentication: Kerberos Version 5 T. Ts'o September 2000 ASCII 14562 7 encryption

This document describes how Kerberos Version 5 is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS-TRACK]

 draft-tso-telnet-krb5-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2942 RFC2943 TELNET Authentication Using DSA R. Housley T. Horting P. Yee September 2000 ASCII 21694 12 digital signature algorithm

This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option. [STANDARDS-TRACK]

 draft-housley-telnet-auth-dsa-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2943 RFC2944 Telnet Authentication: SRP T. Wu September 2000 ASCII 13933 7 secure remote password protocol

This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS-TRACK]

 draft-wu-telnet-auth-srp-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2944 RFC2945 The SRP Authentication and Key Exchange System T. Wu September 2000 ASCII 17843 8 secure remote password protocol

This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]

 draft-wu-srp-auth-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2945 RFC2946 Telnet Data Encryption Option T. Ts'o September 2000 ASCII 16527 8 stream authentication

This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]

 draft-tso-telnet-encryption-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2946 RFC2947 Telnet Encryption: DES3 64 bit Cipher Feedback J. Altman September 2000 ASCII 11064 6 data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS-TRACK]

 draft-altman-telnet-enc-des3-cfb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2947 RFC2948 Telnet Encryption: DES3 64 bit Output Feedback J. Altman September 2000 ASCII 11064 6 data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS-TRACK]

 draft-altman-telnet-enc-des3-ofb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2948 RFC2949 Telnet Encryption: CAST-128 64 bit Output Feedback J. Altman September 2000 ASCII 9240 5 algorithm option

This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

 draft-altman-telnet-enc-cast128-ofb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2949 RFC2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback J. Altman September 2000 ASCII 9267 5 algorithm option

This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

 draft-altman-telnet-enc-cast128-cfb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2950 RFC2951 TELNET Authentication Using KEA and SKIPJACK R. Housley T. Horting P. Yee September 2000 ASCII 20757 11 key exchange algorithm encryption

This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. This memo provides information for the Internet community.

 draft-housley-telnet-auth-keasj-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2951 RFC2952 Telnet Encryption: DES 64 bit Cipher Feedback T. Ts'o September 2000 ASCII 9064 5 data encryption standard

This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. This memo provides information for the Internet community.

 draft-tso-telnet-enc-des-cfb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2952 RFC2953 Telnet Encryption: DES 64 bit Output Feedback T. Ts'o September 2000 ASCII 8995 5 data encryption standard

This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. This memo provides information for the Internet community.

 draft-tso-telnet-enc-des-ofb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2953 RFC2954 Definitions of Managed Objects for Frame Relay Service K. Rehbehn D. Fowler October 2000 ASCII 164217 76 FR-MIB mib management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. [STANDARDS-TRACK]

 draft-ietf-frnetmib-frs-mib-12 RFC1604 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2954 RFC2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function K. Rehbehn O. Nicklass G. Mouradian October 2000 ASCII 83281 39 asynchronous transfer mode permanent virtual connections MIB management information base

This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. [STANDARDS-TRACK]

 draft-ietf-frnetmib-atmiwf-06 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2955 RFC2956 Overview of 1999 IAB Network Layer Workshop M. Kaat October 2000 ASCII 36830 16 intenret architecture board

This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. This memo provides information for the Internet community.

 draft-iab-ntwlyrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2956 RFC2957 The application/whoispp-query Content-Type L. Daigle P. Faltstrom October 2000 ASCII 10262 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2958, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

 draft-daigle-wppquery-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2957 RFC2958 The application/whoispp-response Content-type L. Daigle P. Faltstrom October 2000 ASCII 9995 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

 draft-daigle-wppresp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2958 RFC2959 Real-Time Transport Protocol Management Information Base M. Baugher B. Strahm I. Suconick October 2000 ASCII 62063 31 RTP MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2959 RFC2960 Stream Control Transmission Protocol R. Stewart Q. Xie K. Morneault C. Sharp H. Schwarzbauer T. Taylor I. Rytina M. Kalla L. Zhang V. Paxson October 2000 ASCII 297757 134 SCTP IP internet transport packet network

This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

 draft-ietf-sigtran-sctp-13 RFC4960 RFC3309 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=2960 10.17487/RFC2960 RFC2961 RSVP Refresh Overhead Reduction Extensions L. Berger D. Gan G. Swallow P. Pan F. Tommasi S. Molendini April 2001 ASCII 81675 34 resource reservation protocol messages

This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]

 draft-ietf-rsvp-refresh-reduct-05 RFC5063 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2961 RFC2962 An SNMP Application Level Gateway for Payload Address Translation D. Raz J. Schoenwaelder B. Sugla October 2000 ASCII 46803 20 simple network management protocol

This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. This memo provides information for the Internet community.

 draft-ietf-nat-snmp-alg-05 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2962 RFC2963 A Rate Adaptive Shaper for Differentiated Services O. Bonaventure S. De Cnodder October 2000 ASCII 39895 19 RAS TCP transmission control protocol diffserv

This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively. This memo provides information for the Internet community.

 draft-bonaventure-diffserv-rashaper-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2963 RFC2964 Use of HTTP State Management K. Moore N. Freed October 2000 ASCII 18899 8 hypertext transfer protocol

This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iesg-http-cookies-03 BCP0044 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2964 RFC2965 HTTP State Management Mechanism D. Kristol L. Montulli October 2000 ASCII 56176 26 hypertext transfer protocol

This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS-TRACK]

 draft-ietf-http-state-man-mec-12 RFC2109 RFC6265 HISTORIC PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2965 10.17487/RFC2965 RFC2966 Domain-wide Prefix Distribution with Two-Level IS-IS T. Li T. Przygienda H. Smit October 2000 ASCII 32465 14 intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. This memo provides information for the Internet community.

 draft-ietf-isis-domain-wide-03 RFC5302 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2966 RFC2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways L. Daigle R. Hedberg October 2000 ASCII 209845 105 single point service

The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. This memo provides information for the Internet community.

 draft-daigle-tisdag-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2967 RFC2968 Mesh of Multiple DAG servers - Results from TISDAG L. Daigle T. Eklof October 2000 ASCII 19306 9 technical infrastructure swedish directory access gateways mesh index

This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!). The Common Indexing Protocol (CIP) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. This memo provides information for the Internet community.

 draft-daigle-dag-mesh-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2968 RFC2969 Wide Area Directory Deployment - Experiences from TISDAG T. Eklof L. Daigle October 2000 ASCII 43002 19 technical infrastructure swedish access gateways

This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. This memo provides information for the Internet community.

 draft-eklof-dag-experiences-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2969 RFC2970 Architecture for Integrated Directory Services - Result from TISDAG L. Daigle T. Eklof October 2000 ASCII 40448 18 ids whitepages technical infrastructure swedish access gateways

Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use. This memo provides information for the Internet community.

 draft-daigle-arch-ids-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2970 RFC2971 IMAP4 ID extension T. Showalter October 2000 ASCII 14670 8 internet message access protocol client server

This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK]

 draft-showalter-imap-id-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2971 RFC2972 Context and Goals for Common Name Resolution N. Popp M. Mealling L. Masinter K. Sollins October 2000 ASCII 26252 11 CNRP

This document establishes the context and goals for a Common Name Resolution Protocol. This memo provides information for the Internet community.

 draft-ietf-cnrp-goals-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2972 RFC2973 IS-IS Mesh Groups R. Balay D. Katz J. Parker October 2000 ASCII 14846 8 intermediate system PDU protocol data unit

This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This memo provides information for the Internet community.

 draft-ietf-isis-wg-mesh-group-01 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2973 RFC2974 Session Announcement Protocol M. Handley C. Perkins E. Whelan October 2000 ASCII 40129 18 SAP

This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mmusic-sap-v2-06 EXPERIMENTAL EXPERIMENTAL IETF rai mmusic 10.17487/RFC2974 RFC2975 Introduction to Accounting Management B. Aboba J. Arkko D. Harrington October 2000 ASCII 129771 54 resource consumption data cost allocation

This document describes and discusses the issues involved in the design of the modern accounting systems. The field of Accounting Management is concerned with the collection the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This memo provides information for the Internet community.

 draft-ietf-aaa-acct-06 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2975 RFC2976 The SIP INFO Method S. Donovan October 2000 ASCII 17736 9 session initiation protocol information extension

This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. [STANDARDS-TRACK]

 draft-ietf-sip-info-method-05 RFC6086 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC2976 RFC2977 Mobile IP Authentication, Authorization, and Accounting Requirements S. Glass T. Hiller S. Jacobs C. Perkins October 2000 ASCII 63520 27 AAA internet protocol

This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. This memo provides information for the Internet community.

 draft-ietf-mobileip-aaa-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2977 RFC2978 IANA Charset Registration Procedures N. Freed J. Postel October 2000 ASCII 21615 11 character set mime multipurpose internet mail extensions

Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-freed-charset-regist-03 RFC2278 BCP0019 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2978 10.17487/RFC2978 RFC2979 Behavior of and Requirements for Internet Firewalls N. Freed October 2000 ASCII 14350 7 security intranet network

This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. This memo provides information for the Internet community.

 draft-iab-firewall-req-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2979 RFC2980 Common NNTP Extensions S. Barber October 2000 ASCII 57165 27 network news transfer protocol

In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. This memo provides information for the Internet community.

 draft-ietf-nntpext-imp-04 RFC3977 RFC4643 RFC4644 RFC6048 INFORMATIONAL INFORMATIONAL IETF app nntpext 10.17487/RFC2980 RFC2981 Event MIB R. Kavasseri Editor October 2000 ASCII 98248 50 management information base

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 that can be used to manage and monitor MIB objects and take action through events. [STANDARDS-TRACK]

 draft-ietf-disman-event-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2981 10.17487/RFC2981 RFC2982 Distributed Management Expression MIB R. Kavasseri Editor October 2000 ASCII 81371 41 information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. [STANDARDS-TRACK]

 draft-ietf-disman-express-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2982 RFC2983 Differentiated Services and Tunnels D. Black October 2000 ASCII 35644 14 internet protocol encapsulation

This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms. This memo provides information for the Internet community.

 draft-ietf-diffserv-tunnels-02 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2983 RFC2984 Use of the CAST-128 Encryption Algorithm in CMS C. Adams October 2000 ASCII 11591 6 cryptographic message syntax security cipher

This document specifies how to incorporate CAST-128 into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. [STANDARDS-TRACK]

 draft-ietf-smime-cast-128-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2984 RFC2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0 M. Nystrom B. Kaliski November 2000 ASCII 70703 42 public-key cryptography standards LDAP lightweight directory access protocol

This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.

 draft-nystrom-pkcs9-v2-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2985 10.17487/RFC2985 RFC2986 PKCS #10: Certification Request Syntax Specification Version 1.7 M. Nystrom B. Kaliski November 2000 ASCII 27794 14 public-key cryptography standards PKCS-10 public key distinguished name encryption data

This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.

 draft-nystrom-pkcs10-v1-7-00 RFC2314 RFC5967 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2986 RFC2987 Registration of Charset and Languages Media Features Tags P. Hoffman November 2000 ASCII 8799 6 character sets human languages devices

This document contains the registration for two media feature tags: "charset" and "language". [STANDARDS-TRACK]

 draft-hoffman-char-lang-media-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2987 RFC2988 Computing TCP's Retransmission Timer V. Paxson M. Allman November 2000 ASCII 15280 8 transmission control protocol algorithm

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS-TRACK]

 draft-paxson-tcp-rto-01 RFC6298 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2988 10.17487/RFC2988 RFC2989 Criteria for Evaluating AAA Protocols for Network Access B. Aboba P. Calhoun S. Glass T. Hiller P. McCann H. Shiino P. Walsh G. Zorn G. Dommety C. Perkins B. Patil D. Mitton S. Manning M. Beadles X. Chen S. Sivalingham A. Hameed M. Munson S. Jacobs B. Lim B. Hirschman R. Hsu H. Koo M. Lipford E. Campbell Y. Xu S. Baba E. Jaques November 2000 ASCII 53197 28 authentication authorization accounting

This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. This memo provides information for the Internet community.

 draft-ietf-aaa-na-reqts-07 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2989 RFC2990 Next Steps for the IP QoS Architecture G. Huston November 2000 ASCII 65450 24 internet protocol quality of service end-to-end

This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. This memo provides information for the Internet community.

 draft-iab-qos-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2990 RFC2991 Multipath Issues in Unicast and Multicast Next-Hop Selection D. Thaler C. Hopps November 2000 ASCII 17796 9 routing forwarding packets ECMP

The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community.

 draft-thaler-multipath-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2991 RFC2992 Analysis of an Equal-Cost Multi-Path Algorithm C. Hopps November 2000 ASCII 17524 8 ECMP routing packets forwarding

Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community.

 draft-hopps-ecmp-algo-analysis-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2992 RFC2993 Architectural Implications of NAT T. Hain November 2000 ASCII 74136 29 network address translation

This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community.

 draft-iab-nat-implications-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2993 RFC2994 A Description of the MISTY1 Encryption Algorithm H. Ohta M. Matsui November 2000 ASCII 17803 10 cryptosystem security data stream

This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. This memo provides information for the Internet community.

 draft-ohta-misty1desc-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2994 RFC2995 Pre-Spirits Implementations of PSTN-initiated Services H. Lu Editor I. Faynberg J. Voelker M. Weissman W. Zhang S. Rhim J. Hwang S. Ago S. Moeenuddin S. Hadvani S. Nyckelgard J. Yoakum L. Robart November 2000 ASCII 96427 44 public switched telephone network

This document describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN. This memo provides information for the Internet community.

 draft-ietf-spirits-implementations-02 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC2995 RFC2996 Format of the RSVP DCLASS Object Y. Bernet November 2000 ASCII 18929 9 resource reservation protocol QoS Quality of Service

This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS-TRACK]

 draft-ietf-issll-dclass-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2996 RFC2997 Specification of the Null Service Type Y. Bernet A. Smith B. Davie November 2000 ASCII 25071 12 resource reservation protocol QoS Quality of Service

The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. [STANDARDS-TRACK]

 draft-ietf-issll-nullservice-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2997 RFC2998 A Framework for Integrated Services Operation over Diffserv Networks Y. Bernet P. Ford R. Yavatkar F. Baker L. Zhang M. Speer R. Braden B. Davie J. Wroclawski E. Felstaine November 2000 ASCII 76378 31 intserv QoS Quality of Service end-to-end

This document describes a framework by which Integrated Services may be supported over Diffserv networks. This memo provides information for the Internet community.

 draft-ietf-issll-diffserv-rsvp-05 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2998 RFC2999 Request for Comments Summary RFC Numbers 2900-2999 S. Ginoza August 2001 ASCII 45307 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2999 RFC3000 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza L. Shiota November 2001 ASCII 115207 43

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

 RFC2900 RFC3300 HISTORIC INTERNET STANDARD INDEPENDENT 10.17487/RFC3000 RFC3001 A URN Namespace of Object Identifiers M. Mealling November 2000 ASCII 7459 5 uniform resource names OIDs

This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

 draft-mealling-oid-urn-01 RFC3061 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3001 RFC3002 Overview of 2000 IAB Wireless Internetworking Workshop D. Mitzel December 2000 ASCII 101466 42 internet architecture board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. This memo provides information for the Internet community.

 draft-iab-wirelessws-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3002 RFC3003 The audio/mpeg Media Type M. Nilsson November 2000 ASCII 8381 5 MIME multipurpose internet mail extensions

The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS-TRACK]

 draft-nilsson-audio-mpeg-03 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3003 10.17487/RFC3003 RFC3004 The User Class Option for DHCP G. Stump R. Droms Y. Gu R. Vyaghrapuri A. Demirtjis B. Beser J. Privat November 2000 ASCII 10423 6 dynamic host configuration protocol

This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. [STANDARDS-TRACK]

 draft-ietf-dhc-userclass-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3004 RFC3005 IETF Discussion List Charter S. Harris November 2000 ASCII 5682 3 internet engineering task force

The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-poisson-listaup-02 BCP0045 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3005 RFC3006 Integrated Services in the Presence of Compressible Flows B. Davie C. Iturralde D. Oran S. Casner J. Wroclawski November 2000 ASCII 31588 13 routing resource allocation int-serv

This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. [STANDARDS-TRACK]

 draft-ietf-intserv-compress-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC3006 RFC3007 Secure Domain Name System (DNS) Dynamic Update B. Wellington November 2000 ASCII 18056 9 security authentication validation DNSSEC

This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]

 draft-ietf-dnsext-simple-secure-update-02 RFC2137 RFC2535 RFC2136 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3007 RFC3008 Domain Name System Security (DNSSEC) Signing Authority B. Wellington November 2000 ASCII 13484 7 DNSSEC authentication validation SIG signature

This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. [STANDARDS-TRACK]

 draft-ietf-dnsext-signing-auth-02 RFC4035 RFC4033 RFC4034 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3008 RFC3009 Registration of parityfec MIME types J. Rosenberg H. Schulzrinne November 2000 ASCII 16022 10 media-type multimedia internet mail extensions

The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. [STANDARDS-TRACK]

 draft-ietf-avt-fecmime-01 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3009 RFC3010 NFS version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck December 2000 ASCII 450434 212 NFSv4 network file system

NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [STANDARDS-TRACK]

 draft-ietf-nfsv4-07 RFC3530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3010 10.17487/RFC3010 RFC3011 The IPv4 Subnet Selection Option for DHCP G. Waters November 2000 ASCII 13967 7 internet protocol dynamic host configuration

This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS-TRACK]

 draft-ietf-dhc-subnet-option-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3011 RFC3012 Mobile IPv4 Challenge/Response Extensions C. Perkins P. Calhoun November 2000 ASCII 37005 17 internet protocol authentication foreign agent

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. [STANDARDS-TRACK]

 draft-ietf-mobileip-challenge-13 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3012 RFC3013 Recommended Internet Service Provider Security Services and Procedures T. Killalea November 2000 ASCII 27905 13 ISPs

The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grip-isp-expectations-06 BCP0046 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3013 RFC3014 Notification Log MIB R. Kavasseri November 2000 ASCII 48287 26 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. [STANDARDS-TRACK]

 draft-ietf-disman-notif-log-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3014 RFC3015 Megaco Protocol Version 1.0 F. Cuervo N. Greene A. Rayhan C. Huitema B. Rosen J. Segers November 2000 ASCII 385432 179 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. [STANDARDS-TRACK]

 draft-ietf-megaco-merged-01 RFC2885 RFC2886 RFC3525 PROPOSED STANDARD PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3015 10.17487/RFC3015 RFC3016 RTP Payload Format for MPEG-4 Audio/Visual Streams Y. Kikuchi T. Nomura S. Fukunaga Y. Matsui H. Kimata November 2000 ASCII 47070 21 real-time transport protocol media-type

This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mpeg4-es-05 RFC6416 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3016 RFC3017 XML DTD for Roaming Access Phone Book M. Riegel G. Zorn December 2000 ASCII 59762 33 extensible markup language document type declaration

This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. [STANDARDS-TRACK]

 draft-ietf-roamops-phonebook-xml-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops 10.17487/RFC3017 RFC3018 Unified Memory Space Protocol Specification A. Bogdanov December 2000 ASCII 177783 81 UMSP network connection-oriented

This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. This memo defines an Experimental Protocol for the Internet community.

 draft-bogdanov-umsp-00 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3018 RFC3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol B. Haberman R. Worzella January 2001 ASCII 28293 15 IPv6 MIB MLD

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [STANDARDS-TRACK]

 draft-ietf-ipngwg-mld-mib-05 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3019 RFC3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function P. Pate B. Lynch K. Rehbehn December 2000 ASCII 67736 36 MIB management information base

This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. [STANDARDS-TRACK]

 draft-ietf-frnetmib-mfrmib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3020 RFC3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links A. Retana R. White V. Fuller D. McPherson December 2000 ASCII 19771 10 internet protocol addresses subnet masks

With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK]

 draft-retana-31bits-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3021 RFC3022 Traditional IP Network Address Translator (Traditional NAT) P. Srisuresh K. Egevang January 2001 ASCII 37675 16 internet protocol ports private

The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community.

 draft-ietf-nat-traditional-05 RFC1631 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3022 10.17487/RFC3022 RFC3023 XML Media Types M. Murata S. St. Laurent D. Kohn January 2001 ASCII 86011 39 extensible markup language web authority hypertext transfer protocol

This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]

 draft-murata-xml-09 RFC2376 RFC7303 RFC2048 RFC6839 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3023 10.17487/RFC3023 RFC3024 Reverse Tunneling for Mobile IP, revised G. Montenegro Editor January 2001 ASCII 63929 30 internet protocol node care-of-address

This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. [STANDARDS-TRACK]

 draft-ietf-mobileip-rfc2344-bis-02 RFC2344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3024 10.17487/RFC3024 RFC3025 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung February 2001 ASCII 15611 8 internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

 draft-ietf-mobileip-vendor-ext-11 RFC3115 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3025 RFC3026 Liaison to IETF/ISOC on ENUM R. Blane January 2001 ASCII 11460 6 dns domain name system internet security engineering task force E.164 number

Working Party 1/2, of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. This memo provides information for the Internet community.

 draft-itu-sg2-liason-enum-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3026 RFC3027 Protocol Complications with the IP Network Address Translator M. Holdrege P. Srisuresh January 2001 ASCII 48662 20 IP internet protocol network address translator

The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. This memo provides information for the Internet community.

 draft-ietf-nat-protocol-complications-06 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3027 RFC3028 Sieve: A Mail Filtering Language T. Showalter January 2001 ASCII 73582 36 client server

This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]

 draft-showalter-sieve-12 RFC5228 RFC5429 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3028 10.17487/RFC3028 RFC3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols C. Adams P. Sylvester M. Zolotarev R. Zuccherato February 2001 ASCII 107347 51 DVCS TTP trusted third party

This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-dcs-07 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC3029 RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil December 2000 ASCII 23405 12 simple mail transfer protocol multipurpose interent

This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]

 draft-vaudreuil-esmtp-binary2-03 RFC1830 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3030 10.17487/RFC3030 RFC3031 Multiprotocol Label Switching Architecture E. Rosen A. Viswanathan R. Callon January 2001 ASCII 147175 61 MPLS

This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

 draft-ietf-mpls-arch-06 RFC6178 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3031 10.17487/RFC3031 RFC3032 MPLS Label Stack Encoding E. Rosen D. Tappan G. Fedorkow Y. Rekhter D. Farinacci T. Li A. Conta January 2001 ASCII 48314 23 multi-protocol label switching

This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]

 draft-ietf-mpls-label-encaps-07 RFC3443 RFC4182 RFC5332 RFC3270 RFC5129 RFC5462 RFC5586 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3032 10.17487/RFC3032 RFC3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol M. Suzuki January 2001 ASCII 52188 25 IP

The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. [STANDARDS-TRACK]

 draft-ietf-mpls-git-uus-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3033 RFC3034 Use of Label Switching on Frame Relay Networks Specification A. Conta P. Doolan A. Malis January 2001 ASCII 53176 24 MPLS multi-protocol

This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS-TRACK]

 draft-ietf-mpls-fr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3034 RFC3035 MPLS using LDP and ATM VC Switching B. Davie J. Lawrence K. McCloghrie E. Rosen G. Swallow Y. Rekhter P. Doolan January 2001 ASCII 46463 20 multi-protocol label switching asynchronous transfer mode distribution protocol

This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. [STANDARDS-TRACK]

 draft-ietf-mpls-atm-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3035 RFC3036 LDP Specification L. Andersson P. Doolan N. Feldman A. Fredette B. Thomas January 2001 ASCII 274855 132 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-11 RFC5036 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3036 10.17487/RFC3036 RFC3037 LDP Applicability B. Thomas E. Gray January 2001 ASCII 13601 7 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-applic-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3037 10.17487/RFC3037 RFC3038 VCID Notification over ATM link for LDP K. Nagami Y. Katsube N. Demizu H. Esaki P. Doolan January 2001 ASCII 39134 19 asynchronous transfer mode label distribution protocol

This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS-TRACK]

 draft-ietf-mpls-vcid-atm-05 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3038 RFC3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile S. Santesson W. Polk P. Barzin M. Nystrom January 2001 ASCII 67619 35 syntax

This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The goal of this document is to define a general syntax independent of local legal requirements. [STANDARDS-TRACK]

 draft-ietf-pkix-qc-06 RFC3739 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC3039 RFC3040 Internet Web Replication and Caching Taxonomy I. Cooper I. Melve G. Tomlinson January 2001 ASCII 63257 32 infrastructure www world wide

This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. This memo provides information for the Internet community.

 draft-ietf-wrec-taxonomy-06 INFORMATIONAL INFORMATIONAL IETF app wrec 10.17487/RFC3040 RFC3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves January 2001 ASCII 44446 17 internet protocol interface identifier

This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]

 draft-ietf-ipngwg-addrconf-privacy-04 RFC4941 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3041 10.17487/RFC3041 RFC3042 Enhancing TCP's Loss Recovery Using Limited Transmit M. Allman H. Balakrishnan S. Floyd January 2001 ASCII 19885 9 transmission control protocol

This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS-TRACK]

 draft-ietf-tsvwg-limited-xmit-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3042 RFC3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations M. Mealling January 2001 ASCII 8136 5 uniform resource name

This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community.

 draft-mealling-pin-urn-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3043 RFC3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace S. Rozenfeld January 2001 ASCII 28094 15 serials identifier

This document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier. This memo provides information for the Internet community.

 draft-rozenfeld-urn-issn-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3044 RFC3045 Storing Vendor Information in the LDAP root DSE M. Meredith January 2001 ASCII 10518 6 lightweight directory access protocol DSA-specific entry

This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. This memo provides information for the Internet community.

 draft-mmeredith-rootdse-vendor-info-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3045 RFC3046 DHCP Relay Agent Information Option M. Patrick January 2001 ASCII 30633 14 dynamic host configuration protocol

Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]

 draft-ietf-dhc-agent-options-12 RFC6607 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3046 RFC3047 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi January 2001 ASCII 16292 8 international telecommunication union real-time transport protocol

This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use of G.722.1 with MIME and SDP. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g7221-01 RFC5577 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3047 10.17487/RFC3047 RFC3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer B. Whetten L. Vicisano R. Kermode M. Handley S. Floyd M. Luby January 2001 ASCII 48965 20 RMT protocol core

This document describes a framework for the standardization of bulk-data reliable multicast transport. This memo provides information for the Internet community.

 draft-ietf-rmt-buildingblocks-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3048 RFC3049 TN3270E Service Location and Session Balancing J. Naugle K. Kasthurirangan G. Ledford January 2001 ASCII 40743 21 SLP

This document discusses the implementation of Service Location Protocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. [STANDARDS-TRACK]

 draft-ietf-tn3270e-service-loc-06 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC3049 RFC3050 Common Gateway Interface for SIP J. Lennox H. Schulzrinne J. Rosenberg January 2001 ASCII 76652 35 session initiation protocol

This document defines a SIP CGI interface for providing SIP services on a SIP server. This memo provides information for the Internet community.

 draft-lennox-sip-cgi-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3050 RFC3051 IP Payload Compression Using ITU-T V.44 Packet Method J. Heath J. Border January 2001 ASCII 15845 8 internet protocol international telecommunication union

This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community.

 draft-heath-ipcomp-v44-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3051 RFC3052 Service Management Architectures Issues and Review M. Eder S. Nag January 2001 ASCII 31859 12 framework packets network

The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. This memo provides information for the Internet community.

 draft-irtf-nsmrg-sm-issues-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3052 10.17487/RFC3052 RFC3053 IPv6 Tunnel Broker A. Durand P. Fasano I. Guardini D. Lento January 2001 ASCII 27336 13 internet protocol infrastructure

The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999. This memo provides information for the Internet community.

 draft-ietf-ngtrans-broker-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3053 RFC3054 Megaco IP Phone Media Gateway Application Profile P. Blatherwick R. Bell P. Holland January 2001 ASCII 31971 14 internet protocol H.248 telephone MG

This document specifies a particular application of the Megaco/H.248 Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. This memo provides information for the Internet community.

 draft-ietf-megaco-ipphone-03 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC3054 RFC3055 Management Information Base for the PINT Services Architecture M. Krishnaswamy D. Romascanu February 2001 ASCII 39315 21 MIB PSTN/Internet interworking

This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS-TRACK]

 draft-ietf-pint-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pint 10.17487/RFC3055 RFC3056 Connection of IPv6 Domains via IPv4 Clouds B. Carpenter K. Moore February 2001 ASCII 54902 23 internet protocol wide area network unicast point-to-point

This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]

 draft-ietf-ngtrans-6to4-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans http://www.rfc-editor.org/errata_search.php?rfc=3056 10.17487/RFC3056 RFC3057 ISDN Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom February 2001 ASCII 13601 66 SCTP signaling media gateway interface

This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). [STANDARDS-TRACK]

 draft-ietf-sigtran-iua-10 RFC4233 RFC3807 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3057 RFC3058 Use of the IDEA Encryption Algorithm in CMS S. Teiwes P. Hartmann D. Kuenzi February 2001 ASCII 17257 8 international data encryption algorithm cryptic message syntax s/mime multipurpose internet mail extensions

This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. This memo provides information for the Internet community.

 draft-ietf-smime-idea-08 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3058 RFC3059 Attribute List Extension for the Service Location Protocol E. Guttman February 2001 ASCII 11208 6 SLPv2 messages user agent

This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. [STANDARDS-TRACK]

 draft-guttman-svrloc-attrlist-ext-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3059 RFC3060 Policy Core Information Model -- Version 1 Specification B. Moore E. Ellesson J. Strassner A. Westerinen February 2001 ASCII 240309 100 CIM common schema object-oriented

This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS-TRACK]

 draft-ietf-policy-core-info-model-08 RFC3460 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3060 RFC3061 A URN Namespace of Object Identifiers M. Mealling February 2001 ASCII 8387 6 uniform resource names OIDs

This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

 draft-mealling-rfc3001bis-01 RFC3001 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3061 10.17487/RFC3061 RFC3062 LDAP Password Modify Extended Operation K. Zeilenga February 2001 ASCII 11807 6 lightweight directory access protocol

This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. [STANDARDS-TRACK]

 draft-zeilenga-ldap-passwd-exop-05 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3062 10.17487/RFC3062 RFC3063 MPLS Loop Prevention Mechanism Y. Ohba Y. Katsube E. Rosen P. Doolan February 2001 ASCII 93523 44 multiprotocol label switching path LSPs

This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mpls-loop-prevention-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3063 RFC3064 MGCP CAS Packages B. Foster February 2001 ASCII 116818 56 media gateway controllers

This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. This memo provides information for the Internet community.

 draft-foster-mgcp-cas-packages-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3064 RFC3065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder February 2001 ASCII 20529 11 BGP-ASC AS border gateway protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-confed-rfc1965bis-01 RFC1965 RFC5065 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3065 10.17487/RFC3065 RFC3066 Tags for the Identification of Languages H. Alvestrand January 2001 ASCII 26522 13 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-alvestrand-lang-tag-v2-05 RFC1766 RFC4646 RFC4647 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3066 10.17487/RFC3066 RFC3067 TERENA'S Incident Object Description and Exchange Format Requirements J. Arvidsson A. Cormack Y. Demchenko J. Meijer February 2001 ASCII 36836 17 IEDEF data archiving

The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements. This memo provides information for the Internet community.

 draft-terena-itdwg-iodef-requirements-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3067 RFC3068 An Anycast Prefix for 6to4 Relay Routers C. Huitema June 2001 ASCII 20120 9 exterior gateway protocol interior IGP EGP

This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." [STANDARDS-TRACK]

 draft-ietf-ngtrans-6to4anycast-03 RFC7526 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC3068 RFC3069 VLAN Aggregation for Efficient IP Address Allocation D. McPherson B. Dykes February 2001 ASCII 14891 7 virtual local area network internet protocol

This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. This memo provides information for the Internet community.

 draft-mcpherson-vlan-ipagg-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3069 10.17487/RFC3069 RFC3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay V. Rawat R. Tio S. Nanji R. Verma February 2001 ASCII 12940 7 L2TP-FR point-to-point virtual switched circuits PVCs SVCs

This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS-TRACK]

 draft-ietf-l2tpext-fr-01 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3070 RFC3071 Reflections on the DNS, RFC 1591, and Categories of Domains J. Klensin February 2001 ASCII 24892 10 DNS Policy Top-Level TLD

This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. This memo provides information for the Internet community.

 draft-klensin-1591-reflections-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3071 RFC3072 Structured Data Exchange Format (SDXF) M. Wildgrube March 2001 ASCII 48481 26 chunks file datatype

This specification describes an all-purpose interchange format for use as a file format or for net-working. This memo provides information for the Internet community.

 draft-wildgrube-sdxf-08 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3072 RFC3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration J. Collins March 2001 ASCII 9076 6 multipurpose internet mail extensions

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. This memo provides information for the Internet community.

 draft-collins-pfr-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3073 RFC3074 DHC Load Balancing Algorithm B. Volz S. Gonczi T. Lemon R. Stevens February 2001 ASCII 19374 10 dynamic host configuration protocol

This document proposes a method of algorithmic load balancing. [STANDARDS-TRACK]

 draft-ietf-dhc-loadb-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3074 RFC3075 XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2001 ASCII 145520 64 extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

 draft-ietf-xmldsig-core-11 RFC3275 PROPOSED STANDARD PROPOSED STANDARD IETF sec xmldsig 10.17487/RFC3075 RFC3076 Canonical XML Version 1.0 J. Boyer March 2001 ASCII 63955 28 extensible markup language

This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. This memo provides information for the Internet community.

 draft-ietf-xmldsig-canonical-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3076 RFC3077 A Link-Layer Tunneling Mechanism for Unidirectional Links E. Duros W. Dabbous H. Izumiyama N. Fujii Y. Zhang March 2001 ASCII 52410 25 ll udl bidirectional connectivity ip internet protocol

This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS-TRACK]

 draft-ietf-udlr-lltunnel-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg udlr 10.17487/RFC3077 RFC3078 Microsoft Point-To-Point Encryption (MPPE) Protocol G. Pall G. Zorn March 2001 ASCII 22952 12 security ppp

This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. This memo provides information for the Internet community.

 draft-ietf-pppext-mppe-05 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC3078 RFC3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) G. Zorn March 2001 ASCII 38905 21 security ppp

This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. This memo provides information for the Internet community.

 draft-ietf-pppext-mppe-keys-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3079 RFC3080 The Blocks Extensible Exchange Protocol Core M. Rose March 2001 ASCII 82089 58 BEEP text binary messages kernal

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS-TRACK]

 draft-ietf-beep-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF app beep http://www.rfc-editor.org/errata_search.php?rfc=3080 10.17487/RFC3080 RFC3081 Mapping the BEEP Core onto TCP M. Rose March 2001 ASCII 14008 8 transmission control protocol blocks extensible exchange

This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS-TRACK]

 draft-ietf-beep-tcpmapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app beep 10.17487/RFC3081 RFC3082 Notification and Subscription for SLP J. Kempf J. Goldschmidt March 2001 ASCII 33410 14 service location protocol

The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. This memo defines an Experimental Protocol for the Internet community.

 draft-kempf-srvloc-notify-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3082 RFC3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems R. Woundy March 2001 ASCII 88318 45 MIB BPI data-over-cable service interface specifications

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over- Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo provides information for the Internet community.

 draft-ietf-ipcdn-mcns-bpi-mib-02 INFORMATIONAL INFORMATIONAL IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=3083 10.17487/RFC3083 RFC3084 COPS Usage for Policy Provisioning (COPS-PR) K. Chan J. Seligson D. Durham S. Gai K. McCloghrie S. Herzog F. Reichmeyer R. Yavatkar A. Smith March 2001 ASCII 79341 34 COPS-PR common open service security quality

This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK]

 draft-ietf-rap-pr-05 HISTORIC PROPOSED STANDARD IETF ops rap 10.17487/RFC3084 RFC3085 URN Namespace for NewsML Resources A. Coates D. Allen D. Rivers-Moore March 2001 ASCII 10016 6 uniform resource name newsitems iptc

This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. This memo provides information for the Internet community.

 draft-iptc-newsml-urn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3085 RFC3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification K. Nichols B. Carpenter April 2001 ASCII 63122 24 diffserv QoS quality of service

This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community.

 draft-ietf-diffserv-pdb-def-03 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3086 RFC3087 Control of Service Context using SIP Request-URI B. Campbell R. Sparks April 2001 ASCII 83612 39 session initiation protocol uniform resource identifier

This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. This memo provides information for the Internet community.

 draft-campbell-sip-service-control-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3087 RFC3088 OpenLDAP Root Service An experimental LDAP referral service K. Zeilenga April 2001 ASCII 19471 11 lightweight directory access protocol dns domain name system

The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. This memo defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldap-root-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3088 RFC3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism H. Kitamura April 2001 ASCII 25193 12 internet protocol application layer

This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. This memo provides information for the Internet community.

 draft-ietf-ngtrans-socks-gateway-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3089 RFC3090 DNS Security Extension Clarification on Zone Status E. Lewis March 2001 ASCII 24166 11 domain name system rsa dsa

The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. [STANDARDS-TRACK]

 draft-ietf-dnsext-zone-status-05 RFC4033 RFC4034 RFC4035 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3090 RFC3091 Pi Digit Generation Protocol H. Kennedy April 1 2001 ASCII 10375 6

This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3091 RFC3092 Etymology of "Foo" D. Eastlake 3rd C. Manros E. Raymond April 1 2001 ASCII 29235 14

Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3092 10.17487/RFC3092 RFC3093 Firewall Enhancement Protocol (FEP) M. Gaynor S. Bradner April 1 2001 ASCII 22405 11

Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3093 RFC3094 Tekelec's Transport Adapter Layer Interface D. Sprague R. Benedyk D. Brendes J. Keller April 2001 ASCII 265099 106 signaling gatewa circuit network internet protocol

This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. This memo provides information for the Internet community.

 draft-benedyk-sigtran-tali-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3094 RFC3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed C. Bormann C. Burmeister M. Degermark H. Fukushima H. Hannu L-E. Jonsson R. Hakenberg T. Koren K. Le Z. Liu A. Martensson A. Miyazaki K. Svanbro T. Wiebke T. Yoshimura H. Zheng July 2001 ASCII 368746 168 encapsulating security payload real-time transport protocol user datagram

This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-09 RFC3759 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3095 RFC3096 Requirements for robust IP/UDP/RTP header compression M. Degermark Editor July 2001 ASCII 15018 8 real-time transport internet protocol user datagram

This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP. This memo provides information for the Internet community.

 draft-ietf-rohc-rtp-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3096 RFC3097 RSVP Cryptographic Authentication -- Updated Message Type Value R. Braden L. Zhang April 2001 ASCII 6320 4 RSVP resource reservation protocol security

This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS-TRACK]

 draft-ietf-rsvp-fix-iana-00 RFC2747 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC3097 RFC3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ T. Gavin D. Eastlake 3rd S. Hambridge April 2001 ASCII 64687 28 internet marketing users service providers isps

This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. This memo provides information for the Internet community.

 draft-ietf-run-adverts-02 FYI0038 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC3098 RFC3099 Request for Comments Summary RFC Numbers 3000-3099 S. Ginoza November 2001 ASCII 48990 25 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3099 RFC3100 RFC3101 The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy January 2003 ASCII 76243 33 OSPF-NSSA stub external routes backward compatible

This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]

 draft-ietf-ospf-nssa-update-11 RFC1587 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=3101 10.17487/RFC3101 RFC3102 Realm Specific IP: Framework M. Borella J. Lo D. Grabelsky G. Montenegro October 2001 ASCII 73856 30 RSIP end-to-end NAT addressing requirements

This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-framework-05 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3102 RFC3103 Realm Specific IP: Protocol Specification M. Borella D. Grabelsky J. Lo K. Taniguchi October 2001 ASCII 115855 54 RSIP host gateway NAT requirements

This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-protocol-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3103 RFC3104 RSIP Support for End-to-end IPsec G. Montenegro M. Borella October 2001 ASCII 38719 19 realm specific internet protocol NAT addressing requirements

This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-ipsec-04 EXPERIMENTAL EXPERIMENTAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3104 10.17487/RFC3104 RFC3105 Finding an RSIP Server with SLP J. Kempf G. Montenegro October 2001 ASCII 21427 11 realm specific internet protocol service location NAT addressing requirements

This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-slp-00 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3105 RFC3106 ECML v1.1: Field Specifications for E-Commerce D. Eastlake 3rd T. Goldstein April 2001 ASCII 40715 20 electronic modeling language

Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. This memo provides information for the Internet community.

 draft-eastlake-ecom-fields2-05 RFC2706 RFC4112 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3106 RFC3107 Carrying Label Information in BGP-4 Y. Rekhter E. Rosen May 2001 ASCII 16442 8 SDP asynchronous transfer mode AAL syntax adaption layer

This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK]

 draft-ietf-mpls-bgp4-mpls-04 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3107 10.17487/RFC3107 RFC3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections R. Kumar M. Mostafa May 2001 ASCII 248037 110 asynchronous transfer mode AAL syntax adaption layer

This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-atm-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3108 10.17487/RFC3108 RFC3109 Request to Move STD 39 to Historic Status R. Braden R. Bush J. Klensin May 2001 ASCII 5841 4 BBN 1822 host imp arpanet

This memo changes the status of STD 39, BBN Report 1822, "Specification of the Interconnection of a Host and an IMP", from Standard to Historic. This memo provides information for the Internet community.

 draft-ymbk-std39-historic-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3109 RFC3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) D. Eastlake 3rd May 2001 ASCII 14587 7 RRs resource records security

This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]

 draft-ietf-dnsext-rsa-03 RFC2537 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3110 10.17487/RFC3110 RFC3111 Service Location Protocol Modifications for IPv6 E. Guttman May 2001 ASCII 25543 13 SLP internet protocol

This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. [STANDARDS-TRACK]

 draft-ietf-svrloc-ipv6-12 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC3111 RFC3112 LDAP Authentication Password Schema K. Zeilenga May 2001 ASCII 17116 9 lightweight directory access protocol

This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This memo provides information for the Internet community.

 draft-zeilenga-ldap-authpasswd-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3112 RFC3113 3GPP-IETF Standardization Collaboration K. Rosenbrock R. Sanmugam S. Bradner J. Klensin June 2001 ASCII 11405 7 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community.

 draft-3gpp-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3113 RFC3114 Implementing Company Classification Policy with the S/MIME Security Label W. Nicolls May 2002 ASCII 27764 14 data multipurpose internet mail extensions access control information classification security category

This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. This memo provides information for the Internet community.

 draft-ietf-smime-seclabel-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3114 RFC3115 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung April 2001 ASCII 16363 9 internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

 RFC3025 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3115 RFC3116 Methodology for ATM Benchmarking J. Dunn C. Martin June 2001 ASCII 295052 127 asynchronous transfer mode formats switching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

 draft-ietf-bmwg-atm-method-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3116 RFC3117 On the Design of Application Protocols M. Rose November 2001 ASCII 57279 27 beep bxxp blocks extensible exchange text binary

This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community.

 draft-mrose-beep-design-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3117 RFC3118 Authentication for DHCP Messages R. Droms Editor W. Arbaugh Editor June 2001 ASCII 35536 17 dynamic host configuration protocol verification

This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK]

 draft-ietf-dhc-authentication-16 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3118 10.17487/RFC3118 RFC3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson June 2001 ASCII 37796 19 real-time protocol moving picture experts group

This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mp3-06 RFC5219 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3119 10.17487/RFC3119 RFC3120 A URN Namespace for XML.org K. Best N. Walsh June 2001 ASCII 8068 5 uniform resource name extensible markup language

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

 draft-best-xmlorg-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3120 RFC3121 A URN Namespace for OASIS K. Best N. Walsh June 2001 ASCII 11074 7 uniform resource name organization for the advancement of structured information standards

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

 draft-best-urn-oasis-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3121 RFC3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification A. Conta June 2001 ASCII 40416 20 internet protocol IND link-layer

This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. [STANDARDS-TRACK]

 draft-ietf-ion-ipv6-ind-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3122 10.17487/RFC3122 RFC3123 A DNS RR Type for Lists of Address Prefixes (APL RR) P. Koch June 2001 ASCII 14648 8 domain name system resource record

The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnsext-apl-rr-02 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC3123 RFC3124 The Congestion Manager H. Balakrishnan S. Seshan June 2001 ASCII 53591 22 network stream end-system module

This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS-TRACK]

 draft-ietf-ecm-cm-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ecm 10.17487/RFC3124 RFC3125 Electronic Signature Policies J. Ross D. Pinkas N. Pope September 2001 ASCII 95505 44 signer purchase contract invoice transactions applications

This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-smime-espolicies-00 EXPERIMENTAL EXPERIMENTAL IETF sec smime 10.17487/RFC3125 RFC3126 Electronic Signature Formats for long term electronic signatures D. Pinkas J. Ross N. Pope September 2001 ASCII 175886 84 purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). This memo provides information for the Internet community.

 draft-ietf-smime-esformats-03 RFC5126 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3126 10.17487/RFC3126 RFC3127 Authentication, Authorization, and Accounting: Protocol Evaluation D. Mitton M. St.Johns S. Barkley D. Nelson B. Patil M. Stevens B. Wolff June 2001 ASCII 170579 84 AAA network access requirements

This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. This memo provides information for the Internet community.

 draft-ietf-aaa-proto-eval-02 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC3127 RFC3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858) I. Miller June 2001 ASCII 8242 5 firewalls internet

This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. This memo provides information for the Internet community.

 draft-miller-rfc1858-cmts-00 RFC1858 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3128 RFC3129 Requirements for Kerberized Internet Negotiation of Keys M. Thomas June 2001 ASCII 11401 6 KINK cryptographic security authentication

The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. This memo provides information for the Internet community.

 draft-ietf-kink-reqmt-03 INFORMATIONAL INFORMATIONAL IETF sec kink 10.17487/RFC3129 RFC3130 Notes from the State-Of-The-Technology: DNSSEC E. Lewis June 2001 ASCII 22291 10 domain name system security extensions report

This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. This memo provides information for the Internet community.

 draft-lewis-state-of-dnssec-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3130 RFC3131 3GPP2-IETF Standardization Collaboration S. Bradner P. Calhoun H. Cuschieri S. Dennett G. Flynn M. Lipford M. McPheters June 2001 ASCII 13643 8 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community.

 draft-bradner-3gpp2-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3131 RFC3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement J. Kempf June 2001 ASCII 34985 14 molulity radio link internet protocl

This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. This memo provides information for the Internet community.

 draft-ietf-seamoby-paging-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3132 RFC3133 Terminology for Frame Relay Benchmarking J. Dunn C. Martin June 2001 ASCII 44182 24 switching devices signaling

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. This memo provides information for the Internet community.

 draft-ietf-bmwg-fr-term-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3133 RFC3134 Terminology for ATM ABR Benchmarking J. Dunn C. Martin June 2001 ASCII 29542 16 asynchronous transfer mode available bit rate

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR (Available Bit Rate). This memo provides information for the Internet community.

 draft-ietf-bmwg-atm-term-abr-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3134 RFC3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations J. Border M. Kojo J. Griner G. Montenegro Z. Shelby June 2001 ASCII 114825 45 PEP PILC TCP transmission control protocol

This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community.

 draft-ietf-pilc-pep-07 INFORMATIONAL INFORMATIONAL IETF tsv pilc 10.17487/RFC3135 RFC3136 The SPIRITS Architecture L. Slutsman Editor I. Faynberg H. Lu M. Weissman June 2001 ASCII 19241 10 PSTN public switched telephone network

This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network)and necessitating the interactions between the PSTN and the Internet. This memo provides information for the Internet community.

 draft-ietf-spirits-architecture-03 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3136 RFC3137 OSPF Stub Router Advertisement A. Retana L. Nguyen R. White A. Zinin D. McPherson June 2001 ASCII 8140 5 open shortest path first

This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This memo provides information for the Internet community.

 draft-ietf-ospf-stub-adv-02 RFC6987 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3137 RFC3138 Extended Assignments in 233/8 D. Meyer June 2001 ASCII 6776 4 internet address AS autonomous system number

This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. This memo provides information for the Internet community.

 draft-ietf-mboned-glop-extensions-02 RFC5771 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3138 RFC3139 Requirements for Configuration Management of IP-based Networks L. Sanchez K. McCloghrie J. Saperia June 2001 ASCII 23624 11 internet protocol

This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks. This memo provides information for the Internet community.

 draft-ops-ip-config-management-reqmnts-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3139 RFC3140 Per Hop Behavior Identification Codes D. Black S. Brim B. Carpenter F. Le Faucheur June 2001 ASCII 16586 8 PHB differentiated services codepoint DSCP

This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836. [STANDARDS-TRACK]

 draft-ietf-diffserv-2836bis-02 RFC2836 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3140 RFC3141 CDMA2000 Wireless Data Requirements for AAA T. Hiller P. Walsh X. Chen M. Munson G. Dommety S. Sivalingham B. Lim P. McCann H. Shiino B. Hirschman S. Manning R. Hsu H. Koo M. Lipford P. Calhoun C. Lo E. Jaques E. Campbell Y.Xu,S.Baba,T.Ayaki,T.Seki,A.Hameed June 2001 ASCII 27998 16 authentication authorization accounting

This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. This memo provides information for the Internet community.

 draft-hiller-cdma2000-aaa-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3141 RFC3142 An IPv6-to-IPv4 Transport Relay Translator J. Hagino K. Yamamoto June 2001 ASCII 20864 11 TRT internet protocol

The document describes an IPv6-to-IPv4 transport relay translator (TRT). This memo provides information for the Internet community.

 draft-ietf-ngtrans-tcpudp-relay-04 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3142 RFC3143 Known HTTP Proxy/Caching Problems I. Cooper J. Dilley June 2001 ASCII 57117 32 www world wide web hypertext transfer protocol

This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. This memo provides information for the Internet community.

 draft-cooper-wrec-known-prob-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3143 10.17487/RFC3143 RFC3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring D. Romascanu August 2001 ASCII 62491 30 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [STANDARDS-TRACK]

 draft-ietf-rmonmib-iftopn-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3144 RFC3145 L2TP Disconnect Cause Information R. Verma M. Verma J. Carlson July 2001 ASCII 17421 10 layer2 tunneling PPP point-to-point accounting debugging

This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3145 RFC3146 Transmission of IPv6 Packets over IEEE 1394 Networks K. Fujisawa A. Onoe October 2001 ASCII 16569 8 link-local addresses statelessly autoconfigured

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS-TRACK]

 draft-ietf-ipngwg-1394-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3146 RFC3147 Generic Routing Encapsulation over CLNS Networks P. Christian July 2001 ASCII 14125 8 connectionless network service GRE layer protocol

This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3147 RFC3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics M. Mathis M. Allman July 2001 ASCII 36041 16 BTC transport data

This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity. This memo provides information for the Internet community.

 draft-ietf-ippm-btc-framework-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3148 RFC3149 MGCP Business Phone Packages A. Srinath G. Levendel K. Fritz R. Kalyanaram September 2001 ASCII 77304 41 media gateway control packages

This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. This memo provides information for the Internet community.

 draft-srinath-mgcp-bus-packages-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3149 RFC3150 End-to-end Performance Implications of Slow Links S. Dawkins G. Montenegro M. Kojo V. Magret July 2001 ASCII 39942 17 PILC data applications header compression

This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-slow-06 BCP0048 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3150 RFC3151 A URN Namespace for Public Identifiers N. Walsh J. Cowan P. Grosso August 2001 ASCII 15595 9 uniform resource name publicid

This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI (Uniform Resource Identifiers) syntax. This memo provides information for the Internet community.

 draft-walsh-urn-publicid-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3151 RFC3152 Delegation of IP6.ARPA R. Bush August 2001 ASCII 5727 4 internet protocol domain name system DNS zone

This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ymbk-ip6-arpa-delegation-02 RFC3596 RFC2874 RFC2772 RFC2766 RFC2553 RFC1886 BCP0049 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3152 RFC3153 PPP Multiplexing R. Pazhyannur I. Ali C. Fox August 2001 ASCII 19244 9 point-to-point protocol

This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links. [STANDARDS-TRACK]

 draft-ietf-pppext-pppmux-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3153 RFC3154 Requirements and Functional Architecture for an IP Host Alerting Protocol J. Kempf C. Castelluccia P. Mutaf N. Nakajima Y. Ohba R. Ramjee Y. Saifullah B. Sarikaya X. Xu August 2001 ASCII 31534 16 internet protocol paging mobile hosts

This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This memo provides information for the Internet community.

 draft-ietf-seamoby-paging-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3154 RFC3155 End-to-end Performance Implications of Links with Errors S. Dawkins G. Montenegro M. Kojo V. Magret N. Vaidya August 2001 ASCII 36388 16 TCP transmission control protocol

This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-error-08 BCP0050 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3155 RFC3156 MIME Security with OpenPGP M. Elkins D. Del Torto R. Levien T. Roessler August 2001 ASCII 26809 15 MIME-PGP Authentication Encryption

This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]

 draft-ietf-openpgp-mime-07 RFC2015 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=3156 10.17487/RFC3156 RFC3157 Securely Available Credentials - Requirements A. Arsenault S. Farrell August 2001 ASCII 46169 20 SACRED trusted roots private keys PSE personal security environment

This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This memo provides information for the Internet community.

 draft-ietf-sacred-reqs-03 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3157 RFC3158 RTP Testing Strategies C. Perkins J. Rosenberg H. Schulzrinne August 2001 ASCII 48208 22 real-time transport protocol

This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations. This memo provides information for the Internet community.

 draft-ietf-avt-rtptest-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC3158 RFC3159 Structure of Policy Provisioning Information (SPPI) K. McCloghrie M. Fine J. Seligson K. Chan S. Hahn R. Sahita A. Smith F. Reichmeyer August 2001 ASCII 78621 40 PIB base SNMP simple network management information SMI

This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS-TRACK]

 draft-ietf-rap-sppi-07 HISTORIC PROPOSED STANDARD IETF ops rap 10.17487/RFC3159 RFC3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force S. Harris August 2001 ASCII 98411 38 Internet Engineering Task Force Meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. This memo provides information for the Internet community.

 draft-ietf-uswg-tao-06 RFC1718 RFC4677 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC3160 RFC3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) C. Adams P. Cain D. Pinkas R. Zuccherato August 2001 ASCII 54585 26 TSA authority security request response

This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]

 draft-ietf-pkix-time-stamp-15 RFC5816 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3161 10.17487/RFC3161 RFC3162 RADIUS and IPv6 B. Aboba G. Zorn D. Mitton August 2001 ASCII 20492 12 remote authentication dial in user service attributes

This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]

 draft-aboba-radius-ipv6-10 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3162 10.17487/RFC3162 RFC3163 ISO/IEC 9798-3 Authentication SASL Mechanism R. Zuccherato M. Nystrom August 2001 ASCII 32498 17 simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community.

 draft-zuccherato-9798-3-sasl-03 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3163 RFC3164 The BSD Syslog Protocol C. Lonvick August 2001 ASCII 72951 29 berkeley software distribution transmission messages

This document describes the observed behavior of the syslog protocol. This memo provides information for the Internet community.

 draft-ietf-syslog-syslog-12 RFC5424 INFORMATIONAL INFORMATIONAL IETF sec syslog 10.17487/RFC3164 RFC3165 Definitions of Managed Objects for the Delegation of Management Scripts D. Levi J. Schoenwaelder August 2001 ASCII 134479 64 mib information base

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 a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

 draft-ietf-disman-script-mib-v2-04 RFC2592 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3165 10.17487/RFC3165 RFC3166 Request to Move RFC 1403 to Historic Status D. Meyer J. Scudder August 2001 ASCII 3740 3 BGP-OSPF Border gateway protocol Open shortest path first routing

RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved to Historic status. This memo provides information for the Internet community.

 draft-meyer-rfc1403-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3166 RFC3167 Request to Move RFC 1745 to Historic Status D. Meyer J. Scudder August 2001 ASCII 3825 3 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status. This memo provides information for the Internet community.

 draft-meyer-rfc1745-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3167 RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd D. Black September 2001 ASCII 170966 63 internet protocol header

This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]

 draft-ietf-tsvwg-ecn-04 RFC2481 RFC2003 RFC2474 RFC2401 RFC0793 RFC4301 RFC6040 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3168 10.17487/RFC3168 RFC3169 Criteria for Evaluating Network Access Server Protocols M. Beadles D. Mitton September 2001 ASCII 35303 17 NAS network device AAA authentication authorization accounting

This document defines requirements for protocols used by Network Access Servers (NAS). This memo provides information for the Internet community.

 draft-ietf-nasreq-criteria-06 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC3169 RFC3170 IP Multicast Applications: Challenges and Solutions B. Quinn K. Almeroth September 2001 ASCII 67207 28 internet protocol unicast

This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. This memo provides information for the Internet community.

 draft-ietf-mboned-mcast-apps-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3170 RFC3171 IANA Guidelines for IPv4 Multicast Address Assignments Z. Albanna K. Almeroth D. Meyer M. Schipper August 2001 ASCII 15389 8 internet assigned numbers authority protocol parameters

This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-iana-ipv4-mcast-guidelines-04 RFC5771 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3171 10.17487/RFC3171 RFC3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") G. Huston Editor September 2001 ASCII 18097 8 database DNS domain name system

This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-arpa-03 BCP0052 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC3172 RFC3173 IP Payload Compression Protocol (IPComp) A. Shacham B. Monsour R. Pereira M. Thomas September 2001 ASCII 15389 13 IPCOMP internet protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

 draft-shacham-ippcp-rfc2393bis-08 RFC2393 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3173 RFC3174 US Secure Hash Algorithm 1 (SHA1) D. Eastlake 3rd P. Jones September 2001 ASCII 35525 22 FIPS federal information processing standard

The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.

 draft-eastlake-sha1-02 RFC4634 RFC6234 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3174 10.17487/RFC3174 RFC3175 Aggregation of RSVP for IPv4 and IPv6 Reservations F. Baker C. Iturralde F. Le Faucheur B. Davie September 2001 ASCII 88681 36 resource reservation protocol internet ATM asynchronous transfer mode

This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. [STANDARDS-TRACK]

 draft-ietf-issll-rsvp-aggr-04 RFC5350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC3175 RFC3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks P. Phaal S. Panchen N. McKee September 2001 ASCII 60171 31 agent data MIB management information base

This memo defines InMon Corporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. This memo provides information for the Internet community.

 draft-phaal-sflow-montraffic-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3176 RFC3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites IAB IESG September 2001 ASCII 23178 10 internet architecture board engineering steering group protocol

This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.

 draft-iesg-ipv6-addressing-recommendations-03 RFC6177 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3177 RFC3178 IPv6 Multihoming Support at Site Exit Routers J. Hagino H. Snyder October 2001 ASCII 24453 12 internet protocol ISP Service Provider Routing

The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. This memo provides information for the Internet community.

 draft-ietf-ipngwg-ipv6-2260-02 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC3178 RFC3179 Script MIB Extensibility Protocol Version 1.1 J. Schoenwaelder J. Quittek October 2001 ASCII 56311 25 SMX language management information base

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. This memo defines an Experimental Protocol for the Internet community.

 draft-schoenw-rfc-2593-update-04 RFC2593 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3179 RFC3180 GLOP Addressing in 233/8 D. Meyer P. Lothberg September 2001 ASCII 8225 5 static multicast

This document defines the policy for the use of 233/8 for statically e assigned multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-glop-update-01 RFC2770 BCP0053 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3180 10.17487/RFC3180 RFC3181 Signaled Preemption Priority Policy Element S. Herzog October 2001 ASCII 21990 12 rsvp resource reservation protocol cops common open service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). [STANDARDS-TRACK]

 draft-ietf-rap-signaled-priority-v2-00 RFC2751 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3181 RFC3182 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog R. Hess October 2001 ASCII 36544 18 resource reservation protocol

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-newidentity-01 RFC2752 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap http://www.rfc-editor.org/errata_search.php?rfc=3182 10.17487/RFC3182 RFC3183 Domain Security Services using S/MIME T. Dean W. Ottaway October 2001 ASCII 57129 24 secure/multipurpose internet mail extensions

This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-smime-domsec-09 EXPERIMENTAL EXPERIMENTAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3183 10.17487/RFC3183 RFC3184 IETF Guidelines for Conduct S. Harris October 2001 ASCII 7413 4 internet engineering task force

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-poisson-code-04 RFC7154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3184 RFC3185 Reuse of CMS Content Encryption Keys S. Farrell S. Turner October 2001 ASCII 20404 10 cryptographic message syntax data packets

This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. [STANDARDS-TRACK]

 draft-ietf-smime-rcek-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3185 RFC3186 MAPOS/PPP Tunneling mode S. Shimizu T. Kawano K. Murakami E. Beier December 2001 ASCII 27109 14 multiple access protocol over SONET/SDH point-to-point

This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. This memo provides information for the Internet community.

 draft-shimizu-ppp-mapos-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3186 RFC3187 Using International Standard Book Numbers as Uniform Resource Names J. Hakala H. Walravens October 2001 ASCII 22620 11 isbn urn bibliographic identifiers

This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

 draft-hakala-isbn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3187 RFC3188 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2001 ASCII 27923 13 urn nbn national libraries

This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

 draft-hakala-nbn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3188 RFC3189 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII 25991 13 real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

 draft-ietf-avt-dv-video-04 RFC6469 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3189 10.17487/RFC3189 RFC3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII 34977 17 real-time transport protocol digital audio tape

This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear). [STANDARDS-TRACK]

 draft-ietf-avt-dv-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3190 RFC3191 Minimal GSTN address format in Internet Mail C. Allocchio October 2001 ASCII 24235 13 MIN-PSTN global switched telephone network email

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. [STANDARDS-TRACK]

 draft-ietf-fax-minaddr-v2-04 RFC2303 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3191 RFC3192 Minimal FAX address format in Internet Mail C. Allocchio October 2001 ASCII 18813 11 MINFAX-IM facsimile GSTN global switched telephone network

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses of facsimile devices in the local- part of Internet email addresses. [STANDARDS-TRACK]

 draft-ietf-fax-faxaddr-v2-04 RFC2304 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3192 RFC3193 Securing L2TP using IPsec B. Patel B. Aboba W. Dixon G. Zorn S. Booth November 2001 ASCII 63804 28 layer two tunneling protocol authentication

This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. [STANDARDS-TRACK]

 draft-ietf-l2tpext-security-08 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3193 RFC3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio A. Durand C. Huitema November 2001 ASCII 14539 7 IPng White Paper

This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. This memo provides information for the Internet community.

 draft-durand-huitema-h-density-ratio-01 RFC1715 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3194 RFC3195 Reliable Delivery for syslog D. New M. Rose November 2001 ASCII 60960 36 mappings encryption authentication beep blocks extensible exchange

The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. [STANDARDS-TRACK]

 draft-ietf-syslog-reliable-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC3195 RFC3196 Internet Printing Protocol/1.1: Implementor's Guide T. Hastings C. Manros P. Zehler C. Kugler H. Holst November 2001 ASCII 200720 96 IPP client object

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). This memo provides information for the Internet community.

 draft-ietf-ipp-implementers-guide-v11-03 RFC2639 INFORMATIONAL INFORMATIONAL IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3196 10.17487/RFC3196 RFC3197 Applicability Statement for DNS MIB Extensions R. Austein November 2001 ASCII 8610 5 DNS-R-MIB Domain Name System Management Information Base

This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. This memo provides information for the Internet community.

 draft-ietf-dnsext-dnsmib-historical-00 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3197 RFC3198 Terminology for Policy-Based Management A. Westerinen J. Schnizlein J. Strassner M. Scherling B. Quinn S. Herzog A. Huynh M. Carlson J. Perry S. Waldbusser November 2001 ASCII 47806 21 glossary network ISDs internet standard documents

This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community.

 draft-ietf-policy-terminology-04 INFORMATIONAL INFORMATIONAL IETF ops policy 10.17487/RFC3198 RFC3199 Request for Comments Summary RFC Numbers 3100-3199 S. Ginoza February 2003 ASCII 47287 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3199 RFC3200 RFC3201 Definitions of Managed Objects for Circuit to Interface Translation R. Steinberger O. Nicklass January 2002 ASCII 45583 23 mib

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS-TRACK]

 draft-ietf-frnetmib-frsi-04 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3201 RFC3202 Definitions of Managed Objects for Frame Relay Service Level Definitions R. Steinberger O. Nicklass January 2002 ASCII 130816 64 mib

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS-TRACK]

 draft-ietf-frnetmib-frmrelay-service-06 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3202 RFC3203 DHCP reconfigure extension Y. T'Joens C. Hublet P. De Schrijver December 2001 ASCII 11857 6 dynamic host configuration protocol forcerenew

This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK]

 draft-ietf-dhc-pv4-reconfigure-06 RFC6704 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3203 RFC3204 MIME media types for ISUP and QSIG Objects E. Zimmerer J. Peterson A. Vemuri L. Ong F. Audet M. Watson M. Zonoun December 2001 ASCII 19712 10 multipart internet mail extensions

This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS-TRACK]

 draft-ietf-sip-isup-mime-10 RFC3459 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3204 10.17487/RFC3204 RFC3205 On the use of HTTP as a Substrate K. Moore February 2002 ASCII 34785 14 hypertext transfer protocol layering

Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-moore-using-http-01 BCP0056 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3205 10.17487/RFC3205 RFC3206 The SYS and AUTH POP Response Codes R. Gellens February 2002 ASCII 9917 6 security authentication

This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS-TRACK]

 draft-gellens-pop-err-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3206 RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security P. Hoffman February 2002 ASCII 18679 9 simple mail transfer protocol ssl tls

This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

 draft-hoffman-rfc2487bis-06 RFC2487 RFC7817 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3207 10.17487/RFC3207 RFC3208 PGM Reliable Transport Protocol Specification T. Speakman J. Crowcroft J. Gemmell D. Farinacci S. Lin D. Leshchiner M. Luby T. Montgomery L. Rizzo A. Tweedly N. Bhaskar R. Edmonstone R. Sumanasekera L. Vicisano December 2001 ASCII 244637 111 pragmatic general multicast

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community.

 draft-speakman-pgm-spec-07 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3208 10.17487/RFC3208 RFC3209 RSVP-TE: Extensions to RSVP for LSP Tunnels D. Awduche L. Berger D. Gan T. Li V. Srinivasan G. Swallow December 2001 ASCII 132264 61 resource reservation protocol label switched paths

This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-lsp-tunnel-09 RFC3936 RFC4420 RFC4874 RFC5151 RFC5420 RFC5711 RFC6780 RFC6790 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3209 10.17487/RFC3209 RFC3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels D. Awduche A. Hannan X. Xiao December 2001 ASCII 17691 8 resource reservation protocol label switched paths

This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. This memo provides information for the Internet community.

 draft-ietf-mpls-rsvp-tunnel-applicability-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3210 RFC3211 Password-based Encryption for CMS P. Gutmann December 2001 ASCII 30527 17 cryptographic message syntax S/MIME key wrap derivation passwordrecipientinfo PWRI

This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS-TRACK]

 draft-ietf-smime-password-06 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3211 RFC3212 Constraint-Based LSP Setup using LDP B. Jamoussi Editor L. Andersson R. Callon R. Dantu L. Wu P. Doolan T. Worster N. Feldman A. Fredette M. Girish E. Gray J. Heinanen T. Kilty A. Malis January 2002 ASCII 87591 42 label switching protocol distribution CR

This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS-TRACK]

 draft-ietf-mpls-cr-ldp-06 RFC3468 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3212 RFC3213 Applicability Statement for CR-LDP J. Ash M. Girish E. Gray B. Jamoussi G. Wright January 2002 ASCII 14489 7 constraint-based label distribution protocol

This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community.

 draft-ietf-mpls-crldp-applic-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3213 RFC3214 LSP Modification Using CR-LDP J. Ash Y. Lee P. Ashwood-Smith B. Jamoussi D. Fedyk D. Skalecki L. Li January 2002 ASCII 25453 11 label switching protocol constraint-based distribution

This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS-TRACK]

 draft-ietf-mpls-crlsp-modify-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3214 RFC3215 LDP State Machine C. Boscher P. Cheval L. Wu E. Gray January 2002 ASCII 117278 78 label distribution protocol

This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-state-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3215 RFC3216 SMIng Objectives C. Elliott D. Harrington J. Jason J. Schoenwaelder F. Strauss W. Weiss December 2001 ASCII 58551 33 SNMP simple network management protocol COPS-PR common open policy service provisioning

This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community.

 draft-ietf-sming-reqs-06 INFORMATIONAL INFORMATIONAL IETF ops sming 10.17487/RFC3216 RFC3217 Triple-DES and RC2 Key Wrapping R. Housley December 2001 ASCII 19855 9 algorithm data encryption standard

This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.

 draft-ietf-smime-key-wrap-01 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3217 10.17487/RFC3217 RFC3218 Preventing the Million Message Attack on Cryptographic Message Syntax E. Rescorla January 2002 ASCII 16047 7 cryptographic syntax

This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community.

 draft-ietf-smime-pkcs1-01 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3218 RFC3219 Telephony Routing over IP (TRIP) J. Rosenberg H. Salama M. Squire January 2002 ASCII 184618 79 inter-administrative BGP border gateway protocol

This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS-TRACK]

 draft-ietf-iptel-trip-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3219 10.17487/RFC3219 RFC3220 IP Mobility Support for IPv4 C. Perkins Editor January 2002 ASCII 238343 98 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

 draft-ietf-mobileip-rfc2002-bis-08 RFC2002 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3220 10.17487/RFC3220 RFC3221 Commentary on Inter-Domain Routing in the Internet G. Huston December 2001 ASCII 66580 25 BGP border gateway protocol

This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community.

 draft-iab-bgparch-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3221 RFC3222 Terminology for Forwarding Information Base (FIB) based Router Performance G. Trotter December 2001 ASCII 25483 15 internet protocol routing table benchmark

This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community.

 draft-ietf-bmwg-fib-term-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3222 RFC3223 RFC3224 Vendor Extensions for Service Location Protocol, Version 2 E. Guttman January 2002 ASCII 19618 10 SLP SVRLOC opaque

This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol." [STANDARDS-TRACK]

 RFC2608 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3224 10.17487/RFC3224 RFC3225 Indicating Resolver Support of DNSSEC D. Conrad December 2001 ASCII 11548 6 domain name system security extensions

In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-okbit-02 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3225 RFC3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements O. Gudmundsson December 2001 ASCII 12078 6 domain name space security extensions dns endso

This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS-TRACK]

 draft-ietf-dnsext-message-size-04 RFC2535 RFC2874 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3226 10.17487/RFC3226 RFC3227 Guidelines for Evidence Collection and Archiving D. Brezinski T. Killalea February 2002 ASCII 18468 10 security incident

A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grip-prot-evidence-05 BCP0055 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3227 RFC3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP) B. Fenner February 2002 ASCII 6473 4 assigned numbers authority

This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-magma-igmp-iana-01 BCP0057 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int magma 10.17487/RFC3228 RFC3229 Delta encoding in HTTP J. Mogul B. Krishnamurthy F. Douglis A. Feldmann Y. Goland A. van Hoff D. Hellerstein January 2002 ASCII 111953 49 hyper text transfer protocol

This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]

 draft-mogul-http-delta-10 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3229 RFC3230 Instance Digests in HTTP J. Mogul A. Van Hoff January 2002 ASCII 26846 13 hyper text transfer protocol

HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]

 draft-mogul-http-digest-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3230 RFC3231 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder January 2002 ASCII 61308 29 mib information base

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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS-TRACK]

 draft-ietf-disman-schedule-mib-v2-04 RFC2591 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3231 RFC3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database J. Reynolds Editor January 2002 ASCII 3849 3 IANA internet assigned numbers authority parameters

This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.

 RFC1700 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3232 RFC3233 Defining the IETF P. Hoffman S. Bradner February 2002 ASCII 6401 4 internet engineering task force

This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hoffman-what-is-ietf-05 BCP0058 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3233 RFC3234 Middleboxes: Taxonomy and Issues B. Carpenter S. Brim February 2002 ASCII 62329 27 internet protocol router data path host

This document is intended as part of an IETF discussion about "middleboxes" - 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. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.

 draft-carpenter-midtax-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3234 RFC3235 Network Address Translator (NAT)-Friendly Application Design Guidelines D. Senie January 2002 ASCII 29588 13 NAPT ALG firewall

This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community.

 draft-ietf-nat-app-guide-07 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3235 RFC3236 The 'application/xhtml+xml' Media Type M. Baker P. Stark January 2002 ASCII 16750 8 mime multipurpose internet mail extensions

This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.

 draft-baker-xhtml-media-reg-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3236 RFC3237 Requirements for Reliable Server Pooling M. Tuexen Q. Xie R. Stewart M. Shore L. Ong J. Loughney M. Stillman January 2002 ASCII 16986 10 rserpool application

This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community.

 draft-ietf-rserpool-reqts-03 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC3237 RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services S. Floyd L. Daigle January 2002 ASCII 42336 17 OPES internet architecture board

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community.

 draft-iab-opes-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3238 RFC3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations C. Kugler H. Lewis T. Hastings February 2002 ASCII 29532 15 object device

This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community.

 draft-ietf-ipp-ops-admin-req-01 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3239 RFC3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration D. Clunie E. Cordonnier February 2002 ASCII 9102 6 multipurpose internet mail extensions

This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in "Digital Imaging and Communications in Medicine". This memo provides information for the Internet community.

 draft-dicom-media-type-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3240 RFC3241 Robust Header Compression (ROHC) over PPP C. Bormann April 2002 ASCII 24424 12 point-to-point protocol datagram packets

This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

 draft-ietf-rohc-over-ppp-04 RFC1332 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3241 RFC3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier April 2002 ASCII 49007 21 internet protocol user datagram real-time application transport

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-lla-03 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3242 RFC3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression L-E. Jonsson April 2002 ASCII 12451 6 internet protocol user datagram real-time application transport applications LLA link-layer assisted

This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.

 draft-ietf-rohc-rtp-0-byte-requirements-02 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3243 RFC3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols M. Swift J. Trostle J. Brezak February 2002 ASCII 13334 7 security message codes

This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. This memo provides information for the Internet community.

 draft-trostle-win2k-cat-kerberos-set-passwd-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3244 RFC3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) J. Klensin Editor IAB March 2002 ASCII 23758 10 IAB ARPA

RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.

 draft-iab-itu-enum-notes-00 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3245 10.17487/RFC3245 RFC3246 An Expedited Forwarding PHB (Per-Hop Behavior) B. Davie A. Charny J.C.R. Bennet K. Benson J.Y. Le Boudec W. Courtney S. Davari V. Firoiu D. Stiliadis March 2002 ASCII 33896 16 per-hop behavior expedited forwarding differentiated services delay jitter

This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]

 draft-ietf-diffserv-rfc2598bis-02 RFC2598 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3246 RFC3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) A. Charny J. Bennet K. Benson J. Boudec A. Chiu W. Courtney S. Davari V. Firoiu C. Kalmanek K. Ramakrishnan March 2002 ASCII 53786 24 differentiated services fifo fair queuing delay jitter

This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community.

 draft-ietf-diffserv-ef-supplemental-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3247 10.17487/RFC3247 RFC3248 A Delay Bound alternative revision of RFC 2598 G. Armitage B. Carpenter A. Casati J. Crowcroft J. Halpern B. Kumar J. Schnizlein March 2002 ASCII 21597 11 per hop behavior phb expedited forwarding ef db

For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community.

 draft-ietf-diffserv-efresolve-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3248 RFC3249 Implementers Guide for Facsimile Using Internet Mail V. Cancio M. Moldovan H. Tamura D. Wing September 2002 ASCII 40413 21 fax tiff tiff-fx ifax e-mail email esmtp dsn mdn

This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community.

 draft-ietf-fax-implementers-guide-07 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC3249 RFC3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty September 2002 ASCII 17876 7 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

 draft-ietf-fax-tiff-fx-reg-01 RFC3950 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3250 RFC3251 Electricity over IP B. Rajagopalan April 1 2002 ASCII 18994 9 Internet Protocol

Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This memo provides information for the Internet community.

 draft-bala-mplamps-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3251 RFC3252 Binary Lexical Octet Ad-hoc Transport H. Kennedy April 1 2002 ASCII 25962 16 bloat

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3252 RFC3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) G. Clemm J. Amsden T. Ellison C. Kaler J. Whitehead March 2002 ASCII 245514 118 hypertext transfer protocol clients label configuration management

This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS-TRACK]

 draft-ietf-deltav-versioning-20 PROPOSED STANDARD PROPOSED STANDARD IETF app deltav http://www.rfc-editor.org/errata_search.php?rfc=3253 10.17487/RFC3253 RFC3254 Definitions for talking about directories H. Alvestrand April 2002 ASCII 21541 11 domain name system lightweight access protocol

When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community.

 draft-alvestrand-directory-defs-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3254 RFC3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads N. Jones C. Murton April 2002 ASCII 14192 8

This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS-TRACK]

 draft-ietf-pppext-posvcholo-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3255 RFC3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option D. Jones R. Woundy April 2002 ASCII 8551 5

This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS-TRACK]

 draft-ietf-dhc-agentoptions-device-class-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3256 RFC3257 Stream Control Transmission Protocol Applicability Statement L. Coene April 2002 ASCII 24198 13 sctp udp tcp rtp transport security transport nat multihoming

This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community.

 draft-ietf-sigtran-sctp-applicability-08 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC3257 RFC3258 Distributing Authoritative Name Servers via Shared Unicast Addresses T. Hardie April 2002 ASCII 22195 11 dns network topology latency

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community.

 draft-ietf-dnsop-hardie-shared-root-server-07 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC3258 RFC3259 A Message Bus for Local Coordination J. Ott C. Perkins D. Kutscher April 2002 ASCII 84125 39 mbus message ip multicast addressing transport syntax

The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community.

 draft-ietf-mmusic-mbus-transport-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC3259 RFC3260 New Terminology and Clarifications for Diffserv D. Grossman April 2002 ASCII 21900 10 DIFFSRV scalability IP internet protocol

This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.

 draft-ietf-diffserv-new-terms-08 RFC2474 RFC2475 RFC2597 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3260 10.17487/RFC3260 RFC3261 SIP: Session Initiation Protocol J. Rosenberg H. Schulzrinne G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley E. Schooler June 2002 ASCII 647976 269 SIP application-layer application layer multimedia multicast unicast

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]

 draft-ietf-sip-rfc2543bis-09 RFC2543 RFC3265 RFC3853 RFC4320 RFC4916 RFC5393 RFC5621 RFC5626 RFC5630 RFC5922 RFC5954 RFC6026 RFC6141 RFC6665 RFC6878 RFC7462 RFC7463 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3261 10.17487/RFC3261 RFC3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne June 2002 ASCII 29643 14 SIP application-layer application layer multimedia multicast unicast

This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]

 draft-ietf-sip-100rel-06 RFC2543 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3262 10.17487/RFC3262 RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers J. Rosenberg H. Schulzrinne June 2002 ASCII 42310 17 SIP application-layer application layer multimedia multicast unicast

The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK]

 draft-ietf-sip-srv-06 RFC2543 RFC7984 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3263 RFC3264 An Offer/Answer Model with Session Description Protocol (SDP) J. Rosenberg H. Schulzrinne June 2002 ASCII 60854 25 SIP application-layer application layer multimedia multicast unicast

This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-offer-answer-02 RFC2543 RFC6157 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3264 10.17487/RFC3264 RFC3265 Session Initiation Protocol (SIP)-Specific Event Notification A. B. Roach June 2002 ASCII 89005 38 SIP application-layer application layer multimedia multicast unicast

This document describes an extension to the Session Initiation Protocol (SIP). 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. [STANDARDS-TRACK]

 draft-ietf-sip-events-05 RFC2543 RFC6665 RFC3261 RFC5367 RFC5727 RFC6446 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3265 10.17487/RFC3265 RFC3266 Support for IPv6 in Session Description Protocol (SDP) S. Olson G. Camarillo A. B. Roach June 2002 ASCII 8693 5 internet addresses syntax

This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-ipv6-03 RFC4566 RFC2327 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3266 10.17487/RFC3266 RFC3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie June 2002 ASCII 110652 49 interoperate applications

This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-amr-13 RFC4867 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3267 10.17487/RFC3267 RFC3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) P. Chown June 2002 ASCII 13530 7 idea international data algorithm symmetric

This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS-TRACK]

 draft-ietf-tls-ciphersuite-06 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3268 RFC3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents R. Kermode L. Vicisano April 2002 ASCII 25258 12 definitions operation

This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.

 draft-ietf-rmt-author-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3269 RFC3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services F. Le Faucheur L. Wu B. Davie S. Davari P. Vaananen R. Krishnan P. Cheval J. Heinanen May 2002 ASCII 137960 64 diff-serv ba behaviour aggregate lsp label switched paths

This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]

 draft-ietf-mpls-diff-ext-09 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3270 10.17487/RFC3270 RFC3271 The Internet is for Everyone V. Cerf April 2002 ASCII 12345 6 isoc internet society policy issues social impact economic impact international policy use and abuse of the internet

This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community.

 draft-isoc-internet-for-everyone-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3271 10.17487/RFC3271 RFC3272 Overview and Principles of Internet Traffic Engineering D. Awduche A. Chiu A. Elwalid I. Widjaja X. Xiao May 2002 ASCII 190384 71 te ip networks

This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community.

 draft-ietf-tewg-principles-02 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg http://www.rfc-editor.org/errata_search.php?rfc=3272 10.17487/RFC3272 RFC3273 Remote Network Monitoring Management Information Base for High Capacity Networks S. Waldbusser July 2002 ASCII 150924 77 rmon mib high speed networks

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]

 draft-ietf-rmonmib-hcrmon-10 RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3273 RFC3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS) P. Gutmann June 2002 ASCII 11276 6 content info type

This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK]

 draft-ietf-smime-compression-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3274 RFC3275 (Extensible Markup Language) XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2002 ASCII 164198 73 extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

 draft-ietf-xmldsig-core-2-03 RFC3075 DRAFT STANDARD DRAFT STANDARD IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3275 10.17487/RFC3275 RFC3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing B. Ray R. Abbi May 2002 ASCII 122991 66 mib interfaces

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS-TRACK]

 draft-ietf-adslmib-hdsl2-12 RFC4319 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3276 RFC3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance D. McPherson April 2002 ASCII 13077 6 router

This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community.

 draft-ietf-isis-transient-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3277 RFC3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Blake-Wilson D. Brown P. Lambert April 2002 ASCII 33779 16 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community.

 draft-ietf-smime-ecc-06 RFC5753 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3278 RFC3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile L. Bassham W. Polk R. Housley April 2002 ASCII 53833 27 ASN.1

This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]

 draft-ietf-pkix-ipki-pkalgs-05 RFC4055 RFC4491 RFC5480 RFC5758 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3279 10.17487/RFC3279 RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley W. Polk W. Ford D. Solo April 2002 ASCII 295556 129

This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]

 draft-ietf-pkix-new-part1-12 RFC2459 RFC5280 RFC4325 RFC4630 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3280 10.17487/RFC3280 RFC3281 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley April 2002 ASCII 90580 40 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]

 draft-ietf-pkix-ac509prof-09 RFC5755 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3281 10.17487/RFC3281 RFC3282 Content Language Headers H. Alvestrand May 2002 ASCII 14022 8

This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]

 draft-alvestrand-content-language-03 RFC1766 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3282 RFC3283 Guide to Internet Calendaring B. Mahoney G. Babics A. Taler June 2002 ASCII 31768 16 scheduling systems cap calendar access protocool itip imip

This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.

 draft-ietf-calsch-inetcal-guide-02 INFORMATIONAL INFORMATIONAL IETF app calsch 10.17487/RFC3283 RFC3284 The VCDIFF Generic Differencing and Compression Data Format D. Korn J. MacDonald J. Mogul K. Vo June 2002 ASCII 64035 29 transport portable at&t encoding

This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]

 draft-korn-vcdiff-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3284 RFC3285 Using Microsoft Word to create Internet Drafts and RFCs M. Gahrns T. Hain May 2002 ASCII 34556 19

This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community.

 draft-hain-msword-template-04 RFC5385 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3285 RFC3286 An Introduction to the Stream Control Transmission Protocol (SCTP) L. Ong J. Yoakum May 2002 ASCII 22644 10 transport layer telephony signaling

This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community.

 draft-ong-sigtran-sctpover-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3286 RFC3287 Remote Monitoring MIB Extensions for Differentiated Services A. Bierman July 2002 ASCII 249622 120 rmon management information base diffserv

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS-TRACK]

 draft-ietf-rmonmib-dsmon-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3287 RFC3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose June 2002 ASCII 27434 20 binding markup language xml

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS-TRACK]

 draft-etal-beep-soap-06 RFC4227 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3288 RFC3289 Management Information Base for the Differentiated Services Architecture F. Baker K. Chan A. Smith May 2002 ASCII 239041 116 mib diffserv router architecture

This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS-TRACK]

 draft-ietf-diffserv-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3289 10.17487/RFC3289 RFC3290 An Informal Management Model for Diffserv Routers Y. Bernet S. Blake D. Grossman A. Smith May 2002 ASCII 129443 56 differentiated services

This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.

 draft-ietf-diffserv-model-06 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3290 RFC3291 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder May 2002 ASCII 43564 20 tc mib layer management information base

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ops-rfc2851-update-06 RFC2851 RFC4001 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC3291 RFC3292 General Switch Management Protocol (GSMP) V3 A. Doria F. Hellstrand K. Sundell T. Worster June 2002 ASCII 318983 137 switch label unicast multicast qos quality of service

This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS-TRACK]

 draft-ietf-gsmp-11 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3292 RFC3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP) T. Worster A. Doria J. Buerkle June 2002 ASCII 18206 9

This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS-TRACK]

 draft-ietf-gsmp-encaps-05 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3293 RFC3294 General Switch Management Protocol (GSMP) Applicability A. Doria K. Sundell June 2002 ASCII 18294 9 internet

This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community.

 draft-ietf-gsmp-applicability-02 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3294 RFC3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP) H. Sjostrand J. Buerkle B. Srinivasan June 2002 ASCII 95516 47 mib management information base controller gsmp-mib

This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS-TRACK]

 draft-ietf-gsmp-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3295 RFC3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories K. Zeilenga July 2002 ASCII 27389 14 schema elements description formats

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS-TRACK]

 draft-zeilenga-ldap-namedref-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3296 RFC3297 Content Negotiation for Messaging Services based on Email G. Klyne R. Iwazaki D. Crocker July 2002 ASCII 97094 46 facsimile

This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK]

 draft-ietf-fax-content-negotiation-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3297 10.17487/RFC3297 RFC3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements I. Faynberg J. Gato H. Lu L. Slutsman August 2002 ASCII 36560 17 support

This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community.

 draft-ietf-spirits-reqs-04 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3298 RFC3299 Request for Comments Summary RFC Numbers 3200-3299 S. Ginoza December 2003 ASCII 63813 30 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3299 RFC3300 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza A. De La Cruz November 2002 ASCII 127805 49 RFC3000 RFC3600 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3300 10.17487/RFC3300 RFC3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions Y. T'Joens P. Crivellari B. Sales June 2002 ASCII 42756 19 draft-ietf-l2tpext-atmext-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3301 RFC3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty September 2002 ASCII 15183 8 TIFF Multipurpose Internet Mail extensions draft-ietf-fax-tiff-regbis-05 RFC2302 DRAFT STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3302 RFC3303 Middlebox communication architecture and framework P. Srisuresh J. Kuthan J. Rosenberg A. Molitor A. Rayhan August 2002 ASCII 91209 34 midcom draft-ietf-midcom-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3303 RFC3304 Middlebox Communications (midcom) Protocol Requirements R. P. Swale P. A. Mart P. Sijben S. Brim M. Shore August 2002 ASCII 16187 9 nat network address protocol firewall middleboxes draft-ietf-midcom-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv midcom http://www.rfc-editor.org/errata_search.php?rfc=3304 10.17487/RFC3304 RFC3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations M. Mealling Editor R. Denenberg Editor August 2002 ASCII 21793 11 internet engineering task force draft-mealling-uri-ig-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3305 10.17487/RFC3305 RFC3306 Unicast-Prefix-based IPv6 Multicast Addresses B. Haberman D. Thaler August 2002 ASCII 12713 7 internet protocol draft-ietf-ipngwg-uni-based-mcast-03 RFC3956 RFC4489 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3306 RFC3307 Allocation Guidelines for IPv6 Multicast Addresses B. Haberman August 2002 ASCII 15742 8 internet protocol draft-ietf-malloc-ipv6-guide-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3307 RFC3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension P. Calhoun W. Luo D. McPherson K. Peirce November 2002 ASCII 21536 10 per hop behavior phb diffserv draft-ietf-l2tpext-ds-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3308 RFC3309 Stream Control Transmission Protocol (SCTP) Checksum Change J. Stone R. Stewart D. Otis September 2002 ASCII 34670 17 adler-32 checksum error detection draft-ietf-tsvwg-sctpcsum-07 RFC4960 RFC2960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3309 RFC3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) A. Niemi J. Arkko V. Torvinen September 2002 ASCII 36985 18 one-time password generation mechanism umts universal mobile telecommunications system draft-ietf-sip-digest-aka-03 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3310 RFC3311 The Session Initiation Protocol (SIP) UPDATE Method J. Rosenberg October 2002 ASCII 28125 13 parameters media streams draft-ietf-sip-update-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3311 RFC3312 Integration of Resource Management and Session Initiation Protocol (SIP) G. Camarillo Editor W. Marshall Editor J. Rosenberg October 2002 ASCII 65757 30 PS 655218 PDF 130391 qos quality of service precondition draft-ietf-sip-manyfolks-resource-07 RFC4032 RFC5027 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3312 10.17487/RFC3312 RFC3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization W. Marshall Editor January 2003 ASCII 36866 16 qos quality of service draft-ietf-sip-call-auth-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3313 RFC3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards M. Wasserman Editor September 2002 ASCII 48168 23 internet protocol draft-ietf-ipv6-3gpp-recommend-02 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3314 10.17487/RFC3314 RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor J. Bound B. Volz T. Lemon C. Perkins M. Carney July 2003 ASCII 231402 101 internet protocol parameters addresses draft-ietf-dhc-dhcpv6-28 RFC4361 RFC5494 RFC6221 RFC6422 RFC6644 RFC7083 RFC7227 RFC7283 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3315 10.17487/RFC3315 RFC3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts J. Arkko G. Kuijpers H. Soliman J. Loughney J. Wiljakka April 2003 ASCII 48741 22 links bandwidth draft-ietf-ipv6-cellular-host-03 RFC7066 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3316 RFC3317 Differentiated Services Quality of Service Policy Information Base K. Chan R. Sahita S. Hahn K. McCloghrie March 2003 ASCII 188553 96 pib differentiated services architecture draft-ietf-diffserv-pib-08 HISTORIC INFORMATIONAL IETF tsv diffserv 10.17487/RFC3317 RFC3318 Framework Policy Information Base R. Sahita Editor S. Hahn K. Chan K. McCloghrie March 2003 ASCII 144530 70

This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning.

Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).

One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.

As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each.

 draft-ietf-rap-frameworkpib-09 HISTORIC INFORMATIONAL IETF ops rap 10.17487/RFC3318 RFC3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers H. Schulzrinne B. Volz July 2003 ASCII 14444 7 outbound proxy servers draft-ietf-sip-dhcpv6-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3319 RFC3320 Signaling Compression (SigComp) R. Price C. Bormann J. Christoffersson H. Hannu Z. Liu J. Rosenberg January 2003 ASCII 137035 62 sip session initiation protocol udvm universal decompressor virtual machine draft-ietf-rohc-sigcomp-07 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3320 RFC3321 Signaling Compression (SigComp) - Extended Operations H. Hannu J. Christoffersson S. Forsgren K.-C. Leung Z. Liu R. Price January 2003 ASCII 39433 19 sip session initiation protocol udvm universal decompressor virtual machine draft-ietf-rohc-sigcomp-extended-04 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3321 RFC3322 Signaling Compression (SigComp) Requirements & Assumptions H. Hannu January 2003 ASCII 27533 13 sip session initiation protocol wireless cellular sdp session description protocol draft-ietf-rohc-signaling-req-assump-06 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3322 RFC3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) J. Peterson November 2002 ASCII 54116 22 privacy service draft-ietf-sip-privacy-general-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3323 RFC3324 Short Term Requirements for Network Asserted Identity M. Watson November 2002 ASCII 21964 11 session initiation protocol sip ua user agent draft-ietf-sipping-nai-reqs-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3324 RFC3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks C. Jennings J. Peterson M. Watson November 2002 ASCII 36170 18 trust domain draft-ietf-sip-asserted-identity-01 RFC5876 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3325 10.17487/RFC3325 RFC3326 The Reason Header Field for the Session Initiation Protocol (SIP) H. Schulzrinne D. Oran G. Camarillo December 2002 ASCII 15695 8 heterogeneous error response forking problem herfp

The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]

 draft-ietf-sip-reason-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3326 RFC3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts D. Willis B. Hoeneisen December 2002 ASCII 36493 17 3gpp register contact path registrar user agent ua draft-willis-sip-path-08 RFC5626 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3327 10.17487/RFC3327 RFC3328 RFC3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP) J. Arkko V. Torvinen G. Camarillo A. Niemi T. Haukka January 2003 ASCII 51503 24 ua user agent draft-ietf-sip-sec-agree-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3329 10.17487/RFC3329 RFC3330 Special-Use IPv4 Addresses IANA September 2002 ASCII 16200 7 internet protocol space assignments draft-iana-special-ipv4-05 RFC5735 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3330 10.17487/RFC3330 RFC3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer K. Morneault R. Dantu G. Sidebottom B. Bidulock J. Heitz September 2002 ASCII 210807 94 sctp stream control transmission protocol sg signaling gateway media gateway controller mgc draft-ietf-sigtran-m2ua-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=3331 10.17487/RFC3331 RFC3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) G. Sidebottom Editor K. Morneault Editor J. Pastor-Balbas Editor September 2002 ASCII 265055 120 isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway draft-ietf-sigtran-m3ua-12 RFC4666 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3332 RFC3334 Policy-Based Accounting T. Zseby S. Zander C. Carle October 2002 ASCII 103014 44 measurement metering meter configuration qos auditing aaa aaa architecture inter-domain accounting draft-irtf-aaaarch-pol-acct-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3334 RFC3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Drummond C. Shih September 2002 ASCII 59687 29 multipurpose internet mail extensions edi draft-ietf-ediint-as1-17 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint 10.17487/RFC3335 RFC3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) B. Thompson T. Koren B. Buffam December 2002 ASCII 33631 16 point-to-point protocol atm aal2 datagram packets draft-ietf-pppext-ppp-over-aal2-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3336 RFC3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 B. Thompson T. Koren B. Buffam December 2002 ASCII 14911 7 point-to-point protocol atm aal2 encapsulation draft-ietf-pppext-ppp-over-aal2-class-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3337 RFC3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA) S. Lee M-K. Shin Y-J. Kim E. Nordmark A. Durand October 2002 ASCII 34480 17 draft-ietf-ngtrans-bia-05 RFC6535 EXPERIMENTAL EXPERIMENTAL IETF ops ngtrans 10.17487/RFC3338 RFC3339 Date and Time on the Internet: Timestamps G. Klyne C. Newman July 2002 ASCII 35064 18 gregorian calendar iso draft-ietf-impp-datetime-05 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3339 10.17487/RFC3339 RFC3340 The Application Exchange Core M. Rose G. Klyne D. Crocker July 2002 ASCII 74266 40 APEX draft-ietf-apex-core-06 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3340 RFC3341 The Application Exchange (APEX) Access Service M. Rose G. Klyne D. Crocker July 2002 ASCII 46675 26 APEX draft-ietf-apex-access-08 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3341 RFC3342 The Application Exchange (APEX) Option Party Pack, Part Deux! E. Dixon H. Franklin J. Kint G. Klyne D. New S. Pead M. Rose M. Schwartz July 2002 ASCII 34300 22 datagram service core relaying mesh draft-ietf-apex-party-04 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3342 RFC3343 The Application Exchange (APEX) Presence Service M. Rose G. Klyne D. Crocker April 2003 ASCII 42043 23 endpoint draft-ietf-apex-presence-06 HISTORIC EXPERIMENTAL IETF app apex 10.17487/RFC3343 RFC3344 IP Mobility Support for IPv4 C. Perkins Editor August 2002 ASCII 241041 99 MOBILEIPSUPIP Internet Protocol RFC3220 RFC5944 RFC4636 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3344 10.17487/RFC3344 RFC3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition D. McPherson V. Gill D. Walton A. Retana August 2002 ASCII 38137 19 idr ibgp draft-ietf-idr-route-oscillation-01 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3345 10.17487/RFC3345 RFC3346 Applicability Statement for Traffic Engineering with MPLS J. Boyle V. Gill A. Hannan D. Cooper D. Awduche B. Christian W.S. Lai August 2002 ASCII 33754 14 multiprotocol label switching te draft-ietf-tewg-te-applicability-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3346 RFC3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations M. Krueger R. Haagens July 2002 ASCII 58097 26 scsi tcp. storage fibre channel draft-ietf-ips-iscsi-reqmts-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3347 RFC3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension M. Gahrns R. Cheng July 2002 ASCII 11868 6 children draft-gahrns-imap-child-mailbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3348 10.17487/RFC3348 RFC3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force M. Rose July 2002 ASCII 7916 6 beep draft-mrose-beep-transientid-02 BCP0059 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3349 RFC3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals N. Charlton M. Gasson G. Gybels M. Spanner A. van Wijk August 2002 ASCII 33894 17 relay service transcoding service textphone draft-ietf-sipping-deaf-req-03 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3351 RFC3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status K. Zeilenga March 2003 ASCII 7265 4 CLDAP CLDAP Presentation Address Application Entity Title draft-zeilenga-cldap-02 RFC1798 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3352 RFC3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment D. Ooms B. Sales W. Livens A. Acharya F. Griffoul F. Ansari August 2002 ASCII 65860 30 inrternet protocol l2 multicast routing protocoln draft-ietf-mpls-multicast-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3353 RFC3354 Internet Open Trading Protocol Version 2 Requirements D. Eastlake 3rd August 2002 ASCII 9671 6 payment ecommerce merchant customer delivery signature messaging commerce sale draft-ietf-trade-iotp2-req-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3354 RFC3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) A. Singh R. Turner R. Tio S. Nanji August 2002 ASCII 25114 13 link dial-up server asynchronous transfer mode draft-ietf-l2tpext-l2tp-atm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3355 RFC3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines G. Fishman S. Bradner August 2002 ASCII 27149 12 internet society engineering task force draft-fishman-2436bis-02 RFC2436 RFC6756 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3356 RFC3357 One-way Loss Pattern Sample Metrics R. Koodli R. Ravikanth August 2002 ASCII 30570 15 packets voice video stream draft-ietf-ippm-loss-pattern-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3357 RFC3358 Optional Checksums in Intermediate System to Intermediate System (ISIS) T. Przygienda August 2002 ASCII 8266 4 type length value complete sequence number partial data draft-ietf-isis-wg-snp-checksum-03 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3358 RFC3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System T. Przygienda August 2002 ASCII 7843 5 is-is igp osi complete sequence number partial data draft-ietf-isis-wg-tlv-codepoints-01 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=3359 10.17487/RFC3359 RFC3360 Inappropriate TCP Resets Considered Harmful S. Floyd August 2002 ASCII 46748 19 transmission control protocol rst bit connection draft-floyd-tcp-reset-04 BCP0060 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3360 RFC3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers H. Schulzrinne August 2002 ASCII 12549 7 proxy servers draft-ietf-sip-dhcp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3361 RFC3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration G. Parsons August 2002 ASCII 8301 5 draft-parsons-itu-t38-reg-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3362 RFC3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) R. Bush A. Durand B. Fink O. Gudmundsson T. Hain August 2002 ASCII 11055 6 reverse mapping label binary draft-ietf-dnsext-ipv6-addresses-02 RFC2673 RFC2874 RFC6672 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3363 10.17487/RFC3363 RFC3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) R. Austein August 2002 ASCII 26544 11 reverse mapping rrs resource records draft-ietf-dnsext-ipv6-dns-tradeoffs-02 RFC2673 RFC2874 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3364 10.17487/RFC3364 RFC3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols J. Schiller August 2002 ASCII 16411 8 ietf draft-ietf-saag-whyenc-00 BCP0061 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3365 RFC3366 Advice to link designers on link Automatic Repeat reQuest (ARQ) G. Fairhurst L. Wood August 2002 ASCII 66097 27 tcp/ip subnetworks draft-ietf-pilc-link-arq-issues-04 BCP0062 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3366 RFC3367 Common Name Resolution Protocol (CNRP) N. Popp M. Mealling M. Moseley August 2002 ASCII 86889 42 unique resource locators client applications draft-ietf-cnrp-12 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3367 RFC3368 The 'go' URI Scheme for the Common Name Resolution Protocol M. Mealling August 2002 ASCII 12726 8 uniform resource identifier draft-ietf-cnrp-uri-07 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3368 RFC3369 Cryptographic Message Syntax (CMS) R. Housley August 2002 ASCII 113975 52 digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-rfc2630bis-08 RFC2630 RFC3211 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3369 10.17487/RFC3369 RFC3370 Cryptographic Message Syntax (CMS) Algorithms R. Housley August 2002 ASCII 51001 24 digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-cmsalg-08 RFC2630 RFC3211 RFC5754 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3370 10.17487/RFC3370 RFC3371 Layer Two Tunneling Protocol "L2TP" Management Information Base E. Caves P. Calhoun R. Wheeler August 2002 ASCII 139974 70 mib draft-ietf-l2tpext-l2tp-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3371 RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures A. Vemuri J. Peterson September 2002 ASCII 49893 23 pstn public switch telephone network draft-ietf-sipping-sipt-04 BCP0063 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3372 10.17487/RFC3372 RFC3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies D. Katz R. Saluja September 2002 ASCII 19522 9 links handshake draft-ietf-isis-3way-06 RFC5303 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3373 RFC3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network J. Kempf Editor September 2002 ASCII 28245 14 aaa qos authentication authorization accounting quality of service header compression draft-ietf-seamoby-context-transfer-problem-stat-04 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3374 RFC3375 Generic Registry-Registrar Protocol Requirements S. Hollenbeck September 2002 ASCII 46022 21 rrp client server domain names draft-ietf-provreg-grrp-reqs-06 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3375 RFC3376 Internet Group Management Protocol, Version 3 B. Cain S. Deering I. Kouvelas B. Fenner A. Thyagarajan October 2002 ASCII 119726 53 IGMP IGMP multicast routing IP Internet Protocol draft-ietf-idmr-igmp-v3-11 RFC2236 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=3376 10.17487/RFC3376 RFC3377 Lightweight Directory Access Protocol (v3): Technical Specification J. Hodges R. Morgan September 2002 ASCII 9981 6 ldap ldapv3 draft-ietf-ldapbis-ldapv3-ts-01 RFC4510 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=3377 10.17487/RFC3377 RFC3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams R. Housley S. Hollenbeck September 2002 ASCII 18803 9 internet protocol ip 97 draft-housley-etherip-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3378 RFC3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements D. Pinkas R. Housley September 2002 ASCII 32455 15 dpv dpd public key certificates draft-ietf-pkix-dpv-dpd-req-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3379 RFC3380 Internet Printing Protocol (IPP): Job and Printer Set Operations T. Hastings R. Herriot C. Kugler H. Lewis September 2002 ASCII 132044 59 IPP-E-T IPP application media-type media type draft-ietf-ipp-job-printer-set-ops-05 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3380 RFC3381 Internet Printing Protocol (IPP): Job Progress Attributes T. Hastings H. Lewis R. Bergman September 2002 ASCII 36595 17 IPP-E-T IPP application media-type media type draft-ietf-ipp-job-prog-02 RFC8011 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3381 10.17487/RFC3381 RFC3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax R. deBry T. Hastings R. Herriot K. Ocke P. Zehler September 2002 ASCII 78173 38 IPP-E-T IPP application media-type media type draft-ietf-ipp-collection-05 RFC8010 RFC8011 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3382 10.17487/RFC3382 RFC3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga September 2002 ASCII 45893 23 guidelines extensible values draft-ietf-ldapbis-iana-09 RFC4520 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis 10.17487/RFC3383 RFC3384 Lightweight Directory Access Protocol (version 3) Replication Requirements E. Stokes R. Weiser R. Moats R. Huber October 2002 ASCII 66871 31 ldapv3 data interoperability synchronization multi-master draft-ietf-ldup-replica-req-12 INFORMATIONAL INFORMATIONAL IETF app ldup 10.17487/RFC3384 RFC3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations D. Sheinwald J. Satran P. Thaler V. Cavanna September 2002 ASCII 53450 23 error detection code draft-sheinwald-iscsi-crc-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3385 10.17487/RFC3385 RFC3386 Network Hierarchy and Multilayer Survivability W. Lai Editor D. McDysan Editor November 2002 ASCII 65345 27 service provider packet networks protection restoration recovery draft-ietf-tewg-restore-hierarchy-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3386 RFC3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network M. Eder H. Chaskar S. Nag September 2002 ASCII 52693 19 internet protocol packts fuel-service draft-irtf-smrg-ipsmf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3387 RFC3388 Grouping of Media Lines in the Session Description Protocol (SDP) G. Camarillo G. Eriksson J. Holler H. Schulzrinne December 2002 ASCII 39365 11 formats attribute port host interfaces fid flow identification lip synchronization ls draft-ietf-mmusic-fid-06 RFC5888 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3388 RFC3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) R. Zopf September 2002 ASCII 17018 8 codecs audio multimedia draft-ietf-avt-rtp-cn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3389 10.17487/RFC3389 RFC3390 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge October 2002 ASCII 36177 15 transmission control protocol draft-ietf-tsvwg-initwin-04 RFC2414 RFC2581 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3390 10.17487/RFC3390 RFC3391 The MIME Application/Vnd.pwg-multiplexed Content-Type R. Herriot December 2002 ASCII 54739 25 multipurpose internet mail extensions media type draft-herriot-application-multiplexed-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3391 RFC3392 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder November 2002 ASCII 9885 6 border gateway protocol draft-ietf-idr-rfc2842bis-02 RFC2842 RFC5492 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC3392 RFC3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) C. Demichelis P. Chimento November 2002 ASCII 47731 21 internet protocol ipdv draft-ietf-ippm-ipdv-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC3393 RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm J. Schaad R. Housley September 2002 ASCII 73072 41 security draft-ietf-smime-aes-keywrap-00 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3394 10.17487/RFC3394 RFC3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions A. Bierman C. Bucci R. Dietz A. Warth September 2002 ASCII 43862 21 RMON-MIB management information base draft-ietf-rmonmib-appverbs-04 RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3395 RFC3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) T. Lemon S. Cheshire November 2002 ASCII 18779 9 octet packet code draft-ietf-dhc-concat-05 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3396 RFC3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option B. Aboba S. Cheshire November 2002 ASCII 15446 8 dns client client server draft-aboba-dhc-domsearch-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3397 RFC3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping G. Camarillo A. B. Roach J. Peterson L. Ong December 2002 ASCII 166197 68 signaling system no. 7 ss7 pstn public switched telephone network draft-ietf-sipping-isup-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3398 10.17487/RFC3398 RFC3400 RFC3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS M. Mealling October 2002 ASCII 10172 6 NAPTR domain name system RR

This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.

 draft-ietf-urn-ddds-toc-03 RFC2915 RFC2168 RFC2276 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3401 10.17487/RFC3401 RFC3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm M. Mealling October 2002 ASCII 38925 17 NAPTR domain name system RR

This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

 draft-ietf-urn-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn 10.17487/RFC3402 RFC3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database M. Mealling October 2002 ASCII 31058 14 NAPTR domain name system RR

This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

 draft-ietf-urn-dns-ddds-database-09 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3403 10.17487/RFC3403 RFC3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) M. Mealling October 2002 ASCII 40124 18 NAPTR domain name system RR

This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

 draft-ietf-urn-uri-res-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3404 10.17487/RFC3404 RFC3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures M. Mealling October 2002 ASCII 19469 10 uniform resource identifiers

This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urn-net-procedures-11 BCP0065 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3405 10.17487/RFC3405 RFC3406 Uniform Resource Names (URN) Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Faltstrom October 2002 ASCII 43707 22 namespaces applications structure

This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urn-rfc2611bis-04 RFC2611 BCP0066 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3406 10.17487/RFC3406 RFC3407 Session Description Protocol (SDP) Simple Capability Declaration F. Andreasen October 2002 ASCII 21133 10 SDPng

This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS-TRACK]

 draft-andreasen-mmusic-sdp-simcap-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3407 10.17487/RFC3407 RFC3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile Z. Liu K. Le December 2002 ASCII 14805 7 single-octet packet size

This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-lla-r-mode-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3408 RFC3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression K. Svanbro December 2002 ASCII 25815 11 rohc algorithms

This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community.

 draft-ietf-rohc-rtp-lower-layer-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3409 RFC3410 Introduction and Applicability Statements for Internet-Standard Management Framework J. Case R. Mundy D. Partain B. Stewart December 2002 ASCII 61461 27 snmp simple protocol snmpv3

The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.

 draft-ietf-snmpv3-rfc2570bis-03 RFC2570 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3410 10.17487/RFC3410 RFC3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks D. Harrington R. Presuhn B. Wijnen December 2002 ASCII 140096 64 ARCH-SNMP simple protocol network management

This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]

 draft-ietf-snmpv3-arch-v2-02 RFC2571 RFC5343 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3411 RFC3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen December 2002 ASCII 95710 43 MPD-SNMP processing models multiple

This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS-TRACK]

 draft-ietf-snmpv3-mpd-v2-02 RFC2572 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3412 RFC3413 Simple Network Management Protocol (SNMP) Applications D. Levi P. Meyer B. Stewart December 2002 ASCII 153719 74 SNMP-APP simple network management protocol proxy operations command

This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS-TRACK]

 draft-ietf-snmpv3-appl-v3-01 RFC2573 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3413 10.17487/RFC3413 RFC3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen December 2002 ASCII 193558 88 USM-SNMPV3 message level mib information base

This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]

 draft-ietf-snmpv3-usm-v2-rfc2574bis-01 RFC2574 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3414 10.17487/RFC3414 RFC3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie December 2002 ASCII 82046 39 VACM-SNMP mib information base

This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS-TRACK]

 draft-ietf-snmpv3-vacm-v2-01 RFC2575 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3415 10.17487/RFC3415 RFC3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII 70043 31 OPS-MIB Simple Network Management Protocol Version 2

This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS-TRACK]

 draft-ietf-snmpv3-update-proto-08 RFC1905 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3416 10.17487/RFC3416 RFC3417 Transport Mappings for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII 38650 19 TRANS-MIB Simple Network Management Protocol Version 2

This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS-TRACK]

 draft-ietf-snmpv3-update-transmap-08 RFC1906 RFC4789 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3417 RFC3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII 49096 26 SNMPv2-MIB Simple Network Management Protocol Version 2

This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]

 draft-ietf-snmpv3-update-mib-07 RFC1907 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3418 10.17487/RFC3418 RFC3419 Textual Conventions for Transport Addresses M. Daniele J. Schoenwaelder December 2002 ASCII 37466 18 mib management information base

This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS-TRACK]

 draft-ietf-ops-taddress-mib-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3419 RFC3420 Internet Media Type message/sipfrag R. Sparks November 2002 ASCII 14745 8 mime multipurpose internet mail extesions

This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS-TRACK]

 draft-ietf-sip-sipfrag-00 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3420 10.17487/RFC3420 RFC3421 Select and Sort Extensions for the Service Location Protocol (SLP) W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome November 2002 ASCII 15260 8 user agent url service reply ua svrrply

This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community.

 draft-zhao-slp-customization-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3421 RFC3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS) O. Okamoto M. Maruyama T. Sajima November 2002 ASCII 37576 19 tunneling ethernet frames

This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community.

 draft-okamoto-mac-over-mapos-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3422 RFC3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0 K. Zhang E. Elkin November 2002 ASCII 97731 45 data delivery message format template-based client/server

This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community.

 draft-kzhang-crane-protocol-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3423 RFC3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation L. Daigle Editor IAB November 2002 ASCII 18165 9 nat middleboxes

As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.

 draft-iab-unsaf-considerations-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3424 10.17487/RFC3424 RFC3425 Obsoleting IQUERY D. Lawrence November 2002 ASCII 8615 5 dns lookups domain

The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK]

 draft-ietf-dnsext-obsolete-iquery-04 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3425 RFC3426 General Architectural and Policy Considerations S. Floyd November 2002 ASCII 54868 23 internet architecture

This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community.

 draft-iab-considerations-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3426 RFC3427 Change Process for the Session Initiation Protocol (SIP) A. Mankin S. Bradner R. Mahy D. Willis J. Ott B. Rosen December 2002 ASCII 26234 12 sipping

This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-tsvarea-sipchange-03 RFC5727 RFC3968 RFC3969 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3427 RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging B. Campbell Editor J. Rosenberg H. Schulzrinne C. Huitema D. Gurle December 2002 ASCII 41475 18 im message method

Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS-TRACK]

 draft-ietf-sip-message-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3428 10.17487/RFC3428 RFC3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions H. Ohta November 2002 ASCII 10903 6 reserved lavel values

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community.

 draft-ohta-mpls-label-value-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3429 RFC3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping J. Schoenwaelder December 2002 ASCII 21527 10 snmp tcp

This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-nmrg-snmp-tcp-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3430 RFC3431 Sieve Extension: Relational Tests W. Segmuller December 2002 ASCII 12849 8 sieve mail filtering language

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS-TRACK]

 draft-segmuller-sieve-relation-02 RFC5231 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3431 RFC3432 Network performance measurement with periodic streams V. Raisanen G. Grotefeld A. Morton November 2002 ASCII 52493 23 cbr constant bit rate periodic sampling poisson sampling

This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]

 draft-ietf-ippm-npmps-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC3432 RFC3433 Entity Sensor Management Information Base A. Bierman D. Romascanu K.C. Norseth December 2002 ASCII 31857 17 mib physical sensors snmp

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS-TRACK]

 draft-ietf-entmib-sensor-mib-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=3433 10.17487/RFC3433 RFC3434 Remote Monitoring MIB Extensions for High Capacity Alarms A. Bierman K. McCloghrie December 2002 ASCII 51072 24 rmon counter64 smiv2 snmp

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS-TRACK]

 draft-ietf-rmonmib-hc-alarm-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3434 RFC3435 Media Gateway Control Protocol (MGCP) Version 1.0 F. Andreasen B. Foster January 2003 ASCII 467084 210 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. This memo provides information for the Internet community.

 draft-andreasen-mgcp-rfc2705bis-05 RFC2705 RFC3661 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3435 10.17487/RFC3435 RFC3436 Transport Layer Security over Stream Control Transmission Protocol A. Jungmaier E. Rescorla M. Tuexen December 2002 ASCII 16333 9 sctp tls

This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tls-over-sctp-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3436 RFC3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation W. Palter W. Townsley December 2002 ASCII 20820 10 l2tp lcp

This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS-TRACK]

 draft-ietf-l2tpext-link-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3437 RFC3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update W. Townsley December 2002 ASCII 9135 5 L2TP ppp point-to-point protocol packets

This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-l2tpext-rfc2661-iana-01 BCP0068 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int l2tpext 10.17487/RFC3438 RFC3439 Some Internet Architectural Guidelines and Philosophy R. Bush D. Meyer December 2002 ASCII 70333 28 IAB

This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community.

 draft-ymbk-arch-guidelines-03 RFC1958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3439 10.17487/RFC3439 RFC3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines F. Ly G. Bathrick December 2002 ASCII 76058 36 simple network management protocol mib adsl asymmetric digital subscriber line

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 additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS-TRACK]

 draft-ietf-adslmib-adslext-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3440 RFC3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP) R. Kumar January 2003 ASCII 122455 50 connection codec profile

This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community.

 draft-rajeshkumar-mgcp-atm-package-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3441 RFC3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 T. Lemon S. Cheshire B. Volz December 2002 ASCII 19370 9 Dynamic Host Configuration Protocol Bootstrap

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS-TRACK]

 draft-ietf-dhc-csr-07 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3442 RFC3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks P. Agarwal B. Akyol January 2003 ASCII 18749 10 label stack encoding uniform model pipe model

This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS-TRACK]

 draft-ietf-mpls-ttl-04 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3443 RFC3444 On the Difference between Information Models and Data Models A. Pras J. Schoenwaelder January 2003 ASCII 18596 8 network management

There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.

 draft-irtf-nmrg-im-dm-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3444 RFC3445 Limiting the Scope of the KEY Resource Record (RR) D. Massey S. Rose December 2002 ASCII 20947 10 DNS-SECEXT dns authentication

This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS-TRACK]

 draft-ietf-dnsext-restrict-key-for-dnssec-04 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3445 10.17487/RFC3445 RFC3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) D. Kim D. Meyer H. Kilmer D. Farinacci January 2003 ASCII 14792 7 sparse mode single shared-tree

This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.

 draft-ietf-mboned-anycast-rp-08 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3446 RFC3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 J. Jonsson B. Kaliski February 2003 ASCII 143173 72 data public key cryptosystem

This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.

 draft-jonsson-pkcs1-v2dot1-00 RFC2437 RFC8017 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3447 10.17487/RFC3447 RFC3448 TCP Friendly Rate Control (TFRC): Protocol Specification M. Handley S. Floyd J. Padhye J. Widmer January 2003 ASCII 52657 24 congestion unicast streaming media

This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tfrc-05 RFC5348 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3448 10.17487/RFC3448 RFC3449 TCP Performance Implications of Network Path Asymmetry H. Balakrishnan V. Padmanabhan G. Fairhurst M. Sooriyabandara December 2002 ASCII 108839 41 links sender receiver ack

This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-asym-08 BCP0069 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3449 RFC3450 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby J. Gemmell L. Vicisano L. Rizzo J. Crowcroft December 2002 ASCII 86022 34 content delivery congestion control receivers

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-pi-alc-08 RFC5775 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3450 RFC3451 Layered Coding Transport (LCT) Building Block M. Luby J. Gemmell L. Vicisano L. Rizzo M. Handley J. Crowcroft December 2002 ASCII 72594 29 content stream delivery multicast internet protocol

Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-lct-04 RFC5651 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3451 RFC3452 Forward Error Correction (FEC) Building Block M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII 38368 16 content stream delivery multicast internet protocol

This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-fec-07 RFC5052 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3452 RFC3453 The Use of Forward Error Correction (FEC) in Reliable Multicast M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII 46853 18 ip internet protocol data transport

This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community.

 draft-ietf-rmt-info-fec-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3453 RFC3454 Preparation of Internationalized Strings ("stringprep") P. Hoffman M. Blanchet December 2002 ASCII 138684 91 unicode text internationalization

This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS-TRACK]

 draft-hoffman-stringprep-07 RFC7564 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3454 10.17487/RFC3454 RFC3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) M. Garcia-Martin E. Henrikson D. Mills January 2003 ASCII 79620 34

This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.

 draft-garcia-sipping-3gpp-p-headers-02 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3455 10.17487/RFC3455 RFC3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode B. Patel B. Aboba S. Kelly V. Gupta January 2003 ASCII 40340 18 security internet protocol

This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS-TRACK]

 draft-ietf-ipsec-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsra 10.17487/RFC3456 RFC3457 Requirements for IPsec Remote Access Scenarios S. Kelly S. Ramamoorthi January 2003 ASCII 75167 31 ipsra common remote access scenarios

IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community.

 draft-ietf-ipsra-reqmts-05 INFORMATIONAL INFORMATIONAL IETF sec ipsra 10.17487/RFC3457 RFC3458 Message Context for Internet Mail E. Burger E. Candell C. Eliot G. Klyne January 2003 ASCII 34181 17 user agent ua

This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

 draft-ietf-vpim-hint-08 RFC3938 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3458 RFC3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter E. Burger January 2003 ASCII 54282 24 body parts content-disposition

This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS-TRACK]

 draft-ietf-vpim-cc-08 RFC3204 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3459 RFC3460 Policy Core Information Model (PCIM) Extensions B. Moore Editor January 2003 ASCII 212453 93 CIM common schema object-oriented

This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS-TRACK]

 draft-ietf-policy-pcim-ext-08 RFC3060 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3460 RFC3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) K. Moore January 2003 ASCII 76076 38 SMTP-DSN simple mail transfer protocol

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

 draft-moore-rfc1891bis-02 RFC1891 RFC3798 RFC3885 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3461 10.17487/RFC3461 RFC3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 2003 ASCII 12186 7 MIME-RPT Multipurpose Internet Mail Extensions

The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS-TRACK]

 draft-vaudreuil-1892bis-02 RFC1892 RFC6522 RFC5337 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3462 RFC3463 Enhanced Mail System Status Codes G. Vaudreuil January 2003 ASCII 31832 16 EMS-CODE simple mail transfer protocol SMTP

This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK]

 draft-vaudreuil-1893bis-03 RFC1893 RFC3886 RFC4468 RFC4865 RFC4954 RFC5248 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3463 10.17487/RFC3463 RFC3464 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 2003 ASCII 83060 40 DSN Multipurpose Internet Mail Extensions Content Type

This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS-TRACK]

 draft-vaudreuil-1894bis-02 RFC1894 RFC4865 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3464 10.17487/RFC3464 RFC3465 TCP Congestion Control with Appropriate Byte Counting (ABC) M. Allman February 2003 ASCII 23486 10 transmission control protocol security performance

This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community.

 draft-allman-tcp-abc-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3465 RFC3466 A Model for Content Internetworking (CDI) M. Day B. Cain G. Tomlinson P. Rzewski February 2003 ASCII 37684 17 distribution peering

Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community.

 draft-ietf-cdi-model-02 RFC7336 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3466 RFC3467 Role of the Domain Name System (DNS) J. Klensin February 2003 ASCII 84570 31 history internationalization unicode ascii multilingual names

This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.

 draft-klensin-dns-role-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3467 RFC3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols L. Andersson G. Swallow February 2003 ASCII 22072 11 rsvp-te ldp resource reservation protocol label distribution

This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community.

 draft-andersson-mpls-sig-decision-03 RFC3212 RFC3472 RFC3475 RFC3476 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3468 10.17487/RFC3468 RFC3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery V. Sharma Editor F. Hellstrand Editor February 2003 ASCII 89331 40 routing traffic

Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community.

 draft-ietf-mpls-recovery-frmwrk-08 RFC5462 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3469 RFC3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols S. Hollenbeck M. Rose L. Masinter January 2003 ASCII 64252 28 data documents structure

The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hollenbeck-ietf-xml-guidelines-07 BCP0070 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3470 10.17487/RFC3470 RFC3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description L. Berger Editor January 2003 ASCII 72105 34 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]

 draft-ietf-mpls-generalized-signaling-09 RFC4201 RFC4328 RFC4872 RFC6002 RFC6003 RFC6205 RFC7074 RFC7699 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3471 10.17487/RFC3471 RFC3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions P. Ashwood-Smith Editor L. Berger Editor January 2003 ASCII 49006 23 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

 draft-ietf-mpls-generalized-cr-ldp-07 RFC3468 RFC4201 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3472 RFC3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions L. Berger Editor January 2003 ASCII 91808 42 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

 draft-ietf-mpls-generalized-rsvp-te-09 RFC4003 RFC4201 RFC4420 RFC4783 RFC4874 RFC4873 RFC4974 RFC5063 RFC5151 RFC5420 RFC6002 RFC6003 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3473 10.17487/RFC3473 RFC3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) Z. Lin D. Pendarakis March 2003 ASCII 52551 25 sonet sdh

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.

 draft-lin-ccamp-gmpls-ason-rsvpte-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3474 RFC3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON) O. Aboul-Magd March 2003 ASCII 29995 13 label switching protocol itu-t

Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community.

 draft-aboulmagd-ccamp-crldp-ason-ext-02 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3475 RFC3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling B. Rajagopalan March 2003 ASCII 22009 11 oif optical interworking forum uni user network interface

The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community.

 draft-bala-uni-ldp-rsvp-extensions-04 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3476 RFC3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) K. Kompella Y. Rekhter January 2003 ASCII 19899 9 mpls-te traffic engineering

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-unnum-08 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3477 RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M. Leelanivas Y. Rekhter R. Aggarwal February 2003 ASCII 29248 12 ldp mpls

This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-restart-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3478 RFC3479 Fault Tolerance for the Label Distribution Protocol (LDP) A. Farrel Editor February 2003 ASCII 115778 52 mpls multiprotocol label switching cr-ldp high availability restart

Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-ft-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3479 RFC3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) K. Kompella Y. Rekhter A. Kullberg February 2003 ASCII 17076 8 mpls multiprotocol label switching traffic engineering mpls-te

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3480 RFC3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks H. Inamura Editor G. Montenegro Editor R. Ludwig A. Gurtov F. Khafizov February 2003 ASCII 61528 26 paths algorithm stacks

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-2.5g3g-12 BCP0071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3481 RFC3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview M. Foster T. McGarry J. Yu February 2003 ASCII 78552 30 e.164 telephony routing

This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community.

 draft-ietf-enum-e164-gstn-np-05 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC3482 RFC3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) D. Rawlins A. Kulkarni M. Bokaemper K. Chan March 2003 ASCII 19869 10 accounting policy decision point bdp

Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community.

 draft-ietf-rap-feedback-frwk-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3483 RFC3484 Default Address Selection for Internet Protocol version 6 (IPv6) R. Draves February 2003 ASCII 55076 24 source address destination

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. [STANDARDS-TRACK]

 draft-ietf-ipv6-default-addr-select-09 RFC6724 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3484 RFC3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) M. Garcia-Martin C. Bormann J. Ott R. Price A. B. Roach February 2003 ASCII 80195 30 algorithm

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS-TRACK]

 draft-ietf-sipping-sigcomp-sip-dictionary-05 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3485 RFC3486 Compressing the Session Initiation Protocol (SIP) G. Camarillo February 2003 ASCII 24181 12

This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS-TRACK]

 draft-ietf-sip-compression-02 RFC5049 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3486 RFC3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) H. Schulzrinne February 2003 ASCII 39615 17 circuit switched network resources end system resources proxy resources emergency preparedness communications

This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community.

 draft-ietf-ieprep-sip-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3487 RFC3488 Cisco Systems Router-port Group Management Protocol (RGMP) I. Wu T. Eckert February 2003 ASCII 37152 17 multicast switches packet

This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community.

 draft-wu-rgmp-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3488 RFC3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) J. Rosenberg J. Weinberger C. Huitema R. Mahy March 2003 ASCII 117562 47 lightweight applications firewalls

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS-TRACK]

 draft-ietf-midcom-stun-05 RFC5389 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC3489 RFC3490 Internationalizing Domain Names in Applications (IDNA) P. Faltstrom P. Hoffman A. Costello March 2003 ASCII 51943 22 idn ascii characters

Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

 draft-ietf-idn-idna-14 RFC5890 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3490 10.17487/RFC3490 RFC3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) P. Hoffman M. Blanchet March 2003 ASCII 10316 7 idna applications

This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS-TRACK]

 draft-ietf-idn-nameprep-11 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn 10.17487/RFC3491 RFC3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) A. Costello March 2003 ASCII 67439 35 syntax string host label

Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]

 draft-ietf-idn-punycode-03 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3492 10.17487/RFC3492 RFC3493 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound J. McCann W. Stevens February 2003 ASCII 82570 39 internet protocol api application program interface tcp transmission control

The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.

 RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3493 RFC3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status K. Zeilenga March 2003 ASCII 9225 5 DAP interactive access X.500 LDAP lightweight directory protocol STR-REP directory names representing names

This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community.

 draft-zeilenga-ldapv2-04 RFC1484 RFC1485 RFC1487 RFC1777 RFC1778 RFC1779 RFC1781 RFC2559 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3494 10.17487/RFC3494 RFC3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration B. Beser P. Duffy Editor March 2003 ASCII 26817 13 packetcable media terminal adapter mta

This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS-TRACK]

 draft-ietf-dhc-packetcable-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3495 10.17487/RFC3495 RFC3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering A. G. Malis T. Hsiao March 2003 ASCII 11431 6 diff-serv diffserv rsvp-te resource reservation protocol

This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.

 draft-malis-diff-te-serviceclass-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3496 RFC3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video L. Gharai C. Perkins G. Goncher A. Mankin March 2003 ASCII 26094 12 real-time transport protocol hdtv high definition television

This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS-TRACK]

 draft-ietf-avt-smpte292-video-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3497 RFC3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures J. Kuhfeld J. Johnson M. Thatcher March 2003 ASCII 78701 43 mib management information base tcp/ip transmission control protocol internet protocol

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 Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS-TRACK]

 draft-ietf-atommib-sonetaps-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3498 RFC3499 Request for Comments Summary RFC Numbers 3400-3499 S. Ginoza December 2003 ASCII 88033 38 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3499 RFC3500 RFC3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 M. Crispin March 2003 ASCII 227640 108 IMAPv4 imap imapv4rev1

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]

 draft-crispin-imapv-20 RFC2060 RFC4466 RFC4469 RFC4551 RFC5032 RFC5182 RFC5738 RFC6186 RFC6858 RFC7817 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3501 10.17487/RFC3501 RFC3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension M. Crispin March 2003 ASCII 13379 7 IMAPv4 imap imapv4rev1

This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND". [STANDARDS-TRACK]

 draft-crispin-imap-multiappend-07 RFC4466 RFC4469 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3502 RFC3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP) A. Melnikov March 2003 ASCII 16937 9 mua mail user agent imap4

The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment. This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS-TRACK]

 draft-melnikov-imap-mdn-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3503 RFC3504 Internet Open Trading Protocol (IOTP) Version 1, Errata D. Eastlake March 2003 ASCII 8655 6 commerce payment system merchant system xml extensible markup language security

Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted. This informational document lists these errors and provides corrections for them. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1-errata-01 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=3504 10.17487/RFC3504 RFC3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements D. Eastlake March 2003 ASCII 13915 8 xml extensible markup language

This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing. This memo provides information for the Internet community.

 draft-ietf-trade-ecml2-req-05 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3505 RFC3506 Requirements and Design for Voucher Trading System (VTS) K. Fujimura D. Eastlake March 2003 ASCII 30945 15 generic voucher language gvl

Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described. This memo provides information for the Internet community.

 draft-ietf-trade-drt-requirements-04 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3506 RFC3507 Internet Content Adaptation Protocol (ICAP) J. Elson A. Cerpa April 2003 ASCII 98772 49 http hyper-text markup protocol request response client server

ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. This memo provides information for the Internet community.

 draft-elson-icap-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3507 10.17487/RFC3507 RFC3508 H.323 Uniform Resource Locator (URL) Scheme Registration O. Levin April 2003 ASCII 10983 6 itu-t packet networks

ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

 draft-levin-iptel-h323-url-scheme-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3508 RFC3509 Alternative Implementations of OSPF Area Border Routers A. Zinin A. Lindem D. Yeung April 2003 ASCII 24326 12 traffic backbone

Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. This memo provides information for the Internet community.

 draft-ietf-ospf-abr-alt-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3509 RFC3510 Internet Printing Protocol/1.1: IPP URL Scheme R. Herriot I. McDonald April 2003 ASCII 22009 16 IPP-E-T IPP application media-type media type

This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS-TRACK]

 draft-ietf-ipp-url-scheme-05 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3510 RFC3511 Benchmarking Methodology for Firewall Performance B. Hickman D. Newman S. Tadjudin T. Martin April 2003 ASCII 67916 34 client server traffic authentication web caching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

 draft-ietf-bmwg-firewall-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3511 RFC3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP) M. MacFaden D. Partain J. Saperia W. Tackabury April 2003 ASCII 196529 83 internet standard framework

This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This memo provides information for the Internet community.

 draft-ietf-snmpconf-bcp-12 INFORMATIONAL INFORMATIONAL IETF ops snmpconf 10.17487/RFC3512 RFC3513 Internet Protocol Version 6 (IPv6) Addressing Architecture R. Hinden S. Deering April 2003 ASCII 53920 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK]

 draft-ietf-ipngwg-addr-arch-v3-11 RFC2373 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3513 RFC3514 The Security Flag in the IPv4 Header S. Bellovin April 1 2003 ASCII 11211 6 evil evil bit

Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3514 10.17487/RFC3514 RFC3515 The Session Initiation Protocol (SIP) Refer Method R. Sparks April 2003 ASCII 47788 23 resource request call transfer

This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]

 draft-ietf-sip-refer-07 RFC7647 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3515 10.17487/RFC3515 RFC3516 IMAP4 Binary Content Extension L. Nerenberg April 2003 ASCII 14598 8 internet message acess procotol

This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS-TRACK]

 draft-nerenberg-imap-binary-07 RFC4466 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3516 10.17487/RFC3516 RFC3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP E. Blanton M. Allman K. Fall L. Wang April 2003 ASCII 27855 13 transmission control protocol retransmission congestion control

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 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS-TRACK]

 draft-allman-tcp-sack-13 RFC6675 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3517 RFC3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) M. Higashiyama F. Baker T. Liao April 2003 ASCII 82102 40 PPP-BCP point-to-point datagrams network

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE 802.1D- 1993 MAC Bridge. This document extends that specification by improving support for bridge control packets. [STANDARDS-TRACK]

 draft-ietf-pppext-rfc2878bis-01 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3518 RFC3519 Mobile IP Traversal of Network Address Translation (NAT) Devices H. Levkowetz S. Vaarala April 2003 ASCII 80522 34 Internet Protocol datagram traffic Mobile IP NAT NAPT traversal tunnelling tunneling UDP private address space keepalives port 434 MIP MIPv4 network address translation

Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS-TRACK]

 draft-ietf-mobileip-nat-traversal-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3519 10.17487/RFC3519 RFC3520 Session Authorization Policy Element L-N. Hamer B. Gage B. Kosinski H. Shieh April 2003 ASCII 63445 30 admission control resource reservation

This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-authsession-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3520 RFC3521 Framework for Session Set-up with Media Authorization L-N. Hamer B. Gage H. Shieh April 2003 ASCII 59548 25 qos quality of service streams linkage policy control admission theft service resource reservation token

Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in- line with the media streams requested (and authorized) for the session. This memo provides information for the Internet community.

 draft-ietf-rap-session-auth-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3521 RFC3522 The Eifel Detection Algorithm for TCP R. Ludwig M. Meyer April 2003 ASCII 33731 14 transmission control protocol loss recovery timestamps

The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-tcp-eifel-alg-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3522 RFC3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology J. Polk April 2003 ASCII 10190 6 naming convetions phone

This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This memo provides information for the Internet community.

 draft-polk-ieprep-scenarios-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3523 RFC3524 Mapping of Media Streams to Resource Reservation Flows G. Camarillo A. Monrad April 2003 ASCII 11249 6 sdp session description protocol srf single

This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). [STANDARDS-TRACK]

 draft-ietf-mmusic-reservation-flows-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3524 RFC3525 Gateway Control Protocol Version 1 C. Groves Editor M. Pantaleo Editor T. Anderson Editor T. Taylor Editor June 2003 ASCII 439674 213 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS-TRACK]

 draft-ietf-megaco-3015corr-02 RFC3015 RFC5125 HISTORIC PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3525 10.17487/RFC3525 RFC3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) T. Kivinen M. Kojo May 2003 ASCII 19166 10 bit groups

This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK]

 draft-ietf-ipsec-ike-modp-groups-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3526 RFC3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4 K. Kinnear M. Stapp R. Johnson J. Kumarasamy April 2003 ASCII 16831 9 dynamic host configuration protocol

This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS-TRACK]

 draft-ietf-dhc-agent-subnet-selection-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3527 RFC3528 Mesh-enhanced Service Location Protocol (mSLP) W. Zhao H. Schulzrinne E. Guttman April 2003 ASCII 35208 15 da directory agent slpda service agent sa slpv2

This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti- entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. This memo defines an Experimental Protocol for the Internet community.

 draft-zhao-slp-da-interaction-16 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3528 RFC3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) W. Harold April 2003 ASCII 23314 15 format messages clients servers

Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community.

 draft-harold-beep-xmlrpc-03 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3529 RFC3530 Network File System (NFS) version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck April 2003 ASCII 600988 275 NFSv4 network file system

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 replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rfc3010bis-04 RFC3010 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3530 10.17487/RFC3530 RFC3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block M. Blanchet April 2003 ASCII 11314 7 address plan addressing range space internet protocol

This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. This memo provides information for the Internet community.

 draft-ietf-ipv6-ipaddressassign-06 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3531 RFC3532 Requirements for the Dynamic Partitioning of Switching Elements T. Anderson J. Buerkle May 2003 ASCII 25119 11 atm asynchronous transfer mode

This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. This memo provides information for the Internet community.

 draft-ietf-gsmp-dyn-part-reqs-03 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3532 RFC3533 The Ogg Encapsulation Format Version 0 S. Pfeiffer May 2003 ASCII 32045 15 bitstream media streams video audio xiph.org multimedia media interleading format video bitstream packaging audio bitstream packaging free encapsulation format stream based storage of codec data framed bitstream

This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community.

 draft-pfeiffer-ogg-fileformat-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3533 RFC3534 The application/ogg Media Type L. Walleij May 2003 ASCII 10013 6 mime multipurpose internet mail extenstions

The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS-TRACK]

 draft-walleij-ogg-mediatype-08 RFC5334 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3534 RFC3535 Overview of the 2002 IAB Network Management Workshop J. Schoenwaelder May 2003 ASCII 42566 20 Internet Architecture Board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community.

 draft-iab-nm-workshop-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3535 RFC3536 Terminology Used in Internationalization in the IETF P. Hoffman May 2003 ASCII 64284 30 internet engineering task force

This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community.

 draft-hoffman-i18n-terms-11 RFC6365 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3536 RFC3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key J. Schaad R. Housley May 2003 ASCII 16885 9

This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD]

 draft-ietf-smime-hmac-key-wrap-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3537 10.17487/RFC3537 RFC3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura June 2003 ASCII 103475 56 payment input output parameter

This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-set-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3538 RFC3539 Authentication, Authorization and Accounting (AAA) Transport Profile B. Aboba J. Wood June 2003 ASCII 93110 41

This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK]

 draft-ietf-aaa-transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa 10.17487/RFC3539 RFC3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces N. Spring D. Wetherall D. Ely June 2003 ASCII 30081 13 congestion control tcp traffic control protocol

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-tcp-nonce-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3540 RFC3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D) A. Walsh May 2003 ASCII 11358 6 virtual reality monitoring language vrml extensible markup language x3d xml dtd document type definition

This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. This memo provides information for the Internet community.

 draft-walsh-urn-web3d-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3541 RFC3542 Advanced Sockets Application Program Interface (API) for IPv6 W. Stevens M. Thomas E. Nordmark T. Jinmei May 2003 ASCII 173028 77 application program interface

This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community.

 draft-ietf-ipngwg-rfc2292bis-09 RFC2292 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3542 10.17487/RFC3542 RFC3543 Registration Revocation in Mobile IPv4 S. Glass M. Chandra August 2003 ASCII 81805 33 internet protocol

This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS-TRACK]

 draft-ietf-mobileip-reg-revok-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3543 RFC3544 IP Header Compression over PPP T. Koren S. Casner C. Bormann July 2003 ASCII 27627 14 IPCOM-PPP internet protocol point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS-TRACK]

 draft-koren-pppext-rfc2509bis-03 RFC2509 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3544 RFC3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering T. Koren S. Casner J. Geevarghese B. Thompson P. Ruddy July 2003 ASCII 48278 22 point to point header

This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS-TRACK]

 draft-ietf-avt-crtp-enhance-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3545 RFC3546 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright June 2003 ASCII 63437 29 transport protocol layer authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

 draft-ietf-tls-extensions-06 RFC4366 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3546 RFC3547 The Group Domain of Interpretation M. Baugher B. Weis T. Hardjono H. Harney July 2003 ASCII 108901 48 isamkp doi key management security encryption

This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS-TRACK]

 draft-ietf-msec-gdoi-07 RFC6407 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC3547 RFC3548 The Base16, Base32, and Base64 Data Encodings S. Josefsson Editor July 2003 ASCII 26363 13 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community.

 draft-josefsson-base-encoding-04 RFC4648 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3548 10.17487/RFC3548 RFC3549 Linux Netlink as an IP Services Protocol J. Salim H. Khosravi A. Kleen A. Kuznetsov July 2003 ASCII 72161 33 internet protocol messaging system

This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.

 draft-ietf-forces-netlink-04 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3549 RFC3550 RTP: A Transport Protocol for Real-Time Applications H. Schulzrinne S. Casner R. Frederick V. Jacobson July 2003 ASCII 259985 104 PS 630740 PDF 504117 RTP end-to-end network audio video RTCP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-new-12 RFC1889 RFC5506 RFC5761 RFC6051 RFC6222 RFC7022 RFC7160 RFC7164 STD0064 INTERNET STANDARD DRAFT STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3550 10.17487/RFC3550 RFC3551 RTP Profile for Audio and Video Conferences with Minimal Control H. Schulzrinne S. Casner July 2003 ASCII 106621 44 PS 317286 PDF 237831 RTP-AV end-to-end network conference

This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]

 draft-ietf-avt-profile-new-13 RFC1890 RFC5761 RFC7007 STD0065 INTERNET STANDARD DRAFT STANDARD IETF rai avt 10.17487/RFC3551 RFC3552 Guidelines for Writing RFC Text on Security Considerations E. Rescorla B. Korver July 2003 ASCII 110393 44 Request for Comment

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-sec-cons-03 BCP0072 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3552 10.17487/RFC3552 RFC3553 An IETF URN Sub-namespace for Registered Protocol Parameters M. Mealling L. Masinter T. Hardie G. Klyne June 2003 ASCII 14815 8 syntax uniform resource names

This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-mealling-iana-urn-04 BCP0073 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3553 RFC3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec S. Bellovin J. Ioannidis A. Keromytis R. Stewart July 2003 ASCII 20102 9 ike internet key exchange security

This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS-TRACK]

 draft-ietf-ipsec-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3554 RFC3555 MIME Type Registration of RTP Payload Formats S. Casner P. Hoschka July 2003 ASCII 56618 45 real time transport protocol multipurpose internet mail extensions

This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text- based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mime-06 RFC4855 RFC4856 RFC3625 RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3555 RFC3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth S. Casner July 2003 ASCII 15310 8 real time transport protocol real-time

This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-bw-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3556 RFC3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding Q. Xie Editor July 2003 ASCII 29692 15 real time transport protocol real-time dsr

This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

 draft-ietf-avt-dsr-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3557 RFC3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) A. Li July 2003 ASCII 49787 23 real time transport protocol real-time bundled interleaved

This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS-TRACK]

 draft-ietf-avt-evrc-smv-03 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3558 RFC3559 Multicast Address Allocation MIB D. Thaler June 2003 ASCII 68239 37 maas management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. [STANDARDS-TRACK]

 draft-ietf-malloc-malloc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3559 RFC3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS) R. Housley July 2003 ASCII 37381 18 security encryption

This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK]

 draft-ietf-smime-cms-rsaes-oaep-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3560 RFC3561 Ad hoc On-Demand Distance Vector (AODV) Routing C. Perkins E. Belding-Royer S. Das July 2003 ASCII 90356 37 unicast multiple nodes

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-aodv-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3561 RFC3562 Key Management Considerations for the TCP MD5 Signature Option M. Leech July 2003 ASCII 14965 7 bgp border gateway protocol security encryption

The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community.

 draft-ietf-idr-md5-keys-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC3562 RFC3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development A. Zinin July 2003 ASCII 14974 8

This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community.

 draft-zinin-ietf-jtc1-aggr-01 RFC6233 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3563 RFC3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering F. Le Faucheur W. Lai July 2003 ASCII 50808 22 multi-protocol label switching bandwidth constraints model overbooking

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. This memo provides information for the Internet community.

 draft-ietf-tewg-diff-te-reqts-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3564 RFC3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Schaad July 2003 ASCII 26773 14 security data encoding

This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

 draft-ietf-smime-aes-alg-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3565 RFC3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec S. Frankel H. Herbert September 2003 ASCII 24645 11 authentication hash security

A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. [STANDARDS-TRACK]

 draft-ietf-ipsec-ciph-aes-xcbc-mac-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3566 RFC3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication T. Li R. Atkinson July 2003 ASCII 13467 6 iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community.

 draft-ietf-isis-hmac-04 RFC5304 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3567 RFC3568 Known Content Network (CN) Request-Routing Mechanisms A. Barbir B. Cain R. Nair O. Spatscheck July 2003 ASCII 42443 19 metrics routing redirection

This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community.

 draft-ietf-cdi-known-request-routing-03 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3568 RFC3569 An Overview of Source-Specific Multicast (SSM) S. Bhattacharyya Editor July 2003 ASCII 29387 14 routing applications deployment interoperability

The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community.

 draft-ietf-ssm-overview-05 INFORMATIONAL INFORMATIONAL IETF rtg ssm 10.17487/RFC3569 RFC3570 Content Internetworking (CDI) Scenarios P. Rzewski M. Day D. Gilletti July 2003 ASCII 42432 20 production networks

In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. This memo provides information for the Internet community.

 draft-ietf-cdi-scenarios-01 RFC6770 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3570 RFC3571 Framework Policy Information Base for Usage Feedback D. Rawlins A. Kulkarni K. Ho Chan M. Bokaemper D. Dutt August 2003 ASCII 70894 35 pib

This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community.

 draft-ietf-rap-feedback-fr-pib-06 HISTORIC INFORMATIONAL IETF ops rap 10.17487/RFC3571 RFC3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH) T. Ogura M. Maruyama T. Yoshida July 2003 ASCII 30607 14 ipv6 synchronous optical network synchronous digital hierarchy

Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. This memo provides information for the Internet community.

 draft-ogura-ipv6-mapos-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3572 RFC3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) I. Goyret July 2003 ASCII 22758 13 ppp point to point point-to-point pstn public switched telephone network

The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS-TRACK]

 draft-ietf-l2tpext-v92-moh-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3573 RFC3574 Transition Scenarios for 3GPP Networks J. Soininen Editor August 2003 ASCII 23359 12 third generation parnership project packet ipv6 ipv4 internet

This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community.

 draft-ietf-v6ops-3gpp-cases-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3574 RFC3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service) B. Aboba July 2003 ASCII 15539 8 internet assigned numbers authority encryption NAS Network Access Server

This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]

 draft-aboba-radius-iana-07 RFC2865 RFC2868 RFC6929 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3575 10.17487/RFC3575 RFC3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba July 2003 ASCII 70027 30 nas network access server

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

 draft-chiba-radius-dynamic-authorization-20 RFC5176 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3576 RFC3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules S. Waldbusser R. Cole C. Kalbfleisch D. Romascanu August 2003 ASCII 68551 31 management information base

The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. This memo provides information for the Internet community.

 draft-ietf-rmonmib-framework-05 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3577 RFC3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) G. Camarillo A. B. Roach J. Peterson L. Ong August 2003 ASCII 26667 13 pstn public switched telephone network

This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS-TRACK]

 draft-ietf-sipping-overlap-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3578 RFC3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) B. Aboba P. Calhoun September 2003 ASCII 104469 46 RADIUS encryption NAS Network Access Server

This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community.

 draft-aboba-radius-rfc2869bis-22 RFC2869 RFC5080 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3579 RFC3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines P. Congdon B. Aboba A. Smith G. Zorn J. Roese September 2003 ASCII 66136 30 AAA authentication authorization and accounting

This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

 draft-congdon-radius-8021x-29 RFC7268 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3580 10.17487/RFC3580 RFC3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing J. Rosenberg H. Schulzrinne August 2003 ASCII 66133 13 report client server

The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS-TRACK]

 draft-ietf-sip-symmetric-response-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3581 RFC3582 Goals for IPv6 Site-Multihoming Architectures J. Abley B. Black V. Gill August 2003 ASCII 17045 9 internet protocol multi6

This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community.

 draft-ietf-multi6-multihoming-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC3582 RFC3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP H. Chaskar Editor September 2003 ASCII 22541 10 internet protocol routing packets node

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. This memo provides information for the Internet community.

 draft-ietf-nsis-qos-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3583 RFC3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen August 2003 ASCII 115222 51 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-snmpv3-coex-v2-04 RFC2576 BCP0074 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops snmpv3 10.17487/RFC3584 RFC3585 IPsec Configuration Policy Information Model J. Jason L. Rafalow E. Vyncke August 2003 ASCII 187308 88 ike internet key exchange protocol core pcim

This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task- specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS-TRACK]

 draft-ietf-ipsp-config-policy-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3585 RFC3586 IP Security Policy (IPSP) Requirements M. Blaze A. Keromytis M. Richardson L. Sanchez August 2003 ASCII 22068 10 data integrity authentication host network

This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements. [STANDARDS-TRACK]

 draft-ietf-ipsp-requirements-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3586 RFC3587 IPv6 Global Unicast Address Format R. Hinden S. Deering E. Nordmark August 2003 ASCII 8783 5 internet protocol architecture routing

This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.

 draft-ietf-ipv6-unicast-aggr-v2-03 RFC2374 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3587 RFC3588 Diameter Base Protocol P. Calhoun J. Loughney E. Guttman G. Zorn J. Arkko September 2003 ASCII 341261 147 aaa authentication authorization accounting ip mobility

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-17 RFC6733 RFC5729 RFC5719 RFC6408 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=3588 10.17487/RFC3588 RFC3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5 J. Loughney September 2003 ASCII 8010 5 iana allocation

This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community.

 draft-loughney-aaa-cc-3gpp-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3589 10.17487/RFC3589 RFC3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol B. Haberman September 2003 ASCII 11554 6 MLD-IPv6 internet protocol routher packets

It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS-TRACK]

 draft-ietf-magma-mld-source-07 RFC2710 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC3590 RFC3591 Definitions of Managed Objects for the Optical Interface Type H-K. Lam M. Stewart A. Huynh September 2003 ASCII 310815 174 management information base mib snmp simple network management protocol otn optical transport network itu-t performance monitoring configuration dwdm optical tranmission session optical multiplex section optical channel otuk odukt oduk

This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS-TRACK]

 draft-ietf-atommib-opticalmib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib http://www.rfc-editor.org/errata_search.php?rfc=3591 10.17487/RFC3591 RFC3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type K. Tesink September 2003 ASCII 143588 73 MIB Management SNMP

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 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2558bis-01 RFC2558 DRAFT STANDARD DRAFT STANDARD IETF ops atommib http://www.rfc-editor.org/errata_search.php?rfc=3592 10.17487/RFC3592 RFC3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor September 2003 ASCII 20363 10 management information base data

This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2493bis-01 RFC2493 DRAFT STANDARD DRAFT STANDARD IETF ops atommib 10.17487/RFC3593 RFC3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option P. Duffy September 2003 ASCII 12521 7 dynamic host configuration protocol

This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS-TRACK]

 draft-ietf-dhc-pktc-kerb-tckt-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3594 RFC3595 Textual Conventions for IPv6 Flow Label B. Wijnen September 2003 ASCII 11746 6 mib management information base

This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ops-ipv6-flowlabel-01 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3595 RFC3596 DNS Extensions to Support IP Version 6 S. Thomson C. Huitema V. Ksinant M. Souissi October 2003 ASCII 14093 8 internet protocol domain name system DNS zone

This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]

 draft-ietf-dnsext-rfc1886bis-03 RFC3152 RFC1886 DRAFT STANDARD DRAFT STANDARD IETF int dnsext 10.17487/RFC3596 RFC3597 Handling of Unknown DNS Resource Record (RR) Types A. Gustafsson September 2003 ASCII 17559 8 domain name system name server software compression transparency

Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]

 draft-ietf-dnsext-unknown-rrs-06 RFC2163 RFC2535 RFC4033 RFC4034 RFC4035 RFC5395 RFC6195 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3597 10.17487/RFC3597 RFC3598 Sieve Email Filtering -- Subaddress Extension K. Murchison September 2003 ASCII 11151 6 users detailed addressing language address part test detail filter mailbox

On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. [STANDARDS-TRACK]

 draft-murchison-sieve-subaddress-06 RFC5233 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3598 RFC3599 Request for Comments Summary RFC Numbers 3500-3599 S. Ginoza December 2003 ASCII 76893 34

This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3599 RFC3600 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor November 2003 ASCII 134338 50

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

 RFC3300 RFC3700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3600 10.17487/RFC3600 RFC3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses C. Allocchio September 2003 ASCII 18572 10 notations dtmf dual tone multifrequency telephony e-mail addresses urls integrated messaging 3gpp

This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.

 draft-allocchio-gstn-05 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3601 RFC3602 The AES-CBC Cipher Algorithm and Its Use with IPsec S. Frankel R. Glenn S. Kelly September 2003 ASCII 30254 15 ipsec encapsulating security payload

This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

 draft-ietf-ipsec-ciph-aes-cbc-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3602 RFC3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture W. Marshall Editor F. Andreasen Editor October 2003 ASCII 67509 28 network access coordination

In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

 draft-dcsgroup-sipping-proxy-proxy-03 RFC5503 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3603 RFC3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) H. Khosravi G. Kullgren S. Shew J. Sadler A. Watanabe October 2003 ASCII 30805 16 controllers routers formats codes

This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.

 draft-ietf-gsmp-reqs-06 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3604 RFC3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) C. Huitema October 2003 ASCII 17270 8 nat network access translation port mapping

The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.

 draft-ietf-mmusic-sdp4nat-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3605 10.17487/RFC3605 RFC3606 Definitions of Supplemental Managed Objects for ATM Interface F. Ly M. Noto A. Smith E. Spiegel K. Tesink November 2003 ASCII 183610 94 asynchronous transfer mode mib management information base

This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs).

 draft-ietf-atommib-atm2-19 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3606 RFC3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool M. Leech September 2003 ASCII 14526 8 security encryption des data standard distributed cryptanalysis computer virus network worm codebreaking

This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.

 draft-leech-chinese-lottery-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3607 RFC3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration D. Willis B. Hoeneisen October 2003 ASCII 35628 17 user agent domain register

This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.

 draft-ietf-sip-scvrtdisco-04 RFC5630 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3608 RFC3609 Tracing Requirements for Generic Tunnels R. Bonica K. Kompella D. Meyer September 2003 ASCII 17859 9 traceroute application IP internet protocol

This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.

 draft-ietf-ccamp-tracereq-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC3609 RFC3610 Counter with CBC-MAC (CCM) D. Whiting R. Housley N. Ferguson September 2003 ASCII 64509 26 authentication encryption security ciphers

Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).

 draft-housley-ccm-mode-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3610 RFC3611 RTP Control Protocol Extended Reports (RTCP XR) T. Friedman Editor R. Caceres Editor A. Clark Editor November 2003 ASCII 126736 55 real time transport protocol packet type sdp session description blocks

This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.

 draft-ietf-avt-rtcp-report-extns-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3611 10.17487/RFC3611 RFC3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) A. Farrel September 2003 ASCII 35677 16 mpls fault tolerence high availability multiprotocol label switching cr-ldp high availability restart

This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP".

 draft-ietf-mpls-ldp-restart-applic-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3612 RFC3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE) R. Morgan K. Hazelton October 2003 ASCII 14296 8 internet2 middleware

This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE). This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.

 draft-hazelton-mace-urn-namespace-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3613 RFC3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG) J. Smith September 2003 ASCII 10457 6 iso international organization standardization multimedia metadata xml classification schemes digital rights management

This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.

 draft-smith-urn-mpeg-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3614 RFC3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging J. Gustin A. Goyens September 2003 ASCII 7352 5 messaging service interface software

This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.

 draft-gustin-goyens-urn-id-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3615 RFC3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA) F. Bellifemine I. Constantinescu S. Willmott September 2003 ASCII 13352 8 URN NID Uniform Resource Name Namespace Identification

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.

 draft-bellifemine-urn-fipa-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3616 RFC3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) E. Lear October 2003 ASCII 11848 7

The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.

 draft-lear-tftp-uri-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3617 RFC3618 Multicast Source Discovery Protocol (MSDP) B. Fenner Editor D. Meyer Editor October 2003 ASCII 42238 19 ipv4 pim-sm independent multicast sparse-mode rp rendezvous point

The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.

 draft-ietf-msdp-spec-20 EXPERIMENTAL EXPERIMENTAL IETF rtg msdp http://www.rfc-editor.org/errata_search.php?rfc=3618 10.17487/RFC3618 RFC3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 S. Shah M. Yip October 2003 ASCII 14440 7 ethernet rings robust

This document describes the Ethernet Automatic Protection Switching (EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).

 draft-shah-extreme-eaps-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3619 RFC3620 The TUNNEL Profile D. New October 2003 ASCII 35365 18 beep blocks extensible exchange protocol firewall application layer

This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.

 draft-ietf-idwg-beep-tunnel-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec idwg 10.17487/RFC3620 RFC3621 Power Ethernet MIB A. Berger D. Romascanu December 2003 ASCII 37294 20 management information base data terminal equipment power dte power sourcing equipment pse

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).

 draft-ietf-hubmib-power-ethernet-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3621 RFC3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project M. Mealling February 2004 ASCII 11432 7 federated network identity

This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.

 draft-mealling-liberty-urn-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3622 RFC3623 Graceful OSPF Restart J. Moy P. Pillay-Esnault A. Lindem November 2003 ASCII 38757 18 open shortest path first non-stop forwarding

This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "graceful restart" or "non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.

 draft-ietf-ospf-hitless-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3623 RFC3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package B. Foster D. Auerbach F. Andreasen November 2003 ASCII 34391 19 call agent endpoints naming conventions

The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.

 draft-foster-mgcp-bulkaudits-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3624 RFC3625 The QCP File Format and Media Types for Speech Data R. Gellens H. Garudadri September 2003 ASCII 28603 15 13k qcelp audio multimedia voip real time transport protocol multipurpose internet mail extensions

RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder (EVRC) and Selectable Mode Vocoders (SMV) data. (For example, Eudora(r), QuickTime(r), and cmda2000(r) handsets). This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC and SMV (respectively) data stored in this format.

 draft-gellens-qcp-01 RFC3555 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3625 10.17487/RFC3625 RFC3626 Optimized Link State Routing Protocol (OLSR) T. Clausen Editor P. Jacquet Editor October 2003 ASCII 161265 75 mobile ad hoc wireless multipoint relays mpr mprs

This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.

 draft-ietf-manet-olsr-11 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3626 RFC3627 Use of /127 Prefix Length Between Routers Considered Harmful P. Savola September 2003 ASCII 12436 6 address space anycast

In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.

 draft-savola-ipv6-127-prefixlen-04 RFC6547 HISTORIC INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3627 10.17487/RFC3627 RFC3628 Policy Requirements for Time-Stamping Authorities (TSAs) D. Pinkas N. Pope J. Ross November 2003 ASCII 92941 43 tokens public key certificates

This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.

 draft-ietf-pkix-pr-tsa-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3628 RFC3629 UTF-8, a transformation format of ISO 10646 F. Yergeau November 2003 ASCII 33856 14 UTF-8 UCS Transformation Format

ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.

 draft-yergeau-rfc2279bis-05 RFC2279 STD0063 INTERNET STANDARD INTERNET STANDARD INDEPENDENT 10.17487/RFC3629 RFC3630 Traffic Engineering (TE) Extensions to OSPF Version 2 D. Katz K. Kompella D. Yeung September 2003 ASCII 27717 14 open-shortest path first ink state advertisement

This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.

 draft-katz-yeung-ospf-traffic-10 RFC2370 RFC4203 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3630 RFC3631 Security Mechanisms for the Internet S. Bellovin Editor J. Schiller Editor C. Kaufman Editor December 2003 ASCII 47064 20 protocol host compromise dos denial of service

Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.

 draft-iab-secmech-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3631 RFC3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 S. Hollenbeck S. Veeramachaneni S. Yalamanchilli November 2003 ASCII 13490 8 RRP shared registration system gLTD ccTLD top level domain

This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.

 draft-hollenbeck-rfc2832bis-02 RFC2832 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3632 RFC3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 O. Troan R. Droms December 2003 ASCII 45308 19 automated delegation router

The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.

 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 RFC6603 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3633 10.17487/RFC3633 RFC3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option K. Luehrs R. Woundy J. Bevilacqua N. Davoust December 2003 ASCII 13163 7

This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.

 draft-ietf-dhc-suboptions-kdc-serveraddress-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3634 RFC3635 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick September 2003 ASCII 154476 64 MIB management information base

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 Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.

 draft-ietf-hubmib-etherif-mib-v3-03 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3635 RFC3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) J. Flick September 2003 ASCII 139990 62 MAU-MIB management information base

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 IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.

 draft-ietf-hubmib-mau-mib-v3-04 RFC2668 RFC1515 RFC4836 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3636 RFC3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer C.M. Heard Editor September 2003 ASCII 78785 37 mib management information base

This document 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 the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.

 draft-ietf-hubmib-wis-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3637 RFC3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status J. Flick C. M. Heard September 2003 ASCII 8676 5 ETHER-MIB MIB Network Management SNMP Ethernet

This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.

 draft-ietf-hubmib-1643-to-historic-01 RFC1643 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC3638 RFC3639 Considerations on the use of a Service Identifier in Packet Headers M. St. Johns Editor G. Huston Editor IAB October 2003 ASCII 15389 8 port fields protocol number

This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.

 draft-iab-service-id-considerations-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3639 RFC3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams J. van der Meer D. Mackie V. Swaminathan D. Singer P. Gentric November 2003 ASCII 102606 43 real time transport protocol audio video streams

The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.

 draft-ietf-avt-mpeg4-simple-08 RFC5691 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3640 RFC3641 Generic String Encoding Rules (GSER) for ASN.1 Types S. Legg October 2003 ASCII 34207 16 asn.1 abstract syntax notation

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.

 draft-legg-ldap-gser-04 RFC4792 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3641 RFC3642 Common Elements of Generic String Encoding Rules (GSER) Encodings S. Legg October 2003 ASCII 27774 13 asn.1 abstract syntax notation

The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.

 draft-legg-ldap-gser-abnf-07 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3642 RFC3643 Fibre Channel (FC) Frame Encapsulation R. Weber M. Rajagopal F. Travostino M. O'Donnell C. Monia M. Merhar December 2003 ASCII 39980 20 ips ip storage frame header

This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.

 draft-ietf-ips-fcencapsulation-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3643 RFC3644 Policy Quality of Service (QoS) Information Model Y. Snir Y. Ramberg J. Strassner R. Cohen B. Moore November 2003 ASCII 170150 73 integrated differentiated object oriented

This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.

 draft-ietf-policy-qos-info-model-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3644 RFC3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) S. Kwan P. Garg J. Gilroy L. Esibov J. Westhead R. Hall October 2003 ASCII 56162 26 TSIG domain name system transaction signature

The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.

 draft-ietf-dnsext-gss-tsig-06 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3645 RFC3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor December 2003 ASCII 13312 7 domain name system service server client

This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.

 draft-ietf-dhc-dhcpv6-opt-dnsconfig-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3646 RFC3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford R. Sabett C. Merrill S. Wu November 2003 ASCII 228124 94 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.

 draft-ietf-pkix-ipki-new-rfc2527-02 RFC2527 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3647 10.17487/RFC3647 RFC3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol J. Whitehead J. Reschke Editor December 2003 ASCII 57147 30 server client semantics ordering orderpatch method position header ordering-type header

This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.

 draft-ietf-webdav-ordering-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC3648 RFC3649 HighSpeed TCP for Large Congestion Windows S. Floyd December 2003 ASCII 79801 34 transmission control protocol round-trip rate packet

The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.

 draft-ietf-tsvwg-highspeed-01 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3649 RFC3650 Handle System Overview S. Sun L. Lannom B. Boesch November 2003 ASCII 54927 21 name service

This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.

 draft-sun-handle-system-12 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3650 10.17487/RFC3650 RFC3651 Handle System Namespace and Service Definition S. Sun S. Reilly L. Lannom November 2003 ASCII 104479 41 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.

 draft-sun-handle-system-def-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3651 10.17487/RFC3651 RFC3652 Handle System Protocol (ver 2.1) Specification S. Sun S. Reilly L. Lannom J. Petrone November 2003 ASCII 124380 53 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.

 draft-sun-handle-system-protocol-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3652 RFC3653 XML-Signature XPath Filter 2.0 J. Boyer M. Hughes J. Reagle December 2003 ASCII 32258 15 extensible markup language digital signature

XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. This document is the W3C XML Signature XPath-Filter 2.0 Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

 draft-ietf-xmldsig-xpf2-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3653 RFC3654 Requirements for Separation of IP Control and Forwarding H. Khosravi Editor T. Anderson Editor November 2003 ASCII 40418 18 forces forwarding control element separation data

This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.

 draft-ietf-forces-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3654 RFC3655 Redefinition of DNS Authenticated Data (AD) bit B. Wellington O. Gudmundsson November 2003 ASCII 15646 8 DNS-SECEXT dns authentication

This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.

 draft-ietf-dnsext-ad-is-secure-06 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3655 RFC3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol R. Siemborski December 2003 ASCII 35509 19 imap pop3 post office protocol internet message access

As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.

 draft-siemborski-mupdate-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3656 RFC3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS) S. Moriai A. Kato January 2004 ASCII 26282 14 security mail content key

This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

 draft-ietf-smime-camellia-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3657 RFC3658 Delegation Signer (DS) Resource Record (RR) O. Gudmundsson December 2003 ASCII 42120 19 zone cut zone key security dns domain name system

The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.

 draft-ietf-dnsext-delegation-signer-15 RFC4033 RFC4034 RFC4035 RFC3090 RFC3008 RFC2535 RFC1035 RFC3755 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3658 RFC3659 Extensions to FTP P. Hethmon March 2007 ASCII 137962 61 FTP file transfer protocol stream mode data transfer storage

This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. [STANDARDS-TRACK]

 draft-ietf-ftpext-mlst-16 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=3659 10.17487/RFC3659 RFC3660 Basic Media Gateway Control Protocol (MGCP) Packages B. Foster F. Andreasen December 2003 ASCII 145147 64 generic line trunk handset dtmf dual tone multifrequency

This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.

 draft-foster-mgcp-basic-packages-10 RFC2705 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3660 RFC3661 Media Gateway Control Protocol (MGCP) Return Code Usage B. Foster C. Sivachelvan December 2003 ASCII 49898 24 guidelines call agent implementation

This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP) Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.

 draft-foster-mgcp-returncodes-03 RFC3435 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3661 RFC3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services R. Bless K. Nichols K. Wehrle December 2003 ASCII 39029 17 traffic network ds le

This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.

 draft-bless-diffserv-pdb-le-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3662 RFC3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) A. Newton December 2003 ASCII 42260 21 referral types well-known

Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.

 draft-newton-ldap-whois-03 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3663 RFC3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman January 2004 ASCII 6711 4 security ipsec advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128.

 draft-ietf-ipsec-aes-xcbc-prf-01 RFC4434 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3664 RFC3665 Session Initiation Protocol (SIP) Basic Call Flow Examples A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII 163159 94 user agent client proxy redirect

This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.

 draft-ietf-sipping-basic-call-flows-02 BCP0075 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3665 10.17487/RFC3665 RFC3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII 200478 118 user proxy gateway telephony

This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.

 draft-ietf-sipping-pstn-call-flows-02 BCP0076 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3666 10.17487/RFC3666 RFC3667 IETF Rights in Contributions S. Bradner February 2004 ASCII 43297 18 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-submission-rights-08 RFC3978 RFC2026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3667 RFC3668 Intellectual Property Rights in IETF Technology S. Bradner February 2004 ASCII 41365 17 ipr copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-technology-rights-12 RFC3979 RFC2026 RFC2028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3668 RFC3669 Guidelines for Working Groups on Intellectual Property Issues S. Brim February 2004 ASCII 40946 17 ipr copyright

This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. This memo provides information for the Internet community.

 draft-ietf-ipr-wg-guidelines-05 INFORMATIONAL INFORMATIONAL IETF gen ipr 10.17487/RFC3669 RFC3670 Information Model for Describing Network Device QoS Datapath Mechanisms B. Moore D. Durham J. Strassner A. Westerinen W. Weiss January 2004 ASCII 221687 97 quality of service host netowrk devices traffic

The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository

 draft-ietf-policy-qos-device-info-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3670 RFC3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII 17912 10 x.500 information model schema

X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP.

 draft-zeilenga-ldap-collective-08 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3671 RFC3672 Subentries in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII 24447 12 special subtree

In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).

 draft-zeilenga-ldap-subentry-07 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3672 RFC3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes K. Zeilenga December 2003 ASCII 10003 5 user mechanisms extension

The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.

 draft-zeilenga-ldap-opattrs-05 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3673 RFC3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII 10282 5 elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.

 draft-zeilenga-ldap-features-05 RFC4512 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3674 RFC3675 .sex Considered Dangerous D. Eastlake 3rd February 2004 ASCII 53211 22 top level domains tld ip addresses internet protocol filters

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

 draft-eastlake-xxx-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3675 RFC3676 The Text/Plain Format and DelSp Parameters R. Gellens February 2004 ASCII 42441 20 media type mime multipurpose internet mail extension

This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting. This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. [STANDARDS-TRACK]

 draft-gellens-format-bis-04 RFC2646 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3676 RFC3677 IETF ISOC Board of Trustee Appointment Procedures L. Daigle Editor Internet Architecture Board December 2003 ASCII 13008 7 internet society bot engineering task force

This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.

 draft-iab-isocbot-01 BCP0077 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3677 10.17487/RFC3677 RFC3678 Socket Interface Extensions for Multicast Source Filters D. Thaler B. Fenner B. Quinn January 2004 ASCII 36320 18 ip internet protocol application program interface apis input output

The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.

 draft-ietf-magma-msf-api-05 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=3678 10.17487/RFC3678 RFC3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes R. Droms January 2004 ASCII 13804 8 dynamic host configuration protocol internet assigned numbers authority

Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.

 draft-ietf-dhc-unused-optioncodes-07 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC3679 RFC3680 A Session Initiation Protocol (SIP) Event Package for Registrations J. Rosenberg March 2004 ASCII 35403 26 REGISTER event package name event package parameters

This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS-TRACK]

 draft-ietf-sipping-reg-event-00 RFC6140 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3680 10.17487/RFC3680 RFC3681 Delegation of E.F.F.3.IP6.ARPA R. Bush R. Fink January 2004 ASCII 7137 4 dns domain name system

This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.

 draft-ymbk-6bone-arpa-delegation-01 BCP0080 BEST CURRENT PRACTICE BEST CURRENT PRACTICE INDEPENDENT 10.17487/RFC3681 RFC3682 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer February 2004 ASCII 23321 11 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. This memo defines an Experimental Protocol for the Internet community.

 draft-gill-gtsh-04 RFC5082 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3682 RFC3683 A Practice for Revoking Posting Rights to IETF Mailing Lists M. Rose March 2004 ASCII 15698 13

All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-mrose-ietf-posting-04 BCP0083 BEST CURRENT PRACTICE BEST CURRENT PRACTICE INDEPENDENT 10.17487/RFC3683 RFC3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) R. Ogier F. Templin M. Lewis February 2004 ASCII 107963 46 proactive routing ad-hoc networks neighbor discovery link-state routing mobile ad-hoc network mobile mesh network packet radio network wireless communications

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-tbrpf-11 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3684 RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions C. Daboo February 2004 ASCII 17436 9 messages portable commands

The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]

 draft-daboo-sieve-spamtest-04 RFC5235 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3685 RFC3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) R. Housley January 2004 ASCII 43777 19 authentication vector cipher block

This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.

 draft-ietf-ipsec-ciph-aes-ctr-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3686 RFC3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules S. Legg February 2004 ASCII 96256 42 syntax data schema

The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. [PROPOSED STANDARD]

 draft-legg-ldapext-component-matching-11 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3687 RFC3688 The IETF XML Registry M. Mealling January 2004 ASCII 17325 8 extensible markup language

This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.

 draft-mealling-iana-xmlns-registry-05 BCP0081 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3688 RFC3689 General Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII 21680 10

This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). This memo provides information for the Internet community.

 draft-ietf-ieprep-ets-general-04 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3689 RFC3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII 13919 7

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

 draft-ietf-ieprep-ets-telephony-07 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3690 RFC3691 Internet Message Access Protocol (IMAP) UNSELECT command A. Melnikov February 2004 ASCII 8436 5 mailbox session client

This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. [STANDARDS-TRACK]

 draft-melnikov-imap-unselect-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3691 RFC3692 Assigning Experimental and Testing Numbers Considered Useful T. Narten January 2004 ASCII 15054 7 iana internet assigned numbers authority values implementations

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.

 draft-narten-iana-experimental-allocations-05 RFC2434 BCP0082 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3692 RFC3693 Geopriv Requirements J. Cuellar J. Morris D. Mulligan J. Peterson J. Polk February 2004 ASCII 68881 30 security privacy lo location object

Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. This memo provides information for the Internet community.

 draft-ietf-geopriv-reqs-04 RFC6280 RFC7459 INFORMATIONAL INFORMATIONAL IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=3693 10.17487/RFC3693 RFC3694 Threat Analysis of the Geopriv Protocol M. Danley D. Mulligan J. Morris J. Peterson February 2004 ASCII 44364 18 privacy security data information

This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. This memo provides information for the Internet community.

 draft-ietf-geopriv-threat-analysis-01 RFC6280 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC3694 RFC3695 Compact Forward Error Correction (FEC) Schemes M. Luby L. Vicisano February 2004 ASCII 32012 13 content stream delivery multicast internet protocol

This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-fec-supp-compact-01 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3695 RFC3696 Application Techniques for Checking and Transformation of Names J. Klensin February 2004 ASCII 39238 16 top-level domains tlds

Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. This memo provides information for the Internet community.

 draft-klensin-name-filters-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3696 10.17487/RFC3696 RFC3697 IPv6 Flow Label Specification J. Rajahalme A. Conta B. Carpenter S. Deering March 2004 ASCII 21296 9 nodes packets

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

 draft-ietf-ipv6-flow-label-09 RFC6437 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3697 RFC3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules K. Zeilenga Editor February 2004 ASCII 17562 9 lightweight directory access protocol directory services

This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. [STANDARDS-TRACK]

 draft-zeilenga-ldap-user-schema-mr-00 RFC2798 RFC4517 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3698 RFC3700 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor July 2004 ASCII 148273 54

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

 RFC3600 RFC5000 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3700 10.17487/RFC3700 RFC3701 6bone (IPv6 Testing Address Allocation) Phaseout R. Fink R. Hinden March 2004 ASCII 12019 6 internet protocol protocotype software architecture

The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic. This memo provides information for the Internet community.

 draft-fink-6bone-phaseout-04 RFC2471 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3701 RFC3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) J. Loughney G. Camarillo February 2004 ASCII 31243 15

As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. This memo provides information for the Internet community.

 draft-ietf-sipping-aaa-req-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3702 RFC3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema J. Strassner B. Moore R. Moats E. Ellesson February 2004 ASCII 142983 61 mapping classes

This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. [STANDARDS-TRACK]

 draft-ietf-policy-core-schema-16 RFC4104 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3703 RFC3704 Ingress Filtering for Multihomed Networks F. Baker P. Savola March 2004 ASCII 35942 16 ISP Internet Service Provider Internet Protocol DOS

BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-savola-bcp38-multihoming-update-03 RFC2827 BCP0084 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3704 RFC3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals B. Ray R. Abbi February 2004 ASCII 24158 11 management information base

This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS-TRACK]

 draft-ietf-adslmib-hc-tc-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3705 RFC3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers G. Huang S. Beaulieu D. Rochefort February 2004 ASCII 30196 13 security authentication dead peer detection dpd keepalive

This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. This memo provides information for the Internet community.

 draft-ietf-ipsec-dpd-04 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3706 10.17487/RFC3706 RFC3707 Cross Registry Internet Service Protocol (CRISP) Requirements A. Newton February 2004 ASCII 52411 26 directory services domain

Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. This memo provides information for the Internet community.

 draft-ietf-crisp-requirements-06 INFORMATIONAL INFORMATIONAL IETF app crisp 10.17487/RFC3707 RFC3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions E. Blanton M. Allman February 2004 ASCII 20818 9

TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-dsack-use-02 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3708 RFC3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates S. Santesson R. Housley T. Freeman February 2004 ASCII 46453 21 authentication security identification

This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]

 draft-ietf-pkix-logotypes-13 RFC6170 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3709 10.17487/RFC3709 RFC3710 An IESG charter H. Alvestrand February 2004 ASCII 24912 12 internet engineering steering group

This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community.

 draft-iesg-charter-03 RFC3932 RFC5742 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3710 RFC3711 The Secure Real-time Transport Protocol (SRTP) M. Baugher D. McGrew M. Naslund E. Carrara K. Norrman March 2004 ASCII 134270 56 authentication traffic cryptographic

This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

 draft-ietf-avt-srtp-09 RFC5506 RFC6904 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3711 10.17487/RFC3711 RFC3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald February 2004 ASCII 62301 33 object classes attributes

This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). This memo provides information for the Internet community.

 draft-fleming-ldap-printer-schema-02 RFC7612 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3712 10.17487/RFC3712 RFC3713 A Description of the Camellia Encryption Algorithm M. Matsui J. Nakajima S. Moriai April 2004 ASCII 25031 15 security key cryptographic

This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. This memo provides information for the Internet community.

 draft-nakajima-camellia-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3713 RFC3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet S. Floyd Editor J. Kempf Editor March 2004 ASCII 81368 32 end-to-end qos qualify of service voip internet protocol

This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. This memo provides information for the Internet community.

 draft-iab-congestion-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3714 RFC3715 IPsec-Network Address Translation (NAT) Compatibility Requirements B. Aboba W. Dixon March 2004 ASCII 43476 18 virtual private networks vpns intranet

This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This memo provides information for the Internet community.

 draft-ietf-ipsec-nat-reqts-06 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3715 10.17487/RFC3715 RFC3716 The IETF in the Large: Administration and Execution IAB Advisory Committee March 2004 ASCII 91326 40

In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself. This memo provides information for the Internet community.

 draft-iab-advcomm-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3716 RFC3717 IP over Optical Networks: A Framework B. Rajagopalan J. Luciani D. Awduche March 2004 ASCII 124421 48 transport infrastructure routers high-speed

The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks"). This memo provides information for the Internet community.

 draft-ietf-ipo-framework-05 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC3717 RFC3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access R. McGowan February 2004 ASCII 25865 11

This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes.

 draft-rmcgowan-unicode-procs-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3718 RFC3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor February 2004 ASCII 33941 15 routing routeing interior gateway protocol igp conformance ip traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. This memo provides information for the Internet community.

 draft-ietf-isis-iso-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3719 RFC3720 Internet Small Computer Systems Interface (iSCSI) J. Satran K. Meth C. Sapuntzakis M. Chadalapaka E. Zeidner April 2004 ASCII 578468 257 transport protocol tcp transmission control protocol

This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-20 RFC7143 RFC3980 RFC4850 RFC5048 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3720 10.17487/RFC3720 RFC3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery M. Bakke J. Hafner J. Hufferd K. Voruganti M. Krueger April 2004 ASCII 47564 22 targets environments scalibilty target initiator scsi device name

This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. This memo provides information for the Internet community.

 draft-ietf-ips-iscsi-name-disc-10 RFC7143 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC3721 RFC3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names M. Bakke April 2004 ASCII 14702 8 transport unique global

This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-string-prep-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3722 RFC3723 Securing Block Storage Protocols over IP B. Aboba J. Tseng J. Walker V. Rangan F. Travostino April 2004 ASCII 171673 70 internet threat models performance security

This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. [STANDARDS-TRACK]

 draft-ietf-ips-security-19 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3723 RFC3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture J. Kempf Editor R. Austein Editor IAB March 2004 ASCII 37206 14 architectural guideline

The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.

 draft-iab-e2e-futures-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3724 RFC3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) J. Rosenberg J. Peterson H. Schulzrinne G. Camarillo April 2004 ASCII 77308 31

Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-3pcc-06 BCP0085 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC3725 RFC3726 Requirements for Signaling Protocols M. Brunner Editor April 2004 ASCII 98020 42 rsvp resource reservation protocol middleboxes nsis

This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This memo provides information for the Internet community.

 draft-ietf-nsis-req-09 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3726 RFC3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules S. Legg February 2004 ASCII 8297 5 lightweight directory access protocol

This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS-TRACK]

 draft-legg-ldap-cmr-module-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3727 RFC3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) B. Ray R. Abbi February 2004 ASCII 147232 76 management information base mib

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=3728 10.17487/RFC3728 RFC3729 Application Performance Measurement MIB S. Waldbusser March 2004 ASCII 131354 61

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 measuring the application performance as experienced by end-users. [STANDARDS-TRACK]

 draft-ietf-rmonmib-apm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3729 RFC3730 Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII 134337 69 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-09 RFC4930 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3730 10.17487/RFC3730 RFC3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck March 2004 ASCII 92527 45 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-domain-07 RFC4931 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3731 RFC3732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck March 2004 ASCII 57082 28 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-host-07 RFC4932 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3732 RFC3733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck March 2004 ASCII 83091 41 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-contact-07 RFC4933 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3733 10.17487/RFC3733 RFC3734 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck March 2004 ASCII 19550 9 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-tcp-06 RFC4934 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3734 RFC3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII 27326 13

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. This memo provides information for the Internet community.

 draft-ietf-provreg-epp-ext-03 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3735 RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 R. Droms April 2004 ASCII 18510 9

Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-stateless-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3736 10.17487/RFC3736 RFC3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules B. Wijnen A. Bierman April 2004 ASCII 13127 7 management information base internet assigned numbers authority

This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root. This memo also documents the currently assigned values. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmon-oid-assignments-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3737 RFC3738 Wave and Equation Based Rate Control (WEBRC) Building Block M. Luby V. Goyal April 2004 ASCII 82584 32 congestion control data delivery multicast ip internet protocol

This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-webrc-04 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3738 RFC3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile S. Santesson M. Nystrom T. Polk March 2004 ASCII 67436 34 syntax

This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]

 draft-ietf-pkix-sonof3039-06 RFC3039 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3739 10.17487/RFC3739 RFC3740 The Multicast Group Security Architecture T. Hardjono B. Weis March 2004 ASCII 65531 26 data packets

This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. This memo provides information for the Internet community.

 draft-ietf-msec-arch-05 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC3740 RFC3741 Exclusive XML Canonicalization, Version 1.0 J. Boyer D. Eastlake 3rd J. Reagle March 2004 ASCII 35403 16 extensible markup language namespace

Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the "xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. This memo provides information for the Internet community.

 draft-ietf-xmldsig-xc14n-02 INFORMATIONAL INFORMATIONAL IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3741 10.17487/RFC3741 RFC3742 Limited Slow-Start for TCP with Large Congestion Windows S. Floyd March 2004 ASCII 14840 7 transmission control protocol

This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-slowstart-00 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3742 10.17487/RFC3742 RFC3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean K. Konishi K. Huang H. Qian Y. Ko April 2004 ASCII 74963 33

Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration. The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts. This memo provides information for the Internet community.

 draft-jseng-idn-admin-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3743 RFC3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol G. Clemm J. Reschke E. Sedlar J. Whitehead May 2004 ASCII 146623 72

This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. [STANDARDS-TRACK]

 draft-ietf-webdav-acl-13 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=3744 10.17487/RFC3744 RFC3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444) D. Singer R. Clark D. Lee April 2004 ASCII 31224 14 multipurpose internet mail extensions joint photographic experts group

This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000 (Joint Photographic Experts Group). [STANDARDS-TRACK]

 draft-singer-jp2-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3745 RFC3746 Forwarding and Control Element Separation (ForCES) Framework L. Yang R. Dantu T. Anderson R. Gopal April 2004 ASCII 98660 40 network elements

This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. This is memo provides information for the Internet community.

 draft-ietf-forces-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3746 RFC3747 The Differentiated Services Configuration MIB H. Hazewinkel Editor D. Partain Editor April 2004 ASCII 51659 24 management information base diffserv

This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. [PROPOSED STANDARD]

 draft-ietf-snmpconf-diffpolicy-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC3747 RFC3748 Extensible Authentication Protocol (EAP) B. Aboba L. Blunk J. Vollbrecht J. Carlson H. Levkowetz Editor June 2004 ASCII 157994 67 PPP-EAP data link layers ppp point-to-point ieee 802

This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]

 draft-ietf-eap-rfc2284bis-09 RFC2284 RFC5247 RFC7057 PROPOSED STANDARD PROPOSED STANDARD IETF int eap 10.17487/RFC3748 RFC3749 Transport Layer Security Protocol Compression Methods S. Hollenbeck May 2004 ASCII 16411 8 tls lossless data compression handshake protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]

 draft-ietf-tls-compression-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3749 RFC3750 Unmanaged Networks IPv6 Transition Scenarios C. Huitema R. Austein S. Satapati R. van der Pol April 2004 ASCII 48153 20 single subnet gateway isp internet service provider

This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. This memo provides information for the Internet community.

 draft-ietf-v6ops-unman-scenarios-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3750 RFC3751 Omniscience Protocol Requirements S. Bradner April 1 2004 ASCII 20771 9

There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. This memo provides information for the Internet community.

 draft-bradner-op-req-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3751 RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios A. Barbir E. Burger R. Chen S. McHenry H. Orman R. Penno April 2004 ASCII 29481 14 application data services

This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This memo provides information for the Internet community.

 draft-ietf-opes-scenarios-01 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3752 RFC3753 Mobility Related Terminology J. Manner Editor M. Kojo Editor June 2004 ASCII 74143 36 networks ip internet protocol

There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. This memo provides information for the Internet community.

 draft-ietf-seamoby-mobility-terminology-06 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3753 RFC3754 IP Multicast in Differentiated Services (DS) Networks R. Bless K. Wehrle April 2004 ASCII 86533 34 internet protocol

This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. This memo provides information for the Internet community.

 draft-bless-diffserv-multicast-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3754 RFC3755 Legacy Resolver Compatibility for Delegation Signer (DS) S. Weiler May 2004 ASCII 19812 9 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-2535typecode-change-06 RFC4033 RFC4034 RFC4035 RFC3658 RFC2535 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3755 RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats P. Nikander Editor J. Kempf E. Nordmark May 2004 ASCII 56674 23 authentication security key management

The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.

 draft-ietf-send-psreq-04 INFORMATIONAL INFORMATIONAL IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3756 10.17487/RFC3756 RFC3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag O. Kolkman J. Schlyter E. Lewis April 2004 ASCII 16868 8 dnssec

With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. [STANDARDS-TRACK]

 draft-ietf-dnsext-keyrr-key-signing-flag-12 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3757 10.17487/RFC3757 RFC3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension R. Stewart M. Ramalho Q. Xie M. Tuexen P. Conrad May 2004 ASCII 50999 22 init init ack forward tsn

This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS-TRACK]

 draft-ietf-tsvwg-prsctp-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3758 RFC3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples L-E. Jonsson April 2004 ASCII 50168 20 encapsulating security payload real-time transport protocol user datagram

This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. This memo provides information for the Internet community.

 draft-ietf-rohc-terminology-and-examples-02 RFC3095 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3759 RFC3760 Securely Available Credentials (SACRED) - Credential Server Framework D. Gustafson M. Just M. Nystrom April 2004 ASCII 49910 22

As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. This memo provides information for the Internet community.

 draft-ietf-sacred-framework-07 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3760 RFC3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) P. Faltstrom M. Mealling April 2004 ASCII 41559 18 domain name system

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS-TRACK]

 draft-ietf-enum-rfc2916bis-07 RFC2916 RFC6116 RFC6117 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3761 RFC3762 Telephone Number Mapping (ENUM) Service Registration for H.323 O. Levin April 2004 ASCII 8450 5 multimedia packet based network

The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-h323-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3762 RFC3763 One-way Active Measurement Protocol (OWAMP) Requirements S. Shalunov B. Teitelbaum April 2004 ASCII 23360 11 performance metrics delay unidirectional

With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This memo provides information for the Internet community.

 draft-ietf-ippm-owdp-reqs-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3763 RFC3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record J. Peterson April 2004 ASCII 17604 8 aor electronic number

This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. [STANDARDS-TRACK]

 draft-ietf-enum-sip-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3764 RFC3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control G. Huston April 2004 ASCII 16500 7 peer connections propagated

This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. This memo provides information for the Internet community.

 draft-ietf-ptomaine-nopeer-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3765 RFC3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys H. Orman P. Hoffman April 2004 ASCII 55939 23 security cryptography algorithms integers

Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-orman-public-key-lengths-08 BCP0086 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3766 RFC3767 Securely Available Credentials Protocol S. Farrell Editor June 2004 ASCII 49552 25 beep blocks extensible exchange protocol xml extensible mark up language

This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]

 draft-ietf-sacred-protocol-bss-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec sacred 10.17487/RFC3767 RFC3768 Virtual Router Redundancy Protocol (VRRP) R. Hinden Editor April 2004 ASCII 59969 27 VRRP vrrp lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]

 draft-ietf-vrrp-spec-v2-10 RFC2338 RFC5798 DRAFT STANDARD DRAFT STANDARD IETF rtg vrrp 10.17487/RFC3768 RFC3769 Requirements for IPv6 Prefix Delegation S. Miyakawa R. Droms June 2004 ASCII 10287 6 internet protocol version 6

This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). This memo provides information for the Internet community.

 draft-ietf-ipv6-prefix-delegation-requirement-04 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3769 RFC3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore May 2004 ASCII 18635 9 ssid system service identifiers eap

This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). [STANDARDS-TRACK]

 draft-ietf-pkix-wlan-extns-05 RFC4334 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3770 10.17487/RFC3770 RFC3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message R. Harrison K. Zeilenga April 2004 ASCII 17114 8 LDAPv3 LDAv3 x.500

This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. [STANDARDS-TRACK]

 draft-rharrison-ldap-intermediate-resp-01 RFC4511 RFC4510 RFC2251 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3771 RFC3772 Point-to-Point Protocol (PPP) Vendor Protocol J. Carlson R. Winslow May 2004 ASCII 19846 10 link control protocol lcp

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols. [STANDARDS-TRACK]

 draft-ietf-pppext-vendor-protocol-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3772 RFC3773 High-Level Requirements for Internet Voice Mail E. Candell June 2004 ASCII 19156 9 ivm internet voice messaging voice profile for internet mail vpim

This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2. This memo provides information for the Internet community.

 draft-ietf-vpim-ivm-goals-06 INFORMATIONAL INFORMATIONAL IETF app vpim 10.17487/RFC3773 RFC3774 IETF Problem Statement E. Davies Editor May 2004 ASCII 55172 22 ietf process problem analysis

This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. This memo provides information for the Internet community.

 draft-ietf-problem-issue-statement-05 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3774 RFC3775 Mobility Support in IPv6 D. Johnson C. Perkins J. Arkko June 2004 ASCII 393514 165 internet protocol nodes

This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS-TRACK]

 draft-ietf-mobileip-ipv6-24 RFC6275 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3775 RFC3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents J. Arkko V. Devarapalli F. Dupont June 2004 ASCII 87076 40 security internet protocol

Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. [STANDARDS-TRACK]

 draft-ietf-mobileip-mipv6-ha-ipsec-06 RFC4877 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3776 RFC3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin Editor June 2004 ASCII 76395 34 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-nomcom-rfc2727bis-09 RFC2727 RFC7437 RFC5078 RFC5633 RFC5680 RFC6859 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen nomcom http://www.rfc-editor.org/errata_search.php?rfc=3777 10.17487/RFC3777 RFC3778 The application/pdf Media Type E. Taft J. Pravetz S. Zilles L. Masinter May 2004 ASCII 29891 14 portable document format document exchange digital signatures

PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. This memo provides information for the Internet community.

 draft-zilles-pdf-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3778 RFC3779 X.509 Extensions for IP Addresses and AS Identifiers C. Lynn S. Kent K. Seo June 2004 ASCII 60732 27 allocation atrribute certificate authorization autonomous system number authorization certificate delegation internet registry ip address authorization public key infrastructure right-to-use secure allocation

This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]

 draft-ietf-pkix-x509-ipaddr-as-extn-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3779 10.17487/RFC3779 RFC3780 SMIng - Next Generation Structure of Management Information F. Strauss J. Schoenwaelder May 2004 ASCII 141049 64 data definition language

This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-nmrg-sming-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3780 RFC3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP) F. Strauss J. Schoenwaelder May 2004 ASCII 112267 49 data definition language

SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-nmrg-sming-snmp-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3781 10.17487/RFC3781 RFC3782 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson A. Gurtov April 2004 ASCII 49603 19 Transmission Control Protocol

The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP. [STANDARDS-TRACK]

 draft-ietf-tsvwg-newreno-02 RFC2582 RFC6582 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3782 10.17487/RFC3782 RFC3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI M. Chadalapaka R. Elliott May 2004 ASCII 32358 14 Internet Small Computer Systems Interface iscsi

Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the classic SCSI "I_T nexus", which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. This memo provides information for the Internet community.

 draft-ietf-ips-command-ordering-02 INFORMATIONAL INFORMATIONAL IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3783 10.17487/RFC3783 RFC3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) H. Smit T. Li June 2004 ASCII 27422 13 link state protocol lsp

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This memo provides information for the Internet community.

 draft-ietf-isis-traffic-05 RFC5305 RFC4205 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3784 RFC3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric F. Le Faucheur R. Uppili A. Vedrenne P. Merckx T. Telkamp May 2004 ASCII 17475 8 link bandwidth router

This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tewg-te-metric-igp-02 BCP0087 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF subip tewg 10.17487/RFC3785 RFC3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit A. Hermelin S. Previdi M. Shand May 2004 ASCII 29164 14

This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. This memo provides information for the Internet community.

 draft-ietf-isis-ext-lsp-frags-02 RFC5311 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3786 RFC3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor May 2004 ASCII 25426 11 routing traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. This memo provides information for the Internet community.

 draft-ietf-isis-ip-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3787 RFC3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols J. Loughney M. Tuexen Editor J. Pastor-Balbas June 2004 ASCII 27125 13

This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional. [STANDARDS-TRACK]

 draft-ietf-sigtran-security-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3788 RFC3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 22842 10

This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-intro-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3789 RFC3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents C. Mickles Editor P. Nesser II June 2004 ASCII 102694 49

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-int-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3790 RFC3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents C. Olvera P. Nesser II June 2004 ASCII 27567 15

This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-routing-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3791 RFC3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 46398 25

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-sec-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3792 RFC3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 11624 6

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-subip-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3793 RFC3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 60001 31

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-trans-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3794 RFC3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents R. Sofia P. Nesser II June 2004 ASCII 92584 50

This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-apps-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3795 RFC3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 78400 43

This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-ops-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3796 RFC3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection D. Eastlake 3rd June 2004 ASCII 39883 19 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.

 draft-eastlake-rfc2777bis-selection-04 RFC2777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3797 RFC3798 Message Disposition Notification T. Hansen Editor G. Vaudreuil Editor May 2004 ASCII 64049 30 EMF-MDN MDN media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. [STANDARDS-TRACK]

 draft-vaudreuil-mdnbis-05 RFC2298 RFC3461 RFC2046 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3798 10.17487/RFC3798 RFC3801 Voice Profile for Internet Mail - version 2 (VPIMv2) G. Vaudreuil G. Parsons June 2004 ASCII 118122 55 MIME-VP2 vpim messaging

This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems. This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM. [STANDARDS-TRACK]

 draft-ietf-vpim-vpimv2r2-05 RFC2421 RFC2423 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3801 RFC3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration G. Vaudreuil G. Parsons June 2004 ASCII 11686 7 MIME-ADPCM multipurpose internet mail extensions audio

This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. [STANDARDS-TRACK]

 draft-ietf-vpim-vpimv2r2-32k-03 RFC2422 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3802 RFC3803 Content Duration MIME Header Definition G. Vaudreuil G. Parsons June 2004 ASCII 8213 5 CONT-DUR multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS-TRACK]

 draft-ietf-vpim-vpimv2r2-dur-03 RFC2424 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3803 RFC3804 Voice Profile for Internet Mail (VPIM) Addressing G. Parsons June 2004 ASCII 26122 15 formats

This document lists the various Voice Profile for Internet Mail (VPIM) email address formats that are currently in common use and defines several new address formats for special case usage. Requirements are imposed on the formats of addresses used in VPIM submission mode. [STANDARDS-TRACK]

 draft-ietf-vpim-address-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3804 RFC3805 Printer MIB v2 R. Bergman H. Lewis I. McDonald June 2004 ASCII 366952 171 Print-MIB Management Information Base snmp management

This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. [STANDARDS-TRACK]

 draft-ietf-printmib-mib-info-15 RFC1759 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3805 RFC3806 Printer Finishing MIB R. Bergman H. Lewis I. McDonald June 2004 ASCII 109654 53 finisher snmp

This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a Printer System. This memo provides information for the Internet community.

 draft-ietf-printmib-finishing-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3806 RFC3807 V5.2-User Adaptation Layer (V5UA) E. Weilandt N. Khanchandani S. Rao June 2004 ASCII 49748 24 v5 v5.1 v5.2 backhauling imap sctp isdn access network c-path c-channel efa envelope function address lapv5 pstn v5ptm mgc gateway controller gateway

This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS-TRACK]

 draft-ietf-sigtran-v5ua-04 RFC3057 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3807 RFC3808 IANA Charset MIB I. McDonald June 2004 ASCII 25245 14 management information base IANACharset

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978). This memo provides information for the Internet community.

 draft-mcdonald-iana-charset-mib-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3808 RFC3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) A. Nagarajan Editor June 2004 ASCII 60576 25 service engineering

This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. This memo provides information for the Internet community.

 draft-ietf-l3vpn-generic-reqts-03 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC3809 RFC3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 R. Vida Editor L. Costa Editor June 2004 ASCII 153579 62 ssm source filtering igmp group management mld

This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]

 draft-vida-mld-v2-08 RFC2710 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=3810 10.17487/RFC3810 RFC3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management T. Nadeau Editor J. Cucchiara Editor June 2004 ASCII 40353 20 management information base

This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-mpls-tc-mib-10 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3811 10.17487/RFC3811 RFC3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII 136475 68

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS-TRACK]

 draft-ietf-mpls-te-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3812 RFC3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII 116120 60

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 a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

 draft-ietf-mpls-lsr-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3813 10.17487/RFC3813 RFC3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) T. Nadeau C. Srinivasan A. Viswanathan June 2004 ASCII 87518 42

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

 draft-ietf-mpls-ftn-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3814 RFC3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) J. Cucchiara H. Sjostrand J. Luciani June 2004 ASCII 215916 106

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3815 10.17487/RFC3815 RFC3816 Definitions of Managed Objects for RObust Header Compression (ROHC) J. Quittek M. Stiemerling H. Hartenstein June 2004 ASCII 104947 53 mib management information base

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 a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS-TRACK]

 draft-ietf-rohc-mib-rtp-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=3816 10.17487/RFC3816 RFC3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) W. Townsley R. da Silva June 2004 ASCII 37765 17 point-to-point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. This memo provides information for the Internet community.

 draft-dasilva-l2tp-relaysvc-08 INFORMATIONAL INFORMATIONAL IETF int l2tpext 10.17487/RFC3817 RFC3818 IANA Considerations for the Point-to-Point Protocol (PPP) V. Schryver June 2004 ASCII 6321 4

The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-schryver-pppext-iana-01 BCP0088 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pppext 10.17487/RFC3818 RFC3819 Advice for Internet Subnetwork Designers P. Karn Editor C. Bormann G. Fairhurst D. Grossman R. Ludwig J. Mahdavi G. Montenegro J. Touch L. Wood July 2004 ASCII 152174 60 digital communication equipment link-layer protocols packet-switched local networks

This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-link-design-15 BCP0089 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc http://www.rfc-editor.org/errata_search.php?rfc=3819 10.17487/RFC3819 RFC3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile S. Tuecke V. Welch D. Engert L. Pearlman M. Thompson June 2004 ASCII 86374 37 authentication security credentials restricted delegation single-signon delegation of rights

This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS-TRACK]

 draft-ietf-pkix-proxy-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3820 10.17487/RFC3820 RFC3821 Fibre Channel Over TCP/IP (FCIP) M. Rajagopal E. Rodriguez R. Weber July 2004 ASCII 165907 74 storage area networks IP-based networks unified storage area network

Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. [STANDARDS-TRACK]

 draft-ietf-ips-fcovertcpip-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3821 RFC3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2) D. Peterson July 2004 ASCII 22859 11 dynamic discovery

This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS-TRACK]

 draft-ietf-ips-fcip-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3822 10.17487/RFC3822 RFC3823 MIME Media Type for the Systems Biology Markup Language (SBML) B. Kovitz June 2004 ASCII 14577 8 sub-type application/sbml+xml systems biology community

This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. This memo provides information for the Internet community.

 draft-sbml-media-type-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3823 RFC3824 Using E.164 numbers with the Session Initiation Protocol (SIP) J. Peterson H. Liu J. Yu B. Campbell June 2004 ASCII 36535 16 telephone records applications

There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This memo provides information for the Internet community.

 draft-ietf-sipping-e164-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3824 RFC3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information J. Polk J. Schnizlein M. Linsner July 2004 ASCII 31715 15 dhcp lci geographic location

This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. [STANDARDS-TRACK]

 draft-ietf-geopriv-dhcp-lci-option-03 RFC6225 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC3825 RFC3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model U. Blumenthal F. Maino K. McCloghrie June 2004 ASCII 32821 16 management information base simple network management protocol

This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]

 draft-blumenthal-aes-usm-08 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3826 RFC3827 Additional Snoop Datalink Types K. Sarcar June 2004 ASCII 6344 4

The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. This memo provides information for the Internet community.

 draft-sarcar-snoop-new-types-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3827 RFC3828 The Lightweight User Datagram Protocol (UDP-Lite) L-A. Larzon M. Degermark S. Pink L-E. Jonsson Editor G. Fairhurst Editor July 2004 ASCII 27193 12

This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. [STANDARDS-TRACK]

 draft-ietf-tsvwg-udp-lite-02 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3828 RFC3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls R. Weltman M. Smith M. Wahl July 2004 ASCII 11986 6 bind operation

This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. This memo provides information for the Internet community.

 draft-weltman-ldapv3-auth-response-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3829 10.17487/RFC3829 RFC3830 MIKEY: Multimedia Internet KEYing J. Arkko E. Carrara F. Lindholm M. Naslund K. Norrman August 2004 ASCII 145238 66 key management scheme real-time applications

This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK]

 draft-ietf-msec-mikey-08 RFC4738 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=3830 10.17487/RFC3830 RFC3831 Transmission of IPv6 Packets over Fibre Channel C. DeSanti July 2004 ASCII 53328 24 addresses link-local internet protocol

This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. [STANDARDS-TRACK]

 draft-ietf-imss-ipv6-over-fibre-channel-02 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC3831 RFC3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome July 2004 ASCII 15602 8 DNS-SRV domain name system resource record

Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. This memo defines an Experimental Protocol for the Internet community.

 draft-zhao-slp-remote-da-discovery-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3832 RFC3833 Threat Analysis of the Domain Name System (DNS) D. Atkins R. Austein August 2004 ASCII 39303 16 data disclosure security authentication

Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community.

 draft-ietf-dnsext-dns-threats-07 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3833 RFC3834 Recommendations for Automatic Responses to Electronic Mail K. Moore August 2004 ASCII 53119 22 automatic mail responders

This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS-TRACK]

 draft-moore-auto-email-response-05 RFC5436 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3834 10.17487/RFC3834 RFC3835 An Architecture for Open Pluggable Edge Services (OPES) A. Barbir R. Penno R. Chen M. Hofmann H. Orman August 2004 ASCII 36113 17 application service data stream service data consumer data dispatcher architecture

This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. This memo provides information for the Internet community.

 draft-ietf-opes-architecture-04 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3835 RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols A. Beck M. Hofmann H. Orman R. Penno A. Terzis August 2004 ASCII 28438 13 callout protocol remote execution OPES services

This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. This memo provides information for the Internet community.

 draft-ietf-opes-protocol-reqs-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3836 RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES) A. Barbir O. Batuner B. Srinivas M. Hofmann H. Orman August 2004 ASCII 31883 14 threat discovery threat analysis

The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. This memo provides information for the Internet community.

 draft-ietf-opes-threats-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3837 RFC3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) A. Barbir O. Batuner A. Beck T. Chan H. Orman August 2004 ASCII 38739 17 opes flow

This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. This memo provides information for the Internet community.

 draft-ietf-opes-authorization-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3838 RFC3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files R. Castagno D. Singer July 2004 ASCII 15645 7 standard MIME types 3GPP multimedia file format ISO Media File Format

This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

 draft-singer-avt-3gpp-mime-01 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3839 RFC3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII 81360 36 ua contact header field

This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]

 draft-ietf-sip-callee-caps-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3840 RFC3841 Caller Preferences for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII 61382 26 Uniform Resource Identifiers URI Accept-Contact Reject-Contact Request-Disposition

This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. [STANDARDS-TRACK]

 draft-ietf-sip-callerprefs-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3841 RFC3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) R. Mahy August 2004 ASCII 36877 19 message waiting status message summary

This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK]

 draft-ietf-sipping-mwi-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3842 RFC3843 RObust Header Compression (ROHC): A Compression Profile for IP L-E. Jonsson G. Pelletier June 2004 ASCII 33549 16 compression protocols

The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS-TRACK]

 draft-ietf-rohc-ip-only-05 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3843 RFC3844 IETF Problem Resolution Process E. Davies Editor J. Hofmann Editor August 2004 ASCII 44841 20 ietf process problem analysis

This Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short-term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. This memo provides information for the Internet community.

 draft-ietf-problem-process-04 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3844 RFC3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format J. Schlyter Editor August 2004 ASCII 14793 7 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS-TRACK]

 draft-ietf-dnsext-nsec-rdata-06 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3845 RFC3846 Mobile IPv4 Extension for Carrying Network Access Identifiers F. Johansson T. Johansson June 2004 ASCII 16834 8 nai internet protocol home aaa server ha server home agents

When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. [STANDARDS-TRACK]

 draft-ietf-mip4-aaa-nai-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3846 RFC3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS) M. Shand L. Ginsberg July 2004 ASCII 50023 21 LSP database synchronization transient routing disruption database synchronization

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This memo provides information for the Internet community.

 draft-ietf-isis-restart-05 RFC5306 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3847 RFC3848 ESMTP and LMTP Transmission Types Registration C. Newman July 2004 ASCII 7916 4 smtp simple mail transfer protocol

This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. [STANDARDS-TRACK]

 draft-newman-esmtpsa-01 DRAFT STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3848 RFC3849 IPv6 Address Prefix Reserved for Documentation G. Huston A. Lord P. Smith July 2004 ASCII 7872 4 unicast site-local link-local

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community.

 draft-huston-ipv6-documentation-prefix-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3849 RFC3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling B. Ramsdell Editor July 2004 ASCII 37446 16 x.509 encryption certificate multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. [STANDARDS-TRACK]

 draft-ietf-smime-rfc2632bis-07 RFC2632 RFC5750 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3850 RFC3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification B. Ramsdell Editor July 2004 ASCII 53328 36 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS-TRACK]

 draft-ietf-smime-rfc2633bis-09 RFC2633 RFC5751 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3851 RFC3852 Cryptographic Message Syntax (CMS) R. Housley July 2004 ASCII 15541 56 digitally sign authenticate encrypt arbitrary message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

 draft-ietf-smime-rfc3369bis-04 RFC3369 RFC5652 RFC4853 RFC5083 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3852 10.17487/RFC3852 RFC3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP) J. Peterson July 2004 ASCII 10687 6 SIP application-layer application layer multimedia multicast unicast

RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS-TRACK]

 draft-ietf-sip-smime-aes-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3853 RFC3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME) P. Hoffman C. Bonatti A. Eggen July 2004 ASCII 32801 15 encryption cryptographic signature

This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME). [STANDARDS-TRACK]

 draft-ietf-smime-x400wrap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3854 RFC3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400 P. Hoffman C. Bonatti July 2004 ASCII 25774 12 cms cryptographic message syntax message

This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. [STANDARDS-TRACK]

 draft-ietf-smime-x400transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3855 RFC3856 A Presence Event Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII 62956 27 subscription notification

This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]

 draft-ietf-simple-presence-10 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3856 10.17487/RFC3856 RFC3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII 46221 20

This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. [STANDARDS-TRACK]

 draft-ietf-simple-winfo-package-05 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3857 RFC3858 An Extensible Markup Language (XML) Based Format for Watcher Information J. Rosenberg August 2004 ASCII 26416 13 xml

Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state. [STANDARDS-TRACK]

 draft-ietf-simple-winfo-format-04 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3858 RFC3859 Common Profile for Presence (CPP) J. Peterson August 2004 ASCII 30537 15 data formats semantics instant messaging

At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. [STANDARDS-TRACK]

 draft-ietf-impp-pres-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3859 RFC3860 Common Profile for Instant Messaging (CPIM) J. Peterson August 2004 ASCII 26486 13 data formats semantics instant messaging

At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK]

 draft-ietf-impp-im-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3860 RFC3861 Address Resolution for Instant Messaging and Presence J. Peterson August 2004 ASCII 15764 8 uri schemes universal resource identifier impp instant messaging and presence protocol presentity instant inbox

Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS-TRACK]

 draft-ietf-impp-srv-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3861 RFC3862 Common Presence and Instant Messaging (CPIM): Message Format G. Klyne D. Atkins August 2004 ASCII 56133 30 instant messaging and presence protocol message/cpim

This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS-TRACK]

 draft-ietf-impp-cpim-msgfmt-09 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3862 10.17487/RFC3862 RFC3863 Presence Information Data Format (PIDF) H. Sugano S. Fujimoto G. Klyne A. Bateman W. Carr J. Peterson August 2004 ASCII 56956 28 instant messaging and presence protocol cpp common profile for presence presence data format application/pidf+xml

This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF. [STANDARDS-TRACK]

 draft-ietf-impp-cpim-pidf-08 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3863 10.17487/RFC3863 RFC3864 Registration Procedures for Message Header Fields G. Klyne M. Nottingham J. Mogul September 2004 ASCII 36231 17 Internet mail HTTP Netnews

This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klyne-msghdr-registry-07 BCP0090 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3864 RFC3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension C. Malamud September 2004 ASCII 40717 19 unsolicited bulk email ube no soliciting solicitation class keywords solicitation mail header trace fields

This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. [STANDARDS-TRACK]

 draft-malamud-no-soliciting-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3865 RFC3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga Editor July 2004 ASCII 31501 15 lightweight directory access protocol servers

It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). [STANDARDS-TRACK]

 draft-zeilenga-ldap-rfc2596-05 RFC2596 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3866 10.17487/RFC3866 RFC3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura M. Hiroya H. Beykirch November 2004 ASCII 234572 106 modules data format exchange

The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.

This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.

Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-papi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3867 RFC3868 Signalling Connection Control Part User Adaptation Layer (SUA) J. Loughney Editor G. Sidebottom L. Coene G. Verwimp J. Keller B. Bidulock October 2004 ASCII 294116 131 sctp stream control transmission protocol modular symmetric signalling gateway signalling endpoint architecture

This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. [STANDARDS-TRACK]

 draft-ietf-sigtran-sua-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3868 RFC3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution R. Atkinson Editor S. Floyd Editor Internet Architecture Board August 2004 ASCII 78250 30 internet architecture board internet infrastructure non-commercial funding

This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. This memo provides information for the Internet community.

 draft-iab-research-funding-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3869 RFC3870 application/rdf+xml Media Type Registration A. Swartz September 2004 ASCII 14195 8 xml extensible markup language mime multipurpose internet mail extensions rdf resource description framework

This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. This memo provides information for the Internet community.

 draft-swartz-rdfcore-rdfxml-mediatype-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3870 RFC3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure G. Jones Editor September 2004 ASCII 151101 81

This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. This memo provides information for the Internet community.

 draft-jones-opsec-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3871 RFC3872 Management Information Base for Telephony Routing over IP (TRIP) D. Zinman D. Walker J. Jiang September 2004 ASCII 98614 53 mib

This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. [STANDARDS-TRACK]

 draft-ietf-iptel-trip-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3872 RFC3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) J. Pastor M. Belinchon September 2004 ASCII 82403 46

The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications.

This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. [STANDARDS-TRACK]

 draft-ietf-sigtran-sctp-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3873 RFC3874 A 224-bit One-way Hash Function: SHA-224 R. Housley September 2004 ASCII 11600 6 secure standard

This document specifies a 224-bit one-way hash function, called SHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. This memo provides information for the Internet community.

 draft-ietf-pkix-sha224-01 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3874 RFC3875 The Common Gateway Interface (CGI) Version 1.1 D. Robinson K. Coar October 2004 ASCII 80728 36 PDF 121026 www world wide web

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.

The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. This memo provides information for the Internet community.

 draft-coar-cgi-v11-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3875 10.17487/RFC3875 RFC3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3) D. Chadwick S. Mullan September 2004 ASCII 24233 12 attribute filter

This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. [STANDARDS-TRACK]

 draft-ietf-ldapext-matchedval-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3876 RFC3877 Alarm Management Information Base (MIB) S. Chisholm D. Romascanu September 2004 ASCII 149783 75 alarm mib iana-itu-alarm-tc-mib itu-alarm-tc-mib itu-alarm-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 management objects used for modelling and storing alarms. [STANDARDS-TRACK]

 draft-ietf-disman-alarm-mib-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3877 10.17487/RFC3877 RFC3878 Alarm Reporting Control Management Information Base (MIB) H. Lam A. Huynh D. Perkins September 2004 ASCII 31093 16 alarm condition probably cause

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 controlling the reporting of alarm conditions. [STANDARDS-TRACK]

 draft-ietf-disman-conditionmib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3878 RFC3879 Deprecating Site Local Addresses C. Huitema B. Carpenter September 2004 ASCII 24142 10 ipv6 architecture

This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS-TRACK]

 draft-ietf-ipv6-deprecate-site-local-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3879 RFC3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services J. Lennox X. Wu H. Schulzrinne October 2004 ASCII 154991 74

This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [STANDARDS-TRACK]

 draft-ietf-iptel-cpl-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3880 RFC3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications G. Marshall September 2004 ASCII 86130 47

This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data. This memo provides information for the Internet community.

 draft-marshall-security-audit-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3881 RFC3882 Configuring BGP to Block Denial-of-Service Attacks D. Turk September 2004 ASCII 19637 8 dos border gateway protocol

This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community.

 draft-turk-bgp-dos-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3882 RFC3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC) S. Rao A. Zinin A. Roy October 2004 ASCII 13100 6 OSPF-DC Open Shortest Path First

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem. [STANDARDS-TRACK]

 draft-ietf-ospf-dc-07 RFC1793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3883 RFC3884 Use of IPsec Transport Mode for Dynamic Routing J. Touch L. Eggert Y. Wang September 2004 ASCII 59437 25

IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). This memo provides information for the Internet community.

 draft-touch-ipsec-vpn-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3884 RFC3885 SMTP Service Extension for Message Tracking E. Allman T. Hansen September 2004 ASCII 17458 9 simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]

 draft-ietf-msgtrk-smtpext-05 RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk 10.17487/RFC3885 RFC3886 An Extensible Message Format for Message Tracking Responses E. Allman September 2004 ASCII 21746 11 Delivery Status Notifications DSN Message Disposition Notifications MDN

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. [STANDARDS-TRACK]

 draft-ietf-msgtrk-trkstat-05 RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3886 10.17487/RFC3886 RFC3887 Message Tracking Query Protocol T. Hansen September 2004 ASCII 42763 23 mtqp ESMTP

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS-TRACK]

 draft-ietf-msgtrk-mtqp-12 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3887 10.17487/RFC3887 RFC3888 Message Tracking Model and Requirements T. Hansen September 2004 ASCII 20950 11

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. This memo provides information for the Internet community.

 draft-ietf-msgtrk-model-07 INFORMATIONAL INFORMATIONAL IETF app msgtrk 10.17487/RFC3888 RFC3889 RFC3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) M. Westerlund September 2004 ASCII 49894 22 tias application specific maximum

This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.

The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-bwparam-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3890 RFC3891 The Session Initiation Protocol (SIP) "Replaces" Header R. Mahy B. Biggs R. Dean September 2004 ASCII 34180 16 multi-party applications call control

This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. [STANDARDS-TRACK]

 draft-ietf-sip-replaces-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3891 10.17487/RFC3891 RFC3892 The Session Initiation Protocol (SIP) Referred-By Mechanism R. Sparks September 2004 ASCII 52441 25 REFER

The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK]

 draft-ietf-sip-referredby-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3892 RFC3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format J. Peterson September 2004 ASCII 28500 13 authenticated identity body digitally-signed SIP message message fragment Authenticated Identity Bodies AIB

RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. [STANDARDS-TRACK]

 draft-ietf-sip-authid-body-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3893 RFC3894 Sieve Extension: Copying Without Side Effects J. Degener October 2004 ASCII 9018 5 client server

The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior.

This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. [STANDARDS-TRACK]

 draft-degener-sieve-copy-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3894 RFC3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types O. Nicklass Editor September 2004 ASCII 163841 84 management information base

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 used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2495. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2495bis-06 RFC2495 RFC4805 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3895 RFC3896 Definitions of Managed Objects for the DS3/E3 Interface Type O. Nicklass Editor September 2004 ASCII 129547 63 DS3-E3-MIB management information base

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 used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2496. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2496bis-06 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3896 RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication A. Barbir September 2004 ASCII 33890 14 tracing non-blocking bypass

This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). This memo provides information for the Internet community.

 draft-ietf-opes-end-comm-08 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3897 RFC3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) V. Kalusivalingam October 2004 ASCII 13955 7 NIS Servers NIS+ Servers NIS Client Domain Name NIS+ Client Domain name

This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-opt-nisconfig-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3898 RFC3901 DNS IPv6 Transport Operational Guidelines A. Durand J. Ihren September 2004 ASCII 10025 5 domain name system internet protocol

This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-ipv6-transport-guidelines-02 BCP0091 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC3901 RFC3902 The "application/soap+xml" media type M. Baker M. Nottingham September 2004 ASCII 10575 5

This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. This memo provides information for the Internet community.

 draft-baker-soap-media-reg-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3902 RFC3903 Session Initiation Protocol (SIP) Extension for Event State Publication A. Niemi Editor October 2004 ASCII 72062 32 presence information package

This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. [STANDARDS-TRACK]

 draft-ietf-sip-publish-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3903 RFC3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks C. Huitema R. Austein S. Satapati R. van der Pol September 2004 ASCII 46844 19 home office internet protocol

This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. This memo provides information for the Internet community.

 draft-ietf-v6ops-unmaneval-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3904 RFC3905 A Template for IETF Patent Disclosures and Licensing Declarations V. See Editor September 2004 ASCII 16110 9 ipr

This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. This memo provides information for the Internet community.

 draft-ietf-ipr-template-09 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3905 10.17487/RFC3905 RFC3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels N. Shen H. Smit October 2004 ASCII 18410 8 hop-by-hop link-state routing protocols SPF shortest path first

This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. This memo provides information for the Internet community.

 draft-ietf-rtgwg-igp-shortcut-01 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC3906 RFC3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation K. Zeilenga October 2004 ASCII 13423 7 abandon operation outstanding operation

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. [STANDARDS-TRACK]

 draft-zeilenga-ldap-cancel-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3909 RFC3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol V. Gurbani Editor A. Brusilovsky I. Faynberg J. Gato H. Lu M. Unmehopa October 2004 ASCII 110515 50 pstn sip services event notification eventpackages internet call waiting xml wireless intelligent network in detection point dp

This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built. [STANDARDS-TRACK]

 draft-ietf-spirits-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv spirits 10.17487/RFC3910 RFC3911 The Session Initiation Protocol (SIP) "Join" Header R. Mahy D. Petrie October 2004 ASCII 35373 17

This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative. [STANDARDS-TRACK]

 draft-ietf-sip-join-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3911 RFC3912 WHOIS Protocol Specification L. Daigle September 2004 ASCII 7770 4 NICNAME

This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]

 draft-daigle-rfc954bis-01 RFC0954 RFC0812 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3912 RFC3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification D. Thaler September 2004 ASCII 97443 41 enter-domain source-specific multicast ssm

This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. This memo provides information for the Internet community.

 draft-ietf-bgmp-spec-06 HISTORIC INFORMATIONAL IETF rtg bgmp 10.17487/RFC3913 RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations A. Barbir A. Rousskov October 2004 ASCII 37411 16

IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.

 draft-ietf-opes-iab-05 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3914 RFC3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck September 2004 ASCII 45467 23 dns name system

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rgp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3915 RFC3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) X. Xiao Editor D. McPherson Editor P. Pate Editor September 2004 ASCII 43856 19

This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.

 draft-ietf-pwe3-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3916 RFC3917 Requirements for IP Flow Information Export (IPFIX) J. Quittek T. Zseby B. Claise S. Zander October 2004 ASCII 81615 33 ipfix routers measurment middleboxes

This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.

 draft-ietf-ipfix-reqs-16 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3917 RFC3918 Methodology for IP Multicast Benchmarking D. Stopp B. Hickman October 2004 ASCII 64652 31

The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.

The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. This memo provides information for the Internet community.

 draft-ietf-bmwg-mcastm-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3918 RFC3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS) E. Stephan J. Palet October 2004 ASCII 14228 8 mib

This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895].

This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information. This memo provides information for the Internet community.

 draft-ietf-rmonmib-pi-ipv6-04 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3919 RFC3920 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre Editor October 2004 ASCII 194313 30 instant messaging im extensible markup language xml jabber

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]

 draft-ietf-xmpp-core-24 RFC6120 RFC6122 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3920 10.17487/RFC3920 RFC3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre Editor October 2004 ASCII 217527 107 instant messaging im extensible markup language xml jabber

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]

 draft-ietf-xmpp-im-22 RFC6121 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3921 RFC3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) P. Saint-Andre October 2004 ASCII 70790 34 xml extensible markup language im instant messaging jabber

This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]

 draft-ietf-xmpp-cpim-05 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3922 RFC3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre October 2004 ASCII 51828 27 xml extensible markup language im instant messaging jabber

This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

 draft-ietf-xmpp-e2e-09 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3923 10.17487/RFC3923 RFC3924 Cisco Architecture for Lawful Intercept in IP Networks F. Baker B. Foster C. Sharp October 2004 ASCII 40826 18

For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.

 draft-baker-slem-architecture-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3924 RFC3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) J. Littlefield October 2004 ASCII 17999 9 dhc dhcp class vendor-specific

The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]

 draft-ietf-dhc-vendor-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3925 RFC3926 FLUTE - File Delivery over Unidirectional Transport T. Paila M. Luby R. Lehtonen V. Roca R. Walsh October 2004 ASCII 81224 35

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 memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-flute-08 RFC6726 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=3926 10.17487/RFC3926 RFC3927 Dynamic Configuration of IPv4 Link-Local Addresses S. Cheshire B. Aboba E. Guttman May 2005 ASCII 83102 33 ip network ip address 169.254/16

To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.

IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK]

 draft-ietf-zeroconf-ipv4-linklocal-17 PROPOSED STANDARD PROPOSED STANDARD IETF int zeroconf 10.17487/RFC3927 RFC3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP) R. Megginson Editor M. Smith O. Natkovich J. Parham October 2004 ASCII 36892 30

This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]

 draft-ietf-ldup-lcup-06 PROPOSED STANDARD PROPOSED STANDARD IETF app ldup 10.17487/RFC3928 RFC3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF T. Hardie October 2004 ASCII 26493 11

This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.

 draft-hardie-alt-consensus-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3929 10.17487/RFC3929 RFC3930 The Protocol versus Document Points of View in Computer Protocols D. Eastlake 3rd October 2004 ASCII 36892 15

This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.

 draft-eastlake-proto-doc-pov-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3930 RFC3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3) J. Lau Editor M. Townsley Editor I. Goyret Editor March 2005 ASCII 214407 94 L2TP ppp point-to-point protocol packets

This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]

 draft-ietf-l2tpext-l2tp-base-15 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=3931 10.17487/RFC3931 RFC3932 The IESG and RFC Editor Documents: Procedures H. Alvestrand October 2004 ASCII 17093 8 independent submission

This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.

This document updates procedures described in RFC 2026 and RFC 3710. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iesg-rfced-documents-03 RFC5742 RFC2026 RFC3710 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC3932 RFC3933 A Model for IETF Process Experiments J. Klensin S. Dawkins November 2004 ASCII 14409 7

The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-process-july14-02 BCP0093 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3933 10.17487/RFC3933 RFC3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists M. Wasserman October 2004 ASCII 8488 5 BCP WG escape clause procedures

This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-wasserman-rfc2418-ml-update-01 RFC2418 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3934 RFC3935 A Mission Statement for the IETF H. Alvestrand October 2004 ASCII 16639 7

This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-alvestrand-ietf-mission-02 BCP0095 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3935 RFC3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP) K. Kompella J. Lang October 2004 ASCII 15314 7 resource reservation protocol label switched paths

This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-kompella-rsvp-change-02 RFC3209 RFC2205 BCP0096 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3936 RFC3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC) M. Steidl October 2004 ASCII 15458 9

This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.

 draft-steidl-iptc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3937 RFC3938 Video-Message Message-Context T. Hansen October 2004 ASCII 6224 4 user agent ua

The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message". A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

 draft-hansen-lemonade-msgctxt-videomsg-01 RFC3458 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3938 RFC3939 Calling Line Identification for Voice Mail Messages G. Parsons J. Maruszak December 2004 ASCII 22739 11

This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]

 draft-ema-vpim-clid-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3939 10.17487/RFC3939 RFC3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII 220549 80

This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-pi-norm-10 RFC5740 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3940 RFC3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII 92785 36

This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-norm-09 RFC5401 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3941 RFC3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options B. Volz November 2004 ASCII 13996 7 DHCP-BOOTP Bootstrap

This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]

 draft-ietf-dhc-reclassify-options-01 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3942 10.17487/RFC3942 RFC3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) R. Friend November 2004 ASCII 28942 13 lossless data compression algorithm TLS Record Protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.

 draft-friend-tls-lzs-compression-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3943 RFC3944 H.350 Directory Services T. Johnson S. Okubo S. Campos December 2004 ASCII 61160 30 ldap directory services h.350 h.323 h.320 h.235 sip

The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community.

 draft-johnson-h350-directory-serv-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3944 10.17487/RFC3944 RFC3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture E. Mannie Editor October 2004 ASCII 166700 69

Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-architecture-07 RFC6002 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3945 10.17487/RFC3945 RFC3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou October 2004 ASCII 52205 26

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-sonet-sdh-08 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3946 RFC3947 Negotiation of NAT-Traversal in the IKE T. Kivinen B. Swander A. Huttunen V. Volpe January 2005 ASCII 34759 16

This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]

 draft-ietf-ipsec-nat-t-ike-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3947 RFC3948 UDP Encapsulation of IPsec ESP Packets A. Huttunen B. Swander V. Volpe L. DiBurro M. Stenberg January 2005 ASCII 30366 15

This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]

 draft-ietf-ipsec-udp-encaps-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3948 RFC3949 File Format for Internet Fax R. Buckley D. Venable L. McIntyre G. Parsons J. Rafferty February 2005 ASCII 204903 84 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.

This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the International Telecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. [STANDARDS-TRACK]

 draft-ietf-fax-tiff-fx-14 RFC2301 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3949 RFC3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty February 2005 ASCII 13884 8 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

 draft-ietf-fax-tiff-fx-reg-v2-01 RFC3250 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3950 RFC3951 Internet Low Bit Rate Codec (iLBC) S. Andersen A. Duric H. Astrom R. Hagen W. Kleijn J. Linden December 2004 ASCII 373442 194

This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-avt-ilbc-codec-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3951 RFC3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech A. Duric S. Andersen December 2004 ASCII 28655 13

This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-avt-rtp-ilbc-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3952 RFC3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services J. Peterson January 2005 ASCII 13875 7 uniform resource identifier uri provisioning pres

This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]

 draft-ietf-enum-pres-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3953 RFC3954 Cisco Systems NetFlow Services Export Version 9 B. Claise Editor October 2004 ASCII 76360 33

This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.

 draft-claise-netflow-9-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3954 10.17487/RFC3954 RFC3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) S. Leinen October 2004 ASCII 55143 23

This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.

 draft-leinen-ipfix-eval-contrib-03 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3955 RFC3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola B. Haberman November 2004 ASCII 40136 18 internet protocol

This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]

 draft-ietf-mboned-embeddedrp-07 RFC3306 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC3956 RFC3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 C. Perkins P. Calhoun March 2005 ASCII 63576 27

Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]

 draft-ietf-mip4-aaa-key-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3957 RFC3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle A. Newton January 2005 ASCII 54568 25

This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]

 draft-daigle-snaptr-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3958 10.17487/RFC3958 RFC3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII 22160 11

This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]

 draft-ietf-sipping-early-disposition-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3959 10.17487/RFC3959 RFC3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) G. Camarillo H. Schulzrinne December 2004 ASCII 31692 13

This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.

 draft-ietf-sipping-early-media-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3960 RFC3961 Encryption and Checksum Specifications for Kerberos 5 K. Raeburn February 2005 ASCII 111865 50

This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK]

 draft-ietf-krb-wg-crypto-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=3961 10.17487/RFC3961 RFC3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5 K. Raeburn February 2005 ASCII 32844 16 kerberos cryptosystem suite

The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]

 draft-raeburn-krb-rijndael-krb-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC3962 RFC3963 Network Mobility (NEMO) Basic Support Protocol V. Devarapalli R. Wakikawa A. Petrescu P. Thubert January 2005 ASCII 75955 33 mobile ipv6 session continuity

This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]

 draft-ietf-nemo-basic-support-03 PROPOSED STANDARD PROPOSED STANDARD IETF int nemo 10.17487/RFC3963 RFC3964 Security Considerations for 6to4 P. Savola C. Patel December 2004 ASCII 83360 41

The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community.

 draft-ietf-v6ops-6to4-security-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=3964 10.17487/RFC3964 RFC3965 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing December 2004 ASCII 28157 14 SMFAX-IM data file format e-mail

This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.

This document is a revision of RFC 2305. There have been no technical changes. [STANDARDS-TRACK]

 draft-ietf-fax-service-v2-05 RFC2305 DRAFT STANDARD DRAFT STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3965 10.17487/RFC3965 RFC3966 The tel URI for Telephone Numbers H. Schulzrinne December 2004 ASCII 40783 17 uniform resource locator schemes

This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK]

 draft-ietf-iptel-rfc2806bis-09 RFC2806 RFC5341 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3966 10.17487/RFC3966 RFC3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level R. Bush T. Narten December 2004 ASCII 12251 6

IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ymbk-downref-03 RFC4897 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3967 10.17487/RFC3967 RFC3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII 20615 8

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sip-parameter-registry-02 RFC3427 BCP0098 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3968 RFC3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII 12119 6

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sip-uri-parameter-reg-02 RFC3427 RFC5727 BCP0099 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3969 RFC3970 A Traffic Engineering (TE) MIB K. Kompella January 2005 ASCII 88833 44

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. [STANDARDS-TRACK]

 draft-ietf-tewg-mib-08 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3970 10.17487/RFC3970 RFC3971 SEcure Neighbor Discovery (SEND) J. Arkko Editor J. Kempf B. Zill P. Nikander March 2005 ASCII 123372 56 Neighbor Discovery Protocol NDP

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]

 draft-ietf-send-ndopt-06 RFC6494 RFC6495 RFC6980 PROPOSED STANDARD PROPOSED STANDARD IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3971 10.17487/RFC3971 RFC3972 Cryptographically Generated Addresses (CGA) T. Aura March 2005 ASCII 51473 22 Secure Neighbor Discovery SEND

This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK]

 draft-ietf-send-cga-06 RFC4581 RFC4982 PROPOSED STANDARD PROPOSED STANDARD IETF int send 10.17487/RFC3972 RFC3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) A. Adams J. Nicholas W. Siadak January 2005 ASCII 136708 61 multicast routing protocol prune messages

This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pim-dm-new-v2-05 EXPERIMENTAL EXPERIMENTAL IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=3973 10.17487/RFC3973 RFC3974 SMTP Operational Experience in Mixed IPv4/v6 Environments M. Nakamura J. Hagino January 2005 ASCII 22729 10 simple mail transfer protocol dual stack dualstack ipv4 ipv6

This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.

This document does not define any new protocol. This memo provides information for the Internet community.

 draft-motonori-dualstack-smtp-requirement-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3974 RFC3975 OMA-IETF Standardization Collaboration G. Huston Editor I. Leuca Editor January 2005 ASCII 16926 9 oopen mobile alliance ietf internet engineering task force

This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

 draft-iab-oma-liaison-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3975 RFC3976 Interworking SIP and Intelligent Network (IN) Applications V. K. Gurbani F. Haerens V. Rastogi January 2005 ASCII 60191 25 sip intelligent network call models call model mapping telephony services public switched telephone network pstn

Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). This memo provides information for the Internet community.

 draft-gurbani-sin-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3976 RFC3977 Network News Transfer Protocol (NNTP) C. Feather October 2006 ASCII 247440 125 usenet netnews

The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. [STANDARDS-TRACK]

 draft-ietf-nntpext-base-27 RFC0977 RFC2980 RFC6048 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=3977 10.17487/RFC3977 RFC3978 IETF Rights in Contributions S. Bradner Editor March 2005 ASCII 43574 18 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-subm-rights-fix-00 RFC3667 RFC5378 RFC2026 RFC4748 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3978 10.17487/RFC3978 RFC3979 Intellectual Property Rights in IETF Technology S. Bradner Editor March 2005 ASCII 41366 17 ipr copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC3668 RFC2026 RFC2028 RFC4879 BCP0079 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3979 RFC3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names M. Krueger M. Chadalapaka R. Elliott February 2005 ASCII 14056 8 internet small computer systems interface scsi transport protocol

Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This document updates RFC 3720. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-name-ext-05 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3980 RFC3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol A. Newton M. Sanz January 2005 ASCII 101359 52

This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-core-07 RFC4992 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3981 10.17487/RFC3981 RFC3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz January 2005 ASCII 90901 50

This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-dreg-07 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3982 10.17487/RFC3982 RFC3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) A. Newton M. Sanz January 2005 ASCII 23466 12

This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS-TRACK]

 draft-ietf-crisp-iris-beep-07 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp 10.17487/RFC3983 RFC3984 RTP Payload Format for H.264 Video S. Wenger M.M. Hannuksela T. Stockhammer M. Westerlund D. Singer February 2005 ASCII 205093 83 ITU-T Recommendation H.264 ISO/IEC International Standard 14496-10

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-h264-11 RFC6184 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3984 RFC3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture S. Bryant Editor P. Pate Editor March 2005 ASCII 95062 42

This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

 draft-ietf-pwe3-arch-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3985 RFC3986 Uniform Resource Identifier (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter January 2005 ASCII 141811 61 Internet protocol uniform resource identifier www world wide web

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]

 draft-fielding-uri-rfc2396bis-07 RFC2732 RFC2396 RFC1808 RFC1738 RFC6874 RFC7320 STD0066 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3986 10.17487/RFC3986 RFC3987 Internationalized Resource Identifiers (IRIs) M. Duerst M. Suignard January 2005 ASCII 111190 46 uri uniform resource identifier Universal Character Set

This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.

The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.

 draft-duerst-iri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3987 10.17487/RFC3987 RFC3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol B. Black K. Kompella January 2005 ASCII 18841 9 mtu ldp lsp label switched path label switching router lsr

Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms. This document specifies experimental extensions to LDP in support of LSP MTU discovery. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mpls-ldp-mtu-extensions-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3988 RFC3989 Middlebox Communications (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor February 2005 ASCII 160606 70 nat network address translator firewall

This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This memo provides information for the Internet community.

 draft-ietf-midcom-semantics-08 RFC5189 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3989 RFC3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement B. O'Hara P. Calhoun J. Kempf February 2005 ASCII 11854 5

This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. This memo provides information for the Internet community.

 draft-ietf-capwap-problem-statement-02 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC3990 RFC3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package B. Foster F. Andreasen February 2005 ASCII 22951 11 voice IP internet VoIP

The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. This memo provides information for the Internet community.

 draft-foster-mgcp-redirect-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3991 RFC3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism B. Foster F. Andreasen February 2005 ASCII 9718 5 fault recovery

A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. This memo provides information for the Internet community.

 draft-foster-mgcp-lockstep-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3992 RFC3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option R. Johnson T. Palaniappan M. Stapp March 2005 ASCII 13938 7

This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable "Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

 draft-ietf-dhc-subscriber-id-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3993 RFC3994 Indication of Message Composition for Instant Messaging H. Schulzrinne January 2005 ASCII 27472 13 im status message content type xml extensible markup language

In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS-TRACK]

 draft-ietf-simple-iscomposing-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC3994 RFC3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions R. Herriot T. Hastings March 2005 ASCII 223294 95 optional subscription events subscription objects asynchronous even notification

This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. [STANDARDS-TRACK]

 draft-ietf-ipp-not-spec-12 RFC2911 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3995 RFC3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications R. Herriot T. Hastings H. Lewis March 2005 ASCII 73638 31 pull delivery method event notifications event subscriptions

This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. [STANDARDS-TRACK]

 draft-ietf-ipp-notify-get-10 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3996 RFC3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications T. Hastings Editor R. K. deBry H. Lewis March 2005 ASCII 38185 17 model directory services notification requirements

This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. This memo provides information for the Internet community.

 draft-ietf-ipp-not-07 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3997 RFC3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations C. Kugler H. Lewis T. Hastings Editor March 2005 ASCII 109658 46 system administration operations Enable-Printer and Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs and Release-Held-New-Jobs Deactivate-Printer and Activate-Printer Restart-Printer Shutdown-Printer and Startup-Printer Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Promote-Job Schedule-Job-After

This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet Printing Protocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. (Printer operations: Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer. Job operations: Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After.) [STANDARDS-TRACK]

 draft-ietf-ipp-ops-set2-04 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3998 10.17487/RFC3998 RFC4001 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder February 2005 ASCII 45836 22 MIB management information base internet network layer addressing information

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ops-rfc3291bis-06 RFC3291 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4001 RFC4002 IANA Registration for Enumservice 'web' and 'ft' R. Brandner L. Conroy R. Stastny February 2005 ASCII 18072 10 URI schemes uniform resource identifier enum

This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). [STANDARDS-TRACK]

 draft-ietf-enum-webft-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4002 RFC4003 GMPLS Signaling Procedure for Egress Control L. Berger February 2005 ASCII 10306 5 lsp label switch path gmpls signaling

This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-egress-control-03 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4003 RFC4004 Diameter Mobile IPv4 Application P. Calhoun T. Johansson C. Perkins T. Hiller Editor P. McCann August 2005 ASCII 128210 53 internet protocol version 4 aaa authentication authorization accounting inter-realm diameter accounting

This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-mobileip-20 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4004 10.17487/RFC4004 RFC4005 Diameter Network Access Server Application P. Calhoun G. Zorn D. Spence D. Mitton August 2005 ASCII 198871 85 aaa authentication authorization accounting nas diameter base transport profile extensible authentication protocol radius

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.

The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-nasreq-17 RFC7155 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4005 10.17487/RFC4005 RFC4006 Diameter Credit-Control Application H. Hakala L. Mattila J-P. Koskinen M. Stura J. Loughney August 2005 ASCII 288794 114 real-time credit-control

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-cc-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4006 10.17487/RFC4006 RFC4007 IPv6 Scoped Address Architecture S. Deering B. Haberman T. Jinmei E. Nordmark B. Zill March 2005 ASCII 53555 24 architectural characteristics expected behavior textual representation

This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]

 draft-ietf-ipv6-scoping-arch-02 RFC7346 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4007 RFC4008 Definitions of Managed Objects for Network Address Translators (NAT) R. Rohit P. Srisuresh R. Raghunarayan N. Pai C. Wang March 2005 ASCII 125696 64 mib management information base

This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS-TRACK]

 draft-ietf-nat-natmib-09 RFC7658 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4008 RFC4009 The SEED Encryption Algorithm J. Park S. Lee J. Kim J. Lee February 2005 ASCII 32552 17 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This memo provides information for the Internet community.

 draft-park-seed-01 RFC4269 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4009 10.17487/RFC4009 RFC4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Park S. Lee J. Kim J. Lee February 2005 ASCII 22403 13 smime secure/multipurpose internet mail extensions

This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. [STANDARDS-TRACK]

 draft-ietf-smime-cms-seed-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4010 10.17487/RFC4010 RFC4011 Policy Based Management MIB S. Waldbusser J. Saperia T. Hongal March 2005 ASCII 265942 121 management information base Simple Network Management Protocol snmp infrastructures scripting language script execution environment

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. [STANDARDS-TRACK]

 draft-ietf-snmpconf-pm-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC4011 RFC4012 Routing Policy Specification Language next generation (RPSLng) L. Blunk J. Damas F. Parent A. Robachevsky March 2005 ASCII 35217 16

This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK]

 draft-blunk-rpslng-08 RFC2725 RFC2622 RFC7909 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4012 RFC4013 SASLprep: Stringprep Profile for User Names and Passwords K. Zeilenga February 2005 ASCII 13051 6 unicode strings saslprep stringprep sasl simple authentication and security layer

This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS-TRACK]

 draft-ietf-sasl-saslprep-10 RFC7613 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4013 10.17487/RFC4013 RFC4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option R. Droms J. Schnizlein February 2005 ASCII 15416 8

The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK]

 draft-ietf-dhc-agentopt-radius-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4014 RFC4015 The Eifel Response Algorithm for TCP R. Ludwig A. Gurtov February 2005 ASCII 31512 13 transmision control protocol

Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tcp-eifel-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4015 RFC4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements M. Parthasarathy March 2005 ASCII 36104 15 authentication network access

This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. This memo provides information for the Internet community.

 draft-ietf-pana-threats-eval-07 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4016 RFC4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs D. Stanley J. Walker B. Aboba March 2005 ASCII 22183 11 IEEE 802.11 wireless lan

The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

 draft-walker-ieee802-req-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4017 RFC4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) M. Bakke J. Hufferd K. Voruganti M. Krueger T. Sperry April 2005 ASCII 48498 23 scsi slp

The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. [PROPOSED STANDARD]

 draft-ietf-ips-iscsi-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4018 RFC4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite G. Pelletier April 2005 ASCII 46896 23 rtp udp-lite ip real-time transport protocol user datagram protocol lite internet protocol

This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS-TRACK]

 draft-ietf-rohc-udp-lite-04 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4019 RFC4020 Early IANA Allocation of Standards Track Code Points K. Kompella A. Zinin February 2005 ASCII 13706 7

This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-kompella-zinin-early-allocation-02 RFC7120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4020 RFC4021 Registration of Mail and MIME Header Fields G. Klyne J. Palme March 2005 ASCII 75452 54 IANA

This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]

 draft-klyne-hdrreg-mail-05 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4021 RFC4022 Management Information Base for the Transmission Control Protocol (TCP) R. Raghunarayan Editor March 2005 ASCII 47360 24 MIB-TCP TCP Simple Network Management Protocol 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 used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2012-update-06 RFC2452 RFC2012 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4022 RFC4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) T. Worster Y. Rekhter E. Rosen Editor March 2005 ASCII 31696 14

Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-TRACK]

 draft-ietf-mpls-in-ip-or-gre-08 RFC5332 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4023 RFC4024 Voice Messaging Client Behaviour G. Parsons J. Maruszak July 2005 ASCII 18560 9 vpim profile internet mail voice profile for internet mail fax message

This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message. This memo provides information for the Internet community.

 draft-ema-vpim-cb-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4024 RFC4025 A Method for Storing IPsec Keying Material in DNS M. Richardson March 2005 ASCII 25408 12

This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.

This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]

 draft-ietf-ipseckey-rr-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipseckey 10.17487/RFC4025 RFC4026 Provider Provisioned Virtual Private Network (VPN) Terminology L. Andersson T. Madsen March 2005 ASCII 42124 20 l3vpn l2vpn

The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.

To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.

 draft-ietf-l3vpn-ppvpn-terminology-04 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4026 10.17487/RFC4026 RFC4027 Domain Name System Media Types S. Josefsson April 2005 ASCII 11676 6 media type application/dns text/dns

This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. This memo provides information for the Internet community.

 draft-josefsson-mime-dns-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4027 RFC4028 Session Timers in the Session Initiation Protocol (SIP) S. Donovan J. Rosenberg April 2005 ASCII 65363 27 re-invite request update request session-expires min-se

This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a \%re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: \%Session-Expires, which conveys the lifetime of the session, and \%Min-SE, which conveys the minimum allowed value for the session timer. [STANDARDS-TRACK]

 draft-ietf-sip-session-timer-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4028 10.17487/RFC4028 RFC4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks M. Lind V. Ksinant S. Park A. Baudot P. Savola March 2005 ASCII 64388 28 internet service provider internet protocol

This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified. This memo provides information for the Internet community.

 draft-ietf-v6ops-isp-scenarios-analysis-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4029 10.17487/RFC4029 RFC4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp T. Lemon March 2005 ASCII 34332 15

The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS-TRACK]

 draft-ietf-dhc-auth-suboption-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4030 RFC4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) M. Carugi Editor D. McDysan Editor April 2005 ASCII 118568 50 l3vpn service provider vpn

This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This memo provides information for the Internet community.

 draft-ietf-l3vpn-requirements-02 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4031 RFC4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework G. Camarillo P. Kyzivat March 2005 ASCII 20492 10 qos quality of service precondition

This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS-TRACK]

 draft-ietf-sip-rfc3312-update-03 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4032 RFC4033 DNS Security Introduction and Requirements R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII 52445 21 domain name system authentication origin integrity dnssec domain name system security extensions

The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-intro-13 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC6014 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4033 10.17487/RFC4033 RFC4034 Resource Records for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII 63879 29 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-records-11 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4034 10.17487/RFC4034 RFC4035 Protocol Modifications for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII 130589 53 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-protocol-09 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4035 10.17487/RFC4035 RFC4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management W. Sawyer April 2005 ASCII 57946 27 mib snmp simple network management 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 a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. [STANDARDS-TRACK]

 draft-ietf-ipcdn-subscriber-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4036 RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core A. Rousskov March 2005 ASCII 131487 56 callout server

This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. [STANDARDS-TRACK]

 draft-ietf-opes-ocp-core-05 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4037 RFC4038 Application Aspects of IPv6 Transition M-K. Shin Editor Y-G. Hong J. Hagino P. Savola E. M. Castro March 2005 ASCII 69727 33

As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. This memo provides information for the Internet community.

 draft-ietf-v6ops-application-transition-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4038 RFC4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) S. Park P. Kim B. Volz March 2005 ASCII 22297 10

This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. [STANDARDS-TRACK]

 draft-ietf-dhc-rapid-commit-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4039 RFC4040 RTP Payload Format for a 64 kbit/s Transparent Call R. Kreuter April 2005 ASCII 15363 8 realtime transport protocol

This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called "Clearmode". It also serves as registration for a related MIME type called "audio/clearmode".

"Clearmode" is a basic feature of VoIP Media Gateways. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-clearmode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4040 RFC4041 Requirements for Morality Sections in Routing Area Drafts A. Farrel April 1 2005 ASCII 15249 8 moral values moral code

It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.

This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. This memo provides information for the Internet community.

 draft-farrel-rtg-morality-requirements-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4041 RFC4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode M. Crispin April 1 2005 ASCII 19123 9 universal character set ucs codeopints unicode utf-7 utf-8 utf-16

ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization.

The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.

This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4042 RFC4043 Internet X.509 Public Key Infrastructure Permanent Identifier D. Pinkas T. Gindin May 2005 ASCII 30092 15 subjectAltName extension dn

This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.

The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.

The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK]

 draft-ietf-pkix-pi-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4043 10.17487/RFC4043 RFC4044 Fibre Channel Management MIB K. McCloghrie May 2005 ASCII 127148 69 management information base fc-mgmt-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. [STANDARDS-TRACK]

 draft-ietf-ips-fcmgmt-mib-06 RFC2837 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4044 RFC4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) G. Bourdon April 2005 ASCII 59140 28 ppp point-to-point protocol

The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-l2tpext-mcast-05 EXPERIMENTAL EXPERIMENTAL IETF int l2tpext 10.17487/RFC4045 RFC4046 Multicast Security (MSEC) Group Key Management Architecture M. Baugher R. Canetti L. Dondeti F. Lindholm April 2005 ASCII 97885 38 group security association gsa

This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community.

 draft-ietf-msec-gkmarch-08 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4046 RFC4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS) S. Allen D. Wells April 2005 ASCII 53737 23 multipurpose internet mail extensions astronomical observations

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. This memo provides information for the Internet community.

 draft-allen-fitsmime-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4047 RFC4048 RFC 1888 Is Obsolete B. Carpenter April 2005 ASCII 7394 4 Internet Protocol Open Systems Interconnection

This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community.

 draft-carpenter-obsolete-1888-01 RFC1888 RFC4548 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4048 10.17487/RFC4048 RFC4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley April 2005 ASCII 12302 7 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. This memo defines an Experimental Protocol for the Internet community.

 draft-housley-binarytime-02 RFC6019 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4049 RFC4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures S. Blake-Wilson G. Karlinger T. Kobayashi Y. Wang April 2005 ASCII 35327 19 elliptic curve digital signature algorithm ecdsa elliptic curve cryptography ecc xml digital signatures xml dsig xml

This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. This memo provides information for the Internet community.

 draft-blake-wilson-xmldsig-ecdsa-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4050 RFC4051 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2005 ASCII 33368 17 digital signatures encryption canonicalization

A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information. [STANDARDS-TRACK]

 draft-eastlake-xmldsig-uri-09 RFC6931 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4051 10.17487/RFC4051 RFC4052 IAB Processes for Management of IETF Liaison Relationships L. Daigle Editor Internet Architecture Board April 2005 ASCII 18360 9 internet architecture board sdo standards development organization

This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-liaison-mgt-03 BCP0102 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=4052 10.17487/RFC4052 RFC4053 Procedures for Handling Liaison Statements to and from the IETF S. Trowbridge S. Bradner F. Baker April 2005 ASCII 38816 19 sdo standards develoopment organization

This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.

The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-baker-liaison-statements-04 BCP0103 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4053 RFC4054 Impairments and Other Constraints on Optical Layer Routing J. Strand Editor A. Chiu Editor May 2005 ASCII 73327 29 diversity routing path selection impariment ase pmd optical control plane gmpls

Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. This memo provides information for the Internet community.

 draft-ietf-ipo-impairments-04 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC4054 RFC4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile J. Schaad B. Kaliski R. Housley June 2005 ASCII 57479 25 ASN.1 RSASSA-PSS RSA probabilistic signature scheme signature algorithm RSAES-OAEP RSA encryption scheme optimal asymmetric encryption padding public-key cryptography standards PKCS pki

This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]

 draft-ietf-pkix-rsa-pkalgs-03 RFC3279 RFC5756 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4055 10.17487/RFC4055 RFC4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS) J. Schaad June 2005 ASCII 11514 6 RSA probabilistic signature scheme digital signature

This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

 draft-ietf-smime-pss-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC4056 RFC4057 IPv6 Enterprise Network Scenarios J. Bound Editor June 2005 ASCII 33454 17 internet protocol version 6

This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. This memo provides information for the Internet community.

 draft-ietf-v6ops-ent-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4057 10.17487/RFC4057 RFC4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements A. Yegin Editor Y. Ohba R. Penno G. Tsirtsis C. Wang May 2005 ASCII 41957 19 network connectivity link layer agnostic protocol

It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure. This memo provides information for the Internet community.

 draft-ietf-pana-requirements-09 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4058 RFC4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension D. Linsenbardt S. Pontius A. Sturgeon May 2005 ASCII 17904 9 certificate authority ca insurance policy

This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This memo provides information for the Internet community.

 draft-ietf-pkix-warranty-extn-04 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4059 RFC4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding Q. Xie D. Pearce May 2005 ASCII 39654 19 real-time transport protocol dsr distributed speeech recognition xfe extended front-end xafe extended advanced front-end

This document specifies RTP payload formats for encapsulating European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-dsr-codecs-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4060 10.17487/RFC4060 RFC4061 Benchmarking Basic OSPF Single Router Control Plane Convergence V. Manral R. White A. Shaikh April 2005 ASCII 32706 16 spf time adjacency formation time

This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance.

NOTE: In this document, the word "convergence" relates to single router control plane convergence only. This memo provides information for the Internet community.

 draft-ietf-bmwg-ospfconv-intraarea-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4061 RFC4062 OSPF Benchmarking Terminology and Concepts V. Manral R. White A. Shaikh April 2005 ASCII 15784 9 spf time adjacency formation time

This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. This memo provides information for the Internet community.

 draft-ietf-bmwg-ospfconv-term-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4062 RFC4063 Considerations When Using Basic OSPF Convergence Benchmarks V. Manral R. White A. Shaikh April 2005 ASCII 23401 11 spf time adjacency formation time

This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. This memo provides information for the Internet community.

 draft-ietf-bmwg-ospfconv-applicability-07 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4063 RFC4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4 A. Patel K. Leung May 2005 ASCII 20748 11 internet protocol message types

Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. [STANDARDS-TRACK]

 draft-ietf-mip4-experimental-messages-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4064 RFC4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations J. Kempf July 2005 ASCII 16179 8 candidate access router discovery card context transfer protocol CXTP ICMP

The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-seamoby-iana-02 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4065 RFC4066 Candidate Access Router Discovery (CARD) M. Liebsch Editor A. Singh Editor H. Chaskar D. Funato E. Shim July 2005 ASCII 116733 46 mobile node mn cars candidate ars

To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-seamoby-card-protocol-08 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4066 RFC4067 Context Transfer Protocol (CXTP) J. Loughney Editor M. Nakhjiri C. Perkins R. Koodli July 2005 ASCII 77718 33 mobile node mn

This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-seamoby-ctp-11 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4067 RFC4068 Fast Handovers for Mobile IPv6 R. Koodli Editor July 2005 ASCII 93591 42 internet protocol version 6 access router mobile node mn

Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mipshop-fast-mipv6-03 RFC5268 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC4068 RFC4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding M. Dodge B. Ray May 2005 ASCII 35712 19 mib management information base VDSL-LINE-MIB VDSL-LINE-EXT-SCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl-ext-scm-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4069 RFC4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding M. Dodge B. Ray May 2005 ASCII 48561 24 management information base mib VDSL-LINE-MIB VDSL-LINE-EXT-MCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl-ext-mcm-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4070 RFC4071 Structure of the IETF Administrative Support Activity (IASA) R. Austein Editor B. Wijnen Editor April 2005 ASCII 48614 20 isoc ietf administrative oversight committee IAOC ietf administrative director iad

This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-iasa-bcp-07 RFC4371 RFC7691 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4071 RFC4072 Diameter Extensible Authentication Protocol (EAP) Application P. Eronen Editor T. Hiller G. Zorn August 2005 ASCII 79965 33 command codes avp nas network access server back-end autentication server

The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]

 draft-ietf-aaa-eap-10 RFC7268 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4072 10.17487/RFC4072 RFC4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS) R. Housley May 2005 ASCII 17103 9 content collection

This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]

 draft-housley-contentcollection-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4073 10.17487/RFC4073 RFC4074 Common Misbehavior Against DNS Queries for IPv6 Addresses Y. Morishita T. Jinmei May 2005 ASCII 13073 6 resource records aaaa domain name service

There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. This memo provides information for the Internet community.

 draft-ietf-dnsop-misbehavior-against-aaaa-02 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4074 RFC4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 V. Kalusivalingam May 2005 ASCII 9424 5 dynamic host configuration protocol server addresses

This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-opt-sntp-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4075 RFC4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) T. Chown S. Venaas A. Vijayabhaskar May 2005 ASCII 15745 8 internet protocol stateless address autoconfiguration

IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This memo provides information for the Internet community.

 draft-ietf-dhc-stateless-dhcpv6-renumbering-02 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4076 RFC4077 A Negative Acknowledgement Mechanism for Signaling Compression A.B. Roach May 2005 ASCII 34250 16 sigcomp negative feedback

This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]

 draft-ietf-rohc-sigcomp-nack-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4077 RFC4078 The TV-Anytime Content Reference Identifier (CRID) N. Earnshaw S. Aoki A. Ashley W. Kameyama May 2005 ASCII 21433 10 digital broadcasting tv radio uri uniform resource identifier content referencing storage systems

The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.

The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.

This document reproduces the \%TV-Anytime CRID definition found in the \%TV-Anytime content referencing specification, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

 draft-earnshaw-tv-anytime-crid-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4078 RFC4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects J. Peterson July 2005 ASCII 16718 7 using protocol

GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. This memo provides information for the Internet community.

 draft-ietf-geopriv-pres-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC4079 RFC4080 Next Steps in Signaling (NSIS): Framework R. Hancock G. Karagiannis J. Loughney S. Van den Bosch June 2005 ASCII 122470 49 data flow architectural framework signaling protocols signaling application

The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.

This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. This memo provides information for the Internet community.

 draft-ietf-nsis-fw-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4080 RFC4081 Security Threats for Next Steps in Signaling (NSIS) H. Tschofenig D. Kroeselberg June 2005 ASCII 67786 28

This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. This memo provides information for the Internet community.

 draft-ietf-nsis-threats-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4081 RFC4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction A. Perrig D. Song R. Canetti J. D. Tygar B. Briscoe June 2005 ASCII 54316 22 data streams

This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.

This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. This memo provides information for the Internet community.

 draft-ietf-msec-tesla-intro-04 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4082 RFC4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) M. Garcia-Martin May 2005 ASCII 80203 36 3GPP IP multimedia core network subsystem ims cellular networks

The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. This memo provides information for the Internet community.

 draft-ietf-sipping-3gpp-r5-requirements-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4083 RFC4084 Terminology for Describing Internet Connectivity J. Klensin May 2005 ASCII 24522 11

As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-ip-service-terms-04 BCP0104 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4084 10.17487/RFC4084 RFC4085 Embedding Globally-Routable Internet Addresses Considered Harmful D. Plonka June 2005 ASCII 22656 10

This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-embed-addr-05 BCP0105 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4085 RFC4086 Randomness Requirements for Security D. Eastlake 3rd J. Schiller S. Crocker June 2005 ASCII 114321 48 cryptographic algorithms passwords cryptographic keys pseudo-random random numbers seed

Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-eastlake-randomness2-10 RFC1750 BCP0106 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4086 10.17487/RFC4086 RFC4087 IP Tunnel MIB D. Thaler June 2005 ASCII 53206 25 management information base internet protocol tunnel-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK]

 draft-ietf-ipv6-inet-tunnel-mib-03 RFC2667 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4087 RFC4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) D. Black K. McCloghrie J. Schoenwaelder June 2005 ASCII 43019 18 uri uniform resource identifiers snmp-uri

The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.

This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances. [STANDARDS-TRACK]

 draft-black-snmp-uri-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4088 RFC4089 IAB and IESG Recommendation for IETF Administrative Restructuring S. Hollenbeck Editor IAB and IESG May 2005 ASCII 128660 55 internet architecture board internet engineering steering group internet engineering task force

This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community.

 draft-iab-iesg-adminrest-rec-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4089 RFC4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels P. Pan Editor G. Swallow Editor A. Atlas Editor May 2005 ASCII 83965 38 resource reservation protocol traffic engineering lsp label switch path one-to-one backup facility backup

This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.

Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-lsp-fastreroute-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4090 10.17487/RFC4090 RFC4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework G. Camarillo J. Rosenberg June 2005 ASCII 12931 7

This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]

 draft-ietf-mmusic-anat-02 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4091 RFC4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) G. Camarillo J. Rosenberg June 2005 ASCII 12624 6 sdp-anat option-tag

This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]

 draft-ietf-sip-anat-usage-00 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4092 RFC4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways F. Adrangi Editor H. Levkowetz Editor August 2005 ASCII 44082 19

Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. This memo provides information for the Internet community.

 draft-ietf-mip4-vpn-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC4093 RFC4094 Analysis of Existing Quality-of-Service Signaling Protocols J. Manner X. Fu May 2005 ASCII 103146 45 qos quality of service rsvp nsis yessir boomerang daris insignia bgrp sicap mobility performance security

This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. This memo provides information for the Internet community.

 draft-ietf-nsis-signalling-analysis-05 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4094 RFC4095 Attaching Meaning to Solicitation Class Keywords C. Malamud May 2005 ASCII 23539 11 uri uniform resource identifier no soliciting smtp service extension esmtp service extension dynamic delegation discovery system ddds no-solicit

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.

This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]

 draft-malamud-keyword-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4095 RFC4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best C. Malamud May 2005 ASCII 31618 14

This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, \%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. This memo provides information for the Internet community.

 draft-malamud-subject-line-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4096 RFC4097 Middlebox Communications (MIDCOM) Protocol Evaluation M. Barnes Editor June 2005 ASCII 99303 44 snmp simple network management protocol rsip realm specific internet protocol megaco diameter cops common open policy service

This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. This memo provides information for the Internet community.

 draft-ietf-midcom-protocol-eval-06 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC4097 RFC4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane H. Berkowitz E. Davies Editor S. Hares P. Krishnaswamy M. Lepp June 2005 ASCII 66845 36 border gateway protocol benchmarking methodology ebgp

This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. This memo provides information for the Internet community.

 draft-ietf-bmwg-conterm-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4098 RFC4101 Writing Protocol Models E. Rescorla IAB June 2005 ASCII 47287 22 document review

The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community.

 draft-iab-model-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4101 RFC4102 Registration of the text/red MIME Sub-Type P. Jones June 2005 ASCII 11337 6 rtp real-time transport protocol

This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]

 draft-ietf-avt-text-red-05 RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4102 10.17487/RFC4102 RFC4103 RTP Payload for Text Conversation G. Hellstrom P. Jones June 2005 ASCII 44246 20 real-time applications video audio packets

This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2793bis-09 RFC2793 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4103 10.17487/RFC4103 RFC4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS) M. Pana Editor A. Reyes A. Barba D. Moron M. Brunner June 2005 ASCII 190951 88 policy core lightweight directory access protocol pcim policy core information model mapping classes

This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. [STANDARDS-TRACK]

 draft-reyes-policy-core-ext-schema-07 RFC3703 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4104 RFC4105 Requirements for Inter-Area MPLS Traffic Engineering J.-L. Le Roux Editor J.-P. Vasseur Editor J. Boyle Editor June 2005 ASCII 50111 22 multiprotocol label switching mpls-te mpls te

This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements. This memo provides information for the Internet community.

 draft-ietf-tewg-interarea-mpls-te-req-03 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4105 RFC4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) J. Viega D. McGrew June 2005 ASCII 23399 11 aes advanced encryption standard

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

 draft-ietf-ipsec-ciph-aes-gcm-00 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4106 10.17487/RFC4106 RFC4107 Guidelines for Cryptographic Key Management S. Bellovin R. Housley June 2005 ASCII 14752 7 automated key management manual key management

The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bellovin-mandate-keymgmt-03 BCP0107 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4107 RFC4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages R. Housley August 2005 ASCII 142060 61 hardward module components digital signature

This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]

 draft-housley-cms-fw-wrap-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4108 10.17487/RFC4108 RFC4109 Algorithms for Internet Key Exchange version 1 (IKEv1) P. Hoffman May 2005 ASCII 9491 5 ike ipsec oakley authentication isakmp internet security key management

The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]

 draft-hoffman-ikev1-algorithms-03 RFC2409 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4109 RFC4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) R. Callon M. Suzuki July 2005 ASCII 204159 82

This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This memo provides information for the Internet community.

 draft-ietf-l3vpn-framework-00 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4110 RFC4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) L. Fang Editor July 2005 ASCII 106626 45

This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community.

 draft-ietf-l3vpn-security-framework-03 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4111 10.17487/RFC4111 RFC4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification D. Eastlake 3rd June 2005 ASCII 72537 34

Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]

 draft-ietf-trade-ecml2-spec-13 RFC3106 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC4112 RFC4113 Management Information Base for the User Datagram Protocol (UDP) B. Fenner J. Flick June 2005 ASCII 40323 19 MIB-UDP mib UDP-MIB internet protocol ip

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2013-update-04 RFC2454 RFC2013 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4113 10.17487/RFC4113 RFC4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck June 2005 ASCII 31490 17 shared central repository

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]

 draft-ietf-enum-epp-e164-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=4114 10.17487/RFC4114 RFC4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic O. Aboul-Magd S. Rabie July 2005 ASCII 12131 6 data services service scenarios metering algorithm color-blind color-aware

This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community.

 draft-aboulmagd-trtcm-inprofile-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4115 RFC4116 IPv4 Multihoming Practices and Limitations J. Abley K. Lindqvist E. Davies B. Black V. Gill July 2005 ASCII 26598 13 internet protocol

Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). This memo provides information for the Internet community.

 draft-ietf-multi6-v4-multihoming-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4116 RFC4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) G. Camarillo E. Burger H. Schulzrinne A. van Wijk June 2005 ASCII 37951 19 deaf hard of hearing speech-impaired hearing-impaired

This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. This memo provides information for the Internet community.

 draft-ietf-sipping-transc-3pcc-02 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4117 10.17487/RFC4117 RFC4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP) L. Yang P. Zerfos E. Sadot June 2005 ASCII 93695 41 IEEE 802.11 wireless lan

This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. This memo provides information for the Internet community.

 draft-ietf-capwap-arch-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4118 RFC4119 A Presence-based GEOPRIV Location Object Format J. Peterson December 2005 ASCII 53522 24 pidf presence information data format

This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK]

 draft-ietf-geopriv-pidf-lo-03 RFC5139 RFC5491 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4119 10.17487/RFC4119 RFC4120 The Kerberos Network Authentication Service (V5) C. Neuman T. Yu S. Hartman K. Raeburn July 2005 ASCII 340314 138 KERBEROS CAT,Security

This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]

 draft-ietf-krb-wg-kerberos-clarifications-07 RFC1510 RFC4537 RFC5021 RFC5896 RFC6111 RFC6112 RFC6113 RFC6649 RFC6806 RFC7751 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4120 10.17487/RFC4120 RFC4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 L. Zhu K. Jaganathan S. Hartman July 2005 ASCII 340314 20 GSSAPI-KER cryptosystem

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 Kerberos Version 5 mechanism.

RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. [STANDARDS-TRACK]

 draft-ietf-krb-wg-gssapi-cfx-07 RFC1964 RFC6112 RFC6542 RFC6649 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4121 RFC4122 A Universally Unique IDentifier (UUID) URN Namespace P. Leach M. Mealling R. Salz July 2005 ASCII 59319 32 uniform resource name guid globally unique identifier

This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.

This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]

 draft-mealling-uuid-urn-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4122 10.17487/RFC4122 RFC4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements H. Schulzrinne C. Agboh July 2005 ASCII 29244 16 SIP-H.323 IWF

This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. This memo provides information for the Internet community.

 draft-agrawal-sip-h323-interworking-reqs-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4123 RFC4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII 79265 37 DS-TE igp interior gateway protocol extensions rsvp resource reservation protocol

This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]

 draft-ietf-tewg-diff-te-proto-08 PROPOSED STANDARD PROPOSED STANDARD IETF subip tewg 10.17487/RFC4124 RFC4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur W. Lai June 2005 ASCII 22585 12 ds-te maximum allocation model

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tewg-diff-te-mam-04 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4125 RFC4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons J. Ash June 2005 ASCII 51232 22 diffserv-enabled mpls traffic engineering ds-te mar bandwidth reservation bandwidth allocation bandwidth protection performance evaluation cac network model

This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tewg-diff-te-mar-06 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4126 RFC4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII 23694 13 ds-te russian dolls model multi-protocol label switching

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tewg-diff-te-russian-07 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4127 RFC4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation W. Lai June 2005 ASCII 58691 25 PDF 201138 label switched path lsp lsp blocking lsp preemption lsp priority traffic overload bandwidth efficiency bandwidth sharing bandwidth protection class isolation maximum allocation model russian dolls model

"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. This memo provides information for the Internet community.

 draft-wlai-tewg-bcmodel-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4128 RFC4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol R. Mukundan K. Morneault N. Mangalpally September 2005 ASCII 29034 15 backhauling isdn user adaptation pbx private branch exchanges

This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network. DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. [STANDARDS-TRACK]

 draft-ietf-sigtran-dua-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4129 RFC4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) D. Moberg R. Drummond July 2005 ASCII 99857 47 hyper text transfer protocol simple mail transfer protocol

This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. [STANDARDS-TRACK]

 draft-ietf-ediint-as2-20 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4130 10.17487/RFC4130 RFC4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus S. Green K. Ozawa E. Cardona Editor A. Katsnelson September 2005 ASCII 183091 85 mib snmp simple network management protocol docs-ietf-bpi2-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 a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

 draft-ietf-ipcdn-bpiplus-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4131 RFC4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS) S. Moriai A. Kato M. Kanda July 2005 ASCII 13590 7 camellia encryption algorithm

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

 draft-ietf-tls-camellia-06 RFC5932 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4132 RFC4133 Entity MIB (Version 3) A. Bierman K. McCloghrie August 2005 ASCII 136711 62 management information base snmp simple network management 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 describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). [STANDARDS-TRACK]

 draft-ietf-entmib-v3-07 RFC2737 RFC6933 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4133 10.17487/RFC4133 RFC4134 Examples of S/MIME Messages P. Hoffman Editor July 2005 ASCII 325865 136

This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This memo provides information for the Internet community.

 draft-ietf-smime-examples-15 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4134 10.17487/RFC4134 RFC4135 Goals of Detecting Network Attachment in IPv6 JH. Choi G. Daley August 2005 ASCII 20518 9 dna detecting attachment links change detection

When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling. This memo provides information for the Internet community.

 draft-ietf-dna-goals-04 INFORMATIONAL INFORMATIONAL IETF int dna 10.17487/RFC4135 RFC4136 OSPF Refresh and Flooding Reduction in Stable Topologies P. Pillay-Esnault July 2005 ASCII 8534 5 open shortest path first link state advertisement lsa donotage

This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.

Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies. This memo provides information for the Internet community.

 draft-pillay-esnault-ospf-flooding-07 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4136 RFC4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator J. Vollbrecht P. Eronen N. Petroni Y. Ohba August 2005 ASCII 105781 51 PDF 107470 eap stand-alone authenticator eap backend authenticator eap full authenticator

This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.

The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.

The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

 draft-ietf-eap-statemachine-06 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC4137 RFC4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) P. Sarolahti M. Kojo August 2005 ASCII 55538 23 tcp transmission control protocol

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-frto-02 RFC5682 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC4138 RFC4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) D. Papadimitriou J. Drake J. Ash A. Farrel L. Ong July 2005 ASCII 36660 16 tdm otn control plane call connection

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-reqts-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4139 RFC4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6) H. Soliman C. Castelluccia K. El Malki L. Bellier August 2005 ASCII 71503 29 internet protocol version 6 neighbour discovery neighbor discovery mobility anchor point map

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mipshop-hmipv6-04 RFC5380 EXPERIMENTAL EXPERIMENTAL IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4140 10.17487/RFC4140 RFC4141 SMTP and MIME Extensions for Content Conversion K. Toyoda D. Crocker November 2005 ASCII 55606 26 esmtp simple mail transfer protocol extended simple mail transfer protocol multipurpose internet mail extensions

A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white). In a store-and-forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries. [STANDARDS-TRACK]

 draft-ietf-fax-esmtp-conneg-13 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4141 10.17487/RFC4141 RFC4142 Full-mode Fax Profile for Internet Mail (FFPIM) D. Crocker G. Klyne November 2005 ASCII 16791 9 facsimile full mode internet mail

Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users. [PROPOSED STANDARD]

 draft-ietf-fax-ffpim-08 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC4142 RFC4143 Facsimile Using Internet Mail (IFAX) Service of ENUM K. Toyoda D. Crocker November 2005 ASCII 8642 5 naptr enum naming authority pointer facsimile using internet mail dns domain name system

This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service. IFax is "facsimile using Internet mail". For this use, the Domain Name System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address. [STANDARDS-TRACK]

 draft-ietf-fax-faxservice-enum-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4143 10.17487/RFC4143 RFC4144 How to Gain Prominence and Influence in Standards Organizations D. Eastlake 3rd September 2005 ASCII 19529 9

This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations. This memo provides information for the Internet community.

 draft-eastlake-prominence-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4144 RFC4145 TCP-Based Media Transport in the Session Description Protocol (SDP) D. Yon G. Camarillo September 2005 ASCII 30225 15 setup connection reestablishment

This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-comedia-10 RFC4572 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4145 RFC4146 Simple New Mail Notification R. Gellens August 2005 ASCII 8561 5 mail client nm_notifyuser

This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.

In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail. This memo provides information for the Internet community.

 draft-gellens-notify-mail-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4146 RFC4147 Proposed Changes to the Format of the IANA IPv6 Registry G. Huston August 2005 ASCII 21196 10 internet protocol version 6 address format address architecture

This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format. The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format. This memo provides information for the Internet community.

 draft-huston-ip6-iana-registry-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4147 10.17487/RFC4147 RFC4148 IP Performance Metrics (IPPM) Metrics Registry E. Stephan August 2005 ASCII 23074 14 internet protocol object identities iana-ippm-metrics-registry-mib

This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.

This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.

IANA has been assigned to administer this new registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ippm-metrics-registry-08 RFC6248 BCP0108 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm 10.17487/RFC4148 RFC4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms C. Kalbfleisch R. Cole D. Romascanu August 2005 ASCII 78560 39 sspm mib management information base sspm 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 objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]

 draft-ietf-rmonmib-sspm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4149 RFC4150 Transport Performance Metrics MIB R. Dietz R. Cole August 2005 ASCII 123144 57 managgement information base tpm tpm-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 used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. [STANDARDS-TRACK]

 draft-ietf-rmonmib-tpm-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4150 RFC4151 The 'tag' URI Scheme T. Kindberg S. Hawke October 2005 ASCII 22555 11 uniform resource identifier entity identifier

This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community.

 draft-kindberg-tag-uri-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4151 10.17487/RFC4151 RFC4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code K. Tesink R. Fox August 2005 ASCII 12228 7 ansi ansi t1.213

This document describes a Uniform Resource Name (URN) namespace (RFC 3406) for the assignment of the Common Language Equipment Identifier (CLEI) code, which is used in messages standardized by ANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number). This memo provides information for the Internet community.

 draft-tesink-urn-clei-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4152 RFC4153 XML Voucher: Generic Voucher Language K. Fujimura M. Terada D. Eastlake 3rd September 2005 ASCII 41941 21 extensible markup language logical entity

This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

 draft-ietf-trade-voucher-lang-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4153 RFC4154 Voucher Trading System Application Programming Interface (VTS-API) M. Terada K. Fujimura September 2005 ASCII 61629 32 wallet transfer redeem

This document specifies the Voucher Trading System Application Programming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

 draft-ietf-trade-voucher-vtsapi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4154 RFC4155 The application/mbox Media Type E. Hall September 2005 ASCII 19645 9 mbox database

This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations. This memo provides information for the Internet community.

 draft-hall-mime-app-mbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4155 RFC4156 The wais URI Scheme P. Hoffman August 2005 ASCII 6564 4 uniform resource identifier

This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

 draft-hoffman-wais-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4156 10.17487/RFC4156 RFC4157 The prospero URI Scheme P. Hoffman August 2005 ASCII 7096 4 uniform resource identifier

This document specifies the prospero Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

 draft-hoffman-prospero-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4157 10.17487/RFC4157 RFC4158 Internet X.509 Public Key Infrastructure: Certification Path Building M. Cooper Y. Dzambasow P. Hesse S. Joseph R. Nicholas September 2005 ASCII 199297 81 certification path discovery path discovery certificate path building certificate path discovery

This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments. This memo provides information for the Internet community.

 draft-ietf-pkix-certpathbuild-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4158 RFC4159 Deprecation of "ip6.int" G. Huston August 2005 ASCII 5353 3 ipv6 dns domain name system

This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-huston-ip6-int-03 BCP0109 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4159 RFC4160 Internet Fax Gateway Requirements K. Mimura K. Yokoyama T. Satoh C. Kanaide C. Allocchio August 2005 ASCII 24930 13 general switched telephone network facsimile service gstn fax internet fax service i-fax onramp gateway

To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. This memo provides information for the Internet community.

 draft-ietf-fax-gateway-protocol-13 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4160 RFC4161 Guidelines for Optional Services for Internet Fax Gateways K. Mimura K. Yokoyama T. Satoh K. Watanabe C. Kanaide August 2005 ASCII 23189 12 general switched telephone network acsimile service gstn fax internet fax service i-fax offramp gateway onramp gateway

To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.

This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. This memo provides information for the Internet community.

 draft-ietf-fax-gateway-options-08 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4161 RFC4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS) H.J. Lee J.H. Yoon J.I. Lee August 2005 ASCII 10578 6 encryption algorithm ciphersuite

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

 draft-lee-tls-seed-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4162 RFC4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression L-E. Jonsson August 2005 ASCII 20587 9 transmission control protocol internet protocol compression performance considerations intellectual property rights ipr

This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC. This memo provides information for the Internet community.

 draft-ietf-rohc-tcp-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4163 RFC4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles G. Pelletier August 2005 ASCII 47088 21 context initialization short-lived

This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows. [STANDARDS-TRACK]

 draft-ietf-rohc-context-replication-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4164 RFC4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA) T. George B. Bidulock R. Dantu H. Schwarzbauer K. Morneault September 2005 ASCII 114669 53 ss7 over ip ss7/ip sigtran m2ua

This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. [STANDARDS-TRACK]

 draft-ietf-sigtran-m2pa-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4165 10.17487/RFC4165 RFC4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement L. Coene J. Pastor-Balbas February 2006 ASCII 46659 23

This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given. This memo provides information for the Internet community.

 draft-ietf-sigtran-signalling-over-sctp-applic-09 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC4166 RFC4167 Graceful OSPF Restart Implementation Report A. Lindem October 2005 ASCII 11780 6 open shortest path first

Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. This memo provides information for the Internet community.

 draft-ietf-ospf-graceful-impl-report-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4167 RFC4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne G. Camarillo October 2005 ASCII 21079 10 transport mechanism

This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]

 draft-ietf-sip-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4168 RFC4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2 V. Torvinen J. Arkko M. Naslund November 2005 ASCII 26429 13 tls transport layer security tunneled authentication man-in-the-middle attacks

HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. This memo provides information for the Internet community.

 draft-torvinen-http-digest-aka-v2-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4169 RFC4170 Tunneling Multiplexed Compressed RTP (TCRTP) B. Thompson T. Koren D. Wing November 2005 ASCII 48990 24 real-time transport protocol

This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-avt-tcrtp-08 BCP0110 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC4170 RFC4171 Internet Storage Name Service (iSNS) J. Tseng K. Gibbons F. Travostino C. Du Laney J. Souza September 2005 ASCII 310636 123 isns servers isns clients fibre channel devices ifcp intelligent storage discovery

This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. [STANDARDS-TRACK]

 draft-ietf-ips-isns-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4171 10.17487/RFC4171 RFC4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking C. Monia R. Mullendore F. Travostino W. Jeong M. Edwards September 2005 ASCII 241908 111 gateway-to-gateway fibre channel fabric tcp transport control protocol

This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. [STANDARDS-TRACK]

 draft-ietf-ips-ifcp-14 RFC6172 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4172 RFC4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol P. Sarkar D. Missimer C. Sapuntzakis September 2005 ASCII 27105 12 scsi tcp transport control protocol boot server

Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-boot-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4173 10.17487/RFC4173 RFC4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service C. Monia J. Tseng K. Gibbons September 2005 ASCII 29485 13 isns internet storage name service iscsi internet scsi ifcp internet fibre channel storage devices

This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network. [STANDARDS-TRACK]

 draft-ietf-dhc-isnsoption-13 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4174 RFC4175 RTP Payload Format for Uncompressed Video L. Gharai C. Perkins September 2005 ASCII 39431 18 packetization scheme real-time transport protocol real time transport protocol smpte society of motion picture television engineers video formats

This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. [STANDARDS-TRACK]

 draft-ietf-avt-uncomp-video-06 RFC4421 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4175 10.17487/RFC4175 RFC4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management Y. El Mghazli Editor T. Nadeau M. Boucadair K. Chan A. Gonguet October 2005 ASCII 46348 21

This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.

 draft-ietf-l3vpn-mgt-fwk-08 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4176 RFC4177 Architectural Approaches to Multi-homing for IPv6 G. Huston September 2005 ASCII 95374 36 internet protocol

This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. This memo provides information for the Internet community.

 draft-ietf-multi6-architecture-04 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4177 RFC4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism L. Zhu P. Leach K. Jaganathan W. Ingersoll October 2005 ASCII 46485 22 generic service application security program interface

This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.

This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet. [STANDARDS-TRACK]

 draft-ietf-kitten-2478bis-05 RFC2478 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4178 RFC4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN) S. Kang October 2005 ASCII 12935 7 nca national computerization agency digital resources

This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA. This memo provides information for the Internet community.

 draft-sangug-uci-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4179 RFC4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files Y. Shafranovich October 2005 ASCII 12931 8 text/csv

This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community.

 draft-shafranovich-mime-csv-05 RFC7111 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4180 RFC4181 Guidelines for Authors and Reviewers of MIB Documents C. Heard Editor September 2005 ASCII 102521 42 standards-track specifications management information base review

This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ops-mib-review-guidelines-04 RFC4841 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4181 10.17487/RFC4181 RFC4182 Removing a Restriction on the use of MPLS Explicit NULL E. Rosen September 2005 ASCII 14087 7 multiprotocol label switching ipv4 explicit null

The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.

This document updates RFC 3032. [STANDARDS-TRACK]

 draft-ietf-mpls-explicit-null-02 RFC3032 RFC5462 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4182 10.17487/RFC4182 RFC4183 A Suggested Scheme for DNS Resolution of Networks and Gateways E. Warnicke September 2005 ASCII 18357 9 domain name space ip address internet protocol address netmask first-hop router subnet

This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. This memo provides information for the Internet community.

 draft-warnicke-network-dns-resolution-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4183 RFC4184 RTP Payload Format for AC-3 Audio B. Link T. Hager J. Flaks October 2005 ASCII 25202 13 real time transport protocol audio compression

This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-ac3-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4184 RFC4185 National and Local Characters for DNS Top Level Domain (TLD) Names J. Klensin October 2005 ASCII 50926 19 domain name system multilingual internationalized local translation

In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about "multilingual" or "internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country. This memo provides information for the Internet community.

 draft-klensin-idn-tld-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4185 RFC4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) H. Haverinen Editor J. Salowey Editor January 2006 ASCII 220807 92 3gpp

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.

 draft-haverinen-pppext-eap-sim-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4186 10.17487/RFC4186 RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) J. Arkko H. Haverinen January 2006 ASCII 194958 79 3gpp universal mobile telecommunications system umts

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.

 draft-arkko-pppext-eap-aka-15 RFC5448 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4187 10.17487/RFC4187 RFC4188 Definitions of Managed Objects for Bridges K. Norseth Editor E. Bell Editor September 2005 ASCII 86877 44 BRIDGE-MIB SNMP MIB standard standards 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 MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.

This memo obsoletes RFC 1493. [STANDARDS-TRACK]

 draft-ietf-bridge-bridgemib-smiv2-10 RFC1493 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4188 10.17487/RFC4188 RFC4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) K. Ono S. Tachimoto October 2005 ASCII 25842 12 user agent ua intermediaries

A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. This memo provides information for the Internet community.

 draft-ietf-sipping-e2m-sec-reqs-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4189 RFC4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony K. Carlberg I. Brown C. Beard November 2005 ASCII 69447 28 disaster communications prioritized voip

This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. This memo provides information for the Internet community.

 draft-ietf-ieprep-framework-10 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4190 RFC4191 Default Router Preferences and More-Specific Routes R. Draves D. Thaler November 2005 ASCII 34672 15 router advertisement

This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]

 draft-ietf-ipv6-router-selection-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4191 10.17487/RFC4191 RFC4192 Procedures for Renumbering an IPv6 Network without a Flag Day F. Baker E. Lear R. Droms September 2005 ASCII 52110 22 prefix internet protocol network interface make-before-break enterprise connecting routers

This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community.

 draft-ietf-v6ops-renumbering-procedure-05 RFC2072 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4192 RFC4193 Unique Local IPv6 Unicast Addresses R. Hinden B. Haberman October 2005 ASCII 35908 16 internet protocol local communication

This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]

 draft-ietf-ipv6-unique-local-addr-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4193 RFC4194 The S Hexdump Format J. Strombergson L. Walleij P. Faltstrom October 2005 ASCII 25727 13 shf standard hex format secure hash standard shs sha-1 nist fips 180-2 binary data dump format hexadecimal intel hex format s-rec extensible markup language xml

This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]

 draft-strombergson-shf-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4194 RFC4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum W. Kameyama October 2005 ASCII 10066 6 digital broadcasting tv radio storage systems metadata schemas

This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. This memo provides information for the Internet community.

 draft-kameyama-tv-anytime-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4195 RFC4196 The SEED Cipher Algorithm and Its Use with IPsec H.J. Lee J.H. Yoon S.L. Lee J.I. Lee October 2005 ASCII 22587 12 ipsec esp encryption algorithm

This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 draft-lee-ipsec-cipher-seed-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4196 RFC4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks M. Riegel Editor October 2005 ASCII 47937 24 digital signatures plesiochronous digital hierarchy sonet synchronous optical network sdh synchronous digital hierarchy pwe3 pseudo wire emulation

This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. This memo provides information for the Internet community.

 draft-ietf-pwe3-tdm-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4197 10.17487/RFC4197 RFC4198 A Uniform Resource Name (URN) Namespace for Federated Content D. Tessman November 2005 ASCII 12134 7 content resource content collections

This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections. A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. This memo provides information for the Internet community.

 draft-dtessman-urn-namespace-federated-content-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4198 RFC4201 Link Bundling in MPLS Traffic Engineering (TE) K. Kompella Y. Rekhter L. Berger October 2005 ASCII 27033 12 multiprotocol label switching generalized multiprotocol label switching gmpls lsp label switched path interface identification tlvs

For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]

 draft-ietf-mpls-bundle-06 RFC3471 RFC3472 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4201 RFC4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII 57333 27 open shortest path first

This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-routing-09 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4202 RFC4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII 23130 11 open shortest path first

This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

 draft-ietf-ccamp-ospf-gmpls-extensions-12 RFC3630 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4203 RFC4204 Link Management Protocol (LMP) J. Lang Editor October 2005 ASCII 186515 86 gmpls sonet sdh discovery link verification fault managment control channel management link property correlation traffic engineering links trace monitoring

For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-10 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4204 10.17487/RFC4204 RFC4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII 22323 11

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This memo provides information for the Internet community.

 draft-ietf-isis-gmpls-extensions-19 RFC5307 RFC3784 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC4205 RFC4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) K. Kompella Y. Rekhter October 2005 ASCII 31965 14 lsr label switching router te lsp fa forwarding adjacency

To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).

This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]

 draft-ietf-mpls-lsp-hierarchy-08 RFC6001 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4206 RFC4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages J. Lang D. Papadimitriou October 2005 ASCII 29390 15 gmpls discovery link verification fault management control channel management link property correlation traffic engineering links trace monitoring

This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-test-sonet-sdh-04 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4207 10.17487/RFC4207 RFC4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model G. Swallow J. Drake H. Ishimatsu Y. Rekhter October 2005 ASCII 28693 13 lsp label switched paths routing protocol signaling protocol

Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-overlay-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4208 RFC4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems A. Fredette Editor J. Lang Editor October 2005 ASCII 33906 16 te traffic engineering peer nodes ols optical link interface requirements

The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-wdm-03 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4209 RFC4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) C. Adams S. Farrell T. Kause T. Mononen September 2005 ASCII 212013 95 PKICMP cryptographic authentication pkix pki X.509v3 certificate creation certificate management ca certification authority

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc2510bis-09 RFC2510 RFC6712 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4210 10.17487/RFC4210 RFC4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) J. Schaad September 2005 ASCII 86136 40 X.509-CRMF certification authority ca registration authority ra pkix pki certificate production crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc2511bis-08 RFC2511 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4211 10.17487/RFC4211 RFC4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols M. Blinov C. Adams October 2005 ASCII 41757 19 X.509v3 public-key certificates crmf certificate request message format pkix certificate management protocol pkix-cmp certificate management messages over cms cmc

The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC). This memo provides information for the Internet community.

 draft-adams-cmpaltcert-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4212 RFC4213 Basic Transition Mechanisms for IPv6 Hosts and Routers E. Nordmark R. Gilligan October 2005 ASCII 58575 27 TRANS-IPV6 ipv4 dual sack configured tunneling

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.

This document obsoletes RFC 2893. [STANDARDS-TRACK]

 draft-ietf-v6ops-mech-v2-07 RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4213 10.17487/RFC4213 RFC4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson M. Talwar D. Thaler October 2005 ASCII 27811 14 ISATAP] ipv4 link layer nbma non-broadcast multiple access

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ngtrans-isatap-22 RFC5214 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4214 RFC4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks J. Wiljakka Editor October 2005 ASCII 52903 24 internet protocol gprs general packet radio service global system for mobile communications gsm universal mobile telecommunications system umts wideband code division multiple access wcdma

This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.

The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. This memo provides information for the Internet community.

 draft-ietf-v6ops-3gpp-analysis-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4215 RFC4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements R. Zhang Editor J.-P. Vasseur Editor November 2005 ASCII 64640 29 inter-as mpls-te

This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. This memo provides information for the Internet community.

 draft-ietf-tewg-interas-mpls-te-req-09 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4216 RFC4217 Securing FTP with TLS P. Ford-Hutchinson October 2005 ASCII 61180 29 security authentication file transfer protocol transport layer security

This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".

This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". [STANDARDS-TRACK]

 draft-murray-auth-ftp-ssl-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4217 10.17487/RFC4217 RFC4218 Threats Relating to IPv6 Multihoming Solutions E. Nordmark T. Li October 2005 ASCII 75969 31 security threats internet protocol version 6

This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.

The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. This memo provides information for the Internet community.

 draft-ietf-multi6-multihoming-threats-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4218 RFC4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About E. Lear October 2005 ASCII 25141 12 security threats internet protocol version 6

This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. This memo provides information for the Internet community.

 draft-ietf-multi6-things-to-think-about-01 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4219 RFC4220 Traffic Engineering Link Management Information Base M. Dubuc T. Nadeau J. Lang November 2005 ASCII 104566 54 mib network management protocols te te-link-std-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]

 draft-ietf-mpls-telink-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4220 RFC4221 Multiprotocol Label Switching (MPLS) Management Overview T. Nadeau C. Srinivasan A. Farrel November 2005 ASCII 70291 32 mib management information base management architecture network management

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.

This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. This memo provides information for the Internet community.

 draft-ietf-mpls-mgmt-overview-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4221 RFC4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance G. Choudhury Editor October 2005 ASCII 34132 15 open shortest path first lsa link state advertisement

This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ospf-scalability-09 BCP0112 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf 10.17487/RFC4222 RFC4223 Reclassification of RFC 1863 to Historic P. Savola October 2005 ASCII 5123 3 BGP-IDRP border gateway protocol inter-domain routing

This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletes RFC 1863. This memo provides information for the Internet community.

 draft-ietf-idr-rfc1863-historic-00 RFC1863 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4223 RFC4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets G. Pelletier L-E. Jonsson K. Sandlund January 2006 ASCII 49416 21

RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. This memo provides information for the Internet community.

 draft-ietf-rohc-over-reordering-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4224 RFC4225 Mobile IP Version 6 Route Optimization Security Design Background P. Nikander J. Arkko T. Aura G. Montenegro E. Nordmark December 2005 ASCII 98584 37 mipv6 mip

This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.

The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. This memo provides information for the Internet community.

 draft-ietf-mip6-ro-sec-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4225 RFC4226 HOTP: An HMAC-Based One-Time Password Algorithm D. M'Raihi M. Bellare F. Hoornaert D. Naccache O. Ranen December 2005 ASCII 77117 37 hashed message authentication code security analysis oath open authentication authentication OATH

This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.

This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community.

 draft-mraihi-oath-hmac-otp-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4226 10.17487/RFC4226 RFC4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose January 2006 ASCII 39112 21 xml extensible markup language remote procedure calling rpc asynchronous event notification unacknowledged messages binding

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.

The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. [STANDARDS-TRACK]

 draft-mrose-rfc3288bis-02 RFC3288 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4227 10.17487/RFC4227 RFC4228 Requirements for an IETF Draft Submission Toolset A. Rousskov December 2005 ASCII 76952 31 automation tool

This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community.

 draft-ietf-tools-draft-submission-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4228 RFC4229 HTTP Header Field Registrations M. Nottingham J. Mogul December 2005 ASCII 70879 53 hyper text transfer protocol

This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. This memo provides information for the Internet community.

 draft-nottingham-hdrreg-http-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4229 10.17487/RFC4229 RFC4230 RSVP Security Properties H. Tschofenig R. Graveman December 2005 ASCII 121030 48 resource reservation protocol

This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This memo provides information for the Internet community.

 draft-ietf-nsis-rsvp-sec-properties-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=4230 10.17487/RFC4230 RFC4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 M. Nystrom December 2005 ASCII 17725 9 message authentication codes message authentication schemes

This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]

 draft-nystrom-smime-hmac-sha-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4231 10.17487/RFC4231 RFC4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom January 2006 ASCII 157857 73 stream control transmission protocol sctp signaling gateway sg media gateway controller mgc signaling media gateway interface

This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.

This document obsoletes RFC 3057. [STANDARDS-TRACK]

 draft-ietf-sigtran-rfc3057bis-02 RFC3057 RFC5133 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4233 RFC4234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell October 2005 ASCII 26351 16 ABNF] backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer electronic mail

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

 draft-crocker-abnf-rfc2234bis-00 RFC2234 RFC5234 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4234 10.17487/RFC4234 RFC4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne R. Mahy Editor November 2005 ASCII 83268 39 sip events dialog package

This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]

 draft-ietf-sipping-dialog-package-06 RFC7463 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4235 10.17487/RFC4235 RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES) A. Rousskov M. Stecher November 2005 ASCII 53512 27 callout protocol ocp opes tracing opes bypass

Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]

 draft-ietf-opes-http-03 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4236 RFC4237 Voice Messaging Directory Service G. Vaudreuil October 2005 ASCII 26093 13 vpim voice profile for internet mail

This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.

The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. [STANDARDS-TRACK]

 draft-ietf-vpim-vpimdir-11 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4237 10.17487/RFC4237 RFC4238 Voice Message Routing Service G. Vaudreuil October 2005 ASCII 18902 10 vpim telephone number addressing voice profile and intenret mail vpim directory

Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]

 draft-ietf-vpim-routing-10 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4238 10.17487/RFC4238 RFC4239 Internet Voice Messaging (IVM) S. McRae G. Parsons November 2005 ASCII 24867 11 voicemail vpim voice profile for internet mail

This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.

The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application. [STANDARDS-TRACK]

 draft-ietf-vpim-ivm-06 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC4239 RFC4240 Basic Network Media Services with SIP E. Burger Editor J. Van Dyke A. Spitzer December 2005 ASCII 54976 24 session initiation protocol network media services media servers application servers

In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.

This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.

 draft-burger-sipping-netann-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4240 10.17487/RFC4240 RFC4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service Y. Shirasaki S. Miyakawa T. Yamasaki A. Takenouchi December 2005 ASCII 20580 10 user network specification ntt communications adsl cpe customer preises equipment

This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo provides information for the Internet community.

 draft-shirasaki-dualstack-service-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4241 10.17487/RFC4241 RFC4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) S. Venaas T. Chown B. Volz November 2005 ASCII 14759 8 internet protocol

This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]

 draft-ietf-dhc-lifetime-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4242 RFC4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp R. Johnson T. Palaniappan December 2005 ASCII 14342 7

This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]

 draft-ietf-dhc-vendor-suboption-00 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4243 RFC4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes Editor November 2005 ASCII 98992 44 history-info retarget enhanced services voicemail automatic call distribution

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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. [STANDARDS-TRACK]

 draft-ietf-sip-history-info-06 RFC7044 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4244 10.17487/RFC4244 RFC4245 High-Level Requirements for Tightly Coupled SIP Conferencing O. Levin R. Even November 2005 ASCII 24415 12 session initiation protocol

This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. This memo provides information for the Internet community.

 draft-ietf-sipping-conferencing-requirements-01 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4245 RFC4246 International Standard Audiovisual Number (ISAN) URN Definition M. Dolan February 2006 ASCII 10312 6 numbering system international identification audiovisual uniform resource identifier

The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for ISAN. This memo provides information for the Internet community.

 draft-dolan-urn-isan-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4246 RFC4247 Requirements for Header Compression over MPLS J. Ash B. Goode J. Hand R. Zhang November 2005 ASCII 25127 11 multiprotocol label switching voip voice over ip

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario. This memo provides information for the Internet community.

 draft-ietf-avt-hc-mpls-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4247 RFC4248 The telnet URI Scheme P. Hoffman October 2005 ASCII 7292 4 uniform resource identifier url uniform resource locators

This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

 draft-hoffman-telnet-uri-05 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4248 RFC4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components B. Lilly January 2006 ASCII 28731 14 header field generator header field parser

Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers. This memo provides information for the Internet community.

 draft-lilly-field-specification-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4249 RFC4250 The Secure Shell (SSH) Protocol Assigned Numbers S. Lehtinen C. Lonvick Editor January 2006 ASCII 44010 20 remote login

This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK]

 draft-ietf-secsh-assignednumbers-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4250 RFC4251 The Secure Shell (SSH) Protocol Architecture T. Ylonen C. Lonvick Editor January 2006 ASCII 71750 30 remote login ssh algorithm

The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK]

 draft-ietf-secsh-architecture-22 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4251 RFC4252 The Secure Shell (SSH) Authentication Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII 34268 17 remote login public key password host-based client authentication

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]

 draft-ietf-secsh-userauth-27 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4252 10.17487/RFC4252 RFC4253 The Secure Shell (SSH) Transport Layer Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII 68263 32 remote login encryption server authentication integrity protection diffie-hellman key exchange diffie hellman

The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.

This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]

 draft-ietf-secsh-transport-24 RFC6668 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4253 10.17487/RFC4253 RFC4254 The Secure Shell (SSH) Connection Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII 50338 24 remote login interactive login remote execution encrypted tunnel

Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.

The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK]

 draft-ietf-secsh-connect-25 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4254 10.17487/RFC4254 RFC4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints J. Schlyter W. Griffin January 2006 ASCII 18399 9 domain name system dnssec domain name system security

This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK]

 draft-ietf-secsh-dns-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4255 10.17487/RFC4255 RFC4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) F. Cusack M. Forssen January 2006 ASCII 24728 12 remote login alphanumeric input

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). [STANDARDS-TRACK]

 draft-ietf-secsh-auth-kbdinteract-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4256 10.17487/RFC4256 RFC4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks G. Bernstein E. Mannie V. Sharma E. Gray December 2005 ASCII 86974 35 mpls optical switching sdh sonet

Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. This memo provides information for the Internet community.

 draft-ietf-ccamp-sdhsonet-control-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4257 RFC4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) D. Brungard Editor November 2005 ASCII 48558 22 control domain hierarchy multi-level multi-layer inter-domain intra-domain e-nni i-nni uni

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-routing-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4258 RFC4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks M.-J. Montpetit G. Fairhurst H. Clausen B. Collini-Nocker H. Linder November 2005 ASCII 100423 42 digital television dvb digital video broadcast atsc advanced television systems committee

This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.

The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. This memo provides information for the Internet community.

 draft-ietf-ipdvb-arch-04 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4259 RFC4260 Mobile IPv6 Fast Handovers for 802.11 Networks P. McCann November 2005 ASCII 35276 15 link layer

This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. This memo provides information for the Internet community.

 draft-ietf-mipshop-80211fh-04 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC4260 RFC4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS) J. Walker A. Kulkarni Editor December 2005 ASCII 28662 14 client-accept message

This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.

This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]

 draft-ietf-rap-cops-tls-11 RFC2748 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC4261 RFC4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities S. Santesson December 2005 ASCII 9801 5 cryptographic capabilities

This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK]

 draft-ietf-smime-certcapa-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC4262 RFC4263 Media Subtype Registration for Media Type text/troff B. Lilly January 2006 ASCII 33371 16

A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described. This memo provides information for the Internet community.

 draft-lilly-text-troff-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4263 RFC4264 BGP Wedgies T. Griffin G. Huston November 2005 ASCII 24139 10 border gateway protocol

It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". This memo provides information for the Internet community.

 draft-ietf-grow-bgp-wedgies-03 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4264 RFC4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management B. Schliesser T. Nadeau November 2005 ASCII 10976 6 tc

This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). [STANDARDS-TRACK]

 draft-ietf-l3vpn-tc-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn 10.17487/RFC4265 RFC4266 The gopher URI Scheme P. Hoffman November 2005 ASCII 12083 6 uniform resource identifier url

This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

 draft-hoffman-gopher-uri-03 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4266 RFC4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml M. Froumentin November 2005 ASCII 17753 9 voice browser voice extensible markup language voicexml speech synthesis markup language ssml speech recognition grammar specification srgs call control xml ccxml pronunciation lexicon specification pls

This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language (VoiceXML), the Speech Synthesis Markup Language (SSML), the Speech Recognition Grammar Specification (SRGS), the Call Control XML (CCXML), and the Pronunciation Lexicon Specification (PLS). This memo provides information for the Internet community.

 draft-froumentin-voice-mediatypes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4267 RFC4268 Entity State MIB S. Chisholm D. Perkins November 2005 ASCII 40348 19 management information base snmp entity-state-tc-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 extensions to the Entity MIB to provide information about the state of physical entities.

In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-entmib-state-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4268 10.17487/RFC4268 RFC4269 The SEED Encryption Algorithm H.J. Lee S.J. Lee J.H. Yoon D.H. Cheon J.I. Lee December 2005 ASCII 34390 16 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).

This document obsoletes RFC 4009. This memo provides information for the Internet community.

 draft-lee-rfc4009bis-02 RFC4009 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4269 RFC4270 Attacks on Cryptographic Hashes in Internet Protocols P. Hoffman B. Schneier November 2005 ASCII 26641 12 collision attacks hash algorithms ip digital certificates

Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. This memo provides information for the Internet community.

 draft-hoffman-hash-attacks-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4270 10.17487/RFC4270 RFC4271 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter Editor T. Li Editor S. Hares Editor January 2006 ASCII 222702 104 BGP-4 routing

This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.

This document obsoletes RFC 1771. [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-26 RFC1771 RFC6286 RFC6608 RFC6793 RFC7606 RFC7607 RFC7705 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4271 10.17487/RFC4271 RFC4272 BGP Security Vulnerabilities Analysis S. Murphy January 2006 ASCII 53119 22 border gateway protocol attacks risks insider threat

Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.

This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-vuln-01 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4272 RFC4273 Definitions of Managed Objects for BGP-4 J. Haas Editor S. Hares Editor January 2006 ASCII 65629 32 BGP-4-MIB management information base mib border gateway 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 describes managed objects used for managing the Border Gateway Protocol Version 4 or lower.

The origin of this memo is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.

This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions.

This document obsoletes RFC 1269 and RFC 1657. [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-mib-15 RFC1269 RFC1657 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4273 10.17487/RFC4273 RFC4274 BGP-4 Protocol Analysis D. Meyer K. Patel January 2006 ASCII 38200 16 border gateway protocol

The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4274 10.17487/RFC4274 RFC4275 BGP-4 MIB Implementation Survey S. Hares D. Hares January 2006 ASCII 77598 37 border gateway protocol management information base

This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-mibagent-survey-02 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4275 10.17487/RFC4275 RFC4276 BGP-4 Implementation Report S. Hares A. Retana January 2006 ASCII 132864 97 border gateway protocol

This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).

The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-implementation-02 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4276 RFC4277 Experience with the BGP-4 Protocol D. McPherson K. Patel January 2006 ASCII 45117 19 border gateway protocol

The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.

 draft-ietf-idr-bgp4-experience-protocol-05 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4277 10.17487/RFC4277 RFC4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification S. Bellovin A. Zinin January 2006 ASCII 14483 7 border gateway protocol

The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. This memo provides information for the Internet community.

 draft-iesg-tcpmd5app-01 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC4278 RFC4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) P. Eronen Editor H. Tschofenig Editor December 2005 ASCII 32160 15 psk psks symmetric keys diffie-hellman

This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]

 draft-ietf-tls-psk-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4279 RFC4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers K. Chowdhury P. Yegani L. Madour November 2005 ASCII 23001 11 bcmcs 3g third generation cellular telephone mobile node mn

This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. [STANDARDS-TRACK]

 draft-ietf-dhc-bcmc-options-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4280 10.17487/RFC4280 RFC4281 The Codecs Parameter for "Bucket" Media Types R. Gellens D. Singer P. Frojdh November 2005 ASCII 25529 29 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered.

This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS-TRACK]

 draft-gellens-mime-bucket-04 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4281 10.17487/RFC4281 RFC4282 The Network Access Identifier B. Aboba M. Beadles J. Arkko P. Eronen December 2005 ASCII 34421 16 NAI nai roaming tunneling

In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]

 draft-ietf-radext-rfc2486bis-06 RFC2486 RFC7542 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4282 10.17487/RFC4282 RFC4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6) A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury November 2005 ASCII 14653 8 mobility header mobile nodes correspondent nodes home agents

Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS-TRACK]

 draft-ietf-mip6-mn-ident-option-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4283 10.17487/RFC4283 RFC4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP) F. Adrangi V. Lortz F. Bari P. Eronen January 2006 ASCII 30322 14 nai network access identifier

The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.

The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This memo provides information for the Internet community.

 draft-adrangi-eap-network-discovery-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4284 RFC4285 Authentication Protocol for Mobile IPv6 A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury January 2006 ASCII 40874 19 ip security ipsec mip6 mobile node home agent

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. This memo provides information for the Internet community.

 draft-ietf-mip6-auth-protocol-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4285 10.17487/RFC4285 RFC4286 Multicast Router Discovery B. Haberman J. Martin December 2005 ASCII 35540 18 igmp internet group management protocol mld multicast listener discovery mrd

The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.

This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS-TRACK]

 draft-ietf-magma-mrdisc-07 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4286 10.17487/RFC4286 RFC4287 The Atom Syndication Format M. Nottingham Editor R. Sayre Editor December 2005 ASCII 81922 43 xml-basd web content metadata

This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]

 draft-ietf-atompub-format-11 RFC5988 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub 10.17487/RFC4287 RFC4288 Media Type Specifications and Registration Procedures N. Freed J. Klensin December 2005 ASCII 52667 24 mime multipurpose internet mail extensions media types

This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-freed-media-type-reg-05 RFC2048 RFC6838 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4288 10.17487/RFC4288 RFC4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin December 2005 ASCII 21502 11 media types external body access content-transfer-encodings

This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-freed-mime-p4-07 RFC2048 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4289 RFC4290 Suggested Practices for Registration of Internationalized Domain Names (IDN) J. Klensin December 2005 ASCII 71115 28 chinese domain names japanese domain names korean domain names

This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community.

 draft-klensin-reg-guidelines-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4290 RFC4291 IP Version 6 Addressing Architecture R. Hinden S. Deering February 2006 ASCII 52897 25 internet protocol version 6 unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.

This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]

 draft-ietf-ipv6-addr-arch-v4-04 RFC3513 RFC5952 RFC6052 RFC7136 RFC7346 RFC7371 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4291 10.17487/RFC4291 RFC4292 IP Forwarding Table MIB B. Haberman April 2006 ASCII 69321 34 TABLE-MIB Management Information Base Internet 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 managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. This document obsoletes RFC 2096. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2096-update-07 RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4292 RFC4293 Management Information Base for the Internet Protocol (IP) S. Routhier Editor April 2006 ASCII 242243 122 MIB-IP IP Simple Network Management Protocol MIB ipv6 ICMPv6-MIB| mib internet protocol ip mib ipv4 mib ipv6 mib icmp mib icmpv6 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 used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2011-update-10 RFC2011 RFC2465 RFC2466 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4293 10.17487/RFC4293 RFC4294 IPv6 Node Requirements J. Loughney Editor April 2006 ASCII 39125 20 internet protocol version 6

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This memo provides information for the Internet community.

 draft-ietf-ipv6-node-requirements-11 RFC6434 RFC5095 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4294 10.17487/RFC4294 RFC4295 Mobile IPv6 Management Information Base G. Keeni K. Koide K. Nagami S. Gundavelli April 2006 ASCII 209038 109 mib mipv6

This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS-TRACK]

 draft-ietf-mip6-mipv6-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4295 10.17487/RFC4295 RFC4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols S. Bailey T. Talpey December 2005 ASCII 43907 22 rddp warp

This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. This memo provides information for the Internet community.

 draft-ietf-rddp-arch-07 INFORMATIONAL INFORMATIONAL IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=4296 10.17487/RFC4296 RFC4297 Remote Direct Memory Access (RDMA) over IP Problem Statement A. Romanow J. Mogul T. Talpey S. Bailey December 2005 ASCII 48514 20 overhead copy avoidance

Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.

This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.

 draft-ietf-rddp-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC4297 RFC4298 RTP Payload Format for BroadVoice Speech Codecs J.-H. Chen W. Lee J. Thyssen December 2005 ASCII 30099 14 real time transport narroband wideband bv16 broadvoice16 sdp session description protocol

This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-rtp-bv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4298 RFC4301 Security Architecture for the Internet Protocol S. Kent K. Seo December 2005 ASCII 262123 101 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer ip authentication header ip security IPsec confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]

 draft-ietf-ipsec-rfc2401bis-06 RFC2401 RFC3168 RFC6040 RFC7619 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4301 10.17487/RFC4301 RFC4302 IP Authentication Header S. Kent December 2005 ASCII 82328 34 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6 ip security confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]

 draft-ietf-ipsec-rfc2402bis-10 RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4302 10.17487/RFC4302 RFC4303 IP Encapsulating Security Payload (ESP) S. Kent December 2005 ASCII 114315 44 ESP ipsec internet protocol encapsulating security ipv4 ipv6 ip security confidentiality authentication integrity anti-replay ah ip authentication header ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]

 draft-ietf-ipsec-esp-v3-10 RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4303 10.17487/RFC4303 RFC4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) S. Kent December 2005 ASCII 9243 5 ipsecurity anti-replay ah ip authentication header esp encapsulating security payload ike internet key exchange ikev2

The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64-bit) sequence numbers (ESNs) for a particular AH or ESP security association. [STANDARDS-TRACK]

 draft-ietf-ipsec-esn-addendum-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC4304 RFC4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. Eastlake 3rd December 2005 ASCII 17991 9 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

 draft-ietf-ipsec-esp-ah-algorithms-02 RFC2402 RFC2406 RFC4835 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4305 10.17487/RFC4305 RFC4306 Internet Key Exchange (IKEv2) Protocol C. Kaufman Editor December 2005 ASCII 250941 99 ISAKMPSEC ipsec internet protocol security association key management ipsec cryptography authentication IKE oakley isakmp

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).

This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.

Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS-TRACK]

 draft-ietf-ipsec-ikev2-17 RFC2407 RFC2408 RFC2409 RFC5996 RFC5282 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4306 10.17487/RFC4306 RFC4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) J. Schiller December 2005 ASCII 12985 6 ipsec ike internet key exchange

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

 draft-ietf-ipsec-ikev2-algorithms-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4307 10.17487/RFC4307 RFC4308 Cryptographic Suites for IPsec P. Hoffman December 2005 ASCII 13127 7 ike internet key exchange ikev2 security algorithms ikev1

The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. [STANDARDS-TRACK]

 draft-ietf-ipsec-ui-suites-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4308 10.17487/RFC4308 RFC4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) R. Housley December 2005 ASCII 28998 13 cbc-mac mode initialization vector iv confidentiality data origin authentication connectionless integrity

This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

 draft-ietf-ipsec-ciph-aes-ccm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4309 10.17487/RFC4309 RFC4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck December 2005 ASCII 46326 22 dnssec domain name system security extensions

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. [STANDARDS-TRACK]

 draft-hollenbeck-epp-secdns-08 RFC5910 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4310 RFC4311 IPv6 Host-to-Router Load Sharing R. Hinden D. Thaler November 2005 ASCII 10156 5 internet protocol version 6 conceptual sending algorithm

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]

 draft-ietf-ipv6-host-load-sharing-04 RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4311 RFC4312 The Camellia Cipher Algorithm and Its Use With IPsec A. Kato S. Moriai M. Kanda December 2005 ASCII 15980 8 cipher block chaining mode initialization vector iv esp encapsulating security payload ip security

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit Initialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 draft-kato-ipsec-ciph-camellia-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4312 10.17487/RFC4312 RFC4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources D. Oran December 2005 ASCII 46875 20 speech processing audio streams si speaker identification sv speaker verification tts text to speech

This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. This memo provides information for the Internet community.

 draft-ietf-speechsc-reqts-07 INFORMATIONAL INFORMATIONAL IETF rai speechsc 10.17487/RFC4313 RFC4314 IMAP4 Access Control List (ACL) Extension A. Melnikov December 2005 ASCII 56599 27 IMAP4-ACL Control List interet message access protocol

The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]

 draft-ietf-imapext-2086upd-08 RFC2086 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4314 10.17487/RFC4314 RFC4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension M. Crispin December 2005 ASCII 16629 8 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK]

 draft-crispin-imap-rfc2359bis-04 RFC2359 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4315 RFC4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties J. Reschke December 2005 ASCII 20352 11 datatying propfind

This specification extends the Web Distributed Authoring and Versioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. This memo defines an Experimental Protocol for the Internet community.

 draft-reschke-webdav-property-datatypes-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4316 RFC4317 Session Description Protocol (SDP) Offer/Answer Examples A. Johnston R. Sparks December 2005 ASCII 32262 24

This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. This memo provides information for the Internet community.

 draft-ietf-mmusic-offer-answer-examples-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4317 RFC4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol D. Levi D. Harrington December 2005 ASCII 28124 14 management information base simple network management protocol transparent bridging rstp-mib

This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. [STANDARDS-TRACK]

 draft-ietf-bridge-rstpmib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC4318 RFC4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines C. Sikes B. Ray R. Abbi December 2005 ASCII 146995 75 mib management information base hdsl2-shdsl-line-mib interfaces

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276. [STANDARDS-TRACK]

 draft-ietf-adslmib-gshdslbis-11 RFC3276 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=4319 10.17487/RFC4319 RFC4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII 13853 7

This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261. [STANDARDS-TRACK]

 draft-sparks-sip-nit-actions-03 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4320 RFC4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII 22708 10

This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. This memo provides information for the Internet community.

 draft-sparks-sip-nit-problems-02 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4321 RFC4322 Opportunistic Encryption using the Internet Key Exchange (IKE) M. Richardson D.H. Redelmeier December 2005 ASCII 95453 44 oe linux frees/wan ipsec dns domain name space dns security

This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.

As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. This memo provides information for the Internet community.

 draft-richardson-ipsec-opportunistic-17 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4322 10.17487/RFC4322 RFC4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB) M. Patrick W. Murwin January 2006 ASCII 197285 89 snmp simple network management protocol cm cable modem cmts cable modem termination system docs-ietf-qos-mib

This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0. [STANDARDS-TRACK]

 draft-ietf-ipcdn-qos-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4323 RFC4324 Calendar Access Protocol (CAP) D. Royer G. Babics S. Mansour December 2005 ASCII 254638 131 calendar user cu calendar user agent cua ical calender store cs

The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-royer-calsch-cap-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4324 RFC4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension S. Santesson R. Housley December 2005 ASCII 14449 7 issuer certificate

This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. [STANDARDS-TRACK]

 draft-ietf-pkix-crlaia-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4325 RFC4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) G. Fairhurst B. Collini-Nocker December 2005 ASCII 95422 42

The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.

This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. [STANDARDS-TRACK]

 draft-ietf-ipdvb-ule-06 RFC7280 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=4326 10.17487/RFC4326 RFC4327 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis January 2006 ASCII 150509 82 lmp-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-mib-10 RFC4631 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4327 10.17487/RFC4327 RFC4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control D. Papadimitriou Editor January 2006 ASCII 52145 23 otn optical transport networks pre-otn

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-g709-09 RFC3471 RFC7139 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4328 RFC4329 Scripting Media Types B. Hoehrmann April 2006 ASCII 30230 15 JavaScript EMACScript mime script subtype

This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This memo provides information for the Internet community.

 draft-hoehrmann-script-types-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4329 RFC4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills January 2006 ASCII 67930 27 NTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.

This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP. This memo provides information for the Internet community.

 draft-mills-sntp-v4-01 RFC2030 RFC1769 RFC5905 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4330 10.17487/RFC4330 RFC4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections B. Korver L. Dusseault February 2006 ASCII 19706 10 webdav

Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. [STANDARDS-TRACK]

 draft-ietf-webdav-quota-07 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC4331 RFC4332 Cisco's Mobile IPv4 Host Configuration Extensions K. Leung A. Patel G. Tsirtsis E. Klovning December 2005 ASCII 19788 11 dynamic host configuration protocol dhcp point-to-point ip control protocol ppp ipcp

An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol/IP Control Protocol (PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages. This memo provides information for the Internet community.

 draft-leung-cisco-mip4-host-config-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4332 RFC4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process G. Huston Editor B. Wijnen Editor December 2005 ASCII 15396 9 iad iasa ietf administrative support activity ietf administrative director

This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-iesg-iaoc-selection-03 BCP0113 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4333 RFC4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore February 2006 ASCII 20739 11 eap extensible authentication protocol wireless lan wlan system service identifier ssid

This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc3770bis-03 RFC3770 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4334 10.17487/RFC4334 RFC4335 The Secure Shell (SSH) Session Channel Break Extension J. Galbraith P. Remaker January 2006 ASCII 11370 6

The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS-TRACK]

 draft-ietf-secsh-break-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4335 10.17487/RFC4335 RFC4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP) S. Floyd M. Handley E. Kohler March 2006 ASCII 53585 22

This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games. This memo provides information for the Internet community.

 draft-ietf-dccp-problem-03 INFORMATIONAL INFORMATIONAL IETF tsv dccp 10.17487/RFC4336 RFC4337 MIME Type Registration for MPEG-4 Y Lim D. Singer March 2006 ASCII 17290 11

This document defines the standard MIME types associated with MP4 files. It also recommends use of registered MIME types according to the type of contents. [STANDARDS-TRACK]

 draft-lim-mpeg4-mime-03 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4337 10.17487/RFC4337 RFC4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel C. DeSanti C. Carlson R. Nixon January 2006 ASCII 75541 33 link local address link-local address

This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.

This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]

 draft-ietf-imss-ip-over-fibre-channel-03 RFC3831 RFC2625 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4338 RFC4339 IPv6 Host Configuration of DNS Server Information Approaches J. Jeong Editor February 2006 ASCII 60803 26 domain name server internet protocol address configuration dhcpv6 dynamic host configuration protocol

This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution. This memo provides information for the Internet community.

 draft-ietf-dnsop-ipv6-dns-configuration-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4339 10.17487/RFC4339 RFC4340 Datagram Congestion Control Protocol (DCCP) E. Kohler M. Handley S. Floyd March 2006 ASCII 318830 129 transport protocol

The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]

 draft-ietf-dccp-spec-11 RFC5595 RFC5596 RFC6335 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4340 10.17487/RFC4340 RFC4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control S. Floyd E. Kohler March 2006 ASCII 47868 20 transport protocol amid additive increase multiplicative decrease

This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. [STANDARDS-TRACK]

 draft-ietf-dccp-ccid2-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC4341 RFC4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) S. Floyd E. Kohler J. Padhye March 2006 ASCII 83054 33 transport protocol ecn explicit congestion notification ccid3

This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. [STANDARDS-TRACK]

 draft-ietf-dccp-ccid3-11 RFC5348 RFC6323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4342 10.17487/RFC4342 RFC4343 Domain Name System (DNS) Case Insensitivity Clarification D. Eastlake 3rd January 2006 ASCII 22899 10

Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]

 draft-ietf-dnsext-insensitive-06 RFC1034 RFC1035 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4343 10.17487/RFC4343 RFC4344 The Secure Shell (SSH) Transport Layer Encryption Modes M. Bellare T. Kohno C. Namprempre January 2006 ASCII 27521 12 rekey

Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.

This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. [STANDARDS-TRACK]

 draft-ietf-secsh-newmodes-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4344 RFC4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol B. Harris January 2006 ASCII 8967 5 arcfour cipher key scheduling algorithm

This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm. [STANDARDS-TRACK]

 draft-harris-ssh-arcfour-fixes-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4345 10.17487/RFC4345 RFC4346 The Transport Layer Security (TLS) Protocol Version 1.1 T. Dierks E. Rescorla April 2006 ASCII 187041 87

This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

 draft-ietf-tls-rfc2246-bis-13 RFC2246 RFC5246 RFC4366 RFC4680 RFC4681 RFC5746 RFC6176 RFC7465 RFC7507 RFC7919 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4346 10.17487/RFC4346 RFC4347 Datagram Transport Layer Security E. Rescorla N. Modadugu April 2006 ASCII 56014 25 dtls

This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. [STANDARDS-TRACK]

 draft-rescorla-dtls-05 RFC6347 RFC5746 RFC7507 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4347 10.17487/RFC4347 RFC4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec S. Ahmadi January 2006 ASCII 73528 32 speech codec variable-rate multicode wideband speech codec

This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.

VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vmr-wb-11 RFC4424 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4348 RFC4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) C. Pignataro M. Townsley February 2006 ASCII 22888 11 pseudowire

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-hdlc-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4349 RFC4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government F. Hendrikx C. Wallis February 2006 ASCII 21111 11 nid namespace identification

This document describes a Uniform Resource Name (URN) Namespace Identification (NID)convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New Zealand Government. This memo provides information for the Internet community.

 draft-hendrikx-wallis-urn-nzl-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4350 RFC4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream G. Hellstrom P. Jones January 2006 ASCII 44405 20 itu-t recommendation t.140

This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting audio and text data within a single RTP session.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This memo defines a Historic Document for the Internet community.

 draft-ietf-avt-audio-t140c-00 HISTORIC HISTORIC IETF rai avt 10.17487/RFC4351 RFC4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec J. Sjoberg M. Westerlund A. Lakaniemi S. Wenger January 2006 ASCII 91297 38 real-time transport protocol audio signals

This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-amrwbplus-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4352 10.17487/RFC4352 RFC4353 A Framework for Conferencing with the Session Initiation Protocol (SIP) J. Rosenberg February 2006 ASCII 67405 29

The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community.

 draft-ietf-sipping-conferencing-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4353 RFC4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service M. Garcia-Martin January 2006 ASCII 46847 21 oma open mobile alliance

The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. This memo provides information for the Internet community.

 draft-garcia-sipping-poc-isb-am-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4354 RFC4355 IANA Registration for Enumservices email, fax, mms, ems, and sms R. Brandner L. Conroy R. Stastny January 2006 ASCII 30218 16 domain name system

This document registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-msg-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4355 RFC4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail R. Gellens January 2006 ASCII 69427 31 cellular telephone x-mms

The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.

One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.

This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. [STANDARDS-TRACK]

 draft-ietf-lemonade-mms-mapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4356 RFC4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms V. Popov I. Kurepkin S. Leontiev January 2006 ASCII 114564 51 cpalgs public-key one-way hash block cipher encyption decryption mac hmac prf wrap unwrap ukm kek key parameter derivation digest cbc counter mode digital signature

This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications. This memo provides information for the Internet community.

 draft-popov-cryptopro-cpalgs-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4357 10.17487/RFC4357 RFC4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA) D. Smith January 2006 ASCII 11562 6 nid namespace identifier omna open mobile naming authority

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Open Mobile Alliance (OMA). OMA defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA). This memo provides information for the Internet community.

 draft-smith-oma-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4358 RFC4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) B. Weis January 2006 ASCII 26989 12 ip encapsulating security payload digital signature

This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. [STANDARDS-TRACK]

 draft-ietf-msec-ipsec-signatures-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4359 RFC4360 BGP Extended Communities Attribute S. Sangli D. Tappan Y. Rekhter February 2006 ASCII 24145 12

This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-ext-communities-09 RFC7153 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4360 10.17487/RFC4360 RFC4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) T. Lemon B. Sommerfeld February 2006 ASCII 28009 12 dhcpv6

This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers. [STANDARDS-TRACK]

 draft-ietf-dhc-3315id-for-v4-05 RFC2131 RFC2132 RFC3315 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4361 10.17487/RFC4361 RFC4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier K. Sandlund January 2006 ASCII 53926 23 internet protocol user datagram protocol real-time transport protocol

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc3242bis-01 RFC3242 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4362 RFC4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions D. Levi D. Harrington January 2006 ASCII 188981 99 mib management information base mac bridges traffic classes enhanced multicast filtering p-bridge-mib q-bridge-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM).

Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]

 draft-ietf-bridge-ext-v2-07 RFC2674 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4363 10.17487/RFC4363 RFC4364 BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen Y. Rekhter February 2006 ASCII 116446 47 service provider ip backbone ce router pe router border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]

 draft-ietf-l3vpn-rfc2547bis-03 RFC2547 RFC4577 RFC4684 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4364 10.17487/RFC4364 RFC4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen February 2006 ASCII 77924 32

This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section. This memo provides information for the Internet community.

 draft-ietf-l3vpn-as2547-07 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4365 10.17487/RFC4365 RFC4366 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright April 2006 ASCII 66344 30 transport protocol layer authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.

The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

 draft-ietf-tls-rfc3546bis-02 RFC3546 RFC5246 RFC6066 RFC4346 RFC5746 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4366 10.17487/RFC4366 RFC4367 What's in a Name: False Assumptions about DNS Names J. Rosenberg Editor IAB February 2006 ASCII 41724 17 domain name system

The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided. This memo provides information for the Internet community.

 draft-iab-dns-assumptions-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4367 10.17487/RFC4367 RFC4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition T. Nadeau S. Hegde January 2006 ASCII 43315 22 management information base mpls-lc-atm-std-mib mpls-lc-fr-std-mib

This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. [STANDARDS-TRACK]

 draft-ietf-mpls-lc-if-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4368 10.17487/RFC4368 RFC4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) K. Gibbons C. Monia J. Tseng F. Travostino January 2006 ASCII 59354 29 mib management information base snmp simple network management protocol ifcp gateway ifcp-mgmt-mib

The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS-TRACK]

 draft-ietf-ips-ifcp-mib-07 RFC6173 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4369 RFC4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control R. Weltman February 2006 ASCII 10624 5 proxy authorization control

This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. [STANDARDS-TRACK]

 draft-weltman-ldapv3-proxy-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4370 RFC4371 BCP 101 Update for IPR Trust B. Carpenter Editor L. Lynch Editor January 2006 ASCII 6901 4

This document updates BCP 101 to take account of the new IETF Intellectual Property Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-carpenter-bcp101-update-03 RFC4071 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4371 RFC4372 Chargeable User Identity F. Adrangi A. Lior J. Korhonen J. Loughney January 2006 ASCII 21555 10 radius remote authentication dial-in user service roaming transaction home network

This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK]

 draft-ietf-radext-chargeable-user-id-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4372 RFC4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) R. Harrison J. Sermersheim Y. Dong January 2006 ASCII 31091 16

The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.

The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community.

 draft-rharrison-lburp-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4373 RFC4374 The application/xv+xml Media Type G. McCobb January 2006 ASCII 10308 6 mime sub-type media descriptor xhtml+voice

This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. This memo provides information for the Internet community.

 draft-mccobb-xv-media-type-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4374 RFC4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain K. Carlberg January 2006 ASCII 17037 8 resource transit domain stub domain

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

 draft-ietf-ieprep-domain-req-05 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4375 RFC4376 Requirements for Floor Control Protocols P. Koskelainen J. Ott H. Schulzrinne X. Wu February 2006 ASCII 30021 14 shared resources multiparty conferences

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 defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. This memo provides information for the Internet community.

 draft-ietf-xcon-floor-control-req-03 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4376 RFC4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks T. Nadeau M. Morrow G. Swallow D. Allan S. Matsushima February 2006 ASCII 31889 15

This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. This memo provides information for the Internet community.

 draft-ietf-mpls-oam-requirements-07 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4377 10.17487/RFC4377 RFC4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) D. Allan Editor T. Nadeau Editor February 2006 ASCII 23640 11 data plane fcaps

This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS). The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. This memo provides information for the Internet community.

 draft-ietf-mpls-oam-frmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4378 RFC4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures K. Kompella G. Swallow February 2006 ASCII 116872 50 data plane

This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS-TRACK]

 draft-ietf-mpls-lsp-ping-13 RFC1122 RFC5462 RFC6424 RFC6425 RFC6426 RFC6829 RFC7506 RFC7537 RFC7743 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4379 10.17487/RFC4379 RFC4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) C. Huitema February 2006 ASCII 132607 53

We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]

 draft-huitema-v6ops-teredo-05 RFC5991 RFC6081 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4380 10.17487/RFC4380 RFC4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) M. Behringer February 2006 ASCII 55200 22 service provider atm asynchronous transfer mode frame relay

This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.

The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community.

 draft-behringer-mpls-security-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4381 RFC4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base T. Nadeau Editor H. van der Linde Editor February 2006 ASCII 85594 44 mib management information base multiprotocol label switching label switching router lsr mpls-l3vpn-std-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 to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mpls-vpn-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4382 10.17487/RFC4382 RFC4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) M. Baugher E. Carrara February 2006 ASCII 41766 19 multicast data stream broadcast data stream

This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]

 draft-ietf-msec-srtp-tesla-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4383 RFC4384 BGP Communities for Data Collection D. Meyer February 2006 ASCII 26078 12 border gateway protocol

BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-collection-communities-06 BCP0114 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4384 10.17487/RFC4384 RFC4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN S. Bryant G. Swallow L. Martini D. McPherson February 2006 ASCII 22440 12 multiprotocol label switching packet switched network pseudowire associated channel header

This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]

 draft-ietf-pwe3-cw-06 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4385 10.17487/RFC4385 RFC4386 Internet X.509 Public Key Infrastructure Repository Locator Service S. Boeyen P. Hallam-Baker February 2006 ASCII 11330 6 pki public key infrastructure dns srv

This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories.This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-pkixrep-04 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC4386 RFC4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP P. Gutmann Editor February 2006 ASCII 63182 25 pki hypertext transfer protocol

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. [STANDARDS-TRACK]

 draft-ietf-pkix-certstore-http-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4387 RFC4388 Dynamic Host Configuration Protocol (DHCP) Leasequery R. Woundy K. Kinnear February 2006 ASCII 63914 27 dhcpv4 ip address

A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information. [STANDARDS-TRACK]

 draft-ietf-dhc-leasequery-09 RFC6148 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4388 10.17487/RFC4388 RFC4389 Neighbor Discovery Proxies (ND Proxy) D. Thaler M. Talwar C. Patel April 2006 ASCII 38124 18 ndproxy

Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipv6-ndproxy-04 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4389 10.17487/RFC4389 RFC4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand V. Kashyap April 2006 ASCII 10754 6 bootstrap boot ipoib

IP over Infiniband (IPoIB) link-layer address is 20 octets long. This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol (DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. [STANDARDS-TRACK]

 draft-ietf-ipoib-dhcp-over-infiniband-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4390 RFC4391 Transmission of IP over InfiniBand (IPoIB) J. Chu V. Kashyap April 2006 ASCII 45858 21 address resolution protocol arp ib

This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK]

 draft-ietf-ipoib-ip-over-infiniband-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4391 RFC4392 IP over InfiniBand (IPoIB) Architecture V. Kashyap April 2006 ASCII 53506 23 ib ipv4 ipv6

InfiniBand is a high-speed, channel-based interconnect between systems and devices.

This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. This memo provides information for the Internet community.

 draft-ietf-ipoib-architecture-04 INFORMATIONAL INFORMATIONAL IETF int ipoib 10.17487/RFC4392 RFC4393 MIME Type Registrations for 3GPP2 Multimedia Files H. Garudadri March 2006 ASCII 14369 7 third-generation partnership project 2

This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

 draft-garudadri-avt-3gpp2-mime-02 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4393 RFC4394 A Transport Network View of the Link Management Protocol (LMP) D. Fedyk O. Aboul-Magd D. Brungard J. Lang D. Papadimitriou February 2006 ASCII 40812 18 gmpls ason discovery sdh otn sonet pdh

The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This memo provides information for the Internet community.

 draft-ietf-ccamp-transport-lmp-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4394 RFC4395 Guidelines and Registration Procedures for New URI Schemes T. Hansen T. Hardie L. Masinter February 2006 ASCII 31933 15 uniform resource identifier syntax semantics

This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hansen-2717bis-2718bis-uri-guidelines-06 RFC2717 RFC2718 RFC7595 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4395 10.17487/RFC4395 RFC4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text J. Rey Y. Matsui February 2006 ASCII 155421 66 3GPP 3GPP timed text streaming real-time streaming titling decorated text scrolling text karaoke hyperlinked text highlighted text blinking text highlight color text delay text style text box text wrap text sample sample descriptions modifier boxes UTF-8 UTF-16

This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-3gpp-timed-text-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4396 10.17487/RFC4396 RFC4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture I. Bryskin A. Farrel February 2006 ASCII 40331 19

Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).

This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.

It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-lexicography-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4397 10.17487/RFC4397 RFC4398 Storing Certificates in the Domain Name System (DNS) S. Josefsson March 2006 ASCII 35652 17 SC-DNS cryptology authenticity

Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

 draft-ietf-dnsext-rfc2538bis-09 RFC2538 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4398 10.17487/RFC4398 RFC4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) N. Williams February 2006 ASCII 15272 8 secure session layer message integrity check mic

This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-prf-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4401 RFC4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism N. Williams February 2006 ASCII 9549 5

This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. [STANDARDS-TRACK]

 draft-ietf-kitten-krb5-gssapi-prf-04 RFC7802 HISTORIC PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=4402 10.17487/RFC4402 RFC4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) B. Bergeson K. Boogert V. Nanjundaswamy February 2006 ASCII 78747 42 LDAPv3

This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory. This memo provides information for the Internet community.

 draft-bergeson-uddi-ldap-schema-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4403 RFC4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP) R. Natarajan A. Rijhsinghani February 2006 ASCII 60475 33 mib management information base fcip-mgmt-mib

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 Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. [STANDARDS-TRACK]

 draft-ietf-ips-fcip-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4404 10.17487/RFC4404 RFC4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message E. Allman H. Katz April 2006 ASCII 29429 14 spam spoofing phishing

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. This memo defines an Experimental Protocol for the Internet community.

 draft-katz-submitter-01 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4405 RFC4406 Sender ID: Authenticating E-Mail J. Lyon M. Wong April 2006 ASCII 40428 19 simple mail transfer protocol spam spoofing

Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. This memo defines an Experimental Protocol for the Internet community.

 draft-lyon-senderid-core-01 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4406 RFC4407 Purported Responsible Address in E-Mail Messages J. Lyon April 2006 ASCII 14387 7 pra purported responsible address

This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community.

 draft-lyon-senderid-pra-01 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4407 10.17487/RFC4407 RFC4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 M. Wong W. Schlitt April 2006 ASCII 105009 48 spoofing spf

E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. This memo defines an Experimental Protocol for the Internet community.

 draft-schlitt-spf-classic-02 RFC7208 RFC6652 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4408 10.17487/RFC4408 RFC4409 Message Submission for Mail R. Gellens J. Klensin April 2006 ASCII 34911 17 smtp simle mail transfer protocol ua user agent

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay and final delivery are unaffected, and continue to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

 draft-gellens-submit-bis-02 RFC2476 RFC6409 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4409 10.17487/RFC4409 RFC4410 Selectively Reliable Multicast Protocol (SRMP) M. Pullen F. Zhao D. Cohen February 2006 ASCII 65877 30 transport best-effort srt selectively reliable transport

The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application. This memo defines an Experimental Protocol for the Internet community.

 draft-pullen-srmp-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4410 10.17487/RFC4410 RFC4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events J. Polk February 2006 ASCII 49260 22 Resource-Priority preempt preempted Q.850 preconditions

This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. [STANDARDS-TRACK]

 draft-ietf-sipping-reason-header-for-preemption-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4411 RFC4412 Communications Resource Priority for the Session Initiation Protocol (SIP) H. Schulzrinne J. Polk February 2006 ASCII 79193 36 RP RPH preferential preempt preempted preemption queue DSN DRSN WPS ETS Q.735 Q735 disaster I.255 flash flash-override

This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. [STANDARDS-TRACK]

 draft-ietf-sip-resource-priority-10 RFC7134 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4412 RFC4413 TCP/IP Field Behavior M. West S. McCann March 2006 ASCII 28435 44 transmission control protocol header compression

This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers. This memo provides information for the Internet community.

 draft-ietf-rohc-tcp-field-behavior-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4413 10.17487/RFC4413 RFC4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS) A. Newton February 2006 ASCII 89985 51

This document describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. [STANDARDS-TRACK]

 draft-ietf-enum-iris-ereg-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4414 RFC4415 IANA Registration for Enumservice Voice R. Brandner L. Conroy R. Stastny February 2006 ASCII 15956 8 uniform resource identifier uri voice call audio call

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. [STANDARDS-TRACK]

 draft-ietf-enum-voice-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4415 RFC4416 Goals for Internet Messaging to Support Diverse Service Environments J. Wong Editor February 2006 ASCII 93676 43 IMAP protocol extensions messaging wireless handheld telephone user interface multi-modal LEMONADE extension principles history background motivation cellular interworking constraints TUI WUI client MMS

This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.

The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.

The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.

The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community.

 draft-ietf-lemonade-goals-05 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC4416 RFC4417 Report of the 2004 IAB Messaging Workshop P. Resnick Editor P. Saint-Andre Editor February 2006 ASCII 47201 20 internet architecture board internet messaging

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA. The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB. This memo provides information for the Internet community.

 draft-iab-messaging-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4417 RFC4418 UMAC: Message Authentication Code using Universal Hashing T. Krovetz Editor March 2006 ASCII 51304 27

This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.

To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material. This memo provides information for the Internet community.

 draft-krovetz-umac-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4418 10.17487/RFC4418 RFC4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol M. Friedl N. Provos W. Simpson March 2006 ASCII 18356 10

This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. [STANDARDS-TRACK]

 draft-ietf-secsh-dh-group-exchange-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4419 RFC4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou J.-P. Vasseur A. Ayyangar February 2006 ASCII 47235 21 SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvpte-attributes-05 RFC5420 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4420 RFC4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes C. Perkins February 2006 ASCII 8000 4 realtime transport protocol video stream

The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP. This memo extends the format to support additional colour sampling modes. [STANDARDS-TRACK]

 draft-ietf-avt-uncomp-video-ext-01 RFC4175 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4421 RFC4422 Simple Authentication and Security Layer (SASL) A. Melnikov Editor K. Zeilenga Editor June 2006 ASCII 73206 33 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.

This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.

This document obsoletes RFC 2222. [STANDARDS-TRACK]

 draft-ietf-sasl-rfc2222bis-15 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4422 RFC4423 Host Identity Protocol (HIP) Architecture R. Moskowitz P. Nikander May 2006 ASCII 61049 24

This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. This memo provides information for the Internet community.

 draft-ietf-hip-arch-03 INFORMATIONAL INFORMATIONAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=4423 10.17487/RFC4423 RFC4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec S. Ahmadi February 2006 ASCII 16331 8 speech codec variable-rate multicode wideband speech codec

This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e., VMR-WB mode 4). These updates do not affect the existing modes of VMR-WB already specified in RFC 4348.

The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vmr-wb-extension-02 RFC4348 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4424 RFC4425 RTP Payload Format for Video Codec 1 (VC-1) A. Klemets February 2006 ASCII 84335 36 smpte 421m wmv wmv9 vc-9

This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vc1-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4425 10.17487/RFC4425 RFC4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification J. Lang Editor B. Rajagopalan Editor D. Papadimitriou Editor March 2006 ASCII 55820 23

This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-recovery-functional-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4426 RFC4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) E. Mannie Editor D. Papadimitriou Editor March 2006 ASCII 43842 22

This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-recovery-terminology-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4427 10.17487/RFC4427 RFC4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) D. Papadimitriou Editor E. Mannie Editor March 2006 ASCII 118749 47

This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4428 10.17487/RFC4428 RFC4429 Optimistic Duplicate Address Detection (DAD) for IPv6 N. Moore April 2006 ASCII 33123 17 internet protocol version 6 stateless address autoconfiguration neighbor discovery

Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]

 draft-ietf-ipv6-optimistic-dad-07 RFC7527 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4429 10.17487/RFC4429 RFC4430 Kerberized Internet Negotiation of Keys (KINK) S. Sakane K. Kamada M. Thomas J. Vilhuber March 2006 ASCII 91261 40 ike internet key exchange

This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS-TRACK]

 draft-ietf-kink-kink-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec kink http://www.rfc-editor.org/errata_search.php?rfc=4430 10.17487/RFC4430 RFC4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record M. Andrews S. Weiler February 2006 ASCII 7861 4 dns domain name space

This document defines a new DNS resource record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. This memo provides information for the Internet community.

 draft-andrews-dlv-dns-rr-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4431 RFC4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol B. Harris March 2006 ASCII 16077 8 rivest-sharmir-adleman public key encryption

This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. [STANDARDS-TRACK]

 draft-harris-ssh-rsa-kex-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4432 RFC4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment M. Kulkarni A. Patel K. Leung March 2006 ASCII 55636 25 internet protocol messaging

Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. [STANDARDS-TRACK]

 draft-ietf-mip4-dynamic-assignment-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4433 10.17487/RFC4433 RFC4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman February 2006 ASCII 9384 6 security ipsec advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. [STANDARDS-TRACK]

 draft-hoffman-rfc3664bis-05 RFC3664 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4434 RFC4435 A Framework for the Usage of Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma H. Asaeda H. Schulzrinne April 2006 ASCII 51687 22 session description protocol sdp sdpng

This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. This memo provides information for the Internet community.

 draft-ietf-mmusic-img-framework-09 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4435 RFC4436 Detecting Network Attachment in IPv4 (DNAv4) B. Aboba J. Carlson S. Cheshire March 2006 ASCII 35991 15 internet protocol

The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. [STANDARDS-TRACK]

 draft-ietf-dhc-dna-ipv4-18 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4436 10.17487/RFC4436 RFC4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources J. Whitehead G. Clemm J. Reschke Editor March 2006 ASCII 49932 25 http hyper text transfer protocol

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-webdav-redirectref-protocol-13 EXPERIMENTAL EXPERIMENTAL IETF app webdav 10.17487/RFC4437 RFC4438 Fibre-Channel Name Server MIB C. DeSanti V. Gaonkar H.K. Vivek K. McCloghrie S. Gai April 2006 ASCII 70156 36 management information base T11-fc-name-server-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. [STANDARDS-TRACK]

 draft-ietf-imss-fc-nsm-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4438 10.17487/RFC4438 RFC4439 Fibre Channel Fabric Address Manager MIB C. DeSanti V. Gaonkar K. McCloghrie S. Gai March 2006 ASCII 77153 40 management information base t11-tc-mib t11-fc-fabric-addr-mgr-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fam-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4439 10.17487/RFC4439 RFC4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF) S. Floyd Editor V. Paxson Editor A. Falk Editor IAB March 2006 ASCII 29063 13 internet architecture board

This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF. This memo provides information for the Internet community.

 draft-iab-irtf-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4440 RFC4441 The IEEE 802/IETF Relationship B. Aboba Editor March 2006 ASCII 49624 22 snmp aaa simple network management protocol authentication authorization accounting

Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. This memo provides information for the Internet community.

 draft-iab-ieee-802-rel-05 RFC7241 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4441 RFC4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) S. Fries H. Tschofenig March 2006 ASCII 37345 18 authentication mikey multimedia internet keying protocol

TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.

This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]

 draft-ietf-msec-bootstrapping-tesla-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4442 RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering M. Gupta Editor March 2006 ASCII 48969 24

This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]

 draft-ietf-ipngwg-icmp-v3-07 RFC2463 RFC2780 RFC4884 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4443 10.17487/RFC4443 RFC4444 Management Information Base for Intermediate System to Intermediate System (IS-IS) J. Parker Editor April 2006 ASCII 181968 103 mib routing protocol isis-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. [STANDARDS-TRACK]

 draft-ietf-isis-wg-mib-26 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=4444 10.17487/RFC4444 RFC4445 A Proposed Media Delivery Index (MDI) J. Welch J. Clark April 2006 ASCII 24171 10

This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. This memo provides information for the Internet community.

 draft-welch-mdi-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4445 RFC4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) L. Martini April 2006 ASCII 19782 9

This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pwe3-iana-allocation-15 BCP0116 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4446 10.17487/RFC4446 RFC4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) L. Martini Editor E. Rosen N. El-Aawar T. Smith G. Heron April 2006 ASCII 76204 33 mpls multiprotocol label switching protocol pdu protocol data units

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. [STANDARDS-TRACK]

 draft-ietf-pwe3-control-protocol-17 RFC6723 RFC6870 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4447 10.17487/RFC4447 RFC4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks L. Martini Editor E. Rosen N. El-Aawar G. Heron April 2006 ASCII 49012 24 pw pseudowire pdu protocol data units

An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]

 draft-ietf-pwe3-ethernet-encap-11 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4448 10.17487/RFC4448 RFC4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key C. Perkins June 2006 ASCII 15080 7 mobile node correspondent node binding management key binding updates

A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS-TRACK]

 draft-ietf-mip6-precfgkbm-04 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4449 10.17487/RFC4449 RFC4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents E. Lear H. Alvestrand March 2006 ASCII 23822 11

This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic. This memo provides information for the Internet community.

 draft-ietf-newtrk-decruft-experiment-03 INFORMATIONAL INFORMATIONAL IETF gen newtrk http://www.rfc-editor.org/errata_search.php?rfc=4450 10.17487/RFC4450 RFC4451 BGP MULTI_EXIT_DISC (MED) Considerations D. McPherson V. Gill March 2006 ASCII 28435 13 border gateway protocol

The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.

This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. This memo provides information for the Internet community.

 draft-ietf-grow-bgp-med-considerations-05 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4451 RFC4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces H. Van de Sompel T. Hammond E. Neylon S. Weibel April 2006 ASCII 36408 17 uniform resource identifier

This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces. Namespaces participating in the "info" URI scheme are regulated by an "info" Registry mechanism. This memo provides information for the Internet community.

 draft-vandesompel-info-uri-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4452 10.17487/RFC4452 RFC4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis April 2006 ASCII 16833 8 sip extensions

The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications. This memo provides information for the Internet community.

 draft-ietf-sipping-consent-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4453 RFC4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) S. Singh M. Townsley C. Pignataro May 2006 ASCII 58281 26 extensible tunneling protocol

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use the L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over an IP network. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-atm-04 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4454 RFC4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities M. Hallak-Stamler M. Bakke Y. Lederman M. Krueger K. McCloghrie April 2006 ASCII 178947 88 mib management information base scsi-mib

This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS-TRACK]

 draft-ietf-ips-scsi-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4455 10.17487/RFC4455 RFC4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates E. Chen R. Chandra April 2006 ASCII 23209 12 BGP-RR Border Gateway Protocol autonomous system

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.

This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).

This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]

 draft-ietf-idr-rfc2796bis-02 RFC2796 RFC1966 RFC7606 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4456 10.17487/RFC4456 RFC4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) G. Camarillo G. Blanco April 2006 ASCII 15884 8 3gpp third generation partnership project 3rd generation partnership project ims ip multimedia subsystem

This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. This memo provides information for the Internet community.

 draft-camarillo-sipping-user-database-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4457 RFC4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) C. Jennings F. Audet J. Elwell April 2006 ASCII 41378 21 universal resource identifiers

The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. This memo provides information for the Internet community.

 draft-jennings-sip-voicemail-uri-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4458 10.17487/RFC4458 RFC4459 MTU and Fragmentation Issues with In-the-Network Tunneling P. Savola April 2006 ASCII 32051 14

Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. This memo provides information for the Internet community.

 draft-savola-mtufrag-network-tunneling-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4459 RFC4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues R. Stewart I. Arias-Rodriguez K. Poon A. Caro M. Tuexen April 2006 ASCII 215405 109 SCTP IP internet transport packet network

This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the delta, a description of the problem and the details of the solution are also provided. This memo provides information for the Internet community.

 draft-ietf-tsvwg-sctpimpguide-16 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4460 RFC4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) S. Yasukawa Editor April 2006 ASCII 64542 30 p2mp multiprotocol label switching

This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).

There is no intent to specify solution-specific details or application-specific requirements in this document.

The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.

 draft-ietf-mpls-p2mp-sig-requirement-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4461 RFC4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol J. Hutzelman J. Salowey J. Galbraith V. Welch May 2006 ASCII 65280 29

The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.

This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.

This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS-TRACK]

 draft-ietf-secsh-gsskeyex-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4462 10.17487/RFC4462 RFC4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks S. Shanmugham P. Monaco B. Eberman April 2006 ASCII 176385 86

This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area.

MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). This memo provides information for the Internet community.

 draft-shanmugham-mrcp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4463 RFC4464 Signaling Compression (SigComp) Users' Guide A. Surtees M. West May 2006 ASCII 79643 43

This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. This memo provides information for the Internet community.

 draft-ietf-rohc-sigcomp-user-guide-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4464 RFC4465 Signaling Compression (SigComp) Torture Tests A. Surtees M. West June 2006 ASCII 118772 68 SigComp Universal Decompressor Virtual Machine

This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. This memo provides information for the Internet community.

 draft-ietf-rohc-sigcomp-torture-tests-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4465 RFC4466 Collected Extensions to IMAP4 ABNF A. Melnikov C. Daboo April 2006 ASCII 33752 17

Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.

This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions.

This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK]

 draft-melnikov-imap-ext-abnf-08 RFC2088 RFC2342 RFC3501 RFC3502 RFC3516 RFC6237 RFC7377 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4466 RFC4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension M. Crispin May 2006 ASCII 36714 18 imap url imapurl

This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.

An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". [STANDARDS-TRACK]

 draft-ietf-lemonade-urlauth-08 RFC5092 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4467 RFC4468 Message Submission BURL Extension C. Newman May 2006 ASCII 28614 14 URLAUTH IMAP IMAPURL Forward-without-download mobile-client lemonade

The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS-TRACK]

 draft-ietf-lemonade-burl-04 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4468 10.17487/RFC4468 RFC4469 Internet Message Access Protocol (IMAP) CATENATE Extension P. Resnick April 2006 ASCII 21822 13 append

The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. [STANDARDS-TRACK]

 draft-ietf-lemonade-catenate-05 RFC3501 RFC3502 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4469 10.17487/RFC4469 RFC4470 Minimally Covering NSEC Records and DNSSEC On-line Signing S. Weiler J. Ihren April 2006 ASCII 17471 8 dns security domain name system

This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-online-signing-02 RFC4035 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4470 10.17487/RFC4470 RFC4471 Derivation of DNS Name Predecessor and Successor G. Sisson B. Laurie September 2006 ASCII 42430 23 domain namespace dynamic nsec dnssec

This document describes two methods for deriving the canonically-ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnsext-dns-name-p-s-01 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC4471 RFC4472 Operational Considerations and Issues with IPv6 DNS A. Durand J. Ihren P. Savola April 2006 ASCII 68882 29 domain name system internet protocol version 6

This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. This memo provides information for the Internet community.

 draft-ietf-dnsop-ipv6-dns-issues-12 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4472 RFC4473 Requirements for Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma J. Ott H. Schulzrinne May 2006 ASCII 53864 23 media-on-deman multicast

This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. This memo provides information for the Internet community.

 draft-ietf-mmusic-img-req-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4473 RFC4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) J. Peterson C. Jennings August 2006 ASCII 104952 41 security identity identity-info

The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK]

 draft-ietf-sip-identity-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4474 10.17487/RFC4474 RFC4475 Session Initiation Protocol (SIP) Torture Test Messages R. Sparks Editor A. Hawrylyshen A. Johnston J. Rosenberg H. Schulzrinne May 2006 ASCII 93276 53

This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. This memo provides information for the Internet community.

 draft-ietf-sipping-torture-tests-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4475 RFC4476 Attribute Certificate (AC) Policies Extension C. Francis D. Pinkas May 2006 ASCII 20229 11 acp attribute certificate policies

This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs. [STANDARDS-TRACK]

 draft-ietf-pkix-acpolicies-extn-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4476 RFC4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues T. Chown S. Venaas C. Strauf May 2006 ASCII 30440 14 internet protocol

A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken. This memo provides information for the Internet community.

 draft-ietf-dhc-dual-stack-04 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4477 RFC4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol Y. Nir April 2006 ASCII 10714 5 lifetime

This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function. This memo defines an Experimental Protocol for the Internet community.

 draft-nir-ikev2-auth-lt-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4478 RFC4479 A Data Model for Presence J. Rosenberg July 2006 ASCII 88399 35 simple sip session initiation protocol

This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. [STANDARDS-TRACK]

 draft-ietf-simple-presence-data-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4479 10.17487/RFC4479 RFC4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) H. Schulzrinne V. Gurbani P. Kyzivat J. Rosenberg July 2006 ASCII 74026 37

The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.

This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.

These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]

 draft-ietf-simple-rpid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4480 10.17487/RFC4480 RFC4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals H. Schulzrinne July 2006 ASCII 15549 9

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS-TRACK]

 draft-ietf-simple-future-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4481 RFC4482 CIPID: Contact Information for the Presence Information Data Format H. Schulzrinne July 2006 ASCII 22157 11 pidf

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS-TRACK]

 draft-ietf-simple-cipid-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4482 RFC4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages E. Burger Editor May 2006 ASCII 36794 17 universal resource locator mime external-body access-type

This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. [STANDARDS-TRACK]

 draft-ietf-sip-content-indirect-mech-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4483 10.17487/RFC4483 RFC4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP) J. Peterson J. Polk D. Sicker H. Tschofenig August 2006 ASCII 37169 15 policy decision

This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. This memo provides information for the Internet community.

 draft-ietf-sipping-trait-authz-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4484 RFC4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne May 2006 ASCII 57278 23 interactive communication

The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. This memo provides information for the Internet community.

 draft-ietf-sip-guidelines-09 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4485 RFC4486 Subcodes for BGP Cease Notification Message E. Chen V. Gillet April 2006 ASCII 10254 6 border gateway protocol bgp peers

This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. [STANDARDS-TRACK]

 draft-ietf-idr-cease-subcode-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4486 RFC4487 Mobile IPv6 and Firewalls: Problem Statement F. Le S. Faccin B. Patil H. Tschofenig May 2006 ASCII 32022 16 3g mobile networks

This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.

The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. This memo provides information for the Internet community.

 draft-ietf-mip6-firewalls-04 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4487 RFC4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription O. Levin May 2006 ASCII 17264 8

The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK]

 draft-ietf-sip-refer-with-norefersub-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4488 RFC4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses J-S. Park M-K. Shin H-J. Kim April 2006 ASCII 12224 6 iid interface identifiers

This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast-prefix-based IPv6 multicast addresses. This memo updates RFC 3306. [STANDARDS-TRACK]

 draft-ietf-ipv6-link-scoped-mcast-09 RFC3306 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4489 RFC4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) S. Leontiev Editor G. Chudov Editor May 2006 ASCII 54912 29 CPCMS S/MIME PKIX X.509 certificate CRL revocation public-key one-way hash block cipher encryption decryption MAC HMAC PRF wrap unwrap UKM KEK key Diffie-Hellman agreement transport parameter derivation digest CBC counter mode digital signature

This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. [STANDARDS-TRACK]

 draft-ietf-smime-gost-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4490 10.17487/RFC4490 RFC4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile S. Leontiev Editor D. Shefanovski Editor May 2006 ASCII 39095 20 PKIX X.509 CPPK public-key one-way hash function block cipher encryption decryption key derivation parameter message digest digital signature 34.310 34.311 34.310-95 34.310-2004 34.311-95

This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]

 draft-ietf-pkix-gost-cppk-05 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4491 10.17487/RFC4491 RFC4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) S. Blake-Wilson N. Bolyard V. Gupta C. Hawk B. Moeller May 2006 ASCII 72231 35 ecdh elliptic curve diffie-hellman elliptic curve digital signature algorithm ecdsa

This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. This memo provides information for the Internet community.

 draft-ietf-tls-ecc-12 RFC5246 RFC7027 RFC7919 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4492 10.17487/RFC4492 RFC4493 The AES-CMAC Algorithm JH. Song R. Poovendran J. Lee T. Iwata June 2006 ASCII 38751 20 cipher-based message authentication code omac1 one-key cbc mac1 advanced encryption algorithm

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

 draft-songlee-aes-cmac-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4493 RFC4494 The AES-CMAC-96 Algorithm and Its Use with IPsec JH. Song R. Poovendran J. Lee June 2006 ASCII 14992 8 cipher-basd message authentication code one-key cbc-mac1 omac1 xcbc extended cipher block chaining advanced encryption standard

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode as an authentication mechanism of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. This new algorithm is named AES-CMAC-96. [STANDARDS-TRACK]

 draft-songlee-aes-cmac-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4494 RFC4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow J. Polk S. Dhesikan May 2006 ASCII 44983 21 rsvpv1

This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels. This specification is an extension of RFC 2205. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-bw-reduction-02 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4495 RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases M. Stecher A. Barbir May 2006 ASCII 27403 12

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES. This memo provides information for the Internet community.

 draft-ietf-opes-smtp-use-cases-06 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4496 RFC4497 Interworking between the Session Initiation Protocol (SIP) and QSIG J. Elwell F. Derks P. Mourot O. Rousseau May 2006 ASCII 149992 65 telecommunication networks enterprise networks signalling

This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-qsig2sip-04 BCP0117 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4497 RFC4498 The Managed Object Aggregation MIB G. Keeni May 2006 ASCII 59214 29 management information base aggregate mib time aggregate mib

This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances. This memo defines an Experimental Protocol for the Internet community.

 draft-glenn-mo-aggr-mib-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4498 RFC4501 Domain Name System Uniform Resource Identifiers S. Josefsson May 2006 ASCII 20990 10 dns uri

This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]

 draft-josefsson-dns-url-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4501 10.17487/RFC4501 RFC4502 Remote Network Monitoring Management Information Base Version 2 S. Waldbusser May 2006 ASCII 290816 142 RMON-MIB RMON MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.

This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmon2-v2-05 RFC2021 RFC3273 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=4502 10.17487/RFC4502 RFC4503 A Description of the Rabbit Stream Cipher Algorithm M. Boesgaard M. Vesterager E. Zenner May 2006 ASCII 22308 12 iv initialization vector encryption algorithm

This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed. This memo provides information for the Internet community.

 draft-zenner-rabbit-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4503 10.17487/RFC4503 RFC4504 SIP Telephony Device Requirements and Configuration H. Sinnreich Editor S. Lass C. Stredicke May 2006 ASCII 84849 37 session initiation protocol pc pda analog

This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.

We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community.

 draft-sinnreich-sipdev-req-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4504 RFC4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga June 2006 ASCII 16599 9 SASL-ANON Simple Authentication Security Layer

On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. [STANDARDS-TRACK]

 draft-ietf-sasl-anon-05 RFC2245 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4505 RFC4506 XDR: External Data Representation Standard M. Eisler Editor May 2006 ASCII 55477 27 XDR rpc onc open network computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rfc1832bis-06 RFC1832 STD0067 INTERNET STANDARD INTERNET STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=4506 10.17487/RFC4506 RFC4507 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig May 2006 ASCII 35329 17

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping \%per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. [STANDARDS-TRACK]

 draft-salowey-tls-ticket-07 RFC5077 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4507 RFC4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method O. Levin A. Johnston May 2006 ASCII 11338 6 caller preferences

The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. [STANDARDS-TRACK]

 draft-ietf-sip-refer-feature-param-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4508 RFC4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) W. Hardaker May 2006 ASCII 14155 7 domain name system dns dnskey

This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]

 draft-ietf-dnsext-ds-sha256-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4509 10.17487/RFC4509 RFC4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map K. Zeilenga Editor June 2006 ASCII 12354 7 LDAPV3 LDAv3 x.500 LDAP3-ATD syntax LDAP3-UTF8 x.500 ASN.1 string format STR-LDAP LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document provides a road map of the LDAP Technical Specification. [STANDARDS-TRACK]

 draft-ietf-ldapbis-roadmap-08 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis 10.17487/RFC4510 RFC4511 Lightweight Directory Access Protocol (LDAP): The Protocol J. Sermersheim Editor June 2006 ASCII 150116 68 LDAP TLS LDAPv3 LDAv3 x.500

This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

 draft-ietf-ldapbis-protocol-32 RFC2251 RFC2830 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4511 10.17487/RFC4511 RFC4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models K. Zeilenga Editor June 2006 ASCII 108377 52 LDAv3 x.500 LDAPv3 LDAP3-ATD syntax elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. [STANDARDS-TRACK]

 draft-ietf-ldapbis-models-14 RFC2251 RFC2252 RFC2256 RFC3674 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4512 10.17487/RFC4512 RFC4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms R. Harrison Editor June 2006 ASCII 80546 34 LDAP TLS

This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.

This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.

This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.

This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS-TRACK]

 draft-ietf-ldapbis-authmeth-19 RFC2251 RFC2829 RFC2830 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis 10.17487/RFC4513 RFC4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names K. Zeilenga Editor June 2006 ASCII 31859 15 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

 draft-ietf-ldapbis-dn-16 RFC2253 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4514 10.17487/RFC4514 RFC4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters M. Smith Editor T. Howes June 2006 ASCII 23885 12 STR-LDAP STRLDAP LDAPv3 X.500 BER ASN.1

Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. [STANDARDS-TRACK]

 draft-ietf-ldapbis-filter-09 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4515 10.17487/RFC4515 RFC4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator M. Smith Editor T. Howes June 2006 ASCII 30562 15 LDAP-URL LDAPURL LDAP search URL URI LDAPv3

This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. [STANDARDS-TRACK]

 draft-ietf-ldapbis-url-09 RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4516 10.17487/RFC4516 RFC4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules S. Legg Editor June 2006 ASCII 114285 53 LDAP3-ATD LDAv3 x.500 syntax,

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. [STANDARDS-TRACK]

 draft-ietf-ldapbis-syntaxes-11 RFC2252 RFC2256 RFC3698 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4517 10.17487/RFC4517 RFC4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation K. Zeilenga June 2006 ASCII 28166 14

The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. [STANDARDS-TRACK]

 draft-ietf-ldapbis-strprep-07 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4518 10.17487/RFC4518 RFC4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications A. Sciberras Editor June 2006 ASCII 64996 35 Lightweight Directory Access Protocol syntax

This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS-TRACK]

 draft-ietf-ldapbis-user-schema-11 RFC2256 RFC2247 RFC2798 RFC2377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4519 10.17487/RFC4519 RFC4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga June 2006 ASCII 34298 19

This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ldapbis-bcp64-07 RFC3383 BCP0064 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis 10.17487/RFC4520 RFC4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions K. Zeilenga June 2006 ASCII 34585 16

The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-zeilenga-ldap-ext-10 BCP0118 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4521 10.17487/RFC4521 RFC4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option S. Legg June 2006 ASCII 16276 8 ber ldap-specific encoding

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP\-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. [STANDARDS-TRACK]

 draft-legg-ldap-binary-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4522 RFC4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates K. Zeilenga June 2006 ASCII 43753 24 LDAP3-ATD LDAv3 x.500 syntax pkix

This document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP). The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. [STANDARDS-TRACK]

 draft-zeilenga-ldap-x509-02 RFC2252 RFC2256 RFC2587 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4523 10.17487/RFC4523 RFC4524 COSINE LDAP/X.500 Schema K. Zeilenga Editor June 2006 ASCII 11245 25 Naming

This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE and Internet X.500 pilot projects.

This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. [STANDARDS-TRACK]

 draft-zeilenga-ldap-cosine-02 RFC1274 RFC2247 RFC2798 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4524 10.17487/RFC4524 RFC4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension K. Zeilenga June 2006 ASCII 11251 6 pre-read post-read control extension

This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension. This memo provides information for the Internet community.

 draft-zeilenga-ldap-incr-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4525 RFC4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters K. Zeilenga June 2006 ASCII 10097 5 x.500 string representation

This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. [STANDARDS-TRACK]

 draft-zeilenga-ldap-t-f-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4526 10.17487/RFC4526 RFC4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls K. Zeilenga June 2006 ASCII 15987 8

This document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. [STANDARDS-TRACK]

 draft-zeilenga-ldap-readentry-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4527 RFC4528 Lightweight Directory Access Protocol (LDAP) Assertion Control K. Zeilenga June 2006 ASCII 12539 6 test and set test and clear

This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations. [STANDARDS-TRACK]

 draft-zeilenga-ldap-assert-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4528 RFC4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol K. Zeilenga June 2006 ASCII 11927 6

The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class. This memo provides information for the Internet community.

 draft-zeilenga-ldap-adlist-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4529 10.17487/RFC4529 RFC4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute K. Zeilenga June 2006 ASCII 15191 8 x.500 universally unique identifier

This document describes the LDAP/X.500 \'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. [STANDARDS-TRACK]

 draft-zeilenga-ldap-uuid-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4530 RFC4531 Lightweight Directory Access Protocol (LDAP) Turn Operation K. Zeilenga June 2006 ASCII 18986 9 turn request turn response

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. This memo defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldap-turn-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4531 RFC4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation K. Zeilenga June 2006 ASCII 14247 7 authorization identity

This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP "Who am I?" operation. [STANDARDS-TRACK]

 draft-zeilenga-ldap-authzid-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4532 10.17487/RFC4532 RFC4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation K. Zeilenga J.H. Choi June 2006 ASCII 73895 32 dit directory information tree

This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. This memo defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldup-sync-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4533 RFC4534 Group Security Policy Token v1 A Colegrove H Harney June 2006 ASCII 54157 33 cryptographic group

The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token. [STANDARDS-TRACK]

 draft-ietf-msec-policy-token-sec-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4534 10.17487/RFC4534 RFC4535 GSAKMP: Group Secure Association Key Management Protocol H. Harney U. Meth A. Colegrove G. Gross June 2006 ASCII 240863 106 security framework cryptographic network

This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. [STANDARDS-TRACK]

 draft-ietf-msec-gsakmp-sec-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4535 RFC4536 The application/smil and application/smil+xml Media Types P. Hoschka July 2006 ASCII 13747 8 synchronized multimedia integration language

This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. This memo provides information for the Internet community.

 draft-hoschka-smil-media-type-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4536 RFC4537 Kerberos Cryptosystem Negotiation Extension L. Zhu P. Leach K. Jaganathan June 2006 ASCII 11166 6

This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. [STANDARDS-TRACK]

 draft-zhu-kerb-enctype-nego-04 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4537 RFC4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) J. Rosenberg June 2006 ASCII 36089 17 tdialog

This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. [STANDARDS-TRACK]

 draft-ietf-sip-target-dialog-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4538 RFC4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF) T. Edwards May 2006 ASCII 11950 6

This document serves to register a media type for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. This memo provides information for the Internet community.

 draft-edwards-mime-mxf-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4539 RFC4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 M. Stiemerling J. Quittek C. Cadar May 2006 ASCII 152685 67 midcom

This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-stiemerling-midcom-simco-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4540 RFC4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches M. Christensen K. Kimball F. Solensky May 2006 ASCII 38555 16 igmpv3 mldv2

This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community.

 draft-ietf-magma-snoop-12 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4541 10.17487/RFC4541 RFC4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite F. Baker J. Polk May 2006 ASCII 99770 42 ieps internet emergency preparedness service call admission control cac phb per hop behavior multi-level precedence and preemption mlpp government emergency telecommunication service gets

RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.

This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.

 draft-ietf-tsvwg-mlpp-that-works-04 RFC5865 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4542 RFC4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH D. McGrew J. Viega May 2006 ASCII 29818 14 encapsulating security payload gcm galois/counter mode authentication header

This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

 draft-mcgrew-aes-gmac-esp-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4543 10.17487/RFC4543 RFC4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) M. Bakke M. Krueger T. McSweeney J. Muchow May 2006 ASCII 156541 83 tcp/ip scsi

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 a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-mib-11 RFC7147 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4544 10.17487/RFC4544 RFC4545 Definitions of Managed Objects for IP Storage User Identity Authorization M. Bakke J. Muchow May 2006 ASCII 87345 43 mib management information base snmp tcp/ip ips-auth-mib

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 user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. [STANDARDS-TRACK]

 draft-ietf-ips-auth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4545 10.17487/RFC4545 RFC4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces D. Raftus E. Cardona June 2006 ASCII 300844 139 cmts cm upstream downstream tdma atdma scdma quality of service channel utilizazation

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). [STANDARDS-TRACK]

 draft-ietf-ipcdn-docs-rfmibv2-14 RFC2670 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4546 RFC4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems A. Ahmad G. Nakanishi June 2006 ASCII 83917 40 snmp simple network management protocol mib smiv2 DOCS-IETF-CABLE-DEVICE-NOTIFICATION-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 a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB.

This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. [STANDARDS-TRACK]

 draft-ietf-ipcdn-docsisevent-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4547 RFC4548 Internet Code Point (ICP) Assignments for NSAP Addresses E. Gray J. Rutemiller G. Swallow May 2006 ASCII 17950 9 network service access point

This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. [STANDARDS-TRACK]

 draft-gray-rfc1888bis-03 RFC1888 RFC4048 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4548 RFC4549 Synchronization Operations for Disconnected IMAP4 Clients A. Melnikov Editor June 2006 ASCII 75417 35 internet message access protocol

This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.

This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.

This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. This memo provides information for the Internet community.

 draft-melnikov-imap-disc-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4549 RFC4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile S. Maes A. Melnikov June 2006 ASCII 48790 23 internet message access protocol,

This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). [STANDARDS-TRACK]

 draft-ietf-lemonade-profile-07 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4550 10.17487/RFC4550 RFC4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization A. Melnikov S. Hole June 2006 ASCII 50265 25 internet mail access protocol

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.

The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.

This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]

 draft-ietf-imapext-condstore-09 RFC7162 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4551 10.17487/RFC4551 RFC4552 Authentication/Confidentiality for OSPFv3 M. Gupta N. Melam June 2006 ASCII 31540 15 open shortest path first authentication header encapsulating security payload ah/esp

This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4552 10.17487/RFC4552 RFC4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) A. Vainshtein Editor YJ. Stein Editor June 2006 ASCII 58141 27 SAToP pseudowires circuit emulation structure-agnostic emulation

This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]

 draft-ietf-pwe3-satop-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4553 10.17487/RFC4553 RFC4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks T. Chown June 2006 ASCII 23355 11 Virtual Local Area Network

Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. This memo provides information for the Internet community.

 draft-ietf-v6ops-vlan-usage-01 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4554 RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE) P. Eronen June 2006 ASCII 78698 33 internet key exchange ipsec internet protocol security vpn virtual private networks

This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. [STANDARDS-TRACK]

 draft-ietf-mobike-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec mobike 10.17487/RFC4555 RFC4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu B. Tung June 2006 ASCII 100339 42

This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK]

 draft-ietf-cat-kerberos-pk-init-34 RFC6112 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4556 10.17487/RFC4556 RFC4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan N. Williams June 2006 ASCII 11593 6

This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]

 draft-ietf-krb-wg-ocsp-for-pkinit-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4557 10.17487/RFC4557 RFC4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement Z. Ali R. Rahman D. Prairie D. Papadimitriou June 2006 ASCII 14185 7 Multi-Protocol Label Switching mpls Generalized Multi-Protocol Label Switching gmpls Traffic Engineering te rsvp-te gr graceful restart

Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]

 draft-ietf-ccamp-rsvp-node-id-based-hello-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4558 RFC4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows K. Jaganathan L. Zhu J. Brezak June 2006 ASCII 16088 8 msie microsoft internet explorer iis internet information services simple and protected negotiate nt lan manager

This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document. This memo provides information for the Internet community.

 draft-jaganathan-kerberos-http-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4559 10.17487/RFC4559 RFC4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations J. Quittek Editor K. White Editor June 2006 ASCII 207956 100 mib management information base DISMAN-PING-MIB DEFINITIONS DISMAN-TRACEROUTE-MIB DEFINITIONS DISMAN-NSLOOKUP-MIB DEFINITIONS

This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.

Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. [STANDARDS-TRACK]

 draft-ietf-disman-remops-mib-v2-09 RFC2925 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC4560 RFC4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object J.-P. Vasseur Editor Z. Ali S. Sivabalan June 2006 ASCII 19362 10 multiprotocol label switching traffic engineering plr point of local repair igp interior gateway protocol as autonomous system abr area border router asbr autonomous system border router

In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK]

 draft-ietf-mpls-nodeid-subobject-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4561 RFC4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network T. Melsen S. Blake June 2006 ASCII 30332 13 Ethernet Access Network ARP DHCP

This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.

The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. This memo provides information for the Internet community.

 draft-melsen-mac-forced-fwd-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4562 RFC4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) E. Carrara V. Lehtovirta K. Norrman June 2006 ASCII 20464 10 security key management multicast broadcast MBMS

This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project. [STANDARDS-TRACK]

 draft-ietf-msec-newtype-keyid-05 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4563 RFC4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) S. Govindan Editor H. Cheng ZH. Yao WH. Zhou L. Yang July 2006 ASCII 64576 32 wlan wireless local area network

This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs. This memo provides information for the Internet community.

 draft-ietf-capwap-objectives-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4564 RFC4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols D. Loher D. Nelson O. Volinsky B. Sarikaya July 2006 ASCII 62929 31

This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005. his memo provides information for the Internet community.

 draft-ietf-capwap-eval-00 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4565 RFC4566 SDP: Session Description Protocol M. Handley V. Jacobson C. Perkins July 2006 ASCII 108820 49 SDP mbone internet multicast backbone multimedia internet addresses syntax

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. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-new-26 RFC2327 RFC3266 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4566 10.17487/RFC4566 RFC4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) J. Arkko F. Lindholm M. Naslund K. Norrman E. Carrara July 2006 ASCII 67693 30 key management protocol multimedia internet keying mikey

This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.

General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. [STANDARDS-TRACK]

 draft-ietf-mmusic-kmgmt-ext-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4567 10.17487/RFC4567 RFC4568 Session Description Protocol (SDP) Security Descriptions for Media Streams F. Andreasen M. Baugher D. Wing July 2006 ASCII 107881 44 srtp secure real-time transport protocol

This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdescriptions-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4568 RFC4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag G. Camarillo July 2006 ASCII 6920 4

This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. This memo provides information for the Internet community.

 draft-ietf-sipping-message-tag-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4569 RFC4570 Session Description Protocol (SDP) Source Filters B. Quinn R. Finlayson July 2006 ASCII 28601 14 internet protocol ip source-filter ssm source-specific multicast

This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-srcfilter-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4570 10.17487/RFC4570 RFC4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport J. Lazzaro July 2006 ASCII 18751 9 TCP-based media transport TCP tunnel transmission control protocol

This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-framing-contrans-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4571 10.17487/RFC4571 RFC4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) J. Lennox July 2006 ASCII 38658 17 setup connection reestablishment

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document extends and updates RFC 4145. [STANDARDS-TRACK]

 draft-ietf-mmusic-comedia-tls-06 RFC4145 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4572 RFC4573 MIME Type Registration for RTP Payload Format for H.224 R. Even A. Lochbaum July 2006 ASCII 13587 7 real time transport protocol itu h.281 h.224 far-end camera control

In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS-TRACK]

 draft-ietf-avt-mime-h224-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4573 RFC4574 The Session Description Protocol (SDP) Label Attribute O. Levin G. Camarillo August 2006 ASCII 13484 8 media level attribute media stream

This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-media-label-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4574 RFC4575 A Session Initiation Protocol (SIP) Event Package for Conference State J. Rosenberg H. Schulzrinne O. Levin Editor August 2006 ASCII 97484 48 conference event package uri uniform resource identifier

This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS-TRACK]

 draft-ietf-sipping-conference-package-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4575 RFC4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII 15149 7 service provider sp provider edge pe

This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]

 draft-ietf-ospf-2547-dnbit-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4576 RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII 61515 25 ce open shortest path first mpls Multiprotocol Label Switching

Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (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. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.

This document updates RFC 4364. [STANDARDS-TRACK]

 draft-ietf-l3vpn-ospf-2547-06 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4577 10.17487/RFC4577 RFC4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) M. Johnston S. Venaas Editor November 2006 ASCII 13238 7 efi extensible firmware interface

We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible Firmware Interface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This memo provides information for the Internet community.

 draft-ietf-dhc-pxe-options-03 INFORMATIONAL INFORMATIONAL IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4578 10.17487/RFC4578 RFC4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents A. Johnston O. Levin August 2006 ASCII 96506 43 ua conference-unaware conference-aware focus

This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-cc-conferencing-07 BCP0119 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4579 RFC4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option B. Volz June 2006 ASCII 10937 6

This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-subid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4580 RFC4581 Cryptographically Generated Addresses (CGA) Extension Field Format M. Bagnulo J. Arkko October 2006 ASCII 7636 4 tlv

This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS-TRACK]

 draft-bagnulo-cga-ext-02 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4581 RFC4582 The Binary Floor Control Protocol (BFCP) G. Camarillo J. Ott K. Drage November 2006 ASCII 154497 65 conference

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. [STANDARDS-TRACK]

 draft-ietf-xcon-bfcp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC4582 RFC4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams G. Camarillo November 2006 ASCII 24150 12 bfcp stream

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. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-bfcp-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4583 10.17487/RFC4583 RFC4584 Extension to Sockets API for Mobile IPv6 S. Chakrabarti E. Nordmark July 2006 ASCII 53995 25 advanced socket api mobility header messages hom address destination routing header type 2 socket applications

This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6.

Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. This memo provides information for the Internet community.

 draft-ietf-mip6-mipext-advapi-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4584 10.17487/RFC4584 RFC4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) J. Ott S. Wenger N. Sato C. Burmeister J. Rey July 2006 ASCII 117762 51 media stream feedback based error audio visual profile

Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-feedback-11 RFC5506 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4585 10.17487/RFC4585 RFC4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations C. Burmeister R. Hakenberg A. Miyazaki J. Ott N. Sato S. Fukunaga July 2006 ASCII 66759 28 Real-time Transport Protocol

This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic. This memo provides information for the Internet community.

 draft-burmeister-avt-rtcp-feedback-sim-06 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4586 10.17487/RFC4586 RFC4587 RTP Payload Format for H.261 Video Streams R. Even August 2006 ASCII 37477 17 RTP-H.261 real-time transport protocol sdp session description protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.

The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.

This specification obsoletes RFC 2032. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2032-bis-13 RFC2032 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4587 10.17487/RFC4587 RFC4588 RTP Retransmission Payload Format J. Rey D. Leon A. Miyazaki V. Varsa R. Hakenberg July 2006 ASCII 76630 35 real time transport protocol rtcp real-time transport control protocol RTP/AVPF

RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-retransmission-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4588 10.17487/RFC4588 RFC4589 Location Types Registry H. Schulzrinne H. Tschofenig July 2006 ASCII 24037 12

This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS-TRACK]

 draft-ietf-geopriv-location-types-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4589 RFC4590 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck July 2006 ASCII 67181 32 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

 draft-ietf-radext-digest-auth-09 RFC5090 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4590 10.17487/RFC4590 RFC4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) M. Townsley G. Wilkie S. Booth S. Bryant J. Lau August 2006 ASCII 28232 14 data link protocols frame encapsulation virtual-circuit creation and deletion status change notification

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual-circuit creation and deletion, and status change notification. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-fr-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4591 10.17487/RFC4591 RFC4592 The Role of Wildcards in the Domain Name System E. Lewis July 2006 ASCII 43991 20 cname

This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]

 draft-ietf-dnsext-wcard-clarify-11 RFC1034 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4592 10.17487/RFC4592 RFC4593 Generic Threats to Routing Protocols A. Barbir S. Murphy Y. Yang October 2006 ASCII 48292 22 threat sources threat capability threat action threat consequences

Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately. This memo provides information for the Internet community.

 draft-ietf-rpsec-routing-threats-07 INFORMATIONAL INFORMATIONAL IETF rtg rpsec 10.17487/RFC4593 RFC4594 Configuration Guidelines for DiffServ Service Classes J. Babiarz K. Chan F. Baker August 2006 ASCII 144044 57 differentiated services code points traffic conditioners per-hop behaviors phb dscp active queue management aqm

This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community.

 draft-ietf-tsvwg-diffserv-service-classes-02 RFC5865 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4594 10.17487/RFC4594 RFC4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol F. Maino D. Black July 2006 ASCII 32268 16 internet key exchange

This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies these IKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel. This memo provides information for the Internet community.

 draft-maino-fcsp-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4595 10.17487/RFC4595 RFC4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension J. Rosenberg P. Kyzivat July 2006 ASCII 82954 40

This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841. This memo provides information for the Internet community.

 draft-ietf-sipping-callerprefs-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4596 10.17487/RFC4596 RFC4597 Conferencing Scenarios R. Even N. Ismail August 2006 ASCII 38428 17 multimedia voice video text interactive text xcon

This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. This memo provides information for the Internet community.

 draft-ietf-xcon-conference-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4597 RFC4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio B. Link July 2006 ASCII 39811 17 encoded audio data multichannel audio coding format

This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-eac3-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4598 RFC4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas August 2006 ASCII 340632 150 PDF 304538 PIM-SM routing message type timers flags

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.

This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]

 draft-ietf-pim-sm-v2-new-12 RFC2362 RFC7761 RFC5059 RFC5796 RFC6226 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=4601 10.17487/RFC4601 RFC4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis T. Pusateri August 2006 ASCII 15310 8

This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard. This memo provides information for the Internet community.

 draft-ietf-pim-proposed-req-02 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC4602 RFC4603 Additional Values for the NAS-Port-Type Attribute G. Zorn G. Weber R. Foltak July 2006 ASCII 7354 5 radius Remote Authentication Dial-In User Service

This document defines a set of values for the NAS-Port-Type RADIUS Attribute. This memo provides information for the Internet community.

 draft-zorn-radius-port-type-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4603 RFC4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast H. Holbrook B. Cain B. Haberman August 2006 ASCII 23370 11 ssm

The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]

 draft-holbrook-idmr-igmpv3-ssm-08 RFC3376 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC4604 RFC4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") B. Fenner H. He B. Haberman H. Sandick August 2006 ASCII 25558 12

In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. [STANDARDS-TRACK]

 draft-ietf-magma-igmp-proxy-06 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4605 10.17487/RFC4605 RFC4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou August 2006 ASCII 53492 25

This document provides minor clarification to RFC 3946.

This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc3946bis-01 RFC3946 RFC6344 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4606 10.17487/RFC4606 RFC4607 Source-Specific Multicast for IP H. Holbrook B. Cain August 2006 ASCII 42990 19 ipv4 ssm ipv6

IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]

 draft-ietf-ssm-arch-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ssm http://www.rfc-editor.org/errata_search.php?rfc=4607 10.17487/RFC4607 RFC4608 Source-Specific Protocol Independent Multicast in 232/8 D. Meyer R. Rockell G. Shepherd August 2006 ASCII 15030 7 ip ssm

IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-ssm232-08 BCP0120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4608 RFC4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements P. Savola R. Lehtonen D. Meyer October 2006 ASCII 49812 23 security threats intra-domain inter-domain any-source multicast asm source-specific multicast ssm embedded rendezvous point embedded-rp

This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. This memo provides information for the Internet community.

 draft-ietf-mboned-mroutesec-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC4609 RFC4610 Anycast-RP Using Protocol Independent Multicast (PIM) D. Farinacci Y. Cai August 2006 ASCII 22490 12 rendezvous point rp msdp register multicast source discovery register-stop

This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]

 draft-ietf-pim-anycast-rp-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC4610 RFC4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios M. McBride J. Meylor D. Meyer August 2006 ASCII 33230 14 pim-sm protocol independent multicast sparse mode

This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-msdp-deploy-06 BCP0121 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4611 RFC4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration P. Jones H. Tamura August 2006 ASCII 15675 8 itu-t recommendation t.38 sdp session description protocol

This document defines the MIME sub-type audio/t38. The usage of this MIME type, which is intended for use within Session Description Protocol (SDP), is specified within ITU-T Recommendation T.38. This memo defines a Historic Document for the Internet community.

 draft-jones-avt-audio-t38-05 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4612 10.17487/RFC4612 RFC4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI) P. Frojdh U. Lindgren M. Westerlund September 2006 ASCII 12263 6 dls

This document serves to register a media type for Downloadable Sounds. This memo provides information for the Internet community.

 draft-westerlund-mime-dls-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4613 RFC4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton September 2006 ASCII 75645 33

This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This memo provides information for the Internet community.

 draft-ietf-tcpm-tcp-roadmap-06 RFC7414 RFC6247 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4614 RFC4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) J. Song R. Poovendran J. Lee T. Iwata August 2006 ASCII 13312 7 ipsec ip security pseudo-random function

Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES). This memo describes such an algorithm, called AES-CMAC-PRF-128. It supports fixed and variable key sizes. [STANDARDS-TRACK]

 draft-songlee-aes-cmac-prf-128-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4615 RFC4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga Editor August 2006 ASCII 20270 11 data confidentiality

This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]

 draft-ietf-sasl-plain-09 RFC2595 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4616 10.17487/RFC4616 RFC4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project J. Kornijenko August 2006 ASCII 12934 8 general contractor Olimps LTD subcontractors ABC software LTD Microsoft Latvia LTD Riga Internet eXchange Technologies LTD RIX Microlink LTD

This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian National Government Integration Project (Latvian abbreviation IVIS). This memo provides information for the Internet community.

 draft-kornijenko-ivis-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4617 RFC4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks L. Martini E. Rosen G. Heron A. Malis September 2006 ASCII 33141 16 pw pseudowire point to point protocol pdu packet data unit

A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire. [STANDARDS-TRACK]

 draft-ietf-pwe3-hdlc-ppp-encap-mpls-09 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4618 RFC4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks L. Martini Editor C. Kawa Editor A. Malis Editor September 2006 ASCII 38193 19 pseudowire psn packet switched network pw

A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. [STANDARDS-TRACK]

 draft-ietf-pwe3-frame-relay-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4619 10.17487/RFC4619 RFC4620 IPv6 Node Information Queries M. Crawford B. Haberman Editor August 2006 ASCII 31134 14 internet protocol version 6

This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipngwg-icmp-name-lookups-15 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 10.17487/RFC4620 RFC4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol T. Kivinen H. Tschofenig August 2006 ASCII 73070 30 internet key exchange

The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).

This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. This memo provides information for the Internet community.

 draft-ietf-mobike-design-08 INFORMATIONAL INFORMATIONAL IETF sec mobike 10.17487/RFC4621 RFC4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre July 2006 ASCII 49968 23 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

 draft-saintandre-xmpp-iri-04 RFC5122 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4622 RFC4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly A. Malis M. Townsley August 2006 ASCII 36369 17

This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]

 draft-ietf-pwe3-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4623 10.17487/RFC4623 RFC4624 Multicast Source Discovery Protocol (MSDP) MIB B. Fenner D. Thaler October 2006 ASCII 58759 32 management information base MSDP-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mboned-msdp-mib-01 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC4624 RFC4625 Fibre Channel Routing Information MIB C. DeSanti K. McCloghrie S. Kode S. Gai September 2006 ASCII 41278 22 management information base T11-FC-ROUTE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. [STANDARDS-TRACK]

 draft-ietf-imss-fc-rtm-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4625 RFC4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol C. DeSanti V. Gaonkar K. McCloghrie S. Gai September 2006 ASCII 67953 36 management information base T11-FC-FSPF-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fspf-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4626 RFC4627 The application/json Media Type for JavaScript Object Notation (JSON) D. Crockford July 2006 ASCII 16319 10 data interchange format ECMAScript Programming Language Standard

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.

 draft-crockford-jsonorg-json-04 RFC7159 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4627 10.17487/RFC4627 RFC4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status R. Even January 2007 ASCII 8084 5 real-time transport protocol itu-t itu telecommunication standardization sector transfer

The first RFC that describes RTP payload format for ITU Telecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status. This memo provides information for the Internet community.

 draft-ietf-avt-rfc2190-to-historic-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4628 RFC4629 RTP Payload Format for ITU-T Rec. H.263 Video J. Ott C. Bormann G. Sullivan S. Wenger R. Even Editor January 2007 ASCII 67231 29 real-time transport protocol multicast unicast sdp session description protocol

This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.

The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.

The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2429-bis-09 RFC2429 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4629 RFC4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley S. Santesson August 2006 ASCII 12539 6 utf8string printablestring

This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding. The requirement for exclusive use of UTF8String after December 31, 2003 is removed. [STANDARDS-TRACK]

 draft-ietf-pkix-cert-utf8-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4630 RFC4631 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis A. Farrel September 2006 ASCII 152560 83 lmp-mib

This document provides minor corrections to and obsoletes RFC 4327.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc4327bis-01 RFC4327 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4631 10.17487/RFC4631 RFC4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan V. Fuller T. Li August 2006 ASCII 66944 27 CIDR-STRA global routing state

This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-rfc1519bis-04 RFC1519 BCP0122 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4632 10.17487/RFC4632 RFC4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists S. Hartman August 2006 ASCII 14979 7

Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. This memo defines an Experimental Protocol for the Internet community.

 draft-hartman-mailinglist-experiment-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4633 RFC4634 US Secure Hash Algorithms (SHA and HMAC-SHA) D. Eastlake 3rd T. Hansen July 2006 ASCII 197147 108 fips federal information processing standard sha-224 sha-256 sha-384 sha-512

The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2.

Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.

 draft-eastlake-sha2-02 RFC6234 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4634 10.17487/RFC4634 RFC4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers D. Eastlake 3rd August 2006 ASCII 16533 8 dns resource record rr cryptographic message authentication code cmac

Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. [STANDARDS-TRACK]

 draft-ietf-dnsext-tsig-sha-06 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4635 10.17487/RFC4635 RFC4636 Foreign Agent Error Extension for Mobile IPv4 C. Perkins October 2006 ASCII 11663 6 internet protocol

This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. [STANDARDS-TRACK]

 draft-ietf-mip4-faerr-02 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4636 10.17487/RFC4636 RFC4637 RFC4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) P. Arberg D. Kourkouzelis M. Duckett T. Anschutz J. Moisand September 2006 ASCII 18984 9

The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks. This memo provides information for the Internet community.

 draft-arberg-pppoe-mtu-gt1492-03 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC4638 RFC4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems R. Woundy K. Marez December 2006 ASCII 188220 88 snmp simple network management 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 a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.

This memo obsoletes RFC 2669. [STANDARDS-TRACK]

 draft-ietf-ipcdn-device-mibv2-11 RFC2669 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4639 RFC4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6) A. Patel Editor G. Giaretta Editor September 2006 ASCII 49926 22 internet protocol version 6 mobile node

A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping. This memo provides information for the Internet community.

 draft-ietf-mip6-bootstrap-ps-05 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4640 10.17487/RFC4640 RFC4641 DNSSEC Operational Practices O. Kolkman R. Gieben September 2006 ASCII 79894 35 dns domain name space security extensions zone administrator DNS-SOC cryptology resource records rrs

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 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.

 draft-ietf-dnsop-dnssec-operational-practices-08 RFC2541 RFC6781 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4641 10.17487/RFC4641 RFC4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) K. Murchison J. Vinocur C. Newman October 2006 ASCII 29366 14 encryption single link confidentiality

This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS-TRACK]

 draft-ietf-nntpext-tls-nntp-09 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4642 10.17487/RFC4642 RFC4643 Network News Transfer Protocol (NNTP) Extension for Authentication J. Vinocur K. Murchison October 2006 ASCII 51411 24 authinfo user/pass authinfo simple authinfo generic sasl simple authentication and security layer

This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.

This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. [STANDARDS-TRACK]

 draft-ietf-nntpext-authinfo-10 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4643 10.17487/RFC4643 RFC4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds J. Vinocur K. Murchison October 2006 ASCII 26439 14 check takethis mode stream

This memo defines an extension to the Network News Transfer Protocol (NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.

This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]

 draft-ietf-nntpext-streaming-06 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4644 10.17487/RFC4644 RFC4645 Initial Language Subtag Registry D. Ewell September 2006 ASCII 15517 7 iana

This memo defined the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion. This memo provides information for the Internet community.

 draft-ietf-ltru-initial-06 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC4645 RFC4646 Tags for Identifying Languages A. Phillips M. Davis September 2006 ASCII 135810 59 Lang-Tag

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ltru-registry-14 RFC3066 RFC5646 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru http://www.rfc-editor.org/errata_search.php?rfc=4646 10.17487/RFC4646 RFC4647 Matching of Language Tags A. Phillips M. Davis September 2006 ASCII 45595 20 Lang-Tag

This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ltru-matching-15 RFC3066 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru 10.17487/RFC4647 RFC4648 The Base16, Base32, and Base64 Data Encodings S. Josefsson October 2006 ASCII 35491 18 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]

 draft-josefsson-rfc3548bis-04 RFC3548 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4648 10.17487/RFC4648 RFC4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option B. Volz August 2006 ASCII 10940 6

This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-remoteid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4649 RFC4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) M. Euchner September 2006 ASCII 63016 27 Multicast security MIKEY key management Diffie-Hellman key agreement HMAC

This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY. [STANDARDS-TRACK]

 draft-ietf-msec-mikey-dhhmac-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4650 10.17487/RFC4650 RFC4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization C. Vogt J. Arkko February 2007 ASCII 79226 31 Mobile IPv6 Route Optimization Enhancement Mobility Handoff IP Address Tests Protected Tunnels Optimistic Behavior Proactive IP Address Tests Concurrent Care-of Address Tests Diverted Routing Credit-Based Authorization Heuristic Monitoring Crypto-Based Identifiers Pre-Configuration Semi-Permanent Security Associations Delegation Mobile Networks Location Privacy

This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo provides information for the Internet community.

 draft-irtf-mobopts-ro-enhancements-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4651 RFC4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements D. Papadimitriou Editor L.Ong J. Sadler S. Shew D. Ward October 2006 ASCII 47179 22 gmpls generalized multiprotocol label switching otn optical transport networks sonet sdh synchronous optical network synchronous digital hierarchy itu-t

The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs).

This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-routing-eval-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4652 RFC4653 Improving the Robustness of TCP to Non-Congestion Events S. Bhandarkar A. L. N. Reddy M. Allman E. Blanton August 2006 ASCII 42268 18 ncr non-congestion robustness transmission control protocol

This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-tcp-dcr-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=4653 10.17487/RFC4653 RFC4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification J. Widmer M. Handley August 2006 ASCII 72190 32 streaming media multicase ip internet protocol

This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-tfmcc-07 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=4654 10.17487/RFC4654 RFC4655 A Path Computation Element (PCE)-Based Architecture A. Farrel J.-P. Vasseur J. Ash August 2006 ASCII 97561 40 traffic engineering

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. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.

This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.

 draft-ietf-pce-architecture-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4655 RFC4656 A One-way Active Measurement Protocol (OWAMP) S. Shalunov B. Teitelbaum A. Karp J. Boote M. Zekauskas September 2006 ASCII 132303 56 unidirectional characteristics one-way gps cdma

The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]

 draft-ietf-ippm-owdp-16 RFC7717 RFC7718 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4656 RFC4657 Path Computation Element (PCE) Communication Protocol Generic Requirements J. Ash Editor J.L. Le Roux Editor September 2006 ASCII 45284 21 pce architecture pcc path computation client

The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community.

 draft-ietf-pce-comm-protocol-gen-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4657 RFC4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN J. De Clercq D. Ooms M. Carugi F. Le Faucheur September 2006 ASCII 42090 18 service provider border gateway protocol multiprotocol label switching

This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".

This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK]

 draft-ietf-l3vpn-bgp-ipv6-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4659 10.17487/RFC4659 RFC4660 Functional Description of Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII 63886 31 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.

This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. [STANDARDS-TRACK]

 draft-ietf-simple-event-filter-funct-05 RFC6665 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4660 10.17487/RFC4660 RFC4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII 48890 24 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. [STANDARDS-TRACK]

 draft-ietf-simple-filter-format-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4661 10.17487/RFC4661 RFC4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists A. B. Roach B. Campbell J. Rosenberg August 2006 ASCII 82778 39

This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. [STANDARDS-TRACK]

 draft-ietf-simple-event-list-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4662 10.17487/RFC4662 RFC4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG D. Harrington September 2006 ASCII 47973 22 management information base

This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage. This memo provides information for the Internet community.

 draft-harrington-8021-mib-transition-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4663 RFC4664 Framework for Layer 2 Virtual Private Networks (L2VPNs) L. Andersson Editor E. Rosen Editor September 2006 ASCII 97768 44

This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community.

 draft-ietf-l2vpn-l2-framework-05 INFORMATIONAL INFORMATIONAL IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4664 10.17487/RFC4664 RFC4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks W. Augustyn Editor Y. Serbest Editor September 2006 ASCII 68972 32 l2vpn ppvpn virtual private wire service vpws virtual private lan service vpls

This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives. This memo provides information for the Internet community.

 draft-ietf-l2vpn-requirements-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC4665 RFC4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) K. Morneault Editor J. Pastor-Balbas Editor September 2006 ASCII 292991 124 mtp isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway

This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332. [STANDARDS-TRACK]

 draft-ietf-sigtran-rfc3332bis-06 RFC3332 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4666 10.17487/RFC4666 RFC4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) W. Luo September 2006 ASCII 33166 15 L2VPN L2TP L2TPv3 pseudowire forwarder

The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion. [STANDARDS-TRACK]

 draft-ietf-l2tpext-l2vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4667 RFC4668 RADIUS Authentication Client MIB for IPv6 D. Nelson August 2006 ASCII 48252 24 management information base security remote access dialin user service RADIUS-AUTH-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients.

This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

 draft-ietf-radext-rfc2618bis-04 RFC2618 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4668 10.17487/RFC4668 RFC4669 RADIUS Authentication Server MIB for IPv6 D. Nelson August 2006 ASCII 50525 25 management information base security remote access dialin user service RADIUS-AUTH-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers.

This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

 draft-ietf-radext-rfc2619bis-04 RFC2619 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4669 10.17487/RFC4669 RFC4670 RADIUS Accounting Client MIB for IPv6 D. Nelson August 2006 ASCII 44667 23 management information base security remote access dialin user service RADIUS-ACC-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients.

This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

 draft-ietf-radext-rfc2620bis-04 RFC2620 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4670 10.17487/RFC4670 RFC4671 RADIUS Accounting Server MIB for IPv6 D. Nelson August 2006 ASCII 47694 24 management information base security remote access dialin user service RADIUS-ACC-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers.

This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

 draft-ietf-radext-rfc2621bis-04 RFC2621 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4671 10.17487/RFC4671 RFC4672 RADIUS Dynamic Authorization Client MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII 50817 24 remote authentication dial-in user service dac dynamic authorization client RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS management information base

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 the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

 draft-ietf-radext-dynauth-client-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4672 10.17487/RFC4672 RFC4673 RADIUS Dynamic Authorization Server MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII 47635 24 management information base remote authentication dial-in user service RADIUS-DYNAUTH-SERVER-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 the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

 draft-ietf-radext-dynauth-server-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4673 10.17487/RFC4673 RFC4674 Requirements for Path Computation Element (PCE) Discovery J.L. Le Roux Editor October 2006 ASCII 40321 19 path computation client pcc

This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. This memo provides information for the Internet community.

 draft-ietf-pce-discovery-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4674 RFC4675 RADIUS Attributes for Virtual LAN and Priority Support P. Congdon M. Sanchez B. Aboba September 2006 ASCII 29751 15 remote authentication dial-in user service local area network

This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS or Diameter. [STANDARDS-TRACK]

 draft-ietf-radext-vlan-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4675 10.17487/RFC4675 RFC4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne October 2006 ASCII 45208 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

 draft-ietf-geopriv-dhcp-civil-09 RFC4776 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4676 10.17487/RFC4676 RFC4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force P. Hoffman S. Harris September 2006 ASCII 127383 50 meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. This memo provides information for the Internet community.

 draft-hoffman-taobis-08 RFC3160 RFC6722 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4677 10.17487/RFC4677 RFC4678 Server/Application State Protocol v1 A. Bivens September 2006 ASCII 102713 48 sasp server/application state protocol

Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. This memo provides information for the Internet community.

 draft-bivens-sasp-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4678 10.17487/RFC4678 RFC4679 DSL Forum Vendor-Specific RADIUS Attributes V. Mammoliti G. Zorn P. Arberg R. Rennison September 2006 ASCII 42743 25 remote authentication dial-in user service vsa dsl digital subscriber line

This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum.

These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. This memo provides information for the Internet community.

 draft-mammoliti-radius-dsl-vsa-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4679 10.17487/RFC4679 RFC4680 TLS Handshake Message for Supplemental Data S. Santesson October 2006 ASCII 15602 9 transport layer security

This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]

 draft-santesson-tls-supp-02 RFC4346 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4680 RFC4681 TLS User Mapping Extension S. Santesson A. Medvinsky J. Ball October 2006 ASCII 20682 11 transport layer security handshake message upndomainhint

This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. [STANDARDS-TRACK]

 draft-santesson-tls-ume-07 RFC4346 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4681 RFC4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices E. Nechamkin J-F. Mule December 2006 ASCII 137373 60 mib snmp simple network management protocol PKTC-IETF-MTA-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 a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

 draft-ietf-ipcdn-pktc-mtamib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4682 RFC4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) J. Park J. Lee H.. Lee S. Park T. Polk October 2006 ASCII 41285 20 subjectaltname privacy-sensitive identifiers pepsi

This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.

The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. [STANDARDS-TRACK]

 draft-ietf-pkix-sim-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4683 10.17487/RFC4683 RFC4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) P. Marques R. Bonica L. Fang L. Martini R. Raszuk K. Patel J. Guichard November 2006 ASCII 28474 14 mp-bgp bgp speakers route target

This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364. [STANDARDS-TRACK]

 draft-ietf-l3vpn-rt-constrain-02 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4684 10.17487/RFC4684 RFC4685 Atom Threading Extensions J. Snell September 2006 ASCII 24403 12 atom syndication format extension threading syndication

This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. [STANDARDS-TRACK]

 draft-snell-atompub-feed-thread-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4685 RFC4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) J. Fenton September 2006 ASCII 70382 29 email attack authentication signature ssp

This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. This memo provides information for the Internet community.

 draft-ietf-dkim-threats-03 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC4686 RFC4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks S. Yasukawa A. Farrel D. King T. Nadeau September 2006 ASCII 30486 14 multiprotocol label switching pwmp lsp p2mp mpls lsp

Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.

For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.

This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.

 draft-ietf-mpls-p2mp-oam-reqs-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4687 RFC4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D S. Rushing October 2006 ASCII 13255 8

This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. This memo provides information for the Internet community.

 draft-rushing-s1000d-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4688 RFC4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms S. Poretsky J. Perser S. Erramilli S. Khurana October 2006 ASCII 62369 34 packet classification

This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number. This memo provides information for the Internet community.

 draft-ietf-bmwg-dsmterm-13 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4689 RFC4690 Review and Recommendations for Internationalized Domain Names (IDNs) J. Klensin P. Faltstrom C. Karp IAB September 2006 ASCII 100929 37 dns domain namespace idna internationalizing domain names in applications

This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.

 draft-iab-idn-nextsteps-06 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4690 10.17487/RFC4690 RFC4691 Guidelines for Acting as an IETF Liaison to Another Organization L. Andersson Editor October 2006 ASCII 33888 14 internet engineering task force sdo standards development organization consortium industrial forum

Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. This memo provides information for the Internet community.

 draft-iab-liaison-guidelines-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4691 RFC4692 Considerations on the IPv6 Host Density Metric G. Huston October 2006 ASCII 41357 17 internet protocol version 6 ipv6 unicast address blocks

This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches. This memo provides information for the Internet community.

 draft-huston-hd-metric-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4692 RFC4693 IETF Operational Notes H. Alvestrand October 2006 ASCII 19268 10 ION

This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.

It proposes to establish this series as an RFC 3933 process experiment. This memo defines an Experimental Protocol for the Internet community.

 draft-alvestrand-ipod-03 RFC6393 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4693 RFC4694 Number Portability Parameters for the "tel" URI J. Yu October 2006 ASCII 36910 15 uniform resource identifier np

This document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. [STANDARDS-TRACK]

 draft-ietf-iptel-tel-np-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4694 RFC4695 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII 403808 169 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4-generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtp-midi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-midi-format-15 RFC6295 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4695 10.17487/RFC4695 RFC4696 An Implementation Guide for RTP MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII 83827 38 checkpoint packet checkpoint history guard packets jitter keep-alive packets MIDI musical telepresence network musical performance NMP receiving algorithm recovery journal recovery journal receiving structure recovery journal sending structure RTP RTP MIDI queuing MIDI sending algorithm sending MIDI telepresence

This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-midi-guidelines-15 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4696 10.17487/RFC4696 RFC4697 Observed DNS Resolution Misbehavior M. Larson P. Barber October 2006 ASCII 45187 18 domain name system tld top level domain

This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-bad-dns-res-06 BCP0123 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC4697 RFC4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service E. Gunduz A. Newton S. Kerr October 2006 ASCII 89932 48 ip address autonomous system number internet protocol address

This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-areg-15 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4698 10.17487/RFC4698 RFC4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) M. Stapp T. Lemon A. Gustafsson October 2006 ASCII 24570 12 dns fqdn fully qualified domain name

It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. [STANDARDS-TRACK]

 draft-ietf-dnsext-dhcid-rr-13 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4701 10.17487/RFC4701 RFC4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option M. Stapp B. Volz Y. Rekhter October 2006 ASCII 37534 17 dhcpv4 dns rr

This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK]

 draft-ietf-dhc-fqdn-option-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4702 RFC4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients M. Stapp B. Volz October 2006 ASCII 29690 13 dynamic assignment dns dhcid dns rr

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. [STANDARDS-TRACK]

 draft-ietf-dhc-ddns-resolution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4703 RFC4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option B. Volz October 2006 ASCII 32359 15 dns rr

This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-fqdn-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4704 RFC4705 GigaBeam High-Speed Radio Link Encryption R. Housley A. Corry October 2006 ASCII 30926 15 key management wifiber radio link

This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities. This memo provides information for the Internet community.

 draft-housley-gigabeam-radio-link-encrypt-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4705 10.17487/RFC4705 RFC4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) M. Morgenstern M. Dodge S. Baillie U. Bonollo November 2006 ASCII 347648 167 mib management information base adsl2+ ADSL2-LINE-TC-MIB ADSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Asymmetric Digital Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their variants. [STANDARDS-TRACK]

 draft-ietf-adslmib-adsl2-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4706 RFC4707 Netnews Administration System (NAS) P. Grau V. Heinau H. Schlichting R. Schuettler October 2006 ASCII 86510 49 news servers news administrator news reader

The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.

The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.

NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS-compliant software. This memo defines an Experimental Protocol for the Internet community.

 draft-dfncis-netnews-admin-sys-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4707 RFC4708 CellML Media Type A. Miller October 2006 ASCII 13217 7 media format mathematical model mathematical modelling mathematical modeling content MathML markup languages bioengineering biology

This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language. This memo provides information for the Internet community.

 draft-miller-media-type-cellml-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4708 RFC4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers J. Reschke October 2006 ASCII 23672 15 drag-and-drop

In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a Web Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.

This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. This memo provides information for the Internet community.

 draft-reschke-webdav-mount-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4709 RFC4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII 86403 36 internet protocol end-devices qos quality of service snmp simple network management protocol

There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. [STANDARDS-TRACK]

 draft-ietf-rmonmib-raqmon-framework-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4710 RFC4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII 77341 38 management information base remote monitoring mib qos RAQMON-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB, RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. [STANDARDS-TRACK]

 draft-ietf-rmonmib-raqmon-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4711 RFC4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) A. Siddiqui D. Romascanu E. Golovinsky M. Rahman,Y. Kim October 2006 ASCII 109407 48 mib management information base snmp simple network management protocol rds raqmon data source qos RAQMON-RDS-MIB

This memo specifies two transport mappings of the \%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). [STANDARDS-TRACK]

 draft-ietf-rmonmib-raqmon-pdu-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4712 RFC4713 Registration and Administration Recommendations for Chinese Domain Names X. Lee W. Mao E. Chen N. Hsu J. Klensin October 2006 ASCII 18883 9 cdn sc simplified chinese tc traditional chinese

Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms. The equivalence between Simplified Chinese (SC) and Traditional Chinese (TC) characters is very important for CDN registration. This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names. The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese. This memo provides information for the Internet community.

 draft-xdlee-idn-cdnadmin-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4713 RFC4714 Requirements for IETF Technical Publication Service A. Mankin S. Hayes October 2006 ASCII 53988 24 internet engineering task force

The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. This memo provides information for the Internet community.

 draft-mankin-pub-req-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4714 RFC4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI M. Munakata S. Schubert T. Ohba November 2006 ASCII 28910 14 uniform resource identifier isup isdn user part

Without a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. This memo provides information for the Internet community.

 draft-munakata-iptel-isub-type-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4715 RFC4716 The Secure Shell (SSH) Public Key File Format J. Galbraith R. Thayer November 2006 ASCII 18395 10

This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations.

In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.

 draft-ietf-secsh-publickeyfile-13 INFORMATIONAL INFORMATIONAL IETF sec secsh 10.17487/RFC4716 RFC4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks L. Martini J. Jayakumar M. Bocci N. El-Aawar J. Brayley G. Koleyni December 2006 ASCII 86173 40 pw pseudowire multiprotocol label switching

An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry ATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service. [STANDARDS-TRACK]

 draft-ietf-pwe3-atm-encap-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4717 10.17487/RFC4717 RFC4718 IKEv2 Clarifications and Implementation Guidelines P. Eronen P. Hoffman October 2006 ASCII 129982 58 internet key exchange

This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. This memo provides information for the Internet community.

 draft-eronen-ipsec-ikev2-clarifications-09 RFC5996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4718 10.17487/RFC4718 RFC4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) R. Aggarwal Editor M. Townsley Editor M. Dos Santos Editor November 2006 ASCII 30764 14 port-to-port vlan

This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-ethernet-09 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4719 10.17487/RFC4719 RFC4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention A. Malis D. Allan N. Del Regno November 2006 ASCII 18248 9 fcs

This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires. [STANDARDS-TRACK]

 draft-ietf-pwe3-fcs-retention-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4720 RFC4721 Mobile IPv4 Challenge/Response Extensions (Revised) C. Perkins P. Calhoun J. Bharatia January 2007 ASCII 60386 26 chap

Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as Challenge Handshake Authentication Protocol (CHAP)) for authenticating portable computer devices.

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.

Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. [STANDARDS-TRACK]

 draft-ietf-mip4-rfc3012bis-05 RFC3012 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4721 10.17487/RFC4721 RFC4722 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer November 2006 ASCII 184055 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

 draft-vandyke-mscml-09 RFC5022 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4722 RFC4723 Registration of Media Type audio/mobile-xmf T. Kosonen T. White December 2006 ASCII 12652 8 mma midi manufacturers association association of musical electronices industry amei MIDI Musical Instrument Digital Interface

The MIDI Manufacturers Association (MMA) and the Association of Musical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications. Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration. This document registers the media type audio/mobile-xmf. This memo provides information for the Internet community.

 draft-kosonen-mobile-xmf-mediatype-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4723 RFC4724 Graceful Restart Mechanism for BGP S. Sangli E. Chen R. Fernando J. Scudder Y. Rekhter January 2007 ASCII 32343 15 border gateway protocol end-of-rib bgp restart

This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.

The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK]

 draft-ietf-idr-restart-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4724 10.17487/RFC4724 RFC4725 ENUM Validation Architecture A. Mayrhofer B. Hoeneisen November 2006 ASCII 33216 17 E.164 Registry Registrar Registrant Assignee

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure. This memo provides information for the Internet community.

 draft-ietf-enum-validation-arch-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC4725 RFC4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering A. Farrel J.-P. Vasseur A. Ayyangar November 2006 ASCII 53076 22 mpls mpls-te te lsp label switched path

This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.

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). This memo provides information for the Internet community.

 draft-ietf-ccamp-inter-domain-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4726 RFC4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers B. Fenner November 2006 ASCII 19745 11

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]

 draft-fenner-iana-exp-2780-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4727 RFC4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 D. Johnson Y. Hu D. Maltz February 2007 ASCII 265706 107 route discovery route maintenance

The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and "Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness. Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-dsr-10 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=4728 10.17487/RFC4728 RFC4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum M. Abel November 2006 ASCII 13423 7 forum technical committee

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) resources published by the Near Field Communication (NFC) Forum. The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFC Forum Technical Committee. This memo provides information for the Internet community.

 draft-abel-nfc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4729 RFC4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) E. Burger M. Dolly November 2006 ASCII 120186 56 ua user agent dtmf dual tone multi-frequency

This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). [STANDARDS-TRACK]

 draft-ietf-sipping-kpml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4730 10.17487/RFC4730 RFC4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned A. Melnikov D. Cridland November 2006 ASCII 15431 6 uid search uid

This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK]

 draft-melnikov-imap-search-ret-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4731 RFC4732 Internet Denial-of-Service Considerations M. Handley Editor E. Rescorla Editor IAB December 2006 ASCII 91844 38 dos

This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.

 draft-iab-dos-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4732 RFC4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII 115614 49 real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.

This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.

This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2833bis-15 RFC2833 RFC4734 RFC5244 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4733 10.17487/RFC4733 RFC4734 Definition of Events for Modem, Fax, and Text Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII 116810 47 real-time application protocol DTMF dual-tone multifrequency

This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2833bisdata-08 RFC2833 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4734 RFC4735 Example Media Types for Use in Documentation T. Taylor October 2006 ASCII 9951 6 media type example

This document is registration for the 'example' media type and 'example' subtypes within the standards tree. The 'example/*' and '*/example' media types are defined for documentation purposes only. [STANDARDS-TRACK]

 draft-taylor-types-example-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4735 RFC4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) JP. Vasseur Editor Y. Ikejiri R. Zhang November 2006 ASCII 28850 14 rsvp-te te lsp path

This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community.

 draft-ietf-ccamp-loose-path-reopt-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4736 RFC4737 Packet Reordering Metrics A. Morton L. Ciavattone G. Ramachandran S. Shalunov J. Perser November 2006 ASCII 94699 45 ippm

This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An appendix gives extended definitions for evaluating order with packet fragmentation. [STANDARDS-TRACK]

 draft-ietf-ippm-reordering-13 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4737 RFC4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) D. Ignjatic L. Dondeti F. Audet P. Lin November 2006 ASCII 43015 19 MIKEY SRTP key management group key distribution RSA-R

The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally a Diffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder's ID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode. [STANDARDS-TRACK]

 draft-ietf-msec-mikey-rsa-r-07 RFC3830 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4738 RFC4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol P. Eronen J. Korhonen November 2006 ASCII 22704 11

The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. This memo defines an Experimental Protocol for the Internet community.

 draft-eronen-ipsec-ikev2-multiple-auth-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4739 RFC4740 Diameter Session Initiation Protocol (SIP) Application M. Garcia-Martin Editor M. Belinchon M. Pallares-Lopez C. Canales-Valenzuela K. Tammi November 2006 ASCII 174175 72 authentication authorization diameter client

This document specifies the Diameter Session Initiation Protocol (SIP) application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-sip-app-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4740 10.17487/RFC4740 RFC4741 NETCONF Configuration Protocol R. Enns Editor December 2006 ASCII 173914 95 network configuration protocol network device xml extensible markup language rpc remote procedure call

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS-TRACK]

 draft-ietf-netconf-prot-12 RFC6241 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4741 10.17487/RFC4741 RFC4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH) M. Wasserman T. Goddard December 2006 ASCII 17807 10 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS-TRACK]

 draft-ietf-netconf-ssh-06 RFC6242 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4742 10.17487/RFC4742 RFC4743 Using NETCONF over the Simple Object Access Protocol (SOAP) T. Goddard December 2006 ASCII 39734 20 NETCONF XMLCONF SOAP device managment XML Extensible Markup Language

The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]

 draft-ietf-netconf-soap-08 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4743 RFC4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) E. Lear K. Crozier December 2006 ASCII 19287 10 XML Configuration Network Management Extensible Markup Language

This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]

 draft-ietf-netconf-beep-10 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4744 RFC4745 Common Policy: A Document Format for Expressing Privacy Preferences H. Schulzrinne H. Tschofenig J. Morris J. Cuellar J. Polk J. Rosenberg February 2007 ASCII 63602 32 rules conditions permissions

This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. [STANDARDS-TRACK]

 draft-ietf-geopriv-common-policy-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4745 10.17487/RFC4745 RFC4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange T. Clancy W. Arbaugh November 2006 ASCII 63471 30 EAP-PAX password authenticated exchange key exchange

This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange. This memo provides information for the Internet community.

 draft-clancy-eap-pax-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4746 10.17487/RFC4746 RFC4747 The Virtual Fabrics MIB S. Kipp G. Ramkumar K. McCloghrie November 2006 ASCII 39034 20 management information base T11-FC-VIRTUAL-FABRIC-MIB fibre channel network virtual fabric

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabrics function. [STANDARDS-TRACK]

 draft-ietf-imss-fc-vf-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4747 10.17487/RFC4747 RFC4748 RFC 3978 Update to Recognize the IETF Trust S. Bradner Editor October 2006 ASCII 7284 4 ipr intellectual property rights copyright

This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights.

This document does not constrain how the IETF Trust exercises those rights. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-ietf-trust-update-03 RFC5378 RFC3978 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4748 RFC4749 RTP Payload Format for the G.729.1 Audio Codec A. Sollaud October 2006 ASCII 28838 14 real-time transport protocol itu-t international telecommunication union

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g729-scal-wb-ext-07 RFC5459 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4749 RFC4750 OSPF Version 2 Management Information Base D. Joyal Editor P. Galecki Editor S. Giacalone Editor R. Coltun F. Baker December 2006 ASCII 222459 121 OSPF-MIB Open Shortest Path First SPF MIB routing network management mib OSPF-MIB OSPF-TRAP-MIB

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 version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family.

This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B. [STANDARDS-TRACK]

 draft-ietf-ospf-mib-update-11 RFC1850 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4750 10.17487/RFC4750 RFC4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism A. Melnikov Editor November 2006 ASCII 22133 10 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL.

This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. [STANDARDS-TRACK]

 draft-ietf-sasl-gssapi-08 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4752 10.17487/RFC4752 RFC4753 ECP Groups For IKE and IKEv2 D. Fu J. Solinas January 2007 ASCII 28760 16 elliptic curve Diffie-Hellman suite b nist curve

This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This memo provides information for the Internet community.

 draft-ietf-ipsec-ike-ecp-groups-03 RFC5903 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4753 10.17487/RFC4753 RFC4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) D. Fu J. Solinas January 2007 ASCII 27948 15 suite b

This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK]

 draft-ietf-ipsec-ike-auth-ecdsa-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4754 10.17487/RFC4754 RFC4755 IP over InfiniBand: Connected Mode V. Kashyap December 2006 ASCII 26314 13

This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. [STANDARDS-TRACK]

 draft-ietf-ipoib-connected-mode-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4755 RFC4756 Forward Error Correction Grouping Semantics in Session Description Protocol A. Li November 2006 ASCII 12743 6 fec sdp media lines

This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. [STANDARDS-TRACK]

 draft-ietf-mmusic-fec-grouping-05 RFC5956 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4756 RFC4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows K. Jaganathan L. Zhu J. Brezak December 2006 ASCII 36562 18 md5 hmac

The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.

The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. This memo provides information for the Internet community.

 draft-jaganathan-rc4-hmac-03 RFC6649 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4757 10.17487/RFC4757 RFC4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1 M. Nystroem November 2006 ASCII 110657 54 rsa laboratories one-time password specifications otps

This document constitutes Revision 1 of Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.

CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. This memo provides information for the Internet community.

 draft-nystrom-ct-kip-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4758 10.17487/RFC4758 RFC4759 The ENUM Dip Indicator Parameter for the "tel" URI R. Stastny R. Shockey L. Conroy December 2006 ASCII 15062 8 DNS E.164 telephone number

This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. [STANDARDS-TRACK]

 draft-ietf-iptel-tel-enumdi-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4759 RFC4760 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter January 2007 ASCII 24542 12 MEXT-BGP4 border gateway protocol network layer protocols

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

 draft-ietf-idr-rfc2858bis-10 RFC2858 RFC7606 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4760 10.17487/RFC4760 RFC4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling K. Kompella Editor Y. Rekhter Editor January 2007 ASCII 65219 28 border gateway protocol transparent lan service virtual private switched network service provider

Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.

This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]

 draft-ietf-l2vpn-vpls-bgp-08 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn 10.17487/RFC4761 RFC4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling M. Lasserre Editor V. Kompella Editor January 2007 ASCII 82778 31 land area network transparent lan service

This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.

This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]

 draft-ietf-l2vpn-vpls-ldp-09 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4762 10.17487/RFC4762 RFC4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE) M. Vanderveen H. Soliman November 2006 ASCII 96027 46 IEEE 802.11i user anonymity

This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748. The specification has passed Designated Expert review for this IANA assignment. This memo provides information for the Internet community.

 draft-vanderveen-eap-sake-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4763 10.17487/RFC4763 RFC4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method F. Bersani H. Tschofenig January 2007 ASCII 133990 64 pre-shared key

This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. This memo defines an Experimental Protocol for the Internet community.

 draft-bersani-eap-psk-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4764 RFC4765 The Intrusion Detection Message Exchange Format (IDMEF) H. Debar D. Curry B. Feinstein March 2007 ASCII 307966 157 intrusion detection security secure exchange intrusion IDS XML

The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.

This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-idwg-idmef-xml-16 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4765 RFC4766 Intrusion Detection Message Exchange Requirements M. Wood M. Erlinger March 2007 ASCII 50816 25 idmef idwg intrusion detection exchange format

The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. This memo provides information for the Internet community.

 draft-ietf-idwg-requirements-10 INFORMATIONAL INFORMATIONAL IETF sec idwg 10.17487/RFC4766 RFC4767 The Intrusion Detection Exchange Protocol (IDXP) B. Feinstein G. Matthews March 2007 ASCII 56048 28 intrusion intrusion detection beep security ids security protocol secure protocol secure exchange idmef

This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-idwg-beep-idxp-07 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4767 RFC4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming S. Hartman December 2006 ASCII 27205 12 acl access control list

The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. This memo provides information for the Internet community.

 draft-ietf-kitten-gss-naming-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC4768 RFC4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information J. Livingood R. Shockey November 2006 ASCII 24945 13 tel uri uri scheme sip

This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. [STANDARDS-TRACK]

 draft-ietf-enum-pstn-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4769 RFC4770 vCard Extensions for Instant Messaging (IM) C. Jennings J. Reschke Editor January 2007 ASCII 11077 7 impp instant messaging and presence protocol

This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS-TRACK]

 draft-jennings-impp-vcard-08 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4770 RFC4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) V. Lehtovirta M. Naslund K. Norrman January 2007 ASCII 27945 12 roc

This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS-TRACK]

 draft-lehtovirta-srtp-rcc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4771 10.17487/RFC4771 RFC4772 Security Implications of Using the Data Encryption Standard (DES) S. Kelly December 2006 ASCII 68524 28

The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use. This memo provides information for the Internet community.

 draft-kelly-saag-des-implications-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4772 RFC4773 Administration of the IANA Special Purpose IPv6 Address Block G. Huston December 2006 ASCII 10580 5

This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. This memo provides information for the Internet community.

 draft-huston-ipv6-iana-specials-01 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4773 RFC4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field S. Floyd November 2006 ASCII 37144 15

There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tsvwg-ecn-alternates-02 RFC6040 BCP0124 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC4774 RFC4775 Procedures for Protocol Extensions and Variations S. Bradner B. Carpenter Editor T. Narten December 2006 ASCII 32797 14 sdo standards development organization

This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.

This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-carpenter-protocol-extensions-04 BCP0125 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4775 RFC4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne November 2006 ASCII 45495 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

 RFC4676 RFC5774 RFC6848 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4776 RFC4777 IBM's iSeries Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens November 2006 ASCII 104243 47 midrange business computer telnet environment client server printer

This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.

These support functions are implemented primarily using the Telnet Environment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. This memo provides information for the Internet community.

 draft-murphy-iser-telnet-04 RFC2877 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4777 RFC4778 Operational Security Current Practices in Internet Service Provider Environments M. Kaeo January 2007 ASCII 88344 37 isp

This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. This memo provides information for the Internet community.

 draft-ietf-opsec-current-practices-07 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=4778 10.17487/RFC4778 RFC4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks S. Asadullah A. Ahmed C. Popoviciu P. Savola J. Palet January 2007 ASCII 188511 81 v6ops isp ipv6 deployment scenarios broadband networks

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today\'s Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. This memo provides information for the Internet community.

 draft-ietf-v6ops-bb-deployment-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4779 10.17487/RFC4779 RFC4780 Management Information Base for the Session Initiation Protocol (SIP) K. Lingle J-F. Mule J. Maeng D. Walker April 2007 ASCII 160460 83 mib registrar services SIP-COMMON-MIB SIP-TC-MIB SIP-UA-MIB DEFINITIONS SIP-SERVER-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 a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]

 draft-ietf-sip-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4780 RFC4781 Graceful Restart Mechanism for BGP with MPLS Y. Rekhter R. Aggarwal January 2007 ASCII 23249 10 border gateway protocol multiprotocol label switching nlri bgp network layer reachability information

A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.

The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRACK]

 draft-ietf-mpls-bgp-mpls-restart-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4781 RFC4782 Quick-Start for TCP and IP S. Floyd M. Allman A. Jain P. Sarolahti January 2007 ASCII 214489 82

This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.

This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-quickstart-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4782 10.17487/RFC4782 RFC4783 GMPLS - Communication of Alarm Information L. Berger Editor December 2006 ASCII 42068 19 generalized multiprotocol label switching gmpls-rsvp

This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.

This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-alarm-spec-06 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4783 10.17487/RFC4783 RFC4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks C. Carroll F. Quick June 2007 ASCII 102856 45 mip cryptographic keys dmu

The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA).

cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.

 draft-carroll-dynmobileip-cdma-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4784 RFC4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) U. Blumenthal P. Goel January 2007 ASCII 9550 5 cipher suite

This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS-TRACK]

 draft-ietf-tls-psk-null-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4785 RFC4786 Operation of Anycast Services J. Abley K. Lindqvist December 2006 ASCII 56818 24 ROUTING LOAD-BALANCING LOAD-SHARING

As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.

Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-anycast-04 BCP0126 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4786 RFC4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP F. Audet Editor C. Jennings January 2007 ASCII 68693 29 nat sip udp

This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-nat-udp-08 RFC6888 RFC7857 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC4787 RFC4788 Enhancements to RTP Payload Formats for EVRC Family Codecs Q. Xie R. Kapoor January 2007 ASCII 42216 22 enhanced variable rate codec real time transmission protocol evrc-b dtx discontinuous transmission

This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. [STANDARDS-TRACK]

 draft-ietf-avt-compact-bundled-evrc-11 RFC3558 RFC5188 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4788 RFC4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks J. Schoenwaelder T. Jeffree November 2006 ASCII 17839 9

This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.

This document obsoletes RFC 1089. [STANDARDS-TRACK]

 draft-schoenw-snmp-ether-02 RFC1089 RFC3417 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4789 RFC4790 Internet Application Protocol Collation Registry C. Newman M. Duerst A. Gulbrandsen March 2007 ASCII 55591 26 collation sorting

Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS-TRACK]

 draft-newman-i18n-comparator-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4790 10.17487/RFC4790 RFC4791 Calendaring Extensions to WebDAV (CalDAV) C. Daboo B. Desruisseaux L. Dusseault March 2007 ASCII 206801 107 calsched calsch calcav calendar calendaring scheduling webdav ical icalendar itip text/calendar http

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. [STANDARDS-TRACK]

 draft-dusseault-caldav-15 RFC5689 RFC6638 RFC6764 RFC7809 RFC7953 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4791 10.17487/RFC4791 RFC4792 Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg January 2007 ASCII 17637 9 ASN.1

Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. [STANDARDS-TRACK]

 draft-legg-ldap-gser-ei-02 RFC3641 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4792 RFC4793 The EAP Protected One-Time Password Protocol (EAP-POTP) M. Nystroem February 2007 ASCII 172575 82 otp extensible authentication protocol

This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2). This memo provides information for the Internet community.

 draft-nystrom-eap-potp-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4793 RFC4794 RFC 1264 Is Obsolete B. Fenner December 2006 ASCII 7554 4

RFC 1264 was written during what was effectively a completely different time in the life of the Internet. It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties. In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way. This memo provides information for the Internet community.

 draft-fenner-obsolete-1264-03 RFC1264 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4794 RFC4795 Link-local Multicast Name Resolution (LLMNR) B. Aboba D. Thaler L. Esibov January 2007 ASCII 71969 31

The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. This memo provides information for the Internet community.

 draft-ietf-dnsext-mdns-47 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4795 10.17487/RFC4795 RFC4796 The Session Description Protocol (SDP) Content Attribute J. Hautakorpi G. Camarillo February 2007 ASCII 22886 11 media attribute content

This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-media-content-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4796 RFC4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks Y. Rekhter R. Bonica E. Rosen January 2007 ASCII 18985 10 L3VPN GRE encapsulation

This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE).

The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. This memo provides information for the Internet community.

 draft-ietf-l3vpn-gre-ip-2547-05 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4797 RFC4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) J. De Clercq D. Ooms S. Prevost F. Le Faucheur February 2007 ASCII 31381 14 mp-bgp

This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]

 draft-ooms-v6ops-bgp-tunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4798 RFC4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management T. Nadeau Editor A. Farrel Editor February 2007 ASCII 16347 9 management information base mib GMPLS-TC-STD-MIB

This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-tc-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4801 RFC4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base T. Nadeau Editor A. Farrel Ed. February 2007 ASCII 118164 60 mib GMPLS-TE-STD-MIB IANA-GMPLS-TC-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-te-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4802 RFC4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base T. Nadeau Editor A. Farrel Editor February 2007 ASCII 79925 42 mib GMPLS-LSR-STD-MIB GMPLS-LABEL-STD-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 to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-lsr-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4803 10.17487/RFC4803 RFC4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels F. Le Faucheur Editor February 2007 ASCII 69473 31 multiprotocol label switching traffic engineering diffserv-aware mpls traffic engineering

RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-dste-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4804 10.17487/RFC4804 RFC4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types O. Nicklass Editor March 2007 ASCII 189927 94 mib management information base DS1-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 objects used for managing DS1, J1, E1, DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types.

This document obsoletes RFC 3895. [STANDARDS-TRACK]

 draft-orly-atommib-rfc3895bis-01 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4805 RFC4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2 M. Myers H. Tschofenig February 2007 ASCII 21991 11 internet key exchange version 2

While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.

When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]

 draft-myers-ikev2-ocsp-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4806 RFC4807 IPsec Security Policy Database Configuration MIB M. Baer R. Charlet W. Hardaker R. Story C. Wang March 2007 ASCII 136747 71 management information base IPSEC-SPD-MIB

This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. [STANDARDS-TRACK]

 draft-ietf-ipsp-spd-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4807 10.17487/RFC4807 RFC4808 Key Change Strategies for TCP-MD5 S. Bellovin March 2007 ASCII 14939 8 bgp border gateway protocol

The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. This memo provides information for the Internet community.

 draft-bellovin-keyroll2385-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4808 RFC4809 Requirements for an IPsec Certificate Management Profile C. Bonatti Editor S. Turner Editor G. Lebovitz Editor February 2007 ASCII 98400 45 internet protocol security

This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. This memo provides information for the Internet community.

 draft-ietf-pki4ipsec-mgmt-profile-rqts-07 INFORMATIONAL INFORMATIONAL IETF sec pki4ipsec 10.17487/RFC4809 RFC4810 Long-Term Archive Service Requirements C. Wallace U. Pordesch R. Brandner March 2007 ASCII 35690 17 data integrity digital signatures

There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. This memo provides information for the Internet community.

 draft-ietf-ltans-reqs-10 INFORMATIONAL INFORMATIONAL IETF sec ltans 10.17487/RFC4810 RFC4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization L. Nguyen A. Roy A. Zinin March 2007 ASCII 18976 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.

This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

 draft-nguyen-ospf-oob-resync-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4811 RFC4812 OSPF Restart Signaling L. Nguyen A. Roy A. Zinin March 2007 ASCII 12111 7 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via the Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a Hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.

This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

 draft-nguyen-ospf-restart-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4812 10.17487/RFC4812 RFC4813 OSPF Link-Local Signaling B. Friedman L. Nguyen A. Roy D. Yeung A. Zinin March 2007 ASCII 19687 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This memo defines an Experimental Protocol for the Internet community.

 draft-nguyen-ospf-lls-06 RFC5613 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4813 RFC4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking D. Newman T. Player March 2007 ASCII 59272 26 bmwg benchmarking testing bit-stuffing byte-stuffing

Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. This memo provides information for the Internet community.

 draft-ietf-bmwg-hash-stuffing-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4814 RFC4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 L-E. Jonsson K. Sandlund G. Pelletier P. Kremer February 2007 ASCII 74819 33 ip udp user datagram protocol rtp realtime transport protocol esp encapsulation security payload

RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-impl-guide-22 RFC3095 RFC3241 RFC3843 RFC4019 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4815 RFC4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service A. Malis L. Martini J. Brayley T. Walsh February 2007 ASCII 10269 5

The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. [STANDARDS-TRACK]

 draft-ietf-pwe3-cell-transport-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4816 RFC4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 M. Townsley C. Pignataro S. Wainner T. Seely J. Young March 2007 ASCII 26538 12 l2tpv3 multiprotocol label switching label stack label stack

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [STANDARDS-TRACK]

 draft-ietf-mpls-over-l2tpv3-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4817 RFC4818 RADIUS Delegated-IPv6-Prefix Attribute J. Salowey R. Droms April 2007 ASCII 12993 7 remote authentication dial in user service diameter

This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. [STANDARDS-TRACK]

 draft-ietf-radext-delegated-prefix-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4818 RFC4819 Secure Shell Public Key Subsystem J. Galbraith J. Van Dyke J. Bright March 2007 ASCII 32794 17 ssh ssh2

Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.

The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.

A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK]

 draft-ietf-secsh-publickey-subsystem-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4819 RFC4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei March 2007 ASCII 11597 6

This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-padding-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4820 10.17487/RFC4820 RFC4821 Packetization Layer Path MTU Discovery M. Mathis J. Heffner March 2007 ASCII 75665 32 maximum transmission unit pmtud

This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]

 draft-ietf-pmtud-method-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pmtud http://www.rfc-editor.org/errata_search.php?rfc=4821 10.17487/RFC4821 RFC4822 RIPv2 Cryptographic Authentication R. Atkinson M. Fanto February 2007 ASCII 53828 22 RIP2-MD5 Routing Information Protocol Encryption

This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. [STANDARDS-TRACK]

 draft-rja-ripv2-auth-06 RFC2082 RFC2453 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4822 RFC4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Scott April 2007 ASCII 80992 40 applicability statement as business-to-business

This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. This memo provides information for the Internet community.

 draft-ietf-ediint-as3-04 INFORMATIONAL INFORMATIONAL IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4823 10.17487/RFC4823 RFC4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) J. Hofmueller Editor A. Bachmann Editor IO. zmoelnig Editor April 1 2007 ASCII 25521 13 internet protocol april fools

This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4824 10.17487/RFC4824 RFC4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) J. Rosenberg May 2007 ASCII 166627 71 sip xml http rest buddy list simple presence data manipulation

This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. [STANDARDS-TRACK]

 draft-ietf-simple-xcap-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4825 RFC4826 Extensible Markup Language (XML) Formats for Representing Resource Lists J. Rosenberg May 2007 ASCII 68850 31 http sip xml rest buddy list simple presence data manipulation

In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). [STANDARDS-TRACK]

 draft-ietf-simple-xcap-list-usage-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4826 10.17487/RFC4826 RFC4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents M. Isomaki E. Leppanen May 2007 ASCII 22896 11 PIDF AUID hard state PUBLISH SIP Presence SIMPLE pidf-manipulation XCAP application usage

This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. [STANDARDS-TRACK]

 draft-ietf-simple-xcap-pidf-manipulation-usage-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4827 RFC4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant S. Floyd E. Kohler April 2007 ASCII 116808 46 transmission control protocol

This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.

TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.

Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dccp-tfrc-voip-07 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4828 10.17487/RFC4828 RFC4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering J. de Oliveira Editor JP. Vasseur Editor L. Chen C. Scoglio April 2007 ASCII 43892 19 traffic engineering label switched path te lsp multiprotocol label switching protocol

When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted. The preempted LSPs are then rerouted by their respective \%Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included. This memo provides information for the Internet community.

 draft-deoliveira-diff-te-preemption-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4829 RFC4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII 29815 13

Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. This memo provides information for the Internet community.

 draft-ietf-netlmm-nohost-ps-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4830 RFC4831 Goals for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII 35232 14

In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. This memo provides information for the Internet community.

 draft-ietf-netlmm-nohost-req-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4831 RFC4832 Security Threats to Network-Based Localized Mobility Management (NETLMM) C. Vogt J. Kempf April 2007 ASCII 31467 12 localized mobility anchor mobile access gateway compromise impersonation man in the middle denial of service IP spoofing

This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. This memo provides information for the Internet community.

 draft-ietf-netlmm-threats-04 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4832 RFC4833 Timezone Options for DHCP E. Lear P. Eggert April 2007 ASCII 19573 10 time offset posix tz database tz

Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated. [STANDARDS-TRACK]

 draft-ietf-dhc-timezone-option-05 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4833 RFC4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) T. Morin Editor April 2007 ASCII 80341 37 vpn virtual private networks l3

This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. This memo provides information for the Internet community.

 draft-ietf-l3vpn-ppvpn-mcast-reqts-10 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4834 RFC4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) V. Manral April 2007 ASCII 21492 10 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

 draft-manral-ipsec-rfc4305-bis-errata-03 RFC4305 RFC7321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4835 RFC4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) E. Beili April 2007 ASCII 151012 67 MAU-MIB IANA-MAU-MIB management information base,

This document 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 IEEE 802.3 Medium Attachment Units (MAUs). This document obsoletes RFC 3636. It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. [STANDARDS-TRACK]

 draft-ietf-hubmib-rfc3636bis-05 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib http://www.rfc-editor.org/errata_search.php?rfc=4836 10.17487/RFC4836 RFC4837 Managed Objects of Ethernet Passive Optical Networks (EPON) L. Khermosh July 2007 ASCII 206726 91 Ethernet Passive Optical Networks pon epon IEEE802.3ah 802.3ah p2mp mpcp llid onu olt optical access

This document 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 interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. [STANDARDS-TRACK]

 draft-ietf-hubmib-efm-epon-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4837 RFC4838 Delay-Tolerant Networking Architecture V. Cerf S. Burleigh A. Hooke L. Torgerson R. Durst K. Scott K. Fall H. Weiss April 2007 ASCII 89265 35 disruption tolerant irtf interplanetary internet

This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.

 draft-irtf-dtnrg-arch-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4838 RFC4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) G. Conboy J. Rivlin J. Ferraiolo April 2007 ASCII 7851 5

This document serves to register a media type for the Open eBook Publication Structure (OEBPS) Package Files. This memo provides information for the Internet community.

 draft-conboy-mime-opf-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4839 RFC4840 Multiple Encapsulation Methods Considered Harmful B. Aboba Editor E. Davies D. Thaler April 2007 ASCII 65287 27 iab link-layer protocol ip encapsulation internet protocol encapsulation

This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. This memo provides information for the Internet community.

 draft-iab-link-encaps-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4840 RFC4841 RFC 4181 Update to Recognize the IETF Trust C. Heard Editor March 2007 ASCII 4414 3 management information base standards-track specifications mib review

This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-heard-rfc4181-update-00 RFC4181 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4841 RFC4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) A. Malis P. Pate R. Cohen Editor D. Zelig April 2007 ASCII 96719 43 multiprotocol label switching

This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]

 draft-ietf-pwe3-sonet-14 RFC5143 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4842 10.17487/RFC4842 RFC4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) P. Nikander J. Laganier F. Dupont April 2007 ASCII 32483 14

This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.

 draft-laganier-ipv6-khi-07 RFC7343 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4843 RFC4844 The RFC Series and RFC Editor L. Daigle Editor Internet Architecture Board July 2007 ASCII 38752 20 technical publisher

This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community.

 draft-iab-rfc-editor-04 RFC5741 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4844 RFC4845 Process for Publication of IAB RFCs L. Daigle Editor Internet Architecture Board July 2007 ASCII 9228 5

From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. This memo provides information for the Internet community.

 draft-iab-publication-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4845 RFC4846 Independent Submissions to the RFC Editor J. Klensin Editor D. Thaler Editor July 2007 ASCII 36562 16

There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. This memo provides information for the Internet community.

 draft-iab-rfc-independent-00 RFC5744 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4846 RFC4847 Framework and Requirements for Layer 1 Virtual Private Networks T. Takeda Editor April 2007 ASCII 85807 38 L1VPN

This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.

The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. This memo provides information for the Internet community.

 draft-ietf-l1vpn-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC4847 RFC4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle April 2007 ASCII 19341 10 service-parms service parameters

The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]

 draft-daigle-unaptr-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4848 10.17487/RFC4848 RFC4849 RADIUS Filter Rule Attribute P. Congdon M. Sanchez B. Aboba April 2007 ASCII 18162 9 remote authentication dial in user service nas-filter-rule

While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [STANDARDS-TRACK]

 draft-ietf-radext-filter-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4849 RFC4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture D. Wysochanski April 2007 ASCII 16430 9 transport protocol tcp transmission control protocol

The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-nodearch-key-03 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4850 RFC4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou May 2007 ASCII 131460 64 eap

This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an 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 peer and the EAP server. This memo provides information for the Internet community.

 draft-cam-winget-eap-fast-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4851 10.17487/RFC4851 RFC4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus J. Bound Y. Pouffary S. Klynsma T. Chown D. Green April 2007 ASCII 76199 32 internet protocol version 6 notational network

This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. This memo provides information for the Internet community.

 draft-ietf-v6ops-ent-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4852 10.17487/RFC4852 RFC4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification R. Housley April 2007 ASCII 10146 5 signeddata digitally sign authenticate encrypt arbitrary message content

This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. [STANDARDS-TRACK]

 draft-ietf-smime-cms-mult-sign-03 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4853 10.17487/RFC4853 RFC4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre April 2007 ASCII 15911 9 Extensible Messaging and Presence Protocol XMPP Jabber Instant Messaging Presence Uniform Resource Name URN

This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging and Presence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF). This memo provides information for the Internet community.

 draft-saintandre-xmpp-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4854 RFC4855 Media Type Registration of RTP Payload Formats S. Casner February 2007 ASCII 24404 11 realtime transport protocol multipurpose internet mail extensions

This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3555bis-05 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4855 RFC4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences S. Casner February 2007 ASCII 45881 29 realtime transport protocol multipurpose internet mail extensions

This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3555bis-part2-02 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4856 10.17487/RFC4856 RFC4857 Mobile IPv4 Regional Registration E. Fogelstroem A. Jonsson C. Perkins June 2007 ASCII 79939 35 GFA gateway foreign agent

Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mip4-reg-tunnel-04 EXPERIMENTAL EXPERIMENTAL IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4857 10.17487/RFC4857 RFC4858 Document Shepherding from Working Group Last Call to Publication H. Levkowetz D. Meyer L. Eggert A. Mankin May 2007 ASCII 48572 21 document shepherding ietf documents

This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. This memo provides information for the Internet community.

 draft-ietf-proto-wgchair-doc-shepherding-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4858 RFC4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object A. Farrel April 2007 ASCII 7511 5

This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling. This memo provides information for the Internet community.

 draft-ietf-mpls-iana-rsvp-session-flags-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4859 RFC4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations F. Le Faucheur B. Davie P. Bose C. Christou M. Davenport May 2007 ASCII 73010 32 session object session of interest phb per hop behavior

RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-ipsec-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4860 RFC4861 Neighbor Discovery for IP version 6 (IPv6) T. Narten E. Nordmark W. Simpson H. Soliman September 2007 ASCII 235106 97 IPV6-ND internet protocol link-layer link-layer address

This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]

 draft-ietf-ipv6-2461bis-11 RFC2461 RFC5942 RFC6980 RFC7048 RFC7527 RFC7559 RFC8028 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4861 10.17487/RFC4861 RFC4862 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten T. Jinmei September 2007 ASCII 72482 30 IPV6-AUTO host link-local internet protocol version 6 link-local address duplicate address detection

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2462bis-08 RFC2462 RFC7527 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4862 10.17487/RFC4862 RFC4863 Wildcard Pseudowire Type L. Martini G. Swallow May 2007 ASCII 11321 6 pw type pw

Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need. [STANDARDS-TRACK]

 draft-ietf-pwe3-wildcard-pw-type-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4863 RFC4864 Local Network Protection for IPv6 G. Van de Velde T. Hain R. Droms B. Carpenter E. Klein May 2007 ASCII 95448 36 ipv6 address protection nat

Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. This memo provides information for the Internet community.

 draft-ietf-v6ops-nap-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4864 RFC4865 SMTP Submission Service Extension for Future Message Release G. White G. Vaudreuil May 2007 ASCII 21495 11 simple mail transfer protocol future-release-integer

This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK]

 draft-vaudreuil-futuredelivery-04 RFC3463 RFC3464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4865 10.17487/RFC4865 RFC4866 Enhanced Route Optimization for Mobile IPv6 J. Arkko C. Vogt W. Haddad May 2007 ASCII 145757 54 mobility cryptographically generated addresses cga credit-based authorization cba

This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS-TRACK]

 draft-ietf-mipshop-cga-cba-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4866 10.17487/RFC4866 RFC4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie April 2007 ASCII 139584 59 interoperate applications

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-amr-bis-06 RFC3267 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4867 10.17487/RFC4867 RFC4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec S. Kelly S. Frankel May 2007 ASCII 41432 21 hashed authentication mode data authentication integrity verification

This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]

 draft-kelly-ipsec-ciph-sha2-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4868 10.17487/RFC4868 RFC4869 Suite B Cryptographic Suites for IPsec L. Law J. Solinas May 2007 ASCII 17043 9 ui suites user interface suites elliptic curve ike

This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This memo provides information for the Internet community.

 draft-solinas-ui-suites-01 RFC6379 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4869 RFC4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) M. Delany May 2007 ASCII 87378 41

"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.

This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.

Proof and protection of email identity may assist in the global control of "spam" and "phishing". This memo defines a Historic Document for the Internet community.

 draft-delany-domainkeys-base-06 RFC4871 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC4870 RFC4871 DomainKeys Identified Mail (DKIM) Signatures E. Allman J. Callas M. Delany M. Libbey J. Fenton M. Thomas May 2007 ASCII 166054 71 internet mail authentication spam phishing spoofing digital signature

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". [STANDARDS-TRACK]

 draft-ietf-dkim-base-10 RFC4870 RFC6376 RFC5672 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=4871 10.17487/RFC4871 RFC4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery J.P. Lang Editor Y. Rekhter Editor D. Papadimitriou Editor May 2007 ASCII 111882 47 resource reservation protocol traffic engineering

This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04 RFC3471 RFC4873 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4872 10.17487/RFC4872 RFC4873 GMPLS Segment Recovery L. Berger I. Bryskin D. Papadimitriou A. Farrel May 2007 ASCII 56919 25 generalized multipoint label switching rsvp-te resource reservation protocol traffic engineering NOTIFY_REQUEST

This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-segment-recovery-03 RFC3473 RFC4872 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4873 10.17487/RFC4873 RFC4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) CY. Lee A. Farrel S. De Cnodder April 2007 ASCII 59569 27 srlg shared risk link groups

This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).

The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.

In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS-TRACK]

 draft-ietf-ccamp-rsvp-te-exclude-route-06 RFC3209 RFC3473 RFC6001 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4874 10.17487/RFC4874 RFC4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) R. Aggarwal Editor D. Papadimitriou Editor S. Yasukawa Editor May 2007 ASCII 125394 53 p2mp point-to-multipoint traffic engineering

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.

There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-te-p2mp-07 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4875 10.17487/RFC4875 RFC4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents B. Neal-Joslin Editor L. Howard M. Ansari May 2007 ASCII 73468 39 ldap schema profile configuration nameservice nss pam_ldap nss_ldap rfc2307 rfc 2307

This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. This memo provides information for the Internet community.

 draft-joslin-config-schema-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4876 10.17487/RFC4876 RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture V. Devarapalli F. Dupont April 2007 ASCII 57941 26 Bootstrapping MIP6 Selector Granularity Mobility Header EAP Authentication

This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS-TRACK]

 draft-ietf-mip6-ikev2-ipsec-08 RFC3776 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4877 10.17487/RFC4877 RFC4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces M. Squire June 2007 ASCII 130067 58 efm ethernet in the first mile snmp DOT3-OAM-MIB

This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities. [STANDARDS-TRACK]

 draft-ietf-hubmib-efm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4878 RFC4879 Clarification of the Third Party Disclosure Procedure in RFC 3979 T. Narten April 2007 ASCII 5570 4 ipr copyright

This document clarifies and updates a single sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-narten-ipr-3979-3rd-party-fix-00 RFC3979 BCP0079 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4879 RFC4880 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney D. Shaw R. Thayer November 2007 ASCII 203706 90 public-key cryptography symmetric cryptography

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.

OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]

 draft-ietf-openpgp-rfc2440bis-22 RFC1991 RFC2440 RFC5581 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=4880 10.17487/RFC4880 RFC4881 Low-Latency Handoffs in Mobile IPv4 K. El Malki Editor June 2007 ASCII 151124 64 mip4

Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mobileip-lowlatency-handoffs-v4-11 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4881 RFC4882 IP Address Location Privacy and Mobile IPv6: Problem Statement R. Koodli May 2007 ASCII 24987 11 internet protocol home address care-of address

In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. This memo provides information for the Internet community.

 draft-ietf-mip6-location-privacy-ps-06 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4882 RFC4883 Benchmarking Terminology for Resource Reservation Capable Routers G. Feher K. Nemeth A. Korn I. Cselenyi July 2007 ASCII 54205 24 intserv integrated services benchmarking methodologies

The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. This memo provides information for the Internet community.

 draft-ietf-bmwg-benchres-term-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4883 RFC4884 Extended ICMP to Support Multi-Part Messages R. Bonica D. Gan D. Tappan C. Pignataro April 2007 ASCII 42169 19 internet control message protocol length attribute

This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.

Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.

This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.

The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.

This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]

 draft-bonica-internet-icmp-16 RFC0792 RFC4443 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4884 10.17487/RFC4884 RFC4885 Network Mobility Support Terminology T. Ernst H-Y. Lach July 2007 ASCII 37967 19 nemo

This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements. This memo provides information for the Internet community.

 draft-ietf-nemo-terminology-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4885 10.17487/RFC4885 RFC4886 Network Mobility Support Goals and Requirements T. Ernst July 2007 ASCII 29083 13 nemo

Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. This memo provides information for the Internet community.

 draft-ietf-nemo-requirements-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4886 10.17487/RFC4886 RFC4887 Network Mobility Home Network Models P. Thubert R. Wakikawa V. Devarapalli July 2007 ASCII 40372 19 nemo mobile routers

This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists. This memo provides information for the Internet community.

 draft-ietf-nemo-home-network-models-06 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4887 RFC4888 Network Mobility Route Optimization Problem Statement C. Ng P. Thubert M. Watari F. Zhao July 2007 ASCII 56756 26 nemo

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO. This memo provides information for the Internet community.

 draft-ietf-nemo-ro-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4888 10.17487/RFC4888 RFC4889 Network Mobility Route Optimization Solution Space Analysis C. Ng F. Zhao M. Watari P. Thubert July 2007 ASCII 95880 38 nemo mrha mobile router and home agent ro

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. This memo provides information for the Internet community.

 draft-ietf-nemo-ro-space-analysis-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4889 10.17487/RFC4889 RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls E. Davies J. Mohacsi May 2007 ASCII 83479 38 Internet Control Message Protocol version 6 ipv6 security filter firewall icmpv6

In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.

This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. This memo provides information for the Internet community.

 draft-ietf-v6ops-icmpv6-filtering-recs-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4890 10.17487/RFC4890 RFC4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels R. Graveman M. Parthasarathy P. Savola H. Tschofenig May 2007 ASCII 46635 23 internet protocol internet protocol security ip security

This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipsec-tunnels-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4891 RFC4892 Requirements for a Mechanism Identifying a Name Server Instance S. Woolf D. Conrad June 2007 ASCII 17605 8 domain name service dns name server

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. This memo provides information for the Internet community.

 draft-ietf-dnsop-serverid-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4892 RFC4893 BGP Support for Four-octet AS Number Space Q. Vohra E. Chen May 2007 ASCII 21520 10 autonomous system border gateway protocol

Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. [STANDARDS-TRACK]

 draft-ietf-idr-as4bytes-13 RFC6793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4893 RFC4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec P. Hoffman May 2007 ASCII 22899 11 md5 pkix certificates

This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. This memo provides information for the Internet community.

 draft-hoffman-ike-ipsec-hash-use-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4894 RFC4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei E. Rescorla August 2007 ASCII 42507 19 chunk type shared keys RANDOM CHUNKS HMAC-ALGO

This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4895 10.17487/RFC4895 RFC4896 Signaling Compression (SigComp) Corrections and Clarifications A. Surtees M. West A.B. Roach June 2007 ASCII 58435 28 sip session initiation protocol udvm universal decompressor virtual machine algorithm

This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]

 draft-ietf-rohc-sigcomp-impl-guide-10 RFC3320 RFC3321 RFC3485 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4896 RFC4897 Handling Normative References to Standards-Track Documents J. Klensin S. Hartman June 2007 ASCII 13023 6

The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to such References. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-norm-ref-04 RFC3967 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4897 10.17487/RFC4897 RFC4898 TCP Extended Statistics MIB M. Mathis J. Heffner R. Raghunarayan May 2007 ASCII 153768 75 transmission control protocol management information base TCP-ESTATS-MIB

This document describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tcp-mib-extension-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4898 RFC4901 Protocol Extensions for Header Compression over MPLS J. Ash Editor J. Hand Editor A. Malis Editor June 2007 ASCII 78801 34 multiprotocol label switching hc

This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link. [STANDARDS-TRACK]

 draft-ietf-avt-hc-over-mpls-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4901 RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP M. Stecher May 2007 ASCII 30120 14

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.

The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. This memo provides information for the Internet community.

 draft-ietf-opes-smtp-security-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4902 RFC4903 Multi-Link Subnet Issues D. Thaler June 2007 ASCII 39671 17

There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. This memo provides information for the Internet community.

 draft-iab-multilink-subnet-issues-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4903 RFC4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs) V. Gurbani C. Jennings June 2007 ASCII 41027 19 SIP TEL Trunk group trunkgroup PSTN

This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. [STANDARDS-TRACK]

 draft-ietf-iptel-trunk-group-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4904 RFC4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII 40020 20 multiprotocol label switching pdu protocol data unit draft-martini

This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

 draft-martini-l2circuit-encap-mpls-12 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4905 10.17487/RFC4905 RFC4906 Transport of Layer 2 Frames Over MPLS L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII 47403 22 multiprotocol label switching pdu protocol data unit sonet synchronized optical network

This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

 draft-martini-l2circuit-trans-mpls-19 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4906 10.17487/RFC4906 RFC4907 Architectural Implications of Link Indications B. Aboba Editor June 2007 ASCII 160604 62

A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications. This memo provides information for the Internet community.

 draft-iab-link-indications-10 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4907 10.17487/RFC4907 RFC4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO K. Nagami S. Uda N. Ogashiwa H. Esaki R. Wakikawa H. Ohnishi June 2007 ASCII 20230 10 care-of addresses

Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care-of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy. This memo defines an Experimental Protocol for the Internet community.

 draft-nagami-mip6-nemo-multihome-fixed-network-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4908 RFC4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport L. Dondeti Editor D. Castleford F. Hartung June 2007 ASCII 12228 7 short-term key message long-term key message oma bac browser and content broadcast

This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification. This memo provides information for the Internet community.

 draft-dondeti-msec-mikey-genext-oma-04 RFC5410 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4909 10.17487/RFC4909 RFC4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1) S. Legg D. Prager July 2007 ASCII 182175 80 extensible markup language canonical rxer crxer

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined. This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-rxer-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4910 RFC4911 Encoding Instructions for the Robust XML Encoding Rules (RXER) S. Legg July 2007 ASCII 178977 91 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer canonical robust xml encoding rules crxer asn.x

This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-rxer-ei-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4911 RFC4912 Abstract Syntax Notation X (ASN.X) S. Legg July 2007 ASCII 325190 165 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer

Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents. This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-asd-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4912 RFC4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg July 2007 ASCII 17194 9 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER). This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-asd-gserei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4913 RFC4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER) S. Legg July 2007 ASCII 71526 38 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER). This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-asd-xerei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4914 RFC4915 Multi-Topology (MT) Routing in OSPF P. Psenak S. Mirtorabi A. Roy L. Nguyen P. Pillay-Esnault June 2007 ASCII 43115 20 open shortest path first

This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.

An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]

 draft-ietf-ospf-mt-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4915 RFC4916 Connected Identity in the Session Initiation Protocol (SIP) J. Elwell June 2007 ASCII 42924 24 user agent ua application-layer application layer multimedia multicast unicast

This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK]

 draft-ietf-sip-connected-identity-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4916 RFC4917 Mobile IPv4 Message String Extension V. Sastry K. Leung A. Patel June 2007 ASCII 13302 7 home agent foreign agent registration reply

This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. [STANDARDS-TRACK]

 draft-ietf-mip4-message-string-ext-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4917 RFC4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) L. Dusseault Editor June 2007 ASCII 276352 127 WEBDAV hypertext transfer protocol web content

Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).

RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]

 draft-ietf-webdav-rfc2518bis-18 RFC2518 RFC5689 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=4918 10.17487/RFC4918 RFC4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals N. Kushalnagar G. Montenegro C. Schumacher August 2007 ASCII 27650 12 ieee 802.15.4

This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community.

 draft-ietf-6lowpan-problem-08 INFORMATIONAL INFORMATIONAL IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4919 10.17487/RFC4919 RFC4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE A. Farrel Editor A. Satyanarayana A. Iwata N. Fujita G. Ash July 2007 ASCII 88679 38 multiprotocol label switching generalized multiprotocol label switching traffic engineered te lsp label switched path

In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.

This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]

 draft-ietf-ccamp-crankback-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4920 10.17487/RFC4920 RFC4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network F. Baker P. Bose August 2007 ASCII 92632 38 vpn nested vpn integrated services

Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998. This memo provides information for the Internet community.

 draft-ietf-tsvwg-vpn-signaled-preemption-02 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4923 RFC4924 Reflections on Internet Transparency B. Aboba Editor E. Davies July 2007 ASCII 35040 15

This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. This memo provides information for the Internet community.

 draft-iab-net-transparent-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4924 RFC4925 Softwire Problem Statement X. Li Editor S. Dawkins Editor D. Ward Editor A. Durand Editor July 2007 ASCII 49299 23

This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. This memo provides information for the Internet community.

 draft-ietf-softwire-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC4925 RFC4926 A URN Namespace for GEANT T.Kalin M.Molina July 2007 ASCII 16672 9 uniform resource name dante

This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and Research Networks, its projects, activities, working groups, and other designated subordinates. This memo provides information for the Internet community.

 draft-kalin-geant-urn-namespace-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4926 RFC4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering J.-L. Le Roux Editor June 2007 ASCII 25016 12 gmpls te-lsp traffic engineered label switched path pce path computation element

For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. This memo provides information for the Internet community.

 draft-ietf-pce-pcecp-interarea-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4927 RFC4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks G. Swallow S. Bryant L. Andersson June 2007 ASCII 18376 8 ecmp

This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mpls-ecmp-bcp-03 RFC7274 BCP0128 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4928 10.17487/RFC4928 RFC4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures L. Andersson Editor A. Farrel Editor June 2007 ASCII 56742 23

This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-andersson-rtg-gmpls-change-08 BCP0129 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4929 RFC4930 Extensible Provisioning Protocol (EPP) S. Hollenbeck May 2007 ASCII 135648 72 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3730bis-04 RFC3730 RFC5730 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4930 RFC4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck May 2007 ASCII 88729 46 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 3731. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3731bis-05 RFC3731 RFC5731 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4931 RFC4932 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck May 2007 ASCII 57623 30 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3732bis-04 RFC3732 RFC5732 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4932 RFC4933 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck May 2007 ASCII 82254 43 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3733bis-06 RFC3733 RFC5733 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4933 RFC4934 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck May 2007 ASCII 22914 10 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3734bis-05 RFC3734 RFC5734 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4934 RFC4935 Fibre Channel Fabric Configuration Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII 97345 50 management information base T11-FC-FABRIC-CONFIG-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fcs-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4935 10.17487/RFC4935 RFC4936 Fibre Channel Zone Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII 170801 84 management information base T11-FC-FABRIC-LOCK-MIB T11-FC-ZONE-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. [STANDARDS-TRACK]

 draft-ietf-imss-fc-zs-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4936 RFC4937 IANA Considerations for PPP over Ethernet (PPPoE) P. Arberg V. Mammoliti June 2007 ASCII 11070 6

This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. This memo provides information for the Internet community.

 draft-arberg-pppoe-iana-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4937 RFC4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry H. Holgate June 2007 ASCII 38288 17

This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. This memo provides information for the Internet community.

 draft-bberry-pppoe-credit-06 RFC5578 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4938 10.17487/RFC4938 RFC4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service) K. Gibbons G. Ramkumar S. Kipp July 2007 ASCII 165381 80 mib management information base iscsi internet small computer system interface ifcp internet fibre channel protocol ISNS-MIB

The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS-TRACK]

 draft-ietf-ips-isns-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4939 10.17487/RFC4939 RFC4940 IANA Considerations for OSPF K. Kompella B. Fenner July 2007 ASCII 27595 15 open shortest path first

This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ospf-iana-03 BCP0130 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4940 10.17487/RFC4940 RFC4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves S. Krishnan September 2007 ASCII 56699 23 privacy anonymity unlinkability crypto-based address changing

Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]

 draft-ietf-ipv6-privacy-addrs-v2-05 RFC3041 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4941 10.17487/RFC4941 RFC4942 IPv6 Transition/Co-existence Security Considerations E. Davies S. Krishnan P. Savola September 2007 ASCII 102878 41 internet protocol version 6 dual-protocol network ipv4

The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories:

o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.

This memo provides information for the Internet community.

 draft-ietf-v6ops-security-overview-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4942 RFC4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful S. Roy A. Durand J. Paugh September 2007 ASCII 16719 8 internet protocol version 6

This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm. This memo provides information for the Internet community.

 draft-ietf-v6ops-onlinkassumption-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4943 RFC4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks G. Montenegro N. Kushalnagar J. Hui D. Culler September 2007 ASCII 67232 30 internet protocol version 6 link-local address stateless autoconfiguration

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]

 draft-ietf-6lowpan-format-13 RFC6282 RFC6775 RFC8025 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4944 10.17487/RFC4944 RFC4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX B. Korver August 2007 ASCII 101495 43 internet key exchange public key infrastructure for x.509 ipsec

The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec. [STANDARDS-TRACK]

 draft-ietf-pki4ipsec-ikecert-profile-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec pki4ipsec 10.17487/RFC4945 RFC4946 Atom License Extension J. Snell July 2007 ASCII 14602 8 atom syndication format atom feeds atom entries

This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries. This memo defines an Experimental Protocol for the Internet community.

 draft-snell-atompub-feed-license-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4946 RFC4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks G. Fairhurst M. Montpetit July 2007 ASCII 102717 41 encapsulate motion picture experts group unidirectional link protocol UniDirectional Link Routing address resolution protocol

This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.

In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. This memo provides information for the Internet community.

 draft-ietf-ipdvb-ar-06 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4947 RFC4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006 L. Andersson E. Davies L. Zhang August 2007 ASCII 106199 43 spam botnet

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic. This memo provides information for the Internet community.

 draft-iab-iwout-report-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4948 10.17487/RFC4948 RFC4949 Internet Security Glossary, Version 2 R. Shirey August 2007 ASCII 867626 365 abbreviation clarity definition dictionary language punctuation synonym terminology writing

This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.

 draft-shirey-secgloss-v2-08 RFC2828 FYI0036 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4949 RFC4950 ICMP Extensions for Multiprotocol Label Switching R. Bonica D. Gan D. Tappan C. Pignataro August 2007 ASCII 15091 8 Internet Control Message Protocol

This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK]

 draft-ietf-mpls-icmp-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4950 RFC4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" V. Jain Editor August 2007 ASCII 53659 26 control connection layer 2 connectivity

Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity. [STANDARDS-TRACK]

 draft-ietf-l2tpext-failover-12 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4951 RFC4952 Overview and Framework for Internationalized Email J. Klensin Y. Ko July 2007 ASCII 48409 20 smtp

Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This memo provides information for the Internet community.

 draft-ietf-eai-framework-05 RFC6530 RFC5336 INFORMATIONAL INFORMATIONAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=4952 10.17487/RFC4952 RFC4953 Defending TCP Against Spoofing Attacks J. Touch July 2007 ASCII 72756 28 rst transport control protocol

Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community.

 draft-ietf-tcpm-tcp-antispoof-06 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4953 RFC4954 SMTP Service Extension for Authentication R. Siemborski Editor A. Melnikov Editor July 2007 ASCII 43493 20 simple mail transport protocol security layer sasl

This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.

This document obsoletes RFC 2554. [STANDARDS-TRACK]

 draft-siemborski-rfc2554bis-09 RFC2554 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4954 10.17487/RFC4954 RFC4955 DNS Security (DNSSEC) Experiments D. Blacka July 2007 ASCII 15417 7 domain namespace

This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-experiments-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC4955 RFC4956 DNS Security (DNSSEC) Opt-In R. Arends M. Kosters D. Blacka July 2007 ASCII 32033 17 domain namespace

In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnsext-dnssec-opt-in-09 EXPERIMENTAL EXPERIMENTAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4956 10.17487/RFC4956 RFC4957 Link-Layer Event Notifications for Detecting Network Attachments S. Krishnan Editor N. Montavont E. Njedjou S. Veerepalli A. Yegin Editor August 2007 ASCII 41840 18

Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. This memo provides information for the Internet community.

 draft-ietf-dna-link-information-06 INFORMATIONAL INFORMATIONAL IETF int dna http://www.rfc-editor.org/errata_search.php?rfc=4957 10.17487/RFC4957 RFC4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain K. Carlberg July 2007 ASCII 44008 28 priority prioritization preferential service

This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. This memo provides information for the Internet community.

 draft-ietf-ieprep-domain-frame-08 INFORMATIONAL INFORMATIONAL IETF rai ieprep http://www.rfc-editor.org/errata_search.php?rfc=4958 10.17487/RFC4958 RFC4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response R. Siemborski A. Gulbrandsen September 2007 ASCII 12284 7 imap authenticate internet message access protocol

To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.

This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. [STANDARDS-TRACK]

 draft-siemborski-imap-sasl-initial-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4959 10.17487/RFC4959 RFC4960 Stream Control Transmission Protocol R. Stewart Editor September 2007 ASCII 346022 152 SCTP IP internet transport packet network

This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,

-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,

-- optional bundling of multiple user messages into a single SCTP packet, and

-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]

 draft-ietf-tsvwg-2960bis-05 RFC2960 RFC3309 RFC6096 RFC6335 RFC7053 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4960 10.17487/RFC4960 RFC4961 Symmetric RTP / RTP Control Protocol (RTCP) D. Wing July 2007 ASCII 12539 6 real time transport protocol symmetric rtcp

This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-wing-behave-symmetric-rtprtcp-03 BCP0131 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4961 RFC4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management R. Housley B. Aboba July 2007 ASCII 54927 23

This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-housley-aaa-key-mgmt-09 BCP0132 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4962 RFC4963 IPv4 Reassembly Errors at High Data Rates J. Heffner M. Mathis B. Chandler July 2007 ASCII 22399 10

IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community.

 draft-heffner-frag-harmful-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4963 RFC4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular A. Allen Editor J. Holm T. Hallin September 2007 ASCII 67505 32 p-header oma open mobile alliance poc

This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application. This memo provides information for the Internet community.

 draft-allen-sipping-poc-p-answer-state-header-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4964 RFC4965 CableLabs - IETF Standardization Collaboration J-F. Mule W. Townsley September 2007 ASCII 20885 10 IETF CableLabs Collaboration liaison Cable Television Laboratories DOCSIS PacketCable OpenCable

This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs). This memo provides information for the Internet community.

 draft-mule-ietf-cablelabs-collaboration-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4965 RFC4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status C. Aoun E. Davies July 2007 ASCII 60284 25 NAT-PT v6ops

This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status. This memo provides information for the Internet community.

 draft-ietf-v6ops-natpt-to-historic-00 RFC2766 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4966 10.17487/RFC4966 RFC4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier B. Rosen July 2007 ASCII 12659 6 dialstring

RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK]

 draft-rosen-iptel-dialstring-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4967 10.17487/RFC4967 RFC4968 Analysis of IPv6 Link Models for 802.16 Based Networks S. Madanapalli Editor August 2007 ASCII 34536 16 wimax

This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks. This memo provides information for the Internet community.

 draft-ietf-16ng-ipv6-link-model-analysis-03 INFORMATIONAL INFORMATIONAL IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=4968 10.17487/RFC4968 RFC4969 IANA Registration for vCard Enumservice A. Mayrhofer August 2007 ASCII 14038 7 enum e.164

This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number.

Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. [STANDARDS-TRACK]

 draft-ietf-enum-vcard-06 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4969 RFC4970 Extensions to OSPF for Advertising Optional Router Capabilities A. Lindem Editor N. Shen JP. Vasseur R. Aggarwal S. Shaffer July 2007 ASCII 26416 13 ospfv2 ospfv3 open shortest path first ri router information lsa link state advertisement

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS-TRACK]

 draft-ietf-ospf-cap-11 RFC7770 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4970 RFC4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information JP. Vasseur Editor N. Shen Editor R. Aggarwal Editor July 2007 ASCII 18541 9 capabilty

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. [STANDARDS-TRACK]

 draft-ietf-isis-caps-07 RFC7981 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC4971 RFC4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership JP. Vasseur Editor JL. Leroux Editor S. Yasukawa S. Previdi P. Psenak P. Mabbey July 2007 ASCII 32044 15 mpls-te lsp label switched path igp is-is ospf

The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. [STANDARDS-TRACK]

 draft-ietf-ccamp-automesh-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4972 RFC4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering P. Srisuresh P. Joseph July 2007 ASCII 115361 50 ospf-te link state advertisement lsa

This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks. This memo defines an Experimental Protocol for the Internet community.

 draft-srisuresh-ospf-te-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4973 RFC4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls D. Papadimitriou A. Farrel August 2007 ASCII 72000 31

In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.

A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs).

This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation.

The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-rsvp-te-call-04 RFC3473 RFC6001 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4974 RFC4975 The Message Session Relay Protocol (MSRP) B. Campbell Editor R. Mahy Editor C. Jennings Editor September 2007 ASCII 144254 63 instant message

This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]

 draft-ietf-simple-message-sessions-19 RFC7977 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4975 10.17487/RFC4975 RFC4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP) C. Jennings R. Mahy A. B. Roach September 2007 ASCII 84244 36 instante message page-mode session-mode relay intermediary

Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS-TRACK]

 draft-ietf-simple-msrp-relays-10 RFC7977 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4976 10.17487/RFC4976 RFC4977 Problem Statement: Dual Stack Mobility G. Tsirtsis H. Soliman August 2007 ASCII 16758 8 mobility management protocol mipv4 mipv6 mobile ip

This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node. This memo provides information for the Internet community.

 draft-ietf-mip6-dsmip-problem-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4977 RFC4978 The IMAP COMPRESS Extension A. Gulbrandsen August 2007 ASCII 17554 9 Internet Message Access Protocol

The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK]

 draft-ietf-lemonade-compress-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4978 10.17487/RFC4978 RFC4979 IANA Registration for Enumservice 'XMPP' A. Mayrhofer August 2007 ASCII 11719 7 extensible messaging and presence protocol e.164

This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). [STANDARDS-TRACK]

 draft-ietf-enum-xmpp-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4979 RFC4980 Analysis of Multihoming in Network Mobility Support C. Ng T. Ernst E. Paik M. Bagnulo October 2007 ASCII 88572 39 nemo ipv6 mobile networks

This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. This memo provides information for the Internet community.

 draft-ietf-nemo-multihoming-issues-07 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4980 RFC4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods J. Risson T. Moors September 2007 ASCII 239752 91 Peer-to-peer network Distributed hash table Structured overlay Unstructured overlay Key-based routing Consistent hashing Scalable distributed data structure Dependability Hypercube Plaxton tree de Bruijn graph Skip graph Torus Butterfly network Vector model Latent semantic indexing

The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.

Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.

P2P search methods are first couched within an overall P2P taxonomy. P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. This memo provides information for the Internet community.

 draft-irtf-p2prg-survey-search-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4981 RFC4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) M. Bagnulo J. Arkko July 2007 ASCII 20961 9

This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS-TRACK]

 draft-bagnulo-multiple-hash-cga-03 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4982 10.17487/RFC4982 RFC4983 Fibre Channel Registered State Change Notification (RSCN) MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII 56049 28 management information base T11-FC-RSCN-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). [STANDARDS-TRACK]

 draft-ietf-imss-fc-rscn-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4983 RFC4984 Report from the IAB Workshop on Routing and Addressing D. Meyer Editor L. Zhang Editor K. Fall Editor September 2007 ASCII 96153 39 routing and addressing workshop routing table growth addressing architecture

This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.

 draft-iab-raws-report-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4984 10.17487/RFC4984 RFC4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name S. Santesson August 2007 ASCII 17868 10 othername

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK]

 draft-ietf-pkix-srvsan-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4985 10.17487/RFC4985 RFC4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover H. Eland R. Mundy S. Crocker S. Krishnaswamy August 2007 ASCII 22647 11 dns signed zone

Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. This memo provides information for the Internet community.

 draft-ietf-dnsext-rollover-requirements-04 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC4986 RFC4987 TCP SYN Flooding Attacks and Common Mitigations W. Eddy August 2007 ASCII 48753 19 TCP SYN Flood TCP SYN Cookies denial-of-service DoS

This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community.

 draft-ietf-tcpm-syn-flood-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4987 RFC4988 Mobile IPv4 Fast Handovers R. Koodli C. Perkins October 2007 ASCII 57921 28 mip4 delay packet loss movement detection ip address configuration loation update latency care-of address care of address coa

This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mip4-fmipv4-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4988 RFC4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks K. Shiomoto R. Papneja R. Rabbat September 2007 ASCII 50908 23 address field identifier field

This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.

The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.

This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-addressing-08 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4990 RFC4991 A Common Schema for Internet Registry Information Service Transfer Protocols A. Newton August 2007 ASCII 24418 13 iris xml

This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-common-transport-05 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4991 10.17487/RFC4991 RFC4992 XML Pipelining with Chunks for the Internet Registry Information Service A. Newton August 2007 ASCII 55848 29 tcp transport control protocol iris

This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-xpc-06 RFC3981 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4992 10.17487/RFC4992 RFC4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service A. Newton August 2007 ASCII 34383 19 iris

This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-lwz-08 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4993 10.17487/RFC4993 RFC4994 DHCPv6 Relay Agent Echo Request Option S. Zeng B. Volz K. Kinnear J. Brzozowski September 2007 ASCII 10978 6 dynamic host configuration protocol relay agent option

This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-ero-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4994 RFC4995 The RObust Header Compression (ROHC) Framework L-E. Jonsson G. Pelletier K. Sandlund July 2007 ASCII 87198 40

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc3095bis-framework-04 RFC5795 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4995 10.17487/RFC4995 RFC4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West July 2007 ASCII 183113 94

This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. [STANDARDS-TRACK]

 draft-ietf-rohc-tcp-16 RFC6846 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4996 10.17487/RFC4996 RFC4997 Formal Notation for RObust Header Compression (ROHC-FN) R. Finking G. Pelletier July 2007 ASCII 131231 62 Robust Header Compression - Formal Notation

This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. [STANDARDS-TRACK]

 draft-ietf-rohc-formal-notation-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4997 RFC4998 Evidence Record Syntax (ERS) T. Gondrom R. Brandner U. Pordesch August 2007 ASCII 66888 32 long-term archive security timestamp evidence record archive timestamp

In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]

 draft-ietf-ltans-ers-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC4998 RFC5000 Internet Official Protocol Standards RFC Editor May 2008 ASCII 222566 75

This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.

For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. This memo provides information for the Internet community.

 RFC3700 RFC7100 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC5000 RFC5001 DNS Name Server Identifier (NSID) Option R. Austein August 2007 ASCII 23754 11 domain name space namespace

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]

 draft-ietf-dnsext-nsid-02 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5001 RFC5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) G. Camarillo G. Blanco August 2007 ASCII 15137 7 3gpp ims ip multimedia subsystem

This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request. This memo provides information for the Internet community.

 draft-camarillo-sipping-profile-key-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5002 10.17487/RFC5002 RFC5003 Attachment Individual Identifier (AII) Types for Aggregation C. Metz L. Martini F. Balus J. Sugimoto September 2007 ASCII 14559 7 tlv pseudowire

The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK]

 draft-ietf-pwe3-aii-aggregate-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5003 10.17487/RFC5003 RFC5004 Avoid BGP Best Path Transitions from One External to Another E. Chen S. Sangli September 2007 ASCII 11437 6 border gateway protocol

In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. [STANDARDS-TRACK]

 draft-ietf-idr-avoid-transition-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5004 RFC5005 Feed Paging and Archiving M. Nottingham September 2007 ASCII 28937 15 atom rss

This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents. This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete". [STANDARDS-TRACK]

 draft-nottingham-atompub-feed-history-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5005 10.17487/RFC5005 RFC5006 IPv6 Router Advertisement Option for DNS Configuration J. Jeong Editor S. Park L. Beloeil S. Madanapalli September 2007 ASCII 26136 12 domain namespace

This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. This memo defines an Experimental Protocol for the Internet community.

 draft-jeong-dnsop-ipv6-dns-discovery-12 RFC6106 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5006 RFC5007 DHCPv6 Leasequery J. Brzozowski K. Kinnear B. Volz S. Zeng September 2007 ASCII 47186 23 dhc dhcp ipv6

This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-leasequery-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5007 10.17487/RFC5007 RFC5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas September 2007 ASCII 32869 15 nsa

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851. This memo provides information for the Internet community.

 draft-housley-smime-suite-b-02 RFC6318 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5008 10.17487/RFC5008 RFC5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media R. Ejza September 2007 ASCII 36092 15 IMS NGN ETSI TISPAN Gating Cut-through Call progress Charging PSTN Interworking Gateway Ringback Trust domain

This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. This memo provides information for the Internet community.

 draft-ejzak-sipping-p-em-auth-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5009 RFC5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption K. Kinnear M. Normoyle M. Stapp September 2007 ASCII 13834 7 unicast flag broadcast flag

This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. [STANDARDS-TRACK]

 draft-ietf-dhc-relay-agent-flags-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5010 RFC5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors M. StJohns September 2007 ASCII 30138 14 n-1 key n keys

This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).

This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]

 draft-ietf-dnsext-trustupdate-timers-06 STD0074 INTERNET STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5011 RFC5012 Requirements for Emergency Context Resolution with Internet Technologies H. Schulzrinne R. Marshall Editor January 2008 ASCII 54599 23 emergency calling ecrit

This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end. This memo provides information for the Internet community.

 draft-ietf-ecrit-requirements-13 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5012 10.17487/RFC5012 RFC5013 The Dublin Core Metadata Element Set J. Kunze T. Baker August 2007 ASCII 17776 9 resource description object descriptors digital library collections

This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment. This memo provides information for the Internet community.

 draft-kunze-rfc2413bis-07 RFC2413 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5013 RFC5014 IPv6 Socket API for Source Address Selection E. Nordmark S. Chakrabarti J. Laganier September 2007 ASCII 53601 24 getaddrinfo()cga cryptographically generated address

The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses. This memo provides information for the Internet community.

 draft-chakrabarti-ipv6-addrselect-api-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5014 RFC5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM) M. Handley I. Kouvelas T. Speakman L. Vicisano October 2007 ASCII 96431 43 pim sparse-mode shared trees

This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]

 draft-ietf-pim-bidir-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5015 10.17487/RFC5015 RFC5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol M. Thomas October 2007 ASCII 33710 15 cryptographic

DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD). This memo provides information for the Internet community.

 draft-ietf-dkim-ssp-requirements-05 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5016 RFC5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs) D. McWalter Editor September 2007 ASCII 14826 7 management information base URI-TC-MIB

This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). [STANDARDS-TRACK]

 draft-mcwalter-uri-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5017 RFC5018 Connection Establishment in the Binary Floor Control Protocol (BFCP) G. Camarillo September 2007 ASCII 20244 9 floor control server tls transport layer security

This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]

 draft-ietf-xcon-bfcp-connection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC5018 RFC5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments A. Deacon R. Hurst September 2007 ASCII 46371 22 OCSP Online Certificate Status Protocol certificate status http caching http proxies efficient cacheable pre-produced

This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]

 draft-ietf-pkix-lightweight-ocsp-profile-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5019 RFC5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute K. Zeilenga August 2007 ASCII 8607 5 x.500

This document describes the Lightweight Directory Access Protocol (LDAP) / X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. [STANDARDS-TRACK]

 draft-zeilenga-ldap-entrydn-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5020 RFC5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP S. Josefsson August 2007 ASCII 13431 7

This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK]

 draft-ietf-krb-wg-tcp-expansion-02 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC5021 RFC5022 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer September 2007 ASCII 184482 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

 RFC4722 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5022 10.17487/RFC5022 RFC5023 The Atom Publishing Protocol J. Gregorio Editor B. de hOra Editor October 2007 ASCII 102274 53 atompub http transfer atom syndication format

The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]

 draft-ietf-atompub-protocol-17 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub http://www.rfc-editor.org/errata_search.php?rfc=5023 10.17487/RFC5023 RFC5024 ODETTE File Transfer Protocol 2.0 I. Friend November 2007 ASCII 276953 135

This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.

The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.

The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.

 draft-friend-oftp2-04 RFC2204 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5024 10.17487/RFC5024 RFC5025 Presence Authorization Rules J. Rosenberg December 2007 ASCII 65880 28 presence systems authorization policies xml extensible markup language

Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. [STANDARDS-TRACK]

 draft-ietf-simple-presence-rules-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5025 10.17487/RFC5025 RFC5026 Mobile IPv6 Bootstrapping in Split Scenario G. Giaretta Editor J. Kempf V. Devarapalli Editor October 2007 ASCII 63138 28 mip6 bootstrapping problem statement

A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS-TRACK]

 draft-ietf-mip6-bootstrapping-split-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5026 RFC5027 Security Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen D. Wing October 2007 ASCII 37229 16 DTLS DTLS-SRTP TLS MIKEY Security Descriptions SRTP

This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. [STANDARDS-TRACK]

 draft-ietf-mmusic-securityprecondition-04 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5027 RFC5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services R. Mahy October 2007 ASCII 9804 5 'im:' uri uniform resource identifier

This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. [STANDARDS-TRACK]

 draft-ietf-enum-im-service-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5028 RFC5029 Definition of an IS-IS Link Attribute Sub-TLV JP. Vasseur S. Previdi September 2007 ASCII 9887 6 link-attributes tlv 22

This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. [STANDARDS-TRACK]

 draft-ietf-isis-link-attr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5029 RFC5030 Mobile IPv4 RADIUS Requirements M. Nakhjiri Editor K. Chowdhury A. Lior K. Leung October 2007 ASCII 20319 9 remote authentication dial-in user service mip mipv4

This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures. This memo provides information for the Internet community.

 draft-ietf-mip4-radius-requirements-04 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC5030 RFC5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services H. Schulzrinne January 2008 ASCII 32960 14 urn ecrit

The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. [STANDARDS-TRACK]

 draft-ietf-ecrit-service-urn-07 RFC7163 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5031 10.17487/RFC5031 RFC5032 WITHIN Search Extension to the IMAP Protocol E. Burger Editor September 2007 ASCII 8921 5 imap search older younger

This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. [STANDARDS-TRACK]

 draft-ietf-lemonade-search-within-05 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5032 RFC5033 Specifying New Congestion Control Algorithms S. Floyd M. Allman August 2007 ASCII 23469 10

The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tsvwg-cc-alt-04 BCP0133 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5033 RFC5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism R. Siemborski A. Menon-Sen July 2007 ASCII 24170 12 POP3-AUTH Post Office Protocol Email

This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.

This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449. [STANDARDS-TRACK]

 draft-siemborski-rfc1734bis-11 RFC1734 RFC2449 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5034 RFC5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility J. Schaad August 2007 ASCII 32674 17 validation signature certificate

In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK]

 draft-ietf-smime-escertid-06 RFC2634 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5035 10.17487/RFC5035 RFC5036 LDP Specification L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII 287101 135 label distribution protocol

The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

 draft-ietf-mpls-rfc3036bis-04 RFC3036 RFC6720 RFC6790 RFC7358 RFC7552 DRAFT STANDARD DRAFT STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5036 10.17487/RFC5036 RFC5037 Experience with the Label Distribution Protocol (LDP) L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII 13886 7

The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-experience-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5037 RFC5038 The Label Distribution Protocol (LDP) Implementation Survey Results B. Thomas L. Andersson October 2007 ASCII 46890 23 multiprotocol label switching mpls lsr label switched routers

Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label Distribution Protocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-survey2002-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5038 RFC5039 The Session Initiation Protocol (SIP) and Spam J. Rosenberg C. Jennings January 2008 ASCII 73341 28

Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. This memo provides information for the Internet community.

 draft-ietf-sipping-spam-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5039 RFC5040 A Remote Direct Memory Access Protocol Specification R. Recio B. Metzler P. Culley J. Hilland D. Garcia October 2007 ASCII 142247 66 rdmap ddp direct data placement protocol

This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). 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. It also enables a kernel bypass implementation. [STANDARDS-TRACK]

 draft-ietf-rddp-rdmap-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5040 RFC5041 Direct Data Placement over Reliable Transports H. Shah J. Pinkerton R. Recio P. Culley October 2007 ASCII 84642 38 ddp cpu

The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. [STANDARDS-TRACK]

 draft-ietf-rddp-ddp-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5041 RFC5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security J. Pinkerton E. Deleganes October 2007 ASCII 127453 52 rdma network interface card rnic

This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. [STANDARDS-TRACK]

 draft-ietf-rddp-security-10 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5042 RFC5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation C. Bestler Editor R. Stewart Editor October 2007 ASCII 38740 18 lower layer protocol llp

This document specifies an adaptation layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

 draft-ietf-rddp-sctp-07 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5043 RFC5044 Marker PDU Aligned Framing for TCP Specification P. Culley U. Elzur R. Recio S. Bailey J. Carrier October 2007 ASCII 168918 74 mpa adaaptation layer ddp direct data placement protocol transmission

Marker PDU Aligned Framing (MPA) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. [STANDARDS-TRACK]

 draft-ietf-rddp-mpa-08 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=5044 10.17487/RFC5044 RFC5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) C. Bestler Editor L. Coene October 2007 ASCII 51749 22 rdmap

This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. This memo provides information for the Internet community.

 draft-ietf-rddp-applicability-08 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC5045 RFC5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) M. Ko M. Chadalapaka J. Hufferd U. Elzur H. Shah P. Thaler October 2007 ASCII 202216 85 rdma data transfer

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol, such as the iWARP protocol suite. 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, such as the iWARP protocol suite. [STANDARDS-TRACK]

 draft-ietf-ips-iser-06 RFC7145 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5046 RFC5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) M. Chadalapaka J. Hufferd J. Satran H. Shah October 2007 ASCII 107970 49 scsi transport protocol tcp/ip

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access (RDMA)-capable IP fabrics in the future comprising TCP, the Stream Control Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. This memo provides information for the Internet community.

 draft-ietf-ips-iwarp-da-05 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC5047 RFC5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications M. Chadalapaka Editor October 2007 ASCII 80149 38 scsi iscsi protocol

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-impl-guide-09 RFC7143 RFC3720 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5048 RFC5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) C. Bormann Z. Liu R. Price G. Camarillo Editor December 2007 ASCII 47891 21

This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]

 draft-ietf-rohc-sigcomp-sip-08 RFC3486 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC5049 RFC5050 Bundle Protocol Specification K. Scott S. Burleigh November 2007 ASCII 120435 50 delay tolerant networking dtn dtnrg exchange of messages

This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).

This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-spec-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5050 10.17487/RFC5050 RFC5051 i;unicode-casemap - Simple Unicode Collation Algorithm M. Crispin October 2007 ASCII 14965 7 unicode strings i;ascii-casemap

This document describes "i;unicode-casemap", a simple case-insensitive collation for Unicode strings. It provides equality, substring, and ordering operations. [STANDARDS-TRACK]

 draft-crispin-collation-unicasemap-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5051 RFC5052 Forward Error Correction (FEC) Building Block M. Watson M. Luby L. Vicisano August 2007 ASCII 57754 25 bulk data transfer

This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452. [STANDARDS-TRACK]

 draft-ietf-rmt-fec-bb-revised-07 RFC3452 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5052 10.17487/RFC5052 RFC5053 Raptor Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer October 2007 ASCII 113743 46 fec fec encoding raptor code

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.

Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.

The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-raptor-object-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5053 RFC5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication D. Taylor T. Wu N. Mavrogiannopoulos T. Perrin November 2007 ASCII 44445 24 secure remote password protocol transport layer security

This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community.

 draft-ietf-tls-srp-14 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5054 10.17487/RFC5054 RFC5055 Server-Based Certificate Validation Protocol (SCVP) T. Freeman R. Housley A. Malpani D. Cooper W. Polk December 2007 ASCII 198764 88 certification path construction certification path validation

The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. [STANDARDS-TRACK]

 draft-ietf-pkix-scvp-33 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5055 RFC5056 On the Use of Channel Bindings to Secure Channels N. Williams November 2007 ASCII 49995 23

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK]

 draft-williams-on-channel-binding-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5056 10.17487/RFC5056 RFC5057 Multiple Dialog Usages in the Session Initiation Protocol R. Sparks November 2007 ASCII 62654 26

Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.

This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.

This is an informative document and makes no normative statements of any kind. This memo provides information for the Internet community.

 draft-ietf-sipping-dialogusage-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5057 RFC5058 Explicit Multicast (Xcast) Concepts and Options R. Boivie N. Feldman Y. Imai W. Livens D. Ooms November 2007 ASCII 80072 35 explicit multi-unicast

While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.

This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. This memo defines an Experimental Protocol for the Internet community.

 draft-ooms-xcast-basic-spec-13 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5058 10.17487/RFC5058 RFC5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) N. Bhaskar A. Gall J. Lingard S. Venaas January 2008 ASCII 100749 42 PDF 85519 rendezvous point rp multicast router

This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. [STANDARDS-TRACK]

 draft-ietf-pim-sm-bsr-12 RFC2362 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5059 10.17487/RFC5059 RFC5060 Protocol Independent Multicast MIB R. Sivaramu J. Lingard D. McWalter B. Joshi A. Kessler January 2008 ASCII 170123 90 PIM PIM-SM BIDIR-PIM PIM-DM Multicast Routing PIM-STD-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. [STANDARDS-TRACK]

 draft-ietf-pim-mib-v2-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5060 10.17487/RFC5060 RFC5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration R. Stewart Q. Xie M. Tuexen S. Maruyama M. Kozuka September 2007 ASCII 91851 41

A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. [STANDARDS-TRACK]

 draft-ietf-tsvwg-addip-sctp-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5061 RFC5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures R. Stewart M. Tuexen G. Camarillo September 2007 ASCII 29704 14

This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 4960, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960. This memo provides information for the Internet community.

 draft-ietf-tsvwg-sctpthreat-05 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5062 RFC5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart A. Satyanarayana Editor R. Rahman Editor October 2007 ASCII 58542 24 nodal faults rsvp hello state recovery

This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.

Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.

The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.

These extensions are not used to create or restore data plane state.

The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]

 draft-ietf-ccamp-rsvp-restart-ext-09 RFC2961 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5063 10.17487/RFC5063 RFC5064 The Archived-At Message Header Field M. Duerst December 2007 ASCII 20863 10

This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. [STANDARDS-TRACK]

 draft-duerst-archived-at-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5064 RFC5065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder August 2007 ASCII 28732 14 border gateway protocol tcp/ip full mesh

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.

This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

This document obsoletes RFC 3065. [STANDARDS-TRACK]

 draft-ietf-idr-rfc3065bis-06 RFC3065 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5065 10.17487/RFC5065 RFC5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili November 2007 ASCII 193465 90 Network Management Simple Network Management Protocol SNMP Management Information Base MIB Textual Conventions 2BASE-TL 10PASS-TS 802.3ah EFM PAF PME

This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets. This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. [STANDARDS-TRACK]

 draft-ietf-hubmib-efm-cu-mib-08 RFC7124 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC5066 RFC5067 Infrastructure ENUM Requirements S. Lind P. Pfautz November 2007 ASCII 14311 7 e.164 number mapping carrier

This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) This memo provides information for the Internet community.

 draft-ietf-enum-infrastructure-enum-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5067 RFC5068 Email Submission Operations: Access and Accountability Requirements C. Hutzler D. Crocker P. Resnick E. Allman T. Finch November 2007 ASCII 24481 12 spam email abuse phishing email e-mail service mime rfc2822 rfc 2822 rfc822 rfc 822 rfc2821 rfc 2821 rfc821 rfc 821 architecture mta mua msa mda user delivery relay header gateway agent sieve dsn mdn tussle mhs mail handling service message transfer agent message user agent mail submission agent mail delivery agent

Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.

Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hutzler-spamops-08 BCP0134 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5068 RFC5069 Security Threats and Requirements for Emergency Call Marking and Mapping T. Taylor Editor H. Tschofenig H. Schulzrinne M. Shanmugam January 2008 ASCII 26230 12 ecrit public safety answering points pasp

This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.

Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. This memo provides information for the Internet community.

 draft-ietf-ecrit-security-threats-05 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC5069 RFC5070 The Incident Object Description Exchange Format R. Danyliw J. Meijer Y. Demchenko December 2007 ASCII 171529 92 incident data format compuer security incident computer security incident response team csirt cert security data sharing computer network defense service provider cndsp

The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. [STANDARDS-TRACK]

 draft-ietf-inch-iodef-14 RFC7970 RFC6685 PROPOSED STANDARD PROPOSED STANDARD IETF sec inch http://www.rfc-editor.org/errata_search.php?rfc=5070 10.17487/RFC5070 RFC5071 Dynamic Host Configuration Protocol Options Used by PXELINUX D. Hankins December 2007 ASCII 26777 14 dhcp dhcp option codes

This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211. This memo provides information for the Internet community.

 draft-ietf-dhc-pxelinux-03 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC5071 RFC5072 IP Version 6 over PPP S. Varada Editor D. Haskins E. Allen September 2007 ASCII 33910 16 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.

It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.

This document obsoletes RFC 2472. [STANDARDS-TRACK]

 draft-ietf-ipv6-over-ppp-v2-03 RFC2472 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 10.17487/RFC5072 RFC5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities J.P. Vasseur Editor J.L. Le Roux Editor December 2007 ASCII 27004 13 interior gateway protocol

It is highly desired, in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. [STANDARDS-TRACK]

 draft-ietf-ccamp-te-node-cap-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5073 RFC5074 DNSSEC Lookaside Validation (DLV) S. Weiler November 2007 ASCII 23375 11 dns security trust anchors

DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain. It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publish Delegation Signer (DS) records for their children. This memo provides information for the Internet community.

 draft-weiler-dnssec-dlv-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5074 RFC5075 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden November 2007 ASCII 12499 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. [STANDARDS-TRACK]

 draft-ietf-ipv6-ra-flags-option-02 RFC5175 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=5075 10.17487/RFC5075 RFC5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol B. Hoeneisen December 2007 ASCII 44679 24 epp validation process e.164 enum enum domain name

This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. [STANDARDS-TRACK]

 draft-ietf-enum-validation-epp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5076 RFC5077 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig January 2008 ASCII 41989 20

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]

 draft-salowey-tls-rfc4507bis-01 RFC4507 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5077 10.17487/RFC5077 RFC5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline S. Dawkins October 2007 ASCII 19870 9 Internet Architecture Board Engineering Steering Group nomcom

RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in the NomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson (2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes. This memo provides information for the Internet community.

 draft-dawkins-nomcom-start-earlier-02 RFC7437 RFC3777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5078 RFC5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) J. Rosenberg December 2007 ASCII 15670 8 anonymous calls

The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. [STANDARDS-TRACK]

 draft-ietf-sip-acr-code-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5079 RFC5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes D. Nelson A. DeKok December 2007 ASCII 64138 28

This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS-TRACK]

 draft-ietf-radext-fixes-08 RFC2865 RFC2866 RFC2869 RFC3579 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5080 10.17487/RFC5080 RFC5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos November 2007 ASCII 15300 8 tls handshake protocol handshake

This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tls-openpgp-keys-11 RFC6091 EXPERIMENTAL EXPERIMENTAL IETF sec tls 10.17487/RFC5081 RFC5082 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer P. Savola Editor C. Pignataro October 2007 ASCII 36579 16 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]

 draft-ietf-rtgwg-rfc3682bis-10 RFC3682 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC5082 RFC5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type R. Housley November 2007 ASCII 22810 10 encryption mode

This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]

 draft-ietf-smime-cms-auth-enveloped-06 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5083 RFC5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) R. Housley November 2007 ASCII 21821 11 authenticated encryption algorithm

This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]

 draft-ietf-smime-cms-aes-ccm-and-gcm-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5084 10.17487/RFC5084 RFC5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires T. Nadeau Editor C. Pignataro Editor December 2007 ASCII 67847 30 pw

This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK]

 draft-ietf-pwe3-vccv-15 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5085 10.17487/RFC5085 RFC5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) A. Vainshtein Editor I. Sasson E. Metz T. Frost P. Pate December 2007 ASCII 83233 38 nxds0 psn

This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community.

 draft-ietf-pwe3-cesopsn-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC5086 RFC5087 Time Division Multiplexing over IP (TDMoIP) Y(J). Stein R. Shashoua R. Insler M. Anavi December 2007 ASCII 113071 50 TDM pseudowire PWE3 TDMoIP structure-aware TDM emulation

Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accessibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling. This memo provides information for the Internet community.

 draft-ietf-pwe3-tdmoip-06 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5087 10.17487/RFC5087 RFC5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII 40936 20 pcc path computation client open shortest path first

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]

 draft-ietf-pce-disco-proto-ospf-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5088 10.17487/RFC5088 RFC5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII 34257 17 path computation client pcc intermediate system to intermediate system

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]

 draft-ietf-pce-disco-proto-isis-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5089 10.17487/RFC5089 RFC5090 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck February 2008 ASCII 68299 33 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

 draft-ietf-radext-rfc4590bis-02 RFC4590 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5090 10.17487/RFC5090 RFC5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems X. Boyen L. Martin December 2007 ASCII 103464 63 Encryption Cryptography Security Elliptic Curves Elliptic Curve Cryptography Pairing-based Cryptography Identity-based Cryptography Identity-based Encryption Boneh-Franklin Encryption Scheme Boneh-Boyen Encryption Scheme

This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. This memo provides information for the Internet community.

 draft-martin-ibcs-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5091 10.17487/RFC5091 RFC5092 IMAP URL Scheme A. Melnikov Editor C. Newman November 2007 ASCII 65197 32 IMAP-URL remote access store Internet Message Access Protocol Uniform Resource Identifiers

IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.

This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]

 draft-ietf-lemonade-rfc2192bis-09 RFC2192 RFC4467 RFC5593 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5092 10.17487/RFC5092 RFC5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) G. Hunt December 2007 ASCII 15110 8 next-generation network rtcp xr real time control protocol extended reports transport metrics

This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre-standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. This memo provides information for the Internet community.

 draft-hunt-avt-rtcpxnq-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5093 RFC5094 Mobile IPv6 Vendor Specific Option V. Devarapalli A. Patel K. Leung December 2007 ASCII 11430 7 mobility header mip6 mipv6

There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option. [STANDARDS-TRACK]

 draft-ietf-mip6-vsm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5094 RFC5095 Deprecation of Type 0 Routing Headers in IPv6 J. Abley P. Savola G. Neville-Neil December 2007 ASCII 13423 7 ipv6 type 0 routing header traffic amplification

The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]

 draft-ietf-ipv6-deprecate-rh0-01 RFC2460 RFC4294 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5095 RFC5096 Mobile IPv6 Experimental Messages V. Devarapalli December 2007 ASCII 13669 7 mip6 mobility header mobility option mipv6

This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. [STANDARDS-TRACK]

 draft-ietf-mip6-experimental-messages-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5096 RFC5097 MIB for the UDP-Lite protocol G. Renker G. Fairhurst January 2008 ASCII 48944 23 SMIv2 UDPLITE-MIB management information base lightweight user datagram protocol

This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. [STANDARDS-TRACK]

 draft-ietf-tsvwg-udplite-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5097 RFC5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) G. Beacham S. Kumar S. Channabasappa February 2008 ASCII 159415 79 PKTC-IETF-SIG-MIB snmp simple network management protocol packetcable-compliant ipcablecom-compliant

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

 draft-ietf-ipcdn-pktc-signaling-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=5098 10.17487/RFC5098 RFC5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information B. Claise Editor January 2008 ASCII 147196 63 exporting process collecting process template records

This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP 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. [STANDARDS-TRACK]

 draft-ietf-ipfix-protocol-26 RFC7011 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5101 10.17487/RFC5101 RFC5102 Information Model for IP Flow Information Export J. Quittek S. Bryant B. Claise P. Aitken J. Meyer January 2008 ASCII 335617 171 ipfix ip flow information export protocol measured traffic observation point metering process exporting process

This memo defines an 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. [STANDARDS-TRACK]

 draft-ietf-ipfix-info-15 RFC7012 RFC6313 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5102 10.17487/RFC5102 RFC5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX) B. Trammell E. Boschi January 2008 ASCII 53534 24 flow record biflow

This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]

 draft-ietf-ipfix-biflow-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5103 10.17487/RFC5103 RFC5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) S. Wenger U. Chandra M. Westerlund B. Burman February 2008 ASCII 158098 64 real time protocol real-time protocol itu-t rec. h271 video back channel full intra request temporary maximum media stream bit rate temporal-spatial trade-off

This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.

The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]

 draft-ietf-avt-avpf-ccm-10 RFC7728 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5104 RFC5105 ENUM Validation Token Format Definition O. Lendl December 2007 ASCII 33057 17 telephone number mapping e.164

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. [STANDARDS-TRACK]

 draft-ietf-enum-validation-token-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5105 RFC5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method H. Tschofenig D. Kroeselberg A. Pashalidis Y. Ohba F. Bersani February 2008 ASCII 76645 33 cryptographic ciphersuite negotiation hash function agility identity confidentiality fragmentation fast reconnect mode

This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode. This memo defines an Experimental Protocol for the Internet community.

 draft-tschofenig-eap-ikev2-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5106 10.17487/RFC5106 RFC5107 DHCP Server Identifier Override Suboption R. Johnson J. Kumarasamy K. Kinnear M. Stapp February 2008 ASCII 14837 7 xml extensible markup langauge dynamic host configuration protocol RENEW DHCPREQUEST DHCP RENEW

This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. [STANDARDS-TRACK]

 draft-ietf-dhc-server-override-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5107 RFC5109 RTP Payload Format for Generic Forward Error Correction A. Li Editor December 2007 ASCII 100538 44 fec realtime transport protocol

This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]

 draft-ietf-avt-ulp-23 RFC2733 RFC3009 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5109 10.17487/RFC5109 RFC5110 Overview of the Internet Multicast Routing Architecture P. Savola January 2008 ASCII 56217 25 RFC 3913 RFC 2189 RFC 2201 RFC 1584

This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.

This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.

 draft-ietf-mboned-routingarch-12 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC5110 RFC5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF) B. Aboba L. Dondeti January 2008 ASCII 16740 8 working group formation bof birds of a feather

This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. This memo defines an Experimental Protocol for the Internet community.

 draft-aboba-sg-experiment-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5111 RFC5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) M. Garcia-Martin January 2008 ASCII 67257 25 communication session event notification presence

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. [STANDARDS-TRACK]

 draft-garcia-simple-presence-dictionary-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5112 RFC5113 Network Discovery and Selection Problem J. Arkko B. Aboba J. Korhonen Editor F. Bari January 2008 ASCII 93250 39

When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub- problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed. This memo provides information for the Internet community.

 draft-ietf-eap-netsel-problem-09 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC5113 RFC5114 Additional Diffie-Hellman Groups for Use with IETF Standards M. Lepinski S. Kent January 2008 ASCII 49565 23 elliptic curve ike tls ssh smime x.509

This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE).

All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography.

These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups. This memo provides information for the Internet community.

 draft-lepinski-dh-groups-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5114 RFC5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority K. Carlberg P. O'Hanlon January 2008 ASCII 17194 8 ip telephony ResourcePriority

This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. [STANDARDS-TRACK]

 draft-carlberg-trip-attribute-rp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5115 10.17487/RFC5115 RFC5116 An Interface and Algorithms for Authenticated Encryption D. McGrew January 2008 ASCII 50539 22 Encryption Authentication AEAD authenticated encryption with associated data

This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]

 draft-mcgrew-auth-enc-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5116 10.17487/RFC5116 RFC5117 RTP Topologies M. Westerlund S. Wenger January 2008 ASCII 50293 21 multi-endpoint topologies real-time transport protocol

This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This memo provides information for the Internet community.

 draft-ietf-avt-topologies-07 RFC7667 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5117 10.17487/RFC5117 RFC5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) V. Gurbani C. Boulton R. Sparks February 2008 ASCII 31829 18 Torture test IPv6 SIP

This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation. This memo provides information for the Internet community.

 draft-ietf-sipping-ipv6-torture-tests-04 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5118 10.17487/RFC5118 RFC5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) T. Edwards February 2008 ASCII 17024 9 persistent resources universal labels,

This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described. This memo provides information for the Internet community.

 draft-edwards-urn-smpte-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5119 10.17487/RFC5119 RFC5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) T. Przygienda N. Shen N. Sheth February 2008 ASCII 30318 14 is-is

This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]

 draft-ietf-isis-wg-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5120 RFC5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks B. Patil F. Xia B. Sarikaya JH. Choi S. Madanapalli February 2008 ASCII 50092 22 Neighbor Discovery Per-MS Perfix

IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. [STANDARDS-TRACK]

 draft-ietf-16ng-ipv6-over-ipv6cs-11 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=5121 10.17487/RFC5121 RFC5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre February 2008 ASCII 55566 26 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

 draft-saintandre-rfc4622bis-01 RFC4622 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5122 RFC5123 Considerations in Validating the Path in BGP R. White B. Akyol February 2008 ASCII 39948 16 bgp autonomous system path bgp as path

This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path. This memo provides information for the Internet community.

 draft-white-pathconsiderations-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5123 10.17487/RFC5123 RFC5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) J. Ott E. Carrara February 2008 ASCII 37856 18 avpf rtp communication

An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]

 draft-ietf-avt-profile-savpf-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5124 RFC5125 Reclassification of RFC 3525 to Historic T. Taylor February 2008 ASCII 6646 4 MEGACO H.248 media gateway control

This document reclassifies RFC 3525, Gateway Control Protocol Version 1, to Historic Status. This memo also obsoletes RFC 3525. This memo provides information for the Internet community.

 draft-taylor-megaco-obsol3525-01 RFC3525 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5125 RFC5126 CMS Advanced Electronic Signatures (CAdES) D. Pinkas N. Pope J. Ross March 2008 ASCII 309173 141 verifying party signer purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature.

The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined.

The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it.

The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community.

 draft-ietf-smime-cades-07 RFC3126 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5126 RFC5127 Aggregation of Diffserv Service Classes K. Chan J. Babiarz F. Baker February 2008 ASCII 43751 19 Treatment Aggregate forwarding treatment

In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. This memo provides information for the Internet community.

 draft-ietf-tsvwg-diffserv-class-aggr-07 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5127 RFC5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) P. Srisuresh B. Ford D. Kegel March 2008 ASCII 81008 32

This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. This memo provides information for the Internet community.

 draft-ietf-behave-p2p-state-06 INFORMATIONAL INFORMATIONAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5128 10.17487/RFC5128 RFC5129 Explicit Congestion Marking in MPLS B. Davie B. Briscoe J. Tay January 2008 ASCII 49496 21 Diffserv Differentiated Services QOS ECN tunnel

RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. [STANDARDS-TRACK]

 draft-ietf-tsvwg-ecn-mpls-02 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5129 RFC5130 A Policy Control Mechanism in IS-IS Using Administrative Tags S. Previdi M. Shand Editor C. Martin February 2008 ASCII 16284 8 intermediate systetm to intermediate system ip prefix distribution lsp link state protocol

This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK]

 draft-ietf-isis-admin-tags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5130 RFC5131 A MIB Textual Convention for Language Tags D. McWalter Editor December 2007 ASCII 11119 6 LANGTAG-TC-MIB

This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. [STANDARDS-TRACK]

 draft-mcwalter-langtag-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5131 RFC5132 IP Multicast MIB D. McWalter D. Thaler A. Kessler December 2007 ASCII 120340 59 managament information base IPMCAST-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 objects used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. [STANDARDS-TRACK]

 draft-ietf-mboned-ip-mcast-mib-07 RFC2932 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5132 RFC5133 Terminal Endpoint Identifier (TEI) Query Request Number Change M. Tuexen K. Morneault December 2007 ASCII 7279 4 isdn q.921-user adaptation layer iua

The Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5. However, this number is already being used by the Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129. This document updates RFC 4233 such that the message type of TEI Query Request messages is 8. [STANDARDS-TRACK]

 draft-ietf-sigtran-rfc4233update-02 RFC4233 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC5133 RFC5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards M. Mealling January 2008 ASCII 18352 10 uniform resource name Auto-ID RFID EPCglobal EPC UPC supply chain management bar code

This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. This memo provides information for the Internet community.

 draft-mealling-epc-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5134 10.17487/RFC5134 RFC5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) D. Wing T. Eckert February 2008 ASCII 36528 16 multicast application multicast nat

This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-multicast-12 BCP0135 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5135 10.17487/RFC5135 RFC5136 Defining Network Capacity P. Chimento J. Ishac February 2008 ASCII 30682 14 bandwidth bandwidth estimation capacity estimation link capacity available capacity narrow link tight link

Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. This memo provides information for the Internet community.

 draft-ietf-ippm-bw-capacity-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5136 RFC5137 ASCII Escaping of Unicode Characters J. Klensin February 2008 ASCII 27742 13 Text internationalization ascii unicode utf-8 encoding

There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-unicode-escapes-07 BCP0137 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5137 10.17487/RFC5137 RFC5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI) S. Cox February 2008 ASCII 15005 8

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application of Geoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI. The formal Namespace Identifier (NID) is "cgi". This memo provides information for the Internet community.

 draft-sjdcox-cgi-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5138 RFC5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2008 ASCII 27470 14 location civic location pidf-lo civic address

This document defines an XML format for the representation of civic location. This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. [STANDARDS-TRACK]

 draft-ietf-geopriv-revised-civic-lo-07 RFC4119 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5139 RFC5140 A Telephony Gateway REgistration Protocol (TGREP) M. Bangalore R. Kumar J. Rosenberg H. Salama D.N. Shah March 2008 ASCII 59511 28 telephony prefix soft switches telephony routing over ip trip internet telephony administrative domains itad

This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. [STANDARDS-TRACK]

 draft-ietf-iptel-tgrep-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=5140 10.17487/RFC5140 RFC5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) J. Goodwin H. Apel March 2008 ASCII 57820 28 urn nid uniform resource name namespace identification NSS

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). This memo provides information for the Internet community.

 draft-goodwin-iso-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5141 RFC5142 Mobility Header Home Agent Switch Message B. Haley V. Devarapalli H. Deng J. Kempf January 2008 ASCII 27460 13

This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. [STANDARDS-TRACK]

 draft-ietf-mip6-ha-switch-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5142 RFC5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation A. Malis J. Brayley J. Shirron L. Martini S. Vogelsang February 2008 ASCII 52534 24 psn packet switched network RFC4842

This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs). The PSNs explicitly supported by this document include MPLS and IP. Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. This memo defines a Historic Document for the Internet community.

 draft-malis-sonet-ces-mpls-09 RFC4842 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5143 RFC5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz February 2008 ASCII 30063 17 dreg iris domain registry

This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-dchk-09 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=5144 10.17487/RFC5144 RFC5145 Framework for MPLS-TE to GMPLS Migration K. Shiomoto Editor March 2008 ASCII 44646 19 multiprotocol label switching traffic engineering control plane

The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.

This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.

This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. This memo provides information for the Internet community.

 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5145 RFC5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks K. Kumaki Editor March 2008 ASCII 31624 15 multiprotocol label switching traffic engineering service provider requirements

Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).

The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.

This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. This memo provides information for the Internet community.

 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5146 RFC5147 URI Fragment Identifiers for the text/plain Media Type E. Wilde M. Duerst April 2008 ASCII 37422 17 uniform resource identifier mime entity

This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. [STANDARDS-TRACK]

 draft-wilde-text-fragment-09 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5147 RFC5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove B. Adamson February 2008 ASCII 26379 12 randomly modifying timing control traffic transmission tranmission collision

This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. This memo provides information for the Internet community.

 draft-ietf-manet-jitter-04 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5148 10.17487/RFC5148 RFC5149 Service Selection for Mobile IPv6 J. Korhonen U. Nilsson V. Devarapalli February 2008 ASCII 18746 9 mipv6 service selection mobility option proxy mobile ipv6 mobilty service subscription binding registration procedure

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 to make a specific service selection for the mobility service subscription during the binding registration procedure. This memo provides information for the Internet community.

 draft-korhonen-mip6-service-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5149 RFC5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) A. Ayyangar K. Kompella JP. Vasseur A. Farrel February 2008 ASCII 47099 19 lsp label switched paths e2e lsp lsp stitching lsp segments s-lsp

In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.

It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]

 draft-ietf-ccamp-lsp-stitching-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5150 10.17487/RFC5150 RFC5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions A. Farrel Editor A. Ayyangar JP. Vasseur February 2008 ASCII 56663 25 multiprotocol label switching mpls-te

This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.

For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK]

 draft-ietf-ccamp-inter-domain-rsvp-te-07 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5151 10.17487/RFC5151 RFC5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) JP. Vasseur Editor A. Ayyangar Editor R. Zhang February 2008 ASCII 50563 21 mpls gmpls

This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.

Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. [STANDARDS-TRACK]

 draft-ietf-ccamp-inter-domain-pd-path-comp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5152 RFC5153 IP Flow Information Export (IPFIX) Implementation Guidelines E. Boschi L. Mark J. Quittek M. Stiemerling P. Aitken April 2008 ASCII 82845 35 template mangaement exporting processes collecting processes ipfix middleboxes

The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). This memo provides information for the Internet community.

 draft-ietf-ipfix-implementation-guidelines-08 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5153 10.17487/RFC5153 RFC5154 IP over IEEE 802.16 Problem Statement and Goals J. Jee Editor S. Madanapalli J. Mandin April 2008 ASCII 29853 14 WiMAX Mobile WiMAX WiBro

This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. This memo provides information for the Internet community.

 draft-ietf-16ng-ps-goals-04 INFORMATIONAL INFORMATIONAL IETF int 16ng 10.17487/RFC5154 RFC5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence B. Laurie G. Sisson R. Arends D. Blacka March 2008 ASCII 112338 52 domain name system nsec resource record nsec3

The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]

 draft-ietf-dnsext-nsec3-13 RFC6840 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5155 10.17487/RFC5155 RFC5156 Special-Use IPv6 Addresses M. Blanchet April 2008 ASCII 11931 7 invalid routing prefix

This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. This memo provides information for the Internet community.

 draft-ietf-v6ops-rfc3330-for-ipv6-04 RFC6890 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5156 RFC5157 IPv6 Implications for Network Scanning T. Chown March 2008 ASCII 29054 13 subnet address space

The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. This memo provides information for the Internet community.

 draft-ietf-v6ops-scanning-implications-04 RFC7707 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5157 RFC5158 6to4 Reverse DNS Delegation Specification G. Huston March 2008 ASCII 25536 12 dns domain name system

This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block. This memo provides information for the Internet community.

 draft-huston-6to4-reverse-dns-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5158 10.17487/RFC5158 RFC5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection L. Dondeti Editor A. Jerichow March 2008 ASCII 13921 8 SDP IANA registration OMA BCAST

This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. This memo provides information for the Internet community.

 draft-dondeti-oma-mmusic-sdp-attrs-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5159 RFC5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) P. Levis M. Boucadair March 2008 ASCII 44317 19 sls bgp peering diffserv parallel internet

This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. This memo provides information for the Internet community.

 draft-levis-provider-qos-agreement-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5160 RFC5161 The IMAP ENABLE Extension A. Gulbrandsen Editor A. Melnikov Editor March 2008 ASCII 12220 7 Internet Message Access Protocol

Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]

 draft-gulbrandsen-imap-enable-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5161 RFC5162 IMAP4 Extensions for Quick Mailbox Resynchronization A. Melnikov D. Cridland C. Wilson March 2008 ASCII 51620 23 Internet Message Access Protocol

This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). [STANDARDS-TRACK]

 draft-ietf-lemonade-reconnect-client-06 RFC7162 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5162 10.17487/RFC5162 RFC5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) G. Fairhurst B. Collini-Nocker April 2008 ASCII 42935 18 digital video broadcasting dvb mpeg-2 ts-concat pdu-concat timestamp

This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.

The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. [STANDARDS-TRACK]

 draft-ietf-ipdvb-ule-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb 10.17487/RFC5163 RFC5164 Mobility Services Transport: Problem Statement T. Melia Editor March 2008 ASCII 33726 16 intelligent access selection ip handover mechanism

There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem. This memo provides information for the Internet community.

 draft-ietf-mipshop-mis-ps-05 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5164 RFC5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) C. Reed April 2008 ASCII 14681 7 location geospatial namespace OGC URN Open Geospatial Consortium

This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace IDentifier (NID) is "ogc". This memo provides information for the Internet community.

 draft-creed-ogc-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5165 RFC5166 Metrics for the Evaluation of Congestion Control Mechanisms S. Floyd Editor March 2008 ASCII 53609 23 transport protocol transport modeling research group tmrg

This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.

This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community.

 draft-irtf-tmrg-metrics-11 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5166 RFC5167 Media Server Control Protocol Requirements M. Dolly R. Even March 2008 ASCII 17147 9 logical entities mcp interactive voice response conferencing media services

This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.

This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. This memo provides information for the Internet community.

 draft-ietf-mediactrl-requirements-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5167 RFC5168 XML Schema for Media Control O. Levin R. Even P. Hagendorf March 2008 ASCII 17845 10 extensible markup language video fast update

This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. This memo provides information for the Internet community.

 draft-levin-mmusic-xml-media-control-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5168 RFC5169 Handover Key Management and Re-Authentication Problem Statement T. Clancy M. Nakhjiri V. Narayanan L. Dondeti March 2008 ASCII 34082 15 hokey handover key management fast re-authentication mobility

This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. This memo provides information for the Internet community.

 draft-ietf-hokey-reauth-ps-09 INFORMATIONAL INFORMATIONAL IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5169 10.17487/RFC5169 RFC5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes V. Roca C. Neumann D. Furodet June 2008 ASCII 68567 33 LDPC FEC

This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-ldpc-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5170 RFC5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol M. Foschiano April 2008 ASCII 28149 13 Ethernet switches LAN IEEE 802 spanning tree STP FEFI autonegotiation

This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.

This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. This memo provides information for the Internet community.

 draft-foschiano-udld-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5171 RFC5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol S. Varada Editor March 2008 ASCII 14646 7 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.

This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]

 draft-ietf-ipv6-compression-nego-v2-02 RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5172 RFC5173 Sieve Email Filtering: Body Extension J. Degener P. Guenther April 2008 ASCII 17429 10 search full text email

This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. [STANDARDS-TRACK]

 draft-ietf-sieve-body-09 RFC5229 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5173 RFC5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU) J-P. Evain May 2008 ASCII 13732 8 EBU namespace urn broadcast metadata classification schema

This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU. This memo provides information for the Internet community.

 draft-evain-ebu-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5174 RFC5175 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden March 2008 ASCII 12463 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available. [STANDARDS-TRACK]

 RFC5075 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5175 RFC5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba January 2008 ASCII 79541 34 user session

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

 draft-ietf-radext-rfc3576bis-13 RFC3576 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5176 10.17487/RFC5176 RFC5177 Network Mobility (NEMO) Extensions for Mobile IPv4 K. Leung G. Dommety V. Narayanan A. Petrescu April 2008 ASCII 56094 26 NEMOv4 Mobile Networks Moving Networks Mobile Router Local Fixed Node Prefix Table Mobile Network Prefix Nested Mobile Networks Nested Network Mobility

This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function.

Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]

 draft-ietf-mip4-nemo-v4-base-11 RFC6626 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5177 RFC5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type N. Williams A. Melnikov May 2008 ASCII 17262 9 domain-based-name gss-domain-based-services GSS_C_NT_DOMAINBASED_SERVICE

This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.

Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-domain-based-names-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5178 RFC5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism N. Williams May 2008 ASCII 8017 5 domain-name-based GSS_C_NT_DOMAINBASED_SERVICE

This document describes the mapping of Generic Security Service Application Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. [STANDARDS-TRACK]

 draft-ietf-kitten-krb5-gssapi-domain-based-names-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5179 RFC5180 IPv6 Benchmarking Methodology for Network Interconnect Devices C. Popoviciu A. Hamza G. Van de Velde D. Dugatkin May 2008 ASCII 41712 20 rfc2544 ipv6 benchmarking guidelines

The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. This memo provides information for the Internet community.

 draft-ietf-bmwg-ipv6-meth-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5180 10.17487/RFC5180 RFC5181 IPv6 Deployment Scenarios in 802.16 Networks M-K. Shin Editor Y-H. Han S-E. Kim D. Premec May 2008 ASCII 36671 16 Ethernet CS (Convergence Sublayer) IPv6 CS (Convergence Sublayer)

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. This memo provides information for the Internet community.

 draft-ietf-v6ops-802-16-deployment-scenarios-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5181 RFC5182 IMAP Extension for Referencing the Last SEARCH Result A. Melnikov March 2008 ASCII 24520 13 uid unique identifier searchres internet message access protocol

Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.

This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.

This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]

 draft-melnikov-imap-search-res-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5182 RFC5183 Sieve Email Filtering: Environment Extension N. Freed May 2008 ASCII 16950 10 vnd

This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. [STANDARDS-TRACK]

 draft-freed-sieve-environment-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5183 RFC5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover F. Teraoka K. Gogo K. Mitsuya R. Shibui K. Mitani May 2008 ASCII 64137 29 l2 triggers primitives l3-driven fast handover ip mobility optimizations mobopts

This document proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. This document defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-mobopts-l2-abstractions-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5184 RFC5185 OSPF Multi-Area Adjacency S. Mirtorabi P. Psenak A. Lindem Editor A. Oswal May 2008 ASCII 18698 11 open shortest path first inter-area intra-area path

This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link. [STANDARDS-TRACK]

 draft-ietf-ospf-multi-area-adj-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5185 10.17487/RFC5185 RFC5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction B. Haberman J. Martin May 2008 ASCII 12403 6 source information source-filtering group management

The definitions of the Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols. This memo provides information for the Internet community.

 draft-ietf-magma-igmpv3-and-routing-05 INFORMATIONAL INFORMATIONAL IETF int magma 10.17487/RFC5186 RFC5187 OSPFv3 Graceful Restart P. Pillay-Esnault A. Lindem June 2008 ASCII 14860 7 open shortest path first

This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-graceful-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5187 10.17487/RFC5187 RFC5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec H. Desineni Q. Xie February 2008 ASCII 44821 25

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as email. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-evrc-wb-09 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5188 RFC5189 Middlebox Communication (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor March 2008 ASCII 161167 70 nat network address translator firewall

This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989. [STANDARDS-TRACK]

 draft-ietf-midcom-rfc3989-bis-02 RFC3989 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5189 RFC5190 Definitions of Managed Objects for Middlebox Communication J. Quittek M. Stiemerling P. Srisuresh March 2008 ASCII 204929 92 management information base mib midcom MIDCOM-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 a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. [STANDARDS-TRACK]

 draft-ietf-midcom-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5190 RFC5191 Protocol for Carrying Authentication for Network Access (PANA) D. Forsberg Y. Ohba Editor B. Patil H. Tschofenig A. Yegin May 2008 ASCII 96716 46 eap exensible authentication protocol

This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK]

 draft-ietf-pana-pana-18 RFC5872 PROPOSED STANDARD PROPOSED STANDARD IETF int pana http://www.rfc-editor.org/errata_search.php?rfc=5191 10.17487/RFC5191 RFC5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents L. Morand A. Yegin S. Kumar S. Madanapalli May 2008 ASCII 14986 8 dynamic host configuration protocol pac pana client

This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents (PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs. [STANDARDS-TRACK]

 draft-ietf-dhc-paa-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5192 RFC5193 Protocol for Carrying Authentication for Network Access (PANA) Framework P. Jayaraman R. Lopez Y. Ohba Editor M. Parthasarathy A. Yegin May 2008 ASCII 24474 11

This document defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments. This memo provides information for the Internet community.

 draft-ietf-pana-framework-10 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5193 RFC5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) A. van Wijk Editor G. Gybels Editor June 2008 ASCII 68636 31 text telephone textphone deaf hard-of-hearing speech-impaired interactive text transcoding speech-to-text user alerting emergency services gateway analog terminal adapters PSTN interworking text presentation user alerting instant messaging conversation conversational text interactivity total conversation user requirements text gateway relay relay service text relay TTY text transport text interworking combination gateway

This document lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks. This memo provides information for the Internet community.

 draft-ietf-sipping-toip-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5194 RFC5195 BGP-Based Auto-Discovery for Layer-1 VPNs H. Ould-Brahim D. Fedyk Y. Rekhter June 2008 ASCII 21480 10 import route target l1vpn single-end provisioning

The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. [STANDARDS-TRACK]

 draft-ietf-l1vpn-bgp-auto-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn 10.17487/RFC5195 RFC5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) M. Lonnfors K. Kiss September 2008 ASCII 58488 30 common presence data format cpp common profile for presence

Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities. [STANDARDS-TRACK]

 draft-ietf-simple-prescaps-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5196 RFC5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions S. Fries D. Ignjatic June 2008 ASCII 76848 31 key management media stream security end-to-end SRTP

Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for \%real-time applications. In particular, it has been defined focusing on the support of the Secure \%Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.

This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing. This memo provides information for the Internet community.

 draft-ietf-msec-mikey-applicability-09 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC5197 RFC5198 Unicode Format for Network Interchange J. Klensin M. Padlipsky March 2008 ASCII 45708 19 internationalized utf-8

The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]

 draft-klensin-net-utf8-09 RFC0698 RFC0854 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5198 10.17487/RFC5198 RFC5201 Host Identity Protocol R. Moskowitz P. Nikander P. Jokela Editor T. Henderson April 2008 ASCII 240492 104 hip ip-layer state integrity protection optional encryption

This memo 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 memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-base-10 RFC7401 RFC6253 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5201 10.17487/RFC5201 RFC5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz P. Nikander April 2008 ASCII 68195 30 user data packets

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). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-esp-06 RFC7402 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5202 10.17487/RFC5202 RFC5203 Host Identity Protocol (HIP) Registration Extension J. Laganier T. Koponen L. Eggert April 2008 ASCII 26620 13 register

This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-registration-02 RFC8003 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5203 RFC5204 Host Identity Protocol (HIP) Rendezvous Extension J. Laganier L. Eggert April 2008 ASCII 30233 15 hip registration extension hip nodes hip redezvous server

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-rvs-05 RFC8004 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5204 RFC5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions P. Nikander J. Laganier April 2008 ASCII 34799 17 hip host identity protocol host identity payload dns domain name system

This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-dns-09 RFC8005 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5205 RFC5206 End-Host Mobility and Multihoming with the Host Identity Protocol P. Nikander T. Henderson Editor C. Vogt J. Arkko April 2008 ASCII 99430 40 hip multihoming extensions mobility extentions locator

This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-mm-05 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5206 RFC5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication M. Stiemerling J. Quittek L. Eggert April 2008 ASCII 27873 13 HIP host identity protocol host identity payload NAT traversal middlebox traversal firewall traversal ID locator split problem statement

The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. This memo provides information for the Internet community.

 draft-irtf-hiprg-nat-04 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5207 RFC5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 B. Kaliski May 2008 ASCII 12063 8 rsa laboratories private-key syntax change control

This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.

This document describes a syntax for private-key information. This memo provides information for the Internet community.

 draft-kaliski-pkcs8-00 RFC5958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5208 10.17487/RFC5208 RFC5209 Network Endpoint Assessment (NEA): Overview and Requirements P. Sangster H. Khosravi M. Mani K. Narayan J. Tardo June 2008 ASCII 132227 53 Posture Remediation reassessment Validator Collector Broker compliance privacy disclosure replay trust policy

This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. This memo provides information for the Internet community.

 draft-ietf-nea-requirements-07 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC5209 RFC5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience J. Wu J. Bi X. Li G. Ren K. Xu M. Williams June 2008 ASCII 58363 25 Source Address Validation Source Addressing Spoofing Network Security Testbed IPv6

Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community.

 draft-wu-sava-testbed-experience-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5210 RFC5211 An Internet Transition Plan J. Curran July 2008 ASCII 17158 8

This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model. This memo provides information for the Internet community.

 draft-jcurran-v6transitionplan-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5211 RFC5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) K. Shiomoto D. Papadimitriou JL. Le Roux M. Vigoureux D. Brungard July 2008 ASCII 70286 28 generalized mpls switching technology

Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.

In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-mln-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5212 RFC5213 Proxy Mobile IPv6 S. Gundavelli Editor K. Leung V. Devarapalli K. Chowdhury B. Patil August 2008 ASCII 226902 92 mobility management

Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. [STANDARDS-TRACK]

 draft-ietf-netlmm-proxymip6-18 RFC6543 RFC7864 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5213 10.17487/RFC5213 RFC5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson D. Thaler March 2008 ASCII 30126 15 ipv6 ipv4 non-broadcast multiple access nbma dual-stack

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo provides information for the Internet community.

 draft-templin-rfc4214bis-05 RFC4214 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5214 RFC5215 RTP Payload Format for Vorbis Encoded Audio L. Barbato August 2008 ASCII 54327 26 realtime transport protocol codebook

This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.

Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vorbis-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5215 10.17487/RFC5215 RFC5216 The EAP-TLS Authentication Protocol D. Simon B. Aboba R. Hurst March 2008 ASCII 71599 34 extensible authentication protocol point-to-point link control compression extensible transport level security

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.

This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]

 draft-simon-emu-rfc2716bis-13 RFC2716 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu http://www.rfc-editor.org/errata_search.php?rfc=5216 10.17487/RFC5216 RFC5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability M. Shimaoka Editor N. Hastings R. Nielsen July 2008 ASCII 64814 29 pki multi-domain pki pki domain

The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI. This memo provides information for the Internet community.

 draft-shimaoka-multidomain-pki-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5217 RFC5218 What Makes For a Successful Protocol? D. Thaler B. Aboba July 2008 ASCII 58409 28

The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community.

 draft-iab-protocol-success-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5218 RFC5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson February 2008 ASCII 42830 22 real time protocol real-time protocol mpeg moving picture experts group,

This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3119bis-05 RFC3119 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5219 RFC5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII 33661 17 multiple prefixes

A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. This memo provides information for the Internet community.

 draft-ietf-v6ops-addr-select-ps-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5220 10.17487/RFC5220 RFC5221 Requirements for Address Selection Mechanisms A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII 13732 7 default address selection

There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems. This memo provides information for the Internet community.

 draft-ietf-v6ops-addr-select-req-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5221 RFC5222 LoST: A Location-to-Service Translation Protocol T. Hardie A. Newton H. Schulzrinne H. Tschofenig August 2008 ASCII 123252 69 emergency services emergency call routing

This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]

 draft-ietf-ecrit-lost-10 RFC6848 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5222 10.17487/RFC5222 RFC5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) H. Schulzrinne J. Polk H. Tschofenig August 2008 ASCII 14936 8 mapping service emergency service emergency communication

The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.

This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). [STANDARDS-TRACK]

 draft-ietf-ecrit-dhc-lost-discovery-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5223 RFC5224 Diameter Policy Processing Application M. Brenner March 2008 ASCII 10283 5 policy evaluation or evaluation and enforcement pem-1 peem oma open mobile alliance

This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement). This application is needed as one of the implementations of the Open Mobile Alliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing. This memo provides information for the Internet community.

 draft-brenner-dime-peem-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5224 RFC5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite G. Pelletier K. Sandlund April 2008 ASCII 246120 124 rohc 3095 3843 4019

This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers.

This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.

The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5225 10.17487/RFC5225 RFC5226 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand May 2008 ASCII 66160 27 internet assigned numbers authority values implementations code point protocol constant protocol parameter

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).

In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.

This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-narten-iana-considerations-rfc2434bis-09 RFC2434 BCP0026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5226 10.17487/RFC5226 RFC5227 IPv4 Address Conflict Detection S. Cheshire July 2008 ASCII 53548 21 internet protocol version 4

When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. [STANDARDS-TRACK]

 draft-cheshire-ipv4-acd-06 RFC0826 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5227 RFC5228 Sieve: An Email Filtering Language P. Guenther Editor T. Showalter Editor January 2008 ASCII 87531 42

This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK]

 draft-ietf-sieve-3028bis-13 RFC3028 RFC5229 RFC5429 RFC6785 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5228 RFC5229 Sieve Email Filtering: Variables Extension K. Homme January 2008 ASCII 20023 11

In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. [STANDARDS-TRACK]

 draft-ietf-sieve-variables-08 RFC5228 RFC5173 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5229 RFC5230 Sieve Email Filtering: Vacation Extension T. Showalter N. Freed Editor January 2008 ASCII 29822 16 autoresponder

This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK]

 draft-ietf-sieve-vacation-06 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5230 10.17487/RFC5230 RFC5231 Sieve Email Filtering: Relational Extension W. Segmuller B. Leiba January 2008 ASCII 15243 9 relational operators

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.

This document obsoletes RFC 3431. [STANDARDS-TRACK]

 draft-ietf-sieve-3431bis-04 RFC3431 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5231 RFC5232 Sieve Email Filtering: Imap4flags Extension A. Melnikov January 2008 ASCII 21964 12 imap internet message access control protocol imap flags imap system flags imap keywords

Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent.

This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]

 draft-ietf-sieve-imapflags-05 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5232 RFC5233 Sieve Email Filtering: Subaddress Extension K. Murchison January 2008 ASCII 12448 7 subaddressing detailed addressing :user :detail

On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. [STANDARDS-TRACK]

 draft-ietf-sieve-rfc3598bis-05 RFC3598 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5233 10.17487/RFC5233 RFC5234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell January 2008 ASCII 26359 16 ABNF backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

 draft-crocker-rfc4234bis-01 RFC4234 RFC7405 STD0068 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5234 10.17487/RFC5234 RFC5235 Sieve Email Filtering: Spamtest and Virustest Extensions C. Daboo January 2008 ASCII 25957 13 spamtest spamtestplus virustest scores

The Sieve email filtering language "spamtest", "spamtestplus", and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests. [STANDARDS-TRACK]

 draft-ietf-sieve-spamtestbis-05 RFC3685 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5235 RFC5236 Improved Packet Reordering Metrics A. Jayasumana N. Piratla T. Banka A. Bare R. Whitner June 2008 ASCII 57805 26 reorder density rd reorder buffer-occupancy density rbd

This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.

These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. This memo provides information for the Internet community.

 draft-jayasumana-reorder-density-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5236 RFC5237 IANA Allocation Guidelines for the Protocol Field J. Arkko S. Bradner February 2008 ASCII 9303 5 ipv4 header next header field internet assigned numbers authority IP

This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-arkko-rfc2780-proto-update-02 RFC2780 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5237 10.17487/RFC5237 RFC5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) T. Phelan May 2008 ASCII 24394 10 tls transport protocol

This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]

 draft-ietf-dccp-dtls-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5238 RFC5239 A Framework for Centralized Conferencing M. Barnes C. Boulton O. Levin June 2008 ASCII 146927 57 call signaling call signalling

This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS-TRACK]

 draft-ietf-xcon-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=5239 10.17487/RFC5239 RFC5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB B. Joshi R. Bijlani June 2008 ASCII 42636 23 management information base bootstrap router bsr PIM-BSR-MIB

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 managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). [STANDARDS-TRACK]

 draft-ietf-pim-bsr-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5240 10.17487/RFC5240 RFC5241 Naming Rights in IETF Protocols A. Falk S. Bradner April 1 2008 ASCII 25304 12 april fools field naming rights

This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5241 RFC5242 A Generalized Unified Character Code: Western European and CJK Sections J. Klensin H. Alvestrand April 1 2008 ASCII 31314 14 idn latin greek cyrilllic chinese internationalized domain names

Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5242 RFC5243 OSPF Database Exchange Summary List Optimization R. Ogier May 2008 ASCII 11029 5

This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. This memo provides information for the Internet community.

 draft-ogier-ospf-dbex-opt-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5243 10.17487/RFC5243 RFC5244 Definition of Events for Channel-Oriented Telephony Signalling H. Schulzrinne T. Taylor June 2008 ASCII 55321 23 event code telephony event rtp payload

This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2833biscas-05 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5244 RFC5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols J. Rosenberg April 2010 ASCII 285120 117

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

 draft-ietf-mmusic-ice-19 RFC4091 RFC4092 RFC6336 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5245 10.17487/RFC5245 RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 T. Dierks E. Rescorla August 2008 ASCII 222395 104 idea international data algorithm symmetric transport protocol layer authentication privacy

This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

 draft-ietf-tls-rfc4346-bis-10 RFC3268 RFC4346 RFC4366 RFC4492 RFC5746 RFC5878 RFC6176 RFC7465 RFC7507 RFC7568 RFC7627 RFC7685 RFC7905 RFC7919 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5246 10.17487/RFC5246 RFC5247 Extensible Authentication Protocol (EAP) Key Management Framework B. Aboba D. Simon P. Eronen August 2008 ASCII 193535 79 extensible network access authentication key hierarchy methods

The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]

 draft-ietf-eap-keying-22 RFC3748 PROPOSED STANDARD PROPOSED STANDARD IETF int eap http://www.rfc-editor.org/errata_search.php?rfc=5247 10.17487/RFC5247 RFC5248 A Registry for SMTP Enhanced Mail System Status Codes T. Hansen J. Klensin June 2008 ASCII 23845 11 simple mail transfer protocol

The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hansen-4468upd-mailesc-registry-05 RFC3463 RFC4468 RFC4954 BCP0138 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5248 RFC5249 Templates for Internet-Drafts Containing MIB Modules D. Harrington Editor July 2008 ASCII 7362 4 network management management information base mib smiv2 template

This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-harrington-text-mib-doc-template-06 BCP0139 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5249 RFC5250 The OSPF Opaque LSA Option L. Berger I. Bryskin A. Zinin R. Coltun July 2008 ASCII 37657 17 OSPF-LSA] open shortest path first link state advertisement opaque lsas

This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.

This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]

 draft-ietf-ospf-rfc2370bis-05 RFC2370 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5250 10.17487/RFC5250 RFC5251 Layer 1 VPN Basic Mode D. Fedyk Editor Y. Rekhter Editor D. Papadimitriou R. Rabbat L. Berger July 2008 ASCII 57599 24 virtual private network l1vpn l1vpn bm

This document describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. [STANDARDS-TRACK]

 draft-ietf-l1vpn-basic-mode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5251 10.17487/RFC5251 RFC5252 OSPF-Based Layer 1 VPN Auto-Discovery I. Bryskin L. Berger July 2008 ASCII 23232 11 open shortest path first l1vpn layer 1 virtual private network

This document defines an Open Shortest Path First (OSPF) based Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. [STANDARDS-TRACK]

 draft-ietf-l1vpn-ospf-auto-discovery-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5252 10.17487/RFC5252 RFC5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode T. Takeda Editor July 2008 ASCII 42675 19 gmpls generalized multiprotocol label switching l1vpn bm

This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).

L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. This memo provides information for the Internet community.

 draft-ietf-l1vpn-applicability-basic-mode-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC5253 RFC5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) N. Bitar Editor M. Bocci Editor L. Martini Editor October 2008 ASCII 64584 27 Pseudowire PWE3 multi-segment MS-PW SS-PW S-PE T-PE

This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. This memo provides information for the Internet community.

 draft-ietf-pwe3-ms-pw-requirements-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5254 10.17487/RFC5254 RFC5255 Internet Message Access Protocol Internationalization C. Newman A. Gulbrandsen A. Melnikov June 2008 ASCII 41403 20 imap imapv4 imap4

Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. [STANDARDS-TRACK]

 draft-ietf-imapext-i18n-15 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5255 10.17487/RFC5255 RFC5256 Internet Message Access Protocol - SORT and THREAD Extensions M. Crispin K. Murchison June 2008 ASCII 40779 19 ordered subject references imap capability

This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]

 draft-ietf-imapext-sort-20 RFC5957 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5256 RFC5257 Internet Message Access Protocol - ANNOTATE Extension C. Daboo R. Gellens June 2008 ASCII 58786 31 imap

The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.

Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.

Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-imapext-annotate-16 EXPERIMENTAL EXPERIMENTAL IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5257 10.17487/RFC5257 RFC5258 Internet Message Access Protocol version 4 - LIST Command Extensions B. Leiba A. Melnikov June 2008 ASCII 65074 31 imap4 ,list lsub extended list email

IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK]

 draft-ietf-imapext-list-extensions-18 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5258 RFC5259 Internet Message Access Protocol - CONVERT Extension A. Melnikov Editor P. Coates Editor July 2008 ASCII 63831 30 IMAP Lemonade CONVERT conversion transcoding

CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. [STANDARDS-TRACK]

 draft-ietf-lemonade-convert-20 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5259 RFC5260 Sieve Email Filtering: Date and Index Extensions N. Freed July 2008 ASCII 25735 13 smtp esmtp date index

This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. [STANDARDS-TRACK]

 draft-freed-sieve-date-index-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5260 10.17487/RFC5260 RFC5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors J. Urpalainen September 2008 ASCII 78036 40

Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic &lt;add&gt;, &lt;replace&gt;, and &lt;remove&gt; directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]

 draft-ietf-simple-xml-patch-ops-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5261 10.17487/RFC5261 RFC5262 Presence Information Data Format (PIDF) Extension for Partial Presence M. Lonnfors E. Leppanen H. Khartabil J. Urpalainen September 2008 ASCII 28527 16

The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. [STANDARDS-TRACK]

 draft-ietf-simple-partial-pidf-format-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5262 RFC5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information M. Lonnfors J. Costa-Requena E. Leppanen H. Khartabil September 2008 ASCII 32556 16 pidf presence information data format

By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS-TRACK]

 draft-ietf-simple-partial-notify-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5263 RFC5264 Publication of Partial Presence Information A. Niemi M. Lonnfors E. Leppanen September 2008 ASCII 30594 15

The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. [STANDARDS-TRACK]

 draft-ietf-simple-partial-publish-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5264 RFC5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways S. Vaarala E. Klovning June 2008 ASCII 86254 39 mobile ip mobile ipv4 ipsec mipv4

This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. [STANDARDS-TRACK]

 draft-ietf-mip4-vpn-problem-solution-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5265 RFC5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) V. Devarapalli P. Eronen June 2008 ASCII 33186 15

Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mip4-mobike-connectivity-03 BCP0136 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int mip4 10.17487/RFC5266 RFC5267 Contexts for IMAP4 D. Cridland C. King July 2008 ASCII 36709 18 imap4rev1 esort context

The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. [STANDARDS-TRACK]

 draft-cridland-imap-context-05 RFC5465 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5267 RFC5268 Mobile IPv6 Fast Handovers R. Koodli Editor June 2008 ASCII 113090 48 mipv6 handover latency

Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. [STANDARDS-TRACK]

 draft-ietf-mipshop-fmipv6-rfc4068bis-07 RFC4068 RFC5568 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5268 RFC5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) J. Kempf R. Koodli June 2008 ASCII 32742 14 fast binding update

Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. [STANDARDS-TRACK]

 draft-ietf-mipshop-handover-key-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5269 RFC5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks H. Jang J. Jee Y. Han S. Park J. Cha June 2008 ASCII 42358 18 Mobile IPv6 Handover optimization Cross-layer design

This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently. This memo provides information for the Internet community.

 draft-ietf-mipshop-fh80216e-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5270 RFC5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks H. Yokota G. Dommety June 2008 ASCII 49316 22 FMIP handoff 3GPP2

Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. This memo provides information for the Internet community.

 draft-ietf-mipshop-3gfh-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5271 RFC5272 Certificate Management over CMS (CMC) J. Schaad M. Myers June 2008 ASCII 167138 83 certificate management protocol cryptographic message syntax pki public key infrastructure

This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:

1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and

2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.

CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]

 draft-ietf-pkix-2797-bis-07 RFC2797 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5272 10.17487/RFC5272 RFC5273 Certificate Management over CMS (CMC): Transport Protocols J. Schaad M. Myers June 2008 ASCII 14030 7 cryptographic message syntax http file mail tcp

This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]

 draft-ietf-pkix-cmc-trans-08 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5273 10.17487/RFC5273 RFC5274 Certificate Management Messages over CMS (CMC): Compliance Requirements J. Schaad M. Myers June 2008 ASCII 27380 13 cryptographic message syntax cmc enrollment protocol

This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. [STANDARDS-TRACK]

 draft-ietf-pkix-cmc-compl-05 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5274 RFC5275 CMS Symmetric Key Management and Distribution S. Turner June 2008 ASCII 207920 89 cryptographic message syntax symmetric cryptographic algorithms certificate management over cms cmc

This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS-TRACK]

 draft-ietf-smime-symkeydist-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5275 10.17487/RFC5275 RFC5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records C. Wallace August 2008 ASCII 27422 13 ERS Evidence Record SCVP Server-based Certificate Validation Protocol PKI artifact preservation

The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). [STANDARDS-TRACK]

 draft-ietf-ltans-ers-scvp-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC5276 RFC5277 NETCONF Event Notifications S. Chisholm H. Trevino July 2008 ASCII 70878 35 XML Extensible Markup Language NETCONF Event Asynchronous Message Notification

This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. [STANDARDS-TRACK]

 draft-ietf-netconf-notification-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC5277 RFC5278 IANA Registration of Enumservices for Voice and Video Messaging J. Livingood D. Troshynski July 2008 ASCII 39745 22 vmsg voicemsg videomsg unifmsg sip sips http https tel

This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. [STANDARDS-TRACK]

 draft-ietf-enum-vmsg-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5278 RFC5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP) A. Monrad S. Loreto July 2008 ASCII 11582 7 nid namespace identifier 3gpp

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. This memo provides information for the Internet community.

 draft-monrad-sipping-3gpp-urn-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5279 10.17487/RFC5279 RFC5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile D. Cooper S. Santesson S. Farrell S. Boeyen R. Housley W. Polk May 2008 ASCII 352580 151 X.509 v3 X.509 v2 certificate extensions

This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc3280bis-11 RFC3280 RFC4325 RFC4630 RFC6818 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5280 10.17487/RFC5280 RFC5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) P. Funk S. Blake-Wilson August 2008 ASCII 117059 51 EAP AAA Authentication TLS

EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.

 draft-funk-eap-ttls-v0-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5281 10.17487/RFC5281 RFC5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol D. Black D. McGrew August 2008 ASCII 42137 19 encryption cipher combined mode algorithms aes gcm advanced encryption standard in galois/counter mode aes ccm aes in couner with cbc-mac mode

An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.

The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. [STANDARDS-TRACK]

 draft-black-ipsec-ikev2-aead-modes-01 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5282 10.17487/RFC5282 RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) B. Decraene JL. Le Roux I. Minei July 2008 ASCII 26534 12 LDP label mapping procedures longest-match prefix aggregation

To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP).

This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-interarea-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5283 10.17487/RFC5283 RFC5284 User-Defined Errors for RSVP G. Swallow A. Farrel August 2008 ASCII 17452 9 resource reservation protocol user_error_spec error_spec

The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.

This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-user-error-spec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5284 RFC5285 A General Mechanism for RTP Header Extensions D. Singer H. Desineni July 2008 ASCII 36844 17 real-time transport protocol extmap

This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-hdrext-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5285 RFC5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates A. Atlas Editor A. Zinin Editor September 2008 ASCII 71027 31 FRR LFA recovery failure routing

This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]

 draft-ietf-rtgwg-ipfrr-spec-base-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=5286 10.17487/RFC5286 RFC5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks A. Vainshtein Y(J). Stein August 2008 ASCII 33070 16 pwe3 pseudowire emulation edge-to-edge tdmoip tdm options

This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]

 draft-ietf-pwe3-tdm-control-protocol-extensi-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5287 RFC5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS J. Salowey A. Choudhury D. McGrew August 2008 ASCII 16468 8 advanced encryption standard transport layer security data origin confidentiality

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK]

 draft-ietf-tls-rsa-aes-gcm-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5288 10.17487/RFC5288 RFC5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) E. Rescorla August 2008 ASCII 12195 6 transport layer security mac algorithm

RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). This memo provides information for the Internet community.

 draft-ietf-tls-ecc-new-mac-07 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5289 RFC5290 Comments on the Usefulness of Simple Best-Effort Traffic S. Floyd M. Allman July 2008 ASCII 48612 20 flow-rate fairness

This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping. While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic. A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path. This memo provides information for the Internet community.

 draft-floyd-tsvwg-besteffort-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5290 RFC5291 Outbound Route Filtering Capability for BGP-4 E. Chen Y. Rekhter August 2008 ASCII 23949 12 border gatway protocol orf

This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. [STANDARDS-TRACK]

 draft-ietf-idr-route-filter-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5291 10.17487/RFC5291 RFC5292 Address-Prefix-Based Outbound Route Filter for BGP-4 E. Chen S. Sangli August 2008 ASCII 10429 6 orf border gateway protocol Address Prefix Outbound Route Filter

This document defines a new Outbound Router Filter (ORF) type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-prefix-orf-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5292 RFC5293 Sieve Email Filtering: Editheader Extension J. Degener P. Guenther August 2008 ASCII 17674 9 addheadaer deleteheader

This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. [STANDARDS-TRACK]

 draft-ietf-sieve-editheader-11 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5293 RFC5294 Host Threats to Protocol Independent Multicast (PIM) P. Savola J. Lingard August 2008 ASCII 26525 12 security threat analysis

This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts. This memo provides information for the Internet community.

 draft-ietf-pim-lasthop-threats-04 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC5294 RFC5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) J. Salowey L. Dondeti V. Narayanan M. Nakhjiri August 2008 ASCII 45622 21 EAP keying EMSK DSRK DSUSRK Domain-Specific Key Derivation Usage-Specific Key Derivation

The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]

 draft-ietf-hokey-emsk-hierarchy-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5295 10.17487/RFC5295 RFC5296 EAP Extensions for EAP Re-authentication Protocol (ERP) V. Narayanan L. Dondeti August 2008 ASCII 98264 43 extensible authentication protocol authentication modes

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 not repeat 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. [STANDARDS-TRACK]

 draft-ietf-hokey-erx-14 RFC6696 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5296 10.17487/RFC5296 RFC5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) D. Harkins October 2008 ASCII 50374 26 authenticated encryption key wrapping key derivation block cipher pseudo-random function

This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. This memo provides information for the Internet community.

 draft-dharkins-siv-aes-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5297 RFC5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery T. Takeda Editor A. Farrel Editor Y. Ikejiri JP. Vasseur August 2008 ASCII 59894 26 mpls gmpls multi-domain environment end-to-end diverse Traffic Engineering LSPs

Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.

Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering".

This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community.

 draft-ietf-ccamp-inter-domain-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5298 10.17487/RFC5298 RFC5301 Dynamic Hostname Exchange Mechanism for IS-IS D. McPherson N. Shen October 2008 ASCII 11740 6 intermediate system to intermediate system routers tlv name-to-systemID

RFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.

This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]

 draft-ietf-isis-rfc2763bis-00 RFC2763 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5301 10.17487/RFC5301 RFC5302 Domain-Wide Prefix Distribution with Two-Level IS-IS T. Li H. Smit T. Przygienda October 2008 ASCII 36742 16 intermediate system to intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.

This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. [STANDARDS-TRACK]

 draft-ietf-isis-rfc2966bis-03 RFC2966 RFC1195 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5302 10.17487/RFC5302 RFC5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies D. Katz R. Saluja D. Eastlake 3rd October 2008 ASCII 23203 11 intermediate system to intermediate system

The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.

Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.

This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. [STANDARDS-TRACK]

 draft-ietf-isis-rfc3373bis-01 RFC3373 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5303 10.17487/RFC5303 RFC5304 IS-IS Cryptographic Authentication T. Li R. Atkinson October 2008 ASCII 24131 11 intermediate system to intermediate system IS-IS authentication MD5 HMAC-MD5 security routing iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.

This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]

 draft-ietf-isis-rfc3567bis-03 RFC3567 RFC1195 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5304 RFC5305 IS-IS Extensions for Traffic Engineering T. Li H. Smit October 2008 ASCII 35313 17 intermediate system to intermediate system te router lsp data units link state protocol data units

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]

 draft-ietf-isis-te-bis-00 RFC3784 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5305 RFC5306 Restart Signaling for IS-IS M. Shand L. Ginsberg October 2008 ASCII 51234 22 intermediate system to intermediate system LSP database synchronization Link State Routing

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.

This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. [STANDARDS-TRACK]

 draft-ietf-isis-rfc3847bis-00 RFC3847 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5306 RFC5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2008 ASCII 22619 12 intermediate system to intermediate system

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

 draft-ietf-isis-rfc4205bis-00 RFC4205 RFC5305 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5307 10.17487/RFC5307 RFC5308 Routing IPv6 with IS-IS C. Hopps October 2008 ASCII 13324 7 intermediate system to intermediate system tlv osi

This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]

 draft-ietf-isis-ipv6-07 RFC7775 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5308 RFC5309 Point-to-Point Operation over LAN in Link State Routing Protocols N. Shen Editor A. Zinin Editor October 2008 ASCII 21287 10 broadcast

The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. This memo provides information for the Internet community.

 draft-ietf-isis-igp-p2p-over-lan-06 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC5309 RFC5310 IS-IS Generic Cryptographic Authentication M. Bhatia V. Manral T. Li R. Atkinson R. White M. Fanto February 2009 ASCII 24521 12 IS-IS Security HMAC-SHA Cryptographic Authentication

This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.

Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]

 draft-ietf-isis-hmac-sha-07 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5310 10.17487/RFC5310 RFC5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS D. McPherson Editor L. Ginsberg S. Previdi M. Shand February 2009 ASCII 23886 12

This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]

 draft-ietf-isis-wg-extlsp-05 RFC3786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5311 RFC5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan December 2008 ASCII 45408 19 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te flooding

This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

 draft-ietf-ccamp-isis-interas-te-extension-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5316 RFC5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile S. Bryant Editor L. Andersson Editor February 2009 ASCII 18367 10 PDF 1411313 ITU-T MPLS-TP JWT GMPLS agreement PWE3 OAM transport network

This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (Operations, Administration, and Management), survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides). This memo provides information for the Internet community.

 draft-bryant-mpls-tp-jwt-report-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5317 10.17487/RFC5317 RFC5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) J. Hautakorpi G. Camarillo December 2008 ASCII 24589 12 oma open mobile alliance push to talk over cellular poc

This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list. This memo provides information for the Internet community.

 draft-hautakorpi-sipping-uri-list-handling-refused-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5318 10.17487/RFC5318 RFC5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL) F. Templin Editor February 2010 ASCII 67712 29 virtual topologies mtu maximum transmission units

For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. This document defines an Experimental Protocol for the Internet community.

 draft-templin-seal-23 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5320 10.17487/RFC5320 RFC5321 Simple Mail Transfer Protocol J. Klensin October 2008 ASCII 225929 95 SMTP]

This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]

 draft-klensin-rfc2821bis-11 RFC2821 RFC1123 RFC7504 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5321 10.17487/RFC5321 RFC5322 Internet Message Format P. Resnick Editor October 2008 ASCII 122322 57 MAIL] e-mail email electronic mail header address mailbox reply forward resend resent folding Date From Sender Reply-To To Cc Bcc Message-ID In-Reply-To References Subject Comments Keywords Resent-Date Resent-From Resent-Sender Resent-To Resent-Cc Resent-Bcc Resent-Reply-To Resent-Message-ID Return-Path Received

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]

 draft-resnick-2822upd-06 RFC2822 RFC4021 RFC6854 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5322 10.17487/RFC5322 RFC5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH J. Reschke Editor S. Reddy J. Davis A. Babich November 2008 ASCII 91077 49 HTTP Query Properties

This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. [STANDARDS-TRACK]

 draft-reschke-webdav-search-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5323 RFC5324 MIB for Fibre-Channel Security Protocols (FC-SP) C. DeSanti F. Maino K. McCloghrie September 2008 ASCII 449246 216 management information base T11-FC-SP-TC-MIB T11-FC-SP-AUTHENTICATION-MIB T11-FC-SP-ZONING-MIB T11-FC-SP-POLICY-MIB T11-FC-SP-SA-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fcsp-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC5324 RFC5325 Licklider Transmission Protocol - Motivation S. Burleigh M. Ramadas S. Farrell September 2008 ASCII 57016 23 ltp round-trip times long-haul

This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes.

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 memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-ltp-motivation-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5325 RFC5326 Licklider Transmission Protocol - Specification M. Ramadas S. Burleigh S. Farrell September 2008 ASCII 120567 54 ltp round-trip times rtt long-haul

This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

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 memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-ltp-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5326 10.17487/RFC5326 RFC5327 Licklider Transmission Protocol - Security Extensions S. Farrell M. Ramadas S. Burleigh September 2008 ASCII 23269 11 ltp radio frequency automatic repeat request arq

The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.

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 memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-ltp-extensions-08 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5327 RFC5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) A. Adolf P. MacAvock September 2008 ASCII 26369 12 tv television digital television mpeg-2 iptv multimedia content guide program guide metadata

This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. This memo provides information for the Internet community.

 draft-adolf-dvb-urn-05 RFC7354 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5328 10.17487/RFC5328 RFC5329 Traffic Engineering Extensions to OSPF Version 3 K. Ishiguro V. Manral A. Davey A. Lindem Editor September 2008 ASCII 25864 12 open shortest path first ospfv3 te

This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-traffic-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5329 RFC5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link JP. Vasseur Editor M. Meyer K. Kumaki A. Bonda October 2008 ASCII 15730 8 te lsp

Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link. [STANDARDS-TRACK]

 draft-ietf-mpls-number-0-bw-te-lsps-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5330 RFC5331 MPLS Upstream Label Assignment and Context-Specific Label Space R. Aggarwal Y. Rekhter E. Rosen August 2008 ASCII 30779 13 upstream-assigned mpls labels

RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]

 draft-ietf-mpls-upstream-label-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5331 10.17487/RFC5331 RFC5332 MPLS Multicast Encapsulations T. Eckert E. Rosen Editor R. Aggarwal Y. Rekhter August 2008 ASCII 22887 11 data link layer codepoint multiaccess media upstream-assigned label mac da medium access layer destination address

RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".

RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.

This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]

 draft-ietf-mpls-multicast-encaps-10 RFC3032 RFC4023 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5332 RFC5333 IANA Registration of Enumservices for Internet Calendaring R. Mahy B. Hoeneisen October 2009 ASCII 13945 8 ENUM iCal iMIP i TIP CalDAV

This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS-TRACK]

 draft-ietf-enum-calendar-service-04 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5333 RFC5334 Ogg Media Types I. Goncalves S. Pfeiffer C. Montgomery September 2008 ASCII 27018 14 Ogg MIME Video Audio Codecs

This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534. [STANDARDS-TRACK]

 draft-goncalves-rfc3534bis-07 RFC3534 RFC7845 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5334 RFC5335 Internationalized Email Headers A. Yang Editor September 2008 ASCII 27945 14 unicode utf-8

Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-utf8headers-12 RFC6532 RFC2045 RFC2822 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5335 10.17487/RFC5335 RFC5336 SMTP Extension for Internationalized Email Addresses J. Yao Editor W. Mao Editor September 2008 ASCII 48110 22 EAI UTF8SMTP MAIL TRANSFER

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-smtpext-13 RFC6531 RFC2821 RFC2822 RFC4952 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5336 10.17487/RFC5336 RFC5337 Internationalized Delivery Status and Disposition Notifications C. Newman A. Melnikov Editor September 2008 ASCII 36324 18 EAI DSN SMTP

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-dsn-06 RFC6533 RFC3461 RFC3462 RFC3464 RFC3798 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5337 10.17487/RFC5337 RFC5338 Using the Host Identity Protocol with Legacy Applications T. Henderson P. Nikander M. Komu September 2008 ASCII 34882 14 hip cryptographic name space network stack names api application programming interface

This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. This memo provides information for the Internet community.

 draft-ietf-hip-applications-04 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5338 RFC5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) JL. Le Roux Editor D. Papadimitriou Editor September 2008 ASCII 53998 25 general multiprotocol label switching

This document provides an evaluation of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-mln-eval-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5339 10.17487/RFC5339 RFC5340 OSPF for IPv6 R. Coltun D. Ferguson J. Moy A. Lindem July 2008 ASCII 225664 94 open shortest path first ospfv3

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).

Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).

Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.

All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-update-23 RFC2740 RFC6845 RFC6860 RFC7503 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5340 10.17487/RFC5340 RFC5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry C. Jennings V. Gurbani September 2008 ASCII 13944 7 uniform resource locator schemes

This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. [STANDARDS-TRACK]

 draft-ietf-iptel-tel-reg-06 RFC3966 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC5341 RFC5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters D. Eastlake 3rd September 2008 ASCII 42800 21 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-eastlake-ethernet-iana-considerations-08 RFC7042 RFC2153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5342 RFC5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery J. Schoenwaelder September 2008 ASCII 19938 9 snmpv3 snmpengineid localengineid

The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.

This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.

This document updates RFC 3411. [STANDARDS-TRACK]

 draft-ietf-opsawg-snmp-engineid-discovery-03 RFC3411 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5343 RFC5344 Presence and Instant Messaging Peering Use Cases A. Houri E. Aoki S. Parameswar October 2008 ASCII 18389 9 non-voip collaboration service instant messaging im

This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). This memo provides information for the Internet community.

 draft-ietf-speermint-consolidated-presence-im-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5344 RFC5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats J. Schoenwaelder October 2008 ASCII 52411 23 large-scale snmp irtf nmrg network management research group

The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.

This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.

This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group. This memo provides information for the Internet community.

 draft-irtf-nmrg-snmp-measure-06 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5345 10.17487/RFC5345 RFC5346 Operational Requirements for ENUM-Based Softswitch Use J. Lim W. Kim C. Park L. Conroy October 2008 ASCII 31050 14 Applications ENUM DNS E.164 NAPTR Softswitch Field Trial

This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.

These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. This memo provides information for the Internet community.

 draft-ietf-enum-softswitch-req-04 INFORMATIONAL INFORMATIONAL IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=5346 10.17487/RFC5346 RFC5347 Media Gateway Control Protocol Fax Package F. Andreasen D. Hancock October 2008 ASCII 86532 46 mgcp fax calls fax relay fax transmission

This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. This memo provides information for the Internet community.

 draft-andreasen-mgcp-fax-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5347 10.17487/RFC5347 RFC5348 TCP Friendly Rate Control (TFRC): Protocol Specification S. Floyd M. Handley J. Padhye J. Widmer September 2008 ASCII 133185 58 tcp-friendly rate control congestion control

This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.

This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]

 draft-ietf-dccp-rfc3448bis-06 RFC3448 RFC4342 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5348 10.17487/RFC5348 RFC5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan K. Lauter September 2008 ASCII 19706 10 ecdh elliptic curve diffie-hellman

This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community.

 draft-zhu-pkinit-ecc-04 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5349 RFC5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options J. Manner A. McDonald September 2008 ASCII 17812 8

This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]

 draft-manner-router-alert-iana-03 RFC2113 RFC3175 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5350 RFC5351 An Overview of Reliable Server Pooling Protocols P. Lei L. Ong M. Tuexen T. Dreibholz September 2008 ASCII 33062 15 rserpool

The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite. This memo provides information for the Internet community.

 draft-ietf-rserpool-overview-06 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5351 RFC5352 Aggregate Server Access Protocol (ASAP) R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII 118712 53 rserpool enrp endpoint handlespace redundancy protocol

Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.

In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.

ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.

The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-asap-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5352 RFC5353 Endpoint Handlespace Redundancy Protocol (ENRP) Q. Xie R. Stewart M. Stillman M. Tuexen A. Silverton September 2008 ASCII 83657 39 rserpool asap aggregate server access protocol fault-tolerant registry

The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-enrp-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5353 RFC5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII 50217 23 rserpool

This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-common-param-18 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5354 RFC5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats M. Stillman Editor R. Gopal E. Guttman S. Sengodan M. Holdrege September 2008 ASCII 38042 19

Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community.

 draft-ietf-rserpool-threats-15 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5355 RFC5356 Reliable Server Pooling Policies T. Dreibholz M. Tuexen September 2008 ASCII 33394 16 rserpool enrp endpoint handlespace redundancy protocol

This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-policies-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5356 RFC5357 A Two-Way Active Measurement Protocol (TWAMP) K. Hedayat R. Krzanowski A. Morton K. Yum J. Babiarz October 2008 ASCII 61960 26 two-way measaurement round-trip measurement

The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]

 draft-ietf-ippm-twamp-09 RFC5618 RFC5938 RFC6038 RFC7717 RFC7750 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5357 10.17487/RFC5357 RFC5358 Preventing Use of Recursive Nameservers in Reflector Attacks J. Damas F. Neves October 2008 ASCII 14957 7 denial of service dos

This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-reflectors-are-evil-06 BCP0140 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC5358 RFC5359 Session Initiation Protocol Service Examples A. Johnston Editor R. Sparks C. Cunningham S. Donovan K. Summers October 2008 ASCII 289446 170 sip pbx centrex features hold transfer forwarding screening park pickup redial click call flows

This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-service-examples-15 BCP0144 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5359 RFC5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis October 2008 ASCII 70658 31

SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP. [STANDARDS-TRACK]

 draft-ietf-sip-consent-framework-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5360 10.17487/RFC5360 RFC5361 A Document Format for Requesting Consent G. Camarillo October 2008 ASCII 28256 14 xml extensible markup language premission document

This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. [STANDARDS-TRACK]

 draft-ietf-sipping-consent-format-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5361 RFC5362 The Session Initiation Protocol (SIP) Pending Additions Event Package G. Camarillo October 2008 ASCII 32137 16 consent-related resource list

This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. [STANDARDS-TRACK]

 draft-ietf-sipping-pending-additions-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5362 RFC5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services G. Camarillo A.B. Roach October 2008 ASCII 22912 10

This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services. [STANDARDS-TRACK]

 draft-ietf-sipping-uri-services-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5363 RFC5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists M. Garcia-Martin G. Camarillo October 2008 ASCII 40497 17 XML copy control resource list

In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. [STANDARDS-TRACK]

 draft-ietf-sipping-capacity-attribute-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5364 RFC5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) M. Garcia-Martin G. Camarillo October 2008 ASCII 41393 18 user agent client uac sip message request uniform resource identifier list message uri list

This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]

 draft-ietf-sip-uri-list-message-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5365 RFC5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) G. Camarillo A. Johnston October 2008 ASCII 28369 13 sip uri list invite-contatined uri

This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]

 draft-ietf-sip-uri-list-conferencing-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5366 RFC5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) G. Camarillo A.B. Roach O. Levin October 2008 ASCII 18329 9 subscribe request resrouce list

This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog. [STANDARDS-TRACK]

 draft-ietf-sip-uri-list-subscribe-02 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5367 RFC5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP) G. Camarillo A. Niemi M. Isomaki M. Garcia-Martin H. Khartabil October 2008 ASCII 29389 13 sip refer refer-to multipler-refer

This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag. [STANDARDS-TRACK]

 draft-ietf-sip-multiple-refer-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5368 RFC5369 Framework for Transcoding with the Session Initiation Protocol (SIP) G. Camarillo October 2008 ASCII 20428 10 transcoding services conference bridge model third-party call control model deaf hard of hearing speech-impaired

This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. This memo provides information for the Internet community.

 draft-ietf-sipping-transc-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5369 RFC5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model G. Camarillo October 2008 ASCII 23184 11 transcoding service deaf hard of hearing speech-impaired

This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. [STANDARDS-TRACK]

 draft-ietf-sipping-transc-conf-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5370 RFC5371 RTP Payload Format for JPEG 2000 Video Streams S. Futemma E. Itakura A. Leung October 2008 ASCII 62655 31 JPEG 2000 video RTP Real-time Transport Protocol main header tile number Sony Corporation

This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-jpeg2000-20 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5371 RFC5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery A. Leung S. Futemma E. Itakura October 2008 ASCII 53150 26 Real-time Transport Protocol main header compensation priority field priority mapping table packet-number-based ordering progression-based ordering layer-based ordering resolution-based ordering component-based ordering Sony Corporation

This memo describes extended uses for the payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.

This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-jpeg2000-beam-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5372 RFC5373 Requesting Answering Modes for the Session Initiation Protocol (SIP) D. Willis Editor A. Allen November 2008 ASCII 59839 24 PoC PTT auto automatic manual answer loopback diagnostic answer-mode priv-answer-mode

This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. [STANDARDS-TRACK]

 draft-ietf-sip-answermode-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5373 RFC5374 Multicast Extensions to the Security Architecture for the Internet Protocol B. Weis G. Gross D. Ignjatic November 2008 ASCII 87729 38 ip ipsec ip multicast packets

The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast. [STANDARDS-TRACK]

 draft-ietf-msec-ipsec-extensions-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC5374 RFC5375 IPv6 Unicast Address Assignment Considerations G. Van de Velde C. Popoviciu T. Chown O. Bonness C. Hahn December 2008 ASCII 83809 35 internet protocol version 6 address architecture

One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. This memo provides information for the Internet community.

 draft-ietf-v6ops-addcon-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5375 10.17487/RFC5375 RFC5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) N. Bitar R. Zhang K. Kumaki November 2008 ASCII 33114 14 PCE PCECP inter-AS PCE inter-provider PCE inter-AS MPLS-TE inter-provider MPLS-TE inter-AS PCECP inter-provider PCECP GMPLS path computation MPLS-TE path computation path computation element path computation communication protocol path computing element Interas Interas TE

Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.

The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE. This memo provides information for the Internet community.

 draft-ietf-pce-interas-pcecp-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5376 RFC5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents J. Halpern Editor November 2008 ASCII 17843 8 contributors ietf contributions outbound rights

Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This memo provides information for the Internet community.

 draft-ietf-ipr-outbound-rights-07 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=5377 10.17487/RFC5377 RFC5378 Rights Contributors Provide to the IETF Trust S. Bradner Editor J. Contreras Editor November 2008 ASCII 37980 16 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-3978-incoming-09 RFC3978 RFC4748 RFC2026 BCP0078 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC5378 RFC5379 Guidelines for Using the Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba February 2010 ASCII 52595 23 SIP Privacy priv-value guideline

This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-munakata-sip-privacy-guideline-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5379 RFC5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management H. Soliman C. Castelluccia K. ElMalki L. Bellier October 2008 ASCII 58330 26 mobile ipv6 ipv6 neighbor discovery map mobility anchor point

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. [STANDARDS-TRACK]

 draft-ietf-mipshop-4140bis-05 RFC4140 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5380 RFC5381 Experience of Implementing NETCONF over SOAP T. Iijima Y. Atarashi H. Kimura M. Kitani H. Okita October 2008 ASCII 47724 22 simple object access protocol network configuration protocol mns network management system

This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community.

 draft-iijima-netconf-soap-implementation-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5381 10.17487/RFC5381 RFC5382 NAT Behavioral Requirements for TCP S. Guha Editor K. Biswas B. Ford S. Sivakumar P. Srisuresh October 2008 ASCII 50306 31 network address translation

This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-tcp-08 RFC7857 BCP0142 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5382 RFC5383 Deployment Considerations for Lemonade-Compliant Mobile Email R. Gellens October 2008 ASCII 28290 12

This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-lemonade-deployments-09 BCP0143 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app lemonade 10.17487/RFC5383 RFC5384 The Protocol Independent Multicast (PIM) Join Attribute Format A. Boers I. Wijnands E. Rosen November 2008 ASCII 22330 10 pim-sm multicast distribution tree pim join attribute attr_type

A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]

 draft-ietf-pim-join-attributes-06 RFC7887 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5384 10.17487/RFC5384 RFC5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs J. Touch February 2010 ASCII 38421 20 writing I-Ds writing RFCs authoring tools document preparation

This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.

The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-touch-msword-template-v2.0-07 RFC3285 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5385 10.17487/RFC5385 RFC5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec N. Williams M. Richardson November 2008 ASCII 23103 11 internet protocol security ikev1 ikev2 sas esp ah pad spd btns unauthenticated ipsec

This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). [STANDARDS-TRACK]

 draft-ietf-btns-core-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5386 10.17487/RFC5386 RFC5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) J. Touch D. Black Y. Wang November 2008 ASCII 71707 28 ipsec stand-alone btns sab channel-bound btns cbb

The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.

This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. This memo provides information for the Internet community.

 draft-ietf-btns-prob-and-applic-07 INFORMATIONAL INFORMATIONAL IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5387 10.17487/RFC5387 RFC5388 Information Model and XML Data Model for Traceroute Measurements S. Niccolini S. Tartarelli J. Quittek T. Dietz M. Swany December 2008 ASCII 156801 75 extensible markup language DISMAN-TRACEROUTE-MIB

This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. [STANDARDS-TRACK]

 draft-ietf-ippm-storetraceroutes-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5388 RFC5389 Session Traversal Utilities for NAT (STUN) J. Rosenberg R. Mahy P. Matthews D. Wing October 2008 ASCII 125650 51 SIPs NAT STUN Traversal ICE firewall TURN VOIP

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.

This document obsoletes RFC 3489. [STANDARDS-TRACK]

 draft-ietf-behave-rfc3489bis-18 RFC3489 RFC7350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5389 10.17487/RFC5389 RFC5390 Requirements for Management of Overload in the Session Initiation Protocol J. Rosenberg December 2008 ASCII 32851 14 sip overload handling 503 response

Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. This memo provides information for the Internet community.

 draft-ietf-sipping-overload-reqs-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5390 RFC5391 RTP Payload Format for ITU-T Recommendation G.711.1 A. Sollaud November 2008 ASCII 26304 14 real-time transport protocol itu telecommunication standardization sector audio coded pcmu-wb pcma-wb

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g711wb-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5391 RFC5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan January 2009 ASCII 38690 17 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te open shortest path first ospf-te

This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

 draft-ietf-ccamp-ospf-interas-te-extension-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5392 RFC5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies R. Sparks Editor S. Lawrence A. Hawrylyshen B. Campen December 2008 ASCII 48722 20 SIP application-layer application layer multimedia multicast unicast

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.

This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]

 draft-ietf-sip-fork-loop-fix-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5393 RFC5394 Policy-Enabled Path Computation Framework I. Bryskin D. Papadimitriou L. Berger J. Ash December 2008 ASCII 82226 36 PCE pce policy

The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. This memo provides information for the Internet community.

 draft-ietf-pce-policy-enabled-path-comp-04 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5394 RFC5395 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd November 2008 ASCII 33725 17 RRTYPE RCODE AFSDB

Internet Assigned Number Authority (IANA) parameter assignment considerations are specified 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsext-2929bis-07 RFC2929 RFC6195 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5395 10.17487/RFC5395 RFC5396 Textual Representation of Autonomous System (AS) Numbers G. Huston G. Michaelson December 2008 ASCII 5373 3 decimal value

A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number. This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. [STANDARDS-TRACK]

 draft-ietf-idr-as-representation-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5396 RFC5397 WebDAV Current Principal Extension W. Sanchez C. Daboo December 2008 ASCII 8828 5 http webdav access control acl authentication

This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. [STANDARDS-TRACK]

 draft-sanchez-webdav-current-principal-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5397 RFC5398 Autonomous System (AS) Number Reservation for Documentation Use G. Huston December 2008 ASCII 5433 4 autonomous system numbers asn

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. This memo provides information for the Internet community.

 draft-ietf-idr-as-documentation-reservation-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC5398 RFC5401 Multicast Negative-Acknowledgment (NACK) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2008 ASCII 109312 42

This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-norm-revised-07 RFC3941 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5401 RFC5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message T. Harding Editor February 2010 ASCII 14469 7 internet edi

This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ediint-compression-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5402 RFC5403 RPCSEC_GSS Version 2 M. Eisler February 2009 ASCII 30812 14 Kerberos ONC RPC security authentication integrity GSS GSS-API privacy confidentiality encryption MIC NFS credential verifier mechanism context

This document describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API). [STANDARDS-TRACK]

 draft-ietf-nfsv4-rpcsec-gss-v2-06 RFC2203 RFC7861 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5403 RFC5404 RTP Payload Format for G.719 M. Westerlund I. Johansson January 2009 ASCII 64644 27 ITU-T g.719 full-band codec

This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g719-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5404 10.17487/RFC5404 RFC5405 Unicast UDP Usage Guidelines for Application Designers L. Eggert G. Fairhurst November 2008 ASCII 69607 27 user datagram protocol congestion control

The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tsvwg-udp-guidelines-11 BCP0145 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5405 RFC5406 Guidelines for Specifying the Use of IPsec Version 2 S. Bellovin February 2009 ASCII 30393 13 internet security security considerations

The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bellovin-useipsec-10 BCP0146 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5406 RFC5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP) M. Hasebe J. Koshiko Y. Suzuki T. Yoshikawa P. Kyzivat December 2008 ASCII 120005 60 sip user agents sip ua sip proxy servers

This document gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-race-examples-06 BCP0147 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5407 RFC5408 Identity-Based Encryption Architecture and Supporting Data Structures G. Appenzeller L. Martin M. Schertler January 2009 ASCII 62160 30 public key public-key encryption technology

This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. This memo provides information for the Internet community.

 draft-ietf-smime-ibearch-09 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5408 RFC5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS) L. Martin M. Schertler January 2009 ASCII 25481 13 bf bbq content-encryption keys

This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. This memo provides information for the Internet community.

 draft-ietf-smime-bfibecms-10 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5409 RFC5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 A. Jerichow Editor L. Piron January 2009 ASCII 12444 7 MIKEY Extension IANA registration OMA BCAST draft-jerichow-msec-mikey-genext-oma-00 RFC4909 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5410 RFC5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) J. Rosenberg February 2009 ASCII 96538 39 42 don't panic sip overview,

The Session Initiation Protocol (SIP) 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 SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. This memo provides information for the Internet community.

 draft-ietf-sip-hitchhikers-guide-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5411 RFC5412 Lightweight Access Point Protocol P. Calhoun R. Suri N. Cam-Winget M. Williams S. Hares B. O'Hara S. Kelly February 2010 ASCII 262297 125 lwapp capwap

In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.

The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. This document defines a Historic Document for the Internet community.

 draft-ohara-capwap-lwapp-04 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5412 10.17487/RFC5412 RFC5413 SLAPP: Secure Light Access Point Protocol P. Narasimhan D. Harkins S. Ponnuswamy February 2010 ASCII 147426 75 capwap

The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.

In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.

Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). This document defines a Historic Document for the Internet community.

 draft-narasimhan-ietf-slapp-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5413 RFC5414 Wireless LAN Control Protocol (WiCoP) S. Iino S. Govindan M. Sugiura H. Cheng February 2010 ASCII 118969 54 wlan wireless local area network twp wireless termination points capwap control and provisioning of wireless access points

The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common.

The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community.

 draft-iino-capwap-wicop-02 RFC5415 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5414 RFC5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII 345381 155 LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK]

 draft-ietf-capwap-protocol-specification-15 RFC5414 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5415 10.17487/RFC5415 RFC5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII 175870 76 Operations and Management LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]

 draft-ietf-capwap-protocol-binding-ieee80211-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5416 10.17487/RFC5416 RFC5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option P. Calhoun March 2009 ASCII 11551 6 CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS-TRACK]

 draft-ietf-capwap-dhc-ac-option-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap 10.17487/RFC5417 RFC5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments S. Kelly T. Clancy March 2009 ASCII 74169 34 WLAN security

Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a \%stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. This memo provides information for the Internet community.

 draft-ietf-capwap-threat-analysis-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5418 RFC5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6) B. Patil G. Dommety January 2009 ASCII 45178 19 authentication signaling message mn ha

Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments. This memo provides information for the Internet community.

 draft-ietf-mip6-whyauthdataoption-07 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC5419 RFC5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou JP. Vasseur A. Ayyangarps February 2009 ASCII 47668 22 multiprotocol label switching label switched paths SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.

This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc4420bis-03 RFC4420 RFC3209 RFC3473 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5420 10.17487/RFC5420 RFC5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget H. Zhou March 2009 ASCII 22345 10 generic token card eap-gtc

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer. This memo provides information for the Internet community.

 draft-zhou-emu-fast-gtc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5421 RFC5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou March 2009 ASCII 85200 39

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP- FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. This memo provides information for the Internet community.

 draft-cam-winget-eap-fast-provisioning-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5422 RFC5423 Internet Message Store Events R. Gellens C. Newman March 2009 ASCII 34800 17 imap

One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.

This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. [STANDARDS-TRACK]

 draft-ietf-lemonade-msgevent-07 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5423 10.17487/RFC5423 RFC5424 The Syslog Protocol R. Gerhards March 2009 ASCII 85162 38 event notification message syslog message berkeley software distribution transmission messages

This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.

This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]

 draft-ietf-syslog-protocol-23 RFC3164 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5424 10.17487/RFC5424 RFC5425 Transport Layer Security (TLS) Transport Mapping for Syslog F. Miao Editor Y. Ma Editor J. Salowey Editor March 2009 ASCII 28159 13 syslog message syslog security

This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. [STANDARDS-TRACK]

 draft-ietf-syslog-transport-tls-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5425 10.17487/RFC5425 RFC5426 Transmission of Syslog Messages over UDP A. Okmianski March 2009 ASCII 19354 9 udp User Datagram Protocol

This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. [STANDARDS-TRACK]

 draft-ietf-syslog-transport-udp-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5426 RFC5427 Textual Conventions for Syslog Management G. Keeni March 2009 ASCII 17829 8 syslog facility syslog severity MIB textual-convention

This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-syslog-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5427 RFC5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices S. Channabasappa W. De Ketelaere E. Nechamkin April 2009 ASCII 78139 37 snmp simple network management protocol multimedia terminal adapter PKTC-IETF-EVENT-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 a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

 draft-ietf-ipcdn-pktc-eventmess-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC5428 RFC5429 Sieve Email Filtering: Reject and Extended Reject Extensions A. Stone Editor March 2009 ASCII 28822 14 sieve refuse reject ereject joe-job smtp lmtp spam

This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028.

A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.

This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible.

The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. [STANDARDS-TRACK]

 draft-ietf-sieve-refuse-reject-09 RFC3028 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5429 RFC5430 Suite B Profile for Transport Layer Security (TLS) M. Salter E. Rescorla R. Housley March 2009 ASCII 27586 12 nsa suite b cryptography

The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible. This memo provides information for the Internet community.

 draft-rescorla-tls-suiteb-11 RFC6460 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5430 RFC5431 Diameter ITU-T Rw Policy Enforcement Interface Application D. Sun March 2009 ASCII 10412 5 diameter command code itu-t ITU-T Rw Policy-Install-Request pir Policy-Install-Answer pia

This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). This memo provides information for the Internet community.

 draft-sun-dime-itu-t-rw-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5431 RFC5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) J. Polk S. Dhesikan G. Camarillo March 2009 ASCII 17614 9 offer/answer media stream

The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. [STANDARDS-TRACK]

 draft-ietf-mmusic-qos-identification-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5432 RFC5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method T. Clancy H. Tschofenig February 2009 ASCII 80452 38 EAP EAP-GPSK pre-shared key

This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. [STANDARDS-TRACK]

 draft-ietf-emu-eap-gpsk-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC5433 RFC5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session T. Narten February 2009 ASCII 33887 13 ietf bof working group

This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK]

 draft-narten-successful-bof-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5434 RFC5435 Sieve Email Filtering: Extension for Notifications A. Melnikov Editor B. Leiba Editor W. Segmuller T. Martin January 2009 ASCII 36181 17

Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-12 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5435 RFC5436 Sieve Notification Mechanism: mailto B. Leiba M. Haardt January 2009 ASCII 26519 12 eletctronic mail notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-mailto-10 RFC3834 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5436 RFC5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre A. Melnikov January 2009 ASCII 28448 14 jabber

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-xmpp-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5437 RFC5438 Instant Message Disposition Notification (IMDN) E. Burger H. Khartabil February 2009 ASCII 83723 38 im instant messaging cpim common presence and instant messaging

Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages.

The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.

This document also describes how SIP entities behave using this extension. [STANDARDS-TRACK]

 draft-ietf-simple-imdn-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5438 10.17487/RFC5438 RFC5439 An Analysis of Scaling Issues in MPLS-TE Core Networks S. Yasukawa A. Farrel O. Komolafe February 2009 ASCII 93845 45 multiprotocol label switching traffic engineered scaling concerns lsp label switch path point-to-point mpls-te lsps

Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.

This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.

This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study. This memo provides information for the Internet community.

 draft-ietf-mpls-te-scaling-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5439 10.17487/RFC5439 RFC5440 Path Computation Element (PCE) Communication Protocol (PCEP) JP. Vasseur Editor JL. Le Roux Editor March 2009 ASCII 190529 87 MPLS GMPLS Traffic Engineering Label Switched Path

This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]

 draft-ietf-pce-pcep-19 RFC7896 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5440 10.17487/RFC5440 RFC5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths JP. Vasseur Editor R. Zhang N. Bitar JL. Le Roux April 2009 ASCII 39936 18 te lsp path computation element

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. 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 procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]

 draft-ietf-pce-brpc-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5441 10.17487/RFC5441 RFC5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail E. Burger G. Parsons March 2009 ASCII 28758 15 enhancements to internet email to supportt diverse service environments Phone

This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF. This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service. This memo provides information for the Internet community.

 draft-ietf-lemonade-architecture-04 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5442 RFC5443 LDP IGP Synchronization M. Jork A. Atlas L. Fang March 2009 ASCII 15475 7 label distribution protocol interior gateway protocol

In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-igp-sync-04 RFC6138 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5443 10.17487/RFC5443 RFC5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format T. Clausen C. Dearlove J. Dean C. Adjih February 2009 ASCII 139048 60 routing TLV address

This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. [STANDARDS-TRACK]

 draft-ietf-manet-packetbb-17 RFC7631 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5444 10.17487/RFC5444 RFC5445 Basic Forward Error Correction (FEC) Schemes M. Watson March 2009 ASCII 41713 19 content stream delivery multicast internet protocol

This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-basic-schemes-revised-06 RFC3452 RFC3695 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5445 10.17487/RFC5445 RFC5446 Service Selection for Mobile IPv4 J. Korhonen U. Nilsson February 2009 ASCII 19089 9 internet protocol version 4 host name agent mobility service subscription

In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node. The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure. This memo provides information for the Internet community.

 draft-korhonen-mip4-service-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5446 RFC5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction J. Korhonen Editor J. Bournelle H. Tschofenig C. Perkins K. Chowdhury February 2009 ASCII 38656 17 Diameter Mobile IPv6 Integrated Scenario

A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface. [STANDARDS-TRACK]

 draft-ietf-dime-mip6-integrated-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5447 10.17487/RFC5447 RFC5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') J. Arkko V. Lehtovirta P. Eronen May 2009 ASCII 60641 29 EAP AKA AKA' 3GPP

This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.

This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.

 draft-arkko-eap-aka-kdf-10 RFC4187 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5448 RFC5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks E. Baccelli P. Jacquet D. Nguyen T. Clausen February 2009 ASCII 67216 31 open shortest path first interface type mobile ad hoc

This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type". This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ospf-manet-mpr-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5449 10.17487/RFC5449 RFC5450 Transmission Time Offsets in RTP Streams D. Singer H. Desineni March 2009 ASCII 17073 8 real-time transport IJ inter-arrival jitter

This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-toffset-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5450 RFC5451 Message Header Field for Indicating Message Authentication Status M. Kucherawy April 2009 ASCII 97404 43 authentication-results email authentication result

This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS-TRACK]

 draft-kucherawy-sender-auth-header-20 RFC7001 RFC6577 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5451 10.17487/RFC5451 RFC5452 Measures for Making DNS More Resilient against Forged Answers A. Hubert R. van Mook January 2009 ASCII 37432 18 spoofing source port hardening

The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.

Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.

By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]

 draft-ietf-dnsext-forgery-resilience-10 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5452 RFC5453 Reserved IPv6 Interface Identifiers S. Krishnan February 2009 ASCII 11754 6 unicast address

Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. [STANDARDS-TRACK]

 draft-ietf-6man-reserved-iids-03 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5453 RFC5454 Dual-Stack Mobile IPv4 G. Tsirtsis V. Park H. Soliman March 2009 ASCII 38606 18 ipv6 mipv4

This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. [STANDARDS-TRACK]

 draft-ietf-mip4-dsmipv4-10 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5454 10.17487/RFC5454 RFC5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol S. Sivabalan Editor J. Parker S. Boutros K. Kumaki March 2009 ASCII 16780 9 classtype ds-te diffserv-aware traffic engineering pce

This document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). [STANDARDS-TRACK]

 draft-ietf-pce-dste-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5455 10.17487/RFC5455 RFC5456 IAX: Inter-Asterisk eXchange Version 2 M. Spencer B. Capouch E. Guy Editor F. Miller K. Shumard February 2010 ASCII 226083 101 asterisk private branch exchange pbx voip voice over internet protocol

This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.

IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-guy-iax-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5456 RFC5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 E. Guy Editor February 2010 ASCII 50952 21 asterisk private branch exchange pbx voip voice over internet protocol

This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-guy-iaxiana-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5457 10.17487/RFC5457 RFC5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol H. Cruickshank P. Pillai M. Noisternig S. Iyengar March 2009 ASCII 58733 26 iso 13818-1 transport stream ts ule stream gse generic stream encapsulation

The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC 4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.

The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. This memo provides information for the Internet community.

 draft-ietf-ipdvb-sec-req-09 INFORMATIONAL INFORMATIONAL IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=5458 10.17487/RFC5458 RFC5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support A. Sollaud January 2009 ASCII 14671 7 real-time transport protocol rtp itu-t international telecommunication union g.729.1 audio codec

This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. [STANDARDS-TRACK]

 draft-ietf-avt-rfc4749-dtx-update-03 RFC4749 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5459 RFC5460 DHCPv6 Bulk Leasequery M. Stapp February 2009 ASCII 40629 18 dynamic hos configuration protocol ipv6 dhcpv6 bindings

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-bulk-leasequery-06 RFC7653 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5460 10.17487/RFC5460 RFC5461 TCP's Reaction to Soft Errors F. Gont February 2009 ASCII 31749 13 icmp Internet Control Message Protocol

This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. This memo provides information for the Internet community.

 draft-ietf-tcpm-tcp-soft-errors-09 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5461 RFC5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field L. Andersson R. Asati February 2009 ASCII 19372 9 exp class of service cos tc field

The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".

Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.

To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]

 draft-ietf-mpls-cosfield-def-08 RFC3032 RFC3270 RFC3272 RFC3443 RFC3469 RFC3564 RFC3985 RFC4182 RFC4364 RFC4379 RFC4448 RFC4761 RFC5129 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5462 10.17487/RFC5462 RFC5463 Sieve Email Filtering: Ihave Extension N. Freed March 2009 ASCII 12481 6 SMTP ESMTP

This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. [STANDARDS-TRACK]

 draft-freed-sieve-ihave-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5463 RFC5464 The IMAP METADATA Extension C. Daboo February 2009 ASCII 39425 20 internet message access protocol annotation metadata

The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK]

 draft-daboo-imap-annotatemore-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5464 10.17487/RFC5464 RFC5465 The IMAP NOTIFY Extension A. Gulbrandsen C. King A. Melnikov February 2009 ASCII 46208 22 Internet Message Access Protocol

This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. [STANDARDS-TRACK]

 draft-ietf-lemonade-imap-notify-07 RFC5267 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5465 10.17487/RFC5465 RFC5466 IMAP4 Extension for Named Searches (Filters) A. Melnikov C. King February 2009 ASCII 19415 9 Internet Message Access Protocol

The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. [STANDARDS-TRACK]

 draft-melnikov-imapext-filters-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5466 RFC5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) L. Berger A. Takacs D. Caviglia D. Fedyk J. Meuric March 2009 ASCII 29335 14 RSVP-TE TSPEC ADSPEC

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ccamp-asymm-bw-bidir-lsps-02 RFC6387 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5467 10.17487/RFC5467 RFC5468 Performance Analysis of Inter-Domain Path Computation Methodologies S. Dasgupta J. de Oliveira JP. Vasseur April 2009 ASCII 24151 10 pce path computation element brpc backward recursive path computation

This document presents a performance comparison between the per-domain path computation method and the Path Computation Element (PCE) Architecture-based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. This memo provides information for the Internet community.

 draft-dasgupta-ccamp-path-comp-analysis-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5468 RFC5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS) P. Eronen Editor February 2009 ASCII 8558 4 ciphersuite data encryption standard international data encryption algorithm

Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. This memo provides information for the Internet community.

 draft-ietf-tls-des-idea-02 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5469 RFC5470 Architecture for IP Flow Information Export G. Sadasivan N. Brownlee B. Claise J. Quittek March 2009 ASCII 65717 31 ipfix ipfix device ipfix collector

This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. This memo provides information for the Internet community.

 draft-ietf-ipfix-architecture-12 RFC6183 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5470 RFC5471 Guidelines for IP Flow Information Export (IPFIX) Testing C. Schmoll P. Aitken B. Claise March 2009 ASCII 69313 32 exporting process collecting process

This document presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. This memo provides information for the Internet community.

 draft-ietf-ipfix-testing-05 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5471 RFC5472 IP Flow Information Export (IPFIX) Applicability T. Zseby E. Boschi N. Brownlee B. Claise March 2009 ASCII 71379 31 ie information element PSAMP measurement QoS monitoring attack detection AAA ipfix framework

In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. This memo provides information for the Internet community.

 draft-ietf-ipfix-as-12 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5472 10.17487/RFC5472 RFC5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports E. Boschi L. Mark B. Claise March 2009 ASCII 64654 27

This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.

This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community.

 draft-ietf-ipfix-reducing-redundancy-04 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5473 10.17487/RFC5473 RFC5474 A Framework for Packet Selection and Reporting N. Duffield Editor D. Chiou B. Claise A. Greenberg M. Grossglauser J. Rexford March 2009 ASCII 86080 38 psamp selector collector

This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of the PSAMP functions. This memo provides information for the Internet community.

 draft-ietf-psamp-framework-13 INFORMATIONAL INFORMATIONAL IETF ops psamp 10.17487/RFC5474 RFC5475 Sampling and Filtering Techniques for IP Packet Selection T. Zseby M. Molina N. Duffield S. Niccolini F. Raspall March 2009 ASCII 101260 46 psamp metering process

This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]

 draft-ietf-psamp-sample-tech-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp 10.17487/RFC5475 RFC5476 Packet Sampling (PSAMP) Protocol Specifications B. Claise Editor A. Johnson J. Quittek March 2009 ASCII 101620 45 exporting process collecting process ipfix ip flow information export

This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK]

 draft-ietf-psamp-protocol-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5476 10.17487/RFC5476 RFC5477 Information Model for Packet Sampling Exports T. Dietz B. Claise P. Aitken F. Dressler G. Carle March 2009 ASCII 84673 46 psamp ipfix ip flow information export

This memo defines an information model for the Packet SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]

 draft-ietf-psamp-info-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5477 10.17487/RFC5477 RFC5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces J. Polk March 2009 ASCII 12810 6 us defense information systems agency

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS-TRACK]

 draft-ietf-sip-rph-new-namespaces-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5478 RFC5479 Requirements and Analysis of Media Security Management Protocols D. Wing Editor S. Fries H. Tschofenig F. Audet April 2009 ASCII 99096 45 keying Secure RTP SRTP

This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. This memo provides information for the Internet community.

 draft-ietf-sip-media-security-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5479 10.17487/RFC5479 RFC5480 Elliptic Curve Cryptography Subject Public Key Information S. Turner D. Brown K. Yiu R. Housley T. Polk March 2009 ASCII 36209 20 x.509 asn.1 subjectPubicKeyInfo

This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]

 draft-ietf-pkix-ecc-subpubkeyinfo-11 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5480 10.17487/RFC5480 RFC5481 Packet Delay Variation Applicability Statement A. Morton B. Claise March 2009 ASCII 92218 39 active measurement ipdv pdv inter-packet delay variation

Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.

Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.

 draft-ietf-ippm-delay-var-as-02 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5481 RFC5482 TCP User Timeout Option L. Eggert F. Gont March 2009 ASCII 33568 14 Transmission Control Protocol

The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]

 draft-ietf-tcpm-tcp-uto-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5482 RFC5483 ENUM Implementation Issues and Experiences L. Conroy K. Fujiwara March 2009 ASCII 72780 30 DNS E.164 NAPTR dynamic delegation discovery system

This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents. This memo provides information for the Internet community.

 draft-ietf-enum-experiences-11 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5483 RFC5484 Associating Time-Codes with RTP Streams D. Singer March 2009 ASCII 25408 13 smpte society of motion picture and television engineers media stream

This document describes a mechanism for associating \%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK]

 draft-ietf-avt-smpte-rtp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5484 RFC5485 Digital Signatures on Internet-Draft Documents R. Housley March 2009 ASCII 29582 14 cms cryptographic message syntax detached signature

This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. This memo provides information for the Internet community.

 draft-housley-internet-draft-sig-file-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5485 RFC5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology D. Malas Editor D. Meyer Editor March 2009 ASCII 22036 10

This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). This memo provides information for the Internet community.

 draft-ietf-speermint-terminology-17 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5486 RFC5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode M. Badra March 2009 ASCII 15537 7 PSK Diffie-Hellman Key Exchange advanced encryption standard gcm digest algorithm ciphersuite

RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). [STANDARDS-TRACK]

 draft-ietf-tls-psk-new-mac-aes-gcm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5487 RFC5488 Network Mobility (NEMO) Management Information Base S. Gundavelli G. Keeni K. Koide K. Nagami April 2009 ASCII 87041 44 mib NEMO-MIB

This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. [STANDARDS-TRACK]

 draft-ietf-mext-nemo-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5488 RFC5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) M. Badra I. Hajjeh March 2009 ASCII 14194 7 pre-shared key Diffie-Hellman Key Exchange Elliptic Curve Cryptography

This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy (PFS). This memo provides information for the Internet community.

 draft-ietf-tls-ecdhe-psk-05 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5489 RFC5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata A. Melnikov March 2009 ASCII 16065 8 mail filtering fileinto

This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK]

 draft-melnikov-sieve-imapext-metadata-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5490 RFC5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations J. Winterbottom M. Thomson H. Tschofenig March 2009 ASCII 51681 28 PIDF-LO civic geodetic location well-formed GeoShape

The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. [STANDARDS-TRACK]

 draft-ietf-geopriv-pdif-lo-profile-14 RFC4119 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5491 10.17487/RFC5491 RFC5492 Capabilities Advertisement with BGP-4 J. Scudder R. Chandra February 2009 ASCII 13581 7 bgp idr border gateway protocol capabilities

This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 3392. [STANDARDS-TRACK]

 draft-ietf-idr-rfc3392bis-05 RFC3392 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5492 10.17487/RFC5492 RFC5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network D. Caviglia D. Bramanti D. Li D. McDysan April 2009 ASCII 21991 11 pc spc soft permanent connection data plane traffic

From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.

This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. This memo provides information for the Internet community.

 draft-ietf-ccamp-pc-and-sc-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5493 RFC5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP) J. Arkko C. Pignataro April 2009 ASCII 11894 7 IANA rules Address Resolution Protocol ARP

This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. [STANDARDS-TRACK]

 draft-arkko-arp-iana-rules-06 RFC0826 RFC0951 RFC1044 RFC1329 RFC2131 RFC2132 RFC2176 RFC2225 RFC2834 RFC2835 RFC3315 RFC4338 RFC4361 RFC4701 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5494 RFC5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures D. Li J. Gao A. Satyanarayana S. Bardalai March 2009 ASCII 39325 18 Hello message gmpls

The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.

The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).

Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.

This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.

This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. This memo provides information for the Internet community.

 draft-ietf-ccamp-gr-description-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5495 RFC5496 The Reverse Path Forwarding (RPF) Vector TLV IJ. Wijnands A. Boers E. Rosen March 2009 ASCII 16754 8 pim protocol independent multicast join attribute

This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK]

 draft-ietf-pim-rpf-vector-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5496 10.17487/RFC5496 RFC5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove March 2009 ASCII 30653 14 Routing Protocol TLV Fisheye FSR Fuzzy-Sighted extension packetbb RFC5444

This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK]

 draft-ietf-manet-timetlv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5497 10.17487/RFC5497 RFC5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols I. Chakeres March 2009 ASCII 8399 5 manet protocols

This document enumerates several common IANA allocations for use by Mobile Ad hoc NETwork (MANET) protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. [STANDARDS-TRACK]

 draft-ietf-manet-iana-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5498 10.17487/RFC5498 RFC5501 Requirements for Multicast Support in Virtual Private LAN Services Y. Kamite Editor Y. Wada Y. Serbest T. Morin L. Fang March 2009 ASCII 71507 31 L2 VPN VPLS Ethernet P2MP IGMP MLD PIM

This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. This memo provides information for the Internet community.

 draft-ietf-l2vpn-vpls-mcast-reqts-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC5501 RFC5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem J. van Elburg April 2009 ASCII 33553 14 SIP S-CSCF AS ISC

This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. This memo provides information for the Internet community.

 draft-vanelburg-sipping-served-user-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5502 10.17487/RFC5502 RFC5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture F. Andreasen B. McKibben B. Marshall March 2009 ASCII 80201 34 P-DCS-TRACE-PARTY-ID P-DCS-OSPS P-DCS-BILLING-INFO P-DCS-LAES P-DCS-Redirect P-DCS-INFO

In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. This memo provides information for the Internet community.

 draft-andreasen-sipping-rfc3603bis-07 RFC3603 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5503 RFC5504 Downgrading Mechanism for Email Address Internationalization K. Fujiwara Editor Y. Yoneya Editor March 2009 ASCII 48894 24 EAI Email Address Internationalization Downgrade MAIL

Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-downgrade-12 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5504 RFC5505 Principles of Internet Host Configuration B. Aboba D. Thaler L. Andersson S. Cheshire May 2009 ASCII 57340 25 internet-layer parameter higher-layer configuration

This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols. This memo provides information for the Internet community.

 draft-iab-ip-config-11 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5505 RFC5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences I. Johansson M. Westerlund April 2009 ASCII 41011 17 AVPF non-compound non compound compound

This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-non-compound-09 RFC3550 RFC3711 RFC4585 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5506 10.17487/RFC5506 RFC5507 Design Choices When Expanding the DNS IAB P. Faltstrom Editor R. Austein Editor P. Koch Editor April 2009 ASCII 44045 18 domain name system resource record type

This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community.

 draft-iab-dns-choices-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5507 RFC5508 NAT Behavioral Requirements for ICMP P. Srisuresh B. Ford S. Sivakumar S. Guha April 2009 ASCII 67985 29 ICMP Error payload translation hairpin translation ICMP Query ICMP Error Ping Traceroute

This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-nat-icmp-12 RFC7857 BCP0148 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5508 RFC5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) S. Loreto April 2009 ASCII 10053 5 _sip

This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. [STANDARDS TRACK]

 draft-loreto-simple-im-srv-label-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5509 RFC5510 Reed-Solomon Forward Error Correction (FEC) Schemes J. Lacan V. Roca J. Peltotalo S. Peltotalo April 2009 ASCII 57493 28 maximum distance separable MDS

This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).

Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-rs-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5510 RFC5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications A. Farrel April 2009 ASCII 27026 14 routing bnf

Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.

There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.

Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.

This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]

 draft-farrel-rtg-common-bnf-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5511 RFC5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute P. Mohapatra E. Rosen April 2009 ASCII 30554 13 BGP Encapsulation Encap SAFI Tunnel Softwire 4over6 6over4

In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.

The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]

 draft-ietf-softwire-encaps-safi-05 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5512 RFC5513 IANA Considerations for Three Letter Acronyms A. Farrel April 1 2009 ASCII 13931 7 tla abbreviation

Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors.

Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.

 draft-farrel-iana-tla-registry-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5513 10.17487/RFC5513 RFC5514 IPv6 over Social Networks E. Vyncke April 1 2009 ASCII 10127 6 facebook

There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks. This will immediately add millions of IPv6 hosts to the existing IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. This memo defines an Experimental Protocol for the Internet community.

 draft-vyncke-ip-over-social-network-01 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5514 10.17487/RFC5514 RFC5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions V. Mammoliti C. Pignataro P. Arberg J. Gibbons P. Howard May 2009 ASCII 60768 28 L2TP Acces Line Information DSLAM

This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3. This memo provides information for the Internet community.

 draft-mammoliti-l2tp-accessline-avp-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5515 10.17487/RFC5515 RFC5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) M. Jones L. Morand April 2009 ASCII 9105 5 3GPP Release 8 Diameter command codes EPS

This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for Mobile Management Entity (MME)- and Serving GPRS (General Packet Radio Service) Support Node (SGSN)-related interfaces in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS). This memo provides information for the Internet community.

 draft-jones-dime-3gpp-eps-command-codes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5516 RFC5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment S. HomChaudhuri M. Foschiano February 2010 ASCII 28405 12

This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.

Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sanjib-private-vlan-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5517 RFC5518 Vouch By Reference P. Hoffman J. Levine A. Hathcock April 2009 ASCII 23730 12 VBR DKIM SenderID DK reputation

This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. [STANDARDS-TRACK]

 draft-hoffman-dac-vbr-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5518 10.17487/RFC5518 RFC5519 Multicast Group Membership Discovery MIB J. Chesterfield B. Haberman Editor April 2009 ASCII 76260 41 management information base mgmd mld multicast listener discovery MGMD-STD-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 objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. [STANDARDS-TRACK]

 draft-ietf-magma-mgmd-mib-15 RFC2933 RFC3019 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=5519 10.17487/RFC5519 RFC5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism R. Bradford Editor JP. Vasseur A. Farrel April 2009 ASCII 43125 19 confidential path segment cps pcep

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.

This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]

 draft-ietf-pce-path-key-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5520 10.17487/RFC5520 RFC5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions E. Oki T. Takeda A. Farrel April 2009 ASCII 36294 16 MPLS GMPLS Traffic Engineering Label Switched Path

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".

The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]

 draft-ietf-pce-pcep-xro-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5521 10.17487/RFC5521 RFC5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks W. Eddy W. Ivancic T. Davis October 2009 ASCII 79570 31 NEMO aeronautics space exploration route optimization mobility

This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.

Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. This memo provides information for the Internet community.

 draft-ietf-mext-aero-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5522 RFC5523 OSPFv3-Based Layer 1 VPN Auto-Discovery L. Berger April 2009 ASCII 23473 12 open shortest path first layer 1 virtual private network

This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-l1vpn-ospfv3-auto-discovery-03 EXPERIMENTAL EXPERIMENTAL IETF rtg l1vpn 10.17487/RFC5523 RFC5524 Extended URLFETCH for Binary and Converted Parts D. Cridland May 2009 ASCII 15915 9 IMAP Lemonade

The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. [STANDARDS-TRACK]

 draft-cridland-urlfetch-binary-03 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5524 RFC5525 Reliable Server Pooling MIB Module Definition T. Dreibholz J. Mulik April 2009 ASCII 85897 46 RSerPool Management Information Base asap aggregate server access protocol enrp endpoint handlespace redundancy protocol RSERPOOL-MIB

Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol). This document defines an \%SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-mib-12 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5525 RFC5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM J. Livingood P. Pfautz R. Stastny April 2009 ASCII 9624 5 e164.arpa

This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). This memo provides information for the Internet community.

 draft-ietf-enum-infrastructure-07 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5526 RFC5527 Combined User and Infrastructure ENUM in the e164.arpa Tree M. Haberler O. Lendl R. Stastny May 2009 ASCII 20733 10 e164.arpa

This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution. This memo provides information for the Internet community.

 draft-ietf-enum-combined-09 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5527 RFC5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms A. Kato M. Kanda S. Kanno April 2009 ASCII 56134 22 Camellia Block Cipher Mode of operation

This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM). The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

 draft-kato-camellia-ctrccm-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5528 RFC5529 Modes of Operation for Camellia for Use with IPsec A. Kato M. Kanda S. Kanno April 2009 ASCII 13030 7 IPsec Camellia Block Cipher Mode of operation

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) and Encapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

 draft-kato-ipsec-camellia-modes-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5529 RFC5530 IMAP Response Codes A. Gulbrandsen May 2009 ASCII 17169 9 machine-readable response codes

IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.

This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]

 draft-gulbrandsen-imap-response-codes-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5530 RFC5531 RPC: Remote Procedure Call Protocol Specification Version 2 R. Thurlow May 2009 ASCII 161720 63 RPC ONC Open Network Computing

This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rfc1831bis-13 RFC1831 DRAFT STANDARD DRAFT STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5531 10.17487/RFC5531 RFC5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement T. Talpey C. Juszczak May 2009 ASCII 36746 15 RPC XDR ONC RDDP NFSv4

This document addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead. This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general. This memo provides information for the Internet community.

 draft-ietf-nfsv4-nfs-rdma-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5532 RFC5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6 E. Nordmark M. Bagnulo June 2009 ASCII 299931 124 locator pair

This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]

 draft-ietf-shim6-proto-12 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5533 RFC5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming J. Arkko I. van Beijnum June 2009 ASCII 88152 36 Shim6 reachability protocol REAP

This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. [STANDARDS-TRACK]

 draft-ietf-shim6-failure-detection-13 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5534 RFC5535 Hash-Based Addresses (HBA) M. Bagnulo June 2009 ASCII 63994 25 Shim6 multi-homing cryptographically generated addresses (cgas),

This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. [STANDARDS-TRACK]

 draft-ietf-shim6-hba-05 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5535 RFC5536 Netnews Article Format K. Murchison Editor C. Lindsey D. Kohn November 2009 ASCII 71817 36 Usenet Usefor

This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]

 draft-ietf-usefor-usefor-12 RFC1036 RFC1849 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5536 10.17487/RFC5536 RFC5537 Netnews Architecture and Protocols R. Allbery Editor C. Lindsey November 2009 ASCII 120366 48 usefor Usenet netnews

This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK]

 draft-ietf-usefor-usepro-14 RFC1036 RFC1849 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5537 10.17487/RFC5537 RFC5538 The 'news' and 'nntp' URI Schemes F. Ellermann April 2010 ASCII 29470 14

This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. [STANDARDS-TRACK]

 draft-ellermann-news-nntp-uri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5538 10.17487/RFC5538 RFC5539 NETCONF over Transport Layer Security (TLS) M. Badra May 2009 ASCII 16073 7 Authentication TLS RPC

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. [STANDARDS-TRACK]

 draft-ietf-netconf-tls-07 RFC7589 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC5539 RFC5540 40 Years of RFCs RFC Editor April 2009 ASCII 5579 3

This RFC marks the 40th anniversary of the RFC document series. This memo provides information for the Internet community.

 draft-rfc-editor-40-anniversary-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5540 RFC5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) JL. Le Roux JP. Vasseur Y. Lee June 2009 ASCII 45589 23 pcc path computation client

The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).

In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.

This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.

This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]

 draft-ietf-pce-of-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5541 RFC5542 Definitions of Textual Conventions for Pseudowire (PW) Management T. Nadeau Editor D. Zelig Editor O. Nicklass Editor May 2009 ASCII 19948 11 Pseudowire PWE3 MIB PWE3-TC PW-TC

This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-tc-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5542 RFC5543 BGP Traffic Engineering Attribute H. Ould-Brahim D. Fedyk Y. Rekhter May 2009 ASCII 11883 6 BGP-TE BGP-TE Attribute Traffic Engineering with BGP Inter-domain Traffic Engineering L1VPN BGP-TE BGP-TE-VPN VPN BGP Traffic Engineering Attribute

This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.

The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]

 draft-ietf-softwire-bgp-te-attribute-04 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5543 RFC5544 Syntax for Binding Documents with Time-Stamps A. Santoni February 2010 ASCII 26534 13 time-stamp token,

This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time-stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed.

The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-santoni-timestampeddata-06 RFC5955 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5544 RFC5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar) B. Desruisseaux Editor September 2009 ASCII 345537 168 calsify calsched calsch caldav calendar calendaring meeting event task to-do journal appointment agenda schedule scheduling ical icalendar itip imip text/calendar ischedule xCalendar

This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]

 draft-ietf-calsify-rfc2445bis-10 RFC2445 RFC5546 RFC6868 RFC7529 RFC7953 RFC7986 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5545 10.17487/RFC5545 RFC5546 iCalendar Transport-Independent Interoperability Protocol (iTIP) C. Daboo Editor December 2009 ASCII 318143 133 calendar scheduling

This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.

The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]

 draft-ietf-calsify-2446bis-10 RFC2446 RFC5545 RFC6638 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5546 10.17487/RFC5546 RFC5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer M. Garcia-Martin M. Isomaki G. Camarillo S. Loreto P. Kyzivat May 2009 ASCII 112625 50 msrp message session relay protocol

This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. [STANDARDS-TRACK]

 draft-ietf-mmusic-file-transfer-mech-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5547 10.17487/RFC5547 RFC5548 Routing Requirements for Urban Low-Power and Lossy Networks M. Dohler Editor T. Watteyne Editor T. Winter Editor D. Barthel Editor May 2009 ASCII 47759 21 u-lln roll routing over low-power and loss

The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics. This memo provides information for the Internet community.

 draft-ietf-roll-urban-routing-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5548 RFC5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop F. Le Faucheur E. Rosen May 2009 ASCII 23637 10 BGP IPv6 IPv4

Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]

 draft-ietf-softwire-v4nlri-v6nh-02 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5549 RFC5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile D. Cridland Editor A. Melnikov Editor S. Maes Editor August 2009 ASCII 84862 41 IMAP Sieve SMTP Lemonade mobile email low-bandwidth efficient

This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. [STANDARDS-TRACK]

 draft-ietf-lemonade-profile-bis-12 RFC4550 RFC4469 RFC4467 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5550 RFC5551 Lemonade Notifications Architecture R. Gellens Editor August 2009 ASCII 27542 12 notification filtering

Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) Working Group.

This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. This memo provides information for the Internet community.

 draft-ietf-lemonade-notifications-10 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5551 RFC5552 SIP Interface to VoiceXML Media Services D. Burke M. Scott May 2009 ASCII 85063 36 VoiceXML SIP MRF IVR IMS

This document describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. [STANDARDS-TRACK]

 draft-ietf-mediactrl-vxml-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=5552 10.17487/RFC5552 RFC5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support A. Farrel Editor R. Bradford JP. Vasseur May 2009 ASCII 30020 14 pks path key subobject ero explicit route object rro record route object

The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.

To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation.

This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. [STANDARDS-TRACK]

 draft-ietf-ccamp-path-key-ero-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5553 RFC5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings N. Williams May 2009 ASCII 8173 4 GSS GSS-API channel binding and C-bindings

This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-channel-bindings-07 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5554 RFC5555 Mobile IPv6 Support for Dual Stack Hosts and Routers H. Soliman Editor June 2009 ASCII 92387 41 nemo mipv6 ipv4

The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. [STANDARDS-TRACK]

 draft-ietf-mext-nemo-v4traversal-10 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5555 10.17487/RFC5555 RFC5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement J. Touch R. Perlman May 2009 ASCII 41657 17 spanning tree protocol ieee 802.1

Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. This memo provides information for the Internet community.

 draft-ietf-trill-prob-06 INFORMATIONAL INFORMATIONAL IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=5556 10.17487/RFC5556 RFC5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization Y. Lee JL. Le Roux D. King E. Oki July 2009 ASCII 58888 26 pcc path communication client pce gco global concurrent optimization nms network management system

The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.

This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]

 draft-ietf-pce-global-concurrent-optimization-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5557 10.17487/RFC5557 RFC5558 Virtual Enterprise Traversal (VET) F. Templin Editor February 2010 ASCII 88504 36 Enterprise MANET Encapsulation Tunneling Autoconfiguration Subnetwork Provider-Independent Provider-Aggregated

Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-templin-autoconf-dhcp-38 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5558 RFC5559 Pre-Congestion Notification (PCN) Architecture P. Eardley Editor June 2009 ASCII 134827 54 Quality of Service QoS Congestion Control Differentiated Services Admission Control Termination

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. This memo provides information for the Internet community.

 draft-ietf-pcn-architecture-11 INFORMATIONAL INFORMATIONAL IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5559 10.17487/RFC5559 RFC5560 A One-Way Packet Duplication Metric H. Uijterwaal May 2009 ASCII 25304 14 performance metrics packet duplication unidirectional

When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.

In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]

 draft-ietf-ippm-duplicate-08 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5560 RFC5561 LDP Capabilities B. Thomas K. Raza S. Aggarwal R. Aggarwal JL. Le Roux July 2009 ASCII 27901 12 MPLS LDP Capabilities

A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-capabilities-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5561 RFC5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets A. Kuzmanovic A. Mondal S. Floyd K. Ramakrishnan June 2009 ASCII 77110 33 ecn-capable

The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.

This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-ecnsyn-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5562 RFC5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4 K. Leung G. Dommety P. Yegani K. Chowdhury February 2010 ASCII 92438 41 mipv4 pmipv4

Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-leung-mip4-proxy-mode-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5563 RFC5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains A. El-Sherbiny M. Farah I. Oueichek A. Al-Zoman February 2010 ASCII 22850 11 arabic domain names

This document constitutes technical specifications for the use of Arabic in Internet domain names and provides linguistic guidelines for Arabic domain names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-farah-adntf-ling-guidelines-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5564 RFC5565 Softwire Mesh Framework J. Wu Y. Cui C. Metz E. Rosen June 2009 ASCII 75039 31

The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]

 draft-ietf-softwire-mesh-framework-06 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5565 RFC5566 BGP IPsec Tunnel Encapsulation Attribute L. Berger R. White E. Rosen June 2009 ASCII 17416 8 border gateway protocol safi subsequent address family identifier

The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. [STANDARDS-TRACK]

 draft-ietf-softwire-encaps-ipsec-03 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5566 RFC5567 An Architectural Framework for Media Server Control T. Melanchuk Editor June 2009 ASCII 63384 25

This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. This memo provides information for the Internet community.

 draft-ietf-mediactrl-architecture-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5567 RFC5568 Mobile IPv6 Fast Handovers R. Koodli Editor July 2009 ASCII 121373 51 mpiv6 handover latency

Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures (namely, movement detection, new Care-of Address configuration, and Binding Update) is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.

This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. [STANDARDS-TRACK]

 draft-ietf-mipshop-rfc5268bis-01 RFC5268 RFC7411 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5568 10.17487/RFC5568 RFC5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) R. Despres January 2010 ASCII 21159 10 IPv6 IPv4 migration transition 6to4 6rd

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-despres-6rd-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5569 10.17487/RFC5569 RFC5570 Common Architecture Label IPv6 Security Option (CALIPSO) M. StJohns R. Atkinson G. Thomas July 2009 ASCII 128032 52 sensitivity labels mls multi-level secure

This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community.

 draft-stjohns-sipso-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5570 10.17487/RFC5570 RFC5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) B. Storer C. Pignataro Editor M. Dos Santos B. Stevant Editor L. Toutain J. Tremblay June 2009 ASCII 91379 41 Softwire L2TP Softwire Hub and Spoke Softwire HnS 4over6 6over4 L2TP softwires L2TPv2 softwires

This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]

 draft-ietf-softwire-hs-framework-l2tpv2-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5571 RFC5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) M. Blanchet F. Parent February 2010 ASCII 60017 32 IPv6 Tunnel Transition TSP

A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. This document defines an Experimental Protocol for the Internet community.

 draft-blanchet-v6ops-tunnelbroker-tsp-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5572 10.17487/RFC5572 RFC5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) M. Thomson June 2009 ASCII 17290 8 asynchronous beep channels

The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. This memo defines an Experimental Protocol for the Internet community.

 draft-thomson-beep-async-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5573 RFC5574 RTP Payload Format for the Speex Codec G. Herlein J. Valin A. Heggestad A. Moizard June 2009 ASCII 27995 14 Voip SDP audio CELLP Xiph.Org

Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-rtp-speex-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5574 RFC5575 Dissemination of Flow Specification Rules P. Marques N. Sheth R. Raszuk B. Greene J. Mauch D. McPherson August 2009 ASCII 46473 22 IDR Inter-domain routing BGP DDOS Denial of Service ACL Firewall Filter

This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.

The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]

 draft-ietf-idr-flow-spec-09 RFC7674 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5575 10.17487/RFC5575 RFC5576 Source-Specific Media Attributes in the Session Description Protocol (SDP) J. Lennox J. Ott T. Schierl June 2009 ASCII 40454 18 real-time transport protocol rtp synchronization source ssrc fid flow identification fec forward error correction

The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-source-attributes-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5576 RFC5577 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi R. Even July 2009 ASCII 21705 11 international telecommunication union wide-band audio coded

International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3047-bis-09 RFC3047 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5577 10.17487/RFC5577 RFC5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry Editor S. Ratliff E. Paradise T. Kaiser M. Adams February 2010 ASCII 54936 24 point-to-point protocol over ethernet link quality metric

This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-bberry-rfc4938bis-00 RFC4938 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5578 RFC5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces F. Templin Editor February 2010 ASCII 18998 9 ISATAP Tunnel Encapsulation Map-and-Encaps IPv4 IPv6

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-templin-isatapv4-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5579 RFC5580 Carrying Location Objects in RADIUS and Diameter H. Tschofenig Editor F. Adrangi M. Jones A. Lior B. Aboba August 2009 ASCII 119753 53 remote authentication dial-in user service location information

This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.

The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK]

 draft-ietf-geopriv-radius-lo-24 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5580 RFC5581 The Camellia Cipher in OpenPGP D. Shaw June 2009 ASCII 5129 3 PGP GPG GnuPG Encryption Symmetric

This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community.

 draft-ietf-openpgp-camellia-04 RFC4880 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5581 RFC5582 Location-to-URL Mapping Architecture and Framework H. Schulzrinne September 2009 ASCII 42078 17 ECRIT Mapping LoST Emergency calling

This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. This memo provides information for the Internet community.

 draft-ietf-ecrit-mapping-arch-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5582 10.17487/RFC5582 RFC5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP) T. Schierl S. Wenger July 2009 ASCII 40214 18 media coding ddp decoding dependency

This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.

A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). [STANDARDS-TRACK]

 draft-ietf-mmusic-decoding-dependency-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5583 10.17487/RFC5583 RFC5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family M. Hatanaka J. Matsumoto July 2009 ASCII 65071 30 RTP audio fragmentation layered coding multiplexed multi-session multi-channel redundancy scalable ATRAC ATRAC3 ATRAC-X ATRAC Advanced Lossless AAL Sony Corporation

This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-atrac-family-24 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5584 10.17487/RFC5584 RFC5585 DomainKeys Identified Mail (DKIM) Service Overview T. Hansen D. Crocker P. Hallam-Baker July 2009 ASCII 54110 24 Email Electroni Mail Internet Mail Message Verification

This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This memo provides information for the Internet community.

 draft-ietf-dkim-overview-12 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5585 RFC5586 MPLS Generic Associated Channel M. Bocci Editor M. Vigoureux Editor S. Bryant Editor June 2009 ASCII 41482 19 mpls-tp oam g-ach ach associated channel header gal generic associated label

This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.

 draft-ietf-mpls-tp-gach-gal-06 RFC3032 RFC4385 RFC5085 RFC6423 RFC7026 RFC7214 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5586 10.17487/RFC5586 RFC5587 Extended Generic Security Service Mechanism Inquiry APIs N. Williams July 2009 ASCII 32002 16 GSS-API mechanism inquiry extension

This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.

These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. [STANDARDS-TRACK]

 draft-ietf-kitten-extended-mech-inquiry-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5587 RFC5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials N. Williams July 2009 ASCII 12434 7 GSS-API credential gss_store_cred

This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-store-cred-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5588 RFC5589 Session Initiation Protocol (SIP) Call Control - Transfer R. Sparks A. Johnston Editor D. Petrie June 2009 ASCII 119434 58 REFER GRUU Attended Transfer Target-Dialog Out of Dialog REFER SIP SIP Services blind transfer SIP Features Replaces Referred-By

This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-cc-transfer-12 BCP0149 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5589 10.17487/RFC5589 RFC5590 Transport Subsystem for the Simple Network Management Protocol (SNMP) D. Harrington J. Schoenwaelder June 2009 ASCII 84513 34 Network Management Simple Network Management Protocol SNMP SNMP-TRANSPORT-MIB

This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-tmsm-18 RFC3411 RFC3412 RFC3414 RFC3417 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5590 RFC5591 Transport Security Model for the Simple Network Management Protocol (SNMP) D. Harrington W. Hardaker June 2009 ASCII 61747 28 Network Management Simple Network Management Protocol SNMP Transport Security Model Security Model

This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).

This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-transport-security-model-14 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5591 RFC5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) D. Harrington J. Salowey W. Hardaker June 2009 ASCII 82822 36 Network Management Simple Network Management Protocol SNMP Secure Shell SSH

This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.

This memo also 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 monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-secshell-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5592 RFC5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension N. Cook June 2009 ASCII 18149 10 urlauth imap url

The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.

This document updates RFC 5092. [STANDARDS-TRACK]

 draft-ncook-urlauth-accessid-02 RFC5092 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5593 RFC5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008 J. Peterson A. Cooper July 2009 ASCII 61652 28 P2PI

This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community.

 draft-p2pi-cooper-workshop-report-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5594 RFC5595 The Datagram Congestion Control Protocol (DCCP) Service Codes G. Fairhurst September 2009 ASCII 44803 19 DCCP-Request Ports

This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]

 draft-ietf-dccp-serv-codes-11 RFC4340 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5595 10.17487/RFC5595 RFC5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal G. Fairhurst September 2009 ASCII 57638 25 DCCP NAT traversal Middlebox Issues

This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]

 draft-ietf-dccp-simul-open-08 RFC4340 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5596 RFC5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol R. Denis-Courmont September 2009 ASCII 18933 9 dccp

This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-dccp-05 BCP0150 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5597 RFC5598 Internet Mail Architecture D. Crocker July 2009 ASCII 115741 54 PDF 342738 email e-mail service mime architecture mta mua msa mda admd user originator recipient transfer message transfer deliver delivery relay header gateway agent gateway actor gateway sieve dsn mdn tussle mhs Message handling service message transfer agent message user agent mail submission agent mail delivery agent administrative management domain

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

 draft-crocker-email-arch-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5598 10.17487/RFC5598 RFC5601 Pseudowire (PW) Management Information Base (MIB) T. Nadeau Editor D. Zelig Editor July 2009 ASCII 129328 67 pseudowire edge-to-edge services IANA-PWE3-MIB PW-STD-MIB

This memo defines a Standards Track 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 Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5601 10.17487/RFC5601 RFC5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII 62005 31 pw operation PW-MPLS-STD-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 a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-mpls-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5602 RFC5603 Ethernet Pseudowire (PW) Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII 44125 23 ethernet pw PW-ENET-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]

 draft-ietf-pwe3-enet-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5603 RFC5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) O. Nicklass July 2009 ASCII 80002 41 mib management information base pseudowire encapsulation t1 e1 t3 e3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]

 draft-ietf-pwe3-tdm-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5604 RFC5605 Managed Objects for ATM over Packet Switched Networks (PSNs) O. Nicklass T. Nadeau July 2009 ASCII 69401 36 mib management information base atm pseudowire

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5605 RFC5606 Implications of 'retransmission-allowed' for SIP Location Conveyance J. Peterson T. Hardie J. Morris August 2009 ASCII 27960 11 pidf-lo presence information data format for location objects

This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.

Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. This memo provides information for the Internet community.

 draft-ietf-geopriv-sip-lo-retransmission-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5606 RFC5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management D. Nelson G. Weber July 2009 ASCII 55464 25 Network Management Device Management Simple Network Management Protocol SNMP Network Configuration Protocol NETCONF Access Control

This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]

 draft-ietf-radext-management-authorization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC5607 RFC5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models K. Narayan D. Nelson August 2009 ASCII 34857 14 authorization service ssh transport model secure shell transport model

This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]

 draft-ietf-isms-radius-usage-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5608 10.17487/RFC5608 RFC5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA) V. Fajardo Editor Y. Ohba R. Marin-Lopez August 2009 ASCII 63662 30 PANA State Machine EAP

This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

 draft-ietf-pana-statemachine-12 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5609 RFC5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements E. Boschi B. Trammell L. Mark T. Zseby July 2009 ASCII 42526 20 enterprise-specific Information Element IPFIX Template type record type options template

This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]

 draft-ietf-ipfix-exporting-type-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5610 10.17487/RFC5610 RFC5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires A. Vainshtein S. Galtzur August 2009 ASCII 21979 11 l2tpv3 layer tow tunneling protocol version 3 structure-agnostic structure-aware cesopsn tdmoip

This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]

 draft-ietf-l2tpext-tdm-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5611 RFC5612 Enterprise Number for Documentation Use P. Eronen D. Harrington August 2009 ASCII 6610 4 smi network management private enterprise code

This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.

 draft-eronen-enterprise-number-documentation-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5612 RFC5613 OSPF Link-Local Signaling A. Zinin A. Roy L. Nguyen B. Friedman D. Yeung August 2009 ASCII 23092 12 open shortest path first intra-domain routing

OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.

 draft-ietf-ospf-lls-08 RFC4813 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5613 RFC5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding R. Ogier P. Spagnolo August 2009 ASCII 170106 71 MANET routing link-state routing CDS flooding mesh network MANET Designated Router MDR

This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ospf-manet-mdr-05 RFC7038 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5614 RFC5615 H.248/MEGACO Registration Procedures C. Groves Y. Lin August 2009 ASCII 29069 14 Package Error Code ServiceChange Reason Profile

This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-groves-megaco-pkgereg-04 BCP0151 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5615 RFC5616 Streaming Internet Messaging Attachments N. Cook August 2009 ASCII 65579 28 IMAP SIP streaming stream email multimedia lemonade attachments video audio

This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.

The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). This memo provides information for the Internet community.

 draft-ietf-lemonade-streaming-13 INFORMATIONAL INFORMATIONAL IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5616 10.17487/RFC5616 RFC5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) E. Allman J. Fenton M. Delany J. Levine August 2009 ASCII 43093 21 email e-mail rfc 5322 rfc 5322 rfc 822 rfc 822 rfc 5321 rfc 5321 rfc 821 rfc 821 rfc 4871 rfc 4871 DKIM domain keys domainkeys ADSP ADSP SSP architecture mta user delivery smtp submission email e-mail smtp Internet mailfrom mail from author return address sender signing signing practices

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]

 draft-ietf-dkim-ssp-10 HISTORIC PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=5617 10.17487/RFC5617 RFC5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) A. Morton K. Hedayat August 2009 ASCII 16553 8 twamp-control protocol twamp-test protocol twamp modes

This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]

 draft-ietf-ippm-more-twamp-02 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5618 RFC5619 Softwire Security Analysis and Requirements S. Yamamoto C. Williams H. Yokota F. Parent August 2009 ASCII 64657 28 IPv6 Tunnel Softwire Transition

This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]

 draft-ietf-softwire-security-requirements-09 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5619 RFC5620 RFC Editor Model (Version 1) O. Kolkman Editor IAB August 2009 ASCII 40744 19 RFC Series Editor Independent Stream Editor

The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. This memo provides information for the Internet community.

 draft-iab-rfc-editor-model-07 RFC6548 RFC6635 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5620 RFC5621 Message Body Handling in the Session Initiation Protocol (SIP) G. Camarillo September 2009 ASCII 43676 19 Message body MIME SIP

This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. [STANDARDS-TRACK]

 draft-ietf-sip-body-handling-06 RFC3204 RFC3261 RFC3459 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5621 RFC5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) S. Floyd E. Kohler August 2009 ASCII 45394 19 ccid 4 congestion control identifier 4

This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dccp-ccid4-05 RFC6323 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5622 RFC5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering E. Oki T. Takeda JL. Le Roux A. Farrel September 2009 ASCII 81033 34 MPLS GMPLS Traffic Engineering Label Switched Path Virtual Network Topology

A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.

This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community.

 draft-ietf-pce-inter-layer-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5623 10.17487/RFC5623 RFC5624 Quality of Service Parameters for Usage with Diameter J. Korhonen Editor H. Tschofenig E. Davies August 2009 ASCII 23326 12 Diameter QoS Parameters

This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.

The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS-TRACK]

 draft-ietf-dime-qos-parameters-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5624 RFC5625 DNS Proxy Implementation Guidelines R. Bellis August 2009 ASCII 24585 12 DNS Proxy

This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsext-dnsproxy-06 BCP0152 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC5625 RFC5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) C. Jennings Editor R. Mahy Editor F. Audet Editor October 2009 ASCII 116344 50

The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]

 draft-ietf-sip-outbound-20 RFC3261 RFC3327 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5626 RFC5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII 94790 40 SIP NAT outbound gruu registration traversal

Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]

 draft-ietf-sip-gruu-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5627 10.17487/RFC5627 RFC5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) P. Kyzivat October 2009 ASCII 31031 14 registration

RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.

However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. [STANDARDS-TRACK]

 draft-ietf-sipping-gruu-reg-event-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5628 10.17487/RFC5628 RFC5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII 92959 38 sip dtmf

This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi- Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. [STANDARDS-TRACK]

 draft-ietf-sipping-app-interaction-framework-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5629 RFC5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) F. Audet October 2009 ASCII 114513 56 SIPS SIP TLS

This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. [STANDARDS-TRACK]

 draft-ietf-sip-sips-09 RFC3261 RFC3608 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5630 RFC5631 Session Initiation Protocol (SIP) Session Mobility R. Shacham H. Schulzrinne S. Thakolsri W. Kellerer October 2009 ASCII 89040 35 third party call control (3pcc) transfer voice over ip (voip)

Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document. This memo provides information for the Internet community.

 draft-shacham-sipping-session-mobility-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5631 RFC5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial C. Griffiths J. Livingood L. Popkin R. Woundy Y. Yang September 2009 ASCII 27920 12 ISP Internet Service Provider P2P Peer-to-Peer P4P Proactive Network Provider Partication for P2P DCIA Distributed Computing Industry Association

This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008. This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer Transport Optimization (ALTO) working group. This memo provides information for the Internet community.

 draft-livingood-woundy-p4p-experiences-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5632 10.17487/RFC5632 RFC5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers S. Dawkins Editor August 2009 ASCII 11117 5 Internet Architecture Board Engineering Steering Group

This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-dawkins-nomcom-dont-wait-04 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5633 RFC5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP) G. Fairhurst A. Sathiaseelan August 2009 ASCII 52726 22 ccid congestion control identifier ccid 2 ccid 3 ccid 4

This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dccp-quickstart-05 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5634 RFC5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) W. Kumari D. McPherson August 2009 ASCII 30232 15 rtbh

Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community.

 draft-ietf-opsec-blackhole-urpf-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC5635 RFC5636 Traceable Anonymous Certificate S. Park H. Park Y. Won J. Lee S. Kent August 2009 ASCII 70316 31 x.509 certificate blind issuer anonymity issuer tacs end entity ee

This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-tac-04 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC5636 RFC5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 G. Giaretta I. Guardini E. Demaria J. Bournelle R. Lopez September 2009 ASCII 23409 11 AAA MIPv6 Mobile IP

In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. This memo provides information for the Internet community.

 draft-ietf-mext-aaa-ha-goals-01 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5637 RFC5638 Simple SIP Usage Scenario for Applications in the Endpoints H. Sinnreich Editor A. Johnston E. Shim K. Singh September 2009 ASCII 45946 19 session initiation protocol rich internet application ria

For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints.

This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11.

References for NAT traversal and for security are also provided. This memo provides information for the Internet community.

 draft-sinnreich-sip-tools-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5638 RFC5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation M. Lochter J. Merkle March 2010 ASCII 50566 27

This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-lochter-pkix-brainpool-ecc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5639 10.17487/RFC5639 RFC5640 Load-Balancing for Mesh Softwires C. Filsfils P. Mohapatra C. Pignataro August 2009 ASCII 12250 6 bgp encapsulation subsequent address family identifier safi

Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]

 draft-ietf-softwire-lb-03 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5640 RFC5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values N. McGill C. Pignataro August 2009 ASCII 23133 11 attachment circuits acs pseudowires pw active bit new bit circuit status avp

This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719. [STANDARDS-TRACK]

 draft-ietf-l2tpext-circuit-status-extensions-05 RFC3931 RFC4349 RFC4454 RFC4591 RFC4719 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5641 RFC5642 Dynamic Hostname Exchange Mechanism for OSPF S. Venkata S. Harwani C. Pignataro D. McPherson August 2009 ASCII 19227 8 open shortest path first router information ri ospf dynamic hostname

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3. [STANDARDS-TRACK]

 draft-ietf-ospf-dynamic-hostname-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5642 RFC5643 Management Information Base for OSPFv3 D. Joyal Editor V. Manral Editor August 2009 ASCII 192945 95 mib ipv6 open shortest path first routing protocol OSPFV3-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5643 10.17487/RFC5643 RFC5644 IP Performance Metrics (IPPM): Spatial and Multicast E. Stephan L. Liang A. Morton October 2009 ASCII 110407 57 Multiple point measurement relative performance group performance statistic per hop measurement segment performance

The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]

 draft-ietf-ippm-multimetrics-12 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5644 10.17487/RFC5644 RFC5645 Update to the Language Subtag Registry D. Ewell Editor September 2009 ASCII 27902 13 language tags language tagging ltru registry

This memo defines the procedure used to update the IANA Language Subtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages. This memo provides information for the Internet community.

 draft-ietf-ltru-4645bis-10 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC5645 RFC5646 Tags for Identifying Languages A. Phillips Editor M. Davis Editor September 2009 ASCII 208592 84 language tags private interchange

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ltru-4646bis-23 RFC4646 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru 10.17487/RFC5646 RFC5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol K. Igoe J. Solinas August 2009 ASCII 20990 10 ssh remote-login

Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol. This memo provides information for the Internet community.

 draft-igoe-secsh-aes-gcm-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5647 RFC5648 Multiple Care-of Addresses Registration R. Wakikawa Editor V. Devarapalli G. Tsirtsis T. Ernst K. Nagami October 2009 ASCII 90112 36

According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS-TRACK]

 draft-ietf-monami6-multiplecoa-14 RFC6089 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5648 10.17487/RFC5648 RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm R. Housley M. Dworkin September 2009 ASCII 22507 13

This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.

 draft-housley-aes-key-wrap-with-pad-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5649 RFC5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) M. Morgenstern S. Baillie U. Bonollo September 2009 ASCII 434687 218 mib management information base adsl asymmetric digital subscriber line VDSL2-LINE-TC-MIB VDSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl2-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC5650 RFC5651 Layered Coding Transport (LCT) Building Block M. Luby M. Watson L. Vicisano October 2009 ASCII 85751 34 FEC reliable multicast

The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but it also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC 3451. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-lct-revised-11 RFC3451 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5651 10.17487/RFC5651 RFC5652 Cryptographic Message Syntax (CMS) R. Housley September 2009 ASCII 126813 56 digital signature message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

 draft-ietf-smime-rfc3852bis-00 RFC3852 STD0070 INTERNET STANDARD DRAFT STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5652 10.17487/RFC5652 RFC5653 Generic Security Service API Version 2: Java Bindings Update M. Upadhyay S. Malkani August 2009 ASCII 209903 99 gssapi application program interface gss-api GSI

The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings" (RFC 2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.

The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). [STANDARDS-TRACK]

 draft-ietf-kitten-rfc2853bis-05 RFC2853 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5653 RFC5654 Requirements of an MPLS Transport Profile B. Niven-Jenkins Editor D. Brungard Editor M. Betts Editor N. Sprecher S. Ueno September 2009 ASCII 69999 31 MPLS-TP ITU ITU-T

This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF 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 International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).

This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.

The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-requirements-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5654 10.17487/RFC5654 RFC5655 Specification of the IP Flow Information Export (IPFIX) File Format B. Trammell E. Boschi L. Mark T. Zseby A. Wagner October 2009 ASCII 154566 64 flow file flow storage ipfix storage netflow storage

This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]

 draft-ietf-ipfix-file-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5655 10.17487/RFC5655 RFC5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer D. Stebila J. Green December 2009 ASCII 44259 20 Key Agreement Cryptography

This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]

 draft-green-secsh-ecc-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5656 10.17487/RFC5656 RFC5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard L. Dusseault R. Sparks September 2009 ASCII 29327 12 rfc2026 2026 guidance interoperation implementation reports advancement draft standard

Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-dusseault-impl-reports-04 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5657 10.17487/RFC5657 RFC5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP) T. Froment C. Lebel B. Bonnaerens October 2009 ASCII 39219 18 multi-homed user agent proxy interoperability double record-routing

A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK]

 draft-ietf-sip-record-route-fix-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5658 RFC5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge M. Bocci S. Bryant October 2009 ASCII 55614 24 psn packet switched network

This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

 draft-ietf-pwe3-ms-pw-arch-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5659 10.17487/RFC5659 RFC5660 IPsec Channels: Connection Latching N. Williams October 2009 ASCII 74209 31 IPsec connection latching channel

This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.

Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]

 draft-ietf-btns-connection-latching-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5660 10.17487/RFC5660 RFC5661 Network File System (NFS) Version 4 Minor Version 1 Protocol S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII 1517771 617 Access Control List ACL Communications Sessions Exactly Once Semantics File Access Protocol Global Namespace Network Authentication Network File Access Network File System Network Security NFS Parallel Storage pNFS Storage Cluster

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK]

 draft-ietf-nfsv4-minorversion1-29 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5661 10.17487/RFC5661 RFC5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII 126581 73 xdr nfsv4

This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK]

 draft-ietf-nfsv4-minorversion1-dot-x-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5662 RFC5663 Parallel NFS (pNFS) Block/Volume Layout D. Black S. Fridella J. Glasgow January 2010 ASCII 68571 28 nfsv4 network file sharing version 4

Parallel NFS (pNFS) extends Network File Sharing 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. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. [STANDARDS-TRACK]

 draft-ietf-nfsv4-pnfs-block-12 RFC6688 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5663 10.17487/RFC5663 RFC5664 Object-Based Parallel NFS (pNFS) Operations B. Halevy B. Welch J. Zelenka January 2010 ASCII 78200 35 OSD storage device

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. [STANDARDS-TRACK]

 draft-ietf-nfsv4-pnfs-obj-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5664 10.17487/RFC5664 RFC5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats M. Eisler January 2010 ASCII 28706 14 rpcbind portmap transport independent remote procedure call TI-RPC transport identifier protocol identifier

This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rpc-netid-06 RFC1833 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5665 10.17487/RFC5665 RFC5666 Remote Direct Memory Access Transport for Remote Procedure Call T. Talpey B. Callaghan January 2010 ASCII 83728 34 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rpcrdma-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5666 RFC5667 Network File System (NFS) Direct Data Placement T. Talpey B. Callaghan January 2010 ASCII 83728 10 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport. [STANDARDS-TRACK]

 draft-ietf-nfsv4-nfsdirect-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5667 RFC5668 4-Octet AS Specific BGP Extended Community Y. Rekhter S. Sangli D. Tappan October 2009 ASCII 9017 5 border gateway protocol autonomous system

This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK]

 draft-ietf-l3vpn-as4octet-ext-community-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5668 RFC5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) S. Yoon J. Kim H. Park H. Jeong Y. Won August 2010 ASCII 24918 13

This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

 draft-ietf-avt-seed-srtp-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5669 RFC5670 Metering and Marking Behaviour of PCN-Nodes P. Eardley Editor November 2009 ASCII 44363 20 pre-congestion notification threshold metering threshold marking pcn-threshold-rate pcn-excess-rate

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. [STANDARDS-TRACK]

 draft-ietf-pcn-marking-behaviour-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5670 10.17487/RFC5670 RFC5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) S. Yasukawa A. Farrel Editor October 2009 ASCII 35176 15 multiprotocol label switching generalized mpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs).

This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. This memo provides information for the Internet community.

 draft-ietf-pce-p2mp-app-02 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5671 RFC5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update D. Crocker Editor August 2009 ASCII 29677 14 DKIM email authentication security spam abuse errata trust Signing Domain Identifier SDID AUID Agent or User Identifier

This document updates RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an Errata entry, albeit a rather long one. [STANDARDS-TRACK]

 draft-ietf-dkim-rfc4871-errata-07 RFC6376 RFC4871 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim 10.17487/RFC5672 RFC5673 Industrial Routing Requirements in Low-Power and Lossy Networks K. Pister Editor P. Thubert Editor S. Dwars T. Phinney October 2009 ASCII 67934 27 lln

The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices. This memo provides information for the Internet community.

 draft-ietf-roll-indus-routing-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5673 RFC5674 Alarms in Syslog S. Chisholm R. Gerhards October 2009 ASCII 13837 7 SYSLOG alarm

This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. [STANDARDS-TRACK]

 draft-ietf-opsawg-syslog-alarm-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5674 RFC5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages V. Marinov J. Schoenwaelder October 2009 ASCII 34379 15 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS-TRACK]

 draft-ietf-opsawg-syslog-snmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5675 RFC5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications J. Schoenwaelder A. Clemm A. Karmakar October 2009 ASCII 43160 22 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS-TRACK]

 draft-ietf-opsawg-syslog-msg-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5676 10.17487/RFC5676 RFC5677 IEEE 802.21 Mobility Services Framework Design (MSFD) T. Melia Editor G. Bajko S. Das N. Golmie JC. Zuniga December 2009 ASCII 57479 25 media independent handover mih mobility services mos

This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used. [STANDARDS-TRACK]

 draft-ietf-mipshop-mstp-solution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5677 10.17487/RFC5677 RFC5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery G. Bajko S. Das December 2009 ASCII 30489 14 handover preparation handover decision media independent handover services

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

 draft-ietf-mipshop-mos-dhcp-options-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5678 RFC5679 Locating IEEE 802.21 Mobility Services Using DNS G. Bajko December 2009 ASCII 21127 9 domain name server handover preparation handover decision media independent handover services

This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21, in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

 draft-ietf-mipshop-mos-dns-discovery-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5679 RFC5680 The Nominating Committee Process: Open Disclosure of Willing Nominees S. Dawkins Editor October 2009 ASCII 14296 7

This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-dawkins-nomcom-openlist-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5680 RFC5681 TCP Congestion Control M. Allman V. Paxson E. Blanton September 2009 ASCII 44339 18 slow start congestion avoidance fast retransmit fast recovery

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc2581bis-07 RFC2581 DRAFT STANDARD DRAFT STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5681 10.17487/RFC5681 RFC5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP P. Sarolahti M. Kojo K. Yamamoto M. Hata September 2009 ASCII 47337 19 SACK transmission control protocol loss recovery

The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138.

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc4138bis-04 RFC4138 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5682 RFC5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange A. Brusilovsky I. Faynberg Z. Zeltsan S. Patel February 2010 ASCII 17820 10

This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.

The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-brusilovsky-pak-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5683 RFC5684 Unintended Consequences of NAT Deployments with Overlapping Address Space P. Srisuresh B. Ford February 2010 ASCII 63018 26 network address translator

This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ford-behave-top-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5684 RFC5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) V. Devarapalli K. Weniger November 2009 ASCII 35100 15 IKEv2 Redirect REDIRECT REDIRECTED_FROM anycast redirect home agent redirect VPN gateway direct

The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ikev2-redirect-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5685 RFC5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec Y. Hiwasaki H. Ohmuro October 2009 ASCII 44924 21 RTP Payload type MIME UEMCLIP PCMU Speech Coding

This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-uemclip-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5686 RFC5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements H. Tschofenig H. Schulzrinne March 2010 ASCII 40880 21 Location Information Location Information Server Location by Value Location by Reference

This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-geopriv-l7-lcp-ps-10 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5687 RFC5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes J. Rosenberg January 2010 ASCII 15259 7 SIP IMS

The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports. [STANDARDS-TRACK]

 draft-rosenberg-sip-app-media-tag-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5688 10.17487/RFC5688 RFC5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) C. Daboo September 2009 ASCII 19838 12 webdav HTTP

This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. [STANDARDS-TRACK]

 draft-ietf-vcarddav-webdav-mkcol-06 RFC4791 RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC5689 RFC5690 Adding Acknowledgement Congestion Control to TCP S. Floyd A. Arcia D. Ros J. Iyengar February 2010 ASCII 83437 33 ackcc

This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-floyd-tcpm-ackcc-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5690 RFC5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio F. de Bont S. Doehla M. Schmidt R. Sperschneider October 2009 ASCII 26189 12 MPEG Surround RFC 3640 RTP MPEG-4 AAC

This memo describes extensions for the RTP payload format defined in RFC 3640 for the transport of MPEG Surround multi-channel audio. Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream. In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mps-03 RFC3640 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5691 RFC5692 Transmission of IP over Ethernet over IEEE 802.16 Networks H. Jeon S. Jeong M. Riegel October 2009 ASCII 44724 21 Bridge WiMAX Ethernet-CS Cellular

This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. [STANDARDS-TRACK]

 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5692 RFC5693 Application-Layer Traffic Optimization (ALTO) Problem Statement J. Seedorf E. Burger October 2009 ASCII 34234 14 peer-to-peer p2p

Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.

This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.

 draft-ietf-alto-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF app alto 10.17487/RFC5693 RFC5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability G. Camarillo Editor IAB November 2009 ASCII 68446 26 P2P decentralized architecture

In this document, we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. This memo provides information for the Internet community.

 draft-iab-p2p-archs-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5694 10.17487/RFC5694 RFC5695 MPLS Forwarding Benchmarking Methodology for IP Flows A. Akhter R. Asati C. Pignataro November 2009 ASCII 59976 27 multiprotocol label switching mpmls forwarding devices

This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. This memo provides information for the Internet community.

 draft-ietf-bmwg-mpls-forwarding-meth-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5695 10.17487/RFC5695 RFC5696 Baseline Encoding and Transport of Pre-Congestion Information T. Moncaster B. Briscoe M. Menth November 2009 ASCII 33112 15 Quality of Service QoS Differentiated Services Admission Control Codepoint Protocol

The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. [STANDARDS-TRACK]

 draft-ietf-pcn-baseline-encoding-07 RFC6660 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5696 10.17487/RFC5696 RFC5697 Other Certificates Extension S. Farrell November 2009 ASCII 17949 8 template

Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-other-certs-05 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC5697 RFC5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) T. Kunz S. Okunick U. Pordesch November 2009 ASCII 76313 40 long term archive security policy hash algorithm public key algorithm

Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. [STANDARDS-TRACK]

 draft-ietf-ltans-dssc-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC5698 RFC5701 IPv6 Address Specific BGP Extended Community Attribute Y. Rekhter November 2009 ASCII 9626 5 border gateway protocol

Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]

 draft-ietf-l3vpn-v6-ext-communities-02 RFC7153 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5701 RFC5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC J. Jansen October 2009 ASCII 19425 10 DNSSEC RSA SHA-256 SHA-512

This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]

 draft-ietf-dnsext-dnssec-rsasha256-14 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5702 RFC5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure T. Hansen C. Daboo October 2009 ASCII 34718 18 Email Electronic Mail Internet Mail Message Filtering

This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK]

 draft-ietf-sieve-mime-loop-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5703 RFC5704 Uncoordinated Protocol Development Considered Harmful S. Bryant Editor M. Morrow Editor IAB November 2009 ASCII 36383 15 ITU-T MPLS-TP T-MPLS Joint working team JWT

This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.

This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.

Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.

 draft-iab-mpls-tp-uncoord-harmful-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5704 RFC5705 Keying Material Exporters for Transport Layer Security (TLS) E. Rescorla March 2010 ASCII 16346 7 key establishment

A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]

 draft-ietf-tls-extractor-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5705 10.17487/RFC5705 RFC5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions D. Harrington November 2009 ASCII 82165 35 management operations

New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. This memo provides information for the Internet community.

 draft-ietf-opsawg-operations-and-management-09 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC5706 RFC5707 Media Server Markup Language (MSML) A. Saleem Y. Xin G. Sharratt February 2010 ASCII 376984 184

The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXMLThis document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-saleem-msml-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5707 10.17487/RFC5707 RFC5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System A. Keromytis January 2010 ASCII 12529 6

This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.

In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-keromytis-keynote-x509-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5708 10.17487/RFC5708 RFC5709 OSPFv2 HMAC-SHA Cryptographic Authentication M. Bhatia V. Manral M. Fanto R. White M. Barnes T. Li R. Atkinson October 2009 ASCII 30221 14 open shortest path first nist secure hash standard hashed message authentication code

This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]

 draft-ietf-ospf-hmac-sha-07 RFC2328 RFC7474 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5709 10.17487/RFC5709 RFC5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes L. Berger D. Papadimitriou JP. Vasseur January 2010 ASCII 27233 12 resource reservation protocol rsvp multiprotocol label switching generalized mpls rsvp-te

This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. [STANDARDS-TRACK]

 draft-ietf-mpls-gmpls-lsp-reroute-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5710 RFC5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages JP. Vasseur Editor G. Swallow I. Minei January 2010 ASCII 12596 7 rsvp-te

The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. [STANDARDS-TRACK]

 draft-ietf-mpls-3209-patherr-06 RFC3209 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5711 RFC5712 MPLS Traffic Engineering Soft Preemption M. Meyer Editor JP. Vasseur Editor January 2010 ASCII 27371 13 multiprotocol label switching mpls-te te lsp

This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK]

 draft-ietf-mpls-soft-preemption-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5712 RFC5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) H. Moustafa H. Tschofenig S. De Cnodder January 2010 ASCII 39600 18 ANCP security ANCP threats ANCP attacks

The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.

This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ancp-security-threats-08 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5713 RFC5714 IP Fast Reroute Framework M. Shand S. Bryant January 2010 ASCII 32854 15 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology loop-free-convergence

This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rtgwg-ipfrr-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5714 RFC5715 A Framework for Loop-Free Convergence M. Shand S. Bryant January 2010 ASCII 53223 22 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology PLSN not-via Incremental Cost Packet Marking ordered fib ofib

A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.

This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rtgwg-lf-conv-frmwk-07 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5715 RFC5716 Requirements for Federated File Systems J. Lentini C. Everhart D. Ellard R. Tewari M. Naik January 2010 ASCII 58051 26 Federated File Systems Federated FA FedFS Fed-FS Federation

This document describes and lists the functional requirements of a federated file system and defines related terms. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nfsv4-federated-fs-reqts-06 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5716 RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF B. Lengyel M. Bjorklund December 2009 ASCII 42529 23 YANG Network Management

The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]

 draft-ietf-netconf-partial-lock-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=5717 10.17487/RFC5717 RFC5718 An In-Band Data Communication Network For the MPLS Transport Profile D. Beller A. Farrel January 2010 ASCII 18997 8 MPLS-TP DCN SCN MCN G-Ach GAL

The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.

This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-gach-dcn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5718 RFC5719 Updated IANA Considerations for Diameter Command Code Allocations D. Romascanu H. Tschofenig January 2010 ASCII 11268 5 diameter application diameter commands

The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.

This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS-TRACK]

 draft-ietf-dime-diameter-cmd-iana-01 RFC6733 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5719 RFC5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) F. Templin February 2010 ASCII 65956 26 enterprise network

RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-templin-ranger-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5720 RFC5721 POP3 Support for UTF-8 R. Gellens C. Newman February 2010 ASCII 26250 13 POP UTF8 mail email internationalization charset

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 error strings. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-pop-09 RFC6856 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5721 RFC5722 Handling of Overlapping IPv6 Fragments S. Krishnan December 2009 ASCII 11838 6 fragmentation overlapping fragments

The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]

 draft-ietf-6man-overlap-fragment-03 RFC2460 RFC6946 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5722 10.17487/RFC5722 RFC5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption Y. Sheffer H. Tschofenig January 2010 ASCII 59201 26 IKE Internet Key Exchange session resumption failover high availability cryptographic ticket cryptographic token stateful resumption stateless resumption

The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.

To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.

In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.

A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ikev2-resumption-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5723 RFC5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) E. Wilde A. Vaha-Sipila January 2010 ASCII 39345 18 GSM SMS URI scheme

This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]

 draft-wilde-sms-uri-20 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5724 10.17487/RFC5724 RFC5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen D. Hsu M. Lague February 2010 ASCII 18794 9 Loss repair retransmission FEC

This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-post-repair-rtcp-xr-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5725 10.17487/RFC5725 RFC5726 Mobile IPv6 Location Privacy Solutions Y. Qiu F. Zhao Editor R. Koodli February 2010 ASCII 116016 48 mobopts

Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-mobopts-location-privacy-solutions-16 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5726 RFC5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area J. Peterson C. Jennings R. Sparks March 2010 ASCII 35033 14 RAI sipping

This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427. This memo documents an Internet Best Current Practice.

 draft-peterson-rai-rfc3427bis-04 RFC3427 RFC3265 RFC3969 RFC7957 BCP0067 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5727 10.17487/RFC5727 RFC5728 The SatLabs Group DVB-RCS MIB S. Combes P. Amundsen M. Lambert H-P. Lexow March 2010 ASCII 186132 95 management information base digital video broadcasting return channel DVB-RCS-MIB

This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-combes-ipdvb-mib-rcs-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5728 10.17487/RFC5728 RFC5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm J. Korhonen Editor M. Jones L. Morand T. Tsou December 2009 ASCII 23482 11 nai network access identifier decorated multi-realm

This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]

 draft-ietf-dime-nai-routing-04 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5729 RFC5730 Extensible Provisioning Protocol (EPP) S. Hollenbeck August 2009 ASCII 134464 67 shared framework mapping

This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4930bis-02 RFC4930 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5730 10.17487/RFC5730 RFC5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck August 2009 ASCII 87764 44 EPP Extensible Provisioning Protocol XML domain domain name

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4931bis-01 RFC4931 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5731 10.17487/RFC5731 RFC5732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck August 2009 ASCII 56219 29 EPP Extensible Provisioning Protocol XML host

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4932bis-01 RFC4932 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5732 RFC5733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck August 2009 ASCII 80698 41 EPP Extensible Provisioning Protocol XML contact registrant

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4933bis-02 RFC4933 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5733 RFC5734 Extensible Provisioning Protocol (EPP) Transport over TCP S. Hollenbeck August 2009 ASCII 27887 13 EPP Extensible Provisioning Protocol XML TCP TLS

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4934bis-01 RFC4934 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5734 10.17487/RFC5734 RFC5735 Special Use IPv4 Addresses M. Cotton L. Vegoda January 2010 ASCII 20369 10 internet protocol space assignments

This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.

 draft-iana-rfc3330bis-11 RFC3330 RFC6890 RFC6598 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5735 10.17487/RFC5735 RFC5736 IANA IPv4 Special Purpose Address Registry G. Huston M. Cotton L. Vegoda January 2010 ASCII 10823 6

This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iana-special-ipv4-registry-02 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5736 RFC5737 IPv4 Address Blocks Reserved for Documentation J. Arkko M. Cotton L. Vegoda January 2010 ASCII 7036 4 example addresses IPv4

Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iana-ipv4-examples-02 RFC1166 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5737 RFC5738 IMAP Support for UTF-8 P. Resnick C. Newman March 2010 ASCII 32061 15 internet message access protocol imap4rev1

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 document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-imap-utf8-09 RFC6855 RFC3501 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5738 10.17487/RFC5738 RFC5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) P. Eronen J. Laganier C. Madson February 2010 ASCII 67691 32 remote vpn access vpn gateway virtual link

When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ipsecme-ikev2-ipv6-config-03 EXPERIMENTAL EXPERIMENTAL IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5739 10.17487/RFC5739 RFC5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol B. Adamson C. Bormann M. Handley J. Macker November 2009 ASCII 268831 96 multicast reliable multicast transport negative-acknowledgment forward error correction packet erasure coding group communication

This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK]

 draft-ietf-rmt-pi-norm-revised-14 RFC3940 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5740 RFC5741 RFC Streams, Headers, and Boilerplates L. Daigle Editor O. Kolkman Editor IAB December 2009 ASCII 32160 16

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-streams-headers-boilerplates-08 RFC7841 RFC2223 RFC4844 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5741 10.17487/RFC5741 RFC5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions H. Alvestrand R. Housley December 2009 ASCII 21067 9

This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.

This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.

 draft-housley-iesg-rfc3932bis-12 RFC3932 RFC2026 RFC3710 BCP0092 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5742 RFC5743 Definition of an Internet Research Task Force (IRTF) Document Stream A. Falk December 2009 ASCII 19885 9 irtf stream

This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-rfcs-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5743 RFC5744 Procedures for Rights Handling in the RFC Independent Submission Stream R. Braden J. Halpern December 2009 ASCII 13509 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

 draft-braden-independent-submission-02 RFC4846 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5744 RFC5745 Procedures for Rights Handling in the RFC IAB Stream A. Malis Editor IAB December 2009 ASCII 12518 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

 draft-malis-iab-stream-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5745 RFC5746 Transport Layer Security (TLS) Renegotiation Indication Extension E. Rescorla M. Ray S. Dispensa N. Oskov February 2010 ASCII 33790 15 ssl secure socket layer

Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]

 draft-ietf-tls-renegotiation-03 RFC5246 RFC4366 RFC4347 RFC4346 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5746 RFC5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions J. Wu Y. Cui X. Li M. Xu C. Metz March 2010 ASCII 33768 15 IPv4/IPv6 coexistence CNGI CERNET2 Softwire mesh

The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. This document defines an Experimental Protocol for the Internet community.

 draft-wu-softwire-4over6-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5747 RFC5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY) S. Yoon J. Jeong H. Kim H. Jeong Y. Won August 2010 ASCII 8198 5

This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-seokung-msec-mikey-seed-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5748 10.17487/RFC5748 RFC5749 Distribution of EAP-Based Keys for Handover and Re-Authentication K. Hoeper Editor M. Nakhjiri Y. Ohba Editor March 2010 ASCII 27242 12 security authentication mobility EAP key management key distribution

This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]

 draft-ietf-hokey-key-mgm-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5749 10.17487/RFC5749 RFC5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling B. Ramsdell S. Turner January 2010 ASCII 48716 21 encryption certificate multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. [STANDARDS-TRACK]

 draft-ietf-smime-3850bis-11 RFC3850 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5750 RFC5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification B. Ramsdell S. Turner January 2010 ASCII 98638 45 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]

 draft-ietf-smime-3851bis-11 RFC3851 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5751 10.17487/RFC5751 RFC5752 Multiple Signatures in Cryptographic Message Syntax (CMS) S. Turner J. Schaad January 2010 ASCII 34502 17 signeddata signerinfo downgrade attacks algorithm migration

Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]

 draft-ietf-smime-multisig-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5752 10.17487/RFC5752 RFC5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Turner D. Brown January 2010 ASCII 112095 61 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-smime-3278bis-09 RFC3278 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5753 10.17487/RFC5753 RFC5754 Using SHA2 Algorithms with Cryptographic Message Syntax S. Turner January 2010 ASCII 21543 10 secure hash algorithm message digest algorithm sha-224 sha-256 sha-384 sha-512 cms dsa digital signature algorithm rsa rivest sharmi adleman ecdsa elliptic curve dsa smimecapabilities

This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]

 draft-ietf-smime-sha2-11 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5754 10.17487/RFC5754 RFC5755 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley S. Turner January 2010 ASCII 101482 50 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]

 draft-ietf-pkix-3281update-05 RFC3281 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5755 10.17487/RFC5755 RFC5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters S. Turner D. Brown K. Yiu R. Housley T. Polk January 2010 ASCII 12017 6 rsa encryption scheme optical asymmetric encryption padding subjectpublickeyinfo

This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc4055-update-02 RFC4055 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5756 10.17487/RFC5756 RFC5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey T. Schmidt M. Waehlisch G. Fairhurst February 2010 ASCII 92632 37 PMIPv6 FMIPv6 HMIPv6 SSM ASM MLD Mobile Multicast Routing Hybrid Multicast Wireless Multipoint

This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-mobopts-mmcastv6-ps-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5757 RFC5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Q. Dang S. Santesson K. Moriarty D. Brown T. Polk January 2010 ASCII 15834 8 digital signature algorithm elliptic curve digital signature algorithm pki

This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]

 draft-ietf-pkix-sha2-dsa-ecdsa-10 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5758 10.17487/RFC5758 RFC5759 Suite B Certificate and Certificate Revocation List (CRL) Profile J. Solinas L. Zieglar January 2010 ASCII 21429 11 x.509 v3 certificates x.509 v2 certificate revocation lists crl

This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-solinas-suiteb-cert-profile-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5759 RFC5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback J. Ott J. Chesterfield E. Schooler February 2010 ASCII 160368 66 real-time transport protocol ssm

This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]

 draft-ietf-avt-rtcpssm-19 RFC6128 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5760 10.17487/RFC5760 RFC5761 Multiplexing RTP Data and Control Packets on a Single Port C. Perkins M. Westerlund April 2010 ASCII 31778 13

This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-and-rtcp-mux-07 RFC3550 RFC3551 RFC8035 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5761 10.17487/RFC5761 RFC5762 RTP and the Datagram Congestion Control Protocol (DCCP) C. Perkins April 2010 ASCII 37537 16 real-time transport protocol

The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]

 draft-ietf-dccp-rtp-07 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5762 RFC5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) J. Fischl H. Tschofenig E. Rescorla May 2010 ASCII 81546 37 stip session initiation protocol fingerprint attribute dtls handshake

This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]

 draft-ietf-sip-dtls-srtp-framework-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5763 10.17487/RFC5763 RFC5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) D. McGrew E. Rescorla May 2010 ASCII 60590 26 secure rtp control protocol srtcp

This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]

 draft-ietf-avt-dtls-srtp-07 RFC7983 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5764 10.17487/RFC5764 RFC5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications H. Schulzrinne E. Marocco E. Ivov February 2010 ASCII 72134 28 p2p overlay rtc voip

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-p2prg-rtc-security-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5765 10.17487/RFC5765 RFC5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) R. Mahy P. Matthews J. Rosenberg April 2010 ASCII 172112 67 NAT TURN STUN ICE

If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]

 draft-ietf-behave-turn-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5766 10.17487/RFC5766 RFC5767 User-Agent-Driven Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba April 2010 ASCII 23270 11 SIP IMS privacy guidelines

This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sip-ua-privacy-08 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5767 RFC5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) J. Rosenberg April 2010 ASCII 12962 6 SIP NAT

This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed. [STANDARDS-TRACK]

 draft-ietf-sip-ice-option-tag-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5768 RFC5769 Test Vectors for Session Traversal Utilities for NAT (STUN) R. Denis-Courmont April 2010 ASCII 15407 11 STUN test vectors fingerprint

The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-behave-stun-test-vectors-04 INFORMATIONAL INFORMATIONAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5769 10.17487/RFC5769 RFC5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators M. Komu T. Henderson H. Tschofenig J. Melen A. Keranen Editor April 2010 ASCII 79767 34 ICE HIP relay

This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-nat-traversal-09 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5770 RFC5771 IANA Guidelines for IPv4 Multicast Address Assignments M. Cotton L. Vegoda D. Meyer March 2010 ASCII 22239 11 internet assigned numbers authority protocol parameters

This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice.

 draft-ietf-mboned-rfc3171bis-08 RFC3138 RFC3171 RFC2780 BCP0051 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=5771 10.17487/RFC5771 RFC5772 A Set of Possible Requirements for a Future Routing Architecture A. Doria E. Davies F. Kastenholz February 2010 ASCII 158456 68 Routing Research Group RRG IDR FDR

The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future.

The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

 draft-irtf-routing-reqs-11 HISTORIC HISTORIC IRTF 10.17487/RFC5772 RFC5773 Analysis of Inter-Domain Routing Requirements and History E. Davies A. Doria February 2010 ASCII 127384 51 History IRTF Routing Research Group RRG Routing Requirements IDR FDR

This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

 draft-irtf-routing-history-10 HISTORIC HISTORIC IRTF http://www.rfc-editor.org/errata_search.php?rfc=5773 10.17487/RFC5773 RFC5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition K. Wolf A. Mayrhofer March 2010 ASCII 68468 33

This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. This memo documents an Internet Best Current Practice.

 draft-ietf-geopriv-civic-address-recommendations-03 RFC4776 BCP0154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5774 10.17487/RFC5774 RFC5775 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby M. Watson L. Vicisano April 2010 ASCII 59518 24 Forward Error Correction FEC Layered Coding Transport LCT Building Block WEBRC reliable +object delivery reliable file delivery broadcast multicast

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. [STANDARDS-TRACK]

 draft-ietf-rmt-pi-alc-revised-10 RFC3450 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5775 RFC5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca A. Francillon S. Faurite April 2010 ASCII 135605 58 TESLA FLUTE ALC NORM

This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-msec-tesla-for-alc-norm-10 EXPERIMENTAL EXPERIMENTAL IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=5776 10.17487/RFC5776 RFC5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter J. Korhonen H. Tschofenig M. Arumaithurai M. Jones Editor A. Lior February 2010 ASCII 91305 43 Diameter Qos Attributes Traffic classification Filtering Firewalling

This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. [STANDARDS-TRACK]

 draft-ietf-dime-qos-attributes-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5777 10.17487/RFC5777 RFC5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction J. Korhonen Editor H. Tschofenig J. Bournelle G. Giaretta M. Nakhjiri February 2010 ASCII 75444 34

Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server.

This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. [STANDARDS-TRACK]

 draft-ietf-dime-mip6-split-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5778 10.17487/RFC5778 RFC5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server J. Korhonen Editor J. Bournelle K. Chowdhury A. Muhanna U. Meyer February 2010 ASCII 44709 20 aaa authentication authorization and accounting

This specification defines Authentication, Authorization, and Accounting (AAA) interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. [STANDARDS-TRACK]

 draft-ietf-dime-pmip6-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5779 RFC5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) D. MacDonald B. Lowekamp May 2010 ASCII 67835 27 NAT type diagnostics

This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-behave-nat-behavior-discovery-08 EXPERIMENTAL EXPERIMENTAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5780 10.17487/RFC5780 RFC5781 The rsync URI Scheme S. Weiler D. Ward R. Housley February 2010 ASCII 6704 4 rsyncuri

This document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-weiler-rsync-uri-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5781 RFC5782 DNS Blacklists and Whitelists J. Levine February 2010 ASCII 25296 11 mail electronic mail DNS spam blacklist whitelist

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-asrg-dnsbl-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5782 10.17487/RFC5782 RFC5783 Congestion Control in the RFC Series M. Welzl W. Eddy February 2010 ASCII 68231 28

This document is an informational snapshot taken by the IRTF\'s Internet Congestion Control Research Group (ICCRG) in October 2008. It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-iccrg-cc-rfcs-07 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5783 10.17487/RFC5783 RFC5784 Sieve Email Filtering: Sieves and Display Directives in XML N. Freed S. Vedam March 2010 ASCII 57087 32 SMTP ESMTP Sieve

This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.

The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. [STANDARDS-TRACK]

 draft-freed-sieve-in-xml-07 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5784 10.17487/RFC5784 RFC5785 Defining Well-Known Uniform Resource Identifiers (URIs) M. Nottingham E. Hammer-Lahav April 2010 ASCII 13779 8 well-known locations

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]

 draft-nottingham-site-meta-05 RFC2616 RFC2818 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5785 10.17487/RFC5785 RFC5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions R. Aggarwal K. Kompella March 2010 ASCII 15541 7

OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.

In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.

This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]

 draft-ietf-ospf-te-node-addr-07 RFC3630 RFC6827 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5786 10.17487/RFC5786 RFC5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing D. Papadimitriou March 2010 ASCII 67247 29 itu-t ospfv2 link state routing protocol

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. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ccamp-gmpls-ason-routing-ospf-09 RFC6827 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp 10.17487/RFC5787 RFC5788 IMAP4 Keyword Registry A. Melnikov D. Cridland March 2010 ASCII 22497 11 IMAP email tag label keyword

The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. [STANDARDS TRACK]

 draft-melnikov-imap-keywords-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5788 RFC5789 PATCH Method for HTTP L. Dusseault J. Snell March 2010 ASCII 21706 10 HTTP PATCH Hypertext Transfer Protocol

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]

 draft-dusseault-http-patch-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5789 10.17487/RFC5789 RFC5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols H. Liu W. Cao H. Asaeda February 2010 ASCII 39394 17 IGMP MLD Lite lightweight

This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]

 draft-ietf-mboned-lightweight-igmpv3-mldv2-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5790 RFC5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete J. Reschke J. Kunze February 2010 ASCII 3658 2 DCMI Dublin Core Metadata Initiative XHTML HTML metadata

This document obsoletes RFC 2731, "Encoding Dublin Core Metadata in HTML", as further development of this specification has moved to the Dublin Core Metadata Initiative (DCMI). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-reschke-rfc2731bis-05 RFC2731 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5791 10.17487/RFC5791 RFC5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) P. Sangster K. Narayan March 2010 ASCII 193345 83

This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

 draft-ietf-nea-pa-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5792 10.17487/RFC5792 RFC5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) R. Sahita S. Hanna R. Hurst K. Narayan March 2010 ASCII 169140 76 NEA Network Endpoint Assessment

This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

 draft-ietf-nea-pb-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5793 10.17487/RFC5793 RFC5794 A Description of the ARIA Encryption Algorithm J. Lee J. Lee J. Kim D. Kwon C. Kim March 2010 ASCII 31049 18 ARIA encryption block cipher

This document describes the ARIA encryption algorithm. ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-nsri-aria-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5794 10.17487/RFC5794 RFC5795 The RObust Header Compression (ROHC) Framework K. Sandlund G. Pelletier L-E. Jonsson March 2010 ASCII 89850 41

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.

This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc4995bis-03 RFC4995 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5795 10.17487/RFC5795 RFC5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages W. Atwood S. Islam M. Siami March 2010 ASCII 45442 21 security PIM-SM routing security multicast routing link-local message Protocol Independent Multicast Sparse Mode

RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. [STANDARDS-TRACK]

 draft-ietf-pim-sm-linklocal-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC5796 RFC5797 FTP Command and Extension Registry J. Klensin A. Hoenes March 2010 ASCII 24535 10 FTP FEAT command FTP FEAT response

Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. [STANDARDS-TRACK]

 draft-klensin-ftp-registry-04 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5797 10.17487/RFC5797 RFC5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 S. Nadas Editor March 2010 ASCII 90322 40

This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]

 draft-ietf-vrrp-unified-spec-05 RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp http://www.rfc-editor.org/errata_search.php?rfc=5798 10.17487/RFC5798 RFC5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family S. Josefsson N. Williams July 2010 ASCII 52543 26

This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK]

 draft-ietf-sasl-gs2-20 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5801 10.17487/RFC5801 RFC5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms C. Newman A. Menon-Sen A. Melnikov N. Williams July 2010 ASCII 59049 28 simple authentication and security layer

The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.

This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]

 draft-ietf-sasl-scram-11 RFC7677 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5802 10.17487/RFC5802 RFC5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets A. Melnikov July 2010 ASCII 8195 4 authpassword simple authentication and security layer sasl

This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-melnikov-sasl-scram-ldap-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5803 10.17487/RFC5803 RFC5804 A Protocol for Remotely Managing Sieve Scripts A. Melnikov Editor T. Martin July 2010 ASCII 103194 49 managesieve

Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. [STANDARDS TRACK]

 draft-ietf-sieve-managesieve-09 RFC7817 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5804 10.17487/RFC5804 RFC5805 Lightweight Directory Access Protocol (LDAP) Transactions K. Zeilenga March 2010 ASCII 21723 11 acid atomic consistency isolation durability

Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. This document defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldap-txn-15 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5805 RFC5806 Diversion Indication in SIP S. Levy M. Mohali Editor March 2010 ASCII 107160 53

This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows.

This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.

This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. This document defines a Historic Document for the Internet community.

 draft-levy-sip-diversion-11 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5806 10.17487/RFC5806 RFC5807 Definition of Master Key between PANA Client and Enforcement Point Y. Ohba A. Yegin March 2010 ASCII 13808 7 protocol for carrying authentication for network access

This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]

 draft-ohba-pana-pemk-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5807 RFC5808 Requirements for a Location-by-Reference Mechanism R. Marshall Editor May 2010 ASCII 32475 14

This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-geopriv-lbyr-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5808 RFC5810 Forwarding and Control Element Separation (ForCES) Protocol Specification A. Doria Editor J. Hadi Salim Editor R. Haas Editor H. Khosravi Editor W. Wang Editor L. Dong R. Gopal J. Halpern March 2010 ASCII 239754 124 control elements forwarding elements fe ce network element ne tml transport mapping layer

This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements (CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). [STANDARDS-TRACK]

 draft-ietf-forces-protocol-22 RFC7121 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5810 10.17487/RFC5810 RFC5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol J. Hadi Salim K. Ogawa March 2010 ASCII 61443 28 ForCES TML stream conrol transmission protocol

This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. [STANDARDS TRACK]

 draft-ietf-forces-sctptml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5811 RFC5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model J. Halpern J. Hadi Salim March 2010 ASCII 301491 134 forwarding element control element

This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. [STANDARDS-TRACK]

 draft-ietf-forces-model-16 RFC7408 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5812 10.17487/RFC5812 RFC5813 Forwarding and Control Element Separation (ForCES) MIB R. Haas March 2010 ASCII 31353 17 management information base network element ne forces-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). [STANDARDS-TRACK]

 draft-ietf-forces-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5813 RFC5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks W. Sun Editor G. Zhang Editor March 2010 ASCII 93386 44 Signaling performance RSVP-TE delay measurement control plane performance

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. [STANDARDS-TRACK]

 draft-ietf-ccamp-lsp-dppm-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5814 RFC5815 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz April 2010 ASCII 131258 64 Selector Collector Exporter Sampling Filtering IPFIX IPFIX-MIB IPFIX-SELECTOR-MIB

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. [STANDARDS-TRACK]

 draft-ietf-ipfix-mib-10 RFC6615 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5815 10.17487/RFC5815 RFC5816 ESSCertIDv2 Update for RFC 3161 S. Santesson N. Pope April 2010 ASCII 10216 5 signer certificate secure hash algorithm sha-1

This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK]

 draft-ietf-pkix-rfc3161-update-09 RFC3161 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5816 RFC5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Z. Ali JP. Vasseur A. Zamfir J. Newton April 2010 ASCII 24219 11 mpls-te te

MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.

This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-mpls-graceful-shutdown-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5817 RFC5818 Data Channel Status Confirmation Extensions for the Link Management Protocol D. Li H. Xu S. Bardalai J. Meuric D. Caviglia April 2010 ASCII 34092 15 LMP

This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS-TRACK]

 draft-ietf-ccamp-confirm-data-channel-status-09 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5818 RFC5819 IMAP4 Extension for Returning STATUS Information in Extended LIST A. Melnikov T. Sirainen March 2010 ASCII 10584 6 list lsub

Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK]

 draft-ietf-morg-status-in-list-01 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=5819 10.17487/RFC5819 RFC5820 Extensions to OSPF to Support Mobile Ad Hoc Networking A. Roy Editor M. Chandra Editor March 2010 ASCII 95603 41 open shortest path first manet ospf-or ospf-overlapping relay link-local signaling lls ospf-manet

This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS-TRACK]

 draft-ietf-ospf-manet-or-03 RFC7137 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5820 RFC5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN K. Kumaki Editor R. Zhang Y. Kamite April 2010 ASCII 56102 27 triple-play service

Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.

Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC5824 RFC5825 Displaying Downgraded Messages for Email Address Internationalization K. Fujiwara B. Leiba April 2010 ASCII 26314 14 EAI Email Address Internationalization Downgrade MAIL

This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-downgraded-display-03 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5825 RFC5826 Home Automation Routing Requirements in Low-Power and Lossy Networks A. Brandt J. Buron G. Porcu April 2010 ASCII 38751 17 roll routing over low power and lossy

This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-roll-home-routing-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=5826 10.17487/RFC5826 RFC5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) M. Allman K. Avrachenkov U. Ayesta J. Blanton P. Hurtig May 2010 ASCII 35383 15 transmission control protocol fast retransmission

This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRACK]

 draft-ietf-tcpm-early-rexmt-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5827 RFC5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework D. Fedyk L. Berger L. Andersson March 2010 ASCII 46396 20 transport networks

There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-gmpls-ethernet-arch-09 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5828 RFC5829 Link Relation Types for Simple Version Navigation between Web Resources A. Brown G. Clemm J. Reschke Editor April 2010 ASCII 18649 12

This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-brown-versioning-link-relations-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5829 RFC5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms V. Dolmatov Editor March 2010 ASCII 36234 19 russian federal standard electronic encryption decryption message authentication russian cryptographic standard

This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-dolmatov-cryptocom-gost2814789-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5830 10.17487/RFC5830 RFC5831 GOST R 34.11-94: Hash Function Algorithm V. Dolmatov Editor March 2010 ASCII 25844 17 russian federal standard russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-dolmatov-cryptocom-gost341194-07 RFC6986 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5831 10.17487/RFC5831 RFC5832 GOST R 34.10-2001: Digital Signature Algorithm V. Dolmatov Editor March 2010 ASCII 38936 22 russian federal standard digital signature russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.

 draft-dolmatov-cryptocom-gost34102001-08 RFC7091 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5832 10.17487/RFC5832 RFC5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII 143911 73 mib CAPWAP-BASE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-capwap-base-mib-09 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5833 RFC5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII 51144 25 mib CAPWAP-DOT11-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-capwap-802dot11-mib-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5834 RFC5835 Framework for Metric Composition A. Morton Editor S. Van den Berghe Editor April 2010 ASCII 38138 18

This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-framework-compagg-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5835 RFC5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement Y. Ohba Editor Q. Wu Editor G. Zorn Editor April 2010 ASCII 45912 20 eap early authentication

Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-hokey-preauth-ps-12 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC5836 RFC5837 Extending ICMP for Interface and Next-Hop Identification A. Atlas Editor R. Bonica Editor C. Pignataro Editor N. Shen JR. Rivers April 2010 ASCII 38109 18 Internet Control Message Protocol

This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded.

Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK]

 draft-atlas-icmp-unnumbered-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5837 RFC5838 Support of Address Families in OSPFv3 A. Lindem Editor S. Mirtorabi A. Roy M. Barnes R. Aggarwal April 2010 ASCII 26193 13 af instance id

This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]

 draft-ietf-ospf-af-alt-10 RFC6969 RFC7949 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5838 RFC5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification A. Niemi D. Willis Editor May 2010 ASCII 52999 25 SIP events subnot-etags optimization

The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS-TRACK]

 draft-ietf-sipcore-subnot-etags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC5839 RFC5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility K. Grewal G. Montenegro M. Bhatia April 2010 ASCII 34733 15 wesp

This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS-TRACK]

 draft-ietf-ipsecme-traffic-visibility-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5840 RFC5841 TCP Option to Denote Packet Mood R. Hay W. Turkal April 1 2010 ASCII 15024 9

This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-1april2010-tcp-option-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5841 10.17487/RFC5841 RFC5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) G. Clemm J. Crawford J. Reschke Editor J. Whitehead April 2010 ASCII 91544 45 HTTP WebDAV collections hard link

This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-webdav-bind-27 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5842 RFC5843 Additional Hash Algorithms for HTTP Instance Digests A. Bryan April 2010 ASCII 6731 5 Hypertext Transfer Protocol HTTP Digest Algorithm Values registry update

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" defines values for digest algorithms used by Instance Digests in HTTP. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. This document adds new values to the registry and updates previous values. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-bryan-http-digest-algorithm-values-update-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5843 10.17487/RFC5843 RFC5844 IPv4 Support for Proxy Mobile IPv6 R. Wakikawa S. Gundavelli May 2010 ASCII 116102 49 NAT traversal Dual Stack Mobility IPv4 Support IPv4 Support for PMIPv6

This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. [STANDARDS-TRACK]

 draft-ietf-netlmm-pmip6-ipv4-support-18 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5844 RFC5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 A. Muhanna M. Khalil S. Gundavelli K. Leung June 2010 ASCII 56198 25 PMIP6 PMIPv6 Downlink GRE Key Uplink GRE Key TLV-Header Tunneling TLV-Header Tunneling GRE Key Exchange

This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS-TRACK]

 draft-ietf-netlmm-grekey-option-09 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5845 RFC5846 Binding Revocation for IPv6 Mobility A. Muhanna M. Khalil S. Gundavelli K. Chowdhury P. Yegani June 2010 ASCII 95467 39 PMIP6 PMIPv6 Binding Revocation Indication BRI Binding Revocation Acknowledgement BRA MIP6 DSMIP6 Multiple Care-of Addresses PMIPv6 Revocation Bulk PMIPv6 Revocation

This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. [STANDARDS-TRACK]

 draft-ietf-mext-binding-revocation-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5846 RFC5847 Heartbeat Mechanism for Proxy Mobile IPv6 V. Devarapalli Editor R. Koodli Editor H. Lim N. Kant S. Krishnan J. Laganier June 2010 ASCII 23317 11 Node Reachability Restarts Failure Detection

Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. [STANDARDS TRACK]

 draft-ietf-netlmm-pmipv6-heartbeat-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5847 10.17487/RFC5847 RFC5848 Signed Syslog Messages J. Kelsey J. Callas A. Clemm May 2010 ASCII 102805 40 syslog syslog-sign

This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK]

 draft-ietf-syslog-sign-29 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5848 RFC5849 The OAuth 1.0 Protocol E. Hammer-Lahav Editor April 2010 ASCII 80786 38 authorization delegation

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hammer-oauth-10 RFC6749 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5849 10.17487/RFC5849 RFC5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP) R. Mahy R. Sparks J. Rosenberg D. Petrie A. Johnston Editor May 2010 ASCII 104361 44 call control multiparty features mixing refer 3pcc Refer method Replaces header field Join header field conferencing

This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-cc-framework-12 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5850 10.17487/RFC5850 RFC5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks S. Ooghe N. Voigt M. Platnic T. Haag S. Wadhwa May 2010 ASCII 116214 47 Access Node Control Protocol Topology Discovery Loop Configuration Remote Connectivity Test Multicast Access Node Network Access Server

The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.

This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ancp-framework-13 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5851 RFC5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network D. Caviglia D. Ceccarelli D. Bramanti D. Li S. Bardalai April 2010 ASCII 49293 23 resource reservation protocol handover procedures

In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.

This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]

 draft-ietf-ccamp-pc-spc-rsvpte-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5852 RFC5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments J. Hautakorpi Editor G. Camarillo R. Penfield A. Hawrylyshen M. Bhatia April 2010 ASCII 60476 26

This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-sbc-funcs-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5853 RFC5854 The Metalink Download Description Format A. Bryan T. Tsujikawa N. McNab P. Poeml June 2010 ASCII 72641 39 file transfer mirrors data integrity hash xml http hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files. [STANDARDS-TRACK]

 draft-bryan-metalink-28 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5854 RFC5855 Nameservers for IPv4 and IPv6 Reverse Zones J. Abley T. Manderson May 2010 ASCII 23027 12 IN-ADDR.ARPA IP6.ARPA reverse mapping

This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). This memo documents an Internet Best Current Practice.

 draft-jabley-reverse-servers-01 BCP0155 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5855 RFC5856 Integration of Robust Header Compression over IPsec Security Associations E. Ertekin R. Jasani C. Christou C. Bormann May 2010 ASCII 34548 15 ROHC ROHCoIPsec

IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rohc-hcoipsec-13 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC5856 RFC5857 IKEv2 Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou R. Jasani T. Kivinen C. Bormann May 2010 ASCII 27063 13 ROHC ROHCoIPsec

In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). [STANDARDS-TRACK]

 draft-ietf-rohc-ikev2-extensions-hcoipsec-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5857 10.17487/RFC5857 RFC5858 IPsec Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou C. Bormann May 2010 ASCII 31539 15 ROHC ROHCoIPsec

Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the Security Policy Database (SPD) and Security Association Database (SAD) are required. This document describes the IPsec extensions required to support ROHCoIPsec. [STANDARDS-TRACK]

 draft-ietf-rohc-ipsec-extensions-hcoipsec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5858 10.17487/RFC5858 RFC5859 TFTP Server Address Option for DHCPv4 R. Johnson June 2010 ASCII 11656 6 voip

This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic Host Configuration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-raj-dhc-tftp-addr-option-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5859 RFC5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks M. Vigoureux Editor D. Ward Editor M. Betts Editor May 2010 ASCII 36951 17 MPLS-TP OAM

This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-oam-requirements-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5860 RFC5861 HTTP Cache-Control Extensions for Stale Content M. Nottingham May 2010 ASCII 10359 6

This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-nottingham-http-stale-controls-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5861 10.17487/RFC5861 RFC5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE S. Yasukawa A. Farrel June 2010 ASCII 24219 11 mpls gmpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-p2mp-req-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5862 RFC5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations T. Hansen E. Siegel P. Hallam-Baker D. Crocker May 2010 ASCII 126915 51 Email Electronic Mail Internet Mail Message Verification

DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dkim-deployment-11 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5863 RFC5864 DNS SRV Resource Records for AFS R. Allbery April 2010 ASCII 23846 10 domain name system srv rr distributed file system afsdb rr

This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC 1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. [STANDARDS TRACK]

 draft-allbery-afs-srv-records-05 RFC1183 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5864 10.17487/RFC5864 RFC5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic F. Baker J. Polk M. Dolly May 2010 ASCII 33167 14 real-time traffic

This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. [STANDARDS-TRACK]

 draft-ietf-tsvwg-admitted-realtime-dscp-07 RFC4542 RFC4594 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=5865 10.17487/RFC5865 RFC5866 Diameter Quality-of-Service Application D. Sun Editor P. McCann H. Tschofenig T. Tsou A. Doria G. Zorn Editor May 2010 ASCII 122639 51 Diameter AAA QoS Policy VoIP SIP

This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined. [STANDARDS TRACK]

 draft-ietf-dime-diameter-qos-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5866 RFC5867 Building Automation Routing Requirements in Low-Power and Lossy Networks J. Martocci Editor P. De Mil N. Riou W. Vermeylen June 2010 ASCII 57123 26

The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-roll-building-routing-reqs-09 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5867 RFC5868 Problem Statement on the Cross-Realm Operation of Kerberos S. Sakane K. Kamada S. Zrelli M. Ishiyama May 2010 ASCII 30327 13

This document provides background information regarding large-scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.

This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-krb-wg-cross-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5868 RFC5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) H. Krawczyk P. Eronen May 2010 ASCII 25854 14

This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-krawczyk-hkdf-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5869 RFC5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI) A. Mayrhofer C. Spanring June 2010 ASCII 45943 23 geography geo uri scheme

This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]

 draft-ietf-geopriv-geo-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5870 RFC5871 IANA Allocation Guidelines for the IPv6 Routing Header J. Arkko S. Bradner May 2010 ASCII 4000 3 routing type field

This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]

 draft-ietf-6man-iana-routing-header-00 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5871 RFC5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA) J. Arkko A. Yegin May 2010 ASCII 7999 5

This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). [STANDARDS-TRACK]

 draft-arkko-pana-iana-02 RFC5191 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5872 RFC5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA) Y. Ohba A. Yegin May 2010 ASCII 17137 8

This document defines an extension to the Protocol for Carrying Authentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pana-preauth-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5873 RFC5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources J. Rosenberg J. Urpalainen May 2010 ASCII 49509 24 SIP Instant Messaging

This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package. [STANDARDS-TRACK]

 draft-ietf-simple-xcap-diff-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5874 RFC5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package J. Urpalainen D. Willis Editor May 2010 ASCII 58307 27 xcap-diff xcap diff

This document describes an "xcap-diff" SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format. [STANDARDS TRACK]

 draft-ietf-sip-xcapevent-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5875 RFC5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP) J. Elwell April 2010 ASCII 25860 11 SIP P-Asserted-Identity

The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of the P-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use of P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extends RFC 3325 to cover these situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-update-pai-09 RFC3325 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5876 RFC5877 The application/pkix-attr-cert Media Type for Attribute Certificates R. Housley May 2010 ASCII 6692 4

This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-attr-cert-mime-type-03 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5877 10.17487/RFC5877 RFC5878 Transport Layer Security (TLS) Authorization Extensions M. Brown R. Housley May 2010 ASCII 44594 19 handshake protocol

This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message. This document defines an Experimental Protocol for the Internet community.

 draft-housley-tls-authz-extns-09 RFC5246 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5878 10.17487/RFC5878 RFC5879 Heuristics for Detecting ESP-NULL Packets T. Kivinen D. McDonald May 2010 ASCII 72917 32 IPsec Wrapped ESP (WESP) deep-inspection packet inspection

This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-esp-null-heuristics-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5879 RFC5880 Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII 110279 49

This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]

 draft-ietf-bfd-base-11 RFC7419 RFC7880 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5880 10.17487/RFC5880 RFC5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) D. Katz D. Ward June 2010 ASCII 14307 7

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]

 draft-ietf-bfd-v4v6-1hop-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5881 10.17487/RFC5881 RFC5882 Generic Application of Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII 40439 17

This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]

 draft-ietf-bfd-generic-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5882 10.17487/RFC5882 RFC5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths D. Katz D. Ward June 2010 ASCII 11765 6

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]

 draft-ietf-bfd-multihop-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC5883 RFC5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) R. Aggarwal K. Kompella T. Nadeau G. Swallow June 2010 ASCII 27734 12 Multiprotocol Label Switching lsp ping

One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. [STANDARDS-TRACK]

 draft-ietf-bfd-mpls-07 RFC1122 RFC7726 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC5884 RFC5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) T. Nadeau Editor C. Pignataro Editor June 2010 ASCII 30866 14 Pseudowire VCCV BFD VCCV-BFD PW OAM

This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. [STANDARDS-TRACK]

 draft-ietf-pwe3-vccv-bfd-07 RFC6478 RFC7885 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5885 RFC5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture JP. Vasseur Editor JL. Le Roux Y. Ikejiri June 2010 ASCII 56554 26

A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".

In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK]

 draft-ietf-pce-monitoring-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5886 RFC5887 Renumbering Still Needs Work B. Carpenter R. Atkinson H. Flinck May 2010 ASCII 87131 35

This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-carpenter-renum-needs-work-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5887 RFC5888 The Session Description Protocol (SDP) Grouping Framework G. Camarillo H. Schulzrinne June 2010 ASCII 43924 21 SDP grouping SIP

In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS-TRACK]

 draft-ietf-mmusic-rfc3388bis-04 RFC3388 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5888 10.17487/RFC5888 RFC5889 IP Addressing Model in Ad Hoc Networks E. Baccelli Editor M. Townsley Editor September 2010 ASCII 14918 8 mobile network ad hoc network MANET network architecture addressing framework configuration routing IP networks

This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-autoconf-adhoc-addr-model-03 INFORMATIONAL INFORMATIONAL IETF int autoconf 10.17487/RFC5889 RFC5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework J. Klensin August 2010 ASCII 54245 23 IDNA2008 idn ascii characters

This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]

 draft-ietf-idnabis-defs-13 RFC3490 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5890 10.17487/RFC5890 RFC5891 Internationalized Domain Names in Applications (IDNA): Protocol J. Klensin August 2010 ASCII 38105 17 IDNA2008 idn ascii characters idna applications

This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

 draft-ietf-idnabis-protocol-18 RFC3490 RFC3491 RFC3492 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5891 10.17487/RFC5891 RFC5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) P. Faltstrom Editor August 2010 ASCII 187370 70 IDNA DNS IDN Unicode IDNA2008

This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).

It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]

 draft-ietf-idnabis-tables-09 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5892 10.17487/RFC5892 RFC5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) H. Alvestrand Editor C. Karp August 2010 ASCII 38870 17 IDNA2008 idn ascii characters Bidi

The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]

 draft-ietf-idnabis-bidi-07 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis 10.17487/RFC5893 RFC5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale J. Klensin August 2010 ASCII 115174 43 IDNA2008 idn ascii characters

Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-idnabis-rationale-17 INFORMATIONAL INFORMATIONAL IETF app idnabis 10.17487/RFC5894 RFC5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 P. Resnick P. Hoffman September 2010 ASCII 16556 7 user input character mapping locale user interface Unicode

In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-resman-idna2008-mappings-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5895 RFC5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy L. Hornquist Astrand S. Hartman June 2010 ASCII 12846 6

Several Generic Security Service Application Program Interface (GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, including CIFS (Common Internet File System) file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). [STANDARDS-TRACK]

 draft-lha-gssapi-delegate-policy-05 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5896 RFC5897 Identification of Communications Services in the Session Initiation Protocol (SIP) J. Rosenberg June 2010 ASCII 60349 23 service identification

This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-service-identification-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5897 RFC5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen G. Camarillo D. Oran D. Wing July 2010 ASCII 38969 17 SIP preconditions connection connectivity

This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. [STANDARDS-TRACK]

 draft-ietf-mmusic-connectivity-precon-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5898 RFC5901 Extensions to the IODEF-Document Class for Reporting Phishing P. Cain D. Jevans July 2010 ASCII 97325 51 Incident Object Description Exchange Format

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS-TRACK]

 draft-cain-post-inch-phishingextns-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5901 RFC5902 IAB Thoughts on IPv6 Network Address Translation D. Thaler L. Zhang G. Lebovitz July 2010 ASCII 37224 15 NAT IPv6 Transparency End-to-End Privacy Multihoming

There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-ipv6-nat-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5902 RFC5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 D. Fu J. Solinas June 2010 ASCII 29175 16 Elliptic Curve Cryptography ECC Internet Key Exchange elliptic curve Diffie-Hellman suite b nist curve

This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-solinas-rfc4753bis-01 RFC4753 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5903 10.17487/RFC5903 RFC5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support G. Zorn June 2010 ASCII 26879 15 RADIUS AAA IEEE 802.16

This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zorn-radius-pkmv1-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5904 RFC5905 Network Time Protocol Version 4: Protocol and Algorithms Specification D. Mills J. Martin Editor J. Burbank W. Kasch June 2010 ASCII 241096 110 NTP SNTP Synchronization

The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]

 draft-ietf-ntp-ntpv4-proto-13 RFC1305 RFC4330 RFC7822 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5905 10.17487/RFC5905 RFC5906 Network Time Protocol Version 4: Autokey Specification B. Haberman Editor D. Mills June 2010 ASCII 140145 58 ntp ntpv4 public key cryptography

This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.

This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ntp-autokey-08 INFORMATIONAL INFORMATIONAL IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5906 10.17487/RFC5906 RFC5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) H. Gerstung C. Elliott B. Haberman Editor June 2010 ASCII 46950 26

The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. [STANDARDS-TRACK]

 draft-ietf-ntp-ntpv4-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5907 10.17487/RFC5907 RFC5908 Network Time Protocol (NTP) Server Option for DHCPv6 R. Gayraud B. Lourdelet June 2010 ASCII 17452 9 Dynamic Host Configuration Protocol for IPv6

The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. [STANDARDS-TRACK]

 draft-ietf-ntp-dhcpv6-ntp-opt-06 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5908 10.17487/RFC5908 RFC5909 Securing Neighbor Discovery Proxy: Problem Statement J-M. Combes S. Krishnan G. Daley July 2010 ASCII 50433 22 send secure neighbor discovery

Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.

Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.

Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-csi-sndp-prob-04 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC5909 RFC5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) J. Gould S. Hollenbeck May 2010 ASCII 72490 36 epp Extensible Provisioning Protocol xml dns security dnssec delegation signer ds

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310. [STANDARDS-TRACK]

 draft-gould-rfc4310bis-07 RFC4310 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5910 10.17487/RFC5910 RFC5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME P. Hoffman J. Schaad June 2010 ASCII 101576 59 S/MIME PKIX ASN.1 modules

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-smime-new-asn1-07 RFC6268 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5911 10.17487/RFC5911 RFC5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) P. Hoffman J. Schaad June 2010 ASCII 216154 117 S/MIME PKIX ASN.1 modules

The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-new-asn1-08 RFC6960 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5912 10.17487/RFC5912 RFC5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension S. Turner S. Chokhani June 2010 ASCII 39650 19 x.509 certificate

This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. [STANDARDS-TRACK]

 draft-ietf-pkix-authorityclearanceconstraints-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5913 RFC5914 Trust Anchor Format R. Housley S. Ashmore C. Wallace June 2010 ASCII 28393 14 trust anchor management

This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. [STANDARDS-TRACK]

 draft-ietf-pkix-ta-format-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5914 10.17487/RFC5914 RFC5915 Elliptic Curve Private Key Structure S. Turner D. Brown June 2010 ASCII 13646 7 ec Standards for Efficient Cryptography Group SECG

This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-ecprivatekey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5915 10.17487/RFC5915 RFC5916 Device Owner Attribute S. Turner June 2010 ASCII 8543 6

This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-deviceowner-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5916 RFC5917 Clearance Sponsor Attribute S. Turner June 2010 ASCII 11618 7

This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-clearancesponsor-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5917 10.17487/RFC5917 RFC5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) R. Asati I. Minei B. Thomas August 2010 ASCII 19414 10 Wildcard Typed Wildcard FEC Element Typed Wildcard FEC Capability

The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-typed-wildcard-07 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5918 10.17487/RFC5918 RFC5919 Signaling LDP Label Advertisement Completion R. Asati P. Mohapatra E. Chen B. Thomas August 2010 ASCII 19455 9 label distribution protocol End-of-LIB Unrecognized Notification

There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-end-of-lib-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5919 10.17487/RFC5919 RFC5920 Security Framework for MPLS and GMPLS Networks L. Fang Editor July 2010 ASCII 152830 66

This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-mpls-and-gmpls-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5920 RFC5921 A Framework for MPLS in Transport Networks M. Bocci Editor S. Bryant Editor D. Frost Editor L. Levrau L. Berger July 2010 ASCII 129318 56 multiprotocol label switching mpls-tp transport profile oam itu-t

This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-framework-12 RFC6215 RFC7274 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5921 RFC5922 Domain Certificates in the Session Initiation Protocol (SIP) V. Gurbani S. Lawrence A. Jeffrey June 2010 ASCII 37667 17 PKIX Authentication Mutual Authentication X.509 TLS

This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS-TRACK]

 draft-ietf-sip-domain-certs-07 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5922 RFC5923 Connection Reuse in the Session Initiation Protocol (SIP) V. Gurbani Editor R. Mahy B. Tate June 2010 ASCII 41905 19 TCP Connection SCTP Connection TLS Connection Transport Connection TLS Virtual Server Authentication

This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. [STANDARDS-TRACK]

 draft-ietf-sip-connect-reuse-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5923 10.17487/RFC5923 RFC5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates S. Lawrence V. Gurbani June 2010 ASCII 16868 8 PKIX SIP Domain X.509 Certificate

This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-sip-eku-08 EXPERIMENTAL EXPERIMENTAL IETF rai sip 10.17487/RFC5924 RFC5925 The TCP Authentication Option J. Touch A. Mankin R. Bonica June 2010 ASCII 106174 48 transmission control protocol border gateway protocol transmission control message digest algorithm

This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]

 draft-ietf-tcpm-tcp-auth-opt-11 RFC2385 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5925 10.17487/RFC5925 RFC5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) G. Lebovitz E. Rescorla June 2010 ASCII 31010 15 transmission control protocol

The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]

 draft-ietf-tcpm-tcp-ao-crypto-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5926 RFC5927 ICMP Attacks against TCP F. Gont July 2010 ASCII 87744 36 vulnerability blind attacks connection-reset attack performance-degrading attack throughput-reduction attack source quench PMTUD Path-MTU Discovery ICMP Destination Unreachable

This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tcpm-icmp-attacks-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5927 RFC5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism M. Petit-Huguenin August 2010 ASCII 23993 11 NAT Traversal

This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS-TRACK]

 draft-ietf-behave-turn-uri-10 RFC7350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC5928 RFC5929 Channel Bindings for TLS J. Altman N. Williams L. Zhu July 2010 ASCII 34061 15 TLS channel binding channel-binding tls-unique tls-server-end-point tls-unique-for-telnet

This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).

Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]

 draft-altman-tls-channel-bindings-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5929 RFC5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol S. Shen Y. Mao NSS. Murthy July 2010 ASCII 12217 6 initialization vector IKE_SA_INIT

This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-aes-ctr-ikev2-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5930 RFC5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password D. Harkins G. Zorn August 2010 ASCII 90275 40 Password Authenticated Key Exchange Dictionary Attack Authentication EAP

This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-harkins-emu-eap-pwd-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5931 10.17487/RFC5931 RFC5932 Camellia Cipher Suites for TLS A. Kato M. Kanda S. Kanno June 2010 ASCII 11949 6 block cipher security camellia tls cbc sha2 camellia encryption algorithm

This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132. [STANDARDS-TRACK]

 draft-kato-tls-rfc4132bis-05 RFC4132 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5932 RFC5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC V. Dolmatov Editor A. Chuprina I. Ustinov July 2010 ASCII 17657 9 domain name system security extensions ECC

This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-gost-07 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5933 RFC5934 Trust Anchor Management Protocol (TAMP) R. Housley S. Ashmore C. Wallace August 2010 ASCII 196043 91 trust anchors TA

This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. [STANDARDS-TRACK]

 draft-ietf-pkix-tamp-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5934 10.17487/RFC5934 RFC5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language M. Ellison B. Natale August 2010 ASCII 28164 14 structure of management information

This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. [STANDARDS-TRACK]

 draft-ietf-opsawg-smi-datatypes-in-xsd-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5935 10.17487/RFC5935 RFC5936 DNS Zone Transfer Protocol (AXFR) E. Lewis A. Hoenes Editor June 2010 ASCII 66337 29 authoritative transfer AXFR mechanism

The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.

The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]

 draft-ietf-dnsext-axfr-clarify-14 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5936 RFC5937 Using Trust Anchor Constraints during Certification Path Processing S. Ashmore C. Wallace August 2010 ASCII 16900 8 TA

This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-wallace-using-ta-constraints-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5937 RFC5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) A. Morton M. Chiba August 2010 ASCII 37539 17

The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]

 draft-ietf-ippm-twamp-session-cntrl-07 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5938 10.17487/RFC5938 RFC5939 Session Description Protocol (SDP) Capability Negotiation F. Andreasen September 2010 ASCII 188116 77 multimedia session session announcement session invitation

The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.

The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.

The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-capability-negotiation-13 RFC6871 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5939 10.17487/RFC5939 RFC5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices S. Turner R. Housley August 2010 ASCII 15127 9 online certificate status protocol ocsp server-based certificate validation protocol scvp

The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]

 draft-turner-additional-cms-ri-choices-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5940 10.17487/RFC5940 RFC5941 Sharing Transaction Fraud Data D. M'Raihi S. Boeyen M. Grandcolas S. Bajaj August 2010 ASCII 49219 27 thraud incident object description exchange format iodef

This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mraihi-inch-thraud-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5941 RFC5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes H. Singh W. Beebee E. Nordmark July 2010 ASCII 27035 11

IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. [STANDARDS-TRACK]

 draft-ietf-6man-ipv6-subnet-model-12 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5942 RFC5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing B. Haberman Editor August 2010 ASCII 9016 4

The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). [STANDARDS-TRACK]

 draft-haberman-rpsl-reachable-test-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5943 RFC5944 IP Mobility Support for IPv4, Revised C. Perkins Editor November 2010 ASCII 239935 100 MOBILEIPSUPIP Internet Protocol MIPv4

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

 draft-ietf-mip4-rfc3344bis-10 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5944 10.17487/RFC5944 RFC5945 Resource Reservation Protocol (RSVP) Proxy Approaches F. Le Faucheur J. Manner D. Wing A. Guillou October 2010 ASCII 118234 50

The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tsvwg-rsvp-proxy-approaches-09 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5945 RFC5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy F. Le Faucheur J. Manner A. Narayanan A. Guillou H. Malik October 2010 ASCII 81414 35

Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-proxy-proto-11 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5946 RFC5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP) J. Elwell H. Kaplan September 2010 ASCII 29849 13 Trunking pbx private branch exchange

This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-martini-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai martini 10.17487/RFC5947 RFC5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16 S. Madanapalli S. Park S. Chakrabarti G. Montenegro August 2010 ASCII 26553 13 packet cs

IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer.

This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. [STANDARDS-TRACK]

 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5948 RFC5949 Fast Handovers for Proxy Mobile IPv6 H. Yokota K. Chowdhury R. Koodli B. Patil F. Xia September 2010 ASCII 72722 32 PFMIPv6 handoff PMIPv6 predictive reactive

Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.

When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. [STANDARDS-TRACK]

 draft-ietf-mipshop-pfmipv6-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5949 RFC5950 Network Management Framework for MPLS-based Transport Networks S. Mansfield Editor E. Gray Editor K. Lam Editor September 2010 ASCII 39502 18 mpls-tp network management framework

This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP).

This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.

The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.

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 document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-nm-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5950 RFC5951 Network Management Requirements for MPLS-based Transport Networks K. Lam S. Mansfield E. Gray September 2010 ASCII 49993 24 MPLS Transport Profile mpls-tp

This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-nm-req-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5951 10.17487/RFC5951 RFC5952 A Recommendation for IPv6 Address Text Representation S. Kawamura M. Kawashima August 2010 ASCII 26570 14 IPv6 text representation canonical

As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]

 draft-ietf-6man-text-addr-representation-07 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5952 10.17487/RFC5952 RFC5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker August 2010 ASCII 147393 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-dtls-tm-14 RFC6353 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5953 10.17487/RFC5953 RFC5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 V. Gurbani Editor B. Carpenter Editor B. Tate Editor August 2010 ASCII 13764 7 SIP session initiation protocol Augmented Backus-Naur Form Uniform Resource Identifier IPv6reference IPv6address

This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]

 draft-ietf-sip-ipv6-abnf-fix-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5954 10.17487/RFC5954 RFC5955 The application/timestamped-data Media Type A. Santoni August 2010 ASCII 4527 3 TimeStampedData envelopes

This document defines a new media type for TimeStampedData envelopes as described in RFC 5544. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-santoni-media-type-tsd-00 RFC5544 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5955 RFC5956 Forward Error Correction Grouping Semantics in the Session Description Protocol A. Begen September 2010 ASCII 29530 14 FEC loss repair grouping sdp media lines

This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]

 draft-ietf-mmusic-rfc4756bis-10 RFC4756 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5956 RFC5957 Display-Based Address Sorting for the IMAP4 SORT Extension D. Karp July 2010 ASCII 8709 5 Internet Message Access Protocol

This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. [STANDARDS-TRACK]

 draft-ietf-morg-sortdisplay-03 RFC5256 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC5957 RFC5958 Asymmetric Key Packages S. Turner August 2010 ASCII 26671 14 private key private-key information rsa laboratories private-key syntax change control

This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK]

 draft-turner-asymmetrickeyformat-05 RFC5208 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5958 10.17487/RFC5958 RFC5959 Algorithms for Asymmetric Key Package Content Type S. Turner August 2010 ASCII 13983 7 EncryptedPrivateKeyInfo AsymmetricKeyPackage

This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-asymmetrickeyformat-algs-01 RFC6162 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5959 RFC5960 MPLS Transport Profile Data Plane Architecture D. Frost Editor S. Bryant Editor M. Bocci Editor August 2010 ASCII 31764 15 mpls-tp transport profile itu-t dataplane gal gach

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-data-plane-04 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5960 10.17487/RFC5960 RFC5961 Improving TCP's Robustness to Blind In-Window Attacks A. Ramaiah R. Stewart M. Dalal August 2010 ASCII 44717 19 RST SYN FIN attack Data Injection vulnerability blind attacks BGP spoof mitigation

TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK]

 draft-ietf-tcpm-tcpsecure-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5961 10.17487/RFC5961 RFC5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) H. Schulzrinne V. Singh H. Tschofenig M. Thomson September 2010 ASCII 20109 11 PIDF-LO,location,dynamic,speed,velocity,orientation

The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. [STANDARDS TRACK]

 draft-singh-geopriv-pidf-lo-dynamic-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5962 RFC5963 IPv6 Deployment in Internet Exchange Points (IXPs) R. Gagliano August 2010 ASCII 22786 10 IPv6 IXP deployment exchange

This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6inixp-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5963 RFC5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries J. Winterbottom M. Thomson August 2010 ASCII 21269 11 hole polygon pidf-lo service boundary location LoST

This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described. [STANDARDS-TRACK]

 draft-ietf-ecrit-specifying-holes-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5964 RFC5965 An Extensible Format for Email Feedback Reports Y. Shafranovich J. Levine M. Kucherawy August 2010 ASCII 47452 25 feedback-report

This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]

 draft-ietf-marf-base-06 RFC6650 PROPOSED STANDARD PROPOSED STANDARD IETF app marf http://www.rfc-editor.org/errata_search.php?rfc=5965 10.17487/RFC5965 RFC5966 DNS Transport over TCP - Implementation Requirements R. Bellis August 2010 ASCII 14970 7 DNS TCP/IP

This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS-TRACK]

 draft-ietf-dnsext-dns-tcp-requirements-03 RFC7766 RFC1035 RFC1123 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5966 RFC5967 The application/pkcs10 Media Type S. Turner August 2010 ASCII 10928 6

This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-application-pkcs10-media-type-05 RFC2986 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5967 RFC5968 Guidelines for Extending the RTP Control Protocol (RTCP) J. Ott C. Perkins September 2010 ASCII 42541 17 real-time transport protocol

The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avt-rtcp-guidelines-04 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC5968 RFC5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification W. Townsley O. Troan August 2010 ASCII 45278 18 6rd Provider 6to4 IPv6 softwire IPv6 Transition 6to4

This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. [STANDARDS-TRACK]

 draft-ietf-softwire-ipv6-6rd-10 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=5969 10.17487/RFC5969 RFC5970 DHCPv6 Options for Network Boot T. Huth J. Freimann V. Zimmer D. Thaler September 2010 ASCII 22660 11 boot IPv6 DHCPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-opt-netboot-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5970 RFC5971 GIST: General Internet Signalling Transport H. Schulzrinne R. Hancock October 2010 ASCII 381127 154 nsis next steps in signaling

This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-ntlp-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5971 RFC5972 General Internet Signaling Transport (GIST) State Machine T. Tsenov H. Tschofenig X. Fu Editor C. Aoun E. Davies October 2010 ASCII 53461 27 draft-ietf-nsis-ntlp-statemachine-10 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5972 RFC5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) M. Stiemerling H. Tschofenig C. Aoun E. Davies October 2010 ASCII 219962 90 Next Steps in Signaling NSIS Path-coupled signaling Middlebox

This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-nslp-natfw-25 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5973 RFC5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling J. Manner G. Karagiannis A. McDonald October 2010 ASCII 233309 102 QoS

This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-qos-nslp-18 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5974 RFC5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP) G. Ash Editor A. Bader Editor C. Kappler Editor D. Oran Editor October 2010 ASCII 153418 64

The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-qspec-24 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5975 RFC5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes G. Ash A. Morton M. Dolly P. Tarapore C. Dvorak Y. El Mghazli October 2010 ASCII 42215 19 qos-nslp qos-nslp quality-of-service model qspec

This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-y1541-qosm-10 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5976 RFC5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv A. Bader L. Westberg G. Karagiannis C. Kappler T. Phelan October 2010 ASCII 324264 128 next steps in signaling resource managment in diffserv

This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-rmd-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5977 RFC5978 Using and Extending the NSIS Protocol Family J. Manner R. Bless J. Loughney E. Davies Editor October 2010 ASCII 75732 30 Signaling NTLP NSLP GIST QoS NSLP NAT/Firewall NSLP IP resources Extensibility

This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nsis-ext-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5978 RFC5979 NSIS Operation over IP Tunnels C. Shen H. Schulzrinne S. Lee J. Bang March 2011 ASCII 69850 27 nsis qos next steps in signaling

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-tunnel-13 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5979 RFC5980 NSIS Protocol Operation in Mobile Environments T. Sanda Editor X. Fu S. Jeong J. Manner H. Tschofenig March 2011 ASCII 77323 32

Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nsis-applicability-mobility-signaling-20 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5980 RFC5981 Authorization for NSIS Signaling Layer Protocols J. Manner M. Stiemerling H. Tschofenig R. Bless Editor February 2011 ASCII 82427 37 Next Steps in Signaling gist General Internet Signaling Transport

Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-nslp-auth-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=5981 10.17487/RFC5981 RFC5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement A. Kobayashi Editor B. Claise Editor August 2010 ASCII 56005 25 flow-based measurement

Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipfix-mediators-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5982 RFC5983 Mailing Lists and Internationalized Email Addresses R. Gellens October 2010 ASCII 24462 10

This document describes considerations for mailing lists with the introduction of internationalized email addresses.

This document makes some specific recommendations on how mailing lists should act in various situations. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-mailinglist-07 RFC6783 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5983 RFC5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding K-M. Moller April 1 2011 ASCII 18055 9 extra sensory perception

This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. This document defines an Experimental Protocol for the Internet community.

 draft-moller-esp-based-forwarding-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5984 RFC5985 HTTP-Enabled Location Delivery (HELD) M. Barnes Editor September 2010 ASCII 86914 39 layer 7 location configuration protocol l7 lcp

This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. [STANDARDS-TRACK]

 draft-ietf-geopriv-http-location-delivery-16 RFC7840 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5985 RFC5986 Discovering the Local Location Information Server (LIS) M. Thomson J. Winterbottom September 2010 ASCII 34450 16 u-naptr uri-enabled naptr

Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK]

 draft-ietf-geopriv-lis-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5986 10.17487/RFC5986 RFC5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters J. Reschke August 2010 ASCII 20108 10 HTTP header field parameter internationalization

By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. [STANDARDS-TRACK]

 draft-reschke-rfc2231-in-http-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5987 RFC5988 Web Linking M. Nottingham October 2010 ASCII 46834 23 Link linking http header link relation web

This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]

 draft-nottingham-http-link-header-10 RFC4287 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5988 10.17487/RFC5988 RFC5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource A.B. Roach October 2010 ASCII 40571 19 Link Relations Syndication Atom

The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP Event Framework, for doing so. [STANDARDS-TRACK]

 draft-roach-sip-http-subscribe-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5989 RFC5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS) J. Randall B. Kaliski J. Brainard S. Turner September 2010 ASCII 52579 27 key encapsulation mechanism generic hybrid cipher

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.

 draft-ietf-smime-cms-rsa-kem-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5990 10.17487/RFC5990 RFC5991 Teredo Security Updates D. Thaler S. Krishnan J. Hoagland September 2010 ASCII 20847 10 teredo ipv6 address

The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. [STANDARDS-TRACK]

 draft-krishnan-v6ops-teredo-update-10 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5991 RFC5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic S. Sharikov D. Miloshevic J. Klensin October 2010 ASCII 54378 21 Bosnian and Serbian Bulgarian Byelorussian Belarusian Belarusan Kildin Sami Macedonian Montenegrin Russian Ukrainian

This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sharikov-idn-reg-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5992 RFC5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) X. Duan S. Wang M. Westerlund K. Hellwig I. Johansson October 2010 ASCII 37824 18 speech codec real-time transport protocol

This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-gsm-hr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5993 RFC5994 Application of Ethernet Pseudowires to MPLS Transport Networks S. Bryant Editor M. Morrow G. Swallow R. Cherukuri T. Nadeau N. Harrison B. Niven-Jenkins October 2010 ASCII 24394 11 mpls-tp

Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.

Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.

This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pwe3-mpls-transport-04 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5994 10.17487/RFC5994 RFC5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections J. Reschke September 2010 ASCII 21591 12 HTTP POST WebDAV Collections Collection Members

The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".

This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.

This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. [STANDARDS-TRACK]

 draft-reschke-webdav-post-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5995 RFC5996 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen September 2010 ASCII 346466 138 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ikev2bis-11 RFC4306 RFC4718 RFC7296 RFC5998 RFC6989 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5996 10.17487/RFC5996 RFC5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol A. DeKok August 2010 ASCII 55464 24 status-server

This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-radext-status-server-09 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5997 10.17487/RFC5997 RFC5998 An Extension for EAP-Only Authentication in IKEv2 P. Eronen H. Tschofenig Y. Sheffer September 2010 ASCII 33477 16 mutual authentication password credentials AAA key agreement channel binding

IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.

This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]

 draft-ietf-ipsecme-eap-mutual-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5998 RFC6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) D. Papadimitriou M. Vigoureux K. Shiomoto D. Brungard JL. Le Roux October 2010 ASCII 52501 24

There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).

This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-mln-extensions-12 RFC4202 RFC4203 RFC4206 RFC4874 RFC4974 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6001 RFC6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions L. Berger D. Fedyk October 2010 ASCII 23090 10 Generalized Multi-Protocol Label Switching

This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 RFC3471 RFC3473 RFC3945 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6002 RFC6003 Ethernet Traffic Parameters D. Papadimitriou October 2010 ASCII 28232 14 mef Metro Ethernet Forum MEF10.1

This document describes the support of Metro Ethernet Forum (MEF) Ethernet traffic parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. [STANDARDS-TRACK]

 draft-ietf-ccamp-ethernet-traffic-parameters-10 RFC3471 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6003 10.17487/RFC6003 RFC6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching L. Berger D. Fedyk October 2010 ASCII 32319 15 Generalized Multi-Protocol Label Switching Metro Ethernet Forum MEF draft-ietf-ccamp-gmpls-ether-svcs-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6004 RFC6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) L. Berger D. Fedyk October 2010 ASCII 20301 10 mef itu International Telecommunication Union i-nni internal nni

This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. [STANDARDS- TRACK]

 draft-ietf-ccamp-gmpls-mef-uni-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6005 RFC6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Q. Zhao Editor D. King Editor F. Verhaeghe T. Takeda Z. Ali J. Meuric September 2010 ASCII 68107 33 END-POINTS fragmentation

Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.

This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. [STANDARDS-TRACK]

 draft-ietf-pce-pcep-p2mp-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=6006 10.17487/RFC6006 RFC6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations I. Nishioka D. King September 2010 ASCII 39156 18

A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.

This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-pcep-svec-list-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6007 RFC6008 Authentication-Results Registration for Differentiating among Cryptographic Results M. Kucherawy September 2010 ASCII 14328 7 DKIM DomainKeys SenderID SPF Authentication Reputation

This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. [STANDARDS-TRACK]

 draft-kucherawy-authres-header-b-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6008 RFC6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions N. Freed October 2010 ASCII 28979 15 SMTP ESMTP Sieve

This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions, respectively. The "redirect-dsn" and "redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. [STANDARDS-TRACK]

 draft-freed-sieve-notary-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=6009 10.17487/RFC6009 RFC6010 Cryptographic Message Syntax (CMS) Content Constraints Extension R. Housley S. Ashmore C. Wallace September 2010 ASCII 87495 38 authorization PKI certificate trust anchor TAMP,

This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. [STANDARDS-TRACK]

 draft-housley-cms-content-constraints-extn-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6010 10.17487/RFC6010 RFC6011 Session Initiation Protocol (SIP) User Agent Configuration S. Lawrence Editor J. Elwell October 2010 ASCII 66205 29 HTTP DHCP DHCPv6

This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-lawrence-sipforum-user-agent-config-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6011 10.17487/RFC6011 RFC6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog J. Salowey T. Petch R. Gerhards H. Feng October 2010 ASCII 24475 12 TLS

This document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. [STANDARDS-TRACK]

 draft-ietf-syslog-dtls-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC6012 RFC6013 TCP Cookie Transactions (TCPCT) W. Simpson January 2011 ASCII 76505 37

TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks. This document defines an Experimental Protocol for the Internet community.

 draft-simpson-tcpct-03 RFC7805 HISTORIC EXPERIMENTAL INDEPENDENT 10.17487/RFC6013 RFC6014 Cryptographic Algorithm Identifier Allocation for DNSSEC P. Hoffman November 2010 ASCII 11182 6 DNSSEC digital signatures algorithms

This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-alg-allocation-03 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6014 RFC6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) A. Begen October 2010 ASCII 65399 31 FEC interleaving loss repair loss protection DVB AL-FEC

This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB- IPTV) Application-layer FEC specification. [STANDARDS-TRACK]

 draft-ietf-fecframe-interleaved-fec-scheme-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6015 RFC6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs B. Davie F. Le Faucheur A. Narayanan October 2010 ASCII 95185 38 l3vpn

RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-l3vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6016 10.17487/RFC6016 RFC6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field K. Meadors Editor September 2010 ASCII 8683 5 EDIINT-Features

With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-meadors-ediint-features-header-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6017 RFC6018 IPv4 and IPv6 Greynets F. Baker W. Harrop G. Armitage September 2010 ASCII 21541 9 darknets

This note discusses a feature to support building Greynets for IPv4 and IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-baker-v6ops-greynet-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6018 RFC6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley September 2010 ASCII 11394 6 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]

 rfc4049bis RFC4049 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6019 RFC6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) M. Bjorklund Editor October 2010 ASCII 324178 173 NETCONF XML data modelling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]

 draft-ietf-netmod-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6020 10.17487/RFC6020 RFC6021 Common YANG Data Types J. Schoenwaelder Editor October 2010 ASCII 52826 26 YANG NETCONF

This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]

 draft-ietf-netmod-yang-types-09 RFC6991 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC6021 RFC6022 YANG Module for NETCONF Monitoring M. Scott M. Bjorklund October 2010 ASCII 46988 28 XML NETCONF YANG monitoring

This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema> operation to retrieve them. [STANDARDS-TRACK]

 draft-ietf-netconf-monitoring-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC6022 RFC6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) Y. Nir H. Tschofenig H. Deng R. Singh October 2010 ASCII 12560 7

This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA. This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

 draft-nir-ipsecme-childless-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6023 RFC6024 Trust Anchor Management Requirements R. Reddy C. Wallace October 2010 ASCII 33415 14 PKI certificates digital signatures

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-ta-mgmt-reqs-06 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6024 RFC6025 ASN.1 Translation C. Wallace C. Gardiner October 2010 ASCII 39221 19 Basic Encoding Rules Distinguished Encoding Rules PKIX S/MIME

Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-asn1-translation-03 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6025 RFC6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests R. Sparks T. Zourzouvillys September 2010 ASCII 44035 20 state machine retransmission

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]

 draft-ietf-sipcore-invfix-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6026 10.17487/RFC6026 RFC6027 IPsec Cluster Problem Statement Y. Nir October 2010 ASCII 27497 12 IKE IKEv2 high-availability load-sharing failover hot-standby

This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-ipsec-ha-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6027 RFC6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension G. Camarillo A. Keranen October 2010 ASCII 21571 10 source routing route recording overlay network

This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-via-03 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6028 RFC6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem I. Rimac V. Hilt M. Tomsu V. Gurbani E. Marocco October 2010 ASCII 48615 19 Peer-to-Peer topology estimation Internet coordinate system

A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-p2prg-alto-survey-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6029 10.17487/RFC6029 RFC6030 Portable Symmetric Key Container (PSKC) P. Hoyer M. Pei S. Machani October 2010 ASCII 123974 58 Symmetric Key provisioning AES 3DES TDES OTP Key transport format key provisioning format symmetric key protection symmetric key transport PIN transport PIN provisioning PIN Policy key usage policy

This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]

 draft-ietf-keyprov-pskc-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6030 10.17487/RFC6030 RFC6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type S. Turner R. Housley December 2010 ASCII 56129 29

This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]

 draft-ietf-keyprov-symmetrickeyformat-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6031 10.17487/RFC6031 RFC6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner R. Housley December 2010 ASCII 22725 11 CCC CMS content constraints

This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-encryptedkeypackagecontenttype-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6032 RFC6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner December 2010 ASCII 9818 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-encryptedkeypackagecontenttype-algs-02 RFC6161 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6033 RFC6034 Unicast-Prefix-Based IPv4 Multicast Addresses D. Thaler October 2010 ASCII 11140 5 internet protocol

This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]

 draft-ietf-mboned-ipv4-uni-based-mcast-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6034 RFC6035 Session Initiation Protocol Event Package for Voice Quality Reporting A. Pendleton A. Clark A. Johnston H. Sinnreich November 2010 ASCII 84930 41 sip Voice over Internet Protocol voip RTP Control Protocol Extended Reports RTCP-XR

This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]

 draft-ietf-sipping-rtcp-summary-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6035 10.17487/RFC6035 RFC6036 Emerging Service Provider Scenarios for IPv6 Deployment B. Carpenter S. Jiang October 2010 ASCII 45113 23 isp

This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-isp-scenarios-00 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6036 10.17487/RFC6036 RFC6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs E. Rosen Editor Y. Cai Editor IJ. Wijnands October 2010 ASCII 57136 25 mvpn

This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.

 draft-rosen-vpn-mcast-15 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6037 RFC6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features A. Morton L. Ciavattone October 2010 ASCII 41273 18 Testing Performance Metric

This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]

 draft-ietf-ippm-twamp-reflect-octets-09 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6038 10.17487/RFC6038 RFC6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols V. Manral M. Bhatia J. Jaeggli R. White October 2010 ASCII 50788 21

Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.

The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.

This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-routing-protocols-crypto-issues-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6039 RFC6040 Tunnelling of Explicit Congestion Notification B. Briscoe November 2010 ASCII 89412 35 Congestion Control and Management Congestion Notification Information Security Tunnelling Encapsulation Decapsulation Protocol ECN IPsec

This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]

 draft-ietf-tsvwg-ecn-tunnel-10 RFC3168 RFC4301 RFC4774 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6040 RFC6041 Forwarding and Control Element Separation (ForCES) Applicability Statement A. Crouch H. Khosravi A. Doria Editor X. Wang K. Ogawa October 2010 ASCII 28098 14 Routing Control Plane Management Protocol

The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-forces-applicability-09 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6041 RFC6042 Transport Layer Security (TLS) Authorization Using KeyNote A. Keromytis October 2010 ASCII 12097 7 trust management authorization access control certificates

This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-keromytis-tls-authz-keynote-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6042 RFC6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) J. Mattsson T. Tian March 2011 ASCII 139516 58 MIKEY MIKEY-TICKET KMS SRTP IMS key management ticket

The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mattsson-mikey-ticket-05 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6043 RFC6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) M. Mohali October 2010 ASCII 54486 24

Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.

This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.

Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mohali-diversion-history-info-07 RFC7544 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6044 10.17487/RFC6044 RFC6045 Real-time Inter-network Defense (RID) K. Moriarty November 2010 ASCII 172817 75 Coordinated Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.

RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-moriarty-post-inch-rid-12 RFC6545 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6045 10.17487/RFC6045 RFC6046 Transport of Real-time Inter-network Defense (RID) Messages K. Moriarty B. Trammell November 2010 ASCII 14760 7 Coordinate Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-moriarty-post-inch-rid-transport-03 RFC6546 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6046 RFC6047 iCalendar Message-Based Interoperability Protocol (iMIP) A. Melnikov Editor December 2010 ASCII 40697 22 IMIP] electronic mail transport itip iCalendar Transport-independent Interoperability Protocol iCalendar Object Model

This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]

 draft-ietf-calsify-rfc2447bis-11 RFC2447 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify 10.17487/RFC6047 RFC6048 Network News Transfer Protocol (NNTP) Additions to LIST Command J. Elie November 2010 ASCII 50873 25 Usenet NetNews capabilities

This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.

This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST COUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. [STANDARDS-TRACK]

 draft-elie-nntp-list-additions-05 RFC2980 RFC3977 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6048 RFC6049 Spatial Composition of Metrics A. Morton E. Stephan January 2011 ASCII 57486 29 Performance Measurement IPPM

This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]

 draft-ietf-ippm-spatial-composition-16 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6049 RFC6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services K. Drage November 2010 ASCII 41021 19 SIP trust domain service identifier

This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.

The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-drage-sipping-service-identification-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6050 RFC6051 Rapid Synchronisation of RTP Flows C. Perkins T. Schierl November 2010 ASCII 53503 22 rtcp rtp control protocol mcu multipoint conference units ssm source-specific multicast

This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.

This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK]

 draft-ietf-avt-rapid-rtp-sync-12 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6051 RFC6052 IPv6 Addressing of IPv4/IPv6 Translators C. Bao C. Huitema M. Bagnulo M. Boucadair X. Li October 2010 ASCII 41849 18 address prefix transition translation NAT NAT64 BEHAVE stateless stateful

This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]

 draft-ietf-behave-address-format-10 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6052 RFC6053 Implementation Report for Forwarding and Control Element Separation (ForCES) E. Haleplidis K. Ogawa W. Wang J. Hadi Salim November 2010 ASCII 72337 34 Stream Control Transmission Protocol-based Transport Mapping Layer SCTP TML forces Model

Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.

This document is an implementation report for the ForCES Protocol, Model, and the Stream Control Transmission Protocol-based Transport Mapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-forces-implementation-report-02 RFC6984 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6053 RFC6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic D. McGrew B. Weis November 2010 ASCII 22672 10

Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]

 draft-ietf-msec-ipsec-group-counter-modes-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC6054 RFC6055 IAB Thoughts on Encodings for Internationalized Domain Names D. Thaler J. Klensin S. Cheshire February 2011 ASCII 58799 24 Unicode UTF-8,

This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.

 draft-iab-idn-encoding-04 RFC2130 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6055 10.17487/RFC6055 RFC6056 Recommendations for Transport-Protocol Port Randomization M. Larsen F. Gont January 2011 ASCII 63913 29 tcp transmission control protocl blind attacks

During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.

 draft-ietf-tsvwg-port-randomization-09 BCP0156 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6056 10.17487/RFC6056 RFC6057 Comcast's Protocol-Agnostic Congestion Management System C. Bastian T. Klieber J. Livingood J. Mills R. Woundy December 2010 ASCII 74685 29 ISP Internet Service Provider Network Management

This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-livingood-woundy-congestion-mgmt-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6057 RFC6058 Transient Binding for Proxy Mobile IPv6 M. Liebsch Editor A. Muhanna O. Blume March 2011 ASCII 90201 35 PMIP handover optimization handover delay tBCE late path switch forwarding make-before-break dual radio handover single radio handover transient binding cache entry

This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mipshop-transient-bce-pmipv6-07 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC6058 RFC6059 Simple Procedures for Detecting Network Attachment in IPv6 S. Krishnan G. Daley November 2010 ASCII 40655 19 DNA DNAv6 ND IPv6 neighbor discovery neighbor discovery send secure neighbor discovery DHCPv6 stateless autoconfiguration change detection movement detection DNAv4 link detection mobility

Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]

 draft-ietf-dna-simple-17 PROPOSED STANDARD PROPOSED STANDARD IETF int dna 10.17487/RFC6059 RFC6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) D. Fedyk H. Shah N. Bitar A. Takacs March 2011 ASCII 45600 20 IEEE data plane

This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-ethernet-pbb-te-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6060 RFC6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA) B. Rosen January 2011 ASCII 14145 7

This document describes the Namespace Identifier (NID) "nena" for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA Registry System (NRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-rosen-urn-nena-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6061 RFC6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations S. Perreault Editor J. Rosenberg November 2010 ASCII 28978 13 NAT TURN STUN

This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]

 draft-ietf-behave-turn-tcp-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6062 10.17487/RFC6062 RFC6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP) A. Doherty M. Pei S. Machani M. Nystrom December 2010 ASCII 233675 105 Cryptographic module Cryptographic Token key initialization credentials online provisioning

The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.

Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module. [STANDARDS-TRACK]

 draft-ietf-keyprov-dskpp-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6063 10.17487/RFC6063 RFC6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service M. Westerlund P. Frojdh January 2011 ASCII 44810 22 3GPP PSS MBMS SDP RTSP IANA

The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-westerlund-mmusic-3gpp-sdp-rtsp-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6064 RFC6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings K. Narayan D. Nelson R. Presuhn Editor December 2010 ASCII 39695 19 Network Management Security Management Information Base MIB SMIv2 RADIUS AAA VACM

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]

 draft-ietf-isms-radius-vacm-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC6065 RFC6066 Transport Layer Security (TLS) Extensions: Extension Definitions D. Eastlake 3rd January 2011 ASCII 55079 25 server_name max_fragment_length client_certificate_url trusted_ca_keys truncated_hmac status_request

This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]

 draft-ietf-tls-rfc4366-bis-12 RFC4366 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6066 10.17487/RFC6066 RFC6067 BCP 47 Extension U M. Davis A. Phillips Y. Umaoka December 2010 ASCII 17012 8 locale bcp 47

This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-davis-u-langtag-ext-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6067 10.17487/RFC6067 RFC6068 The 'mailto' URI Scheme M. Duerst L. Masinter J. Zawinski October 2010 ASCII 36683 17 mailto email address URI scheme IRI

This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]

 draft-duerst-mailto-bis-10 RFC2368 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6068 10.17487/RFC6068 RFC6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) A. Zimmermann A. Hannemann December 2010 ASCII 59600 23 Internet Control Message Protocol (ICMP) Retranmission Timeout (RTO)

Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.

This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-tcp-lcd-03 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6069 RFC6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors S. Josefsson January 2011 ASCII 7334 5

This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-josefsson-pbkdf2-test-vectors-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6070 RFC6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap S. Frankel S. Krishnan February 2011 ASCII 148655 63 internet protocol privacy authentication

Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.

This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap."

The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-roadmap-10 RFC2411 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6071 RFC6072 Certificate Management Service for the Session Initiation Protocol (SIP) C. Jennings J. Fischl Editor February 2011 ASCII 69071 30 credential service aor address of record

This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]

 draft-ietf-sip-certs-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=6072 10.17487/RFC6072 RFC6073 Segmented Pseudowire L. Martini C. Metz T. Nadeau M. Bocci M. Aissaoui January 2011 ASCII 102428 43 pws psn packet switched network pw control plane domain

This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]

 draft-ietf-pwe3-segmented-pw-18 RFC6723 RFC7267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6073 RFC6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) E. Rosen B. Davie V. Radoaca W. Luo January 2011 ASCII 76543 32

Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]

 draft-ietf-l2vpn-signaling-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6074 RFC6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry D. Cridland December 2010 ASCII 13088 7 annotate metadata

The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. [STANDARDS-TRACK]

 draft-cridland-acap-vendor-registry-02 RFC2244 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6075 RFC6076 Basic Telephony SIP End-to-End Performance Metrics D. Malas A. Morton January 2011 ASCII 61559 27 Benchmarking Lab Test Time Measurement Service Session Protocol

This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. [STANDARDS-TRACK]

 draft-ietf-pmol-sip-perf-metrics-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops pmol 10.17487/RFC6076 RFC6077 Open Research Issues in Internet Congestion Control D. Papadimitriou Editor M. Welzl M. Scharf B. Briscoe February 2011 ASCII 130169 51 Signalling Performance Robustness Fairness Stability Misbehaviour Architecture

This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-iccrg-welzl-congestion-control-open-research-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6077 RFC6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) G. Camarillo J. Melen January 2011 ASCII 41482 17 HIP DATA

This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-hiccups-05 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6078 RFC6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) G. Camarillo P. Nikander J. Hautakorpi A. Keranen A. Johnston January 2011 ASCII 51013 21

This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols". This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-bone-07 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6079 RFC6080 A Framework for Session Initiation Protocol User Agent Profile Delivery D. Petrie S. Channabasappa Editor March 2011 ASCII 126917 54 SIP Configuration Framework User Agent profile

This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. [STANDARDS-TRACK]

 draft-ietf-sipping-config-framework-18 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6080 RFC6081 Teredo Extensions D. Thaler January 2011 ASCII 143419 59 IPv6 NAT traversal transition translation translator

This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. [STANDARDS-TRACK]

 draft-thaler-v6ops-teredo-extensions-08 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6081 10.17487/RFC6081 RFC6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic K. Whistler G. Adams M. Duerst R. Presuhn Editor J. Klensin November 2010 ASCII 6633 4 characters strings ASCII

RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-presuhn-rfc2482-historic-02 RFC2482 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6082 RFC6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) M. Tuexen R. Seggelmann E. Rescorla January 2011 ASCII 16674 9

This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).

DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.

Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]

 draft-ietf-tsvwg-dtls-for-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6083 RFC6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) X. Fu C. Dickmann J. Crowcroft January 2011 ASCII 27040 12 Multihoming Signaling Partial Reliability

The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-ntlp-sctp-15 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC6084 RFC6085 Address Mapping of IPv6 Multicast Packets on Ethernet S. Gundavelli M. Townsley O. Troan W. Dec January 2011 ASCII 4968 3

When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK]

 draft-gundavelli-v6ops-l2-unicast-06 RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6085 RFC6086 Session Initiation Protocol (SIP) INFO Method and Package Framework C. Holmberg E. Burger H. Kaplan January 2011 ASCII 75949 36 Info Package Info-Package Recv-Info

This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. [STANDARDS-TRACK]

 draft-ietf-sipcore-info-events-10 RFC2976 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6086 10.17487/RFC6086 RFC6087 Guidelines for Authors and Reviewers of YANG Data Model Documents A. Bierman January 2011 ASCII 49969 26 NETMOD NETCONF XML YANG

This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netmod-yang-usage-11 INFORMATIONAL INFORMATIONAL IETF ops netmod 10.17487/RFC6087 RFC6088 Traffic Selectors for Flow Bindings G. Tsirtsis G. Giarreta H. Soliman N. Montavont January 2011 ASCII 28040 13 Mobile IPv6 Binary Traffic Selectors

This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK]

 draft-ietf-mext-binary-ts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6088 RFC6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support G. Tsirtsis H. Soliman N. Montavont G. Giaretta K. Kuladinithi January 2011 ASCII 69353 31 Flow Identification Flow Summary Binding Reference Traffic Selector Flow Binding Entry

This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. [STANDARDS- TRACK]

 draft-ietf-mext-flow-binding-11 RFC5648 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6089 RFC6090 Fundamental Elliptic Curve Cryptography Algorithms D. McGrew K. Igoe M. Salter February 2011 ASCII 75993 34 ECC

This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mcgrew-fundamental-ecc-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6090 10.17487/RFC6090 RFC6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos D. Gillmor February 2011 ASCII 18529 9 Certificate type negotiation tls handshake protocol handshake

This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mavrogiannopoulos-rfc5081bis-09 RFC5081 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6091 RFC6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service J. Woodyatt Editor January 2011 ASCII 91729 36 cpe firewall filter

This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-cpe-simple-security-16 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6092 RFC6093 On the Implementation of the TCP Urgent Mechanism F. Gont A. Yourtchenko January 2011 ASCII 25921 12 Transmission Control Protocol

This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK]

 draft-ietf-tcpm-urgent-data-07 RFC0793 RFC1011 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=6093 10.17487/RFC6093 RFC6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols M. Bhatia V. Manral February 2011 ASCII 24583 11 IGP security

The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.

To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.

Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.

This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-igp-crypto-requirements-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6094 RFC6095 Extending YANG with Language Abstractions B. Linowski M. Ersue S. Kuryla March 2011 ASCII 140259 75 YANG model complex-type Complex Types Typed Instance Resource Model Inheritance class

YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. This document defines an Experimental Protocol for the Internet community.

 draft-linowski-netmod-yang-abstract-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6095 RFC6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration M. Tuexen R. Stewart January 2011 ASCII 15368 8

This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-chunk-flags-02 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6096 RFC6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 J. Korhonen V. Devarapalli February 2011 ASCII 21682 10 PMIPv6 3GPP DNS AAA

Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netlmm-lma-discovery-08 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC6097 RFC6098 Generic Notification Message for Mobile IPv4 H. Deng H. Levkowetz V. Devarapalli S. Gundavelli B. Haley April 2012 ASCII 76848 33 mipv4

This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose. [STANDARDS-TRACK]

 draft-ietf-mip4-generic-notification-message-16 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6098 RFC6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 A. Freier P. Karlton P. Kocher August 2011 ASCII 142297 67 Transport layer security

This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.

This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community.

 draft-mavrogiannopoulos-ssl-version3-06 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6101 RFC6104 Rogue IPv6 Router Advertisement Problem Statement T. Chown S. Venaas February 2011 ASCII 36518 16 RA rogue ra

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-rogue-ra-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6104 RFC6105 IPv6 Router Advertisement Guard E. Levy-Abegnoli G. Van de Velde C. Popoviciu J. Mohacsi February 2011 ASCII 20817 10 SEcure Neighbor Discovery Stateless Address Autoconfiguration

Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-ra-guard-08 RFC7113 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6105 RFC6106 IPv6 Router Advertisement Options for DNS Configuration J. Jeong S. Park L. Beloeil S. Madanapalli November 2010 ASCII 45181 19 DNS Service DNS Option Recursive DNS Server Address DNS Search List Stateless Autoconfiguration

This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. [STANDARDS-TRACK]

 draft-ietf-6man-dns-options-bis-08 RFC5006 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6106 10.17487/RFC6106 RFC6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths K. Shiomoto Editor A. Farrel Editor February 2011 ASCII 65363 30 TE links Bundled links GMPLS dynamically provisioned networks

Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.

Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]

 draft-ietf-ccamp-lsp-hierarchy-bis-08 RFC3477 RFC4206 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6107 10.17487/RFC6107 RFC6108 Comcast's Web Notification System Design C. Chung A. Kasyanov J. Livingood N. Mody B. Van Lieu February 2011 ASCII 55329 24 ISP Internet Service Provider bot remediation bot notification

The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-livingood-web-notification-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6108 RFC6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail C. Petrucci F. Gennai A. Shahin A. Vinciarelli April 2011 ASCII 135569 65 PEC Registered mail Return receipt Digitally signed email Digitally signed notification MIME SMIME

Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing.

The design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National Research Council (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-gennai-smime-cnipa-pec-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6109 10.17487/RFC6109 RFC6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content L. Lhotka Editor February 2011 ASCII 192547 100 DSDL validation RELAX NG Schematron DSRL

This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc. Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]

 draft-ietf-netmod-dsdl-map-10 RFC7952 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6110 10.17487/RFC6110 RFC6111 Additional Kerberos Naming Constraints L. Zhu April 2011 ASCII 14113 6 principal names realm names

This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK]

 draft-ietf-krb-wg-naming-07 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6111 RFC6112 Anonymity Support for Kerberos L. Zhu P. Leach S. Hartman April 2011 ASCII 37858 16 kerberos realm

This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. [STANDARDS-TRACK]

 draft-ietf-krb-wg-anon-12 RFC4120 RFC4121 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6112 10.17487/RFC6112 RFC6113 A Generalized Framework for Kerberos Pre-Authentication S. Hartman L. Zhu April 2011 ASCII 121122 48

Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal.

This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.

This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK]

 draft-ietf-krb-wg-preauth-framework-17 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6113 RFC6114 The 128-Bit Blockcipher CLEFIA M. Katagi S. Moriai March 2011 ASCII 68618 33 security lightweight cryptography encryption algorithm

This document describes the specification of the blockcipher CLEFIA. CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and 256 bits, which is compatible with the interface of the Advanced Encryption Standard (AES). The algorithm of CLEFIA was published in 2007, and its security has been scrutinized in the public community. CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES. Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware. CLEFIA will be of benefit to the Internet, which will be connected to more distributed and constrained devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-katagi-clefia-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6114 RFC6115 Recommendation for a Routing Architecture T. Li Editor February 2011 ASCII 178526 73

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-rrg-recommendation-16 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6115 RFC6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) S. Bradner L. Conroy K. Fujiwara March 2011 ASCII 52840 22 DNS E.164 NAPTR dynamic delegation discovery system e164.arpa

This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-3761bis-09 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6116 RFC6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations B. Hoeneisen A. Mayrhofer J. Livingood March 2011 ASCII 83838 40 domain name system

This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. [STANDARDS-TRACK]

 draft-ietf-enum-enumservices-guide-22 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6117 RFC6118 Update of Legacy IANA Registrations of Enumservices B. Hoeneisen A. Mayrhofer March 2011 ASCII 115372 68 domain name system

This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-enumservices-transition-06 RFC3762 RFC3764 RFC3953 RFC4143 RFC4002 RFC4238 RFC4355 RFC4415 RFC4769 RFC4969 RFC4979 RFC5028 RFC5278 RFC5333 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6118 RFC6119 IPv6 Traffic Engineering in IS-IS J. Harrison J. Berger M. Bartlett February 2011 ASCII 21146 10

This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]

 draft-ietf-isis-ipv6-te-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6119 RFC6120 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre March 2011 ASCII 451942 211 XMPP Extensible Messaging and Presence Protocol Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]

 draft-ietf-xmpp-3920bis-22 RFC3920 RFC7590 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6120 10.17487/RFC6120 RFC6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre March 2011 ASCII 244800 114 XMPP Extensible Messaging and Presence Protocol Jabber IM Instant Messaging Presence XML Extensible Markup Language

This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]

 draft-ietf-xmpp-3921bis-20 RFC3921 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6121 10.17487/RFC6121 RFC6122 Extensible Messaging and Presence Protocol (XMPP): Address Format P. Saint-Andre March 2011 ASCII 50646 23 XMPP Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. [STANDARDS-TRACK]

 draft-ietf-xmpp-address-09 RFC7622 RFC3920 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6122 10.17487/RFC6122 RFC6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts A. Farrel February 2011 ASCII 28277 13

It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.

Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community.

 draft-ietf-pce-manageability-requirements-11 HISTORIC HISTORIC IETF rtg pce 10.17487/RFC6123 RFC6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol Y. Sheffer G. Zorn H. Tschofenig S. Fluhrer February 2011 ASCII 71706 33 password-based authentication mutual authentication password-based cryptography password authenticated key exchange weak password authentication

The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sheffer-emu-eap-eke-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6124 RFC6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) P. Saint-Andre J. Hodges March 2011 ASCII 136507 57

Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]

 draft-saintandre-tls-server-id-check-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6125 10.17487/RFC6125 RFC6126 The Babel Routing Protocol J. Chroboczek April 2011 ASCII 99833 45

Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document defines an Experimental Protocol for the Internet community.

 draft-chroboczek-babel-routing-protocol-05 RFC7298 RFC7557 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6126 10.17487/RFC6126 RFC6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios J. Arkko M. Townsley May 2011 ASCII 48227 20 address depletion translation NAT-PT dual-stack Softwire Behave NAT NAT444

When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.

This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-arkko-townsley-coexistence-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6127 RFC6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions A. Begen February 2011 ASCII 11544 6

The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-port-for-ssm-04 RFC5760 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6128 RFC6129 The 'application/tei+xml' Media Type L. Romary S. Lundberg February 2011 ASCII 14214 8 Text Encoding Initiative xml text encoding text representation MIME type

This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding and Interchange guidelines. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-lundberg-app-tei-xml-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6129 10.17487/RFC6129 RFC6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) T. Clausen C. Dearlove J. Dean April 2011 ASCII 190678 88 MANET OLSRv2 packetbb Routing Protocol NHDP ad hoc network bi-directional 2-hop discovery Wireless SMF

This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK]

 draft-ietf-manet-nhdp-15 RFC7183 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6130 10.17487/RFC6130 RFC6131 Sieve Vacation Extension: "Seconds" Parameter R. George B. Leiba July 2011 ASCII 9407 5 email filters auto-replies

This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. [STANDARDS-TRACK]

 draft-ietf-sieve-vacation-seconds-03 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6131 RFC6132 Sieve Notification Using Presence Information R. George B. Leiba July 2011 ASCII 17677 8 email filters context status

This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify_method_capability feature. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-presence-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6132 RFC6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality R. George B. Leiba A. Melnikov July 2011 ASCII 17652 9

This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sieve-autoreply-04 INFORMATIONAL INFORMATIONAL IETF app sieve 10.17487/RFC6133 RFC6134 Sieve Extension: Externally Stored Lists A. Melnikov B. Leiba July 2011 ASCII 37379 18

The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.

This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK]

 draft-ietf-sieve-external-lists-10 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6134 RFC6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau February 2011 ASCII 17262 8 comedia comedia-tls relay SBC

This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK]

 draft-ietf-simple-msrp-acm-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6135 RFC6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework A. Sajassi Editor D. Mohan Editor March 2011 ASCII 92170 42

This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS). Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l2vpn-oam-req-frmk-11 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6136 RFC6137 The Network Trouble Ticket Data Model (NTTDM) D. Zisiadis Editor S. Kopsidas Editor M. Tsavli Editor G. Cessieux Editor February 2011 ASCII 83462 46 Grid Management EGEE

Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent, and disseminate TT information in different formats.

As a result, management of the daily workload by a central Network Operation Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE (Enabling Grids for E-sciencE) project. This document defines an Experimental Protocol for the Internet community.

 draft-dzis-nwg-nttdm-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6137 10.17487/RFC6137 RFC6138 LDP IGP Synchronization for Broadcast Networks S. Kini Editor W. Lu Editor February 2011 ASCII 20161 9

RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol message changes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-ldp-igp-sync-bcast-06 RFC5443 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6138 RFC6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios S. Russert Editor E. Fleischman Editor F. Templin Editor February 2011 ASCII 101101 39 Encapsulation Tunnel Architecture Scalability Mobility MANET Security IPv6 Aerospace IRON VET SEAL ISATAP

"Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-russert-rangers-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6139 RFC6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) A.B. Roach March 2011 ASCII 79372 35 Bulk Registration Implicit Registration GIN PBX SSP SIP-PBX

This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique. This document therefore focuses on this use case. [STANDARDS-TRACK]

 draft-ietf-martini-gin-13 RFC3680 PROPOSED STANDARD PROPOSED STANDARD IETF rai martini http://www.rfc-editor.org/errata_search.php?rfc=6140 10.17487/RFC6140 RFC6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) G. Camarillo Editor C. Holmberg Y. Gao March 2011 ASCII 57517 26 re-INVITE offer/answer rollback

The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. [STANDARDS-TRACK]

 draft-ietf-sipcore-reinvite-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6141 RFC6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP A. Moise J. Brodkin March 2011 ASCII 58320 26 Advanced Metering Infrastructure ami application layer message

This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network.

This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-c1222-transport-over-ip-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6142 RFC6143 The Remote Framebuffer Protocol T. Richardson J. Levine March 2011 ASCII 91737 39 vnc rfb remote framebuffer remote GUI

RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-levine-rfb-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6143 10.17487/RFC6143 RFC6144 Framework for IPv4/IPv6 Translation F. Baker X. Li C. Bao K. Yin April 2011 ASCII 67181 31 stateless translation stateful translation

This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-behave-v6v4-framework-10 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6144 RFC6145 IP/ICMP Translation Algorithm X. Li C. Bao F. Baker April 2011 ASCII 76484 33 SIIT] internet protocol control message IPv4 IPv6 Stateless IP/ICMP Translation Algorithm,

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765. [STANDARDS-TRACK]

 draft-ietf-behave-v6v4-xlate-23 RFC2765 RFC7915 RFC6791 RFC7757 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6145 10.17487/RFC6145 RFC6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers M. Bagnulo P. Matthews I. van Beijnum April 2011 ASCII 107954 45 NAT64 IPv6 draft-ietf-behave-v6v4-xlate-stateful-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6146 10.17487/RFC6146 RFC6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers M. Bagnulo A. Sullivan P. Matthews I. van Beijnum April 2011 ASCII 75103 32 AAAA

DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]

 draft-ietf-behave-dns64-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6147 10.17487/RFC6147 RFC6148 DHCPv4 Lease Query by Relay Agent Remote ID P. Kurapati R. Desetti B. Joshi February 2011 ASCII 26185 13 dynamic host configuration protocol

Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost. The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients. In certain scenarios, this model is not scalable. This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. [STANDARDS-TRACK]

 draft-ietf-dhc-leasequery-by-remote-id-09 RFC4388 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6148 RFC6149 MD2 to Historic Status S. Turner L. Chen March 2011 ASCII 14158 7 security encryption signature

This document retires MD2 and discusses the reasons for doing so. This document moves RFC 1319 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-md2-to-historic-10 RFC1319 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6149 10.17487/RFC6149 RFC6150 MD4 to Historic Status S. Turner L. Chen March 2011 ASCII 19583 10 MD4 security encryption signature

This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-md4-to-historic-11 RFC1320 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6150 10.17487/RFC6150 RFC6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms S. Turner L. Chen March 2011 ASCII 14662 7 signature eneryption ipsec Message Digest encryption

This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-md5-seccon-update-08 RFC1321 RFC2104 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6151 RFC6152 SMTP Service Extension for 8-bit MIME Transport J. Klensin N. Freed M. Rose D. Crocker Editor March 2011 ASCII 13034 7 simple mail transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

 draft-ietf-yam-rfc1652bis-03 RFC1652 STD0071 INTERNET STANDARD INTERNET STANDARD IETF app yam 10.17487/RFC6152 RFC6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery S. Das G. Bajko February 2011 ASCII 13420 7 Dynamic Host Configuration Protocol

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in the Third Generation Partnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes (MNs). [STANDARDS-TRACK]

 draft-das-mipshop-andsf-dhcp-options-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6153 RFC6154 IMAP LIST Extension for Special-Use Mailboxes B. Leiba J. Nicolson March 2011 ASCII 25544 12 IMAP email

Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK]

 draft-ietf-morg-list-specialuse-06 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=6154 10.17487/RFC6154 RFC6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) J. Winterbottom M. Thomson H. Tschofenig R. Barnes March 2011 ASCII 58542 27

When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.

Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.

This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. [STANDARDS-TRACK]

 draft-ietf-geopriv-held-identity-extensions-06 RFC6915 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6155 RFC6156 Traversal Using Relays around NAT (TURN) Extension for IPv6 G. Camarillo O. Novo S. Perreault Editor April 2011 ASCII 27758 14 STUN TURN IPv6

This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). [STANDARDS-TRACK]

 draft-ietf-behave-turn-ipv6-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6156 RFC6157 IPv6 Transition in the Session Initiation Protocol (SIP) G. Camarillo K. El Malki V. Gurbani April 2011 ASCII 32492 15

This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered. [STANDARDS-TRACK]

 draft-ietf-sipping-v6-transition-07 RFC3264 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6157 10.17487/RFC6157 RFC6158 RADIUS Design Guidelines A. DeKok Editor G. Weber March 2011 ASCII 89319 38

This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice.

 draft-ietf-radext-design-19 RFC6929 BCP0158 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops radext 10.17487/RFC6158 RFC6159 Session-Specific Explicit Diameter Request Routing T. Tsou G. Zorn T. Taylor Editor April 2011 ASCII 45051 19 Diameter routing

This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-tsou-diameter-explicit-routing-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6159 RFC6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types S. Turner April 2011 ASCII 10115 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-cms-symmetrickeypackage-algs-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6160 RFC6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner April 2011 ASCII 5504 3 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes the conventions for using several Elliptic Curve cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 6033. [STANDARDS-TRACK]

 draft-turner-ekpct-algs-update-03 RFC6033 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6161 RFC6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type S. Turner April 2011 ASCII 6155 4 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 5959. [STANDARDS-TRACK]

 draft-turner-akf-algs-update-03 RFC5959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6162 RFC6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) Y. Lee Editor G. Bernstein Editor W. Imajuku April 2011 ASCII 115511 51 Generalized Multi-Protocol Label Switching Routing and Wavelength Assignment RWA

This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths.

This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-rwa-wson-framework-12 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6163 RFC6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links M. Kohno B. Nitzan R. Bush Y. Matsuzaki L. Colitti T. Narten April 2011 ASCII 16057 8 addressing prefix length security

On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. [STANDARDS-TRACK]

 draft-ietf-6man-prefixlen-p2p-01 RFC6547 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6164 10.17487/RFC6164 RFC6165 Extensions to IS-IS for Layer-2 Systems A. Banerjee D. Ward April 2011 ASCII 12266 7 Intermediate System to Intermediate System

This document specifies the Intermediate System to Intermediate System (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. Furthermore, the Type, Length, Value pairs (TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. [STANDARDS- TRACK]

 draft-ietf-isis-layer2-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6165 RFC6166 A Registry for PIM Message Types S. Venaas April 2011 ASCII 7441 4 IANA Protocol Independent Multicast

This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types.

In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]

 draft-ietf-pim-registry-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6166 RFC6167 URI Scheme for Java(tm) Message Service 1.0 M. Phillips P. Adams D. Rokicki E. Johnson April 2011 ASCII 44285 22 SOAP JMS JNDI IRI

This document defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS). It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMS URI is not compatible with previously existing, but unregistered, "jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-merrick-jms-uri-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6167 10.17487/RFC6167 RFC6168 Requirements for Management of Name Servers for the DNS W. Hardaker May 2011 ASCII 36679 17 DNS Domain Name System Management

Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.

This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-name-server-management-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6168 RFC6169 Security Concerns with IP Tunneling S. Krishnan D. Thaler J. Hoagland April 2011 ASCII 45018 20

A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]

 draft-ietf-v6ops-tunnel-security-concerns-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6169 RFC6170 Internet X.509 Public Key Infrastructure -- Certificate Image S. Santesson R. Housley S. Bajaj L. Rosenthol May 2011 ASCII 25240 12 otherLogos

This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]

 draft-ietf-pkix-certimage-11 RFC3709 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6170 RFC6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control K. Zeilenga March 2011 ASCII 11124 6 x.511 dontusecopy

This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]

 draft-zeilenga-ldap-dontusecopy-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6171 RFC6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode D. Black D. Peterson March 2011 ASCII 11625 6 FCIP

Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.

iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.

This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]

 draft-ietf-storm-ifcp-ipn133-updates-03 RFC4172 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6172 RFC6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) P. Venkatesen Editor March 2011 ASCII 63695 31 Management Information Base mib IFCP-MGMT-MIB

This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.

This document obsoletes RFC 4369. [STANDARDS-TRACK]

 draft-ietf-storm-ifcpmib-07 RFC4369 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6173 RFC6174 Definition of IETF Working Group Document States E. Juskevicius March 2011 ASCII 56883 25 WG I-D States I-D Availability States

The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.

This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and their Delegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-proto-wgdocument-states-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6174 RFC6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors E. Juskevicius March 2011 ASCII 55481 23 WG Document States I-D States

This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-juskevicius-datatracker-wgdocstate-reqts-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6175 RFC6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0 S. Turner T. Polk March 2011 ASCII 7642 4

This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]

 draft-ietf-tls-ssl2-must-not-04 RFC2246 RFC4346 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC6176 RFC6177 IPv6 Address Assignment to End Sites T. Narten G. Huston L. Roberts March 2011 ASCII 21231 9 internet architecture board engineering steering group protocol

RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.

This document obsoletes RFC 3177. [STANDARDS-TRACK]

 draft-ietf-v6ops-3177bis-end-sites-01 RFC3177 BCP0157 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC6177 RFC6178 Label Edge Router Forwarding of IPv4 Option Packets D. Smith J. Mullooly W. Jaeger T. Scholl March 2011 ASCII 21645 9 FEC MPLS LER Security DoS

This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]

 draft-ietf-mpls-ip-options-07 RFC3031 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6178 RFC6179 The Internet Routing Overlay Network (IRON) F. Templin Editor March 2011 ASCII 92638 37 Encapsulation Tunnel Architecture Scalability Mobility MANET Security Recursion Addressing Routing IPv6 Aerospace Aeronautics Space IRON RANGER VET SEAL ISATAP

Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-templin-iron-17 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6179 RFC6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment J. Arkko F. Baker May 2011 ASCII 49679 20

The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-arkko-ipv6-transition-guidelines-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6180 RFC6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses M. Bagnulo March 2011 ASCII 44251 17 Multipath TCP threats security MPTCP

Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mptcp-threat-08 INFORMATIONAL INFORMATIONAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=6181 10.17487/RFC6181 RFC6182 Architectural Guidelines for Multipath TCP Development A. Ford C. Raiciu M. Handley S. Barre J. Iyengar March 2011 ASCII 68772 28 multipath tcp architecture

Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.

This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mptcp-architecture-05 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6182 RFC6183 IP Flow Information Export (IPFIX) Mediation: Framework A. Kobayashi B. Claise G. Muenz K. Ishibashi April 2011 ASCII 67997 29

This document describes a framework for IP Flow Information Export (IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipfix-mediators-framework-09 RFC5470 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6183 10.17487/RFC6183 RFC6184 RTP Payload Format for H.264 Video Y.-K. Wang R. Even T. Kristensen R. Jesup May 2011 ASCII 250627 101 AVC H.264/AVC Advanced Video Coding

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.

This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-rfc3984bis-12 RFC3984 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=6184 10.17487/RFC6184 RFC6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video T. Kristensen P. Luthi May 2011 ASCII 55562 22 H.264 H.241 ITU-T RTP Video SDP RCDO

This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-h264-rcdo-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6185 RFC6186 Use of SRV Records for Locating Email Submission/Access Services C. Daboo March 2011 ASCII 18895 9 imap pop3 smtp dns discovery

This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]

 draft-daboo-srv-email-05 RFC1939 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6186 RFC6187 X.509v3 Certificates for Secure Shell Authentication K. Igoe D. Stebila March 2011 ASCII 35208 16

X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]

 draft-igoe-secsh-x509v3-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6187 RFC6188 The Use of AES-192 and AES-256 in Secure RTP D. McGrew March 2011 ASCII 35973 16 SRTP

This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]

 draft-ietf-avt-srtp-big-aes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6188 RFC6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP P. Zimmermann A. Johnston Editor J. Callas April 2011 ASCII 293784 115

This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zimmermann-avt-zrtp-22 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6189 RFC6190 RTP Payload Format for Scalable Video Coding S. Wenger Y.-K. Wang T. Schierl A. Eleftheriadis May 2011 ASCII 250504 100 SVC AVC H.264/AVC Advanced Video Coding Scalable Video Coding

This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-svc-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload http://www.rfc-editor.org/errata_search.php?rfc=6190 10.17487/RFC6190 RFC6191 Reducing the TIME-WAIT State Using TCP Timestamps F. Gont April 2011 ASCII 22953 10

This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice.

 draft-ietf-tcpm-tcp-timestamps-04 BCP0159 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpm 10.17487/RFC6191 RFC6192 Protecting the Router Control Plane D. Dugal C. Pignataro R. Dunn March 2011 ASCII 49422 25 ACL Router Control Plane Protection Filter

This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.

Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-protect-control-plane-06 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=6192 10.17487/RFC6192 RFC6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP) M. Saito D. Wing M. Toyama April 2011 ASCII 50201 22 SIP IPsec setup VPN

This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-saito-mmusic-sdp-ike-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6193 RFC6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms T. Polk L. Chen S. Turner P. Hoffman March 2011 ASCII 15172 7

This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-sha0-sha1-seccon-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6194 10.17487/RFC6194 RFC6195 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd March 2011 ASCII 33790 17 RRTYPE RCODE AFSDB

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. This memo documents an Internet Best Current Practice.

 draft-ietf-dnsext-5395bis-03 RFC5395 RFC6895 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6195 RFC6196 Moving mailserver: URI Scheme to Historic A. Melnikov March 2011 ASCII 5679 3 mailserver URI

This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]

 draft-melnikov-mailserver-uri-to-historic-00 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6196 10.17487/RFC6196 RFC6197 Location-to-Service Translation (LoST) Service List Boundary Extension K. Wolf April 2011 ASCII 27562 15 listservicesbylocation

Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ecrit-lost-servicelistboundary-05 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit 10.17487/RFC6197 RFC6198 Requirements for the Graceful Shutdown of BGP Sessions B. Decraene P. Francois C. Pelsser Z. Ahmad A.J. Elizondo Armengol T. Takeda April 2011 ASCII 37906 20 routing BGP graceful shutdown connectivity loss maintenance network operation make-before-break planned

The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-bgp-graceful-shutdown-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6198 RFC6201 Device Reset Characterization R. Asati C. Pignataro F. Calabria C. Olvera March 2011 ASCII 34695 17 operation redundancy failover

An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.

This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-reset-06 RFC1242 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6201 RFC6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP S. Loreto P. Saint-Andre S. Salsano G. Wilkins April 2011 ASCII 44724 19 Hypertext Transfer Protocol bidirectional HTTP HTTP long polling HTTP streaming

On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-loreto-http-bidirectional-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6202 RFC6203 IMAP4 Extension for Fuzzy Search T. Sirainen March 2011 ASCII 13606 7 email

This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]

 draft-ietf-morg-fuzzy-search-03 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC6203 RFC6204 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark O. Troan Editor April 2011 ASCII 37026 17 IPv6 CE requirements

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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-ipv6-cpe-router-09 RFC7084 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6204 10.17487/RFC6204 RFC6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers T. Otani Editor D. Li Editor March 2011 ASCII 27749 15 DWDM CWDM Wavelength Label LSC

Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.

Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered.

In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-g-694-lambda-labels-11 RFC3471 RFC7699 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6205 RFC6206 The Trickle Algorithm P. Levis T. Clausen J. Hui O. Gnawali J. Ko March 2011 ASCII 30283 13 Consistency Eventual consistency Low-power Low power

The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]

 draft-ietf-roll-trickle-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6206 RFC6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml R. Denenberg Editor April 2011 ASCII 18090 11 mods Metadata Object Description Schema MADS Metadata Authority Description Schema METS Metadata Encoding and Transmission Standard MARCXML MARC21 XML Schema SRU Search/Retrieve via URL Response Format

This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-denenberg-mods-etc-media-types-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6207 RFC6208 Cloud Data Management Interface (CDMI) Media Types K. Sankar Editor A. Jones April 2011 ASCII 23187 13 snia Storage Networking Industry Association

This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:

o application/cdmi-object

o application/cdmi-container

o application/cdmi-domain

o application/cdmi-capability

o application/cdmi-queue

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cdmi-mediatypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6208 RFC6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) W. Kim J. Lee J. Park D. Kwon April 2011 ASCII 19501 9 aria encryption

This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-nsri-tls-aria-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6209 RFC6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME J. Schaad April 2011 ASCII 28339 14 example MD5-XOR Parameterized

New hash algorithms are being developed that may include parameters. Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. This document defines an Experimental Protocol for the Internet community.

 draft-schaad-smime-hash-experiment-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6210 10.17487/RFC6210 RFC6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute J. Schaad April 2011 ASCII 22646 11 example s/mime SMIME

The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]

 draft-schaad-smime-algorithm-attribute-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6211 RFC6212 Authentication-Results Registration for Vouch by Reference Results M. Kucherawy April 2011 ASCII 13199 7 VBR Reputation DKIM

This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]

 draft-kucherawy-authres-vbr-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6212 RFC6213 IS-IS BFD-Enabled TLV C. Hopps L. Ginsberg April 2011 ASCII 15527 7 type-length-value Bidirectional Forwarding Detection

This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]

 draft-ietf-isis-bfd-tlv-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6213 RFC6214 Adaptation of RFC 1149 for IPv6 B. Carpenter R. Hinden April 1 2011 ASCII 15073 7 avian carrier april fool

This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-carpenter-6man-adapt-rfc1149-00 RFC1149 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6214 10.17487/RFC6214 RFC6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces M. Bocci L. Levrau D. Frost April 2011 ASCII 13619 6

The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-uni-nni-03 RFC5921 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6215 RFC6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms C. Jennings K. Ono R. Sparks B. Hibbard Editor April 2011 ASCII 143891 67

This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipcore-sec-flows-09 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC6216 RFC6217 Regional Broadcast Using an Atmospheric Link Layer T. Ritter April 1 2011 ASCII 19546 9

Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ritter-regional-bcast-atmospheric-linklayer-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6217 RFC6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material G. Zorn T. Zhang J. Walker J. Salowey April 2011 ASCII 34463 18 Security

This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zorn-radius-keywrap-18 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6218 RFC6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition X. Li C. Bao M. Chen H. Zhang J. Wu May 2011 ASCII 44774 22 Stateless IPv4/IPv6 translation IPv4/IPv6 Header Translation IPv4-embedded IPv6 Address IPv4/IPv6 Multicast Translation stateless NAT64

This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.

The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-xli-behave-ivi-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6219 RFC6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators D. McPherson Editor O. Kolkman Editor J. Klensin Editor G. Huston Editor Internet Architecture Board April 2011 ASCII 23733 11

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-iana-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6220 RFC6221 Lightweight DHCPv6 Relay Agent D. Miles Editor S. Ooghe W. Dec S. Krishnan A. Kavanagh May 2011 ASCII 28471 17 ipv6 dsl

This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-ldra-03 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6221 10.17487/RFC6221 RFC6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing April 2011 ASCII 20393 9

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-cnames-05 RFC7022 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6222 RFC6223 Indication of Support for Keep-Alive C. Holmberg April 2011 ASCII 41439 18 SIP STUN outbound NAT traversal

This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. [STANDARDS-TRACK]

 draft-ietf-sipcore-keep-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6223 RFC6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt M. Waehlisch S. Krishnan April 2011 ASCII 46105 19 MLD proxy multicast routing mobility management transparent handover

This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-multimob-pmipv6-base-solution-07 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6224 RFC6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information J. Polk M. Linsner M. Thomson B. Aboba Editor July 2011 ASCII 77001 36

This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. [STANDARDS-TRACK]

 draft-ietf-geopriv-rfc3825bis-17 RFC3825 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=6225 10.17487/RFC6225 RFC6226 PIM Group-to-Rendezvous-Point Mapping B. Joshi A. Kessler D. McWalter May 2011 ASCII 24092 11 auto-RP BSR hash algorithm

Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. [STANDARDS-TRACK]

 draft-ietf-pim-group-rp-mapping-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6226 RFC6227 Design Goals for Scalable Internet Routing T. Li Editor May 2011 ASCII 18418 8 routing architecture addressing architecture

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering. The Routing Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-rrg-design-goals-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6227 RFC6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog C. Holmberg May 2011 ASCII 34311 14 199 Early dialog Forking Provisional response

This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. [STANDARDS-TRACK]

 draft-ietf-sipcore-199-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6228 10.17487/RFC6228 RFC6229 Test Vectors for the Stream Cipher RC4 J. Strombergson S. Josefsson May 2011 ASCII 28406 12 arcfour128 arcfour256 arcfour ARC4m Stream Cipher Test Vectors Known Answer Test arcfour ARC4 WEP WPA RFC 4345

This document contains test vectors for the stream cipher RC4. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-josefsson-rc4-test-vectors-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6229 RFC6230 Media Control Channel Framework C. Boulton T. Melanchuk S. McGlashan May 2011 ASCII 112479 49

This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.

The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. [STANDARDS-TRACK]

 draft-ietf-mediactrl-sip-control-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6230 RFC6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton May 2011 ASCII 286771 134

This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. [STANDARDS-TRACK]

 draft-ietf-mediactrl-ivr-control-package-11 RFC6623 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6231 10.17487/RFC6231 RFC6232 Purge Originator Identification TLV for IS-IS F. Wei Y. Qin Z. Li T. Li J. Dong May 2011 ASCII 10234 6 Purge Originator Identification IIH:n LSP:y SNP:n Purge:y

At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge. This makes it difficult to locate the source IS.

To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normal Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.

This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

 draft-ietf-isis-purge-tlv-05 RFC5301 RFC5304 RFC5310 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6232 RFC6233 IS-IS Registry Extension for Purges T. Li L. Ginsberg May 2011 ASCII 8435 4 Intermediate System to Intermediate System LSP security authentication IANA

IANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS Protocol Data Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

 draft-ietf-isis-reg-purge-01 RFC3563 RFC5304 RFC5310 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6233 RFC6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) D. Eastlake 3rd T. Hansen May 2011 ASCII 236573 127

Federal Information Processing Standard, FIPS

 draft-eastlake-sha2b-07 RFC4634 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6234 RFC6235 IP Flow Anonymization Support E. Boschi B. Trammell May 2011 ASCII 112595 43 IPFIX flow information export address anonymization pseudonymization data protection privacy

This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ipfix-anon-06 EXPERIMENTAL EXPERIMENTAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6235 10.17487/RFC6235 RFC6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) I. Johansson K. Jung May 2011 ASCII 49356 23

This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a \%low-end \%hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. [STANDARDS-TRACK]

 draft-ietf-mmusic-image-attributes-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6236 10.17487/RFC6236 RFC6237 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov May 2011 ASCII 21234 10 email multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-morg-multimailbox-search-07 RFC7377 RFC4466 EXPERIMENTAL EXPERIMENTAL IETF app morg 10.17487/RFC6237 RFC6238 TOTP: Time-Based One-Time Password Algorithm D. M'Raihi S. Machani M. Pei J. Rydell May 2011 ASCII 32174 16 OTP OATH HOTP two factor authentication strong authentication

This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.

The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mraihi-totp-timebased-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6238 10.17487/RFC6238 RFC6239 Suite B Cryptographic Suites for Secure Shell (SSH) K. Igoe May 2011 ASCII 28990 14

This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-igoe-secsh-suiteb-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6239 RFC6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 D. Zelig Editor R. Cohen Editor T. Nadeau Editor May 2011 ASCII 129814 67 management information base PW-CEP-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). [STANDARDS-TRACK]

 draft-ietf-pwe3-cep-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6240 RFC6241 Network Configuration Protocol (NETCONF) R. Enns Editor M. Bjorklund Editor J. Schoenwaelder Editor A. Bierman Editor June 2011 ASCII 209465 113 XML Configuration Network Management Extensible Markup Language

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]

 draft-ietf-netconf-4741bis-10 RFC4741 RFC7803 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6241 10.17487/RFC6241 RFC6242 Using the NETCONF Protocol over Secure Shell (SSH) M. Wasserman June 2011 ASCII 22704 11 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]

 draft-ietf-netconf-rfc4742bis-08 RFC4742 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC6242 RFC6243 With-defaults Capability for NETCONF A. Bierman B. Lengyel June 2011 ASCII 51568 26 network configuration protocol

The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]

 draft-ietf-netconf-with-defaults-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6243 10.17487/RFC6243 RFC6244 An Architecture for Network Management Using NETCONF and YANG P. Shafer June 2011 ASCII 63276 30 network configuration protocol

The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.

This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netmod-arch-10 INFORMATIONAL INFORMATIONAL IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6244 10.17487/RFC6244 RFC6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 P. Yegani K. Leung A. Lior K. Chowdhury J. Navali May 2011 ASCII 16823 8

The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses. When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling. [STANDARDS-TRACK]

 draft-ietf-mip4-gre-key-extension-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6245 RFC6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges A. Sajassi Editor F. Brockners D. Mohan Editor Y. Serbest June 2011 ASCII 51024 20 ieee bridges

One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.

When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l2vpn-vpls-bridge-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6246 RFC6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status L. Eggert May 2011 ASCII 6414 4

This document reclassifies several TCP extensions that have never seen widespread use to Historic status. The affected RFCs are RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-eggert-tcpm-historicize-02 RFC1072 RFC1106 RFC1110 RFC1145 RFC1146 RFC1379 RFC1644 RFC1693 RFC4614 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6247 RFC6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete A. Morton April 2011 ASCII 10192 6

This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM) Metrics Registry", as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-morton-ippm-rfc4148-obsolete-03 RFC4148 RFC4737 RFC5560 RFC5644 RFC6049 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6248 RFC6249 Metalink/HTTP: Mirrors and Hashes A. Bryan N. McNab T. Tsujikawa P. Poeml H. Nordstrom June 2011 ASCII 45303 21 file transfer download link signature data integrity hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/HTTP clients and servers are described here. [STANDARDS-TRACK]

 draft-bryan-metalinkhttp-22 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6249 10.17487/RFC6249 RFC6250 Evolution of the IP Model D. Thaler May 2011 ASCII 60778 25 Internet Protocol IPv4 IPv6 service model

This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-ip-model-evolution-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6250 RFC6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol S. Josefsson May 2011 ASCII 17051 8 kerberos tls starttls kdc

This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-josefsson-kerberos5-starttls-09 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC6251 RFC6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization A. Dutta Editor V. Fajardo Y. Ohba K. Taniuchi H. Schulzrinne June 2011 ASCII 149395 57 Mobility Optimization Proactive handoff Link-layer security Handover taxonomy Layer 2 handoff Layer 3 handoff Network discovery Handover delay Packet loss Proactive binding update Multi-interface IP address acquisition Tunnel management

This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.

This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-mobopts-mpa-framework-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6252 RFC6253 Host Identity Protocol Certificates T. Heer S. Varjonen May 2011 ASCII 24079 12

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the CERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates.

The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 5201. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-cert-12 RFC8002 RFC5201 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6253 RFC6254 Request to Move RFC 2754 to Historic Status M. McFadden May 2011 ASCII 6696 3 RPS

RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System. In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iana-rfc2754-to-historic-02 RFC2754 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6254 RFC6255 Delay-Tolerant Networking Bundle Protocol IANA Registries M. Blanchet May 2011 ASCII 19606 9 DTN SNDV DTNRG Space networking

The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group 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 executed by IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-dtnrg-iana-bp-registries-02 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6255 RFC6256 Using Self-Delimiting Numeric Values in Protocols W. Eddy E. Davies May 2011 ASCII 40765 17 SDNV DTN

Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. 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 is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-dtnrg-sdnv-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6256 RFC6257 Bundle Security Protocol Specification S. Symington S. Farrell H. Weiss P. Lovell May 2011 ASCII 142509 60

This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.

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 an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-security-19 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6257 10.17487/RFC6257 RFC6258 Delay-Tolerant Networking Metadata Extension Block S. Symington May 2011 ASCII 22584 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. 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 an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-metadata-block-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6258 RFC6259 Delay-Tolerant Networking Previous-Hop Insertion Block S. Symington May 2011 ASCII 23278 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol. This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. 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 an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-previous-hop-block-12 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6259 RFC6260 Compressed Bundle Header Encoding (CBHE) S. Burleigh May 2011 ASCII 25381 12 DTN delay-tolerant networking BP bundle protocol IPN

This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.

Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.

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 an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-cbhe-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6260 RFC6261 Encrypted Signaling Transport Modes for the Host Identity Protocol A. Keranen May 2011 ASCII 28354 13

This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-over-hip-06 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6261 RFC6262 RTP Payload Format for IP-MR Speech Codec S. Ikonin August 2011 ASCII 39511 19 ipmr vocoder multirate scalable scalability

This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-ipmr-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6262 RFC6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows X. Marjou A. Sollaud June 2011 ASCII 23345 12 AVT SDP port

This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK]

 draft-ietf-avt-app-rtp-keepalive-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6263 RFC6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition S. Jiang D. Guo B. Carpenter June 2011 ASCII 31881 13

Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.

This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-incremental-cgn-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6264 RFC6265 HTTP State Management Mechanism A. Barth April 2011 ASCII 79724 37 Cookie Set-Cookie Secure HttpOnly

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]

 draft-ietf-httpstate-cookie-23 RFC2965 PROPOSED STANDARD PROPOSED STANDARD IETF app httpstate http://www.rfc-editor.org/errata_search.php?rfc=6265 10.17487/RFC6265 RFC6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) J. Reschke June 2011 ASCII 26080 14 filename attachment inline

RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]

 draft-ietf-httpbis-content-disp-09 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=6266 10.17487/RFC6266 RFC6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) V. Cakulev G. Sundaram June 2011 ASCII 68031 30 Identity based encryption authentication key agreement

This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cakulev-mikey-ibake-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6267 RFC6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) J. Schaad S. Turner July 2011 ASCII 55693 33 ASN.1 Certficate Extensions HMAC

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-additional-new-asn-08 RFC5911 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6268 RFC6269 Issues with IP Address Sharing M. Ford Editor M. Boucadair A. Durand P. Levis P. Roberts June 2011 ASCII 71660 29 IPv4 address exhaustion completion shared sharing issues

The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.

Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-intarea-shared-addressing-issues-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6269 RFC6270 The 'tn3270' URI Scheme M. Yevstifeyev June 2011 ASCII 10876 6 URI Telnet Telnet 3270 TN3270

This document is the specification of the 'tn3270' Uniform Resource Identifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270 Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned this URI scheme without defining its syntax and semantics. [STANDARDS-TRACK]

 draft-yevstifeyev-tn3270-uri-18 RFC2355 RFC1738 RFC1041 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6270 RFC6271 Requirements for SIP-Based Session Peering J-F. Mule June 2011 ASCII 54492 23 IETF speermint guidelines requirements for session interconnects session peering SIP interconnects VoIP peering

This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-requirements-11 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6271 RFC6272 Internet Protocols for the Smart Grid F. Baker D. Meyer June 2011 ASCII 162815 66

This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-baker-ietf-core-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6272 RFC6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis A. Kukec S. Krishnan S. Jiang June 2011 ASCII 13100 7

This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-csi-hash-threat-12 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC6273 RFC6274 Security Assessment of the Internet Protocol Version 4 F. Gont July 2011 ASCII 179909 75 vulnerabilities Denial of Service resiliency hardening information leakage

This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-ip-security-07 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=6274 10.17487/RFC6274 RFC6275 Mobility Support in IPv6 C. Perkins Editor D. Johnson J. Arkko July 2011 ASCII 405488 169 MIPv6 mobility IPv6 internet protocol nodes

This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK]

 draft-ietf-mext-rfc3775bis-13 RFC3775 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6275 10.17487/RFC6275 RFC6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO) R. Droms P. Thubert F. Dupont W. Haddad C. Bernardos July 2011 ASCII 30430 14 IPv6 mobile router home agent mobile network prefix

One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. [STANDARDS-TRACK]

 draft-ietf-mext-nemo-pd-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6276 10.17487/RFC6276 RFC6277 Online Certificate Status Protocol Algorithm Agility S. Santesson P. Hallam-Baker June 2011 ASCII 21682 11 ocsp

The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]

 draft-ietf-pkix-ocspagility-10 RFC6960 RFC2560 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6277 RFC6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax J. Herzog R. Khazan June 2011 ASCII 36593 16 set-key group-key

This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-herzog-static-ecdh-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6278 RFC6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement M. Liebsch Editor S. Jeong Q. Wu June 2011 ASCII 32954 14 Local Routing Route Optimization Traffic Offload

Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netext-pmip6-lr-ps-06 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC6279 RFC6280 An Architecture for Location and Location Privacy in Internet Applications R. Barnes M. Lepinski A. Cooper J. Morris H. Tschofenig H. Schulzrinne July 2011 ASCII 99801 41 geolocation geopriv

Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. This memo documents an Internet Best Current Practice.

 draft-ietf-geopriv-arch-03 RFC3693 RFC3694 BCP0160 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv 10.17487/RFC6280 RFC6281 Understanding Apple's Back to My Mac (BTMM) Service S. Cheshire Z. Zhu R. Wakikawa L. Zhang June 2011 ASCII 39314 16

This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zhu-mobileme-doc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6281 10.17487/RFC6281 RFC6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks J. Hui Editor P. Thubert September 2011 ASCII 52588 24 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]

 draft-ietf-6lowpan-hc-15 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=6282 10.17487/RFC6282 RFC6283 Extensible Markup Language Evidence Record Syntax (XMLERS) A. Jerman Blazic S. Saljic T. Gondrom July 2011 ASCII 99031 43 long term trust integrity long term integrity data preservation document preservation time-stamp time-stamping archive time stamp electronic archive electronic archiving trusted archiving long-term archive archive data evidence evidence record evidence record syntax hash tree ERS XML hash signature renewal algorithm cryptography

In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK]

 draft-ietf-ltans-xmlers-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC6283 RFC6284 Port Mapping between Unicast and Multicast RTP Sessions A. Begen D. Wing T. Van Caenegem June 2011 ASCII 73289 30 Port mapping port translation RTP multicast NAT

This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK]

 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6284 RFC6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions B. Ver Steeg A. Begen T. Van Caenegem Z. Vax June 2011 ASCII 141497 56 SSM multicast IPTV fast channel change

When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.

In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [STANDARDS-TRACK]

 draft-ietf-avt-rapid-acquisition-for-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6285 RFC6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen J. Yuan June 2011 ASCII 7497 4

To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-identifier-14 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=6286 10.17487/RFC6286 RFC6287 OCRA: OATH Challenge-Response Algorithm D. M'Raihi J. Rydell S. Bajaj S. Machani D. Naccache June 2011 ASCII 78076 38 HOTP TOTP One-Time Password Authentication Signature

This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication (OATH). The specified mechanisms leverage the HMAC-based One-Time Password (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mraihi-mutual-oath-hotp-variants-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6287 10.17487/RFC6287 RFC6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG) C. Reed August 2011 ASCII 16218 8 Namespace Identifier nid DGIWG Registry System drs

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) Namespace resources published by the Defence Geospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.

Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-reed-urn-dgiwg-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6288 RFC6289 A Uniform Resource Name (URN) Namespace for CableLabs E. Cardona S. Channabasappa J-F. Mule June 2011 ASCII 12976 7 namespace identifier nid

This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cardona-cablelabs-urn-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6289 RFC6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Y. Nir Editor D. Wierbowski F. Detienne P. Sethi June 2011 ASCII 48891 22 QCD

This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK]

 draft-ietf-ipsecme-failure-detection-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6290 10.17487/RFC6290 RFC6291 Guidelines for the Use of the "OAM" Acronym in the IETF L. Andersson H. van Helvoort R. Bonica D. Romascanu S. Mansfield June 2011 ASCII 16696 9

At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.

This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice.

 draft-ietf-opsawg-mpls-tp-oam-def-10 BCP0161 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsawg 10.17487/RFC6291 RFC6292 Requirements for a Working Group Charter Tool P. Hoffman June 2011 ASCII 23701 11

The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-charter-tool-09 RFC6433 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6292 10.17487/RFC6292 RFC6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker P. Hoffman June 2011 ASCII 36874 17

The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-datatracker-community-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6293 RFC6294 Survey of Proposed Use Cases for the IPv6 Flow Label Q. Hu B. Carpenter June 2011 ASCII 43303 18 Quality of service QoS

The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hu-flow-label-cases-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6294 RFC6295 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek June 2011 ASCII 409730 171 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtpmidi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695. [STANDARDS-TRACK]

 draft-ietf-payload-rfc4695-bis-02 RFC4695 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6295 RFC6296 IPv6-to-IPv6 Network Prefix Translation M. Wasserman F. Baker June 2011 ASCII 73700 32

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. This document defines an Experimental Protocol for the Internet community.

 draft-mrw-nat66-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6296 10.17487/RFC6296 RFC6297 A Survey of Lower-than-Best-Effort Transport Protocols M. Welzl D. Ros June 2011 ASCII 46532 18 Less-than-Best-Effort Congestion Control LEDBAT

This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best-effort service. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ledbat-survey-07 INFORMATIONAL INFORMATIONAL IETF tsv ledbat 10.17487/RFC6297 RFC6298 Computing TCP's Retransmission Timer V. Paxson M. Allman J. Chu M. Sargent June 2011 ASCII 22454 11 RTO

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]

 draft-paxson-tcpm-rfc2988bis-02 RFC2988 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6298 RFC6301 A Survey of Mobility Support in the Internet Z. Zhu R. Wakikawa L. Zhang July 2011 ASCII 84861 33

Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zhu-mobility-survey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6301 RFC6302 Logging Recommendations for Internet-Facing Servers A. Durand I. Gashinsky D. Lee S. Sheppard June 2011 ASCII 10039 5 port logging

In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address. This memo documents an Internet Best Current Practice.

 draft-ietf-intarea-server-logging-recommendations-04 BCP0162 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6302 RFC6303 Locally Served DNS Zones M. Andrews July 2011 ASCII 22503 10 AS112 Reverse IN-ADDR.ARPA IP6.ARPA RFC1918

Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics. This memo documents an Internet Best Current Practice.

 draft-ietf-dnsop-default-local-zones-15 BCP0163 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC6303 RFC6304 AS112 Nameserver Operations J. Abley W. Maton July 2011 ASCII 34002 18 DNS RFC1918

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-as112-ops-09 RFC7534 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6304 RFC6305 I'm Being Attacked by PRISONER.IANA.ORG! J. Abley W. Maton July 2011 ASCII 15287 8

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.

Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.

This document provides background information and technical advice to those firewall operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-as112-under-attack-help-help-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6305 RFC6306 Hierarchical IPv4 Framework P. Frejborg July 2011 ASCII 160667 65 core address space area locators alocs edge address space endpoint locators elocs

This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique. In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.

This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing Domain Name System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. This document defines an Experimental Protocol for the Internet community.

 draft-frejborg-hipv4-14 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6306 RFC6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks D. Black Editor L. Dunbar Editor M. Roth R. Solomon April 2012 ASCII 49421 21

A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. [STANDARDS-TRACK]

 draft-ietf-pwe3-fc-encap-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6307 RFC6308 Overview of the Internet Multicast Addressing Architecture P. Savola June 2011 ASCII 30988 14 assignment allocation SSM ASM GLOP

The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mboned-addrarch-07 RFC2908 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6308 RFC6309 IANA Rules for MIKEY (Multimedia Internet KEYing) J. Arkko A. Keranen J. Mattsson August 2011 ASCII 10706 6 short-term key message long-term key message oma bac browser and content broadcast

This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK]

 draft-arkko-mikey-iana-01 RFC4909 RFC3830 RFC4563 RFC5410 RFC6043 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6309 RFC6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping M. Aissaoui P. Busschbach L. Martini M. Morrow T. Nadeau Y(J). Stein July 2011 ASCII 85733 40 interworking defect state defect indication pseudowire OAM

This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK]

 draft-ietf-pwe3-oam-msg-map-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6310 10.17487/RFC6310 RFC6311 Protocol Support for High Availability of IKEv2/IPsec R. Singh Editor G. Kalyani Y. Nir Y. Sheffer D. Zhang July 2011 ASCII 58672 26 IPsec high availability load sharing clustering fail-over

The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.

This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ipsecha-protocol-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6311 10.17487/RFC6311 RFC6312 Mobile Networks Considerations for IPv6 Deployment R. Koodli July 2011 ASCII 45988 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6-in-mobile-networks-05 RFC6342 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6312 RFC6313 Export of Structured Data in IP Flow Information Export (IPFIX) B. Claise G. Dhandapani P. Aitken S. Yates July 2011 ASCII 163360 71 ipfix information model

This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK]

 draft-ietf-ipfix-structured-data-06 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6313 10.17487/RFC6313 RFC6314 NAT Traversal Practices for Client-Server SIP C. Boulton J. Rosenberg G. Camarillo F. Audet July 2011 ASCII 152998 60

Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-nat-scenarios-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6314 RFC6315 IANA Registration for Enumservice 'iax' E. Guy K. Darilion July 2011 ASCII 11067 6 ENUM E.164 VoIP Voice over IP

This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC 6117. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-enum-iax-10 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC6315 RFC6316 Sockets Application Program Interface (API) for Multihoming Shim M. Komu M. Bagnulo K. Slavov S. Sugimoto Editor July 2011 ASCII 93076 44 Shim6 HIP identifier/locator split

This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.

This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and the Host Identity Protocol (HIP). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-shim6-multihome-shim-api-17 INFORMATIONAL INFORMATIONAL IETF int shim6 10.17487/RFC6316 RFC6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP) M. Komu T. Henderson July 2011 ASCII 43970 18 host identity tag cryptographic identity cryptographic namespace sockets API Shim6 opportunistic mode resolver HIP wildcard address ORCHID source address selection HIT prefix locator handling

This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags (HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-native-api-12 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6317 RFC6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas June 2011 ASCII 31488 15

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-housley-rfc5008bis-01 RFC5008 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6318 RFC6319 Issues Associated with Designating Additional Private IPv4 Address Space M. Azinger L. Vegoda July 2011 ASCII 26939 12 private network

When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space.

While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-azinger-additional-private-ipv4-space-issues-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6319 RFC6320 Protocol for Access Node Control Mechanism in Broadband Networks S. Wadhwa J. Moisand T. Haag N. Voigt T. Taylor Editor October 2011 ASCII 178446 82 ancp

This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.

ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. [STANDARDS-TRACK]

 draft-ietf-ancp-protocol-17 RFC7256 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC6320 RFC6321 xCal: The XML Format for iCalendar C. Daboo M. Douglass S. Lees August 2011 ASCII 79701 54 extensible markup language

This specification defines "xCal", an XML format for iCalendar data. [STANDARDS-TRACK]

 draft-daboo-et-al-icalendar-in-xml-11 RFC6868 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6321 10.17487/RFC6321 RFC6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams P. Hoffman July 2011 ASCII 24153 11

This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent Submissions Editor. The states and annotations that are to be added to the Datatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventual RFC, and will continue through the lifetime of the Internet-Draft. The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of these Internet-Drafts and the streams from which they originate. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hoffman-alt-streams-tracker-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6322 RFC6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) G. Renker G. Fairhurst July 2011 ASCII 27434 13 DCCP TFRC CCID-3 CCID-4

This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP.

The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.

It is integrated into the feature set of DCCP as an end-to-end negotiable extension. [STANDARDS-TRACK]

 draft-ietf-dccp-tfrc-rtt-option-06 RFC4342 RFC5622 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC6323 RFC6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations G. Nakibly F. Templin August 2011 ASCII 47385 19 Encapsulation ISATAP 6rd

This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-tunnel-loops-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6324 RFC6325 Routing Bridges (RBridges): Base Protocol Specification R. Perlman D. Eastlake 3rd D. Dutt S. Gai A. Ghanwani July 2011 ASCII 243158 99 TRILL

Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.

RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.

The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]

 draft-ietf-trill-rbridge-protocol-16 RFC6327 RFC6439 RFC7172 RFC7177 RFC7357 RFC7179 RFC7180 RFC7455 RFC7780 RFC7783 PROPOSED STANDARD PROPOSED STANDARD IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=6325 10.17487/RFC6325 RFC6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake A. Banerjee D. Dutt R. Perlman A. Ghanwani July 2011 ASCII 51059 25 TRILL RBridge IS-IS ISIS

The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. [STANDARDS-TRACK]

 draft-ietf-isis-trill-05 RFC7176 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6326 10.17487/RFC6326 RFC6327 Routing Bridges (RBridges): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani D. Dutt V. Manral July 2011 ASCII 59014 26 RBridge TRILL Adjacency

The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, 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. Devices that implement TRILL are called Routing Bridges (RBridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. [STANDARDS-TRACK]

 draft-ietf-trill-adj-07 RFC7177 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6327 RFC6328 IANA Considerations for Network Layer Protocol Identifiers D. Eastlake 3rd July 2011 ASCII 16123 9 NLPID

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA considerations. This memo documents an Internet Best Current Practice.

 draft-eastlake-nlpid-iana-considerations-04 BCP0164 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6328 RFC6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging D. Fedyk Editor P. Ashwood-Smith Editor D. Allan A. Bragg P. Unbehagen April 2012 ASCII 88465 37 spb

802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. [STANDARDS-TRACK]

 draft-ietf-isis-ieee-aq-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6329 10.17487/RFC6329 RFC6330 RaptorQ Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer L. Minder August 2011 ASCII 169852 69 FEC code fountain code systematic code AL FEC code Sub-blocking FEC object delivery

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.

RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.

The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-raptorq-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC6330 RFC6331 Moving DIGEST-MD5 to Historic A. Melnikov July 2011 ASCII 14047 6 http hypertext transfer protocol security simple layer

This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-kitten-digest-to-historic-04 RFC2831 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC6331 RFC6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen E. Friedrich July 2011 ASCII 35217 16 SSM multicast IPTV RAMS rapid acquisition fast channel change

In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avtext-multicast-acq-rtcp-xr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6332 RFC6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion A. Durand R. Droms J. Woodyatt Y. Lee August 2011 ASCII 65622 32 NAT

This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]

 draft-ietf-softwire-dual-stack-lite-11 RFC7335 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6333 RFC6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite D. Hankins T. Mrugalski August 2011 ASCII 14362 7 Softwire DS-Lite

This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK]

 draft-ietf-softwire-ds-lite-tunnel-option-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6334 RFC6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry M. Cotton L. Eggert J. Touch M. Westerlund S. Cheshire August 2011 ASCII 79088 33 IANA transport ports port numbers allocation assignment procedures

This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.

This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.

 draft-ietf-tsvwg-iana-ports-10 RFC2780 RFC2782 RFC3828 RFC4340 RFC4960 RFC5595 BCP0165 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6335 10.17487/RFC6335 RFC6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options M. Westerlund C. Perkins July 2011 ASCII 8228 5

It has been identified that "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245. [STANDARDS-TRACK]

 draft-ietf-mmusic-ice-options-registry-02 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6336 RFC6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model S. Okumura T. Sawada P. Kyzivat August 2011 ASCII 76776 33 answer offer SDP SIP

The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-sip-offeranswer-18 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6337 RFC6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC) V. Giralt R. McDuff August 2011 ASCII 21688 11 TERENA tf-emc2

This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).

The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-giralt-schac-ns-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6338 RFC6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API) S. Josefsson L. Hornquist Astrand August 2011 ASCII 13285 8

This document describes three abstract Generic Security Service Application Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces. [STANDARDS-TRACK]

 draft-josefsson-gss-capsulate-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6339 RFC6340 Textual Conventions for the Representation of Floating-Point Numbers R. Presuhn August 2011 ASCII 13811 7 Network Management IEEE 754 Floating-point MIB SMIv2 Textual Convention FLOAT-TC-MIB

This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK]

 draft-ietf-opsawg-mib-floats-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC6340 RFC6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC) K. Rehor Editor L. Portman Editor A. Hutton R. Jain August 2011 ASCII 34155 16

Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.

Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-siprec-req-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC6341 RFC6342 Mobile Networks Considerations for IPv6 Deployment R. Koodli August 2011 ASCII 46288 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6-in-mobile-networks-rfc6312bis RFC6312 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6342 RFC6343 Advisory Guidelines for 6to4 Deployment B. Carpenter August 2011 ASCII 51496 20 IPv6 relay

This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-6to4-advisory-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6343 RFC6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) G. Bernstein Editor D. Caviglia R. Rabbat H. van Helvoort August 2011 ASCII 44897 21

This document describes requirements for, and the use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-vcat-lcas-13 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6344 RFC6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element P. Duffy S. Chakrabarti R. Cragie Y. Ohba Editor A. Yegin August 2011 ASCII 25128 12 EAP ZigBee

This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. [STANDARDS-TRACK]

 draft-ohba-pana-relay-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6345 10.17487/RFC6345 RFC6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage R. Bush Editor August 2011 ASCII 89553 38

We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.

This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community.

 draft-ymbk-aplusp-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6346 RFC6347 Datagram Transport Layer Security Version 1.2 E. Rescorla N. Modadugu January 2012 ASCII 73546 32 dtls dtls protocol

This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]

 draft-ietf-tls-rfc4347-bis-06 RFC4347 RFC7507 RFC7905 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6347 10.17487/RFC6347 RFC6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol JL. Le Roux Editor T. Morin Editor September 2011 ASCII 38902 20 MPLS LDP multipoint P2MP multicast

This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.

This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. This document defines a Historic Document for the Internet community.

 draft-ietf-mpls-mp-ldp-reqs-08 HISTORIC HISTORIC IETF rtg mpls 10.17487/RFC6348 RFC6349 Framework for TCP Throughput Testing B. Constantine G. Forget R. Geib R. Schrage August 2011 ASCII 62494 27 metric TCP testing

This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCP Throughput. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-tcp-throughput-tm-13 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6349 RFC6350 vCard Format Specification S. Perreault August 2011 ASCII 139895 74 vCard

This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]

 draft-ietf-vcarddav-vcardrev-22 RFC2425 RFC2426 RFC4770 RFC2739 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6350 10.17487/RFC6350 RFC6351 xCard: vCard XML Representation S. Perreault August 2011 ASCII 34086 22 vCard

This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]

 draft-ietf-vcarddav-vcardxml-11 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6351 10.17487/RFC6351 RFC6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) C. Daboo August 2011 ASCII 98548 48 address address book contact

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]

 draft-ietf-vcarddav-carddav-10 RFC6764 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6352 10.17487/RFC6352 RFC6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker July 2011 ASCII 148571 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-dtls-tm-rfc5953bis-00 RFC5953 STD0078 INTERNET STANDARD DRAFT STANDARD IETF sec isms 10.17487/RFC6353 RFC6354 Forward-Shifted RTP Redundancy Payload Support Q. Xie August 2011 ASCII 26488 13

This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). [STANDARDS-TRACK]

 draft-ietf-avt-forward-shifted-red-08 RFC2198 RFC4102 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6354 RFC6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) T. Narten J. Johnson August 2011 ASCII 11453 5 universally unique identifier

This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. [STANDARDS-TRACK]

 draft-ietf-dhc-duid-uuid-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6355 RFC6356 Coupled Congestion Control for Multipath Transport Protocols C. Raiciu M. Handley D. Wischik October 2011 ASCII 27961 12 multipath tcp congestion control

Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.

New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.

This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mptcp-congestion-07 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp 10.17487/RFC6356 RFC6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control V. Hilt E. Noel C. Shen A. Abdelal August 2011 ASCII 64252 25 Session Initiation Protocol Overload Control Congestion Collapse

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 discusses models and design considerations for a SIP overload control mechanism. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-soc-overload-design-08 INFORMATIONAL INFORMATIONAL IETF rai soc 10.17487/RFC6357 RFC6358 Additional Master Secret Inputs for TLS P. Hoffman January 2012 ASCII 9074 4 tls dtls datagram tls

This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). This document defines an Experimental Protocol for the Internet community.

 draft-hoffman-tls-master-secret-input-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6358 RFC6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information S. Ginoza M. Cotton A. Morris September 2011 ASCII 38532 18 id-tracker backend extensions

This document captures the requirements for integrating IANA and RFC Editor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC. Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-datatracker-iana-rfced-extns-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6359 RFC6360 Conclusion of FYI RFC Sub-Series R. Housley August 2011 ASCII 4729 3

This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iesg-rfc1150bis-01 RFC1150 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6360 RFC6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol J. Carlson D. Eastlake 3rd August 2011 ASCII 17705 8 point-to-point protocol rbridges routing bridges

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK]

 draft-ietf-pppext-trill-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6361 RFC6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT) K. Meadors Editor August 2011 ASCII 15137 8 EDIINT AS2 Multiple Attachments

The Electronic Data Interchange - Internet Integration (EDIINT) AS1, AS2, and AS3 messages were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDIINT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message. The attachments are stored within the MIME multipart/related structure. A minimal list of content-types to be supported as attachments is provided. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-meadors-multiple-attachments-ediint-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6362 RFC6363 Forward Error Correction (FEC) Framework M. Watson A. Begen V. Roca October 2011 ASCII 98725 42 Reliable streaming content delivery FEC schemes

This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]

 draft-ietf-fecframe-framework-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6363 RFC6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework A. Begen October 2011 ASCII 36160 18 FEC configuration FEC topologies

This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. [STANDARDS-TRACK]

 draft-ietf-fecframe-sdp-elements-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6364 RFC6365 Terminology Used in Internationalization in the IETF P. Hoffman J. Klensin September 2011 ASCII 103155 47 i18n vocabulary terms

This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.

 draft-ietf-appsawg-rfc3536bis-06 RFC3536 BCP0166 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6365 10.17487/RFC6365 RFC6366 Requirements for an Internet Audio Codec J. Valin K. Vos August 2011 ASCII 39355 17

This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-codec-requirements-05 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6366 RFC6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) S. Kanno M. Kanda September 2011 ASCII 17613 8 TLS GCM Eliptic Curve Encryption Block Cipher psk

This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-kanno-tls-camellia-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6367 10.17487/RFC6367 RFC6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) P. Marques R. Raszuk K. Patel K. Kumaki T. Yamagata September 2011 ASCII 29938 14 l3vpn iBGP loops as-override attribute set attr_set

This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK]

 draft-ietf-l3vpn-ibgp-08 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6368 10.17487/RFC6368 RFC6369 Forwarding and Control Element Separation (ForCES) Implementation Experience E. Haleplidis O. Koufopavlou S. Denazis September 2011 ASCII 34236 18

The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-haleplidis-forces-implementation-experience-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6369 RFC6370 MPLS Transport Profile (MPLS-TP) Identifiers M. Bocci G. Swallow E. Gray September 2011 ASCII 35294 17

This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-identifiers-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6370 RFC6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks I. Busi Editor D. Allan Editor September 2011 ASCII 142857 62

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.

This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-oam-framework-11 RFC6435 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6371 10.17487/RFC6371 RFC6372 MPLS Transport Profile (MPLS-TP) Survivability Framework N. Sprecher Editor A. Farrel Editor September 2011 ASCII 142437 56 Protection Restoration Recovery

Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.

This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-survive-fwk-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6372 RFC6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework L. Andersson Editor L. Berger Editor L. Fang Editor N. Bitar Editor E. Gray Editor September 2011 ASCII 144259 57

The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-mpls-tp-cp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6373 RFC6374 Packet Loss and Delay Measurement for MPLS Networks D. Frost S. Bryant September 2011 ASCII 123462 52

Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]

 draft-ietf-mpls-loss-delay-04 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6374 10.17487/RFC6374 RFC6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks D. Frost Editor S. Bryant Editor September 2011 ASCII 10026 5

Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.

The 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 describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-loss-delay-profile-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6375 RFC6376 DomainKeys Identified Mail (DKIM) Signatures D. Crocker Editor T. Hansen Editor M. Kucherawy Editor September 2011 ASCII 176999 76 email architecture abuse verification anti-abuse identity integrity responsible author sender originator email filtering anti-phishing mail signature

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]

 draft-ietf-dkim-rfc4871bis-15 RFC4871 RFC5672 STD0076 INTERNET STANDARD DRAFT STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6376 10.17487/RFC6376 RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists M. Kucherawy September 2011 ASCII 61792 26 email architecture verification anti-abuse identity integrity responsible author sender originator

DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). This memo documents an Internet Best Current Practice.

 draft-ietf-dkim-mailinglists-12 BCP0167 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6377 10.17487/RFC6377 RFC6378 MPLS Transport Profile (MPLS-TP) Linear Protection Y. Weingarten Editor S. Bryant E. Osborne N. Sprecher A. Fulignoli Editor October 2011 ASCII 99684 45 PSC Protection State Coordination Protocol,

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-linear-protection-09 RFC7214 RFC7271 RFC7324 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6378 RFC6379 Suite B Cryptographic Suites for IPsec L. Law J. Solinas October 2011 ASCII 12624 7 UI suites user interface suites elliptic curve ike

This document proposes four cryptographic user interface suites ("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-law-rfc4869bis-01 RFC4869 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6379 RFC6380 Suite B Profile for Internet Protocol Security (IPsec) K. Burgin M. Peck October 2011 ASCII 21769 10 cryptographic algorithm policy security application suite b cryptography

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 IP Security (IPsec).

Since many of the Suite B algorithms are used in other environments, 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 detail repeated to aid developers who choose to support Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-burgin-ipsec-suiteb-profile-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6380 RFC6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types R. Gellens D. Singer P. Frojdh August 2011 ASCII 39790 19 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered.

This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).

Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]

 draft-gellens-mime-bucket-bis-09 RFC4281 RFC3839 RFC4393 RFC4337 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6381 RFC6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services D. McPherson R. Donnelly F. Scalzo October 2011 ASCII 25224 10 BGP SIDR RPKI security routing operations root TLD DNS DDOS peering RIR IRR MITM

This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment. This memo documents an Internet Best Current Practice.

 draft-ietf-grow-unique-origin-as-01 BCP0169 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6382 RFC6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE K. Shiomoto A. Farrel September 2011 ASCII 26456 11 RSVP-TE GMPLS MPLS-TE cross-connect data plane

The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.

End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.

This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-shiomoto-ccamp-switch-programming-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6383 RFC6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation I. van Beijnum October 2011 ASCII 38126 16 FTP SIIT NAT64

The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.

FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]

 draft-ietf-behave-ftp64-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6384 RFC6385 General Area Review Team (Gen-ART) Experiences M. Barnes A. Doria H. Alvestrand B. Carpenter October 2011 ASCII 53233 23 genart

The General Area Review Team (Gen-ART) has been doing reviews of Internet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-doria-genart-experience-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6385 RFC6386 VP8 Data Format and Decoding Guide J. Bankoski J. Koleszar L. Quillio J. Salonen P. Wilkins Y. Xu November 2011 ASCII 564613 304

This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-bankoski-vp8-bitstream-06 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6386 10.17487/RFC6386 RFC6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) A. Takacs L. Berger D. Caviglia D. Fedyk J. Meuric September 2011 ASCII 23329 11 rsvp resource reservation protocol

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. [STANDARDS-TRACK]

 draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03 RFC5467 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6387 RFC6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor I. Minei Editor K. Kompella B. Thomas November 2011 ASCII 86457 39

This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-p2mp-15 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6388 RFC6389 MPLS Upstream Label Assignment for LDP R. Aggarwal JL. Le Roux November 2011 ASCII 30935 13

This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-upstream-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6389 RFC6390 Guidelines for Considering New Performance Metric Development A. Clark B. Claise October 2011 ASCII 49930 23

This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice.

 draft-ietf-pmol-metrics-framework-12 BCP0170 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops pmol 10.17487/RFC6390 RFC6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network S. Bryant Editor C. Filsfils U. Drafz V. Kompella J. Regan S. Amante November 2011 ASCII 43848 19

Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.

This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]

 draft-ietf-pwe3-fat-pw-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6391 RFC6392 A Survey of In-Network Storage Systems R. Alimi Editor A. Rahman Editor Y. Yang Editor October 2011 ASCII 90978 44 P2P DECADE DECoupled Application Data Enroute

This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-decade-survey-06 INFORMATIONAL INFORMATIONAL IETF tsv decade http://www.rfc-editor.org/errata_search.php?rfc=6392 10.17487/RFC6392 RFC6393 Moving RFC 4693 to Historic M. Yevstifeyev September 2011 ASCII 4252 3 ION historic

This document moves RFC 4693 to Historic status. It also obsoletes RFC 4693. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-yevstifeyev-ion-report-07 RFC4693 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6393 RFC6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) R. Barnes October 2011 ASCII 29477 12 TLS PKIX

Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. [STANDARDS-TRACK]

 draft-ietf-dane-use-cases-05 INFORMATIONAL INFORMATIONAL IETF sec dane 10.17487/RFC6394 RFC6395 An Interface Identifier (ID) Hello Option for PIM S. Gulrajani S. Venaas October 2011 ASCII 11469 6

This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK]

 draft-ietf-pim-hello-intid-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6395 RFC6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format L. Blunk M. Karir C. Labovitz October 2011 ASCII 73982 33

This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. [STANDARDS-TRACK]

 draft-ietf-grow-mrt-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=6396 10.17487/RFC6396 RFC6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions T. Manderson October 2011 ASCII 16864 8 GPS Coordinates Terrestrial Coordinates BGP Speaker BGP Peer BGP Latitude BGP Longitude

This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. [STANDARDS-TRACK]

 draft-ietf-grow-geomrt-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC6397 RFC6398 IP Router Alert Considerations and Usage F. Le Faucheur Editor October 2011 ASCII 44914 19

The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers. This memo documents an Internet Best Current Practice.

 draft-ietf-intarea-router-alert-considerations-10 RFC2113 RFC2711 BCP0168 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6398 RFC6401 RSVP Extensions for Admission Priority F. Le Faucheur J. Polk K. Carlberg October 2011 ASCII 72343 32

Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer.

Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK]

 draft-ietf-tsvwg-emergency-rsvp-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6401 RFC6402 Certificate Management over CMS (CMC) Updates J. Schaad November 2011 ASCII 66722 37 cyrptographic message syntax

This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.

The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc5272-bis-08 RFC5272 RFC5273 RFC5274 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6402 10.17487/RFC6402 RFC6403 Suite B Profile of Certificate Management over CMS L. Zieglar S. Turner M. Peck November 2011 ASCII 36631 16 cmc suite b x.509 public key certificates

The United States government has published guidelines for "NSA Suite\0B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-suiteb-cmc-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6403 RFC6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures J. Seedorf S. Niccolini E. Chen H. Scholz November 2011 ASCII 54066 22 VoIP Security Threats multimedia Threat countermeasures SIP Interconnect VoIP peering Fraud prevention Network protection SIP RTP RTCP control plane user plane

The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements for SPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP and RTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. Each SSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-voipthreats-09 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6404 RFC6405 Voice over IP (VoIP) SIP Peering Use Cases A. Uzelac Editor Y. Lee Editor November 2011 ASCII 51354 23 VoIP SIP Peering

This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-voip-consolidated-usecases-18 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6405 RFC6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture D. Malas Editor J. Livingood Editor November 2011 ASCII 35032 16

This document defines a peering architecture for the Session Initiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-architecture-19 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6406 RFC6407 The Group Domain of Interpretation B. Weis S. Rowles T. Hardjono October 2011 ASCII 147102 64

This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. [STANDARDS-TRACK]

 draft-ietf-msec-gdoi-update-11 RFC3547 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=6407 10.17487/RFC6407 RFC6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage M. Jones J. Korhonen L. Morand November 2011 ASCII 32490 14 Services Field Peer Discovery

The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. [STANDARDS-TRACK]

 draft-ietf-dime-extended-naptr-09 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6408 RFC6409 Message Submission for Mail R. Gellens J. Klensin November 2011 ASCII 40153 20 Text Internationalization ASCII Unicode UTF-8

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay is unaffected, and continues to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

 draft-ietf-yam-rfc4409bis-03 RFC4409 STD0072 INTERNET STANDARD INTERNET STANDARD IETF app yam http://www.rfc-editor.org/errata_search.php?rfc=6409 10.17487/RFC6409 RFC6410 Reducing the Standards Track to Two Maturity Levels R. Housley D. Crocker E. Burger October 2011 ASCII 12619 6

This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.

 draft-housley-two-maturity-levels-09 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6410 10.17487/RFC6410 RFC6411 Applicability of Keying Methods for RSVP Security M. Behringer F. Le Faucheur B. Weis October 2011 ASCII 46072 19 RSVP authentication RSVP integrity Resource reservation protocol GDOI Group domain of interpretation

The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tsvwg-rsvp-security-groupkeying-11 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC6411 RFC6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII 51856 29

This document describes the terminology for benchmarking link-state Interior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-igp-dataplane-conv-term-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6412 RFC6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII 90935 42 Interior Gateway Protocol

This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-igp-dataplane-conv-meth-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6413 RFC6414 Benchmarking Terminology for Protection Performance S. Poretsky R. Papneja J. Karthik S. Vapiwala November 2011 ASCII 55563 33

This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-protection-term-09 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6414 RFC6415 Web Host Metadata E. Hammer-Lahav Editor B. Cook October 2011 ASCII 32018 16

This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. [STANDARDS-TRACK]

 draft-hammer-hostmeta-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6415 10.17487/RFC6415 RFC6416 RTP Payload Format for MPEG-4 Audio/Visual Streams M. Schmidt F. de Bont S. Doehla J. Kim October 2011 ASCII 77031 35 RFC3016 RTP MPEG-4 Audio Visual Video AAC HE AAC HE AAC v2 MPEG Surround

This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.

For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. [STANDARDS-TRACK]

 draft-ietf-payload-rfc3016bis-03 RFC3016 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6416 RFC6417 How to Contribute Research Results to Internet Standardization P. Eardley L. Eggert M. Bagnulo R. Winter November 2011 ASCII 33781 14

The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.

For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-weeb-research-to-internet-stds-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6417 RFC6418 Multiple Interfaces and Provisioning Domains Problem Statement M. Blanchet P. Seite November 2011 ASCII 50537 22 multi-homing MIF DNS DHCP

This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mif-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=6418 10.17487/RFC6418 RFC6419 Current Practices for Multiple-Interface Hosts M. Wasserman P. Seite November 2011 ASCII 51809 21 current practices multi-homing MIF

An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mif-current-practices-12 INFORMATIONAL INFORMATIONAL IETF int mif 10.17487/RFC6419 RFC6420 PIM Multi-Topology ID (MT-ID) Join Attribute Y. Cai H. Ou November 2011 ASCII 28310 13

This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. [STANDARDS-TRACK]

 draft-ietf-pim-mtid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6420 RFC6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) D. Nelson Editor November 2011 ASCII 27028 12

This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-radext-crypto-agility-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops radext 10.17487/RFC6421 RFC6422 Relay-Supplied DHCP Options T. Lemon Q. Wu December 2011 ASCII 16056 8 DHCPv6 Relay DHCPv6 option

DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.

This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-relay-supplied-options-09 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6422 RFC6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) H. Li L. Martini J. He F. Huang November 2011 ASCII 9343 5

This document describes the requirements for using the Generic Associated Channel Label (GAL) in pseudowires (PWs) in MPLS Transport Profile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. [STANDARDS-TRACK]

 draft-ietf-pwe3-mpls-tp-gal-in-pw-01 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6423 RFC6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels N. Bahadur K. Kompella G. Swallow November 2011 ASCII 48270 23 MPLS OAM lsp ping LSP-Ping

This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-lsp-ping-enhanced-dsmap-11 RFC4379 RFC7537 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6424 RFC6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping S. Saxena Editor G. Swallow Z. Ali A. Farrel S. Yasukawa T. Nadeau November 2011 ASCII 68437 28 p2mp

Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.

The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".

The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.

This document updates RFC 4379. [STANDARDS-TRACK]

 draft-ietf-mpls-p2mp-lsp-ping-18 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6425 10.17487/RFC6425 RFC6426 MPLS On-Demand Connectivity Verification and Route Tracing E. Gray N. Bahadur S. Boutros R. Aggarwal November 2011 ASCII 46539 22 lsp ping mpls tp mpls-tp

Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions in MPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-on-demand-cv-07 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6426 10.17487/RFC6426 RFC6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM) G. Swallow Editor A. Fulignoli Editor M. Vigoureux Editor S. Boutros D. Ward November 2011 ASCII 34069 17 mpls-oam

This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-fault-07 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6427 RFC6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile D. Allan Editor G. Swallow Editor J. Drake Editor November 2011 ASCII 44293 21 mpls-tp oam Operations Administration and Maintenance bfd bidirectional forwarding dectection

Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).

Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section.

This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-cc-cv-rdi-06 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6428 10.17487/RFC6428 RFC6429 TCP Sender Clarification for Persist Condition M. Bashyam M. Jethanandani A. Ramaiah December 2011 ASCII 14280 7 zero window probe denial of service (DoS) security vulnerability

This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tcpm-persist-07 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6429 RFC6430 Email Feedback Report Type Value: not-spam K. Li B. Leiba November 2011 ASCII 12678 7 arf abuse reporting format

This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK]

 draft-ietf-marf-not-spam-feedback-03 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6430 RFC6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) M. Boucadair P. Levis G. Bajko T. Savolainen T. Tsou November 2011 ASCII 33981 16 IPv4 Address Exhaustion IPv4 service continuity IPv6 A+P

This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-boucadair-pppext-portrange-option-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6431 RFC6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses R. Jesske L. Liess November 2011 ASCII 7487 4 cause code

Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. [STANDARDS-TRACK]

 draft-jesske-dispatch-update3326-reason-responses-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6432 RFC6433 Requirements for a Working Group Milestones Tool P. Hoffman November 2011 ASCII 15423 7 working group charter charter

The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Group charters. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document updates RFC 6292. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-milestones-tool-06 RFC6292 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6433 RFC6434 IPv6 Node Requirements E. Jankiewicz J. Loughney T. Narten December 2011 ASCII 64407 30 Internet Protocol Version 6 Internet Protocol IP

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6man-node-req-bis-11 RFC4294 INFORMATIONAL INFORMATIONAL IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6434 10.17487/RFC6434 RFC6435 MPLS Transport Profile Lock Instruct and Loopback Functions S. Boutros Editor S. Sivabalan Editor R. Aggarwal Editor M. Vigoureux Editor X. Dai Editor November 2011 ASCII 23862 12 oam operations administration and maintenance

Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.

This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.

This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-li-lb-08 RFC6371 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6435 10.17487/RFC6435 RFC6436 Rationale for Update to the IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang November 2011 ASCII 28062 13 ECMP LAG

Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6man-flow-update-07 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6436 RFC6437 IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang J. Rajahalme November 2011 ASCII 35269 15

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.

The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

 draft-ietf-6man-flow-3697bis-07 RFC3697 RFC2205 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6437 RFC6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels B. Carpenter S. Amante November 2011 ASCII 20999 9 ECMP LAG

The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]

 draft-ietf-6man-flow-ecmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6438 RFC6439 Routing Bridges (RBridges): Appointed Forwarders R. Perlman D. Eastlake Y. Li A. Banerjee F. Hu November 2011 ASCII 36978 15 trill TRansparent Interconnection of Lots of Links

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. Devices that implement TRILL are called "RBridges" (Routing Bridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]

 draft-ietf-trill-rbridge-af-05 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6439 RFC6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option G. Zorn Q. Wu Y. Wang December 2011 ASCII 10158 6 re-authentication handover LDN Discovery

In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.

This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]

 draft-ietf-hokey-ldn-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6440 RFC6441 Time to Remove Filters for Previously Unallocated IPv4 /8s L. Vegoda November 2011 ASCII 8646 5 bogons IPv4 martians filters

It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.

This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. This memo documents an Internet Best Current Practice.

 draft-ietf-grow-no-more-unallocated-slash8s-04 BCP0171 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6441 RFC6442 Location Conveyance for the Session Initiation Protocol J. Polk B. Rosen J. Peterson December 2011 ASCII 80795 35 sip geographic location location target

This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK]

 draft-ietf-sipcore-location-conveyance-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6442 10.17487/RFC6442 RFC6443 Framework for Emergency Calling Using Internet Multimedia B. Rosen H. Schulzrinne J. Polk A. Newton December 2011 ASCII 98096 38

The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ecrit-framework-13 RFC7852 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6443 RFC6444 Location Hiding: Problem Statement and Requirements H. Schulzrinne L. Liess H. Tschofenig B. Stark A. Kuett January 2012 ASCII 18495 9 emergency call privacy PSAP Location by Reference

The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.

This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ecrit-location-hiding-req-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6444 RFC6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute T. Nadeau Editor A. Koushik Editor R. Cetin Editor November 2011 ASCII 101627 53 mib frr MPLS-FRR-GENERAL-STD-MIB MPLS-FRR-ONE2ONE-STD-MIB MPLS-FRR-FACILITY-STD-MIB

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method. [STANDARDS-TRACK]

 draft-ietf-mpls-fastreroute-mib-21 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6445 RFC6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control A. Niemi K. Kiss S. Loreto January 2012 ASCII 57971 25 SIP events rate control

This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. [STANDARDS-TRACK]

 draft-ietf-sipcore-event-rate-control-09 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6446 RFC6447 Filtering Location Notifications in the Session Initiation Protocol (SIP) R. Mahy B. Rosen H. Tschofenig January 2012 ASCII 36577 19 geopriv location

This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). [STANDARDS-TRACK]

 draft-ietf-geopriv-loc-filters-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6447 RFC6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message R. Yount November 2011 ASCII 8369 4 credential

The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message. [STANDARDS-TRACK]

 draft-ietf-krb-wg-clear-text-cred-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6448 RFC6449 Complaint Feedback Loop Operational Recommendations J. Falk Editor November 2011 ASCII 75139 31 MAAWG ARF MARF feedback loop spam reporting

Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.

This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-jdfalk-maawg-cfblbcp-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6449 RFC6450 Multicast Ping Protocol S. Venaas December 2011 ASCII 59420 24 ssm asm ssmping asmping

The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping". [STANDARDS-TRACK]

 draft-ietf-mboned-ssmping-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6450 RFC6451 Location-to-Service Translation (LoST) Protocol Extensions A. Forte H. Schulzrinne December 2011 ASCII 45682 23 location-based services location GPS point of interest

An important class of location-based services answers the question, "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by". This document defines an Experimental Protocol for the Internet community.

 draft-forte-lost-extensions-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6451 RFC6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 P. Faltstrom Editor P. Hoffman Editor November 2011 ASCII 6817 4 DNS IDN

This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. [STANDARDS-TRACK]

 draft-faltstrom-5892bis-05 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6452 RFC6453 A URN Namespace for the Open Grid Forum (OGF) F. Dijkstra R. Hughes-Jones December 2011 ASCII 16678 9 identifier

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-dijkstra-urn-ogf-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6453 RFC6454 The Web Origin Concept A. Barth December 2011 ASCII 41363 20 same-origin policy security cross-origin

This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]

 draft-ietf-websec-origin-06 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6454 10.17487/RFC6454 RFC6455 The WebSocket Protocol I. Fette A. Melnikov December 2011 ASCII 162067 71 HyBi Working Group HYBI websocket

The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]

 draft-ietf-hybi-thewebsocketprotocol-17 RFC7936 PROPOSED STANDARD PROPOSED STANDARD IETF app hybi http://www.rfc-editor.org/errata_search.php?rfc=6455 10.17487/RFC6455 RFC6456 Multi-Segment Pseudowires in Passive Optical Networks H. Li R. Zheng A. Farrel November 2011 ASCII 27499 12 MPLS PSN PON G-PON XG-PON OMCI

This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN).

PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) Terminating Provider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.

This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or 10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.

This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-li-pwe3-ms-pw-pon-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6456 RFC6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering T. Takeda Editor A. Farrel December 2011 ASCII 29107 12 PCEP inter-layer traffic engineering MPLS GMPLS VNT

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS).

MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery".

This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-inter-layer-req-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6457 RFC6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) R. Stewart M. Tuexen K. Poon P. Lei V. Yasevich December 2011 ASCII 237112 115

This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tsvwg-sctpsocket-32 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC6458 RFC6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) J. Korhonen Editor J. Soininen B. Patil T. Savolainen G. Bajko K. Iisakkila January 2012 ASCII 84769 36 Transition Migration

The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-3gpp-eps-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6459 RFC6460 Suite B Profile for Transport Layer Security (TLS) M. Salter R. Housley January 2012 ASCII 31428 14 cryptographic algorithm policy

The United States government has published guidelines for "NSA Suite B Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-salter-rfc5430bis-01 RFC5430 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6460 10.17487/RFC6460 RFC6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements S. Channabasappa Editor January 2012 ASCII 36435 15 registry registry provisioning registrar destination group route group

This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry". This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-drinks-usecases-requirements-06 INFORMATIONAL INFORMATIONAL IETF rai drinks 10.17487/RFC6461 RFC6462 Report from the Internet Privacy Workshop A. Cooper January 2012 ASCII 55638 23

On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-privacy-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6462 RFC6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 J. Korhonen Editor S. Gundavelli H. Yokota X. Cui February 2012 ASCII 50702 22

This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. [STANDARDS-TRACK]

 draft-ietf-netext-redirect-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6463 RFC6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication J. Lennox Editor E. Ivov E. Marocco December 2011 ASCII 18809 9 ssrc-audio-level ssrc speech sound energy conference bridge

This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK]

 draft-ietf-avtext-client-to-mixer-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6464 RFC6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication E. Ivov Editor E. Marocco Editor J. Lennox December 2011 ASCII 30154 15 csrc-audio-level csrc speech sound energy conference bridge

This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]

 draft-ietf-avtext-mixer-to-client-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6465 RFC6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) G. Salgueiro December 2011 ASCII 11660 6 t.38 media

This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK]

 draft-salgueiro-mmusic-image-iana-registration-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6466 RFC6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) T. Kivinen December 2011 ASCII 21987 10 IPsec IKE mutual authentication credentials VPN gateway

This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.

 draft-kivinen-ipsecme-secure-password-framework-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6467 RFC6468 Sieve Notification Mechanism: SIP MESSAGE A. Melnikov B. Leiba K. Li February 2012 ASCII 21331 10 Sieve SIP notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-sip-message-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6468 RFC6469 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi K. Mishima S. Casner C. Bormann December 2011 ASCII 38041 18 DV/RTP real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. [STANDARDS-TRACK]

 draft-ietf-payload-rfc3189bis-03 RFC3189 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6469 RFC6470 Network Configuration Protocol (NETCONF) Base Notifications A. Bierman February 2012 ASCII 26361 15 XML

The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. [STANDARDS-TRACK]

 draft-ietf-netconf-system-notifications-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6470 10.17487/RFC6470 RFC6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices C. Lewis M. Sergeant January 2012 ASCII 49264 21 DNSBL policy

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-asrg-bcp-blacklists-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6471 RFC6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP W. Kumari K. Sriram December 2011 ASCII 10673 5 BGPv4 Operator RPKI Aggregation Route Origin

This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. This memo documents an Internet Best Current Practice.

 draft-ietf-idr-deprecate-as-sets-06 BCP0172 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6472 RFC6473 vCard KIND:application P. Saint-Andre December 2011 ASCII 9776 5 vCard

This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. [STANDARDS-TRACK]

 draft-ietf-vcarddav-kind-app-00 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC6473 RFC6474 vCard Format Extensions: Place of Birth, Place and Date of Death K. Li B. Leiba December 2011 ASCII 8884 6 contacts address-book personal-information

The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. [STANDARDS-TRACK]

 draft-ietf-vcarddav-birth-death-extensions-02 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6474 10.17487/RFC6474 RFC6475 Proxy Mobile IPv6 Management Information Base G. Keeni K. Koide S. Gundavelli R. Wakikawa May 2012 ASCII 132402 63

This memo defines a portion of the Proxy Mobile IPv6 Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. [STANDARDS-TRACK]

 draft-ietf-netlmm-pmipv6-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6475 10.17487/RFC6475 RFC6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS) P. Gutmann January 2012 ASCII 33186 15 authenticated data

This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. [STANDARDS-TRACK]

 draft-gutmann-cms-hmac-enc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6476 10.17487/RFC6476 RFC6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail A. Melnikov G. Lunt January 2012 ASCII 43492 21

A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-melnikov-mmhs-header-fields-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6477 RFC6478 Pseudowire Status for Static Pseudowires L. Martini G. Swallow G. Heron M. Bocci May 2012 ASCII 28285 13

This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allows PW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status-signaling information. [STANDARDS-TRACK]

 draft-ietf-pwe3-static-pw-status-10 RFC5885 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6478 RFC6479 IPsec Anti-Replay Algorithm without Bit Shifting X. Zhang T. Tsou January 2012 ASCII 16619 9

This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zhang-ipsecme-anti-replay-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6479 RFC6480 An Infrastructure to Support Secure Internet Routing M. Lepinski S. Kent February 2012 ASCII 62127 24 RPKI BGP ROA

This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sidr-arch-13 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6480 RFC6481 A Profile for Resource Certificate Repository Structure G. Huston R. Loomans G. Michaelson February 2012 ASCII 36117 15 rpki Resource Public Key Infrastructure

This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]

 draft-ietf-sidr-repos-struct-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6481 RFC6482 A Profile for Route Origin Authorizations (ROAs) M. Lepinski S. Kent D. Kong February 2012 ASCII 15745 9 RPKI BGP

This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]

 draft-ietf-sidr-roa-format-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6482 10.17487/RFC6482 RFC6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) G. Huston G. Michaelson February 2012 ASCII 19811 8 rpki bgp Resource Public Key Infrastructure

This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sidr-roa-validation-10 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6483 RFC6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) S. Kent D. Kong K. Seo R. Watro February 2012 ASCII 77855 35 Certification Practice Statement CPS

This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. This memo documents an Internet Best Current Practice.

 draft-ietf-sidr-cp-17 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6484 RFC6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) G. Huston February 2012 ASCII 11377 6

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK]

 draft-ietf-sidr-rpki-algs-05 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6485 10.17487/RFC6485 RFC6486 Manifests for the Resource Public Key Infrastructure (RPKI) R. Austein G. Huston S. Kent M. Lepinski February 2012 ASCII 42913 19

This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK]

 draft-ietf-sidr-rpki-manifests-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6486 RFC6487 A Profile for X.509 PKIX Resource Certificates G. Huston G. Michaelson R. Loomans February 2012 ASCII 69150 32 rpki Resource Public Key Infrastructure Internet Number Resources INR

This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]

 draft-ietf-sidr-res-certs-22 RFC7318 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6487 10.17487/RFC6487 RFC6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI) M. Lepinski A. Chi S. Kent February 2012 ASCII 25130 13 ROA manifest GhostBusters

This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]

 draft-ietf-sidr-signed-object-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6488 10.17487/RFC6488 RFC6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) G. Huston G. Michaelson S. Kent February 2012 ASCII 23060 10 RPKI

This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. This memo documents an Internet Best Current Practice.

 draft-ietf-sidr-keyroll-08 BCP0174 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6489 10.17487/RFC6489 RFC6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent February 2012 ASCII 15004 7 tal

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). [STANDARDS-TRACK]

 draft-ietf-sidr-ta-07 RFC7730 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6490 RFC6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA T. Manderson L. Vegoda S. Kent February 2012 ASCII 23662 12 sidr rpki iana as0 as 0 roa

This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. [STANDARDS-TRACK]

 draft-ietf-sidr-iana-objects-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6491 RFC6492 A Protocol for Provisioning Resource Certificates G. Huston R. Loomans B. Ellacott R. Austein February 2012 ASCII 65896 32 RPKI

This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. [STANDARDS-TRACK]

 draft-ietf-sidr-rescerts-provisioning-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6492 RFC6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record R. Bush February 2012 ASCII 15491 8 RPKI Resource Certificate Human Contact vCard

In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]

 draft-ietf-sidr-ghostbusters-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6493 10.17487/RFC6493 RFC6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) R. Gagliano S. Krishnan A. Kukec February 2012 ASCII 26425 12 RPKI ND

SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. [STANDARDS-TRACK]

 draft-ietf-csi-send-cert-10 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi http://www.rfc-editor.org/errata_search.php?rfc=6494 10.17487/RFC6494 RFC6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields R. Gagliano S. Krishnan A. Kukec February 2012 ASCII 10575 5

SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). [STANDARDS-TRACK]

 draft-ietf-csi-send-name-type-registry-06 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi 10.17487/RFC6495 RFC6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) S. Krishnan J. Laganier M. Bonola A. Garcia-Martinez February 2012 ASCII 57746 24 SPND CGA Mobile IPv6 MIPv6 Proxy Mobile IPv6 PMIPv6

SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-csi-proxy-send-05 EXPERIMENTAL EXPERIMENTAL IETF int csi 10.17487/RFC6496 RFC6497 BCP 47 Extension T - Transformed Content M. Davis A. Phillips Y. Umaoka C. Falk February 2012 ASCII 32915 15 locale

This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-davis-t-langtag-ext-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6497 10.17487/RFC6497 RFC6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package J. Stone R. Kumar F. Andreasen February 2012 ASCII 92301 47

This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy, and FEC. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-stone-mgcp-vbd-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6498 RFC6501 Conference Information Data Model for Centralized Conferencing (XCON) O. Novo G. Camarillo D. Morgan J. Urpalainen March 2012 ASCII 180210 94

RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK]

 draft-ietf-xcon-common-data-model-32 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6501 RFC6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON) G. Camarillo S. Srinivasan R. Even J. Urpalainen March 2012 ASCII 26245 14

This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. [STANDARDS-TRACK]

 draft-ietf-xcon-event-package-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6502 RFC6503 Centralized Conferencing Manipulation Protocol M. Barnes C. Boulton S. Romano H. Schulzrinne March 2012 ASCII 257058 119 conference user ad hoc conference sidebar conference scheduled conference

The Centralized Conferencing Manipulation Protocol (CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. [STANDARDS-TRACK]

 draft-ietf-xcon-ccmp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=6503 10.17487/RFC6503 RFC6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples M. Barnes L. Miniero R. Presta S P. Romano March 2012 ASCII 186366 78

This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-xcon-examples-10 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC6504 RFC6505 A Mixer Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton March 2012 ASCII 187038 89 conference mixer

This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers [STANDARDS-TRACK]

 draft-ietf-mediactrl-mixer-control-package-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6505 10.17487/RFC6505 RFC6506 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem February 2012 ASCII 41992 20 Routing security

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. [STANDARDS-TRACK]

 draft-ietf-ospf-auth-trailer-ospfv3-11 RFC7166 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6506 10.17487/RFC6506 RFC6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) M. Groves February 2012 ASCII 36233 17

Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-groves-eccsi-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6507 RFC6508 Sakai-Kasahara Key Encryption (SAKKE) M. Groves February 2012 ASCII 42700 21

In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-groves-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6508 RFC6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY) M. Groves February 2012 ASCII 47389 21

This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-groves-mikey-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6509 RFC6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects L. Berger G. Swallow February 2012 ASCII 16650 8

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. [STANDARDS-TRACK]

 draft-ietf-ccamp-attribute-bnf-02 RFC4875 RFC5420 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6510 RFC6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths Z. Ali G. Swallow R. Aggarwal February 2012 ASCII 21767 10

There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6511 RFC6512 Using Multipoint LDP When the Backbone Has No Route to the Root IJ. Wijnands E. Rosen M. Napierala N. Leymann February 2012 ASCII 24352 12

The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core. This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. [STANDARDS-TRACK]

 draft-ietf-mpls-mldp-recurs-fec-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6512 RFC6513 Multicast in MPLS/BGP IP VPNs E. Rosen Editor R. Aggarwal Editor February 2012 ASCII 213780 88

In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]

 draft-ietf-l3vpn-2547bis-mcast-10 RFC7582 RFC7900 RFC7988 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6513 10.17487/RFC6513 RFC6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs R. Aggarwal E. Rosen T. Morin Y. Rekhter February 2012 ASCII 145112 59

This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]

 draft-ietf-l3vpn-2547bis-mcast-bgp-08 RFC6515 RFC6625 RFC7385 RFC7441 RFC7582 RFC7899 RFC7900 RFC7902 RFC7988 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6514 10.17487/RFC6514 RFC6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN R. Aggarwal E. Rosen February 2012 ASCII 17550 8 mvpn mcast-vpn multicast-vpn

To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mvpn-infra-addrs-05 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6515 RFC6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages Y. Cai E. Rosen Editor I. Wijnands February 2012 ASCII 11992 6

The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider Multicast Service Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mvpn-spmsi-joins-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6516 RFC6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution T. Morin Editor B. Niven-Jenkins Editor Y. Kamite R. Zhang N. Leymann N. Bitar February 2012 ASCII 102395 41 mpls vpn multicast l3vpn bgp pim p2mp ldp rsvp-te

More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.

To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l3vpn-mvpn-considerations-06 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC6517 RFC6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines G. Lebovitz M. Bhatia February 2012 ASCII 76782 30 MAC hash security securing secure authorization protection harden hardening infrastructure router crypto cryptography cryptographic roadmap guide guideline message framework key keys management protocol KMP key management protocol,

This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-karp-design-guide-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6518 RFC6519 RADIUS Extensions for Dual-Stack Lite R. Maglione A. Durand February 2012 ASCII 22574 11 IPv6 tunnel attribute

Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK]

 draft-ietf-softwire-dslite-radius-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6519 10.17487/RFC6519 RFC6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension R. Seggelmann M. Tuexen M. Williams February 2012 ASCII 16858 9 tls/dtls

This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]

 draft-ietf-tls-dtls-heartbeat-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC6520 RFC6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks A. Makela J. Korhonen February 2012 ASCII 123256 53 mobile router mobile network prefix correspondent router

This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mip4-nemo-haaro-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC6521 RFC6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages M. Kucherawy Editor January 2012 ASCII 15715 9 MIME Multipurpose Internet Mail Extensions

The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.

This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". [STANDARDS-TRACK]

 draft-ietf-appsawg-rfc3462bis-04 RFC3462 RFC6533 STD0073 INTERNET STANDARD INTERNET STANDARD IETF app appsawg 10.17487/RFC6522 RFC6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration R. Stewart M. Tuexen P. Lei February 2012 ASCII 72734 34

Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-strrst-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6525 RFC6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream B. Claise P. Aitken A. Johnson G. Muenz March 2012 ASCII 51285 23

This document specifies an extension to the specifications in RFC 5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol).

When implemented at both the Exporting Process and Collecting Process, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. [STANDARDS-TRACK]

 draft-ietf-ipfix-export-per-sctp-stream-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6526 RFC6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3) K. Tata March 2012 ASCII 62639 31 management information base

This specification defines a portion of the Management Information Base (MIB) for use with network management based on the Simple Network Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787. [STANDARDS-TRACK]

 draft-ietf-vrrp-unified-mib-10 RFC2787 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6527 10.17487/RFC6527 RFC6528 Defending against Sequence Number Attacks F. Gont S. Bellovin February 2012 ASCII 26917 12 TCP security TCP Sequence Numbers Sequence Number Randomization obfuscation TCP vulnerabilities

This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc1948bis-02 RFC1948 RFC0793 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6528 RFC6529 Host/Host Protocol for the ARPA Network A. McKenzie S. Crocker April 2012 ASCII 69527 34

This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series. This document is not an Internet Standards Track specification; it is published for the historical record.

 draft-mckenzie-arpanet-host-host-protocol-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6529 RFC6530 Overview and Framework for Internationalized Email J. Klensin Y. Ko February 2012 ASCII 64371 26 SMTP Email I18n Internationalization SMTPUTF8

Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]

 draft-ietf-eai-frmwrk-4952bis-12 RFC4952 RFC5504 RFC5825 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6530 RFC6531 SMTP Extension for Internationalized Email J. Yao W. Mao February 2012 ASCII 40977 18 SMTP Email I18n Internationalization SMTPUTF8

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]

 draft-ietf-eai-rfc5336bis-16 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6531 RFC6532 Internationalized Email Headers A. Yang S. Steele N. Freed February 2012 ASCII 22725 11

Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.

This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]

 draft-ietf-eai-rfc5335bis-13 RFC5335 RFC2045 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6532 10.17487/RFC6532 RFC6533 Internationalized Delivery Status and Disposition Notifications T. Hansen Editor C. Newman A. Melnikov February 2012 ASCII 37990 19 dsn

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK]

 draft-ietf-eai-rfc5337bis-dsn-06 RFC5337 RFC3461 RFC3464 RFC3798 RFC6522 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6533 RFC6534 Loss Episode Metrics for IP Performance Metrics (IPPM) N. Duffield A. Morton J. Sommers May 2012 ASCII 45147 21

The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts. However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]

 draft-ietf-ippm-loss-episode-metrics-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6534 RFC6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) B. Huang H. Deng T. Savolainen February 2012 ASCII 54452 25 NAT NAT46 DNS DNS46 translation IPv4 applications IPv6 ENR

Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK]

 draft-ietf-behave-v4v6-bih-09 RFC2767 RFC3338 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6535 10.17487/RFC6535 RFC6536 Network Configuration Protocol (NETCONF) Access Control Model A. Bierman M. Bjorklund March 2012 ASCII 90803 49 NETCONF YANG XML

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]

 draft-ietf-netconf-access-control-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6536 10.17487/RFC6536 RFC6537 Host Identity Protocol Distributed Hash Table Interface J. Ahrenholz February 2012 ASCII 49467 20 HIP Host Identity Protocol DHT DIstributed Hash Table HIT Host Identity Tag resolution service

This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host- Identity-Tag-to-address lookup service. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-hiprg-dht-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6537 RFC6538 The Host Identity Protocol (HIP) Experiment Report T. Henderson A. Gurtov March 2012 ASCII 88376 35 Security ID/locator split IPsec Research

This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-hip-experiment-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6538 RFC6539 IBAKE: Identity-Based Authenticated Key Exchange V. Cakulev G. Sundaram I. Broustis March 2012 ASCII 28913 13 ibe identity based encryption

Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management. The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cakulev-ibake-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6539 RFC6540 IPv6 Support Required for All IP-Capable Nodes W. George C. Donley C. Liljenstolpe L. Howard April 2012 ASCII 12883 6 IPv4 requirement

Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. This memo documents an Internet Best Current Practice.

 draft-ietf-intarea-ipv6-required-02 BCP0177 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6540 RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures M. Kucherawy February 2012 ASCII 31655 16 Authentication Reputation

This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. This document defines an Experimental Protocol for the Internet community.

 draft-kucherawy-dkim-atps-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6541 RFC6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility S. Emery March 2012 ASCII 11080 6

Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121). This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. [STANDARDS-TRACK]

 draft-ietf-krb-wg-gss-cb-hash-agility-10 RFC4121 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6542 RFC6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 S. Gundavelli May 2012 ASCII 10565 5

Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes. This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required. This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose. This document also updates RFC 5213. [STANDARDS-TRACK]

 draft-gundavelli-v6ops-pmipv6-address-reservations-06 RFC5213 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6543 RFC6544 TCP Candidates with Interactive Connectivity Establishment (ICE) J. Rosenberg A. Keranen B. B. Lowekamp A. B. Roach March 2012 ASCII 72318 29 ICE TCP NAT NAT traversal

Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK]

 draft-ietf-mmusic-ice-tcp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6544 10.17487/RFC6544 RFC6545 Real-time Inter-network Defense (RID) K. Moriarty April 2012 ASCII 203100 84 incident response incident coordination incident handling incident communication

Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC 6045. [STANDARDS-TRACK]

 draft-ietf-mile-rfc6045-bis-11 RFC6045 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6545 10.17487/RFC6545 RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS B. Trammell April 2012 ASCII 19114 8 Coordinated Incident Response CSIRT Incident Object Description Exchange Format IODEF

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. [STANDARDS-TRACK]

 draft-ietf-mile-rfc6046-bis-09 RFC6046 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6546 10.17487/RFC6546 RFC6547 RFC 3627 to Historic Status W. George February 2012 ASCII 4917 3 IPv6 /127 point-to-point address inter-router links

This document moves "Use of /127 Prefix Length Between Routers Considered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter- Router Links" (RFC 6164). A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict. This document links the two RFCs so that the IETF's updated guidance on this topic is clearer. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6man-3627-historic-01 RFC3627 RFC6164 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6547 RFC6548 Independent Submission Editor Model N. Brownlee Editor IAB June 2012 ASCII 9298 5 Independent Stream Editor

This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administrative Oversight Committee (IAOC). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-ise-model-07 RFC5620 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6548 RFC6549 OSPFv2 Multi-Instance Extensions A. Lindem A. Roy S. Mirtorabi March 2012 ASCII 16639 9 Instance ID

OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.

This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.

This document updates RFC 2328. [STANDARDS-TRACK]

 draft-ietf-ospf-multi-instance-09 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6549 10.17487/RFC6549 RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks T. Winter Editor P. Thubert Editor A. Brandt J. Hui R. Kelsey P. Levis K. Pister R. Struik JP. Vasseur R. Alexander March 2012 ASCII 360651 157 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph

Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]

 draft-ietf-roll-rpl-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6550 10.17487/RFC6550 RFC6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks JP. Vasseur Editor M. Kim Editor K. Pister N. Dejean D. Barthel March 2012 ASCII 67707 30 RPL ROLL LLN Constrained based routing,

Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]

 draft-ietf-roll-routing-metrics-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6551 10.17487/RFC6551 RFC6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) P. Thubert Editor March 2012 ASCII 30419 14 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph RPL

The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.

This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]

 draft-ietf-roll-of0-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6552 RFC6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams J. Hui JP. Vasseur March 2012 ASCII 19093 9 LLN LLNs Trickle

The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]

 draft-ietf-6man-rpl-option-06 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6553 RFC6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Hui JP. Vasseur D. Culler V. Manral March 2012 ASCII 30270 13 LLN LLNs

In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]

 draft-ietf-6man-rpl-routing-header-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6554 RFC6555 Happy Eyeballs: Success with Dual-Stack Hosts D. Wing A. Yourtchenko April 2012 ASCII 34048 15

When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]

 draft-ietf-v6ops-happy-eyeballs-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6555 10.17487/RFC6555 RFC6556 Testing Eyeball Happiness F. Baker April 2012 ASCII 23727 10 test methodology IPv4 IPv6 session startup metrics

The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-baker-bmwg-testing-eyeball-happiness-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6556 RFC6557 Procedures for Maintaining the Time Zone Database E. Lear P. Eggert February 2012 ASCII 18469 9

Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. This memo documents an Internet Best Current Practice.

 draft-lear-iana-timezone-database-05 BCP0175 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6557 RFC6558 Sieve Extension for Converting Messages before Delivery A. Melnikov B. Leiba K. Li March 2012 ASCII 17152 8 Sieve CONVERT

This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK]

 draft-ietf-sieve-convert-06 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6558 RFC6559 A Reliable Transport Mechanism for PIM D. Farinacci IJ. Wijnands S. Venaas M. Napierala March 2012 ASCII 70159 29

This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pim-port-09 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6559 RFC6560 One-Time Password (OTP) Pre-Authentication G. Richards April 2012 ASCII 95896 43

The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password (OTP) authentication. [STANDARDS-TRACK]

 draft-ietf-krb-wg-otp-preauth-21 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6560 RFC6561 Recommendations for the Remediation of Bots in ISP Networks J. Livingood N. Mody M. O'Reirdan March 2012 ASCII 74562 29 ISP Internet Service Provider Bot Botnet Remediation malware notification

This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-oreirdan-mody-bot-remediation-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6561 10.17487/RFC6561 RFC6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP C. Perkins JM. Valin March 2012 ASCII 14288 6 vbr

This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. [STANDARDS-TRACK]

 draft-ietf-avtcore-srtp-vbr-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6562 RFC6563 Moving A6 to Historic Status S. Jiang D. Conrad B. Carpenter March 2012 ASCII 16654 8

This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-jiang-a6-to-historic-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6563 RFC6564 A Uniform Format for IPv6 Extension Headers S. Krishnan J. Woodyatt E. Kline J. Hoagland M. Bhatia April 2012 ASCII 12879 6

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]

 draft-ietf-6man-exthdr-06 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6564 10.17487/RFC6564 RFC6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol P. Pillay-Esnault P. Moyer J. Doyle E. Ertekin M. Lundberg June 2012 ASCII 43217 20 L3VPN BGP/MPLS VPN

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 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. [STANDARDS-TRACK]

 draft-ietf-l3vpn-ospfv3-pece-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6565 RFC6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments Y. Lee Editor G. Bernstein Editor D. Li G. Martinelli March 2012 ASCII 68851 31

As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.

This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to support Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation. This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-wson-impairments-10 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6566 RFC6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP A. Johnston L. Liess April 2012 ASCII 25981 11

This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-cuss-sip-uui-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai cuss 10.17487/RFC6567 RFC6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) E. Kim D. Kaspar JP. Vasseur April 2012 ASCII 64728 28

This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6lowpan-usecases-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6568 RFC6569 Guidelines for Development of an Audio Codec within the IETF JM. Valin S. Borilin K. Vos C. Montgomery R. Chen March 2012 ASCII 33718 14 audio codec speech codec

This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-codec-guidelines-08 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6569 RFC6570 URI Template J. Gregorio R. Fielding M. Hadley M. Nottingham D. Orchard March 2012 ASCII 79813 34 template Uniform Resource Identifier URI URI Template Internationalized Resource Identifier IRI IRI Template

A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]

 draft-gregorio-uritemplate-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6570 10.17487/RFC6570 RFC6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks C. Filsfils Editor P. Francois Editor M. Shand B. Decraene J. Uttaro N. Leymann M. Horneffer June 2012 ASCII 71363 35 IP Fast Reroute Routing Convergence Network Topology IS-IS OSPF

In this document, we analyze the applicability of the Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rtgwg-lfa-applicability-06 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=6571 10.17487/RFC6571 RFC6572 RADIUS Support for Proxy Mobile IPv6 F. Xia B. Sarikaya J. Korhonen Editor S. Gundavelli D. Damic June 2012 ASCII 74903 36

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 (MN) 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 interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. [STANDARDS-TRACK]

 draft-ietf-netext-radius-pmip6-08 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6572 RFC6573 The Item and Collection Link Relations M. Amundsen April 2012 ASCII 7492 5

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-amundsen-item-and-collection-link-relations-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6573 RFC6574 Report from the Smart Object Workshop H. Tschofenig J. Arkko April 2012 ASCII 74281 32 Smart Objects Internet of Things

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-smart-object-workshop-10 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6574 RFC6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs H. Shah Editor E. Rosen Editor G. Heron Editor V. Kompella Editor June 2012 ASCII 65881 28

The Virtual Private Wire Service (VPWS), detailed in RFC 4664, 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 or 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 "Address Resolution Protocol (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. [STANDARDS-TRACK]

 draft-ietf-l2vpn-arp-mediation-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6575 RFC6576 IP Performance Metrics (IPPM) Standard Advancement Testing R. Geib Editor A. Morton R. Fardid A. Steinmitz March 2012 ASCII 84447 37 inter-operability equivalence measurement compliance metric

This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is an Internet Best Current Practice.

 draft-ietf-ippm-metrictest-05 BCP0176 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6576 10.17487/RFC6576 RFC6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results M. Kucherawy March 2012 ASCII 8173 5 SPF Authentication

This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the Sender Policy Framework (SPF) specification. [STANDARDS-TRACK]

 draft-kucherawy-authres-spf-erratum-02 RFC7001 RFC5451 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6577 RFC6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) C. Daboo A. Quillaud March 2012 ASCII 55731 29 sync-collection sync-token

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. [STANDARDS-TRACK]

 draft-daboo-webdav-sync-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6578 RFC6579 The 'disclosure' Link Relation Type M. Yevstifeyev March 2012 ASCII 7427 5

This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. [STANDARDS-TRACK]

 draft-yevstifeyev-disclosure-relation-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6579 RFC6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols M. Ko D. Black April 2012 ASCII 17613 10

The original RFCs that specified the Remote Direct Data Placement (RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. [STANDARDS-TRACK]

 draft-ietf-storm-rddp-registries-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm http://www.rfc-editor.org/errata_search.php?rfc=6580 10.17487/RFC6580 RFC6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment A. Kanevsky Editor C. Bestler Editor R. Sharp S. Wise April 2012 ASCII 57766 25

This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. [STANDARDS-TRACK]

 draft-ietf-storm-mpa-peer-connect-09 RFC5043 RFC5044 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6581 RFC6582 The NewReno Modification to TCP's Fast Recovery Algorithm T. Henderson S. Floyd A. Gurtov Y. Nishida April 2012 ASCII 35413 16 congestion avoidance congestion control fast retransmit

RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc3782-bis-05 RFC3782 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6582 RFC6583 Operational Neighbor Discovery Problems I. Gashinsky J. Jaeggli W. Kumari March 2012 ASCII 29480 12

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 (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. 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 the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK]

 draft-ietf-v6ops-v6nd-problems-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6583 RFC6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca April 2012 ASCII 67466 30 TESLA FLUTE

This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]

 draft-ietf-rmt-simple-auth-for-alc-norm-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC6584 RFC6585 Additional HTTP Status Codes M. Nottingham R. Fielding April 2012 ASCII 17164 10 Hypertext Transfer Protocol

This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]

 draft-nottingham-http-new-status-04 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6585 RFC6586 Experiences from an IPv6-Only Network J. Arkko A. Keranen April 2012 ASCII 52062 21 IPv6 NAT64

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-arkko-ipv6-only-experience-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6586 RFC6587 Transmission of Syslog Messages over TCP R. Gerhards C. Lonvick April 2012 ASCII 21006 11 SYSLOG SYSLOG transport TCP

There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. This memo describes how TCP has been used as a transport for syslog messages. This document defines a Historic Document for the Internet community.

 draft-gerhards-syslog-plain-tcp-14 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6587 RFC6588 A URN Namespace for ucode C. Ishikawa April 2012 ASCII 14382 8

This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places. ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ishikawa-yrpunl-ucode-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6588 10.17487/RFC6588 RFC6589 Considerations for Transitioning Content to IPv6 J. Livingood April 2012 ASCII 68822 27

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6589 RFC6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports J. Falk Editor M. Kucherawy Editor April 2012 ASCII 15927 8 ARF MARF feedback loop spam reporting

Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. [STANDARDS-TRACK]

 draft-ietf-marf-redaction-08 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6590 RFC6591 Authentication Failure Reporting Using the Abuse Reporting Format H. Fontana April 2012 ASCII 32378 16 auth auth failure dkim spf AFRF ARF

This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]

 draft-ietf-marf-authfailure-report-10 RFC6692 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6591 RFC6592 The Null Packet C. Pignataro April 1 2012 ASCII 11036 6

The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-pignataro-the-null-packet-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6592 RFC6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) C. Pignataro J. Clarke G. Salgueiro April 1 2012 ASCII 16752 8

With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.

This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.

 draft-joegonzalocarlos-service-hide-n-seek-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6593 RFC6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records O. Sury April 2012 ASCII 17418 9 DNS Domain Name System SSHFP SHA-256 Secure Shell ECDSA

This document updates the IANA registries in RFC 4255, which defines SSHFP, a DNS Resource Record (RR) that contains a standard Secure Shell (SSH) key fingerprint used to verify SSH host keys using DNS Security Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic Curve Digital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm in SSHFP Resource Records. [STANDARDS-TRACK]

 draft-os-ietf-sshfp-ecdsa-sha2-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6594 RFC6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) K. Wierenga E. Lear S. Josefsson April 2012 ASCII 49522 22 Generic Security Service Application Program Interface SAML 2.0

The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The 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 mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]

 draft-ietf-kitten-sasl-saml-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC6595 RFC6596 The Canonical Link Relation M. Ohye J. Kupke April 2012 ASCII 13800 8

RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ohye-canonical-link-relation-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6596 RFC6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data J. Downs Editor J. Arbeiter Editor April 2012 ASCII 27339 13 KLV

This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP). [STANDARDS-TRACK]

 draft-ietf-payload-rtp-klv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6597 RFC6598 IANA-Reserved IPv4 Prefix for Shared Address Space J. Weil V. Kuarsingh C. Donley C. Liljenstolpe M. Azinger April 2012 ASCII 22055 11 shared block CGN NAT Carrier Grade NAT private address space service provider address translation non-globally routable non-overlapping address space

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).

Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.

This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice.

 draft-weil-shared-transition-space-request-15 RFC5735 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6598 RFC6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks G. Ash Editor D. McDysan April 2012 ASCII 82005 34

This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. This document defines an Experimental Protocol for the Internet community.

 draft-ash-gcac-algorithm-spec-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6601 RFC6602 Bulk Binding Update Support for Proxy Mobile IPv6 F. Abinader Editor S. Gundavelli Editor K. Leung S. Krishnan D. Premec May 2012 ASCII 56348 23 Proxy Mobile IPv6 PMIPv6 bulk registrations MN group ID

For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. [STANDARDS-TRACK]

 draft-ietf-netext-bulk-re-registration-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6602 RFC6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation J. Korhonen Editor T. Savolainen S. Krishnan O. Troan May 2012 ASCII 19485 10 OPTION_PD_EXCLUDE

This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK]

 draft-ietf-dhc-pd-exclude-04 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6603 10.17487/RFC6603 RFC6604 xNAME RCODE and Status Bits Clarification D. Eastlake 3rd April 2012 ASCII 10790 5 DNS DNSSEC CNAME DNAME Domain Name response code canonical name

The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. [STANDARDS-TRACK]

 draft-ietf-dnsext-xnamercode-00 RFC1035 RFC2308 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6604 RFC6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC P. Hoffman W.C.A. Wijngaards April 2012 ASCII 14332 8 dnskey algorithm ds hash algo crypto DNS key DNSKEY algorithm DS digest hash cryptography SHA-384 ECDSAP256SHA256 ECDSAP384SHA384

This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]

 draft-ietf-dnsext-ecdsa-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6605 RFC6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing E. Kim D. Kaspar C. Gomez C. Bormann May 2012 ASCII 75436 32 WSN Sensor Network Wireless Sensor Network WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing ieee 802.15.4 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

IPv6 over Low-Power Wireless Personal Area Networks (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 defines 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 6LoWPANs, 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 that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6lowpan-routing-requirements-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6606 RFC6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 K. Kinnear R. Johnson M. Stapp April 2012 ASCII 60312 26 draft-ietf-dhc-vpn-option-15 RFC3046 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6607 RFC6608 Subcodes for BGP Finite State Machine Error J. Dong M. Chen A. Suryanarayana May 2012 ASCII 8612 5

This document defines several subcodes for the BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. This document updates RFC 4271. [STANDARDS-TRACK]

 draft-ietf-idr-fsm-subcode-03 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6608 RFC6609 Sieve Email Filtering: Include Extension C. Daboo A. Stone May 2012 ASCII 26142 14

The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. [STANDARDS-TRACK]

 draft-ietf-sieve-include-15 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6609 RFC6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6) H. Jang A. Yegin K. Chowdhury J. Choi T. Lemon May 2012 ASCII 36878 16

This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. [STANDARDS-TRACK]

 draft-ietf-mip6-hiopt-18 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6610 RFC6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario K. Chowdhury Editor A. Yegin May 2012 ASCII 27152 12

Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. [STANDARDS-TRACK]

 draft-ietf-mip6-bootstrapping-integrated-dhc-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6611 RFC6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues G. Giaretta Editor May 2012 ASCII 40116 18

The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netlmm-mip-interactions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6612 RFC6613 RADIUS over TCP A. DeKok May 2012 ASCII 37646 16 Remote Authentication Dial-In User Server Transmission Control Protocol RADIUS/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 confidentiality and security. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-radext-tcp-transport-09 RFC7930 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6613 RFC6614 Transport Layer Security (TLS) Encryption for RADIUS S. Winter M. McCauley S. Venaas K. Wierenga May 2012 ASCII 48004 22 RADIUS AAA Security Reliability Remote Authentication Dial-In User Server

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. [STANDARDS-TRACK]

 draft-ietf-radext-radsec-12 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6614 RFC6615 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz June 2012 ASCII 137274 65 IPFIX MIB Filtering Sampling Selection

This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors, including basic configuration information. [STANDARDS-TRACK]

 draft-ietf-ipfix-rfc5815bis-03 RFC5815 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6615 RFC6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID E. Lear H. Tschofenig H. Mauldin S. Josefsson May 2012 ASCII 39323 18 web single sign-on

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. [STANDARDS-TRACK]

 draft-ietf-kitten-sasl-openid-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC6616 RFC6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) D. Harkins June 2012 ASCII 53805 24 Authenticated Key Exchange Dictionary Attack

This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. This document defines an Experimental Protocol for the Internet community.

 draft-harkins-ipsecme-spsk-auth-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6617 RFC6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent J. Korhonen Editor B. Patil H. Tschofenig D. Kroeselberg May 2012 ASCII 87475 38 Mobile IPv6 Security

Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2. 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 MN and HA. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mext-mip6-tls-05 EXPERIMENTAL EXPERIMENTAL IETF int mext 10.17487/RFC6618 RFC6619 Scalable Operation of Address Translators with Per-Interface Bindings J. Arkko L. Eggert M. Townsley June 2012 ASCII 18590 9 NAT IPv4 IPv6

This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. [STANDARDS-TRACK]

 draft-arkko-dual-stack-extra-lite-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6619 RFC6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses E. Nordmark M. Bagnulo E. Levy-Abegnoli May 2012 ASCII 84010 35 ingress filtering BCP38

This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. [STANDARDS-TRACK]

 draft-ietf-savi-fcfs-14 PROPOSED STANDARD PROPOSED STANDARD IETF int savi http://www.rfc-editor.org/errata_search.php?rfc=6620 10.17487/RFC6620 RFC6621 Simplified Multicast Forwarding J. Macker Editor May 2012 ASCII 139674 55 routing flooding optimized flooding CDS connected dominating set duplicate packet detection hash-based packet detection MPR MPR-CDS E-CDS edge mobility mobile ad hoc mesh network

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-smf-14 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6621 10.17487/RFC6621 RFC6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen May 2012 ASCII 48083 21 packetbb NHDP OLSRv2 security integrity routing

This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. [STANDARDS-TRACK]

 draft-ietf-manet-packetbb-sec-09 RFC7182 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6622 RFC6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package E. Burger May 2012 ASCII 15756 6

This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, as described in RFC 6231. [STANDARDS-TRACK]

 draft-ietf-mediactrl-6231-iana-00 RFC6231 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6623 RFC6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling K. Kompella B. Kothari R. Cherukuri May 2012 ASCII 64693 26 BGP L2VPN discovery signaling pseudowire

Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-kompella-l2vpn-l2vpn-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6624 RFC6625 Wildcards in Multicast VPN Auto-Discovery Routes E. Rosen Editor Y. Rekhter Editor W. Hendrickx R. Qiu May 2012 ASCII 35348 17 mvpn

In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mvpn-wildcards-02 RFC6514 RFC7582 RFC7900 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6625 RFC6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4) G. Tsirtsis V. Park V. Narayanan K. Leung May 2012 ASCII 9270 5 mobile router

The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism for NEMOv4. [STANDARDS-TRACK]

 draft-ietf-mip4-nemov4-dynamic-06 RFC5177 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6626 RFC6627 Overview of Pre-Congestion Notification Encoding G. Karagiannis K. Chan T. Moncaster M. Menth P. Eardley B. Briscoe July 2012 ASCII 47274 20

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 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 that 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 those approaches along with an explanation of the constraints that apply to any solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pcn-encoding-comparison-09 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6627 RFC6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 S. Shin K. Kobara June 2012 ASCII 45831 20 PAKE augmented PAKE off-line dictionary attacks resistance to server compromise

This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2). This document defines an Experimental Protocol for the Internet community.

 draft-shin-augmented-pake-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6628 RFC6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) J. Abley M. Bagnulo A. Garcia-Martinez June 2012 ASCII 70291 28 Cryptographically Generated Address CGA Hash-Based Address HBA Fault tolerance

This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-garcia-shim6-applicability-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6629 RFC6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) Z. Cao H. Deng Q. Wu G. Zorn Editor June 2012 ASCII 40373 20 ERP AAK EAP Early-authentication

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. [STANDARDS-TRACK]

 draft-ietf-hokey-erp-aak-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6630 RFC6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) D. Kuegler Y. Sheffer June 2012 ASCII 53353 26 pace password authenticated connection establishment

The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration. This document defines an Experimental Protocol for the Internet community.

 draft-kuegler-ipsecme-pace-ikev2-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6631 RFC6632 An Overview of the IETF Network Management Standards M. Ersue Editor B. Claise June 2012 ASCII 210159 85 network management data model monitoring configuration alarm notification

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 Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsawg-management-stds-07 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC6632 RFC6633 Deprecation of ICMP Source Quench Messages F. Gont May 2012 ASCII 16367 8 congestion control icmp attacks tcp tcp security udp dccp sctp

This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. [STANDARDS-TRACK]

 draft-ietf-tsvwg-source-quench-06 RFC0792 RFC1122 RFC1812 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6633 RFC6635 RFC Editor Model (Version 2) O. Kolkman Editor J. Halpern Editor IAB June 2012 ASCII 48170 21 RFC Series Editor Independenet Series Editor RSE ISE RSOC RFC Series Oversight Committee

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 RFC 5620, and obsoletes that document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-rfc-editor-model-v2-05 RFC5620 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6635 RFC6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks H. Asaeda H. Liu Q. Wu May 2012 ASCII 30261 12 Mobility PMIPv6

The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-multimob-igmp-mld-tuning-06 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6636 RFC6637 Elliptic Curve Cryptography (ECC) in OpenPGP A. Jivsov June 2012 ASCII 31532 15

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 and these Elliptic Curves. [STANDARDS-TRACK]

 draft-jivsov-openpgp-ecc-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6637 RFC6638 Scheduling Extensions to CalDAV C. Daboo B. Desruisseaux June 2012 ASCII 156287 78 calsify calsched calsch calendar calendaring webcal ical icalendar ischedule itip imip text/calendar http

This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. [STANDARDS-TRACK]

 draft-desruisseaux-caldav-sched-12 RFC4791 RFC5546 RFC7953 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6638 RFC6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview D. King Editor M. Venkatesan Editor June 2012 ASCII 58669 29

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, 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-mib-management-overview-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6639 10.17487/RFC6639 RFC6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions W. George June 2012 ASCII 27610 13 Meetings

This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-george-travel-faq-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6640 RFC6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4 C. Everhart W. Adamson J. Zhang June 2012 ASCII 24047 11 domainroot domain root file system

The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, 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 namespaces together to allow construction of a global, uniform NFS file namespace. [STANDARDS-TRACK]

 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6641 RFC6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report Q. Wu Editor F. Xia R. Even June 2012 ASCII 29758 13 Feedback Suppression NACK Retransmission

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 Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK]

 draft-ietf-avtcore-feedback-supression-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6642 RFC6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules J. Schoenwaelder July 2012 ASCII 69140 36 SMIv2 YANG data modeling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), 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 Simple Network Management Protocol (SNMP). 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. [STANDARDS-TRACK]

 draft-ietf-netmod-smi-yang-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6643 10.17487/RFC6643 RFC6644 Rebind Capability in DHCPv6 Reconfigure Messages D. Evans R. Droms S. Jiang July 2012 ASCII 19176 10 internet protocol parameters addresses

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. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-reconfigure-rebind-10 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6644 RFC6645 IP Flow Information Accounting and Export Benchmarking Methodology J. Novak July 2012 ASCII 87875 39 Performance Flow monitoring IPFIX Netflow

This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the 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 RFC 5470, "Architecture for IP Flow Information Export". The methodology quantifies the impact of the IP flow monitoring process on the network equipment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-ipflow-meth-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6645 RFC6646 DECoupled Application Data Enroute (DECADE) Problem Statement H. Song N. Zong Y. Yang R. Alimi July 2012 ASCII 25124 12 In-network storage P2P

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 can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-decade-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF tsv decade 10.17487/RFC6646 RFC6647 Email Greylisting: An Applicability Statement for SMTP M. Kucherawy D. Crocker June 2012 ASCII 38097 17 Email Greylisting Spam

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. [STANDARDS-TRACK]

 draft-ietf-appsawg-greylisting-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6647 RFC6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols P. Saint-Andre D. Crocker M. Nottingham June 2012 ASCII 28393 13

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. This memo documents an Internet Best Current Practice.

 draft-ietf-appsawg-xdash-05 BCP0178 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6648 RFC6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos L. Hornquist Astrand T. Yu July 2012 ASCII 13498 7

The Kerberos 5 network authentication protocol, originally specified in RFC 1510, 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 RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos. Because RFC 1510 (obsoleted by RFC 4120) supports only DES, this document recommends the reclassification of RFC 1510 as Historic. This memo documents an Internet Best Current Practice.

 draft-ietf-krb-wg-des-die-die-die-04 RFC1510 RFC1964 RFC4120 RFC4121 RFC4757 BCP0179 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec krb-wg 10.17487/RFC6649 RFC6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) J. Falk M. Kucherawy Editor June 2012 ASCII 35273 15 marf spam reporting

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. [STANDARDS-TRACK]

 draft-ietf-marf-as-16 RFC5965 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6650 RFC6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting M. Kucherawy June 2012 ASCII 35028 18 authentication fraud phishing spoofing

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. [STANDARDS-TRACK]

 draft-ietf-marf-dkim-reporting-16 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6651 RFC6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format S. Kitterman June 2012 ASCII 15373 8 fraud phishing spoofing

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 RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]

 draft-ietf-marf-spf-reporting-11 RFC4408 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6652 RFC6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks B. Sarikaya F. Xia T. Lemon July 2012 ASCII 28755 13

As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sarikaya-v6ops-prefix-delegation-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6653 RFC6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd) T. Tsou C. Zhou T. Taylor Q. Chen July 2012 ASCII 16949 8 IPv6 transition

This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-tsou-softwire-gwinit-6rd-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6654 RFC6655 AES-CCM Cipher Suites for Transport Layer Security (TLS) D. McGrew D. Bailey July 2012 ASCII 17052 8 Authentication Encryption Advanced Encryption Standard (AES)

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]

 draft-mcgrew-tls-aes-ccm-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6655 10.17487/RFC6655 RFC6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4 R. Johnson K. Kinnear M. Stapp July 2012 ASCII 54971 24

This memo documents a DHCPv4 option that currently exists and was previously privately defined for 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 the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dhc-subnet-alloc-13 INFORMATIONAL INFORMATIONAL IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6656 10.17487/RFC6656 RFC6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types A. Melnikov J. Reschke July 2012 ASCII 10111 6 MIME charset text

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. [STANDARDS-TRACK]

 draft-ietf-appsawg-mime-default-charset-04 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6657 RFC6658 Packet Pseudowire Encapsulation over an MPLS PSN S. Bryant Editor L. Martini G. Swallow A. Malis July 2012 ASCII 32164 15

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. [STANDARDS-TRACK]

 draft-ietf-pwe3-packet-pw-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC6658 RFC6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method A. Begen July 2012 ASCII 24234 12 IPTV FEC retransmission

The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avtext-rams-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6659 RFC6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP) B. Briscoe T. Moncaster M. Menth July 2012 ASCII 52230 24 Quality of Service QoS Congestion Control Congestion Notification Tunnelling Encapsulation & Decapsulation Differentiated Services Integrated Services Signalling Protocol Flow Admission Control Flow Termination

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 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 that 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 reusing 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 Diffserv codepoint (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 RFC 5696. [STANDARDS-TRACK]

 draft-ietf-pcn-3-in-1-encoding-11 RFC5696 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn 10.17487/RFC6660 RFC6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation A. Charny F. Huang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII 72258 33 PCN controlled load CL boundary node behavior

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 behaviors for a PCN-domain. The behavior 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 behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pcn-cl-edge-behaviour-14 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6661 RFC6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation A. Charny J. Zhang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII 67000 31 PCN single marking SM edge node behavior

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 behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pcn-sm-edge-behaviour-12 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6662 RFC6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain G. Karagiannis T. Taylor K. Chan M. Menth P. Eardley July 2012 ASCII 15316 7

Pre-Congestion 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). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pcn-signaling-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6663 RFC6664 S/MIME Capabilities for Public Key Definitions J. Schaad July 2012 ASCII 37926 19 OCSP CMS

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. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-pubkey-caps-07 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6664 RFC6665 SIP-Specific Event Notification A.B. Roach July 2012 ASCII 125556 53 SUBSCRIBE NOTIFY state

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. [STANDARDS-TRACK]

 draft-ietf-sipcore-rfc3265bis-09 RFC3265 RFC3261 RFC4660 RFC7621 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6665 RFC6666 A Discard Prefix for IPv6 N. Hilliard D. Freedman August 2012 ASCII 10658 6 RTBH black hole

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 the "IPv6 Special Purpose Address Registry" 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-ipv6-discard-prefix-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6666 RFC6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements K. Raza S. Boutros C. Pignataro July 2012 ASCII 17068 8

The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. 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 Pseudowire Identifier (PWid) (0x80) and Generalized PWid (0x81) FEC Element types. [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-typed-wc-fec-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6667 RFC6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol D. Bider M. Baushke July 2012 ASCII 8710 5

This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC 4253 by specifying a new RECOMMENDED data integrity algorithm. [STANDARDS-TRACK]

 draft-dbider-sha2-mac-for-ssh-06 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6668 RFC6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks N. Sprecher L. Fang July 2012 ASCII 46171 21

This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that 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 the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to 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 documents), which are referenced by this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-oam-analysis-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6669 10.17487/RFC6669 RFC6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) N. Sprecher KY. Hong July 2012 ASCII 77266 33

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.

During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.

One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sprecher-mpls-tp-oam-considerations-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6670 RFC6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) M. Betts November 2012 ASCII 8941 5

This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, and Management (MPLS-TP OAM) messages in the MPLS Generic Associated Channel. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-betts-itu-oam-ach-code-point-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6671 RFC6672 DNAME Redirection in the DNS S. Rose W. Wijngaards June 2012 ASCII 45704 22

The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]

 draft-ietf-dnsext-rfc2672bis-dname-26 RFC2672 RFC3363 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6672 RFC6673 Round-Trip Packet Loss Metrics A. Morton August 2012 ASCII 28458 14 IP IPPM

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 round-trip packet loss metric specified according to the RFC 2330 framework.

This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]

 draft-ietf-ippm-rt-loss-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6673 RFC6674 Gateway-Initiated Dual-Stack Lite Deployment F. Brockners S. Gundavelli S. Speicher D. Ward July 2012 ASCII 32731 15 GI-DS-Lite Gateway Initiated Dual-Stack Lite Dual-Stack Lite IPv6 Transitioning IPv6 Migration

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 to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]

 draft-ietf-softwire-gateway-init-ds-lite-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6674 RFC6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP E. Blanton M. Allman L. Wang I. Jarvinen M. Kojo Y. Nishida August 2012 ASCII 34484 15 transmission control protocol retransmission congestion control

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. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]

 draft-ietf-tcpm-3517bis-02 RFC3517 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6675 RFC6676 Multicast Addresses for Documentation S. Venaas R. Parekh G. Van de Velde T. Chown M. Eubanks August 2012 ASCII 14100 7

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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mboned-mcaddrdoc-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6676 RFC6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods S. Hartman Editor T. Clancy K. Hoeper July 2012 ASCII 79805 31

This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]

 draft-ietf-emu-chbind-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC6677 RFC6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method K. Hoeper S. Hanna H. Zhou J. Salowey Editor July 2012 ASCII 54446 23

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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-emu-eaptunnel-req-09 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC6678 RFC6679 Explicit Congestion Notification (ECN) for RTP over UDP M. Westerlund I. Johansson C. Perkins P. O'Hanlon K. Carlberg August 2012 ASCII 148560 58 ECN RTP UDP Congestion Control VoIP IPTV Packet Loss

This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the 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 initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]

 draft-ietf-avtcore-ecn-for-rtp-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore http://www.rfc-editor.org/errata_search.php?rfc=6679 10.17487/RFC6679 RFC6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions N. Williams L. Johansson S. Hartman S. Josefsson August 2012 ASCII 37063 18

The Generic Security Service Application Programming Interface (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-gssapi-naming-exts-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=6680 10.17487/RFC6680 RFC6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME M. Watson T. Stockhammer M. Luby August 2012 ASCII 46372 22

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 the 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 the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the 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. [STANDARDS-TRACK]

 draft-ietf-fecframe-raptor-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6681 RFC6682 RTP Payload Format for Raptor Forward Error Correction (FEC) M. Watson T. Stockhammer M. Luby August 2012 ASCII 35386 18

This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP. This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. [STANDARDS-TRACK]

 draft-ietf-fecframe-rtp-raptor-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6682 RFC6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection A. Begen T. Stockhammer August 2012 ASCII 22726 11 DVB FEC AL-FEC IPTV parity codes Raptor codes

Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP. 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 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-fecframe-dvb-al-fec-04 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6683 RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) B. Trammell July 2012 ASCII 23550 12 mile incident handling

This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mile-template-05 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC6684 RFC6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry B. Trammell July 2012 ASCII 4363 3 mile xml schema

This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to Incident Object Description Exchange Format (IODEF). [STANDARDS-TRACK]

 draft-ietf-mile-iodef-xmlreg-01 RFC7970 RFC5070 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC6685 RFC6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments M. Kucherawy July 2012 ASCII 26421 12 SPF Sender ID authentication authorization email

In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (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 all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-spfbis-experiment-11 INFORMATIONAL INFORMATIONAL IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=6686 10.17487/RFC6686 RFC6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Tripathi Editor J. de Oliveira Editor JP. Vasseur Editor October 2012 ASCII 63624 26 PDF 589296 ROLL

This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-tripathi-roll-rpl-simulation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6687 10.17487/RFC6687 RFC6688 Parallel NFS (pNFS) Block Disk Protection D. Black Editor J. Glasgow S. Faibish July 2012 ASCII 12119 6 NFS NFSv4 pNFS SAN GPT

Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it 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. [STANDARDS-TRACK]

 draft-ietf-nfsv4-pnfs-block-disk-protection-03 RFC5663 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6688 RFC6689 Usage of the RSVP ASSOCIATION Object L. Berger July 2012 ASCII 26037 11 Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-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 the 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-assoc-info-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6689 RFC6690 Constrained RESTful Environments (CoRE) Link Format Z. Shelby August 2012 ASCII 47720 22 CoRE Link Format HTTP Link Header Format Resource Discovery

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 RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]

 draft-ietf-core-link-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF app core http://www.rfc-editor.org/errata_search.php?rfc=6690 10.17487/RFC6690 RFC6691 TCP Options and Maximum Segment Size (MSS) D. Borman July 2012 ASCII 16707 9

This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tcpm-tcpmss-05 RFC0879 RFC2385 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6691 RFC6692 Source Ports in Abuse Reporting Format (ARF) Reports R. Clayton M. Kucherawy July 2012 ASCII 8053 5 ARF ports reporting feedback

This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.

This document updates RFC 6591. [STANDARDS-TRACK]

 draft-kucherawy-marf-source-ports-05 RFC6591 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6692 RFC6693 Probabilistic Routing Protocol for Intermittently Connected Networks A. Lindgren A. Doria E. Davies S. Grasic August 2012 ASCII 280908 113 DTN Routing PRoPHET

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 the 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. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-prophet-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6693 RFC6694 The "about" URI Scheme S. Moonesamy Editor August 2012 ASCII 11604 7

This document describes 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-appsawg-about-uri-scheme-07 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC6694 RFC6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information R. Asati August 2012 ASCII 34678 15

The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).

This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-fecframe-config-signaling-09 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6695 RFC6696 EAP Extensions for the EAP Re-authentication Protocol (ERP) Z. Cao B. He Y. Shi Q. Wu Editor G. Zorn Editor July 2012 ASCII 103860 47 EAP keying EMSK inter-authenticator roaming

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. [STANDARDS-TRACK]

 draft-ietf-hokey-rfc5296bis-07 RFC5296 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6696 RFC6697 Handover Keying (HOKEY) Architecture Design G. Zorn Editor Q. Wu T. Taylor Y. Nir K. Hoeper S. Decugis July 2012 ASCII 44243 20 Handover Keying Architecture Re-authentication Early authentication

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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-hokey-arch-design-11 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC6697 RFC6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA P. Hoffman J. Schlyter August 2012 ASCII 84034 37 DNSSEC certificates public keys PKI

Encrypted communication on the Internet often uses Transport Layer 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. [STANDARDS-TRACK]

 draft-ietf-dane-protocol-23 RFC7218 RFC7671 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=6698 10.17487/RFC6698 RFC6701 Sanctions Available for Application to Violators of IETF IPR Policy A. Farrel P. Resnick August 2012 ASCII 25078 12

The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.

The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.

This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-farrresnickel-ipr-sanctions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6701 RFC6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules T. Polk P. Saint-Andre August 2012 ASCII 35052 16

The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-polk-ipr-disclosure-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6702 RFC6703 Reporting IP Network Performance Metrics: Different Points of View A. Morton G. Ramachandran G. Maguluri August 2012 ASCII 60152 27 Loss Delay Delay Variation Capacity TCP

Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-reporting-metrics-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6703 RFC6704 Forcerenew Nonce Authentication D. Miles W. Dec J. Bristow R. Maglione August 2012 ASCII 26538 12 DHCP

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 the Forcerenew Nonce Authentication protocol, 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. [STANDARDS-TRACK]

 draft-ietf-dhc-forcerenew-nonce-07 RFC3203 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6704 10.17487/RFC6704 RFC6705 Localized Routing for Proxy Mobile IPv6 S. Krishnan R. Koodli P. Loureiro Q. Wu A. Dutta September 2012 ASCII 43309 20 PMIPv6

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 (MNs) attached to the same or different Mobile Access Gateways (MAGs) 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. [STANDARDS-TRACK]

 draft-ietf-netext-pmip-lr-10 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6705 RFC6706 Asymmetric Extended Route Optimization (AERO) F. Templin Editor August 2012 ASCII 77250 33 route optimize optimization redirect redirection protocol routing link multi-access IPv6

Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. This document defines an Experimental Protocol for the Internet community.

 draft-templin-aero-12 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6706 10.17487/RFC6706 RFC6707 Content Distribution Network Interconnection (CDNI) Problem Statement B. Niven-Jenkins F. Le Faucheur N. Bitar September 2012 ASCII 75060 32 Delivery CDN

Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-cdni-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6707 RFC6708 Application-Layer Traffic Optimization (ALTO) Requirements S. Kiesel Editor S. Previdi M. Stiemerling R. Woundy Y. Yang September 2012 ASCII 47549 20

Many Internet applications are used to access resources, such as pieces of information or server processes that 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 that 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 the utilization of the underlying network infrastructure.

This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-alto-reqs-16 INFORMATIONAL INFORMATIONAL IETF tsv alto 10.17487/RFC6708 RFC6709 Design Considerations for Protocol Extensions B. Carpenter B. Aboba Editor S. Cheshire September 2012 ASCII 103913 42

This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-extension-recs-17 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6709 RFC6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities A. Melnikov K. Carlberg August 2012 ASCII 59966 28 SMTP priority MMHS

This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]

 draft-melnikov-smtp-priority-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6710 10.17487/RFC6710 RFC6711 An IANA Registry for Level of Assurance (LoA) Profiles L. Johansson August 2012 ASCII 14416 7 Identity Assurance

This document establishes an IANA registry for Level of Assurance (LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 and OpenID Connect. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-johansson-loa-registry-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6711 RFC6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) T. Kause M. Peylo September 2012 ASCII 21308 10 CMPtrans

This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]

 draft-ietf-pkix-cmp-transport-protocols-20 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6712 RFC6713 The 'application/zlib' and 'application/gzip' Media Types J. Levine August 2012 ASCII 6525 4 compress deflate stream compression

This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-levine-application-gzip-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6713 RFC6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau E. Burger August 2012 ASCII 50543 22 Middlebox IBCF SBC

This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]

 draft-ietf-simple-msrp-cema-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6714 RFC6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group D. Cauchie B. Leiba K. Li August 2012 ASCII 18951 11 expertise hobby interest

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 (OMA) 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. [STANDARDS-TRACK]

 draft-ietf-vcarddav-oma-cab-extensions-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6715 10.17487/RFC6715 RFC6716 Definition of the Opus Audio Codec JM. Valin K. Vos T. Terriberry September 2012 ASCII 977743 326 voice music lossy compression VOIP

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 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]

 draft-ietf-codec-opus-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai codec http://www.rfc-editor.org/errata_search.php?rfc=6716 10.17487/RFC6716 RFC6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012 H. Hotz R. Allbery August 2012 ASCII 29044 13 Kerberos X.509 kx509 KCA kca-service kca_service

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 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hotz-kx509-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6717 RFC6718 Pseudowire Redundancy P. Muley M. Aissaoui M. Bocci August 2012 ASCII 41486 18 Active standby protection dual-homing vpls vpws

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 redundant set. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pwe3-redundancy-09 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC6718 RFC6719 The Minimum Rank with Hysteresis Objective Function O. Gnawali P. Levis September 2012 ASCII 29637 13 Routing Protocol for Low Power and Lossy Networks RPL Low Power and Lossy Networks LLN

The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions 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 additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK]

 draft-ietf-roll-minrank-hysteresis-of-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6719 10.17487/RFC6719 RFC6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) C. Pignataro R. Asati August 2012 ASCII 17823 8 GTSM LDP

The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's 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. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-gtsm-09 RFC5036 RFC7552 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6720 RFC6721 The Atom "deleted-entry" Element J. Snell September 2012 ASCII 22678 10 Atom Feed Entry Documents

This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. [STANDARDS-TRACK]

 draft-snell-atompub-tombstones-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6721 RFC6722 Publishing the "Tao of the IETF" as a Web Page P. Hoffman Editor August 2012 ASCII 6192 3

This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hoffman-tao-as-web-page-04 RFC4677 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6722 RFC6723 Update of the Pseudowire Control-Word Negotiation Mechanism L. Jin Editor R. Key Editor S. Delord T. Nadeau S. Boutros September 2012 ASCII 20307 9 control word control word negotiation control word renegotiation control word negotiation mechanism control word renegotiation mechanism

The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. [STANDARDS-TRACK]

 draft-ietf-pwe3-cbit-negotiation-05 RFC4447 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6723 RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) D. Thaler Editor R. Draves A. Matsumoto T. Chown September 2012 ASCII 74407 32 source destination sort sorting

This document describes two algorithms, one for source address selection and one 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.

Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]

 draft-ietf-6man-rfc3484bis-06 RFC3484 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6724 10.17487/RFC6724 RFC6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates S. Rose August 2012 ASCII 9236 5

The DNS Security Extensions (DNSSEC) require 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. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-registry-update-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6725 RFC6726 FLUTE - File Delivery over Unidirectional Transport T. Paila R. Walsh M. Luby V. Roca R. Lehtonen November 2012 ASCII 108261 46 Multicast

This document defines File Delivery over Unidirectional Transport (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 RFC 3926. [STANDARDS-TRACK]

 draft-ietf-rmt-flute-revised-16 RFC3926 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=6726 10.17487/RFC6726 RFC6727 Definitions of Managed Objects for Packet Sampling T. Dietz Editor B. Claise J. Quittek October 2012 ASCII 55441 28 PSAMP IPFIX MIB Sampling Filtering Selection

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. For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP- MIB module containing managed objects for providing information on applied packet selection functions and their parameters. [STANDARDS-TRACK]

 draft-ietf-ipfix-psamp-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6727 RFC6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols G. Muenz B. Claise P. Aitken October 2012 ASCII 279937 129

This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF). 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). [STANDARDS-TRACK]

 draft-ietf-ipfix-configuration-model-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6728 10.17487/RFC6728 RFC6729 Indicating Email Handling States in Trace Fields D. Crocker M. Kucherawy September 2012 ASCII 24665 12 Quarantine Moderation

This document 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, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. [STANDARDS-TRACK]

 draft-ietf-appsawg-received-state-04 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6729 10.17487/RFC6729 RFC6730 Requirements for IETF Nominations Committee Tools S. Krishnan J. Halpern September 2012 ASCII 19765 10

This document defines the requirements for a set of tools for use by the IETF Nominations Committee. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-krishnan-nomcom-tools-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6730 RFC6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes T. Savolainen J. Kato T. Lemon December 2012 ASCII 68882 29 DNS RDNSS interface FQDN selection

A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might 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 use. 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. [STANDARDS-TRACK]

 draft-ietf-mif-dns-server-selection-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mif 10.17487/RFC6731 RFC6732 6to4 Provider Managed Tunnels V. Kuarsingh Editor Y. Lee O. Vautrin September 2012 ASCII 28156 12 6to4-PMT

6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07 RFC7526 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC6732 RFC6733 Diameter Base Protocol V. Fajardo Editor J. Arkko J. Loughney G. Zorn Editor October 2012 ASCII 343760 152 Diameter AAA

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 it must be supported by all new Diameter implementations. [STANDARDS-TRACK]

 draft-ietf-dime-rfc3588bis-33 RFC3588 RFC5719 RFC7075 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6733 10.17487/RFC6733 RFC6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport G. Zorn Q. Wu V. Cakulev October 2012 ASCII 12643 7 AAA,ERP,MSK

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. [STANDARDS-TRACK]

 draft-ietf-dime-local-keytran-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6734 RFC6735 Diameter Priority Attribute-Value Pairs K. Carlberg Editor T. Taylor October 2012 ASCII 21793 10 AVP

This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]

 draft-ietf-dime-priority-avps-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6735 10.17487/RFC6735 RFC6736 Diameter Network Address and Port Translation Control Application F. Brockners S. Bhandari V. Singh V. Fajardo October 2012 ASCII 138288 58 NAT control NAT44 NAT66 CGN BNG

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 Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator 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. [STANDARDS-TRACK]

 draft-ietf-dime-nat-control-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6736 RFC6737 The Diameter Capabilities Update Application K. Jiao G. Zorn October 2012 ASCII 12380 6

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. [STANDARDS-TRACK]

 draft-ietf-dime-capablities-update-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6737 RFC6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers V. Cakulev A. Lior S. Mizikovsky October 2012 ASCII 35536 17 Internet Key Exchange Protocol version 2

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 (SK).

Diameter interworking for Mobile IPv6 between the Home Agent (HA), 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 SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. [STANDARDS-TRACK]

 draft-ietf-dime-ikev2-psk-diameter-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6738 RFC6739 Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol H. Schulzrinne H. Tschofenig October 2012 ASCII 52011 25 Location

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 <mapping> element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.

This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ecrit-lost-sync-18 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=6739 10.17487/RFC6739 RFC6740 Identifier-Locator Network Protocol (ILNP) Architectural Description RJ Atkinson SN Bhatti November 2012 ASCII 126139 53

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 Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-arch-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6740 10.17487/RFC6740 RFC6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations RJ Atkinson SN Bhatti November 2012 ASCII 93512 38

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 Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-eng-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6741 RFC6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti S. Rose November 2012 ASCII 42996 20

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 Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-dns-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6742 10.17487/RFC6742 RFC6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII 24972 12

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 Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-icmpv6-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6743 RFC6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII 33737 14

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 Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-noncev6-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6744 RFC6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII 25137 12

This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). 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 Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-icmpv4-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6745 RFC6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII 24866 11

This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-v4opts-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6746 RFC6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII 24322 12

This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-arp-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6747 RFC6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII 86535 37

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. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-adv-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6748 RFC6749 The OAuth 2.0 Authorization Framework D. Hardt Editor October 2012 ASCII 163498 76 Client Resource Owner Authorization Server Resource Server Token Endpoint Authorization Endpoint Authorization Request Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier Access Token Scope Delegation

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. [STANDARDS-TRACK]

 draft-ietf-oauth-v2-31 RFC5849 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6749 10.17487/RFC6749 RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage M. Jones D. Hardt October 2012 ASCII 38949 18 Client Resource Owner Authorization Server Resource Server, Token Endpoint Authorization Endpoint Authorization Request, Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier, Access Token Scope Bearer Authorization Header Bearer Access Token Type

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. [STANDARDS-TRACK]

 draft-ietf-oauth-v2-bearer-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC6750 RFC6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44) R. Despres Editor B. Carpenter D. Wing S. Jiang October 2012 ASCII 73468 33 Coexistence Transition Interworking Tunneling Encapsulation Mapping map-and-encap Global Addressing

In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the 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 based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. This document defines an Experimental Protocol for the Internet community.

 draft-despres-6a44-02 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6751 10.17487/RFC6751 RFC6752 Issues with Private IP Addressing in the Internet A. Kirkham September 2012 ASCII 31838 14

The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-private-ip-sp-cores-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6752 RFC6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) J. Winterbottom H. Tschofenig H. Schulzrinne M. Thomson October 2012 ASCII 49866 25 HELD Dereference lbyr HTTP Location GEOPRIV

This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This 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. [STANDARDS-TRACK]

 draft-ietf-geopriv-deref-protocol-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6753 RFC6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect Y. Cai L. Wei H. Ou V. Arya S. Jethwani October 2012 ASCII 24599 12

A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal cost multipaths (ECMPs), 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 selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]

 draft-ietf-pim-ecmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6754 RFC6755 An IETF URN Sub-Namespace for OAuth B. Campbell H. Tschofenig October 2012 ASCII 8336 5 OAuth URN sub-namespace urn:ietf:params:oauth

This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-oauth-urn-sub-ns-06 INFORMATIONAL INFORMATIONAL IETF sec oauth 10.17487/RFC6755 RFC6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines S. Trowbridge Editor E. Lear Editor G. Fishman Editor S. Bradner Editor September 2012 ASCII 33355 16

This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). 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 A Series Supplement 3 (07/2012).

Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-rfc3356bis-05 RFC3356 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6756 10.17487/RFC6756 RFC6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6 S. Gundavelli Editor J. Korhonen Editor M. Grayson K. Leung R. Pazhyannur October 2012 ASCII 43863 19 ANI ANI option Access Network Identifier option PMIPv6 ANI option

The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) 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. [STANDARDS-TRACK]

 draft-ietf-netext-access-network-option-13 RFC7563 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6757 RFC6758 Tunneling of SMTP Message Transfer Priorities A. Melnikov K. Carlberg October 2012 ASCII 22159 11 Priority MMHS

This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-melnikov-smtp-priority-tunneling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6758 RFC6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) B. Claise P. Aitken N. Ben-Dvora November 2012 ASCII 83584 43

This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-claise-export-application-info-in-ipfix-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6759 10.17487/RFC6759 RFC6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) S. Cheshire M. Krochmal February 2013 ASCII 38212 16

One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.

 draft-cheshire-dnsext-nbp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6760 RFC6761 Special-Use Domain Names S. Cheshire M. Krochmal February 2013 ASCII 28862 13

This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.

 draft-cheshire-dnsext-special-names-03 RFC1918 RFC2606 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6761 RFC6762 Multicast DNS S. Cheshire M. Krochmal February 2013 ASCII 184992 70

As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.

Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.

The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.

 draft-cheshire-dnsext-multicastdns-15 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6762 10.17487/RFC6762 RFC6763 DNS-Based Service Discovery S. Cheshire M. Krochmal February 2013 ASCII 125192 49

This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.

 draft-cheshire-dnsext-dns-sd-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6763 RFC6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) C. Daboo February 2013 ASCII 28361 14 SRV iCalendar

This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.

 draft-daboo-srv-caldav-10 RFC4791 RFC6352 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6764 RFC6765 xDSL Multi-Pair Bonding (G.Bond) MIB E. Beili M. Morgenstern February 2013 ASCII 154301 73 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998 G.998.1 G.998.2 G.998.3 TDIM IMA EFM

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA). The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.

 draft-ietf-adslmib-gbond-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6765 10.17487/RFC6765 RFC6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB E. Beili February 2013 ASCII 107078 55 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998.3

This document defines a 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), as defined in ITU-T Recommendation G.998.3.

 draft-ietf-adslmib-gbond-tdim-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6766 10.17487/RFC6766 RFC6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB E. Beili M. Morgenstern February 2013 ASCII 105415 53 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding Ethernet bonding aggregation 802.3ah G.998.2

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.

 draft-ietf-adslmib-gbond-eth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6767 10.17487/RFC6767 RFC6768 ATM-Based xDSL Bonded Interfaces MIB E. Beili February 2013 ASCII 64283 34 Network Management Simple Network Management Protocol SNMP Management Information Base bonding xDSL bonding aggregation G.Bond G.Bond/ATM G.998.1 IMA IMA+

This document defines a 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 ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.

 draft-ietf-adslmib-gbond-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6768 10.17487/RFC6768 RFC6769 Simple Virtual Aggregation (S-VA) R. Raszuk J. Heitz A. Lo L. Zhang X. Xu October 2012 ASCII 16565 8 BGP aggregation

All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).

Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.

The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-simple-va-12 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6769 RFC6770 Use Cases for Content Delivery Network Interconnection G. Bertrand Editor E. Stephan T. Burbridge P. Eardley K. Ma G. Watson November 2012 ASCII 33281 16 CDN CDNI

Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. 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 the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-cdni-use-cases-10 RFC3570 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6770 RFC6771 Considerations for Having a Successful "Bar BOF" Side Meeting L. Eggert G. Camarillo October 2012 ASCII 24724 10

New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.

During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.

This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-eggert-successful-bar-bof-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6771 RFC6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information H. Schulzrinne Editor H. Tschofenig Editor J. Cuellar J. Polk J. Morris M. Thomson January 2013 ASCII 87801 44 Authorization Policy Location Privacy

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 to data 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, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK]

 draft-ietf-geopriv-policy-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6772 RFC6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal T. Phelan G. Fairhurst C. Perkins November 2012 ASCII 45073 20 DCCP NAPT NAT 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 Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]

 draft-ietf-dccp-udpencap-11 RFC4340 RFC5762 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=6773 10.17487/RFC6773 RFC6774 Distribution of Diverse BGP Paths R. Raszuk Editor R. Fernando K. Patel D. McPherson K. Kumaki November 2012 ASCII 48316 22

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 that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.

The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, the Nth best path can be distributed. This 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 a software upgrade of provider edge (PE) routers acting as route reflector clients. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-diverse-bgp-path-dist-08 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6774 RFC6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) Z. Shelby Editor S. Chakrabarti E. Nordmark C. Bormann November 2012 ASCII 130616 55

The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs 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 the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]

 draft-ietf-6lowpan-nd-21 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan 10.17487/RFC6775 RFC6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block A. Clark Q. Wu October 2012 ASCII 17259 9 RTP Control Protocol

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 blocks may refer. [STANDARDS-TRACK]

 draft-ietf-xrblock-rtcp-xr-meas-identity-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6776 RFC6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks W. Sun Editor G. Zhang Editor J. Gao G. Xie R. Papneja November 2012 ASCII 57725 29 Provisioning performance Performance measurement UNI Bandwidth on Demand performance evaluation Measurement methodologies

When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, 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 way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]

 draft-ietf-ccamp-dpm-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6777 RFC6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching R. Sparks October 2012 ASCII 15396 8 tool

The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sparks-genarea-mailarch-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6778 RFC6779 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres October 2012 ASCII 131403 67 Network Management Management Information base MIB SMIv2 Routing Neighbor Discovery MANET

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 document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]

 draft-ietf-manet-nhdp-mib-19 RFC7939 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6779 RFC6780 RSVP ASSOCIATION Object Extensions L. Berger F. Le Faucheur A. Narayanan October 2012 ASCII 41252 17

The RSVP ASSOCIATION object was defined in the context of GMPLS-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. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]

 draft-ietf-ccamp-assoc-ext-06 RFC2205 RFC3209 RFC3473 RFC4872 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6780 RFC6781 DNSSEC Operational Practices, Version 2 O. Kolkman W. Mekking R. Gieben December 2012 ASCII 161581 71 DNSSEC operational key rollover

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-dnsop-rfc4641bis-13 RFC4641 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=6781 10.17487/RFC6781 RFC6782 Wireline Incremental IPv6 V. Kuarsingh Editor L. Howard November 2012 ASCII 71197 29 transition IPv6 transition operator

Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to 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 periods 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-wireline-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6782 RFC6783 Mailing Lists and Non-ASCII Addresses J. Levine R. Gellens November 2012 ASCII 21960 9 Mail internationalization mailing lists

This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. This document is a product of the Internet Engineering Task Force (IETF).

 draft-ietf-eai-mailinglistbis-05 RFC5983 INFORMATIONAL INFORMATIONAL IETF app eai 10.17487/RFC6783 RFC6784 Kerberos Options for DHCPv6 S. Sakane M. Ishiyama November 2012 ASCII 24110 12 security dhcpv6

This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]

 draft-sakane-dhc-dhcpv6-kdc-option-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6784 RFC6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve B. Leiba November 2012 ASCII 42644 20 email filtering

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 IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. [STANDARDS-TRACK]

 draft-ietf-sieve-imap-sieve-09 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6785 RFC6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs A. Yegin R. Cragie November 2012 ASCII 21361 11

This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form. [STANDARDS-TRACK]

 draft-yegin-pana-encr-avp-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6786 RFC6787 Media Resource Control Protocol Version 2 (MRCPv2) D. Burnett S. Shanmugham November 2012 ASCII 496648 224 mrcp speechsc asr tts speech services speech recognition speech synthesis nlsml speaker authentication speaker verification speaker identification

The Media Resource Control Protocol Version 2 (MRCPv2) 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 the Session Initiation Protocol (SIP), to coordinate 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 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [STANDARDS-TRACK]

 draft-ietf-speechsc-mrcpv2-28 PROPOSED STANDARD PROPOSED STANDARD IETF rai speechsc http://www.rfc-editor.org/errata_search.php?rfc=6787 10.17487/RFC6787 RFC6788 The Line-Identification Option S. Krishnan A. Kavanagh B. Varga S. Ooghe E. Nordmark November 2012 ASCII 38410 17

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 in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK]

 draft-ietf-6man-lineid-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6788 RFC6789 Congestion Exposure (ConEx) Concepts and Use Cases B. Briscoe Editor R. Woundy Editor A. Cooper Editor December 2012 ASCII 41078 17 Congestion Signaling Traffic Management

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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-conex-concepts-uses-05 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC6789 RFC6790 The Use of Entropy Labels in MPLS Forwarding K. Kompella J. Drake S. Amante W. Henderickx L. Yong November 2012 ASCII 53837 25 entropy hash ecmp load balancing

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. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]

 draft-ietf-mpls-entropy-label-06 RFC3031 RFC3107 RFC3209 RFC5036 RFC7274 RFC7447 RFC8012 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6790 10.17487/RFC6790 RFC6791 Stateless Source Address Mapping for ICMPv6 Packets X. Li C. Bao D. Wing R. Vaithianathan G. Huston November 2012 ASCII 11793 6 IP/ICMP Translation Algorithm IPv4-translatable IPv6 addresses ICMPv6 traceroute

A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK]

 draft-ietf-v6ops-ivi-icmp-address-07 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC6791 RFC6792 Guidelines for Use of the RTP Monitoring Framework Q. Wu Editor G. Hunt P. Arden November 2012 ASCII 42473 17 Real Time Control Protocol

This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR 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 that 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 that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avtcore-monarch-22 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC6792 RFC6793 BGP Support for Four-Octet Autonomous System (AS) Number Space Q. Vohra E. Chen December 2012 ASCII 26366 12 autonomous system border gateway protocol

The Autonomous System 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 and updates RFC 4271. [STANDARDS-TRACK]

 draft-ietf-idr-rfc4893bis-07 RFC4893 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=6793 10.17487/RFC6793 RFC6794 A Framework for Session Initiation Protocol (SIP) Session Policies V. Hilt G. Camarillo J. Rosenberg December 2012 ASCII 94464 36

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. [STANDARDS-TRACK]

 draft-ietf-sip-session-policy-framework-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC6794 RFC6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies V. Hilt G. Camarillo December 2012 ASCII 42920 18

This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. [STANDARDS-TRACK]

 draft-ietf-sipping-policy-package-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6795 RFC6796 A User Agent Profile Data Set for Media Policy V. Hilt G. Camarillo J. Rosenberg D. Worley December 2012 ASCII 88634 43 SIP Session Policy Data Set

This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. [STANDARDS-TRACK]

 draft-camarillo-rai-media-policy-dataset-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6796 RFC6797 HTTP Strict Transport Security (HSTS) J. Hodges C. Jackson A. Barth November 2012 ASCII 103554 46 HTTPS TLS SSL ForceHTTPS man-in-the-middle MITM certificate error certificate verification security policy secure transport IDNA-Canonicalization

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. [STANDARDS-TRACK]

 draft-ietf-websec-strict-transport-sec-14 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6797 10.17487/RFC6797 RFC6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting A. Clark Q. Wu November 2012 ASCII 26901 13

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. [STANDARDS-TRACK]

 draft-ietf-xrblock-rtcp-xr-pdv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6798 RFC6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework U. Kozat A. Begen November 2012 ASCII 24923 11

This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-fecframe-pseudo-cdp-05 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6801 RFC6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets S. Baillargeon C. Flinta A. Johnsson November 2012 ASCII 37309 15 available capacity rate train interval padding buffer test session

This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-twamp-value-added-octets-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6802 RFC6803 Camellia Encryption for Kerberos 5 G. Hudson November 2012 ASCII 23516 13 Camellia Kerberos

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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-krb-wg-camellia-cts-02 INFORMATIONAL INFORMATIONAL IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6803 10.17487/RFC6803 RFC6804 DISCOVER: Supporting Multicast DNS Queries B. Manning November 2012 ASCII 19946 9

This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. This document defines a Historic Document for the Internet community.

 draft-manning-opcode-discover-07 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6804 RFC6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS D. King Editor A. Farrel Editor November 2012 ASCII 77669 33

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 PCE-based Computation (BRPC) procedure 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-hierarchy-fwk-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6805 RFC6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals S. Hartman Editor K. Raeburn L. Zhu November 2012 ASCII 47572 19 authentication security protocols identity

This 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 Ticket-Granting Ticket (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. [STANDARDS-TRACK]

 draft-ietf-krb-wg-kerberos-referrals-15 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6806 RFC6807 Population Count Extensions to Protocol Independent Multicast (PIM) D. Farinacci G. Shepherd S. Venaas Y. Cai December 2012 ASCII 32114 15

This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pim-pop-count-07 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6807 RFC6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser December 2012 ASCII 62061 29 One-way Delay IP Performance Metrics IPPM

This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. 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. This memo also provides direct input for development of a revision of RFC 2679. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-testplan-rfc2679-03 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6808 RFC6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) C. Holmberg I. Sedlacek H. Kaplan November 2012 ASCII 40053 19 proxy feature feature tag feature-capability indicator Feature-Caps capability

This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.

SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.

This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]

 draft-ietf-sipcore-proxy-feature-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6809 RFC6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush R. Austein January 2013 ASCII 59714 27

In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK]

 draft-ietf-sidr-rpki-rtr-26 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6810 RFC6811 BGP Prefix Origin Validation P. Mohapatra J. Scudder D. Ward R. Bush R. Austein January 2013 ASCII 20082 10 SIDR security

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 Autonomous System (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. [STANDARDS-TRACK]

 draft-ietf-sidr-pfx-validate-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6811 RFC6812 Cisco Service-Level Assurance Protocol M. Chiba A. Clemm S. Medley J. Salowey S. Thombare E. Yedavalli January 2013 ASCII 68237 27 Cisco's SLA Protocol

Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a Performance Measurement protocol that has been widely deployed. The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss. This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cisco-sla-protocol-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6812 RFC6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis J. Salowey S. Hanna December 2012 ASCII 15899 8 Man-in-the-Middle MITM Security Endpoint Posture Protocol Forwarding TNC Channel Binding Cryptographic Countermeasure

The Network Endpoint Assessment (NEA) 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nea-asokan-02 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC6813 RFC6814 Formally Deprecating Some IPv4 Options C. Pignataro F. Gont November 2012 ASCII 11327 6

A number of IPv4 options have become obsolete in practice, but have never been formally deprecated. This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry. Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. [STANDARDS-TRACK]

 draft-gp-intarea-obsolete-ipv4-options-iana-02 RFC1385 RFC1393 RFC1475 RFC1770 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6814 RFC6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful S. Bradner K. Dubray J. McQuaid A. Morton November 2012 ASCII 22308 11 testing performance

The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-2544-as-08 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6815 RFC6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan December 2012 ASCII 49938 24 Forward Error Correction LDPC-Staircase

This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. 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-ldpc-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6816 RFC6817 Low Extra Delay Background Transport (LEDBAT) S. Shalunov G. Hazel J. Iyengar M. Kuehlewind December 2012 ASCII 57813 25 Congestion control delay-based scavenger P2P

Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that 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 to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ledbat-congestion-10 EXPERIMENTAL EXPERIMENTAL IETF tsv ledbat 10.17487/RFC6817 RFC6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile P. Yee January 2013 ASCII 17439 8

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. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc5280-clarifications-11 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6818 RFC6819 OAuth 2.0 Threat Model and Security Considerations T. Lodderstedt Editor M. McGloin P. Hunt January 2013 ASCII 158332 71 authorization authentication token counter-measures HTTP REST

This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-oauth-v2-threatmodel-08 INFORMATIONAL INFORMATIONAL IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6819 10.17487/RFC6819 RFC6820 Address Resolution Problems in Large Data Center Networks T. Narten M. Karir I. Foo January 2013 ASCII 42650 17 ARMD data center ARP ND Neighbor Discovery

This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution (the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery (ND) in IPv6) within a data center. This document is a product of the Internet Engineering Task Force (IETF).

 draft-ietf-armd-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF ops armd 10.17487/RFC6820 RFC6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality E. Marocco A. Fusco I. Rimac V. Gurbani December 2012 ASCII 33299 16 cross-domain traffic bandwidth transit traffic peer-to-peer caching peer-to-peer swarm

Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.

This document is a product of the IRTF P2PRG (Peer-to-Peer Research Group).

 draft-irtf-p2prg-mythbustering-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6821 RFC6822 IS-IS Multi-Instance S. Previdi Editor L. Ginsberg M. Shand A. Roy D. Ward December 2012 ASCII 30254 14 intermediate system to intermediate system

This document 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 (or topologies) to which the PDU belongs.

 draft-ietf-isis-mi-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6822 10.17487/RFC6822 RFC6823 Advertising Generic Information in IS-IS L. Ginsberg S. Previdi M. Shand December 2012 ASCII 22708 11 intermediate system to intermediate system

This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.

 draft-ietf-isis-genapp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6823 RFC6824 TCP Extensions for Multipath Operation with Multiple Addresses A. Ford C. Raiciu M. Handley O. Bonaventure January 2013 ASCII 164866 64

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 it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mptcp-multiaddressed-12 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=6824 10.17487/RFC6824 RFC6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS M. Miyazawa T. Otani K. Kumaki T. Nadeau January 2013 ASCII 72765 40 TED-MIB ted mib

This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-ted-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6825 RFC6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor T. Eckert N. Leymann M. Napierala January 2013 ASCII 23927 12

Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that 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. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-mldp-in-band-signaling-08 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6826 RFC6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols A. Malis Editor A. Lindem Editor D. Papadimitriou Editor January 2013 ASCII 73279 30

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. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), 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 that were current when those documents were written. Future extensions or 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. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc5787bis-06 RFC5787 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6827 RFC6828 Content Splicing for RTP Sessions J. Xia January 2013 ASCII 38904 17

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.

This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avtext-splicing-for-rtp-12 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6828 RFC6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 M. Chen P. Pan C. Pignataro R. Asati January 2013 ASCII 15683 8

The Multiprotocol 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 LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.

This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. [STANDARDS-TRACK]

 draft-ietf-mpls-ipv6-pw-lsp-ping-04 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6829 RFC6830 The Locator/ID Separation Protocol (LISP) D. Farinacci V. Fuller D. Meyer D. Lewis January 2013 ASCII 189977 75

This document 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. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, 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. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-24 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6830 RFC6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments D. Farinacci D. Meyer J. Zwiebel S. Venaas January 2013 ASCII 71901 28

This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-multicast-14 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6831 RFC6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites D. Lewis D. Meyer D. Farinacci V. Fuller January 2013 ASCII 43758 19

This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that 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 Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) 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. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-interworking-06 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6832 RFC6833 Locator/ID Separation Protocol (LISP) Map-Server Interface V. Fuller D. Farinacci January 2013 ASCII 30144 13

This document describes the Mapping Service for the Locator/ID 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" 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. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-ms-16 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6833 RFC6834 Locator/ID Separation Protocol (LISP) Map-Versioning L. Iannone D. Saucez O. Bonaventure January 2013 ASCII 51447 21

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 the transport of 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. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-map-versioning-09 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6834 RFC6835 The Locator/ID Separation Protocol Internet Groper (LIG) D. Farinacci D. Meyer January 2013 ASCII 26810 12

A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-lisp-lig-06 INFORMATIONAL INFORMATIONAL IETF int lisp 10.17487/RFC6835 RFC6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) V. Fuller D. Farinacci D. Meyer D. Lewis January 2013 ASCII 62093 25

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) that 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 Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-alt-11 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6836 RFC6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database E. Lear January 2013 ASCII 72499 31

The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries. This document defines an Experimental Protocol for the Internet community.

 draft-lear-lisp-nerd-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6837 RFC6838 Media Type Specifications and Registration Procedures N. Freed J. Klensin T. Hansen January 2013 ASCII 72942 32

This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.

 draft-ietf-appsawg-media-type-regs-14 RFC4288 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6838 RFC6839 Additional Media Type Structured Syntax Suffixes T. Hansen A. Melnikov January 2013 ASCII 26071 14 structured syntax suffix media type

A content media type name sometimes includes partitioned meta- information distinguished 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 provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-appsawg-media-type-suffix-regs-08 RFC3023 RFC7303 INFORMATIONAL INFORMATIONAL IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6839 10.17487/RFC6839 RFC6840 Clarifications and Implementation Notes for DNS Security (DNSSEC) S. Weiler Editor D. Blacka Editor February 2013 ASCII 47283 21 EAP AAA reconnect

This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.

This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.

 draft-ietf-dnsext-dnssec-bis-updates-20 RFC4033 RFC4034 RFC4035 RFC5155 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6840 10.17487/RFC6840 RFC6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements F. Ljunggren AM. Eklund Lowinder T. Okubo January 2013 ASCII 57936 27 DNS DNSSEC DP DPS

This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-dnssec-dps-framework-11 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6841 RFC6842 Client Identifier Option in DHCP Server Replies N. Swamy G. Halwasia P. Jhingran January 2013 ASCII 10030 5

This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK]

 draft-ietf-dhc-client-id-07 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6842 RFC6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting A. Clark K. Gross Q. Wu January 2013 ASCII 18354 9 Round Trip Delay End System Delay

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]

 draft-ietf-xrblock-rtcp-xr-delay-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6843 RFC6844 DNS Certification Authority Authorization (CAA) Resource Record P. Hallam-Baker R. Stradling January 2013 ASCII 36848 18 DNS DNSSEC PKIX

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) 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. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]

 draft-ietf-pkix-caa-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6844 10.17487/RFC6844 RFC6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type N. Sheth L. Wang J. Zhang January 2013 ASCII 17019 9 OSPF P2MP Broadcast Interface

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 Link State Advertisement (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 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK]

 draft-ietf-ospf-hybrid-bcast-and-p2mp-06 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC6845 RFC6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West January 2013 ASCII 187518 96

This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.

This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]

 draft-sandlund-rfc4996bis-02 RFC4996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6846 10.17487/RFC6846 RFC6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL) D. Melman T. Mizrahi D. Eastlake 3rd January 2013 ASCII 28693 13 FCoE FCRB TRILL RBridge

Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mme-trill-fcoe-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6847 RFC6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO) J. Winterbottom M. Thomson R. Barnes B. Rosen R. George January 2013 ASCII 41081 21 Extension Local Civic Location GEOPRIV

New fields are occasionally added to civic addresses. A backward- 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. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. [STANDARDS-TRACK]

 draft-ietf-geopriv-local-civic-10 RFC4776 RFC5222 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6848 RFC6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback H. Kaplan Editor K. Hedayat N. Venna P. Jones N. Stratton February 2013 ASCII 66214 33 multimedia audio video RTCP diagnostic voip

The wide deployment of Voice over IP (VoIP), real-time 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 Session Description Protocol (SDP) media types and attributes that 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-loopback-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6849 RFC6850 Definitions of Managed Objects for Routing Bridges (RBridges) A. Rijhsinghani K. Zebrose January 2013 ASCII 104287 59

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a Routing Bridge (RBridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. [STANDARDS-TRACK]

 draft-ietf-trill-rbridge-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6850 RFC6851 Internet Message Access Protocol (IMAP) - MOVE Extension A. Gulbrandsen N. Freed Editor January 2013 ASCII 15689 8 IMAP

This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [STANDARDS-TRACK]

 draft-ietf-imapmove-command-05 PROPOSED STANDARD PROPOSED STANDARD IETF app imapmove 10.17487/RFC6851 RFC6852 Affirmation of the Modern Paradigm for Standards R. Housley S. Mills J. Jaffe B. Aboba L. St.Amour January 2013 ASCII 9696 5

On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-modern-paradigm-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6852 RFC6853 DHCPv6 Redundancy Deployment Considerations J. Brzozowski J. Tremblay J. Chen T. Mrugalski February 2013 ASCII 34209 16 DHCPv6 Redundancy Deployment Considerations

This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services.

 draft-ietf-dhc-dhcpv6-redundancy-consider-03 BCP0180 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc 10.17487/RFC6853 RFC6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields B. Leiba March 2013 ASCII 20190 9

The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations.

 draft-leiba-5322upd-from-group-09 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6854 RFC6855 IMAP Support for UTF-8 P. Resnick Editor C. Newman Editor S. Shen Editor March 2013 ASCII 24370 12 IMAP IDNA

This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.

 draft-ietf-eai-5738bis-12 RFC5738 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6855 10.17487/RFC6855 RFC6856 Post Office Protocol Version 3 (POP3) Support for UTF-8 R. Gellens C. Newman J. Yao K. Fujiwara March 2013 ASCII 26790 14 internationalized

This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.

 draft-ietf-eai-rfc5721bis-08 RFC5721 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6856 RFC6857 Post-Delivery Message Downgrading for Internationalized Email Messages K. Fujiwara March 2013 ASCII 39255 20 EAI Email Address Internationalization Downgrade MAIL

The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.

 draft-ietf-eai-popimap-downgrade-08 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6857 10.17487/RFC6857 RFC6858 Simplified POP and IMAP Downgrading for Internationalized Email A. Gulbrandsen March 2013 ASCII 12169 6

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-eai-simpledowngrade-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6858 RFC6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership B. Leiba January 2013 ASCII 5619 3 nomcom IAOC

RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777. There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC. This memo documents an Internet Best Current Practice.

 draft-leiba-3777upd-eligibility-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6859 RFC6860 Hiding Transit-Only Networks in OSPF Y. Yang A. Retana A. Roy January 2013 ASCII 26368 13

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 are 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 reduce vulnerability to remote attacks.

In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.

This document updates RFCs 2328 and 5340. [STANDARDS-TRACK]

 draft-ietf-ospf-prefix-hiding-07 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6860 10.17487/RFC6860 RFC6861 The "create-form" and "edit-form" Link Relations I. Dzmanashvili January 2013 ASCII 8191 6

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ioseb-dzmanashvili-link-relation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6861 RFC6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements G. Lebovitz M. Bhatia B. Weis March 2013 ASCII 67802 26

Different routing protocols employ different mechanisms for securing 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. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.

 draft-ietf-karp-threats-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6862 RFC6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide S. Hartman D. Zhang March 2013 ASCII 26996 11

This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.

 draft-ietf-karp-ospf-analysis-06 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6863 RFC6864 Updated Specification of the IPv4 ID Field J. Touch February 2013 ASCII 44418 19

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 address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. 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 RFCs 791, 1122, and 2003 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. [STANDARDS-TRACK]

 draft-ietf-intarea-ipv4-id-update-07 RFC0791 RFC1122 RFC2003 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC6864 RFC6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan A. Bouabdallah K. Matsuzono February 2013 ASCII 48493 23 Forward Error Correction Reed-Solomon

This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, 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 the Low-Density Parity Check (LDPC) codes, for instance.

 draft-ietf-fecframe-simple-rs-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6865 RFC6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks B. Carpenter S. Jiang February 2013 ASCII 26524 11

This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.

 draft-ietf-6renum-static-problem-03 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6866 RFC6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) Y. Nir Q. Wu January 2013 ASCII 19322 9

This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. This document defines an Experimental Protocol for the Internet community.

 draft-nir-ipsecme-erx-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6867 RFC6868 Parameter Value Encoding in iCalendar and vCard C. Daboo February 2013 ASCII 11025 7 calendar contact

This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.

 draft-daboo-ical-vcard-parameter-encoding-04 RFC5545 RFC6321 RFC6350 RFC6351 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6868 10.17487/RFC6868 RFC6869 vCard KIND:device G. Salgueiro J. Clarke P. Saint-Andre February 2013 ASCII 14648 9 vCard

This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]

 draft-salgueiro-vcarddav-kind-device-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6869 RFC6870 Pseudowire Preferential Forwarding Status Bit P. Muley Editor M. Aissaoui Editor February 2013 ASCII 79254 35 PW redundancy active PW standby PW primary PW secondary PW PW precedence

This document describes a mechanism for signaling the active and standby status 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 defined. This bit indicates a Preferential Forwarding status with a value 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 RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.

 draft-ietf-pwe3-redundancy-bit-09 RFC4447 RFC7771 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6870 10.17487/RFC6870 RFC6871 Session Description Protocol (SDP) Media Capabilities Negotiation R. Gilman R. Even F. Andreasen February 2013 ASCII 124829 55 Session Capabilities Latent Configurations Media Format Capability

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. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.

This document updates the IANA Considerations of RFC 5939.

 draft-ietf-mmusic-sdp-media-capabilities-17 RFC5939 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6871 RFC6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model V. Gurbani Editor E. Burger Editor T. Anjali H. Abdelnur O. Festor February 2013 ASCII 72134 39 logging analytics information 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 troubleshooting 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. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.

 draft-ietf-sipclf-problem-statement-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6872 RFC6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Gurbani A. B. Roach February 2013 ASCII 63449 28 SIPCLF

The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF 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 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 information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.

 draft-ietf-sipclf-format-11 RFC7355 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6873 RFC6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers B. Carpenter S. Cheshire R. Hinden February 2013 ASCII 19361 10

This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.

 draft-ietf-6man-uri-zoneid-06 RFC3986 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6874 10.17487/RFC6874 RFC6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan S. Kamei T. Momose T. Inoue T. Nishitani February 2013 ASCII 41572 18 overlay network content delivery network peer-to-peer traffic engineering experiments in Japan

This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.

 draft-kamei-p2p-experiments-japan-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6875 RFC6876 A Posture Transport Protocol over TLS (PT-TLS) P. Sangster N. Cam-Winget J. Salowey February 2013 ASCII 109852 44 Network Endpoint Assessment NEA

This document specifies PT-TLS, a TLS-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-nea-pt-tls-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC6876 RFC6877 464XLAT: Combination of Stateful and Stateless Translation M. Mawatari M. Kawashima C. Byrne April 2013 ASCII 31382 14 XLAT Stateful Translation 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 (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.

 draft-ietf-v6ops-464xlat-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6877 RFC6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field A.B. Roach March 2013 ASCII 4688 3

This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261.

 draft-ietf-sipcore-priority-00 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6878 10.17487/RFC6878 RFC6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods S. Jiang B. Liu B. Carpenter February 2013 ASCII 38833 17

This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.

 draft-ietf-6renum-enterprise-06 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6879 RFC6880 An Information Model for Kerberos Version 5 L. Johansson March 2013 ASCII 28121 14 kerberos kdc LDAP schema

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 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC.

 draft-ietf-krb-wg-kdc-model-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6880 RFC6881 Best Current Practice for Communications Services in Support of Emergency Calling B. Rosen J. Polk March 2013 ASCII 63007 28 SIP emergency emergency calls emergency call emergency calling 9-1-1 1-1-2 ecrit

The IETF and other standards organizations 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-phonebcp-20 RFC7840 RFC7852 BCP0181 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai ecrit 10.17487/RFC6881 RFC6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs) K. Kumaki Editor T. Murai D. Cheng S. Matsushima P. Jiang March 2013 ASCII 33125 15

IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.

The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.

 draft-kumaki-murai-l3vpn-rsvp-te-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6882 RFC6883 IPv6 Guidance for Internet Content Providers and Application Service Providers B. Carpenter S. Jiang March 2013 ASCII 60430 24

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 hosting providers or to any enterprise network preparing for IPv6 users.

 draft-ietf-v6ops-icp-guidance-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6883 RFC6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) Z. Fang March 2013 ASCII 43207 21 EVRC-WB EVRC-B

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 email.

 draft-ietf-avt-rtp-evrc-nw-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6884 RFC6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) M. Blanchet A. Sullivan March 2013 ASCII 72167 34

If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called 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-precis-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF app precis 10.17487/RFC6885 RFC6886 NAT Port Mapping Protocol (NAT-PMP) S. Cheshire M. Krochmal April 2013 ASCII 87891 33

This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.

 draft-cheshire-nat-pmp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6886 10.17487/RFC6886 RFC6887 Port Control Protocol (PCP) D. Wing Editor S. Cheshire M. Boucadair R. Penno P. Selkirk April 2013 ASCII 221314 88 NAT Firewall

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-base-29 RFC7488 RFC7652 RFC7843 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp http://www.rfc-editor.org/errata_search.php?rfc=6887 10.17487/RFC6887 RFC6888 Common Requirements for Carrier-Grade NATs (CGNs) S. Perreault Editor I. Yamagata S. Miyakawa A. Nakagawa H. Ashida April 2013 ASCII 32484 15 CGN NAT

This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.

 draft-ietf-behave-lsn-requirements-10 RFC4787 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC6888 RFC6889 Analysis of Stateful 64 Translation R. Penno T. Saxena M. Boucadair S. Sivakumar April 2013 ASCII 33171 15 NAT64 DNS64 NAT-PT ALG (Application Layer Gateway) NAT traversal IPv4-IPv6 interconnection IPv4-IPv6 translation

Due to specific problems, Network Address Translation - Protocol Translation (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-64-analysis-07 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6889 RFC6890 Special-Purpose IP Address Registries M. Cotton L. Vegoda R. Bonica Editor B. Haberman April 2013 ASCII 48326 23 Internet Protocol space assignments

This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.

 draft-bonica-special-purpose-07 RFC4773 RFC5156 RFC5735 RFC5736 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6890 10.17487/RFC6890 RFC6891 Extension Mechanisms for DNS (EDNS(0)) J. Damas M. Graff P. Vixie April 2013 ASCII 32856 16 DNS extensions domain name system resource records opt

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 Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.

 draft-ietf-dnsext-rfc2671bis-edns0-10 RFC2671 RFC2673 STD0075 INTERNET STANDARD INTERNET STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6891 10.17487/RFC6891 RFC6892 The 'describes' Link Relation Type E. Wilde March 2013 ASCII 10846 5

This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.

 draft-wilde-describes-link-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6892 RFC6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF) P. Higgs P. Szucs March 2013 ASCII 12403 8

This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF.

 draft-higgs-oipf-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6893 RFC6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection R. Papneja S. Vapiwala J. Karthik S. Poretsky S. Rao JL. Le Roux March 2013 ASCII 64597 35

This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection. This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.

 draft-ietf-bmwg-protection-meth-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6894 RFC6895 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd April 2013 ASCII 38979 19 RRTYPE RCODE AFSDB

This document specifies Internet Assigned Numbers 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 and updates RFCs 1183, 2845, 2930, and 3597.

 draft-ietf-dnsext-rfc6195bis-05 RFC6195 RFC1183 RFC2845 RFC2930 RFC3597 BCP0042 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6895 RFC6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP S. Barbato S. Dorigotti T. Fossati Editor March 2013 ASCII 44175 23 HTTP Secure Cookies

This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.

Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.

 draft-secure-cookie-session-protocol-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6896 10.17487/RFC6896 RFC6897 Multipath TCP (MPTCP) Application Interface Considerations M. Scharf A. Ford March 2013 ASCII 75704 31

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 that is a simple extension of TCP's interface for MPTCP-aware applications.

 draft-ietf-mptcp-api-07 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6897 RFC6898 Link Management Protocol Behavior Negotiation and Configuration Modifications D. Li D. Ceccarelli L. Berger March 2013 ASCII 21446 11 LMP

The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). 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.

This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.

 draft-ietf-ccamp-lmp-behavior-negotiation-11 RFC4204 RFC4207 RFC4209 RFC5818 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6898 RFC6901 JavaScript Object Notation (JSON) Pointer P. Bryan Editor K. Zyp M. Nottingham Editor April 2013 ASCII 13037 8

JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.

 draft-ietf-appsawg-json-pointer-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6901 10.17487/RFC6901 RFC6902 JavaScript Object Notation (JSON) Patch P. Bryan Editor M. Nottingham Editor April 2013 ASCII 26405 18

JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.

 draft-ietf-appsawg-json-patch-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6902 10.17487/RFC6902 RFC6903 Additional Link Relation Types J. Snell March 2013 ASCII 10452 6 http link rel

This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.

 draft-snell-additional-link-relations-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6903 RFC6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) J. Lennox April 2013 ASCII 33486 15 real-time transport protocol rtp header extensions security

The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.

This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.

 draft-ietf-avtcore-srtp-encrypted-header-ext-05 RFC3711 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6904 RFC6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) T. Senevirathne D. Bond S. Aldrin Y. Li R. Watve March 2013 ASCII 24278 13

Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).

 draft-ietf-trill-oam-req-05 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC6905 RFC6906 The 'profile' Link Relation Type E. Wilde March 2013 ASCII 18469 8 application profile profile identifier

This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.

 draft-wilde-profile-link-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6906 RFC6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties T. Manderson K. Sriram R. White March 2013 ASCII 66099 31 Prefix origin validation Routing security BGP security

This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.

 draft-ietf-sidr-usecases-06 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6907 RFC6908 Deployment Considerations for Dual-Stack Lite Y. Lee R. Maglione C. Williams C. Jacquenet M. Boucadair March 2013 ASCII 35359 14

This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.

 draft-ietf-softwire-dslite-deployment-08 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC6908 RFC6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 S. Gundavelli Editor X. Zhou J. Korhonen G. Feige R. Koodli April 2013 ASCII 34575 14

This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.

 draft-ietf-netext-pmipv6-sipto-option-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6909 RFC6910 Completion of Calls for the Session Initiation Protocol (SIP) D. Worley M. Huelsemann R. Jesske D. Alexeitsev April 2013 ASCII 86166 37 call completion CC SS7 Signaling System 7 purpose header parameter m URI parameter m header parameter call-completion event package, CCBS CCNR CCNL Call-Info header field Presence Information Data Format PIDF P-Asserted-Identity header field

The "completion of calls" 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 "Session Initiation Protocol 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 "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.

The architecture is designed to interoperate well with existing completion of calls solutions in other networks.

 draft-ietf-bliss-call-completion-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss 10.17487/RFC6910 RFC6911 RADIUS Attributes for IPv6 Access Networks W. Dec Editor B. Sarikaya G. Zorn Editor D. Miles B. Lourdelet April 2013 ASCII 28123 15 AAA RADIUS IPv6

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 an 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-ipv6-access-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6911 RFC6912 Principles for Unicode Code Point Inclusion in Labels in the DNS A. Sullivan D. Thaler J. Klensin O. Kolkman April 2013 ASCII 27078 12

Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.

 draft-iab-dns-zone-codepoint-pples-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6912 RFC6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP) D. Hanes G. Salgueiro K. Fleming March 2013 ASCII 18119 9 media feature tag

This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP). Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.

 draft-hanes-dispatch-fax-capability-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6913 RFC6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP) J. Rosenberg April 2013 ASCII 35472 15 SIP SIMPLE presence IM

The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other.

 draft-ietf-simple-simple-09 INFORMATIONAL INFORMATIONAL IETF rai simple 10.17487/RFC6914 RFC6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD) R. Bellis April 2013 ASCII 14175 9 HELD Flow

RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.

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 specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement.

This document updates RFC 6155 by deprecating the port number elements specified therein.

 draft-ietf-geopriv-flow-identity-02 RFC6155 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6915 RFC6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) R. Gagliano S. Kent S. Turner April 2013 ASCII 48395 20 Resource Public Key Infrastructure RPKI Algorithm Transition SIDR routing security BGP security

This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) 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 over a timescale of several 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-algorithm-agility-12 BCP0182 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6916 RFC6917 Media Resource Brokering C. Boulton L. Miniero G. Munson April 2013 ASCII 280399 136

The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling 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-mediactrl-mrb-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6917 RFC6918 Formally Deprecating Some ICMPv4 Message Types F. Gont C. Pignataro April 2013 ASCII 13639 8 IANA IPv4 Options

A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.

 draft-gp-obsolete-icmp-types-iana-01 RFC1788 RFC0792 RFC0950 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6918 RFC6919 Further Key Words for Use in RFCs to Indicate Requirement Levels R. Barnes S. Kent E. Rescorla April 1 2013 ASCII 11076 6

RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

 draft-barnes-2119bis-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6919 RFC6920 Naming Things with Hashes S. Farrell D. Kutscher C. Dannewitz B. Ohlman A. Keranen P. Hallam-Baker April 2013 ASCII 54124 23 Cryptography URI Information Centric Networking

This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and 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. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.

 draft-farrell-decade-ni-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6920 10.17487/RFC6920 RFC6921 Design Considerations for Faster-Than-Light (FTL) Communication R. Hinden April 1 2013 ASCII 15100 7

We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.

 draft-hinden-FTL-design-considerations-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6921 RFC6922 The application/sql Media Type Y. Shafranovich April 2013 ASCII 8453 5 SQL MIME

This document registers the application/sql media type to be used for the Structured Query Language (SQL).

 draft-shafranovich-mime-sql-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6922 RFC6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions R. Winter E. Gray H. van Helvoort M. Betts May 2013 ASCII 23811 12

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 Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).

 draft-ietf-mpls-tp-itu-t-identifiers-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6923 RFC6924 Registration of Second-Level URN Namespaces under "ietf" B. Leiba April 2013 ASCII 5952 4

RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".

 draft-leiba-urnbis-ietf-namespace-02 RFC2648 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6924 RFC6925 The DHCPv4 Relay Agent Identifier Sub-Option B. Joshi R. Desetti M. Stapp April 2013 ASCII 17664 8 DHCP relay

This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option 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 sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.

 draft-ietf-dhc-relay-id-suboption-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6925 RFC6926 DHCPv4 Bulk Leasequery K. Kinnear M. Stapp R. Desetti B. Joshi N. Russell P. Kurapati B. Volz April 2013 ASCII 88215 41

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol 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-bulk-leasequery-07 RFC7724 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6926 RFC6927 Variants in Second-Level Names Registered in Top-Level Domains J. Levine P. Hoffman May 2013 ASCII 39615 18 DNS variant TLDs

Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS. Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.

 draft-levine-tld-variant-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6927 RFC6928 Increasing TCP's Initial Window J. Chu N. Dukkipati Y. Cheng M. Mathis April 2013 ASCII 56523 24

This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. 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 resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.

 draft-ietf-tcpm-initcwnd-08 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6928 RFC6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions A. DeKok A. Lior April 2013 ASCII 133099 68

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 that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.

 draft-ietf-radext-radius-extensions-13 RFC2865 RFC3575 RFC6158 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6929 RFC6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) D. Guo S. Jiang Editor R. Despres R. Maglione April 2013 ASCII 23573 12

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.

 draft-ietf-softwire-6rd-radius-attrib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6930 10.17487/RFC6930 RFC6931 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2013 ASCII 75220 36

This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.

 draft-eastlake-additional-xmlsec-uris-10 RFC4051 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6931 10.17487/RFC6931 RFC6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry D. Harkins Editor May 2013 ASCII 20785 12 elliptic curve Diffie-Hellman

This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.

 draft-harkins-brainpool-ike-groups-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6932 RFC6933 Entity MIB (Version 4) A. Bierman D. Romascanu J. Quittek M. Chandramouli May 2013 ASCII 165278 76 management information base snmp simple network management 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 describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.

 draft-ietf-eman-rfc4133bis-06 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman http://www.rfc-editor.org/errata_search.php?rfc=6933 10.17487/RFC6933 RFC6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs) N. Bitar Editor S. Wadhwa Editor T. Haag H. Li June 2013 ASCII 104111 39

The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of 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 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-ancp-pon-05 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC6934 RFC6935 IPv6 and UDP Checksums for Tunneled Packets M. Eubanks P. Chimento M. Westerlund April 2013 ASCII 29055 12 Tunnel Encapsulation Integrity Packet Corruption Middlebox

This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.

 draft-ietf-6man-udpchecksums-08 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6935 10.17487/RFC6935 RFC6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums G. Fairhurst M. Westerlund April 2013 ASCII 99557 40

This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.

 draft-ietf-6man-udpzero-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6936 10.17487/RFC6936 RFC6937 Proportional Rate Reduction for TCP M. Mathis N. Dukkipati Y. Cheng May 2013 ASCII 39437 16 TCP loss recovery packet conservation self clock

This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.

 draft-ietf-tcpm-proportional-rate-reduction-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6937 RFC6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID J. Scudder May 2013 ASCII 3875 3 BGP

This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.

 draft-ietf-idr-deprecate-dpa-etal-00 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6938 RFC6939 Client Link-Layer Address Option in DHCPv6 G. Halwasia S. Bhandari W. Dec May 2013 ASCII 14739 7

This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.

 draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6939 RFC6940 REsource LOcation And Discovery (RELOAD) Base Protocol C. Jennings B. Lowekamp Editor E. Rescorla S. Baset H. Schulzrinne January 2014 ASCII 403862 176 p2p dht p2psip chord peer to peer

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 need to 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-base-26 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip http://www.rfc-editor.org/errata_search.php?rfc=6940 10.17487/RFC6940 RFC6941 MPLS Transport Profile (MPLS-TP) Security Framework L. Fang Editor B. Niven-Jenkins Editor S. Mansfield Editor R. Graveman Editor April 2013 ASCII 27119 15 threats mitigation defensive techniques

This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (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 as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.

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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network.

 draft-ietf-mpls-tp-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6941 RFC6942 Diameter Support for the EAP Re-authentication Protocol (ERP) J. Bournelle L. Morand S. Decugis Q. Wu G. Zorn May 2013 ASCII 35357 18

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 Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.

 draft-ietf-dime-erp-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6942 RFC6943 Issues in Identifier Comparison for Security Purposes D. Thaler Editor May 2013 ASCII 62676 26 Canonicalization Normalization Hostname URI IRI

Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security 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. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.

 draft-iab-identifier-comparison-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6943 RFC6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status S. Rose April 2013 ASCII 13876 7

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, but there is no record of 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. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.

 draft-ietf-dnsext-dnssec-algo-imp-status-04 RFC2536 RFC2539 RFC3110 RFC4034 RFC4398 RFC5155 RFC5702 RFC5933 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6944 10.17487/RFC6944 RFC6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush B. Wijnen K. Patel M. Baer May 2013 ASCII 52515 25

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 Resource Public Key Infrastructure (RPKI) to Router Protocol.

 draft-ietf-sidr-rpki-rtr-protocol-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6945 RFC6946 Processing of IPv6 "Atomic" Fragments F. Gont May 2013 ASCII 18843 9 fragmentation attacks vulnerabilities atomic fragments

The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by 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 normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.

 draft-ietf-6man-ipv6-atomic-fragments-04 RFC2460 RFC5722 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6946 10.17487/RFC6946 RFC6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute M. Boucadair H. Kaplan R. Gilman S. Veikkolainen May 2013 ASCII 51910 24

This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.

The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.

 draft-boucadair-mmusic-altc-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6947 RFC6948 Some Measurements on World IPv6 Day from an End-User Perspective A. Keranen J. Arkko July 2013 ASCII 25416 11 PDF 114829

During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.

 draft-keranen-ipv6day-measurements-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6948 RFC6949 RFC Series Format Requirements and Future Development H. Flanagan N. Brownlee May 2013 ASCII 29181 14

This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.

 draft-iab-rfcformatreq-03 RFC2223 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6949 RFC6950 Architectural Considerations on Application Features in the DNS J. Peterson O. Kolkman H. Tschofenig B. Aboba October 2013 ASCII 85548 31

A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.

 draft-iab-dns-applications-07 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6950 RFC6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication M. Tuexen R. Stewart May 2013 ASCII 25676 12

This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support 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.

Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.

This document covers only end-hosts and not tunneling (egress or ingress) endpoints.

 draft-ietf-tsvwg-sctp-udp-encaps-14 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6951 RFC6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide M. Jethanandani K. Patel L. Zheng May 2013 ASCII 37969 17 key authentication routing DoS

This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.

 draft-ietf-karp-routing-tcp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6952 RFC6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements A. Mancuso Editor S. Probasco B. Patil May 2013 ASCII 53560 23

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. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.

 draft-ietf-paws-problem-stmt-usecases-rqmts-15 INFORMATIONAL INFORMATIONAL IETF app paws 10.17487/RFC6953 RFC6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2) J. Merkle M. Lochter July 2013 ASCII 20366 11 IKE Elliptic Curve

This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).

 draft-merkle-ikev2-ke-brainpool-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6954 RFC6955 Diffie-Hellman Proof-of-Possession Algorithms J. Schaad H. Prafullchandra May 2013 ASCII 81491 43 POP ECDH DH

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.

This document obsoletes RFC 2875.

 draft-schaad-pkix-rfc2875-bis-08 RFC2875 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6955 RFC6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library W. Wang E. Haleplidis K. Ogawa C. Li J. Halpern June 2013 ASCII 236056 111 ForCES LFB Library

This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.

 draft-ietf-forces-lfb-lib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC6956 RFC6957 Duplicate Address Detection Proxy F. Costa J-M. Combes Editor X. Pougnard H. Li June 2013 ASCII 32537 16 IPv6 SLAAC DAD SAVI

The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, 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 defends the address rather than the device using the address.

 draft-ietf-6man-dad-proxy-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6957 RFC6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting A. Clark S. Zhang J. Zhao Q. Wu Editor May 2013 ASCII 31057 16 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock http://www.rfc-editor.org/errata_search.php?rfc=6958 10.17487/RFC6958 RFC6959 Source Address Validation Improvement (SAVI) Threat Scope D. McPherson F. Baker J. Halpern May 2013 ASCII 62217 25

The 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-savi-threat-scope-08 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC6959 RFC6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP S. Santesson M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 2013 ASCII 82037 41 PKIX digital security ocsp

This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.

 draft-ietf-pkix-rfc2560bis-20 RFC2560 RFC6277 RFC5912 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6960 RFC6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension Y. Pettersen June 2013 ASCII 21473 10 RFC 6066 RFC 2560 RFC 6960 RFC 5246 OCSP OCSP stapling multi-stapling certificate status checking revocation information status_request status_request_v2

This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.

 draft-ietf-tls-multiple-cert-status-extension-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6961 10.17487/RFC6961 RFC6962 Certificate Transparency B. Laurie A. Langley E. Kasper June 2013 ASCII 55048 27 TLS certificates

This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.

Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

 draft-laurie-pki-sunlight-12 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6962 10.17487/RFC6962 RFC6963 A Uniform Resource Name (URN) Namespace for Examples P. Saint-Andre May 2013 ASCII 11749 7 URN examples documentation

This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.

 draft-saintandre-urn-example-05 BCP0183 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6963 RFC6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin May 2013 ASCII 49568 20 IPv6 IPv4 IPv6/IPv4 IPv6-in-IPv4 tunnel automatic isatap enterprise site

Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

 draft-templin-v6ops-isops-19 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6964 RFC6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design L. Fang Editor N. Bitar R. Zhang M. Daikoku P. Pan August 2013 ASCII 36728 16

This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.

 draft-ietf-mpls-tp-use-cases-and-design-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6965 RFC6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments M. Boucadair J. Touch P. Levis R. Penno June 2013 ASCII 53498 24 NAT Host Identifier

This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.

This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.

 draft-ietf-intarea-nat-reveal-analysis-10 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6967 RFC6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca B. Adamson July 2013 ASCII 96399 40

This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered Coding Transport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.

 draft-ietf-rmt-fcast-08 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC6968 RFC6969 OSPFv3 Instance ID Registry Update A. Retana D. Cheng July 2013 ASCII 7959 4

This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates RFC 5838.

 draft-ietf-ospf-ospfv3-iid-registry-update-04 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6969 10.17487/RFC6969 RFC6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) M. Boucadair R. Penno D. Wing July 2013 ASCII 50900 23 UPnP pinhole PCP mapping NAT control interworking

This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.

 draft-ietf-pcp-upnp-igd-interworking-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC6970 RFC6971 Depth-First Forwarding (DFF) in Unreliable Networks U. Herberg Editor A. Cardenas T. Iwao M. Dow S. Cespedes June 2013 ASCII 95276 41 DFF Depth first forwarding IPv6 Forwarding plane Lossy networks Reliability

This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only.

 draft-cardenas-dff-14 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6971 10.17487/RFC6971 RFC6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) Y. Zhang N. Zong July 2013 ASCII 53634 22 P2P

Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols. This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer Streaming Protocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP.

 draft-ietf-ppsp-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF tsv ppsp 10.17487/RFC6972 RFC6973 Privacy Considerations for Internet Protocols A. Cooper H. Tschofenig B. Aboba J. Peterson J. Morris M. Hansen R. Smith July 2013 ASCII 89198 36 Disclosure Anonymity Pseudonymity Confidentiality Identity

This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.

 draft-iab-privacy-considerations-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6973 RFC6974 Applicability of MPLS Transport Profile for Ring Topologies Y. Weingarten S. Bryant D. Ceccarelli D. Caviglia F. Fondelli M. Corsi B. Wu X. Dai July 2013 ASCII 69318 30

This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.

 draft-ietf-mpls-tp-ring-protection-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6974 RFC6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC) S. Crocker S. Rose July 2013 ASCII 18353 9 DNS DNSSEC EDNS

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 document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.

 draft-ietf-dnsext-dnssec-algo-signal-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6975 RFC6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach M. Shand S. Bryant S. Previdi C. Filsfils P. Francois O. Bonaventure July 2013 ASCII 61011 28

This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.

This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.

After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.

The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

 draft-ietf-rtgwg-ordered-fib-12 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6976 RFC6977 Triggering DHCPv6 Reconfiguration from Relay Agents M. Boucadair X. Pougnard July 2013 ASCII 29769 13 Reconfigure-Request Reconfigure-Reply Link Address Option

This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.

 draft-ietf-dhc-triggered-reconfigure-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6977 RFC6978 A TCP Authentication Option Extension for NAT Traversal J. Touch July 2013 ASCII 11461 6 TCP-AO

This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.

 draft-touch-tcp-ao-nat-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6978 RFC6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) T. Pornin August 2013 ASCII 140386 79 dsa ecdsa digital signature deterministic

This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.

 draft-pornin-deterministic-dsa-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6979 10.17487/RFC6979 RFC6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery F. Gont August 2013 ASCII 20850 10 vulnerabilities evasion monitoring

This document analyzes the security implications of employing IPv6 fragmentation 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 countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.

 draft-ietf-6man-nd-extension-headers-05 RFC3971 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6980 RFC6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses S. Bryant S. Previdi M. Shand August 2013 ASCII 79311 34 not-via

This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.

The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

 draft-ietf-rtgwg-ipfrr-notvia-addresses-11 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6981 RFC6982 Improving Awareness of Running Code: The Implementation Status Section Y. Sheffer A. Farrel July 2013 ASCII 19358 9

This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.

 draft-sheffer-running-code-06 RFC7942 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6982 RFC6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI) R. van Brandenburg O. van Deventer F. Le Faucheur K. Leung July 2013 ASCII 107197 45 video caching HTTP content delivery

This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.

 draft-brandenburg-cdni-has-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6983 RFC6984 Interoperability Report for Forwarding and Control Element Separation (ForCES) W. Wang K. Ogawa E. Haleplidis M. Gao J. Hadi Salim August 2013 ASCII 70308 29

This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.

 draft-ietf-forces-interop-09 RFC6053 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6984 RFC6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing A. Morton July 2013 ASCII 19782 10 Traffic Pattern Benchmarking

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 a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX" ("Internet Mix"). 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 document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.

 draft-ietf-bmwg-imix-genome-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6985 RFC6986 GOST R 34.11-2012: Hash Function V. Dolmatov Editor A. Degtyarev August 2013 ASCII 78975 40

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.

 draft-dolmatov-gost34112012-01 RFC5831 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6986 RFC6987 OSPF Stub Router Advertisement A. Retana L. Nguyen A. Zinin R. White D. McPherson September 2013 ASCII 10890 7 ospf stub

This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.

This document obsoletes RFC 3137.

 draft-ietf-ospf-rfc3137bis-04 RFC3137 INFORMATIONAL INFORMATIONAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6987 10.17487/RFC6987 RFC6988 Requirements for Energy Management J. Quittek Editor M. Chandramouli R. Winter T. Dietz B. Claise September 2013 ASCII 58116 28 monitoring functions control functions

This document defines requirements for standards specifications for Energy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions. Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.

This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.

 draft-ietf-eman-requirements-14 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC6988 RFC6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Sheffer S. Fluhrer July 2013 ASCII 21099 10 Elliptic Curve cryptography secret key reuse recipient tests

This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.

 draft-ietf-ipsecme-dh-checks-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC6989 RFC6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting R. Huang Q. Wu H. Asaeda G. Zorn August 2013 ASCII 21657 11 RTCP XR MPEG2 PSI Decodability

An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP. The metrics specified in the RTCP XR block are not dependent on Program Specific Information (PSI) carried in MPEG-2 TS.

 draft-ietf-xrblock-rtcp-xr-decodability-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6990 RFC6991 Common YANG Data Types J. Schoenwaelder Editor July 2013 ASCII 60242 30 YANG data model netconf

This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.

 draft-ietf-netmod-rfc6021-bis-03 RFC6021 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6991 10.17487/RFC6991 RFC6992 Routing for IPv4-Embedded IPv6 Packets D. Cheng M. Boucadair A. Retana July 2013 ASCII 34703 15

This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.

 draft-ietf-ospf-ipv4-embedded-ipv6-routing-14 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC6992 RFC6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) P. Saint-Andre July 2013 ASCII 7431 5 SIP Call-Info header field Instant Messaging Presence

This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).

 draft-saintandre-impp-call-info-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6993 RFC6994 Shared Use of Experimental TCP Options J. Touch August 2013 ASCII 25577 11

This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.

 draft-ietf-tcpm-experimental-options-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6994 RFC6996 Autonomous System (AS) Reservation for Private Use J. Mitchell July 2013 ASCII 8198 4 asn

This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document.

 draft-ietf-idr-as-private-reservation-05 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6996 RFC6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks M. Goyal Editor E. Baccelli M. Philipp A. Brandt J. Martocci August 2013 ASCII 96596 40 P2P Routing RPL ROLL

This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.

 draft-ietf-roll-p2p-rpl-17 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6997 RFC6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network M. Goyal Editor E. Baccelli A. Brandt J. Martocci August 2013 ASCII 68274 29 Measurement Route Quality P2P Routes RPL ROLL

This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.

 draft-ietf-roll-p2p-measurement-10 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6998 RFC7001 Message Header Field for Indicating Message Authentication Status M. Kucherawy September 2013 ASCII 101316 43 DKIM DomainKeys SenderID SPF ADSP ATPS VBR Authentication Reputation

This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

 draft-ietf-appsawg-rfc5451bis-10 RFC5451 RFC6577 RFC7601 RFC7410 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7001 10.17487/RFC7001 RFC7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting A. Clark G. Zorn Q. Wu September 2013 ASCII 22523 12

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) 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-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7002 RFC7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting A. Clark R. Huang Q. Wu Editor September 2013 ASCII 25970 14 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock http://www.rfc-editor.org/errata_search.php?rfc=7003 10.17487/RFC7003 RFC7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting G. Zorn R. Schott Q. Wu Editor R. Huang September 2013 ASCII 41795 21 RTCP XR Summary Statistics Burst/Gap Loss Burst/Gap Discard Frame Impairment

This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-summary-stat-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7004 RFC7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting A. Clark V. Singh Q. Wu September 2013 ASCII 27050 14

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-jb-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7005 RFC7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) M. Garcia-Martin S. Veikkolainen R. Gilman September 2013 ASCII 47133 22 PDF 163470 title capability connection data capability bandwidth capability

The Session Description Protocol (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 session or media titles ("i=" line for each session or media).

 draft-ietf-mmusic-sdp-miscellaneous-caps-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=7006 10.17487/RFC7006 RFC7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) T. Terriberry August 2013 ASCII 6777 4

The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.

 draft-ietf-avtcore-avp-codecs-03 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7007 RFC7008 A Description of the KCipher-2 Encryption Algorithm S. Kiyomoto W. Shin August 2013 ASCII 71051 37 encryption stream cipher cipher

This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan.

 draft-kiyomoto-kcipher2-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7008 RFC7009 OAuth 2.0 Token Revocation T. Lodderstedt Editor S. Dronia M. Scurtescu August 2013 ASCII 23517 11

This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.

 draft-ietf-oauth-revocation-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7009 RFC7010 IPv6 Site Renumbering Gap Analysis B. Liu S. Jiang B. Carpenter S. Venaas W. George September 2013 ASCII 57067 26

This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering. The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process.

 draft-ietf-6renum-gap-analysis-08 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC7010 RFC7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information B. Claise Editor B. Trammell Editor P. Aitken September 2013 ASCII 170852 76

This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are 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-protocol-rfc5101bis-10 RFC5101 STD0077 INTERNET STANDARD INTERNET STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7011 10.17487/RFC7011 RFC7012 Information Model for IP Flow Information Export (IPFIX) B. Claise Editor B. Trammell Editor September 2013 ASCII 50237 24

This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model 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 this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.

 draft-ietf-ipfix-information-model-rfc5102bis-10 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7012 10.17487/RFC7012 RFC7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements B. Trammell B. Claise September 2013 ASCII 76406 32 IE-DOCTORS IANA

This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.

 draft-ietf-ipfix-ie-doctors-07 BCP0184 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops ipfix 10.17487/RFC7013 RFC7014 Flow Selection Techniques S. D'Antonio T. Zseby C. Henke L. Peluso September 2013 ASCII 72581 33

The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.

 draft-ietf-ipfix-flow-selection-tech-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7014 RFC7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol B. Trammell A. Wagner B. Claise September 2013 ASCII 112055 49 Flow metering Flow measurement IPFIX mediator

This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.

 draft-ietf-ipfix-a9n-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7015 RFC7016 Adobe's Secure Real-Time Media Flow Protocol M. Thornburgh November 2013 ASCII 236685 113 RTMFP

This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used.

 draft-thornburgh-adobe-rtmfp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7016 RFC7017 IMAP Access to IETF Email List Archives R. Sparks August 2013 ASCII 9886 5

The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service.

 draft-sparks-genarea-imaparch-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7017 RFC7018 Auto-Discovery VPN Problem Statement and Requirements V. Manral S. Hanna September 2013 ASCII 27284 12 IPsec Overlay SDN IKE

This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.

Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.

 draft-ietf-ipsecme-ad-vpn-problem-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC7018 RFC7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD) J. Buford M. Kolberg Editor September 2013 ASCII 83788 41 application-layer multicast

We define a REsource LOcation And Discovery (RELOAD) Usage for Application-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast.

This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).

 draft-irtf-samrg-sam-baseline-protocol-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7019 RFC7020 The Internet Numbers Registry System R. Housley J. Curran G. Huston D. Conrad August 2013 ASCII 19332 9

This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.

This document also provides information about the processes for further evolution of the Internet Numbers Registry System.

This document replaces RFC 2050.

This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.

 draft-housley-rfc2050bis-02 RFC2050 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7020 RFC7021 Assessing the Impact of Carrier-Grade NAT on Network Applications C. Donley Editor L. Howard V. Kuarsingh J. Berg J. Doshi September 2013 ASCII 66150 29 CGN NAT444 DS-Lite Dual-Stack Lite IPv4 NAT IPv6 LSN transition

NAT444 is an IPv4 extension technology being considered by Service Providers as a means 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 include the Dual-Stack Lite (DS-Lite) impacts also.

 draft-donley-nat444-impacts-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7021 RFC7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing E. Rescorla September 2013 ASCII 21717 10

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.

For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222.

 draft-ietf-avtcore-6222bis-06 RFC6222 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7022 RFC7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking D. Mohan Editor N. Bitar Editor A. Sajassi Editor S. DeLord P. Niger R. Qiu October 2013 ASCII 47621 23

This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (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-eth-oam-iwk-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7023 RFC7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs H. Jeng J. Uttaro L. Jalil B. Decraene Y. Rekhter R. Aggarwal October 2013 ASCII 62926 25

With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.

Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.

 draft-ietf-l3vpn-virtual-hub-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7024 RFC7025 Requirements for GMPLS Applications of PCE T. Otani K. Ogaki D. Caviglia F. Zhang C. Margaria September 2013 ASCII 26498 12 Path Computation CSPF PCC Traffic Engineering TE

The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.

 draft-ietf-pce-gmpls-aps-req-09 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7025 RFC7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel A. Farrel S. Bryant September 2013 ASCII 9297 5 ACH G-ACh Pseudowire PW MPLS-TP

The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs

No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.

This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.

 draft-ietf-mpls-retire-ach-tlv-03 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7026 RFC7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) J. Merkle M. Lochter October 2013 ASCII 16366 10 TLS Elliptic Curve Cryptography

This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.

 draft-merkle-tls-brainpool-04 RFC4492 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7027 10.17487/RFC7027 RFC7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 JC. Zuniga LM. Contreras CJ. Bernardos S. Jeon Y. Kim September 2013 ASCII 63110 29 multimob PMIPv6 MTMA selector MLD IGMP

This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. 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 Mobile Access Gateway can provide access to multicast content in the local network. The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.

 draft-ietf-multimob-pmipv6-ropt-08 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7028 RFC7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding S. Hartman M. Wasserman D. Zhang October 2013 ASCII 45360 19 MITM man-in-the-middle EMSK crypto binding Extended Master Session Key tunnel

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. Cryptographic binding is a facility described in RFC 3748 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 cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.

 draft-ietf-emu-crypto-bind-04 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC7029 RFC7030 Enrollment over Secure Transport M. Pritikin Editor P. Yee Editor D. Harkins Editor October 2013 ASCII 123989 53 pki est

This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.

 draft-ietf-pkix-est-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=7030 10.17487/RFC7030 RFC7031 DHCPv6 Failover Requirements T. Mrugalski K. Kinnear September 2013 ASCII 39321 17 DHCPv6 Failover

The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol.

 draft-ietf-dhc-dhcpv6-failover-requirements-07 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7031 RFC7032 LDP Downstream-on-Demand in Seamless MPLS T. Beckhaus Editor B. Decraene K. Tiruveedhula M. Konstantynowicz Editor L. Martini October 2013 ASCII 75588 35

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 networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (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-dod-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7032 RFC7033 WebFinger P. Jones G. Salgueiro M. Jones J. Smarr September 2013 ASCII 61552 28 WebFinger JRD JSON Resource Descriptor service discovery service discovery protocol information discovery information discovery protocol

This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.

 draft-ietf-appsawg-webfinger-18 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7033 RFC7034 HTTP Header Field X-Frame-Options D. Ross T. Gondrom October 2013 ASCII 27263 14 frame-options HTTP header websec

To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.

 draft-ietf-websec-x-frame-options-12 INFORMATIONAL INFORMATIONAL IETF app websec 10.17487/RFC7034 RFC7035 Relative Location Representation M. Thomson B. Rosen D. Stanley G. Bajko A. Thomson October 2013 ASCII 74709 39 Relative location

This document defines an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.

Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.

 draft-ietf-geopriv-relative-location-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7035 RFC7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group R. Housley October 2013 ASCII 14314 7

When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group. This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc.

 draft-housley-ltans-oids-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7036 RFC7037 RADIUS Option for the DHCPv6 Relay Agent L. Yeh M. Boucadair October 2013 ASCII 23356 10 DHCPv6 RADIUS

The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the Network Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.

 draft-ietf-dhc-dhcpv6-radius-opt-14 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7037 RFC7038 Use of OSPF-MDR in Single-Hop Broadcast Networks R. Ogier October 2013 ASCII 15535 7 routing mobile ad hoc network MANET designated router wireless point-to-multipoint interface

RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.

 draft-ietf-ospf-manet-single-hop-mdr-04 RFC5614 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7038 RFC7039 Source Address Validation Improvement (SAVI) Framework J. Wu J. Bi M. Bagnulo F. Baker C. Vogt Editor October 2013 ASCII 31946 14 anti-spoofing BCP38 ingress filtering

Source Address Validation Improvement (SAVI) 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 that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.

 draft-ietf-savi-framework-06 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC7039 RFC7040 Public IPv4-over-IPv6 Access Network Y. Cui J. Wu P. Wu O. Vautrin Y. Lee November 2013 ASCII 27273 13 Public 4over6 IPv4 over IPv6 Access Network DHCPv4 over IPv6 IPv6 Tunnel IPv6 Transition

This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.

 draft-ietf-softwire-public-4over6-10 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC7040 RFC7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging F. Balus Editor A. Sajassi Editor N. Bitar Editor November 2013 ASCII 31236 15

The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multiple Provider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability than Provider Bridges (PBs) in terms of the number of customer Media Access Control addresses and the number of service instances that can be supported.

The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid Spanning Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.

This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model.

 draft-ietf-l2vpn-pbb-vpls-pe-model-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7041 RFC7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters D. Eastlake 3rd J. Abley October 2013 ASCII 53488 27 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342.

 draft-eastlake-rfc5342bis-05 RFC5342 RFC2153 BCP0141 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7042 RFC7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS J. Abley October 2013 ASCII 15504 8 IEEE ethernet

48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique Identifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.

This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS.

This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated.

 draft-jabley-dnsext-eui48-eui64-rrtypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7043 RFC7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes F. Audet S. Schubert J. van Elburg C. Holmberg February 2014 ASCII 85068 36 history-info retarget enhanced services voicemail automatic call distribution

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-rfc4244bis-12 RFC4244 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=7044 10.17487/RFC7044 RFC7045 Transmission and Processing of IPv6 Extension Headers B. Carpenter S. Jiang December 2013 ASCII 21852 10

Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.

 draft-ietf-6man-ext-transmit-05 RFC2460 RFC2780 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7045 RFC7046 A Common API for Transparent Hybrid Multicast M. Waehlisch T. Schmidt S. Venaas December 2013 ASCII 85861 41 Peer-to-Peer (P2P) adaptive multicast multicast naming multicast addressing

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 that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.

 draft-irtf-samrg-common-api-11 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7046 RFC7047 The Open vSwitch Database Management Protocol B. Pfaff B. Davie Editor December 2013 ASCII 69446 35 vswitch virtualization overlay OVS

Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. The Open vSwitch project includes open-source OVSDB client and server implementations.

 draft-pfaff-ovsdb-proto-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7047 RFC7048 Neighbor Unreachability Detection Is Too Impatient E. Nordmark I. Gashinsky January 2014 ASCII 17946 8 6MAN IPv6 Neighbor Discovery

IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor -- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861.

 draft-ietf-6man-impatient-nud-07 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7048 RFC7049 Concise Binary Object Representation (CBOR) C. Bormann P. Hoffman October 2013 ASCII 134062 54 parser encoder binary format data interchange format JSON

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

 draft-bormann-cbor-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7049 10.17487/RFC7049 RFC7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis T. Savolainen J. Korhonen D. Wing November 2013 ASCII 50097 22 NAT64 DNS64 464XLAT Pref64::/n

This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.

 draft-ietf-behave-nat64-discovery-heuristic-17 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC7050 RFC7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix J. Korhonen Editor T. Savolainen Editor November 2013 ASCII 55248 25 NAT64 DNS64 464XLAT Pref64::/n

Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery.

 draft-ietf-behave-nat64-learn-analysis-03 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC7051 RFC7052 Locator/ID Separation Protocol (LISP) MIB G. Schudel A. Jain V. Moreno October 2013 ASCII 125519 66

This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.

 draft-ietf-lisp-mib-13 EXPERIMENTAL EXPERIMENTAL IETF int lisp http://www.rfc-editor.org/errata_search.php?rfc=7052 10.17487/RFC7052 RFC7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol M. Tuexen I. Ruengeler R. Stewart November 2013 ASCII 15773 8

This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.

 draft-ietf-tsvwg-sctp-sack-immediately-04 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7053 RFC7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) A. Farrel H. Endo R. Winter Y. Koike M. Paul November 2013 ASCII 25444 11

The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.

This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.

 draft-ietf-mpls-tp-mip-mep-map-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7054 RFC7055 A GSS-API Mechanism for the Extensible Authentication Protocol S. Hartman Editor J. Howlett December 2013 ASCII 87564 35

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 Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.

 draft-ietf-abfab-gss-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7055 RFC7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism S. Hartman J. Howlett December 2013 ASCII 24622 11

The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) 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, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes how to use the Naming Extensions API to access that information.

 draft-ietf-abfab-gss-eap-naming-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7056 RFC7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) S. Winter J. Salowey December 2013 ASCII 16006 7 EAP AAA

This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.

 draft-ietf-abfab-eapapplicability-06 RFC3748 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7057 RFC7058 Media Control Channel Framework (CFW) Call Flow Examples A. Amirante T. Castaldi L. Miniero S P. Romano November 2013 ASCII 387335 182 MediaCtrl Media Server Control Media Control Channel Framework

This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers.

 draft-ietf-mediactrl-call-flows-13 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC7058 RFC7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms S. Steffann I. van Beijnum R. van Rein November 2013 ASCII 98886 41

This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.

 draft-steffann-tunnels-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7059 RFC7060 Using LDP Multipoint Extensions on Targeted LDP Sessions M. Napierala E. Rosen IJ. Wijnands November 2013 ASCII 19384 9

Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.

 draft-ietf-mpls-targeted-mldp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7060 RFC7061 eXtensible Access Control Markup Language (XACML) XML Media Type R. Sinnema E. Wilde November 2013 ASCII 14666 8

This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).

 draft-sinnema-xacml-media-type-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7061 RFC7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks F. Zhang Editor D. Li H. Li S. Belotti D. Ceccarelli November 2013 ASCII 56109 26

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 (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.

 draft-ietf-ccamp-gmpls-g709-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7062 RFC7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments L. Zheng J. Zhang R. Parekh December 2013 ASCII 21964 12

This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard.

 draft-ietf-pim-rfc4601-update-survey-report-03 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC7063 RFC7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol S. Nandakumar G. Salgueiro P. Jones M. Petit-Huguenin November 2013 ASCII 15045 9

This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.

 draft-nandakumar-rtcweb-stun-uri-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7064 RFC7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers M. Petit-Huguenin S. Nandakumar G. Salgueiro P. Jones November 2013 ASCII 16143 9

This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).

 draft-petithuguenin-behave-turn-uris-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7065 RFC7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts J. Korhonen Editor J. Arkko Editor T. Savolainen S. Krishnan November 2013 ASCII 44253 20

As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.

 draft-ietf-v6ops-rfc3316bis-06 RFC3316 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7066 RFC7067 Directory Assistance Problem and High-Level Design Proposal L. Dunbar D. Eastlake 3rd R. Perlman I. Gashinsky November 2013 ASCII 34720 15 TRILL Orchestration Directory Push Pull RBridge ARP

Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus.

This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (Address Resolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.

 draft-ietf-trill-directory-framework-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7067 RFC7068 Diameter Overload Control Requirements E. McMurry B. Campbell November 2013 ASCII 69536 29

When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided.

 draft-ietf-dime-overload-reqs-13 INFORMATIONAL INFORMATIONAL IETF ops dime 10.17487/RFC7068 RFC7069 DECoupled Application Data Enroute (DECADE) R. Alimi A. Rahman D. Kutscher Y. Yang H. Song K. Pentikousis November 2013 ASCII 81867 35 decade

Content distribution applications, such as those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.

 draft-alimi-decade-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7069 RFC7070 An Architecture for Reputation Reporting N. Borenstein M. Kucherawy November 2013 ASCII 32262 14 domain security messaging dkim spf authentication reputation

This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model.

 draft-ietf-repute-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7070 RFC7071 A Media Type for Reputation Interchange N. Borenstein M. Kucherawy November 2013 ASCII 29541 17 reputation domain security messaging dkim spf authentication

This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.

 draft-ietf-repute-media-type-13 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7071 RFC7072 A Reputation Query Protocol N. Borenstein M. Kucherawy November 2013 ASCII 17416 9 reputation domain security messaging dkim spf authentication

This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.

 draft-ietf-repute-query-http-11 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7072 RFC7073 A Reputation Response Set for Email Identifiers N. Borenstein M. Kucherawy November 2013 ASCII 14857 8 reputation domain security messaging dkim spf authentication

This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.

 draft-ietf-repute-email-identifiers-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7073 RFC7074 Revised Definition of the GMPLS Switching Capability and Type Fields L. Berger J. Meuric November 2013 ASCII 19376 9

GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used 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 all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.

 draft-ietf-ccamp-swcaps-update-03 RFC3471 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7074 RFC7075 Realm-Based Redirection In Diameter T. Tsou R. Hao T. Taylor Editor November 2013 ASCII 21434 10 Diameter routing

The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".

This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs).

 draft-ietf-dime-realm-based-redirect-13 RFC6733 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7075 RFC7076 P6R's Secure Shell Public Key Subsystem M. Joseph J. Susoy November 2013 ASCII 20430 11 key management certificate management security

The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.

The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).

The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).

Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.

 draft-joseph-pkix-p6rsshextension-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7076 RFC7077 Update Notifications for Proxy Mobile IPv6 S. Krishnan S. Gundavelli M. Liebsch H. Yokota J. Korhonen November 2013 ASCII 49176 21 MIPv6

This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.

 draft-ietf-netext-update-notifications-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7077 RFC7078 Distributing Address Selection Policy Using DHCPv6 A. Matsumoto T. Fujisaki T. Chown January 2014 ASCII 25094 12

RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site.

 draft-ietf-6man-addr-select-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7078 RFC7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results N. Del Regno Editor A. Malis Editor November 2013 ASCII 67854 41 Control Word (CW) Control Channel (CC)

The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the Pseudowire / Virtual Circuit Connectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word.

 draft-ietf-pwe3-vccv-impl-survey-results-03 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7079 RFC7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges A. Sajassi S. Salam N. Bitar F. Balus December 2013 ASCII 61560 26 h-vpls

The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008. It aims to improve the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access.

 draft-ietf-l2vpn-pbb-vpls-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7080 RFC7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) E. Ivov P. Saint-Andre E. Marocco November 2013 ASCII 46772 19 real-time communication unified communication voice video instant messaging chat presence telephony

This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real-time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.

 draft-ivov-xmpp-cusax-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7081 RFC7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP) R. Shekh-Yusef M. Barnes December 2013 ASCII 18709 10

The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.

This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package.

 draft-yusef-dispatch-ccmp-indication-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7082 RFC7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT R. Droms November 2013 ASCII 14630 7

This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with new values.

 draft-ietf-dhc-dhcpv6-solmaxrt-update-05 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7083 RFC7084 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark November 2013 ASCII 46569 21 6rd DS-Lite

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 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.

 draft-ietf-v6ops-6204bis-12 RFC6204 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7084 RFC7085 Top-Level Domains That Are Already Dotless J. Levine P. Hoffman December 2013 ASCII 11369 6 DNS

Recent statements from the Internet Architecture Board (IAB) and the Internet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains"). In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them. This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others.

 draft-hoffine-already-dotless-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7085 RFC7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) A. Keranen G. Camarillo J. Maenpaa January 2014 ASCII 21406 10 HIP overlay P2P

This document is the HIP-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-reload-instance-10 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC7086 RFC7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations H. van Helvoort Editor L. Andersson Editor N. Sprecher Editor December 2013 ASCII 43925 21

The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (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 or 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-rosetta-stone-13 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7087 RFC7088 Session Initiation Protocol Service Example -- Music on Hold D. Worley February 2014 ASCII 69311 36 Music on hold

"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music-on-hold method described in Section 2.3 of RFC 5359.

 draft-worley-service-example-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7088 RFC7089 HTTP Framework for Time-Based Access to Resource States -- Memento H. Van de Sompel M. Nelson R. Sanderson December 2013 ASCII 107130 50 HTTP content negotiation datetime negotiation resource versions archival resources Memento

The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.

 draft-vandesompel-memento-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7089 RFC7090 Public Safety Answering Point (PSAP) Callback H. Schulzrinne H. Tschofenig C. Holmberg M. Patel April 2014 ASCII 37445 18 PSAP callback SIP emergency VoIP

After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel 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 state of an accident victim. A call taker may trigger a callback to 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 Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order 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. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to mark PSAP callbacks.

 draft-ietf-ecrit-psap-callback-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7090 RFC7091 GOST R 34.10-2012: Digital Signature Algorithm V. Dolmatov Editor A. Degtyarev December 2013 ASCII 39924 21

This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832.

 draft-dolmatov-gost34102012-00 RFC5832 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7091 RFC7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents H. Kaplan V. Pascual December 2013 ASCII 22085 10 SIP B2BUA taxonomy

In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).

There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.

 draft-ietf-straw-b2bua-taxonomy-03 INFORMATIONAL INFORMATIONAL IETF rai straw 10.17487/RFC7092 RFC7093 Additional Methods for Generating Key Identifiers Values S. Turner S. Kent J. Manger December 2013 ASCII 7622 5

This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions.

 draft-turner-additional-methods-4kis-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7093 RFC7094 Architectural Considerations of IP Anycast D. McPherson D. Oran D. Thaler E. Osterweil January 2014 ASCII 50246 22 anycast architecture

This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.

 draft-iab-anycast-arch-implications-12 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7094 RFC7095 jCard: The JSON Format for vCard P. Kewisch January 2014 ASCII 59088 29 jCard JSON vCard addressbook contacts CardDAV PIM

This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.

 draft-ietf-jcardcal-jcard-07 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal 10.17487/RFC7095 RFC7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) S. Belotti Editor P. Grandi D. Ceccarelli Editor D. Caviglia F. Zhang D. Li January 2014 ASCII 50281 23 Routing CCAMP Working Group OSPF GMPLS G709 OTN

ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs).

This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.

 draft-ietf-ccamp-otn-g709-info-model-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7096 RFC7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets J. Ott V. Singh Editor I. Curcio January 2014 ASCII 20581 11 RTP RTCP discard metrics

The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order 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 de- jitter buffer after successful reception.

 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7097 RFC7098 Using the IPv6 Flow Label for Load Balancing in Server Farms B. Carpenter S. Jiang W. Tarreau January 2014 ASCII 30884 13 ECMP

This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.

 draft-ietf-intarea-flow-label-balancing-03 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7098 RFC7100 Retirement of the "Internet Official Protocol Standards" Summary Document P. Resnick December 2013 ASCII 5365 3

This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.

 draft-resnick-retire-std1-01 RFC5000 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7100 RFC7101 List of Internet Official Protocol Standards: Replaced by a Web Page S. Ginoza December 2013 ASCII 6922 4

At one time, the RFC Editor published snapshots of the "Internet Official Protocol Standards". These documents were known as xx00 documents, the last of which was published in May 2008. These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs. As a result, the RFC Editor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment.

 draft-rfced-rfcxx00-retired-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7101 RFC7102 Terms Used in Routing for Low-Power and Lossy Networks JP. Vasseur January 2014 ASCII 16444 8

This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.

 draft-ietf-roll-terminology-13 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7102 RFC7103 Advice for Safe Handling of Malformed Messages M. Kucherawy G. Shapiro N. Freed January 2014 ASCII 48387 24 MTA SMTP

Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.

 draft-ietf-appsawg-malformed-mail-11 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC7103 RFC7104 Duplication Grouping Semantics in the Session Description Protocol A. Begen Y. Cai H. Ou January 2014 ASCII 17719 10 SDP ssrc synchronization source grouping framework

Packet loss is undesirable for real-time multimedia sessions, but it 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. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.

 draft-ietf-mmusic-duplication-grouping-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7104 RFC7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols M. Thomson J. Winterbottom January 2014 ASCII 155084 74 HELD Location Measurements Device-based

This document describes a protocol for a Device to provide location-related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.

 draft-ietf-geopriv-held-measurements-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7105 RFC7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State E. Ivov January 2014 ASCII 11939 6 SIP Conference Event Package service-uris conference-uris URI purpose

This document defines and registers a value of "grouptextchat" ("Group Text Chat") for the URI <purpose> element of SIP's Conference Event Package.

 draft-ivov-grouptextchat-purpose-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7106 RFC7107 Object Identifier Registry for the S/MIME Mail Security Working Group R. Housley January 2014 ASCII 43898 18

When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

 draft-housley-smime-oids-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7107 RFC7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes J. Abley T. Manderson January 2014 ASCII 24125 11

Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.

Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.

This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.

 draft-jabley-dnsop-anycast-mapping-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7108 10.17487/RFC7108 RFC7109 Flow Bindings Initiated by Home Agents for Mobile IPv6 H. Yokota D. Kim B. Sarikaya F. Xia February 2014 ASCII 40637 18 MIPv6 Flow mobility

There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.

 draft-yokota-mext-ha-init-flow-binding-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7109 RFC7110 Return Path Specified Label Switched Path (LSP) Ping M. Chen W. Cao S. Ning F. Jounay S. Delord January 2014 ASCII 44625 21 Tunnel Stack Reply TC

This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.

 draft-ietf-mpls-return-path-specified-lsp-ping-15 RFC7737 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7110 10.17487/RFC7110 RFC7111 URI Fragment Identifiers for the text/csv Media Type M. Hausenblas E. Wilde J. Tennison January 2014 ASCII 24818 13 mime

This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell. Fragment identification can use single items or ranges.

 draft-hausenblas-csv-fragment-08 RFC4180 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7111 RFC7112 Implications of Oversized IPv6 Header Chains F. Gont V. Manral R. Bonica January 2014 ASCII 15897 8

The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that 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 the First Fragment of a packet is required to contain the entire IPv6 Header Chain.

 draft-ietf-6man-oversized-header-chain-09 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7112 RFC7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) F. Gont February 2014 ASCII 29272 13

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-ra-guard-implementation-07 RFC6105 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7113 RFC7114 Creation of a Registry for smime-type Parameter Values B. Leiba January 2014 ASCII 7176 4

Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the Content-Type parameter "smime-type". As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values. This document creates the registry, registers the current values, and specifies the policies for registration of new values.

 draft-leiba-smime-type-registry-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7114 RFC7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) R. Bush January 2014 ASCII 26033 11

Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations. This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.

 draft-ietf-sidr-origin-ops-23 BCP0185 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC7115 RFC7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries K. Scott M. Blanchet February 2014 ASCII 18568 10

The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields 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 management. This document describes the necessary IANA actions.

 draft-dtnrg-ltp-cbhe-registries-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7116 RFC7117 Multicast in Virtual Private LAN Service (VPLS) R. Aggarwal Editor Y. Kamite L. Fang Y. Rekhter C. Kodeboniya February 2014 ASCII 126280 50

RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.

This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.

 draft-ietf-l2vpn-vpls-mcast-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7117 RFC7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) I. Baz Castillo J. Millan Villegas V. Pascual January 2014 ASCII 51248 25 SIP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.

 draft-ietf-sipcore-sip-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC7118 RFC7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators B. Claise A. Kobayashi B. Trammell February 2014 ASCII 74807 32

This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.

 draft-ietf-ipfix-mediation-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7119 RFC7120 Early IANA Allocation of Standards Track Code Points M. Cotton January 2014 ASCII 17722 9 early allocation policy protocol

This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.

 draft-cotton-rfc4020bis-02 RFC4020 BCP0100 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7120 RFC7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element K. Ogawa W. Wang E. Haleplidis J. Hadi Salim February 2014 ASCII 62599 31 ForCES HA

This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.

 draft-ietf-forces-ceha-10 RFC5810 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7121 RFC7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) H. Kruse S. Jero S. Ostermann March 2014 ASCII 25889 11

This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.

 draft-irtf-dtnrg-dgram-clayer-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7122 RFC7123 Security Implications of IPv6 on IPv4 Networks F. Gont W. Liu February 2014 ASCII 42374 19

This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.

 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7123 RFC7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili February 2014 ASCII 12123 6 EFM-CU-MIB ieee

This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group.

 draft-ietf-opsawg-rfc5066bis-07 RFC5066 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7124 RFC7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element B. Trammell P. Aitken February 2014 ASCII 11679 6

This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.

 draft-trammell-ipfix-tcpcontrolbits-revision-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7125 RFC7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options F. Gont R. Atkinson C. Pignataro February 2014 ASCII 72504 36

This 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-ietf-opsec-ip-options-filtering-07 BCP0186 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7126 RFC7127 Characterization of Proposed Standards O. Kolkman S. Bradner S. Turner January 2014 ASCII 9902 5 Guidance Standards Standards Process Advancement Proposed Standard

RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.

 draft-kolkman-proposed-standards-clarified-06 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7127 RFC7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report R. Bush R. Austein K. Patel H. Gredler M. Waehlisch February 2014 ASCII 19348 11 routing security

This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The 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-impl-05 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7128 RFC7129 Authenticated Denial of Existence in the DNS R. Gieben W. Mekking February 2014 ASCII 62936 30 Internet DNSSEC Denial of Existence NSEC NSEC3

Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.

This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.

 draft-gieben-auth-denial-of-existence-dns-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7129 RFC7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces M. Bhatia Editor M. Chen Editor S. Boutros Editor M. Binderberger Editor J. Haas Editor February 2014 ASCII 21291 11

This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link.

This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding.

 draft-ietf-bfd-on-lags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7130 RFC7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples M. Barnes F. Audet S. Schubert H. van Elburg C. Holmberg March 2014 ASCII 93039 52 SIP History-Info RFC4244bis Example Call Flow

This document describes use cases and documents call flows that 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-ietf-sipcore-rfc4244bis-callflows-08 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC7131 RFC7132 Threat Model for BGP Path Security S. Kent A. Chi February 2014 ASCII 52539 20 BGPSEC RPKI SIDR

This document describes a threat model for the context in which External Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI) and focuses on the ability of an Autonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI.

The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with a brief discussion of residual vulnerabilities.

 draft-ietf-sidr-bgpsec-threats-09 INFORMATIONAL INFORMATIONAL IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7132 10.17487/RFC7132 RFC7133 Information Elements for Data Link Layer Traffic Measurement S. Kashima A. Kobayashi Editor P. Aitken May 2014 ASCII 76209 41 IPFIX PSAMP Provider Bridge Provider Backbone Bridge ipfix

This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.

 draft-ietf-ipfix-data-link-layer-monitoring-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7133 RFC7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" B. Rosen March 2014 ASCII 3565 2 Resource-Priority Namespaces Resource-Priority Priority-values

RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC 4412 to change the management policy of these registries to "IETF Review".

 draft-rosen-rph-reg-policy-01 RFC4412 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC7134 RFC7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications J. Polk May 2014 ASCII 20749 9

This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace 'esnet' and registers this namespace with IANA. The new header field namespace allows for local emergency session establishment to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations.

 draft-polk-local-emergency-rph-namespace-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7135 RFC7136 Significance of IPv6 Interface Identifiers B. Carpenter S. Jiang February 2014 ASCII 23172 10

The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.

 draft-ietf-6man-ug-06 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7136 RFC7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks A. Retana S. Ratliff February 2014 ASCII 16017 8

This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.

This document updates RFC 5820.

 draft-ietf-ospf-manet-single-hop-or-04 RFC5820 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7137 RFC7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks D. Ceccarelli Editor F. Zhang S. Belotti R. Rao J. Drake March 2014 ASCII 77038 36 OSPF GMPLS G709 OTN

This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.

 draft-ietf-ccamp-gmpls-ospf-g709v3-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7138 RFC7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks F. Zhang Editor G. Zhang S. Belotti D. Ceccarelli K. Pithewan March 2014 ASCII 58382 27

ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.

This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.

 draft-ietf-ccamp-gmpls-signaling-g709v3-12 RFC4328 RFC7892 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7139 10.17487/RFC7139 RFC7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path L. Jin F. Jounay IJ. Wijnands N. Leymann March 2014 ASCII 33570 15 P2MP LSP MP2MP LSP

This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.

 draft-ietf-mpls-mldp-hsmp-06 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7140 RFC7141 Byte and Packet Congestion Notification B. Briscoe J. Manner February 2014 ASCII 103344 41 active queue management aqm availability denial of service dos quality of service qos congestion control fairness incentives architecture layering protocol

This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms.

 draft-ietf-tsvwg-byte-pkt-congest-12 RFC2309 RFC2914 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC7141 RFC7142 Reclassification of RFC 1142 to Historic M. Shand L. Ginsberg February 2014 ASCII 5036 3

This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain Routing Protocol", to Historic status. This memo also obsoletes RFC 1142.

 draft-ietf-isis-rfc1142-to-historic-00 RFC1142 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC7142 RFC7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated) M. Chadalapaka J. Satran K. Meth D. Black April 2014 ASCII 655576 295 iSCSI SCSI storage SAN block storage SCSI object storage devices OSD SAM disk T10

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 the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as 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. 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-cons-10 RFC3720 RFC3980 RFC4850 RFC5048 RFC3721 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7143 RFC7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update F. Knight M. Chadalapaka April 2014 ASCII 49817 25

Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in RFC 7143 (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.

 draft-ietf-storm-iscsi-sam-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7144 RFC7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification M. Ko A. Nezhinsky April 2014 ASCII 214093 91

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.

This document obsoletes RFC 5046.

 draft-ietf-storm-iser-15 RFC5046 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7145 RFC7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3 D. Black P. Koning April 2014 ASCII 37991 18 IPsec

RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP). This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.

 draft-ietf-storm-ipsec-ips-update-04 RFC3720 RFC3723 RFC3821 RFC3822 RFC4018 RFC4172 RFC4173 RFC4174 RFC5040 RFC5041 RFC5042 RFC5043 RFC5044 RFC5045 RFC5046 RFC5047 RFC5048 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7146 RFC7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI) M. Bakke P. Venkatesen April 2014 ASCII 175936 92 ISCSI-MIB

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 RFC 4544.

 draft-ietf-storm-iscsimib-04 RFC4544 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7147 RFC7148 Prefix Delegation Support for Proxy Mobile IPv6 X. Zhou J. Korhonen C. Williams S. Gundavelli CJ. Bernardos March 2014 ASCII 60422 27 Prefix Delegation Proxy Mobile IPv6 PMIPv6 Mobile Router

This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes.

 draft-ietf-netext-pd-pmip-14 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7148 RFC7149 Software-Defined Networking: A Perspective from within a Service Provider Environment M. Boucadair C. Jacquenet March 2014 ASCII 47516 20 Network Automation Policy Management Connectivity Provisioning Service Parameter Exposure Dynamic Negotiation Dynamic Service Provisioning Autonomic Programmable Networks

Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.

It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.

 draft-sin-sdnrg-sdn-approach-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7149 RFC7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2014 ASCII 24156 12

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.

 draft-ietf-pce-vendor-constraints-11 RFC7470 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7150 RFC7151 File Transfer Protocol HOST Command for Virtual Hosts P. Hethmon R. McMurray March 2014 ASCII 54330 24 FTP HOST

The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.

 draft-hethmon-mcmurray-ftpext-ftp-hosts-05 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7151 RFC7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) R. Key Editor S. DeLord F. Jounay L. Huang Z. Liu M. Paul March 2014 ASCII 22795 12 RMP Rooted-Multipoint VPLS Virtual Private LAN Service E-VPN Ethernet Virtual Private Network MPLS Multi-Protocol Label Switching CE Carrier Ethernet

This document provides functional requirements for the support of Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 2 Virtual Private Network solutions (referred to as simply "L2VPN"). It is intended that potential solutions will use these requirements as guidelines.

 draft-ietf-l2vpn-etree-reqt-05 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7152 RFC7153 IANA Registries for BGP Extended Communities E. Rosen Y. Rekhter March 2014 ASCII 30557 16 Border Gateway Protocol

This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 and RFC 5701.

 draft-ietf-idr-extcomm-iana-02 RFC4360 RFC5701 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7153 RFC7154 IETF Guidelines for Conduct S. Moonesamy Editor March 2014 ASCII 12363 7

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.

This document is an updated version of the guidelines for conduct originally published in RFC 3184.

 draft-moonesamy-ietf-conduct-3184bis-07 RFC3184 BCP0054 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7154 RFC7155 Diameter Network Access Server Application G. Zorn Editor April 2014 ASCII 154559 70 AAA Authentication Authorization Accounting Remote Access

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting 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-dime-rfc4005bis-14 RFC4005 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7155 RFC7156 Diameter Support for Proxy Mobile IPv6 Localized Routing G. Zorn Q. Wu J. Korhonen April 2014 ASCII 25657 11

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 a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol.

 draft-ietf-dime-pmip6-lr-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7156 RFC7157 IPv6 Multihoming without Network Address Translation O. Troan Editor D. Miles S. Matsushima T. Okimoto D. Wing March 2014 ASCII 49038 22 NPTv6

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 IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 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, but NPTv6 may be required as an intermediate solution.

 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7157 RFC7158 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII 27451 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

 draft-ietf-json-rfc4627bis-10 RFC7159 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7158 RFC7159 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII 27451 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

 draft-ietf-json-rfc4627bis-rfc7159bis RFC4627 RFC7158 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7159 10.17487/RFC7159 RFC7160 Support for Multiple Clock Rates in an RTP Session M. Petit-Huguenin G. Zorn Editor April 2014 ASCII 25255 13

This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550.

 draft-ietf-avtext-multiple-clock-rates-11 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7160 RFC7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) LM. Contreras CJ. Bernardos I. Soto March 2014 ASCII 85916 37 PMIPv6 Proxy Mobile IPv6 multicast handover SIAL

This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).

 draft-ietf-multimob-handover-optimization-07 EXPERIMENTAL EXPERIMENTAL IETF int multimob http://www.rfc-editor.org/errata_search.php?rfc=7161 10.17487/RFC7161 RFC7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) A. Melnikov D. Cridland May 2014 ASCII 111930 52 IMAP CONDSTORE QRESYNC VANISHED EXPUNGE quick resynchronization

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.

Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.

This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.

Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.

 draft-ietf-qresync-rfc5162bis-10 RFC4551 RFC5162 RFC2683 PROPOSED STANDARD PROPOSED STANDARD IETF app qresync 10.17487/RFC7162 RFC7163 URN for Country-Specific Emergency Services C. Holmberg I. Sedlacek March 2014 ASCII 7884 4 sip emergency urn country 5031 sos

This document updates the registration guidance provided in Section 4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country.

 draft-ietf-ecrit-country-emg-urn-03 RFC5031 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7163 RFC7164 RTP and Leap Seconds K. Gross R. Brandenburg March 2014 ASCII 20637 9 Leap second rtp Real-time Transport Protocol ntp Network Time Protocol UTC Universal Coordinated Time tai International Atomic Time Unix time

This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.

 draft-ietf-avtcore-leap-second-08 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7164 RFC7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) R. Barnes April 2014 ASCII 58324 25 JWS JWE JWK JWA JWT CMS S/MIME JOSE XMPP ALTO OAuth

Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1. Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.

 draft-ietf-jose-use-cases-06 INFORMATIONAL INFORMATIONAL IETF sec jose 10.17487/RFC7165 RFC7166 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem March 2014 ASCII 49533 23

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.

The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.

 draft-ietf-ospf-rfc6506bis-05 RFC6506 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7166 RFC7167 A Framework for Point-to-Multipoint MPLS in Transport Networks D. Frost S. Bryant M. Bocci L. Berger April 2014 ASCII 23842 12 mpls-tp mpls

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to-multipoint transport paths.

 draft-ietf-mpls-tp-p2mp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7167 RFC7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) I. Nazar April 1 2014 ASCII 14490 7

The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.

 draft-nazar-htcpcp-tea-00 RFC2324 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7168 RFC7169 The NSA (No Secrecy Afforded) Certificate Extension S. Turner April 1 2014 ASCII 5480 3

This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party. Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.

 draft-turner-no-secrecy-afforded-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7169 RFC7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1 H. Zhou N. Cam-Winget J. Salowey S. Hanna May 2014 ASCII 205545 101 EAP Tunnel

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) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.

 draft-ietf-emu-eap-tunnel-method-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC7170 RFC7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods N. Cam-Winget P. Sangster May 2014 ASCII 45604 19 NEA EAP

This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport Layer Security (TLS). The document also describes the intended applicability of PT-EAP.

 draft-ietf-nea-pt-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC7171 RFC7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling D. Eastlake 3rd M. Zhang P. Agarwal R. Perlman D. Dutt May 2014 ASCII 61855 27 TRILL VLAN Fine-Grained Label

The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.

 draft-ietf-trill-fine-labeling-07 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7172 RFC7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires L. Yong D. Eastlake 3rd S. Aldrin J. Hudson May 2014 ASCII 21280 11 TRILL pseudowires MPLS RBridge

This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.

 draft-ietf-trill-o-pw-06 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7173 RFC7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework S. Salam T. Senevirathne S. Aldrin D. Eastlake 3rd May 2014 ASCII 73464 33 RBridge CFM BFD MEP MIP MA Fault Performance Maintenance Continuity Connectivity Delay Operations Administration

This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM.

 draft-ietf-trill-oam-framework-04 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7174 RFC7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support V. Manral D. Eastlake 3rd D. Ward A. Banerjee May 2014 ASCII 24954 12 RBridge Echo one-hop

This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.

BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.

 draft-ietf-trill-rbridge-bfd-07 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7175 RFC7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake 3rd T. Senevirathne A. Ghanwani D. Dutt A. Banerjee May 2014 ASCII 98059 45 Affinity multicast multi-topology fine-grained VLAN

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides 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-ietf-isis-rfc6326bis-03 RFC6326 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7176 RFC7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani H. Yang V. Manral May 2014 ASCII 77117 35 RBridge TRILL Adjacency BFD p2p point-to-point

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System (IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325.

 draft-ietf-trill-rfc6327bis-04 RFC6327 RFC6325 RFC7780 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7177 RFC7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support D. Eastlake 3rd V. Manral Y. Li S. Aldrin D. Ward May 2014 ASCII 49461 21 TRILL native

This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.

 draft-ietf-trill-rbridge-channel-08 RFC7978 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7178 RFC7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension D. Eastlake 3rd A. Ghanwani V. Manral Y. Li C. Bestler May 2014 ASCII 25422 12 RBridge extension option

The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.

 draft-ietf-trill-rbridge-extension-05 RFC6325 RFC7780 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7179 RFC7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates D. Eastlake 3rd M. Zhang A. Ghanwani V. Manral A. Banerjee May 2014 ASCII 56276 24 TRILL RBridge IS-IS reachability overload MTU DEI multicast

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.

RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.

 draft-ietf-trill-clear-correct-06 RFC7780 RFC6325 RFC6327 RFC6439 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7180 RFC7181 The Optimized Link State Routing Protocol Version 2 T. Clausen C. Dearlove P. Jacquet U. Herberg April 2014 ASCII 253538 115 MANET ad hoc network NHDP

This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).

 draft-ietf-manet-olsrv2-19 RFC7183 RFC7187 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7181 10.17487/RFC7181 RFC7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen C. Dearlove April 2014 ASCII 68671 31 NHDP OLSRv2 security integrity routing

This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively.

 draft-ietf-manet-rfc6622-bis-06 RFC6622 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7182 RFC7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) U. Herberg C. Dearlove T. Clausen April 2014 ASCII 33255 15 MANET OLSRv2 Security Integrity protection ICV

This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time.

The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.

This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.

 draft-ietf-manet-nhdp-olsrv2-sec-05 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7183 10.17487/RFC7183 RFC7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 U. Herberg R. Cole T. Clausen April 2014 ASCII 175224 86 Network Management Management Information Base MIB SMIv2 Routing MANET Optimized Link STate Routing Protocol version 2

This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing Protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers.

 draft-ietf-manet-olsrv2-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7184 RFC7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale C. Dearlove T. Clausen P. Jacquet April 2014 ASCII 59906 25 MANET ad hoc network proactive NHDP neighborhood discovery OLSR OLSRv2 routing protocol metrics

The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.

 draft-ietf-manet-olsrv2-metrics-rationale-04 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC7185 RFC7186 Security Threats for the Neighborhood Discovery Protocol (NHDP) J. Yi U. Herberg T. Clausen April 2014 ASCII 45763 20

This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP) and describes their potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described.

 draft-ietf-manet-nhdp-sec-threats-06 RFC7985 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7186 10.17487/RFC7186 RFC7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) C. Dearlove T. Clausen April 2014 ASCII 9341 5

This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.

 draft-ietf-manet-olsrv2-rmpr-optimization-01 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7187 RFC7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs C. Dearlove T. Clausen April 2014 ASCII 36174 16 MANET OLSRv2 NHDP TLV

This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP).

 draft-ietf-manet-nhdp-olsrv2-tlv-extension-05 RFC6130 RFC7181 RFC7722 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7188 RFC7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP) G. Mirsky March 2014 ASCII 14254 7 PW VCCV MPLS-TP CC/CV/RDI

This document specifies how signaling and selection processes for Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs. This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined.

 draft-ietf-pwe3-mpls-tp-cv-adv-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7189 RFC7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) C. Villamizar March 2014 ASCII 36633 15 MPLS composite link link aggregation ECMP link bundling multipath MPLS-TP

Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.

Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.

 draft-ietf-mpls-multipath-use-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7190 RFC7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types R. Housley April 2014 ASCII 53803 25

This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.

 draft-housley-ct-keypackage-receipt-n-error-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7191 RFC7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types S. Turner April 2014 ASCII 11255 6 Key Package Key Package Receipt Key Package Error

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.

 draft-turner-ct-keypackage-receipt-n-error-algs-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7192 RFC7193 The application/cms Media Type S. Turner R. Housley J. Schaad April 2014 ASCII 23621 12 Cryptographic Message Syntax

This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.

 draft-turner-application-cms-media-type-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7193 10.17487/RFC7193 RFC7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL R. Hartmann August 2014 ASCII 9497 6

This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.

 draft-hartmann-default-port-for-irc-via-tls-ssl-09 RFC1459 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7194 RFC7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) M. Garcia-Martin S. Veikkolainen May 2014 ASCII 92699 39 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-cs-23 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7195 RFC7196 Making Route Flap Damping Usable C. Pelsser R. Bush K. Patel P. Mohapatra O. Maennel May 2014 ASCII 15202 8 rfd

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.

 draft-ietf-idr-rfd-usable-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7196 10.17487/RFC7196 RFC7197 Duplication Delay Attribute in the Session Description Protocol A. Begen Y. Cai H. Ou April 2014 ASCII 22559 11 Interleaving temporal diversity temporal redundancy time shifted delayed duplication

A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to 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-ietf-mmusic-delayed-duplication-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7197 RFC7198 Duplicating RTP Streams A. Begen C. Perkins April 2014 ASCII 29317 13 RTP duplication live/live redundancy

Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.

 draft-ietf-avtext-rtp-duplication-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7198 RFC7199 Location Configuration Extensions for Policy Management R. Barnes M. Thomson J. Winterbottom H. Tschofenig April 2014 ASCII 41313 20 geopriv geolocation privacy policy

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-policy-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7199 RFC7200 A Session Initiation Protocol (SIP) Load-Control Event Package C. Shen H. Schulzrinne A. Koike April 2014 ASCII 98689 44 SIP Overload Control Server Performance

This specification defines a load-control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts.

 draft-ietf-soc-load-control-event-package-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7200 RFC7201 Options for Securing RTP Sessions M. Westerlund C. Perkins April 2014 ASCII 92462 37 Secure RTP SRTP key management real-time media

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.

 draft-ietf-avtcore-rtp-security-options-10 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7201 RFC7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution C. Perkins M. Westerlund April 2014 ASCII 23428 10 SRTP RTP Profile Payload Format

This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.

 draft-ietf-avt-srtp-not-mandatory-16 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7202 RFC7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information T. Takahashi K. Landfield Y. Kadobayashi April 2014 ASCII 57694 28 data structure information architecture incident response response team security incident information exchange knowledge sharing security operation automation vulnerability CERT CSIRT

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.

 draft-ietf-mile-sci-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=7203 10.17487/RFC7203 RFC7204 Requirements for Labeled NFS T. Haynes April 2014 ASCII 39350 18 NFSv4

This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes but to describe the environment in which they reside.

 draft-ietf-nfsv4-labreqs-05 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC7204 RFC7205 Use Cases for Telepresence Multistreams A. Romanow S. Botzko M. Duckworth R. Even Editor April 2014 ASCII 42087 17

Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co-located presence through multimedia communication that includes at least audio and video signals of high fidelity. 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 enable 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-clue-telepresence-use-cases-09 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7205 RFC7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks P. Jones G. Salgueiro J. Polk L. Liess H. Kaplan May 2014 ASCII 28383 15

This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.

 draft-ietf-insipid-session-id-reqts-11 INFORMATIONAL INFORMATIONAL IETF rai insipid 10.17487/RFC7206 RFC7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging M. Ortseifen G. Dickfeld April 2014 ASCII 15690 8 URN Namespace Eurosystem TARGET2 TARGET2-Securities ESCB

This document defines and registers with IANA a Uniform Resource Name (URN) namespace for usage within messages standardized by the Eurosystem. The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB).

 draft-bundesbank-eurosystem-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7207 RFC7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 S. Kitterman April 2014 ASCII 144189 64 spoofing spf anti-forgery authentication

Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.

This document obsoletes RFC 4408.

 draft-ietf-spfbis-4408bis-21 RFC4408 RFC7372 PROPOSED STANDARD PROPOSED STANDARD IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=7208 10.17487/RFC7208 RFC7209 Requirements for Ethernet VPN (EVPN) A. Sajassi R. Aggarwal J. Uttaro N. Bitar W. Henderickx A. Isaac May 2014 ASCII 34040 15 ethernet l2vpn

The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (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 (EVPN) solution, which addresses the above issues.

 draft-ietf-l2vpn-evpn-req-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7209 RFC7210 Database of Long-Lived Symmetric Cryptographic Keys R. Housley T. Polk S. Hartman D. Zhang April 2014 ASCII 32642 14

This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database. In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.

 draft-ietf-karp-crypto-key-table-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg karp http://www.rfc-editor.org/errata_search.php?rfc=7210 10.17487/RFC7210 RFC7211 Operations Model for Router Keying S. Hartman D. Zhang June 2014 ASCII 47824 18

The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.

 draft-ietf-karp-ops-model-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC7211 RFC7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol D. Frost S. Bryant M. Bocci June 2014 ASCII 52340 23

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-gach-adv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7212 RFC7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing D. Frost S. Bryant M. Bocci June 2014 ASCII 20407 9 MPLS

The 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.

 draft-ietf-mpls-tp-ethernet-addressing-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7213 RFC7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry L. Andersson C. Pignataro May 2014 ASCII 12382 7

RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586.

This document also updates RFCs 6374, 6378, 6427, and 6428.

 draft-ietf-mpls-moving-iana-registries-04 RFC5586 RFC6374 RFC6378 RFC6427 RFC6428 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7214 RFC7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations L. Jakab A. Cabellos-Aparicio F. Coras J. Domingo-Pascual D. Lewis April 2014 ASCII 68686 30 LISP deployment

This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.

 draft-ietf-lisp-deployment-12 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC7215 RFC7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS M. Thomson R. Bellis April 2014 ASCII 39389 18 HELD LIS Discovery NAT Residential Gateway

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-geopriv-res-gw-lis-discovery-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7216 RFC7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) F. Gont April 2014 ASCII 48497 19

This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).

 draft-ietf-6man-stable-privacy-addresses-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7217 RFC7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) O. Gudmundsson April 2014 ASCII 8907 5 DNSSEC DANE Applications

Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records. This document updates the format of the IANA registry created by RFC 6698.

 draft-ietf-dane-registry-acronyms-04 RFC6698 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7218 RFC7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) M. Bagnulo A. Garcia-Martinez May 2014 ASCII 90423 38 IPv6 ingress filtering packet filtering Neighbor Discovery

This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.

 draft-ietf-savi-send-11 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7219 RFC7220 Description Option for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing May 2014 ASCII 11332 6

This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does this by defining a new DESCRIPTION option.

 draft-ietf-pcp-description-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7220 RFC7221 Handling of Internet-Drafts by IETF Working Groups A. Farrel D. Crocker Editor April 2014 ASCII 31669 14 IETF process working group Internet-Draft adoption handling creation

The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.

 draft-crocker-id-adoption-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7221 RFC7222 Quality-of-Service Option for Proxy Mobile IPv6 M. Liebsch P. Seite H. Yokota J. Korhonen S. Gundavelli May 2014 ASCII 139026 58 QoS Quality of Service PMIP-QoS PMIPv6-QoS WiFi-QoS 3GPP-QoS

This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.

 draft-ietf-netext-pmip6-qos-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7222 RFC7223 A YANG Data Model for Interface Management M. Bjorklund May 2014 ASCII 70537 39 NETCONF ietf-interfaces

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics).

 draft-ietf-netmod-interfaces-cfg-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7223 10.17487/RFC7223 RFC7224 IANA Interface Type YANG Module M. Bjorklund May 2014 ASCII 51377 37 yang netconf iana-if-type

This document defines the initial version of the iana-if-type YANG module.

 draft-ietf-netmod-iana-if-type-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7224 RFC7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) M. Boucadair May 2014 ASCII 40239 17

This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals.

 draft-ietf-pcp-nat64-prefix64-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7225 RFC7226 Requirements for Advanced Multipath in MPLS Networks C. Villamizar Editor D. McDysan Editor S. Ning A. Malis L. Yong May 2014 ASCII 38581 17 MPLS Advanced Multipath composite link link aggregation ECMP link bundling delay metric

This document provides a set of requirements for Advanced Multipath in MPLS networks.

Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.

 draft-ietf-rtgwg-cl-requirement-16 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7226 RFC7227 Guidelines for Creating New DHCPv6 Options D. Hankins T. Mrugalski M. Siodelski S. Jiang S. Krishnan May 2014 ASCII 83694 35 DHCPv6 option guidelines option guidance option format

This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.

 draft-ietf-dhc-option-guidelines-17 RFC3315 BCP0187 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=7227 10.17487/RFC7227 RFC7228 Terminology for Constrained-Node Networks C. Bormann M. Ersue A. Keranen May 2014 ASCII 37635 17 IoT Internet of Things Embedded Internet Smart Object Sensor Network WSN Constrained node Constrained network LLN LoWPAN 6LoWPAN Always-on Low-power Energy efficient

The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.

 draft-ietf-lwig-terminology-07 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC7228 RFC7229 Object Identifiers for Test Certificate Policies R. Housley May 2014 ASCII 6589 4

This document provides several certificate policy identifiers for testing certificate handling software.

 draft-housley-pkix-test-oids-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7229 RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing R. Fielding Editor J. Reschke Editor June 2014 ASCII 205947 89 Hyptertext Transfer Protocol HTTP HTTP message format

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

 draft-ietf-httpbis-p1-messaging-26 RFC2145 RFC2616 RFC2817 RFC2818 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7230 10.17487/RFC7230 RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content R. Fielding Editor J. Reschke Editor June 2014 ASCII 235053 101 Hypertext Transfer Protocol HTTP HTTP semantics HTTP payload HTTP content HTTP method HTTP status code

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.

 draft-ietf-httpbis-p2-semantics-26 RFC2616 RFC2817 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7231 10.17487/RFC7231 RFC7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests R. Fielding Editor J. Reschke Editor June 2014 ASCII 56696 28 HyperText Transfer Protocol HTTP HTTP conditional requests

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.

 draft-ietf-httpbis-p4-conditional-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7232 RFC7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests R. Fielding Editor Y. Lafon Editor J. Reschke Editor June 2014 ASCII 46933 25

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.

 draft-ietf-httpbis-p5-range-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7233 10.17487/RFC7233 RFC7234 Hypertext Transfer Protocol (HTTP/1.1): Caching R. Fielding Editor M. Nottingham Editor J. Reschke Editor June 2014 ASCII 90647 43 HTTP caching HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.

 draft-ietf-httpbis-p6-cache-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7234 10.17487/RFC7234 RFC7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication R. Fielding Editor J. Reschke Editor June 2014 ASCII 38142 19 HTTP authentication HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.

 draft-ietf-httpbis-p7-auth-26 RFC2616 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7235 RFC7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations J. Reschke June 2014 ASCII 5770 3 HyperText Transfer Protocol HTTP Authentication Authentication Scheme

This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.

 draft-ietf-httpbis-authscheme-registrations-10 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7236 RFC7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations J. Reschke June 2014 ASCII 8732 5 HyperText Transfer Protocol HTTP Request Method

This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.

 draft-ietf-httpbis-method-registrations-15 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7237 RFC7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke June 2014 ASCII 10623 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

 draft-reschke-http-status-308-07 RFC7538 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC7238 RFC7239 Forwarded HTTP Extension A. Petersson M. Nilsson June 2014 ASCII 35003 16 proxy x-forwarded-for x-forwarded-by x-forwarded-host x-forwarded-proto via

This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, 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-http-forwarded-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7239 RFC7240 Prefer Header for HTTP J. Snell June 2014 ASCII 32796 17 http prefer

This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.

 draft-snell-http-prefer-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7240 10.17487/RFC7240 RFC7241 The IEEE 802/IETF Relationship S. Dawkins P. Thaler D. Romascanu B. Aboba Editor July 2014 ASCII 80378 35 snmp aaa simple network management protocol authentication authorization accounting

This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.

Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.

 draft-iab-rfc4441rev-08 RFC4441 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7241 10.17487/RFC7241 RFC7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol M. Demmer J. Ott S. Perreault June 2014 ASCII 53818 22

This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG).

 draft-irtf-dtnrg-tcp-clayer-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7242 RFC7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric V. Singh Editor J. Ott I. Curcio May 2014 ASCII 23198 12 rtp reception statistics de-jitter buffer

The RTP Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) 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 report computing the bytes discarded from the de-jitter buffer after successful reception.

 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7243 RFC7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting H. Asaeda Q. Wu R. Huang May 2014 ASCII 27341 13

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-synchronization-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7244 RFC7245 An Architecture for Media Recording Using the Session Initiation Protocol A. Hutton Editor L. Portman Editor R. Jain K. Rehor May 2014 ASCII 34314 16 sip

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 that is based on the Session Initiation Protocol (SIP).

 draft-ietf-siprec-architecture-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC7245 RFC7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context IJ. Wijnands Editor P. Hitchen N. Leymann W. Henderickx A. Gulko J. Tantsura June 2014 ASCII 24698 13

An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.

 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7246 RFC7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII 57218 24 XMPP SIP

As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

 draft-ietf-stox-core-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7247 RFC7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII 60875 30 XMPP Jabber SIP SIMPLE IM Instant Messaging Presence

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

 draft-ietf-stox-presence-09 RFC8048 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7248 RFC7249 Internet Numbers Registries R. Housley May 2014 ASCII 10070 6

RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.

This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.

 draft-housley-number-registries-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7249 RFC7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Wouters Editor H. Tschofenig Editor J. Gilmore S. Weiler T. Kivinen June 2014 ASCII 38040 18 TLS DNSSEC DANE Raw Public Key

This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.

 draft-ietf-tls-oob-pubkey-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7250 RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS D. McGrew D. Bailey M. Campagna R. Dugal June 2014 ASCII 18851 10

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.

 draft-mcgrew-tls-aes-ccm-ecc-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7251 RFC7252 The Constrained Application Protocol (CoAP) Z. Shelby K. Hartke C. Bormann June 2014 ASCII 258789 112

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.

CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with 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-coap-18 RFC7959 PROPOSED STANDARD PROPOSED STANDARD IETF app core http://www.rfc-editor.org/errata_search.php?rfc=7252 10.17487/RFC7252 RFC7253 The OCB Authenticated-Encryption Algorithm T. Krovetz P. Rogaway May 2014 ASCII 39712 19 OCB AEAD authenticated-encryption

This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-ocb-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7253 RFC7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI) M. Montemurro Editor A. Allen D. McDonald P. Gosden May 2014 ASCII 33488 16 GSM UMTS LTE 3GPP Mobile identifier instance ID

This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and Software Version number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System (UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly.

 draft-montemurro-gsma-imei-urn-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7254 RFC7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID A. Allen Editor May 2014 ASCII 21606 9 GSM UMTS LTE 3GPP IMS SIP GRUU Mobile identifier instance ID

This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.

 draft-allen-dispatch-imei-urn-as-instanceid-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7255 RFC7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP) F. Le Faucheur R. Maglione T. Taylor July 2014 ASCII 234572 99

This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities:

o multicast replication initiated by the Network Access Server (NAS);

o conditional access and admission control with white and black lists;

o conditional access and admission control with grey lists;

o bandwidth delegation; and

o committed bandwidth reporting.

These capabilities may be combined according to the rules given in this specification.

This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.

 draft-ietf-ancp-mc-extensions-16 RFC6320 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC7256 RFC7257 Virtual Private LAN Service (VPLS) Management Information Base T. Nadeau Editor A. Kiran Koushik Editor R. Mediratta Editor July 2014 ASCII 89099 48

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 to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with the Pseudowire (PW) Management Information Base (PW-STD-MIB from RFC 5601).

 draft-ietf-l2vpn-vpls-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7257 10.17487/RFC7257 RFC7258 Pervasive Monitoring Is an Attack S. Farrell H. Tschofenig May 2014 ASCII 13396 6 pervasive monitoring

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

 draft-farrell-perpass-attack-06 BCP0188 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7258 RFC7259 The Jabber-ID Header Field P. Saint-Andre May 2014 ASCII 12816 7 Jabber XMPP Extensible Messaging and Presence Protocol email netnews message header field IM instant messaging

This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.

 draft-saintandre-jabberid-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7259 RFC7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration A. Takacs D. Fedyk J. He June 2014 ASCII 58030 24 MPLS-TP Transport Profile GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure 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 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.

 draft-ietf-ccamp-oam-configuration-fwk-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7260 10.17487/RFC7260 RFC7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B M. Perumal P. Ravindran May 2014 ASCII 14097 8 offer answer

This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.

 draft-ietf-mmusic-sdp-g723-g729-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7261 RFC7262 Requirements for Telepresence Multistreams A. Romanow S. Botzko M. Barnes June 2014 ASCII 26403 12

This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein.

 draft-ietf-clue-telepresence-requirements-07 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7262 RFC7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII 42104 20 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

 draft-ietf-p2psip-drr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7263 RFC7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII 31995 15 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

 draft-ietf-p2psip-rpr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7264 RFC7265 jCal: The JSON Format for iCalendar P. Kewisch C. Daboo M. Douglass May 2014 ASCII 56274 31

This specification defines "jCal", a JSON format for iCalendar data. The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.

 draft-ietf-jcardcal-jcal-10 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal http://www.rfc-editor.org/errata_search.php?rfc=7265 10.17487/RFC7265 RFC7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting A. Clark Q. Wu R. Schott G. Zorn June 2014 ASCII 48110 23

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-qoe-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7266 RFC7267 Dynamic Placement of Multi-Segment Pseudowires L. Martini Editor M. Bocci Editor F. Balus Editor June 2014 ASCII 49414 24 pw pw switching point pe sub-tlv

RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.

 draft-ietf-pwe3-dynamic-ms-pw-22 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7267 RFC7268 RADIUS Attributes for IEEE 802 Networks B. Aboba J. Malinen P. Congdon J. Salowey M. Jones July 2014 ASCII 56686 29

RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072.

 draft-ietf-radext-ieee802ext-12 RFC3580 RFC4072 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC7268 RFC7269 NAT64 Deployment Options and Experience G. Chen Z. Cao C. Xie D. Binet June 2014 ASCII 56043 22

This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.

 draft-ietf-v6ops-nat64-experience-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7269 RFC7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX) A. Yourtchenko P. Aitken B. Claise June 2014 ASCII 33990 21 IPFIX

This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.

 draft-yourtchenko-cisco-ies-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7270 RFC7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators J. Ryoo Editor E. Gray Editor H. van Helvoort A. D'Alessandro T. Cheung E. Osborne June 2014 ASCII 87586 40 PSC mode APS mode capabilities priority non-revertive MS-W support SD support EXER support

This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.

This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.

This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.

This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.

 draft-ietf-mpls-tp-psc-itu-04 RFC6378 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7271 RFC7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) R. van Brandenburg H. Stokking O. van Deventer F. Boronat M. Montagud K. Gross June 2014 ASCII 56261 23 Inter-Destination Media Synchronization RTP Control Protocol RTCP

This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.

Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.

 draft-ietf-avtcore-idms-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7272 RFC7273 RTP Clock Source Signalling A. Williams K. Gross R. van Brandenburg H. Stokking June 2014 ASCII 63009 30 clock source

NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.

 draft-ietf-avtcore-clksrc-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore http://www.rfc-editor.org/errata_search.php?rfc=7273 10.17487/RFC7273 RFC7274 Allocating and Retiring Special-Purpose MPLS Labels K. Kompella L. Andersson A. Farrel June 2014 ASCII 23442 11

Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.

As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.

This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.

This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.

 draft-ietf-mpls-special-purpose-labels-06 RFC3032 RFC3038 RFC3209 RFC3811 RFC4182 RFC4928 RFC5331 RFC5586 RFC5921 RFC5960 RFC6391 RFC6478 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7274 RFC7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy L. Martini S. Salam A. Sajassi M. Bocci S. Matsushima T. Nadeau June 2014 ASCII 172294 83 iccp

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 among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.

 draft-ietf-pwe3-iccp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7275 RFC7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools T. Mizrahi N. Sprecher E. Bellagamba Y. Weingarten June 2014 ASCII 120925 53

Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.

This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.

The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.

 draft-ietf-opsawg-oam-overview-16 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7276 RFC7277 A YANG Data Model for IP Management M. Bjorklund June 2014 ASCII 50043 30 netmod

This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data.

 draft-ietf-netmod-ip-cfg-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7277 RFC7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link C. Byrne D. Drown A. Vizdal June 2014 ASCII 19965 10

This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.

 draft-ietf-v6ops-64share-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7278 RFC7279 An Acceptable Use Policy for New ICMP Types and Codes M. Shore C. Pignataro May 2014 ASCII 17829 10 icmp icmpv4 icmpv6

In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use.

This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.

 draft-shore-icmp-aup-12 BCP0189 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7279 RFC7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry G. Fairhurst June 2014 ASCII 14954 7 ULE IANA

This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next- Header registry. This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols.

 draft-fairhurst-ipdvb-ule-iana-07 RFC4326 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7280 RFC7281 Authentication-Results Registration for S/MIME Signature Verification A. Melnikov June 2014 ASCII 23717 11 Authentication-Results S/MIME

RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication- Results header field for S/MIME-related signature checks.

 draft-melnikov-authentication-results-smime-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7281 RFC7282 On Consensus and Humming in the IETF P. Resnick June 2014 ASCII 52339 19 accommodate agree agreement appease argue argument balloting capitulated capitulation chair choice choose coin compromise count decide decision disagree disagreement hands horse-trade horse-trading hum issue judge judging king majority member minority object objection objector president rough unaddressed vote voting working group

The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.

Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.

 draft-resnick-on-consensus-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7282 RFC7283 Handling Unknown DHCPv6 Messages Y. Cui Q. Sun T. Lemon July 2014 ASCII 13021 7 DHCPv6 Unknown Messages

DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315.

 draft-ietf-dhc-dhcpv6-unknown-msg-08 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7283 RFC7284 The Profile URI Registry M. Lanthaler June 2014 ASCII 8848 5 profile profiles URI registry

This document defines a registry for profile URIs to be used in specifications standardizing profiles.

 draft-lanthaler-profile-registry-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7284 RFC7285 Application-Layer Traffic Optimization (ALTO) Protocol R. Alimi Editor R. Penno Editor Y. Yang Editor S. Kiesel S. Previdi W. Roome S. Shalunov R. Woundy September 2014 ASCII 194499 91 ALTO Information Resources Network Map PID Filtered Network Map Cost Map Endpoint Property Service Endpoint Cost Service

Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.

The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.

This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.

 draft-ietf-alto-protocol-27 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC7285 RFC7286 Application-Layer Traffic Optimization (ALTO) Server Discovery S. Kiesel M. Stiemerling N. Schwan M. Scharf H. Song November 2014 ASCII 32830 15

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers.

This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.

 draft-ietf-alto-server-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC7286 RFC7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt Editor S. Gao H. Zhang M. Waehlisch June 2014 ASCII 66766 28

Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.

 draft-ietf-multimob-pmipv6-source-09 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7287 RFC7288 Reflections on Host Firewalls D. Thaler June 2014 ASCII 28885 13 Filter Filtering

In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice. Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.

 draft-iab-host-firewalls-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7288 RFC7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs V. Kuarsingh Editor J. Cianfarani June 2014 ASCII 45731 20 NAT444 LSN Large-Scale NAT

This document specifies a framework to integrate a Network Address Translation (NAT) layer into an operator's network to function as a Carrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. 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 that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs, which allow for virtual routing separation, helping ease the CGN's impact on the network. This document does not intend to defend the merits of CGN.

 draft-ietf-opsawg-lsn-deployment-06 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7289 RFC7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser July 2014 ASCII 59898 31 packet loss IPPM implementation comparison perfas+ netem IPPM comparison metric test, WIPM NetProbe

This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. 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 2680.

 draft-ietf-ippm-testplan-rfc2680-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7290 RFC7291 DHCP Options for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing July 2014 ASCII 20868 11 PCP Server discovery Port Mapping Shared Address

This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document.

 draft-ietf-pcp-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7291 RFC7292 PKCS #12: Personal Information Exchange Syntax v1.1 K. Moriarty Editor M. Nystrom S. Parkinson A. Rusch M. Scott July 2014 ASCII 58991 29 PKCS#12 PKCS12v1.1 PKCS#12v1.1

PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.

This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

 draft-moriarty-pkcs12v1-1-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7292 10.17487/RFC7292 RFC7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension W. Mills M. Kucherawy July 2014 ASCII 54440 24 Security Privacy Email Account Expiration

This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension.

The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications.

 draft-ietf-appsawg-rrvs-header-field-11 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7293 RFC7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications A. Clark G. Zorn C. Bi Q. Wu July 2014 ASCII 43611 22 Real Time Control Protocol

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.

 draft-ietf-xrblock-rtcp-xr-loss-conceal-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7294 RFC7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication H. Tschofenig L. Eggert Z. Sarker July 2014 ASCII 59655 26 Congestion Control RTCWEB Workshop Real-Time Communication

This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.

The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).

 draft-iab-cc-workshop-report-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7295 RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen T. Kivinen October 2014 ASCII 354358 142 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.

 draft-kivinen-ipsecme-ikev2-rfc5996bis-04 RFC5996 RFC7427 RFC7670 STD0079 INTERNET STANDARD INTERNET STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7296 10.17487/RFC7296 RFC7297 IP Connectivity Provisioning Profile (CPP) M. Boucadair C. Jacquenet N. Wang July 2014 ASCII 48281 22

This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.

Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.

 draft-boucadair-connectivity-provisioning-profile-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7297 RFC7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication D. Ovsienko July 2014 ASCII 128503 55 routing protocol authentication applied cryptography

This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.

 draft-ovsienko-babel-hmac-authentication-09 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7298 RFC7299 Object Identifier Registry for the PKIX Working Group R. Housley July 2014 ASCII 65861 30 Public-Key Infrastructure using X.509

When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

 draft-housley-pkix-oids-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7299 RFC7300 Reservation of Last Autonomous System (AS) Numbers J. Haas J. Mitchell July 2014 ASCII 7952 5 asn last asns

This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as "Last ASNs", and provides guidance to implementers and operators on their use. This document updates Section 10 of RFC 1930.

 draft-ietf-idr-last-as-reservation-07 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC7300 RFC7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension S. Friedl A. Popov A. Langley E. Stephan July 2014 ASCII 17439 9 ALPN

This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.

 draft-ietf-tls-applayerprotoneg-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7301 RFC7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux July 2014 ASCII 14419 8 EIDR Entertainment Identifier Registry URN

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.

 draft-pal-eidr-urn-03 RFC7972 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7302 RFC7303 XML Media Types H. Thompson C. Lilley July 2014 ASCII 77654 35 application/xml application/xml-external-parsed-entity application/xml-dtd text/xml text/xml-external-parsed-entity +xml

This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.

 draft-ietf-appsawg-xml-mediatypes-10 RFC3023 RFC6839 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7303 10.17487/RFC7303 RFC7304 A Method for Mitigating Namespace Collisions W. Kumari July 2014 ASCII 6626 4

This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.

 draft-wkumari-dnsop-defense-collision-mitigate-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7304 RFC7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) E. Lear Editor July 2014 ASCII 37799 17

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-itat-report-04 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7305 10.17487/RFC7305 RFC7306 Remote Direct Memory Access (RDMA) Protocol Extensions H. Shah F. Marti W. Noureddine A. Eiriksson R. Sharp June 2014 ASCII 73986 34 iWARP RDMAP DDP RDMA DMA

This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP) as specified in RFC 5040. 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-storm-rdmap-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm http://www.rfc-editor.org/errata_search.php?rfc=7306 10.17487/RFC7306 RFC7307 LDP Extensions for Multi-Topology Q. Zhao K. Raza C. Zhou L. Fang L. Li D. King July 2014 ASCII 39530 20 MT Label Distribution Protocol

Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. 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-ldp-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7307 RFC7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) E. Osborne July 2014 ASCII 14811 7 colors link colors igp te extensions

MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).

This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.

 draft-ietf-mpls-extended-admin-group-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7308 RFC7309 Redundancy Mechanism for Inter-domain VPLS Service Z. Liu L. Jin R. Chen D. Cai S. Salam July 2014 ASCII 24644 12 ICCP PW

In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains.

 draft-ietf-l2vpn-vpls-inter-domain-redundancy-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7309 RFC7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs J. Lindsay H. Foerster July 2014 ASCII 32743 16

This document specifies a scheme for packetizing Standard apt-X or Enhanced apt-X encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).

 draft-ietf-payload-rtp-aptx-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC7310 RFC7311 The Accumulated IGP Metric Attribute for BGP P. Mohapatra R. Fernando E. Rosen J. Uttaro August 2014 ASCII 32615 15

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-aigp-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7311 RFC7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) J. Fabini A. Morton August 2014 ASCII 41125 17 Measurement Wireless Reactive Repeatability Continuity Actionable Conservative Spatial Composition Temporal Composition

To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.

 draft-ietf-ippm-2330-update-05 RFC2330 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7312 RFC7313 Enhanced Route Refresh Capability for BGP-4 K. Patel E. Chen B. Venkatachalapathy July 2014 ASCII 15111 8 Border Gateway Protocol bgp rib BGP Routing Information Base

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 correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.

 draft-ietf-idr-bgp-enhanced-route-refresh-10 RFC2918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7313 RFC7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option M. Andrews July 2014 ASCII 8473 4 IXFR AXFR zone transfer DNS SOA

This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.

 draft-andrews-dnsext-expire-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7314 RFC7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP R. Jesske K. Drage C. Holmberg July 2014 ASCII 101144 43

This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.

 draft-drage-sipping-rfc3455bis-14 RFC3455 RFC7913 RFC7976 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7315 10.17487/RFC7315 RFC7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header) J. van Elburg K. Drage M. Ohsugi S. Schubert K. Arai July 2014 ASCII 33599 15

This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP. The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.

 draft-vanelburg-dispatch-private-network-ind-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7316 RFC7317 A YANG Data Model for System Management A. Bierman M. Bjorklund August 2014 ASCII 60119 35 NETCONF

This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.

 draft-ietf-netmod-system-mgmt-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7317 10.17487/RFC7317 RFC7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates A. Newton G. Huston July 2014 ASCII 8214 5

This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource Public Key Infrastructure (RPKI) resource certificates.

 draft-ietf-sidr-policy-qualifiers-02 RFC6487 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7318 RFC7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points D. Eastlake 3rd July 2014 ASCII 7759 5 CFM OAM Connectivity Continuity Fault IANA TRILL

IEEE 802.1 has specified Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA considerations for the assignment of values from these blocks.

 draft-eastlake-iana-cfm-considerations-02 BCP0191 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7319 RFC7320 URI Design and Ownership M. Nottingham July 2014 ASCII 18275 9 URI structure

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards.

 draft-ietf-appsawg-uri-get-off-my-lawn-05 RFC3986 BCP0190 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7320 10.17487/RFC7320 RFC7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. McGrew P. Hoffman August 2014 ASCII 25724 11

This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.

ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.

 draft-ietf-ipsecme-esp-ah-reqts-10 RFC4835 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7321 RFC7322 RFC Style Guide H. Flanagan S. Ginoza September 2014 ASCII 49915 24 editorial guidance format style manual house style

This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".

 draft-iab-styleguide-02 RFC2223 RFC7997 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7322 RFC7323 TCP Extensions for High Performance D. Borman B. Braden V. Jacobson R. Scheffenegger Editor September 2014 ASCII 106013 49 Timestamps Timestamp RTT RTTM Window Scale PAWS TCP options

This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.

This document obsoletes RFC 1323 and describes changes from it.

 draft-ietf-tcpm-1323bis-21 RFC1323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC7323 RFC7324 Updates to MPLS Transport Profile Linear Protection E. Osborne July 2014 ASCII 23687 11 multiprotocol label switching mpls-tp psc protection state coordination

This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.

 draft-ietf-mpls-psc-updates-06 RFC6378 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7324 RFC7325 MPLS Forwarding Compliance and Performance Requirements C. Villamizar Editor K. Kompella S. Amante A. Malis C. Pignataro August 2014 ASCII 139536 59 MPLS ECMP link bundling multipath MPLS-TP forwarding

This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers.

 draft-ietf-mpls-forwarding-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7325 RFC7326 Energy Management Framework J. Parello B. Claise B. Schoening J. Quittek September 2014 ASCII 107145 54

This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks. The framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between Energy Objects.

 draft-ietf-eman-framework-19 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC7326 RFC7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML R. Gieben August 2014 ASCII 17590 10

This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) or RFCs.

The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML.

 draft-gieben-pandoc2rfc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7328 RFC7329 A Session Identifier for the Session Initiation Protocol (SIP) H. Kaplan August 2014 ASCII 39057 17

There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.

The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.

 draft-kaplan-insipid-session-id-04 RFC7989 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7329 RFC7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management T. Nadeau Z. Ali N. Akiya August 2014 ASCII 20910 11 Network Management management Information Base MIB SMIv2 BFD

This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations.

 draft-ietf-bfd-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7330 RFC7331 Bidirectional Forwarding Detection (BFD) Management Information Base T. Nadeau Z. Ali N. Akiya August 2014 ASCII 72272 39 Network Management Management Information Base MIB SMIv2 BFD

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 managed objects for modeling the Bidirectional Forwarding Detection (BFD) protocol.

 draft-ietf-bfd-mib-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7331 10.17487/RFC7331 RFC7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) H. Kaplan V. Pascual August 2014 ASCII 11157 5

SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.

 draft-ietf-straw-b2bua-loop-detection-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw http://www.rfc-editor.org/errata_search.php?rfc=7332 10.17487/RFC7332 RFC7333 Requirements for Distributed Mobility Management H. Chan Editor D. Liu P. Seite H. Yokota J. Korhonen August 2014 ASCII 50110 24 Distributed Mobility Management Network function distribution Flat mobile network Mobile network operation and management Control and data plane separation

This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described.

 draft-ietf-dmm-requirements-17 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7333 RFC7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths Q. Zhao D. Dhody D. King Z. Ali R. Casellas August 2014 ASCII 48897 25 Core-tree

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-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.

This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.

 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08 EXPERIMENTAL EXPERIMENTAL IETF rtg pce 10.17487/RFC7334 RFC7335 IPv4 Service Continuity Prefix C. Byrne August 2014 ASCII 7763 4

Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element. Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.

 draft-ietf-v6ops-clatip-04 RFC6333 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC7335 RFC7336 Framework for Content Distribution Network Interconnection (CDNI) L. Peterson B. Davie R. van Brandenburg Editor August 2014 ASCII 145294 58 CDNI content delivery network federation cdni request routing cdni logging cdmi metadata cdni control

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. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. 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. This document, in combination with RFC 6707, obsoletes RFC 3466.

 draft-ietf-cdni-framework-14 RFC3466 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7336 RFC7337 Content Distribution Network Interconnection (CDNI) Requirements K. Leung Editor Y. Lee Editor August 2014 ASCII 55208 23

Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.

The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.

 draft-ietf-cdni-requirements-17 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7337 RFC7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks F. Jounay Editor Y. Kamite Editor G. Heron M. Bocci September 2014 ASCII 36120 18

This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point-to-multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).

 draft-ietf-pwe3-p2mp-pw-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7338 RFC7339 Session Initiation Protocol (SIP) Overload Control V. Gurbani Editor V. Hilt H. Schulzrinne September 2014 ASCII 89898 38 SIP Overload Control

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all the 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 behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.

 draft-ietf-soc-overload-control-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7339 RFC7340 Secure Telephone Identity Problem Statement and Requirements J. Peterson H. Schulzrinne H. Tschofenig September 2014 ASCII 65026 25 SIP XMPP Secure Origin Identification Communication Security RTCWeb Problem Statement Real-Time Communication

Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.

 draft-ietf-stir-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7340 RFC7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport Q. Sun Y. Cui M. Siodelski S. Krishnan I. Farrer August 2014 ASCII 35599 16 ipv6 transition softwire migration tunnel residual ipv4 dhcpv6 relay ipv6-only

IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.

 draft-ietf-dhc-dhcpv4-over-dhcpv6-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7341 RFC7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers L. Dunbar W. Kumari I. Gashinsky August 2014 ASCII 28413 14

This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.

 draft-dunbar-armd-arp-nd-scaling-practices-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7342 RFC7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) J. Laganier F. Dupont September 2014 ASCII 28699 14 HIP HIPv2 ORCHID CGA API

This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.

 draft-ietf-hip-rfc4843-bis-08 RFC4843 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7343 RFC7344 Automating DNSSEC Delegation Trust Maintenance W. Kumari O. Gudmundsson G. Barwood September 2014 ASCII 39434 18 key roll trust anchor CDS CDNSKEY DNSSEC DNS

This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.

 draft-ietf-dnsop-delegation-trust-maintainance-14 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7344 RFC7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) C. Holmberg I. Sedlacek G. Salgueiro August 2014 ASCII 42943 23 SDP SIP DTLS UDPTL fax transport

This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).

 draft-ietf-mmusic-udptl-dtls-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7345 RFC7346 IPv6 Multicast Address Scopes R. Droms August 2014 ASCII 10831 6 IPv6 multicast address scopes

This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.

 draft-ietf-6man-multicast-scopes-07 RFC4007 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7346 RFC7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP) H. van Helvoort Editor J. Ryoo Editor H. Zhang F. Huang H. Li A. D'Alessandro September 2014 ASCII 70158 32 PDF 394963

The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.

This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.

The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.

 draft-zulr-mpls-tp-linear-protection-switching-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7347 RFC7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks M. Mahalingam D. Dutt K. Duda P. Agarwal L. Kreeger T. Sridhar M. Bursell C. Wright August 2014 ASCII 49406 22

This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.

 draft-mahalingam-dutt-dcops-vxlan-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7348 RFC7349 LDP Hello Cryptographic Authentication L. Zheng M. Chen M. Bhatia August 2014 ASCII 32447 14

This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.

 draft-ietf-mpls-ldp-hello-crypto-auth-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7349 RFC7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) M. Petit-Huguenin G. Salgueiro August 2014 ASCII 27599 16 Security Encryption

This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidance on when and how to use DTLS with the currently standardized STUN usages. It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFCs 5389 and 5928.

 draft-ietf-tram-stun-dtls-05 RFC5389 RFC5928 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC7350 RFC7351 A Media Type for XML Patch Operations E. Wilde August 2014 ASCII 27784 14 Media Type XML Patch Operations

The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations.

 draft-wilde-xml-patch-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7351 RFC7352 Sieve Email Filtering: Detecting Duplicate Deliveries S. Bosch September 2014 ASCII 31191 15 sieve duplicate deliveries

This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header field or other parts of the message.

 draft-ietf-appsawg-sieve-duplicate-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7352 RFC7353 Security Requirements for BGP Path Validation S. Bellovin R. Bush D. Ward August 2014 ASCII 18148 9 Routing BGP Security AS_PATH and RPKI

This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.

 draft-ietf-sidr-bgpsec-reqs-12 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7353 RFC7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace A. Adolf P. Siebert September 2014 ASCII 5052 3

RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updates RFC 5328 with new registrant information.

 draft-adolf-dvb-urn-upd-01 RFC5328 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7354 RFC7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Pascual A. Roman S. Garcia September 2014 ASCII 16180 9

RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC 6873, with a new "Transport Flag" for such SIP WebSocket transport.

 draft-salgueiro-dispatch-websocket-sipclf-02 RFC6873 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7355 RFC7356 IS-IS Flooding Scope Link State PDUs (LSPs) L. Ginsberg S. Previdi Y. Yang September 2014 ASCII 46089 23

Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.

The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.

 draft-ietf-isis-fs-lsp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7356 RFC7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol H. Zhai F. Hu R. Perlman D. Eastlake 3rd O. Stokes September 2014 ASCII 72379 31 ESADI TRILL RBridge Address Learning Reachability MAC Addresses

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 multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).

ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.

 draft-ietf-trill-esadi-09 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7357 RFC7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) K. Raza S. Boutros L. Martini N. Leymann October 2014 ASCII 15582 8

The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.

 draft-ietf-mpls-ldp-applicability-label-adv-03 RFC3212 RFC4447 RFC5036 RFC5918 RFC6388 RFC7140 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7358 RFC7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks F. Gont August 2014 ASCII 26506 12

The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.

 draft-ietf-opsec-vpn-leakages-06 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7359 RFC7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS A. DeKok September 2014 ASCII 60007 27

The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.

 draft-ietf-radext-dtls-13 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7360 RFC7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) P. Dutta F. Balus O. Stokes G. Calvignac D. Fedyk September 2014 ASCII 62854 27 MAC flush message MAC Flush TLV MAC flushing

RFC 4762 describes a mechanism to remove or unlearn Media Access Control (MAC) addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology changes. This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.

 draft-ietf-l2vpn-vpls-ldp-mac-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7361 10.17487/RFC7361 RFC7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication E. Ivov H. Kaplan D. Wing September 2014 ASCII 39139 16 VoIP firewall traversal

This document describes the behavior of signaling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.

This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.

Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol.

 draft-ietf-mmusic-latching-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC7362 RFC7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo September 2014 ASCII 54308 22 P2PSIP P2P Chord

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-self-tuning-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7363 RFC7364 Problem Statement: Overlays for Network Virtualization T. Narten Editor E. Gray Editor D. Black L. Fang L. Kreeger M. Napierala October 2014 ASCII 57831 23

This document describes issues associated with providing multi-tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks. Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway). Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures.

 draft-ietf-nvo3-overlay-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7364 RFC7365 Framework for Data Center (DC) Network Virtualization M. Lasserre F. Balus T. Morin N. Bitar Y. Rekhter October 2014 ASCII 57811 26 nvo3 network virtualization over layer 3

This document provides a framework for Data Center (DC) Network Virtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.

 draft-ietf-nvo3-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7365 RFC7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Gutmann September 2014 ASCII 15775 7

This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.

 draft-ietf-tls-encrypt-then-mac-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7366 10.17487/RFC7366 RFC7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process R. Cole J. Macker B. Adamson October 2014 ASCII 135588 65 Network Management Management Information Base MIB SMIv2 Routing MANET Multicast

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 aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc Networks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.

 draft-ietf-manet-smf-mib-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7367 RFC7368 IPv6 Home Networking Architecture Principles T. Chown Editor J. Arkko A. Brandt O. Troan J. Weil October 2014 ASCII 125402 49 IPv6

This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.

 draft-ietf-homenet-arch-17 INFORMATIONAL INFORMATIONAL IETF int homenet 10.17487/RFC7368 RFC7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration A. Takacs B. Gero H. Long October 2014 ASCII 38843 18 GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks. CFM can also be 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 the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.

 draft-ietf-ccamp-rsvp-te-eth-oam-ext-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7369 RFC7370 Updates to the IS-IS TLV Codepoints Registry L. Ginsberg September 2014 ASCII 12318 7 Codepoint

This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.

 draft-ietf-isis-tlv-codepoints-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7370 RFC7371 Updates to the IPv6 Multicast Addressing Architecture M. Boucadair S. Venaas September 2014 ASCII 18327 10 IPv6 Multicast Flag Bits updated unicast-prefix-based address updated Embedded-RP

This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.

This document updates RFCs 3956, 3306, and 4291.

 draft-ietf-6man-multicast-addr-arch-update-08 RFC3306 RFC3956 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7371 RFC7372 Email Authentication Status Codes M. Kucherawy September 2014 ASCII 14224 8

This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.

This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.

 draft-ietf-appsawg-email-auth-codes-07 RFC7208 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7372 RFC7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types B. Trammell September 2014 ASCII 29054 14 information element unicode

This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.

 draft-ietf-ipfix-text-adt-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7373 RFC7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo October 2014 ASCII 45569 20 P2PSIP ReDiR P2P DHT

REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC 6940). This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism can be applied to RELOAD overlays to provide a generic service discovery mechanism.

 draft-ietf-p2psip-service-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7374 RFC7375 Secure Telephone Identity Threat Model J. Peterson October 2014 ASCII 31067 13 SIP Secure Origin Identification Communication Security RTCWeb Threat Real-Time Communication

As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.

 draft-ietf-stir-threats-04 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7375 RFC7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) T. Reddy R. Ravindranath M. Perumal A. Yegin September 2014 ASCII 16447 8

This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.

 draft-ietf-tram-auth-problems-05 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7376 RFC7377 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov October 2014 ASCII 24711 11 IMAP email search multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237.

 draft-ietf-appsawg-multimailbox-search-04 RFC6237 RFC4466 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7377 RFC7378 Trustworthy Location H. Tschofenig H. Schulzrinne B. Aboba Editor December 2014 ASCII 75402 31

The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.

This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.

 draft-ietf-ecrit-trustworthy-location-14 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7378 RFC7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge Y. Li W. Hao R. Perlman J. Hudson H. Zhai October 2014 ASCII 26764 13

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.

 draft-ietf-trill-active-active-connection-prob-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7379 RFC7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting J. Tong C. Bi Editor R. Even Q. Wu Editor R. Huang November 2014 ASCII 22440 11 TR 101 290

An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR block are related to Program Specific Information (PSI) carried in MPEG TS.

 draft-ietf-xrblock-rtcp-xr-psi-decodability-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7380 RFC7381 Enterprise IPv6 Deployment Guidelines K. Chittimaneni T. Chown L. Howard V. Kuarsingh Y. Pouffary E. Vyncke October 2014 ASCII 90299 34 IPV6 migration transition enterprise

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 eventually 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-ietf-v6ops-enterprise-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7381 RFC7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) S. Kent D. Kong K. Seo April 2015 ASCII 82372 38

This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.

 draft-ietf-sidr-cps-04 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC7382 RFC7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation V. Smyslov November 2014 ASCII 47354 20 IP fragmentation NAT firewall PMTU discovery

This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.

 draft-ietf-ipsecme-ikev2-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7383 RFC7384 Security Requirements of Time Protocols in Packet Switched Networks T. Mizrahi October 2014 ASCII 78942 36 ptp precision time protocol ntp network time protocol

As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.

 draft-ietf-tictoc-security-requirements-12 INFORMATIONAL INFORMATIONAL IETF int tictoc 10.17487/RFC7384 RFC7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points L. Andersson G. Swallow October 2014 ASCII 6690 4

RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". However, the RFC did not create a corresponding IANA registry.

There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.

 draft-ietf-l3vpn-pmsi-registry-07 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7385 RFC7386 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII 12930 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

 draft-ietf-appsawg-json-merge-patch-07 RFC7396 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7386 10.17487/RFC7386 RFC7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network R. Key Editor L. Yong Editor S. Delord F. Jounay L. Jin October 2014 ASCII 28205 13 mef etherhet lan e-lan metro ethernet forum

This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service 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-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7387 RFC7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) J. Schoenwaelder A. Sehgal T. Tsou C. Zhou October 2014 ASCII 53451 27 Network Management Management Information Base MIB SMIv2

This document 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 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).

 draft-ietf-6lo-lowpan-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7388 RFC7389 Separation of Control and User Plane for Proxy Mobile IPv6 R. Wakikawa R. Pazhyannur S. Gundavelli C. Perkins October 2014 ASCII 26217 12 Control and User Plane Split Control and User Plane Separation LMA User-Plane Address Mobility Option

This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6). Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.

 draft-ietf-netext-pmip-cp-up-separation-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7389 RFC7390 Group Communication for the Constrained Application Protocol (CoAP) A. Rahman Editor E. Dijk Editor October 2014 ASCII 106675 46 multicast IP multicast RESTful Internet of Things (IoT)

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.

 draft-ietf-core-groupcomm-25 EXPERIMENTAL EXPERIMENTAL IETF app core 10.17487/RFC7390 RFC7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions J. Hadi Salim October 2014 ASCII 49481 23 ForCES Protocol Extension

Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.

 draft-ietf-forces-protoextension-06 RFC5810 RFC7121 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7391 RFC7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires P. Dutta M. Bocci L. Martini December 2014 ASCII 20846 10 Pseudowire MS-PW explicit route

When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.

 draft-ietf-pwe3-mspw-er-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7392 RFC7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS X. Deng M. Boucadair Q. Zhao J. Huang C. Zhou November 2014 ASCII 30130 14 address sharing CGN service continuity service availability user-generated content address-sharing issues DS-Lite service delivery in CGN contexts

This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo.

 draft-deng-pcp-ddns-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7393 RFC7394 Definition of Time to Live TLV for LSP-Ping Mechanisms S. Boutros S. Sivabalan G. Swallow S. Saxena V. Manral S. Aldrin November 2014 ASCII 15120 8

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) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming.

 draft-ietf-mpls-lsp-ping-ttl-tlv-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7394 10.17487/RFC7394 RFC7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket L. Stout Editor J. Moffitt E. Cestari October 2014 ASCII 36795 18 WebSocket XMPP

This document defines a binding for the Extensible Messaging and Presence Protocol (XMPP) over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.

 draft-ietf-xmpp-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp 10.17487/RFC7395 RFC7396 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII 12791 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

 draft-ietf-rfc7386bis-00 RFC7386 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7396 RFC7397 Report from the Smart Object Security Workshop J. Gilger H. Tschofenig December 2014 ASCII 51259 23 Smart Objects Internet of Things Workshop Security

This document provides a summary of a workshop on 'Smart Object Security' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.

This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

 draft-gilger-smart-object-security-workshop-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7397 RFC7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance M. Bagnulo T. Burbridge S. Crawford P. Eardley A. Morton February 2015 ASCII 36938 17 LMAP performance metrics

This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.

 draft-ietf-ippm-lmap-path-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7398 RFC7399 Unanswered Questions in the Path Computation Element Architecture A. Farrel D. King October 2014 ASCII 70588 29 SDN Software Defined Networking H-PCE Hierarchical PCE VNTM Virtual Network Topology Manager ABNO Application-Based Network Operation TE Traffic Engineering

The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.

These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.

This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.

 draft-ietf-pce-questions-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7399 RFC7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) C. Bormann November 2014 ASCII 47533 24 IoT Internet of Things Embedded Internet Sensor Network WSN Constrained node Constrained network Constrained-node network LLN LoWPAN packet encoding capability indication 6CIO LZ77 RFC 6282 RFC 4944 adaptation layer IEEE 802.15.4

RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.

 draft-ietf-6lo-ghc-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7400 RFC7401 Host Identity Protocol Version 2 (HIPv2) R. Moskowitz Editor T. Heer P. Jokela T. Henderson April 2015 ASCII 309319 128 HIP IP-layer state integrity protection optional encryption

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 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 Encapsulating 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-hip-rfc5201-bis-20 RFC5201 RFC8002 PROPOSED STANDARD PROPOSED STANDARD IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=7401 10.17487/RFC7401 RFC7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz J. Melen April 2015 ASCII 88644 40 encryption user data packets

This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202.

 draft-ietf-hip-rfc5202-bis-07 RFC5202 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7402 RFC7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP) H. Kaplan November 2014 ASCII 15108 7

SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back-to-back user agents (B2BUAs).

 draft-ietf-straw-sip-traceroute-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw 10.17487/RFC7403 RFC7404 Using Only Link-Local Addressing inside an IPv6 Network M. Behringer E. Vyncke November 2014 ASCII 24444 10 IPv6 security routing Link-Local Routing Protocol Security

In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.

 draft-ietf-opsec-lla-only-11 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7404 10.17487/RFC7404 RFC7405 Case-Sensitive String Support in ABNF P. Kyzivat December 2014 ASCII 6668 4 BNF ABNF Syntax

This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.

 draft-kyzivat-case-sensitive-abnf-02 RFC5234 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7405 RFC7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices H. Schulzrinne S. McCann G. Bajko H. Tschofenig D. Kroeselberg December 2014 ASCII 52779 25

This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.

 draft-ietf-ecrit-unauthenticated-access-10 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7406 RFC7407 A YANG Data Model for SNMP Configuration M. Bjorklund J. Schoenwaelder December 2014 ASCII 155373 88

This document defines a collection of YANG definitions for configuring SNMP engines.

 draft-ietf-netmod-snmp-cfg-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7407 10.17487/RFC7407 RFC7408 Forwarding and Control Element Separation (ForCES) Model Extension E. Haleplidis November 2014 ASCII 62348 31 ForCES Model Extension

This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.

 draft-ietf-forces-model-extension-05 RFC5812 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7408 RFC7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization E. Haleplidis J. Halpern November 2014 ASCII 53906 27 ForCES Model Extension

Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation (ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).

 draft-ietf-forces-packet-parallelization-03 EXPERIMENTAL EXPERIMENTAL IETF rtg forces 10.17487/RFC7409 RFC7410 A Property Types Registry for the Authentication-Results Header Field M. Kucherawy December 2014 ASCII 9957 5 Authentication-Results Reputation

This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.

 draft-ietf-appsawg-authres-ptypes-registry-04 RFC7601 RFC7001 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7410 RFC7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers T. Schmidt Editor M. Waehlisch R. Koodli G. Fairhurst D. Liu November 2014 ASCII 72298 30 Multicast Mobility IPv6 PIM MLD Group Communication

Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format.

This document updates RFC 5568, "Mobile IPv6 Fast Handovers".

 draft-ietf-multimob-fmipv6-pfmipv6-multicast-10 RFC5568 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7411 RFC7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection Y. Weingarten S. Aldrin P. Pan J. Ryoo G. Mirsky December 2014 ASCII 34117 16

This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.

 draft-ietf-mpls-smp-requirements-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7412 RFC7413 TCP Fast Open Y. Cheng J. Chu S. Radhakrishnan A. Jain December 2014 ASCII 59945 26

This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.

 draft-ietf-tcpm-fastopen-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=7413 10.17487/RFC7413 RFC7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton A. Zimmermann February 2015 ASCII 130622 57 TCP Roadmap

This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.

This document obsoletes RFC 4614.

 draft-ietf-tcpm-tcp-rfc4614bis-08 RFC4614 RFC7805 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7414 RFC7415 Session Initiation Protocol (SIP) Rate Control E. Noel P. Williams February 2015 ASCII 30456 15

The prevalent use of the Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.

 draft-ietf-soc-overload-rate-control-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7415 RFC7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) T. Tsao R. Alexander M. Dohler V. Daza A. Lozano M. Richardson Editor January 2015 ASCII 94452 40 LLN ROLL security

This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.

 draft-ietf-roll-security-threats-11 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7416 RFC7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains G. Karagiannis A. Bhargava December 2014 ASCII 79227 36 generic aggregate rsvp

This document specifies extensions to Generic Aggregate RSVP (RFC 4860) for support of the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.

 draft-ietf-tsvwg-rsvp-pcn-11 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC7417 RFC7418 An IRTF Primer for IETF Participants S. Dawkins Editor December 2014 ASCII 14467 7 Research Group

This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF). This document emphasizes differences in expectations between the two organizations.

 draft-dawkins-irtf-newrg-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7418 RFC7419 Common Interval Support in Bidirectional Forwarding Detection N. Akiya M. Binderberger G. Mirsky December 2014 ASCII 16944 8 BFD hardware interval timer

Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions.

This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. 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. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.

 draft-ietf-bfd-intervals-05 RFC5880 INFORMATIONAL INFORMATIONAL IETF rtg bfd 10.17487/RFC7419 RFC7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module A. Koushik E. Stephan Q. Zhao D. King J. Hardwick December 2014 ASCII 130964 65 Network Management Management Information Base MIB SMIv2 PCE PCEP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for 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.

 draft-ietf-pce-pcep-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=7420 10.17487/RFC7420 RFC7421 Analysis of the 64-bit Boundary in IPv6 Addressing B. Carpenter Editor T. Chown F. Gont S. Jiang A. Petrescu A. Yourtchenko January 2015 ASCII 60469 24

The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.

 draft-ietf-6man-why64-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7421 RFC7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments C. Donley C. Grundemann V. Sarawat K. Sundaresan O. Vautrin December 2014 ASCII 33575 14

In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use.

 draft-donley-behave-deterministic-cgn-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7422 10.17487/RFC7422 RFC7423 Diameter Applications Design Guidelines L. Morand Editor V. Fajardo H. Tschofenig November 2014 ASCII 67829 29 AAA Authentication Authorization Accounting

The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.

 draft-ietf-dime-app-design-guide-28 BCP0193 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dime 10.17487/RFC7423 RFC7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks R. Krishnan L. Yong A. Ghanwani N. So B. Khasnabish January 2015 ASCII 60733 29

Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this.

 draft-ietf-opsawg-large-flow-load-balancing-15 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7424 RFC7425 Adobe's RTMFP Profile for Flash Communication M. Thornburgh December 2014 ASCII 103979 49

This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.

 draft-thornburgh-rtmfp-flash-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7425 RFC7426 Software-Defined Networking (SDN): Layers and Architecture Terminology E. Haleplidis Editor K. Pentikousis Editor S. Denazis J. Hadi Salim D. Meyer O. Koufopavlou January 2015 ASCII 85111 35 Software-defined Networking SDN Programmable Networks Architecture Layer Terminology

Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.

 draft-irtf-sdnrg-layer-terminology-04 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7426 RFC7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) T. Kivinen J. Snyder January 2015 ASCII 39041 18 IPsec IKE IKEv2 Signature Authentication RSA DSS DSA ECDSA SASSA-PSS PKIX

The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.

 draft-kivinen-ipsecme-signature-auth-07 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7427 10.17487/RFC7427 RFC7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks A. Brandt J. Buron February 2015 ASCII 42657 21

This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.

 draft-ietf-6lo-lowpanz-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7428 RFC7429 Distributed Mobility Management: Current Practices and Gap Analysis D. Liu Editor JC. Zuniga Editor P. Seite H. Chan CJ. Bernardos January 2015 ASCII 80973 34 DMM Distributed Mobility Management anchor gap analysis best practices

This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.

 draft-ietf-dmm-best-practices-gap-analysis-09 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7429 RFC7430 Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) M. Bagnulo C. Paasch F. Gont O. Bonaventure C. Raiciu July 2015 ASCII 41877 19 MPTCP security threat analysis

This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.

 draft-ietf-mptcp-attacks-04 INFORMATIONAL INFORMATIONAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=7430 10.17487/RFC7430 RFC7431 Multicast-Only Fast Reroute A. Karan C. Filsfils IJ. Wijnands Editor B. Decraene August 2015 ASCII 28906 14

As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).

 draft-ietf-rtgwg-mofrr-08 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7431 RFC7432 BGP MPLS-Based Ethernet VPN A. Sajassi Editor R. Aggarwal N. Bitar A. Isaac J. Uttaro J. Drake W. Henderickx February 2015 ASCII 134119 56

This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".

 draft-ietf-l2vpn-evpn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7432 10.17487/RFC7432 RFC7433 A Mechanism for Transporting User-to-User Call Control Information in SIP A. Johnston J. Rafferty January 2015 ASCII 45687 19 UUI Package Content Encoding Media

There is a class of applications that 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 syntax and semantics for the UUI data used by 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-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss 10.17487/RFC7433 RFC7434 Interworking ISDN Call Control User Information with SIP K. Drage Editor A. Johnston January 2015 ASCII 39276 17 UUS Supplementary Service

The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service.

This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed.

The package is identified by the new value "isdn-uui" of the "purpose" header field parameter.

 draft-ietf-cuss-sip-uui-isdn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss http://www.rfc-editor.org/errata_search.php?rfc=7434 10.17487/RFC7434 RFC7435 Opportunistic Security: Some Protection Most of the Time V. Dukhovni December 2014 ASCII 27451 11 authentication encryption

This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.

 draft-dukhovni-opportunistic-security-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7435 RFC7436 IP-Only LAN Service (IPLS) H. Shah E. Rosen F. Le Faucheur G. Heron January 2015 ASCII 74340 32

A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's "Media Access Control (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.

The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.

 draft-ietf-l2vpn-ipls-16 HISTORIC HISTORIC IETF rtg l2vpn 10.17487/RFC7436 RFC7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees M. Kucherawy Editor January 2015 ASCII 77786 35 Internet Architecture Board Engineering Steering Group nomcom IAOC

The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published.

 draft-kucherawy-rfc3777bis-04 RFC3777 RFC5078 RFC5633 RFC5680 RFC6859 RFC7776 BCP0010 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7437 RFC7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards IJ. Wijnands Editor E. Rosen A. Gulko U. Joorde J. Tantsura January 2015 ASCII 36744 16 mpls multicast

There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246.

 draft-ietf-mpls-mldp-in-band-wildcard-encoding-03 RFC6826 RFC7246 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7438 RFC7439 Gap Analysis for Operating IPv6-Only MPLS Networks W. George Editor C. Pignataro Editor January 2015 ASCII 64087 28 MPLS LDP IPv6 RSVP L3VPN L2VPN

This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.

In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.

 draft-ietf-mpls-ipv6-only-gap-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7439 10.17487/RFC7439 RFC7440 TFTP Windowsize Option P. Masotta January 2015 ASCII 17710 9

The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.

This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension" (RFC 2347).

 draft-masotta-tftpexts-windowsize-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7440 RFC7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes IJ. Wijnands E. Rosen U. Joorde January 2015 ASCII 22839 10

Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.

 draft-ietf-l3vpn-mvpn-mldp-nlri-10 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7441 RFC7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) Y. Rekhter R. Aggarwal N. Leymann W. Henderickx Q. Zhao R. Li February 2015 ASCII 24020 11

When IP multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions for P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).

 draft-ietf-mpls-pim-sm-over-mldp-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7442 RFC7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages P. Patil T. Reddy G. Salgueiro M. Petit-Huguenin January 2015 ASCII 9145 5

Application-Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS).

 draft-ietf-tram-alpn-08 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7443 RFC7444 Security Labels in Internet Email K. Zeilenga A. Melnikov February 2015 ASCII 32183 16 email header fields ESS Security Label Confidential Label Message Sensitivity

This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label.

 draft-zeilenga-email-seclabel-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7444 RFC7445 Analysis of Failure Cases in IPv6 Roaming Scenarios G. Chen H. Deng D. Michaud J. Korhonen M. Boucadair March 2015 ASCII 44466 19 Mobile Network Dual Stack IPv6-only

This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.

 draft-ietf-v6ops-ipv6-roaming-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7445 RFC7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Y. Lee Editor G. Bernstein Editor D. Li W. Imajuku February 2015 ASCII 48370 23 WSON RWA

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 optical path 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-info-24 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7446 RFC7447 Deprecation of BGP Entropy Label Capability Attribute J. Scudder K. Kompella February 2015 ASCII 7486 4

The BGP Entropy Label Capability attribute is defined in RFC 6790. Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice. This specification deprecates the attribute. A forthcoming document will propose a replacement.

 draft-ietf-mpls-deprecate-bgp-entropy-label-02 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7447 RFC7448 MIB Transfer from the IETF to the IEEE 802.3 WG T. Taylor Editor D. Romascanu February 2015 ASCII 12501 7 Ethernet IEEE

This document records the transfer of responsibility for the Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group (WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG.

 draft-ietf-opsawg-mibs-to-ieee80231-01 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7448 RFC7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment Y. Lee Editor G. Bernstein Editor J. Martensson T. Takeda T. Tsuritani O. Gonzalez de Dios February 2015 ASCII 25117 12

This memo provides application-specific requirements for the Path Computation Element Communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSONs). 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 PCEP extensions in support of optical impairments will be addressed in a separate document.

 draft-ietf-pce-wson-routing-wavelength-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7449 RFC7450 Automatic Multicast Tunneling G. Bumgardner February 2015 ASCII 188711 82 AMT IGMPv2 IGMPv3 MLDv1 MLDv2 ASM SSM amt gateway amt relay multicast replication multicast encapsulation

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-auto-multicast-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC7450 RFC7451 Extension Registry for the Extensible Provisioning Protocol S. Hollenbeck February 2015 ASCII 20373 12 domain host contact

The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.

 draft-ietf-eppext-reg-10 INFORMATIONAL INFORMATIONAL IETF app eppext 10.17487/RFC7451 RFC7452 Architectural Considerations in Smart Object Networking H. Tschofenig J. Arkko D. Thaler D. McPherson March 2015 ASCII 53504 24 IAB Statement Smart Objects

The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.

This document offers guidance to engineers designing Internet- connected smart objects.

 draft-iab-smart-object-architecture-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7452 RFC7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) V. Mahalingam K. Sampath S. Aldrin T. Nadeau February 2015 ASCII 117910 62

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 additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.

 draft-ietf-mpls-tp-te-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7453 RFC7454 BGP Operations and Security J. Durand I. Pepelnjak G. Doering February 2015 ASCII 56946 26

The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.

This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.

 draft-ietf-opsec-bgp-security-07 BCP0194 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7454 RFC7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management T. Senevirathne N. Finn S. Salam D. Kumar D. Eastlake 3rd S. Aldrin Y. Li March 2015 ASCII 126153 63 Fault Continuity Connectivity OAM CFM MEP CCM

This document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1. This document updates RFC 6325.

 draft-ietf-trill-oam-fm-11 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7455 RFC7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) T. Mizrahi T. Senevirathne S. Salam D. Kumar D. Eastlake 3rd March 2015 ASCII 66752 32

Performance Monitoring (PM) is a key aspect of Operations, Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms for Loss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.

 draft-ietf-trill-loss-delay-08 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7456 RFC7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) Y. Sheffer R. Holz P. Saint-Andre February 2015 ASCII 28614 13 Transport Layer Security TLS Datagram TLS DTLS Secure Sockets Layer SSL security attacks

Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).

 draft-ietf-uta-tls-attacks-05 INFORMATIONAL INFORMATIONAL IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7457 10.17487/RFC7457 RFC7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core R. Valmikam R. Koodli February 2015 ASCII 38925 18 Mobile Networks 3GPP EAP EPC Handover Identity APN

With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks.

The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.

 draft-ietf-netext-wifi-epc-eap-attributes-16 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7458 RFC7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2015 ASCII 80144 39

This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.

This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693.

 draft-ietf-geopriv-uncertainty-04 RFC3693 RFC4119 RFC5491 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7459 RFC7460 Monitoring and Control MIB for Power and Energy M. Chandramouli B. Claise B. Schoening J. Quittek T. Dietz March 2015 ASCII 148167 69 management information base IANAPowerStateSet-MIB ENERGY-OBJECT-MIB POWER-ATTRIBUTES-MIB

This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.

 draft-ietf-eman-energy-monitoring-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7460 RFC7461 Energy Object Context MIB J. Parello B. Claise M. Chandramouli March 2015 ASCII 67077 32 management information base ENERGY-OBJECT-CONTEXT-MIB IANA-ENERGY-RELATION-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 energy relationships between devices.

 draft-ietf-eman-energy-aware-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7461 RFC7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) L. Liess Editor R. Jesske A. Johnston D. Worley P. Kyzivat March 2015 ASCII 97730 46

The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for 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 these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.

This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.

 draft-ietf-salud-alert-info-urns-14 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai salud 10.17487/RFC7462 RFC7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) A. Johnston Editor M. Soroushnejad Editor V. Venkataramanan March 2015 ASCII 171979 72

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 Private Branch Exchange (IPBX) 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. This specification updates RFCs 3261 and 4235.

 draft-ietf-bliss-shared-appearances-15 RFC3261 RFC4235 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss http://www.rfc-editor.org/errata_search.php?rfc=7463 10.17487/RFC7463 RFC7464 JavaScript Object Notation (JSON) Text Sequences N. Williams February 2015 ASCII 16132 8 JSON sequence online streaming log file

This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).

 draft-ietf-json-text-sequence-13 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7464 RFC7465 Prohibiting RC4 Cipher Suites A. Popov February 2015 ASCII 8397 6 TLS transport layer security

This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246.

 draft-ietf-tls-prohibiting-rc4-01 RFC5246 RFC4346 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7465 RFC7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) C. Dearlove T. Clausen March 2015 ASCII 17949 9 MANET NHDP OLSRv2 link quality

The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.

NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.

This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust".

 draft-ietf-manet-nhdp-optimization-04 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7466 RFC7467 URN Namespace for the North Atlantic Treaty Organization (NATO) A. Murdock April 2015 ASCII 16675 8

This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization (NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.

 draft-murdock-nato-nid-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7467 RFC7468 Textual Encodings of PKIX, PKCS, and CMS Structures S. Josefsson S. Leonard April 2015 ASCII 41594 20

This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

 draft-josefsson-pkix-textual-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7468 10.17487/RFC7468 RFC7469 Public Key Pinning Extension for HTTP C. Evans C. Palmer R. Sleevi April 2015 ASCII 61619 28 pin

This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted 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.

 draft-ietf-websec-key-pinning-21 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=7469 10.17487/RFC7469 RFC7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2015 ASCII 28647 14

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.

This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.

 draft-ietf-pce-rfc7150bis-01 RFC7150 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7470 RFC7471 OSPF Traffic Engineering (TE) Metric Extensions S. Giacalone D. Ward J. Drake A. Atlas S. Previdi March 2015 ASCII 38803 19

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.

This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.

Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.

 draft-ietf-ospf-te-metric-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7471 RFC7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme I. McDonald M. Sweet March 2015 ASCII 37666 19

This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.

This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.

 draft-mcdonald-ipps-uri-scheme-18 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7472 RFC7473 Controlling State Advertisements of Non-negotiated LDP Applications K. Raza S. Boutros March 2015 ASCII 36189 15

There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.

 draft-ietf-mpls-ldp-ip-pw-capability-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7473 RFC7474 Security Extension for OSPFv2 When Using Manual Key Management M. Bhatia S. Hartman D. Zhang A. Lindem Editor April 2015 ASCII 31832 14 OSPF cryptographic authentication security replay attacks

The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.

This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.

 draft-ietf-ospf-security-extension-manual-keying-11 RFC2328 RFC5709 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7474 RFC7475 Increasing the Number of Area Directors in an IETF Area S. Dawkins March 2015 ASCII 9350 5

This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).

 draft-dawkins-iesg-one-or-more-05 RFC2026 RFC2418 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7475 RFC7476 Information-Centric Networking: Baseline Scenarios K. Pentikousis Editor B. Ohlman D. Corujo G. Boggia G. Tyson E. Davies A. Molinaro S. Eum March 2015 ASCII 120235 45

This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-scenarios-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7476 RFC7477 Child-to-Parent Synchronization in DNS W. Hardaker March 2015 ASCII 34471 15

This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.

 draft-ietf-dnsop-child-syncronization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7477 10.17487/RFC7477 RFC7478 Web Real-Time Communication Use Cases and Requirements C. Holmberg S. Hakansson G. Eriksson March 2015 ASCII 64824 28 webrtc browser websocket real-time

This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases.

This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future.

 draft-ietf-rtcweb-use-cases-and-requirements-16 INFORMATIONAL INFORMATIONAL IETF rai rtcweb 10.17487/RFC7478 RFC7479 Using Ed25519 in SSHFP Resource Records S. Moonesamy March 2015 ASCII 6440 4

The Ed25519 signature algorithm has been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519.

 draft-moonesamy-sshfp-ed25519-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7479 10.17487/RFC7479 RFC7480 HTTP Usage in the Registration Data Access Protocol (RDAP) A. Newton B. Ellacott N. Kong March 2015 ASCII 34671 16 Registry WHOIS

This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.

 draft-ietf-weirds-using-http-15 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7480 RFC7481 Security Services for the Registration Data Access Protocol (RDAP) S. Hollenbeck N. Kong March 2015 ASCII 29954 13 RDAP Security

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.

 draft-ietf-weirds-rdap-sec-12 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7481 RFC7482 Registration Data Access Protocol (RDAP) Query Format A. Newton S. Hollenbeck March 2015 ASCII 43429 20 WHOIS

This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).

 draft-ietf-weirds-rdap-query-18 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7482 RFC7483 JSON Responses for the Registration Data Access Protocol (RDAP) A. Newton S. Hollenbeck March 2015 ASCII 125362 78 WHOIS

This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses.

 draft-ietf-weirds-json-response-14 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7483 10.17487/RFC7483 RFC7484 Finding the Authoritative Registration Data (RDAP) Service M. Blanchet March 2015 ASCII 33947 17 whois bootstrap IDN AS IPv4 IPv6 JSON

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.

 draft-ietf-weirds-bootstrap-11 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7484 RFC7485 Inventory and Analysis of WHOIS Registration Objects L. Zhou N. Kong S. Shen S. Sheng A. Servin March 2015 ASCII 74392 33 whois restful weirds response object inventory

WHOIS output objects from registries, including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed. This document describes the process and results of the statistical analysis of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses.

 draft-ietf-weirds-object-inventory-06 INFORMATIONAL INFORMATIONAL IETF app weirds 10.17487/RFC7485 RFC7486 HTTP Origin-Bound Authentication (HOBA) S. Farrell P. Hoffman M. Thomas March 2015 ASCII 64868 28 Network Working Group http authentication origin-bound key

HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.

 draft-ietf-httpauth-hoba-10 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC7486 RFC7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE E. Bellagamba A. Takacs G. Mirsky L. Andersson P. Skoldstrom D. Ward March 2015 ASCII 67217 32 RSVP-TE GMPLS MPLS MPLS-TP OAM

This specification describes the configuration of proactive MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE.

 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7487 RFC7488 Port Control Protocol (PCP) Server Selection M. Boucadair R. Penno D. Wing P. Patil T. Reddy March 2015 ASCII 22577 12 PCP Server discovery Port Mapping Shared Address Multiple PCP Servers

This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.

This document updates RFC 6887.

 draft-ietf-pcp-server-selection-10 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7488 RFC7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) M. Kucherawy Editor E. Zwicky Editor March 2015 ASCII 162707 73 domain email security messaging dkim spf authentication reporting conformance

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.

DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.

 draft-kucherawy-dmarc-base-12 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7489 10.17487/RFC7489 RFC7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) S. Bryant C. Filsfils S. Previdi M. Shand N. So April 2015 ASCII 66207 29

This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.

 draft-ietf-rtgwg-remote-lfa-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7490 RFC7491 A PCE-Based Architecture for Application-Based Network Operations D. King A. Farrel March 2015 ASCII 163636 71 Software-Defined Networking (SDN) Path Computation Element (PCE) Network management Network programming

Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.

This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.

 draft-farrkingel-pce-abno-architecture-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7491 RFC7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines M. Bhatia D. Zhang M. Jethanandani March 2015 ASCII 21689 9 BFD KARP replay attacks cryptographic authentication security DoS attacks

This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".

 draft-ietf-karp-bfd-analysis-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7492 RFC7493 The I-JSON Message Format T. Bray Editor March 2015 ASCII 12849 6 JSON Internet JSON

I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.

 draft-ietf-json-i-json-06 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7493 RFC7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) C. Shao H. Deng R. Pazhyannur F. Bari R. Zhang S. Matsushima April 2015 ASCII 23378 13 CAPWAP MAC Profile Encryption IEEE 802.11

The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control (MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs): Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC.

 draft-ietf-opsawg-capwap-hybridmac-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7494 RFC7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) A. Montville D. Black March 2015 ASCII 19891 10 IODEF Incident Reference Enumeration Format

The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.

This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.

 draft-ietf-mile-enum-reference-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC7495 RFC7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension M. Tuexen R. Seggelmann R. Stewart S. Loreto April 2015 ASCII 21272 11

This document defines two additional policies for the Partially Reliable Stream Control Transmission Protocol (PR-SCTP) extension. These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer.

 draft-ietf-tsvwg-sctp-prpolicies-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7496 RFC7497 Rate Measurement Test Protocol Problem Statement and Requirements A. Morton April 2015 ASCII 31281 14 Internet access Asymmetric Packet Size

This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.

 draft-ietf-ippm-rate-problem-10 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7497 RFC7498 Problem Statement for Service Function Chaining P. Quinn Editor T. Nadeau Editor April 2015 ASCII 28970 13 service function chaining steering sfc

This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.

The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.

This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.

 draft-ietf-sfc-problem-statement-13 INFORMATIONAL INFORMATIONAL IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=7498 10.17487/RFC7498 RFC7499 Support of Fragmentation of RADIUS Packets A. Perez-Mendez Editor R. Marin-Lopez F. Pereniguez-Garcia G. Lopez-Millan D. Lopez A. DeKok April 2015 ASCII 83448 38 RADIUS attribute extension fragmentation chunk

The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.

 draft-ietf-radext-radius-fragmentation-12 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7499 RFC7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries R. Housley Editor O. Kolkman Editor April 2015 ASCII 15720 7

This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.

 draft-iab-iana-principles-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7500 RFC7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII 36573 20

This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures.

 draft-ietf-bmwg-sip-bench-term-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7501 RFC7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII 41281 21

This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.

 draft-ietf-bmwg-sip-bench-meth-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7502 RFC7503 OSPFv3 Autoconfiguration A. Lindem J. Arkko April 2015 ASCII 33521 15

OSPFv3 is a candidate for deployments in environments where autoconfiguration 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. This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).

 draft-ietf-ospf-ospfv3-autoconfig-15 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7503 RFC7504 SMTP 521 and 556 Reply Codes J. Klensin June 2015 ASCII 13936 7 Reply code Email Server No Mail

This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.

 draft-klensin-smtp-521code-07 RFC1846 RFC5321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7504 RFC7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail J. Levine M. Delany June 2015 ASCII 12534 6 DNS e-mail

Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

 draft-ietf-appsawg-nullmx-10 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC7505 RFC7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) K. Raza N. Akiya C. Pignataro April 2015 ASCII 11322 6 IPv6 LSP Ping MPLS OAM

RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in the IP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations, Administration, and Maintenance (OAM) tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379.

The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/ Traceroute.

 draft-ietf-mpls-oam-ipv6-rao-03 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7506 RFC7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks B. Moeller A. Langley April 2015 ASCII 17165 8

This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.

 draft-ietf-tls-downgrade-scsv-05 RFC2246 RFC4346 RFC4347 RFC5246 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7507 RFC7508 Securing Header Fields with S/MIME L. Cailleux C. Bonatti April 2015 ASCII 39853 19 secure headers

This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non-repudiation, and confidentiality. This extension is referred to as 'Secure Headers'.

 draft-cailleux-secure-headers-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7508 RFC7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics R. Huang V. Singh May 2015 ASCII 23350 11

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.

 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7509 RFC7510 Encapsulating MPLS in UDP X. Xu N. Sheth L. Yong R. Callon D. Black April 2015 ASCII 43208 19 MPLS UDP Tunnel Checksum encapsulation multipath ECMP

This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.

 draft-ietf-mpls-in-udp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7510 10.17487/RFC7510 RFC7511 Scenic Routing for IPv6 M. Wilhelm April 1 2015 ASCII 14715 8 green it

This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.

 draft-scenig-routing INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7511 10.17487/RFC7511 RFC7512 The PKCS #11 URI Scheme J. Pechanec D. Moffat April 2015 ASCII 48759 20 PKCS11 PKCS-11 PKCS#11,

This memo specifies a PKCS #11 Uniform Resource Identifier (URI) Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token Interface Standard".

 draft-pechanec-pkcs11uri-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7512 10.17487/RFC7512 RFC7513 Source Address Validation Improvement (SAVI) Solution for DHCP J. Bi J. Wu G. Yao F. Baker May 2015 ASCII 123735 54 SAVI-DHCP

This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.

 draft-ietf-savi-dhcp-34 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7513 RFC7514 Really Explicit Congestion Notification (RECN) M. Luckie April 1 2015 ASCII 9776 5

This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).

 draft-luckie-recn EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7514 RFC7515 JSON Web Signature (JWS) M. Jones J. Bradley N. Sakimura May 2015 ASCII 131110 59 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.

 draft-ietf-jose-json-web-signature-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7515 RFC7516 JSON Web Encryption (JWE) M. Jones J. Hildebrand May 2015 ASCII 108322 51 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.

 draft-ietf-jose-json-web-encryption-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7516 RFC7517 JSON Web Key (JWK) M. Jones May 2015 ASCII 93906 40 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.

 draft-ietf-jose-json-web-key-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7517 RFC7518 JSON Web Algorithms (JWA) M. Jones May 2015 ASCII 155905 69

This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

 draft-ietf-jose-json-web-algorithms-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7518 RFC7519 JSON Web Token (JWT) M. Jones J. Bradley N. Sakimura May 2015 ASCII 63039 30 Assertion Claim Security Token JavaScript Object Notation JSON JSON Web Token JWT JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

 draft-ietf-oauth-json-web-token-32 RFC7797 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7519 RFC7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) M. Miller May 2015 ASCII 198174 120 JSON Object Signing and Encryption JOSE JavaScript Object Notation JSON JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA Cookbook

This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data. These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption (JWE) results given similar inputs.

 draft-ietf-jose-cookbook-08 INFORMATIONAL INFORMATIONAL IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7520 10.17487/RFC7520 RFC7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones Y. Goland May 2015 ASCII 44458 20 OAuth SAML JWT Assertion

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.

The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.

Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

 draft-ietf-oauth-assertions-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7521 RFC7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones May 2015 ASCII 33890 15 OAuth SAML Assertion

This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.

 draft-ietf-oauth-saml2-bearer-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7522 RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants M. Jones B. Campbell C. Mortimore May 2015 ASCII 26459 12 OAuth JWT Assertion Token Security Token

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 client authentication.

 draft-ietf-oauth-jwt-bearer-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7523 RFC7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) Y. Rekhter E. Rosen R. Aggarwal T. Morin I. Grosclaude N. Leymann S. Saad May 2015 ASCII 105804 42

This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). 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 multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.

 draft-ietf-mpls-seamless-mcast-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7524 RFC7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Y. Sheffer R. Holz P. Saint-Andre May 2015 ASCII 60283 27 Transport Layer Security TLS DTLS Secure Sockets Layer SSL

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.

 draft-ietf-uta-tls-bcp-11 BCP0195 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7525 10.17487/RFC7525 RFC7526 Deprecating the Anycast Prefix for 6to4 Relay Routers O. Troan B. Carpenter Editor May 2015 ASCII 20894 10

Experience with the 6to4 transition mechanism defined in RFC 3056 ("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343.

 draft-ietf-v6ops-6to4-to-historic-11 RFC3068 RFC6732 BCP0196 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7526 RFC7527 Enhanced Duplicate Address Detection R. Asati H. Singh W. Beebee C. Pignataro E. Dart W. George April 2015 ASCII 24528 11 Automated DAD loopback detection

IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the 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, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.

 draft-ietf-6man-enhanced-dad-15 RFC4429 RFC4861 RFC4862 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7527 RFC7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association P. Higgs J. Piesing April 2015 ASCII 12921 7

This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications. Example resources include technical documents and specifications, Extensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV.

 draft-higgs-hbbtv-urn-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7528 RFC7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) C. Daboo G. Yakushev May 2015 ASCII 43124 21 calendaring iCalendar iTIP CalDAV

This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.

 draft-ietf-calext-rscale-04 RFC5545 RFC6321 RFC7265 PROPOSED STANDARD PROPOSED STANDARD IETF app calext 10.17487/RFC7529 RFC7530 Network File System (NFS) Version 4 Protocol T. Haynes Editor D. Noveck Editor March 2015 ASCII 724613 323

The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of 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 has 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 External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.

 draft-ietf-nfsv4-rfc3530bis-35 RFC3530 RFC7931 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7530 10.17487/RFC7530 RFC7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description T. Haynes Editor D. Noveck Editor March 2015 ASCII 67541 39

The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.

 draft-ietf-nfsv4-rfc3530bis-dot-x-24 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7531 RFC7532 Namespace Database (NSDB) Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII 127373 65 Federated File Systems

This document describes a file system 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 file systems physically hosted on and exported by the constituent fileservers.

 draft-ietf-nfsv4-federated-fs-protocol-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7532 RFC7533 Administration Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII 76429 37 Federated File Systems

This document describes the administration protocol for a federated file system (FedFS) 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 file systems physically hosted on and exported by the constituent fileservers.

 draft-ietf-nfsv4-federated-fs-admin-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7533 RFC7534 AS112 Nameserver Operations J. Abley W. Sotomayor May 2015 ASCII 47269 24 AS112 DNS reverse DNS anycast

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.

This document obsoletes RFC 6304.

 draft-ietf-dnsop-rfc6304bis-06 RFC6304 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7534 RFC7535 AS112 Redirection Using DNAME J. Abley B. Dickson W. Kumari G. Michaelson May 2015 ASCII 31730 16 DNS root server

AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.

This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.

 draft-ietf-dnsop-as112-dname-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7535 RFC7536 Large-Scale Broadband Measurement Use Cases M. Linsner P. Eardley T. Burbridge F. Sorensen May 2015 ASCII 41039 17 lmap

Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol. This document details two use cases that can assist in developing that framework. The details of the measurement metrics themselves are beyond the scope of this document.

 draft-ietf-lmap-use-cases-06 INFORMATIONAL INFORMATIONAL IETF ops lmap 10.17487/RFC7536 RFC7537 IANA Registries for LSP Ping Code Points B. Decraene N. Akiya C. Pignataro L. Andersson S. Aldrin May 2015 ASCII 11895 7 MPLS OAM lsp ping LSP-Ping

RFCs 4379 and 6424 created name spaces for Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for Downstream Mapping object Flags (DS Flags), Multipath Types, Pad TLVs, and Interface and Label Stack Address Types.

There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose.

 draft-ietf-mpls-lsp-ping-registry-03 RFC4379 RFC6424 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7537 RFC7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke April 2015 ASCII 11189 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

 draft-ietf-httpbis-rfc7238bis-03 RFC7238 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7538 RFC7539 ChaCha20 and Poly1305 for IETF Protocols Y. Nir A. Langley May 2015 ASCII 88173 45 AEAD

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.

This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-chacha20-poly1305-10 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7539 10.17487/RFC7539 RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2) M. Belshe R. Peon M. Thomson Editor May 2015 ASCII 209580 96 HTTP SPDY Web

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.

This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

 draft-ietf-httpbis-http2-17 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7540 10.17487/RFC7540 RFC7541 HPACK: Header Compression for HTTP/2 R. Peon H. Ruellan May 2015 ASCII 117827 55 HTTP Header

This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.

 draft-ietf-httpbis-header-compression-12 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7541 10.17487/RFC7541 RFC7542 The Network Access Identifier A. DeKok May 2015 ASCII 66596 30

In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.

 draft-ietf-radext-nai-15 RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC7542 RFC7543 Covering Prefixes Outbound Route Filter for BGP-4 H. Jeng L. Jalil R. Bonica K. Patel L. Yong May 2015 ASCII 38583 21 ORF VPN

This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.

 draft-ietf-bess-orf-covering-prefixes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=7543 10.17487/RFC7543 RFC7544 Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP) M. Mohali August 2015 ASCII 68612 30 Diversion History-Info

Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling.

RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests.

Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations.

This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.

 draft-mohali-rfc6044bis-02 RFC6044 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7544 10.17487/RFC7544 RFC7545 Protocol to Access White-Space (PAWS) Databases V. Chen Editor S. Das L. Zhu J. Malyar P. McCann May 2015 ASCII 188634 90 dynamic spectrum radio spectrum wireless spectrum spectrum spectrum database TV white space TVWS TVBD white space device WSD

Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "white space". Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization.

One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White-Space (PAWS) Databases".

 draft-ietf-paws-protocol-20 PROPOSED STANDARD PROPOSED STANDARD IETF app paws 10.17487/RFC7545 RFC7546 Structure of the Generic Security Service (GSS) Negotiation Loop B. Kaduk May 2015 ASCII 50075 21 GSS-API security authentication

This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.

 draft-ietf-kitten-gss-loop-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC7546 RFC7547 Management of Networks with Constrained Devices: Problem Statement and Requirements M. Ersue Editor D. Romascanu J. Schoenwaelder U. Herberg May 2015 ASCII 87357 44 Constrained Management IoT M2M

This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.

 draft-ietf-opsawg-coman-probstate-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7547 RFC7548 Management of Networks with Constrained Devices: Use Cases M. Ersue Editor D. Romascanu J. Schoenwaelder A. Sehgal May 2015 ASCII 71103 26 Constrained Management IoT M2M

This document discusses use cases concerning the management of networks in which constrained devices are involved. A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547).

 draft-ietf-opsawg-coman-use-cases-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7548 RFC7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter C. Holmberg J. Holm R. Jesske M. Dolly May 2015 ASCII 32607 17 3GPP IMS NNI IOTL CSCF RAVEL TRF operator transit

In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.

This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).

 draft-holmberg-dispatch-iotl-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7549 RFC7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options O. Troan B. Volz M. Siodelski May 2015 ASCII 54206 24 CPE CER CE Customer Edge Router Prefix Delegation IPv6 Address Option Session State Machine Advertise Time Timer T1 T2 Renew Rebind Confirm Decline Provision

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues.

 draft-ietf-dhc-dhcpv6-stateful-issues-12 RFC3315 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7550 RFC7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) F. Zhang Editor R. Jing R. Gandhi Editor May 2015 ASCII 43752 20

This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.

 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7551 RFC7552 Updates to LDP for IPv6 R. Asati C. Pignataro K. Raza V. Manral R. Papneja June 2015 ASCII 48801 24 Label Distribution Protocol

The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720.

 draft-ietf-mpls-ldp-ipv6-17 RFC5036 RFC6720 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7552 RFC7553 The Uniform Resource Identifier (URI) DNS Resource Record P. Faltstrom O. Kolkman June 2015 ASCII 28278 14 Operations DNS applications

This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.

 draft-faltstrom-uri-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7553 RFC7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement T. Watteyne Editor M. Palattella L. Grieco May 2015 ASCII 50706 23 6TiSCH

This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.

 draft-ietf-6tisch-tsch-06 INFORMATIONAL INFORMATIONAL IETF int 6tisch http://www.rfc-editor.org/errata_search.php?rfc=7554 10.17487/RFC7554 RFC7555 Proxy MPLS Echo Request G. Swallow V. Lim S. Aldrin June 2015 ASCII 62109 28

This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).

 draft-ietf-mpls-proxy-lsp-ping-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7555 10.17487/RFC7555 RFC7556 Multiple Provisioning Domain Architecture D. Anipko Editor June 2015 ASCII 59307 25

This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.

 draft-ietf-mif-mpvd-arch-11 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=7556 10.17487/RFC7556 RFC7557 Extension Mechanism for the Babel Routing Protocol J. Chroboczek May 2015 ASCII 22626 11 Babel routing extension TLV sub-TLV

This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.

 draft-chroboczek-babel-extension-mechanism-04 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7557 RFC7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions K. Lynn S. Cheshire M. Blanchet D. Migault July 2015 ASCII 30291 14

DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalable DNS-SD.

 draft-ietf-dnssd-requirements-06 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC7558 RFC7559 Packet-Loss Resiliency for Router Solicitations S. Krishnan D. Anipko D. Thaler May 2015 ASCII 11619 6

When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these Router Solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations.

 draft-ietf-6man-resilient-rs-06 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7559 RFC7560 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback M. Kuehlewind Editor R. Scheffenegger B. Briscoe August 2015 ASCII 40528 17 congestion control TCP

Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback.

 draft-ietf-tcpm-accecn-reqs-08 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7560 RFC7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN J. Kaippallimalil R. Pazhyannur P. Yegani June 2015 ASCII 50348 23 PMIPv6 Wi-Fi QoS

This document provides guidelines for achieving end-to-end Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end-to-end QoS.

 draft-ietf-netext-pmip-qos-wifi-08 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7561 RFC7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates D. Thakore July 2015 ASCII 32576 15 Transport Layer Security TLS SupplementalData DTCP

This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).

 draft-dthakore-tls-authz-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7562 RFC7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option R. Pazhyannur S. Speicher S. Gundavelli J. Korhonen J. Kaippallimalil June 2015 ASCII 27982 12

The Access Network Identifier (ANI) mobility option was introduced in RFC 6757, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6". This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and the MAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.

 draft-ietf-netext-ani-location-09 RFC6757 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7563 RFC7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols P. Saint-Andre M. Blanchet May 2015 ASCII 93580 40 internationalization i18n Stringprep

Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454.

 draft-ietf-precis-framework-23 RFC3454 PROPOSED STANDARD PROPOSED STANDARD IETF app precis http://www.rfc-editor.org/errata_search.php?rfc=7564 10.17487/RFC7564 RFC7565 The 'acct' URI Scheme P. Saint-Andre May 2015 ASCII 18244 8 Uniform Resource Identifier URI

This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.

 draft-ietf-appsawg-acct-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7565 RFC7566 Enumservice Registration for 'acct' URI L. Goix K. Li June 2015 ASCII 16874 8 Reverse Phone Lookup Social Network Web

This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).

 draft-goix-appsawg-enum-acct-uri-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7566 RFC7567 IETF Recommendations Regarding Active Queue Management F. Baker Editor G. Fairhurst Editor July 2015 ASCII 76832 31

This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.

Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.

 draft-ietf-aqm-recommendation-11 RFC2309 BCP0197 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv aqm 10.17487/RFC7567 RFC7568 Deprecating Secure Sockets Layer Version 3.0 R. Barnes M. Thomson A. Pironti A. Langley June 2015 ASCII 13489 7 SSL TLS insecure diediedie

The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.

This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.

 draft-ietf-tls-sslv3-diediedie-03 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7568 10.17487/RFC7568 RFC7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats D. Quigley J. Lu T. Haynes July 2015 ASCII 22406 10 NFSv4

In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.

To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.

 draft-ietf-nfsv4-lfs-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7569 RFC7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) C. Margaria Editor G. Martinelli S. Balls B. Wright July 2015 ASCII 34223 15 RSVP-TE GMPLS

RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.

 draft-ietf-teas-lsp-attribute-ro-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7570 RFC7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback J. Dong M. Chen Z. Li D. Ceccarelli July 2015 ASCII 19767 9 OAM

This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.

 draft-ietf-teas-rsvp-te-li-lb-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7571 RFC7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging P. Saint-Andre A. Houri J. Hildebrand June 2015 ASCII 29027 13 XMPP Jabber SIP SIMPLE IM Instant Message

This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

 draft-ietf-stox-im-13 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7572 RFC7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions P. Saint-Andre S. Loreto June 2015 ASCII 42607 20 Text Chat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).

 draft-ietf-stox-chat-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7573 RFC7574 Peer-to-Peer Streaming Peer Protocol (PPSPP) A. Bakker R. Petrocco V. Grishchenko July 2015 ASCII 208360 85 video on demand live streaming content integrity protection

The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content. It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.

 draft-ietf-ppsp-peer-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ppsp http://www.rfc-editor.org/errata_search.php?rfc=7574 10.17487/RFC7574 RFC7575 Autonomic Networking: Definitions and Design Goals M. Behringer M. Pritikin S. Bjarnason A. Clemm B. Carpenter S. Jiang L. Ciavaglia June 2015 ASCII 36838 16 self-management self-chop autonomic secure by default simplification

Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.

This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.

 draft-irtf-nmrg-autonomic-network-definitions-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7575 RFC7576 General Gap Analysis for Autonomic Networking S. Jiang B. Carpenter M. Behringer June 2015 ASCII 42472 17

This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.

This document is a product of the IRTF's Network Management Research Group.

 draft-irtf-nmrg-an-gap-analysis-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7576 RFC7577 Definition of Managed Objects for Battery Monitoring J. Quittek R. Winter T. Dietz July 2015 ASCII 86505 40 Energy Management Battery Status Battery MIB Management Information Base

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-battery-mib-20 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7577 RFC7578 Returning Values from Forms: multipart/form-data L. Masinter July 2015 ASCII 30240 15 media-type multipurpose internet mail extensions

This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. This document obsoletes RFC 2388.

 draft-ietf-appsawg-multipart-form-data-11 RFC2388 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7578 10.17487/RFC7578 RFC7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII 62347 28 WSON Optical Network Control Protocol-agnostic encoding

Generalized Multiprotocol Label Switching (GMPLS) 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-general-constraint-encode-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7579 RFC7580 OSPF-TE Extensions for General Network Element Constraints F. Zhang Y. Lee J. Han G. Bernstein Y. Xu June 2015 ASCII 25189 12 WSON Optical Routing

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). 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 describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.

 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7580 RFC7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII 72511 37 Optical Networks GMPLS control plane Wavelength Assignment Optical LSP Optical Routing

A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) 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 specific to WSONs.

This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. 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-rwa-wson-encode-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7581 RFC7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels E. Rosen IJ. Wijnands Y. Cai A. Boers July 2015 ASCII 79244 34

A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.

 draft-ietf-bess-mvpn-bidir-04 RFC6513 RFC6514 RFC6625 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7582 RFC7583 DNSSEC Key Rollover Timing Considerations S. Morris J. Ihren J. Dickinson W. Mekking October 2015 ASCII 66442 31

This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.

 draft-ietf-dnsop-dnssec-key-timing-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7583 RFC7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs) R. Ravindranath T. Reddy G. Salgueiro July 2015 ASCII 32675 14

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.

This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.

 draft-ietf-straw-b2bua-stun-08 PROPOSED STANDARD PROPOSED STANDARD IETF art straw http://www.rfc-editor.org/errata_search.php?rfc=7584 10.17487/RFC7584 RFC7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) S. Winter M. McCauley October 2015 ASCII 70699 32 RADIUS AAA Security Reliability DNS

This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).

 draft-ietf-radext-dynamic-discovery-15 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7585 RFC7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers Y. Nachum L. Dunbar I. Yerushalmi T. Mizrahi June 2015 ASCII 44538 21 ARP data center proxy

This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.

 draft-nachum-sarp-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7586 RFC7587 RTP Payload Format for the Opus Speech and Audio Codec J. Spittka K. Vos JM. Valin June 2015 ASCII 41770 18 audio codec

This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format.

 draft-ietf-payload-rtp-opus-11 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7587 RFC7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem R. Bonica C. Pignataro J. Touch July 2015 ASCII 24453 12 GRE MTU Fragmentation

This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration.

 draft-ietf-intarea-gre-mtu-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7588 RFC7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication M. Badra A. Luchuk J. Schoenwaelder June 2015 ASCII 22727 11 NETCONF 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 with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.

 draft-ietf-netconf-rfc5539bis-10 RFC5539 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC7589 RFC7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre T. Alkemade June 2015 ASCII 20393 9 Extensible Messaging and Presence Protocol XMPP Jabber Secure Sockets Layer SSL Transport Layer Security TLS instant messaging presence encryption authentication

This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120.

 draft-ietf-uta-xmpp-07 RFC6120 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC7590 RFC7591 OAuth 2.0 Dynamic Client Registration Protocol J. Richer Editor M. Jones J. Bradley M. Machulak P. Hunt July 2015 ASCII 87811 39 OpenID Connect Dynamic Client Registration OpenID Connect oidc openid user managed access uma Dynamic Registration Dynamic Client Registration

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

 draft-ietf-oauth-dyn-reg-30 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7591 RFC7592 OAuth 2.0 Dynamic Client Registration Management Protocol J. Richer Editor M. Jones J. Bradley M. Machulak July 2015 ASCII 38044 18

This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.

 draft-ietf-oauth-dyn-reg-management-15 EXPERIMENTAL EXPERIMENTAL IETF sec oauth 10.17487/RFC7592 RFC7593 The eduroam Architecture for Network Roaming K. Wierenga S. Winter T. Wolniewicz September 2015 ASCII 89517 37 Federated Authentication AAA RADIUS IEEE 802.1X roaming EAP eduroam

This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.

 draft-wierenga-ietf-eduroam-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7593 RFC7594 A Framework for Large-Scale Measurement of Broadband Performance (LMAP) P. Eardley A. Morton M. Bagnulo T. Burbridge P. Aitken A. Akhter September 2015 ASCII 131972 55 Controller Collector Measurement Agent Metric Measurement Method Measurement Results Registry

Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. This document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance).

 draft-ietf-lmap-framework-14 INFORMATIONAL INFORMATIONAL IETF ops lmap 10.17487/RFC7594 RFC7595 Guidelines and Registration Procedures for URI Schemes D. Thaler Editor T. Hansen T. Hardie June 2015 ASCII 42897 19 URI scheme IRI Internationalized Resource Identifier Uniform Resource Identifier URI registration

This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.

 draft-ietf-appsawg-uri-scheme-reg-06 RFC4395 BCP0035 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7595 10.17487/RFC7595 RFC7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture Y. Cui Q. Sun M. Boucadair T. Tsou Y. Lee I. Farrer July 2015 ASCII 47038 22 DS-Lite address sharing address exhaustion aplusp A+P IPv4 service continuity IPv4 over IPv6 connectivity

Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs.

 draft-ietf-softwire-lw4over6-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7596 RFC7597 Mapping of Address and Port with Encapsulation (MAP-E) O. Troan Editor W. Dec X. Li C. Bao S. Matsushima T. Murakami T. Taylor Editor July 2015 ASCII 70507 35

This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.

 draft-ietf-softwire-map-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7597 RFC7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients T. Mrugalski O. Troan I. Farrer S. Perreault W. Dec C. Bao L. Yeh X. Deng July 2015 ASCII 40023 18 MAP DHCPv6

This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.

 draft-ietf-softwire-map-dhcp-12 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7598 10.17487/RFC7598 RFC7599 Mapping of Address and Port using Translation (MAP-T) X. Li C. Bao W. Dec Editor O. Troan S. Matsushima T. Murakami July 2015 ASCII 55548 27

This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.

 draft-ietf-softwire-map-t-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7599 RFC7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) R. Despres S. Jiang Editor R. Penno Y. Lee G. Chen M. Chen July 2015 ASCII 96462 45 Coexistence Transition Interworking Tunneling Stateless 4rd IPv4 IPv6 Mapping Global Addressing

This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.

 draft-ietf-softwire-4rd-10 EXPERIMENTAL EXPERIMENTAL IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7600 10.17487/RFC7600 RFC7601 Message Header Field for Indicating Message Authentication Status M. Kucherawy August 2015 ASCII 120736 53 DKIM DomainKeys SenderID SPF ADSP ATPS VBR Authentication Reputation

This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

 draft-ietf-appsawg-rfc7001bis-11 RFC7001 RFC7410 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7601 10.17487/RFC7601 RFC7602 IS-IS Extended Sequence Number TLV U. Chunduri W. Lu A. Tian N. Shen July 2015 ASCII 23904 12

This document defines the Extended Sequence Number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks.

 draft-ietf-isis-extended-sequence-no-tlv-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7602 RFC7603 Energy Management (EMAN) Applicability Statement B. Schoening M. Chandramouli B. Nordman August 2015 ASCII 62218 28

The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.

 draft-ietf-eman-applicability-statement-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7603 RFC7604 Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) M. Westerlund T. Zeng September 2015 ASCII 110996 46 RTP Real-time Transport Protocol Real-time Firewall UDP

This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-Time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it, and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document.

 draft-ietf-mmusic-rtsp-nat-evaluation-16 INFORMATIONAL INFORMATIONAL IETF art mmusic 10.17487/RFC7604 RFC7605 Recommendations on Using Assigned Transport Port Numbers J. Touch August 2015 ASCII 58012 24 tcp udp sctp dccp service iana

This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document.

 draft-ietf-tsvwg-port-use-11 BCP0165 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=7605 10.17487/RFC7605 RFC7606 Revised Error Handling for BGP UPDATE Messages E. Chen Editor J. Scudder Editor P. Mohapatra K. Patel August 2015 ASCII 42141 19 BGP

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 because 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 a number of existing attributes.

This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.

 draft-ietf-idr-error-handling-19 RFC1997 RFC4271 RFC4360 RFC4456 RFC4760 RFC5543 RFC5701 RFC6368 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7606 RFC7607 Codification of AS 0 Processing W. Kumari R. Bush H. Schiller K. Patel August 2015 ASCII 9113 5 BGP AS 0 AS_PATH AS-PATH

This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message.

 draft-ietf-idr-as0-06 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7607 10.17487/RFC7607 RFC7608 IPv6 Prefix Length Recommendation for Forwarding M. Boucadair A. Petrescu F. Baker July 2015 ASCII 10818 6 IPv6 Routing CIDR Classless Inter-Domain Routing IPv6 Addressing Architecture IPv6 Forwarding Information Base IPv6 Routing Information Base FIB RIB IPv6 Deployment

IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.

 draft-ietf-v6ops-cidr-prefix-03 BCP0198 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7608 RFC7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol M. Fox C. Kassimis J. Stevens August 2015 ASCII 326888 143

This document describes IBM's Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides Remote Direct Memory Access (RDMA) communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available. It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.

 draft-fox-tcpm-shared-memory-rdma-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7609 RFC7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers F. Gont W. Liu G. Van de Velde August 2015 ASCII 26119 12

This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.

 draft-ietf-opsec-dhcpv6-shield-08 BCP0199 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7610 RFC7611 BGP ACCEPT_OWN Community Attribute J. Uttaro P. Mohapatra D. Smith R. Raszuk J. Scudder August 2015 ASCII 16976 8 BGP VPN L3VPN Extranet Well-known Reserved

Under certain conditions, it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router as the VRF(s) that imports the route. However, due to the constraints of BGP, it does not work if the two are on the same PE. This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.

 draft-ietf-l3vpn-acceptown-community-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7611 RFC7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald June 2015 ASCII 99282 54

This document defines a schema, object classes, and attributes, for Printers and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of "Internet Printing Protocol/1.1: Model and Semantics" (RFC 2911). Additional Printer attributes are based on definitions in "Printer MIB v2" (RFC 3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG 5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG 5100.13), and "IPP Everywhere" (PWG 5100.14).

This memo is an Independent Submission to the RFC Editor by the Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO Printer Working Group (PWG), as part of their PWG "IPP Everywhere" (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software.

This document obsoletes RFC 3712.

 draft-mcdonald-ldap-printer-schema-13 RFC3712 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7612 RFC7613 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords P. Saint-Andre A. Melnikov August 2015 ASCII 59062 27 Username Password Unicode Internationalization i18n Authentication SASLprep strings stringprep

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013.

 draft-ietf-precis-saslprepbis-18 RFC4013 PROPOSED STANDARD PROPOSED STANDARD IETF art precis 10.17487/RFC7613 RFC7614 Explicit Subscriptions for the REFER Method R. Sparks August 2015 ASCII 32358 14 SIP SIP Events nosub explicitsub Refer-Events-At

The Session Initiation Protocol (SIP) REFER request, as defined by RFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing. This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one.

 draft-ietf-sipcore-refer-explicit-subscription-03 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7614 RFC7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields J. Reschke September 2015 ASCII 12239 6 HTTP authentication

This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in Hypertext Transfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.

 draft-ietf-httpbis-auth-info-05 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7615 RFC7616 HTTP Digest Access Authentication R. Shekh-Yusef Editor D. Ahrens S. Bremer September 2015 ASCII 71946 32 HTTP authentication scheme

The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.

 draft-ietf-httpauth-digest-19 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF sec httpauth http://www.rfc-editor.org/errata_search.php?rfc=7616 10.17487/RFC7616 RFC7617 The 'Basic' HTTP Authentication Scheme J. Reschke September 2015 ASCII 30163 15 HTTP authentication scheme basic authentication scheme

This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.

 draft-ietf-httpauth-basicauth-update-07 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF sec httpauth 10.17487/RFC7617 RFC7618 Dynamic Allocation of Shared IPv4 Addresses Y. Cui Q. Sun I. Farrer Y. Lee Q. Sun M. Boucadair August 2015 ASCII 32576 15

This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport- layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included.

Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized.

 draft-ietf-dhc-dynamic-shared-v4allocation-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7618 RFC7619 The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) V. Smyslov P. Wouters August 2015 ASCII 24593 12 unauthenticated opportunistic security pervasive monitoring Peer Authorization Database PAD opportunistic encryption

This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity.

 draft-ietf-ipsecme-ikev2-null-auth-07 RFC4301 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7619 RFC7620 Scenarios with Host Identification Complications M. Boucadair Editor B. Chatras T. Reddy B. Williams B. Sarikaya August 2015 ASCII 60354 26 IP address sharing IPv4 service continuity host identifier de-multiplexing connections policy enforcement service delivery

This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered. This problem is abstracted as "host identification". Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase.

This document does not include any solution-specific discussions.

 draft-boucadair-intarea-host-identifier-scenarios-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7620 RFC7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework A.B. Roach August 2015 ASCII 6891 4 session initiation protocol

Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior.

This document updates RFC 6665.

 draft-ietf-sipcore-6665-clarification-00 RFC6665 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7621 RFC7622 Extensible Messaging and Presence Protocol (XMPP): Address Format P. Saint-Andre September 2015 ASCII 60008 27 Extensible Messaging and Presence Protocol XMPP Jabber Messaging Instant Messaging Presence Internationalization i18n PRECIS

This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122.

 draft-ietf-xmpp-6122bis-24 RFC6122 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp http://www.rfc-editor.org/errata_search.php?rfc=7622 10.17487/RFC7622 RFC7623 Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) A. Sajassi Editor S. Salam N. Bitar A. Isaac W. Henderickx September 2015 ASCII 52595 23

This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, 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.

 draft-ietf-l2vpn-pbb-evpn-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7623 RFC7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement R. Barnes B. Schneier C. Jennings T. Hardie B. Trammell C. Huitema D. Borkmann August 2015 ASCII 62260 24 eavesdropping

Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.

 draft-iab-privsec-confidentiality-threat-07 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7624 RFC7625 Architecture of an IP/MPLS Network with Hardened Pipes J. T. Hao P. Maheshwari R. Huang L. Andersson M. Chen August 2015 ASCII 30486 15

This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the "Hard Pipes", called the "Hard Pipe Stratum", and one for the normal IP/MPLS traffic, called the "Normal IP/MPLS Stratum".

This document introduces the concept of a Hard Pipe -- an MPLS Label Switched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon.

The Hard Pipe stratum does not use statistical multiplexing; for the LSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end.

The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services.

 draft-hao-mpls-ip-hard-pipe-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7625 RFC7626 DNS Privacy Considerations S. Bortzmeyer August 2015 ASCII 43202 17 Confidentiality Pervasive Surveillance Domain Name System

This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions.

 draft-ietf-dprive-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF int dprive 10.17487/RFC7626 RFC7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension K. Bhargavan Editor A. Delignat-Lavaud A. Pironti A. Langley M. Ray September 2015 ASCII 34788 15

The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.

 draft-ietf-tls-session-hash-06 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7627 RFC7628 A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth W. Mills T. Showalter H. Tschofenig August 2015 ASCII 46408 21

OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf.

This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols.

Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password.

 draft-ietf-kitten-sasl-oauth-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7628 RFC7629 Flow-Binding Support for Mobile IP S. Gundavelli Editor K. Leung G. Tsirtsis A. Petrescu August 2015 ASCII 42488 19 Multipath Flow Binding Hybrid Access Flow Mobility MIPv4-NEMO

This specification defines extensions to the Mobile IP 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 IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care-of addresses.

 draft-ietf-mip4-multiple-tunnel-support-13 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC7629 RFC7630 HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 J. Merkle Editor M. Lochter October 2015 ASCII 29324 14 Network Management SNMP USM HMAC SHA-2

This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.

 draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 RFC7860 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=7630 10.17487/RFC7630 RFC7631 TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format C. Dearlove T. Clausen September 2015 ASCII 34376 15 MANET packet message address TLV

This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the "Mobile Ad hoc NETwork (MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation.

This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444.

 draft-ietf-manet-tlv-naming-05 RFC5444 RFC7722 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7631 RFC7632 Endpoint Security Posture Assessment: Enterprise Use Cases D. Waltermire D. Harrington September 2015 ASCII 53853 23 security automation continuous monitoring endpoint posture assessment use case asset management configuration management vulnerability management content management

This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture.

 draft-ietf-sacm-use-cases-10 INFORMATIONAL INFORMATIONAL IETF sec sacm 10.17487/RFC7632 RFC7633 X.509v3 Transport Layer Security (TLS) Feature Extension P. Hallam-Baker October 2015 ASCII 21839 11 PKIX Transport Layer Security Cryptography Certificate

The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial-of-service attack that might otherwise be possible.

 draft-hallambaker-tlsfeature-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7633 10.17487/RFC7633 RFC7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec Y. Nir August 2015 ASCII 27513 13 IKE IPsec AEAD ChaCha ChaCha20 Salsa

This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec.

 draft-ietf-ipsecme-chacha20-poly1305-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7634 RFC7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization T. Reddy P. Patil R. Ravindranath J. Uberti August 2015 ASCII 51753 24 OAuth 2.0 STUN TURN WebRTC Authentication and Authorization

This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.

 draft-ietf-tram-turn-third-party-authz-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram http://www.rfc-editor.org/errata_search.php?rfc=7635 10.17487/RFC7635 RFC7636 Proof Key for Code Exchange by OAuth Public Clients N. Sakimura Editor J. Bradley N. Agarwal September 2015 ASCII 39482 20 smart phones apps XARA authorization custom scheme intent man-in-the-middle eavesdropping user agent swap spop pop openid connect pkce pixie

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").

 draft-ietf-oauth-spop-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7636 RFC7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation P. Garg Editor Y. Wang Editor September 2015 ASCII 40042 17

This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.

 draft-sridharan-virtualization-nvgre-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7637 RFC7638 JSON Web Key (JWK) Thumbprint M. Jones N. Sakimura September 2015 ASCII 27593 13 JavaScript Object Notation JSON JSON Web Key JWK ThumbprintOB Fingerprint Digest

This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.

 draft-ietf-jose-jwk-thumbprint-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7638 RFC7639 The ALPN HTTP Header Field A. Hutton J. Uberti M. Thomson August 2015 ASCII 14455 7 HTTP CONNECT Firewall HTTP proxy

This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.

 draft-ietf-httpbis-tunnel-protocol-05 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7639 RFC7640 Traffic Management Benchmarking B. Constantine R. Krishnan September 2015 ASCII 107543 51

This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.). The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic.

 draft-ietf-bmwg-traffic-management-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7640 RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) K. Hartke September 2015 ASCII 65842 30 Smart Objects Internet of Things IoT REST

The Constrained Application Protocol (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 enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.

 draft-ietf-core-observe-16 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC7641 RFC7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements K. LI Editor P. Hunt B. Khasnabish A. Nadalin Z. Zeltsan September 2015 ASCII 38759 19 SIM user scenarios SCIM use cases

This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.

 draft-ietf-scim-use-cases-08 INFORMATIONAL INFORMATIONAL IETF art scim 10.17487/RFC7642 RFC7643 System for Cross-domain Identity Management: Core Schema P. Hunt Editor K. Grizzle E. Wahlstroem C. Mortimore September 2015 ASCII 180665 104 Identity Provisioning User Group

The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.

This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers.

 draft-ietf-scim-core-schema-22 PROPOSED STANDARD PROPOSED STANDARD IETF art scim 10.17487/RFC7643 RFC7644 System for Cross-domain Identity Management: Protocol P. Hunt Editor K. Grizzle M. Ansari E. Wahlstroem C. Mortimore September 2015 ASCII 170460 89 SCIM

The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.

 draft-ietf-scim-api-19 PROPOSED STANDARD PROPOSED STANDARD IETF art scim http://www.rfc-editor.org/errata_search.php?rfc=7644 10.17487/RFC7644 RFC7645 The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis U. Chunduri A. Tian W. Lu September 2015 ASCII 28986 12

This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518) for both manual and automated key management protocols.

 draft-ietf-karp-isis-analysis-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7645 RFC7646 Definition and Use of DNSSEC Negative Trust Anchors P. Ebersman W. Kumari C. Griffiths J. Livingood R. Weber September 2015 ASCII 36117 16 NTA ISP Internet Service Provider DNS DNSSEC Negative Trust Anchors

DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.

 draft-ietf-dnsop-negative-trust-anchors-13 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7646 RFC7647 Clarifications for the Use of REFER with RFC 6665 R. Sparks A.B. Roach September 2015 ASCII 12596 6

The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.

 draft-ietf-sipcore-refer-clarifications-04 RFC3515 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7647 RFC7648 Port Control Protocol (PCP) Proxy Function S. Perreault M. Boucadair R. Penno D. Wing S. Cheshire September 2015 ASCII 31233 14 NAT firewall CGN AFTR NAT64 port forwarding pinholing port mapping external IP address discover port number running a server behind NAT NAT control NAT cascading DS-Lite incoming connection control outbound connection referral address referral ALG offload PCP client PCP server

This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.

 draft-ietf-pcp-proxy-09 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7648 RFC7649 The Jabber Scribe Role at IETF Meetings P. Saint-Andre D. York September 2015 ASCII 27720 12 Jabber Scribe IETF Meetings

During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.

 draft-saintandre-jabber-scribe-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7649 RFC7650 A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD) J. Jimenez J. Lopez-Vega J. Maenpaa G. Camarillo September 2015 ASCII 37404 19 CoAP 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 (WSNs) in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.

 draft-jimenez-p2psip-coap-reload-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7650 RFC7651 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2) A. Dodd-Noble S. Gundavelli J. Korhonen F. Baboescu B. Weis September 2015 ASCII 18767 10 P-CSCF P-CSCF Option for IKEv2 Proxy-Call Session Control Function IMS Option for IKEv2

This document defines two new configuration attributes for the Internet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.

 draft-gundavelli-ipsecme-3gpp-ims-options-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7651 RFC7652 Port Control Protocol (PCP) Authentication Mechanism M. Cullen S. Hartman D. Zhang T. Reddy September 2015 ASCII 78237 34

An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices.

This document updates RFC 6887.

 draft-ietf-pcp-authentication-14 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp http://www.rfc-editor.org/errata_search.php?rfc=7652 10.17487/RFC7652 RFC7653 DHCPv6 Active Leasequery D. Raghuvanshi K. Kinnear D. Kukrety October 2015 ASCII 71631 30 DHCP IPv6 ACTIVELEASEQUERY DHCPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.

 draft-ietf-dhc-dhcpv6-active-leasequery-04 RFC5460 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7653 RFC7654 Benchmarking Methodology for In-Service Software Upgrade (ISSU) S. Banks F. Calabria G. Czirjak R. Machat October 2015 ASCII 36991 16

Modern forwarding devices attempt to minimize any control- and data-plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service Software Upgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.

 draft-ietf-bmwg-issu-meth-02 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7654 RFC7655 RTP Payload Format for G.711.0 M. Ramalho Editor P. Jones N. Harada M. Perumal L. Miao November 2015 ASCII 77477 32 G.711.0 G.711 G.711ZIP Lossless G.711 Compression G.711 Data Compression Algorithm

This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.

 draft-ietf-payload-g7110-06 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7655 RFC7656 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources J. Lennox K. Gross S. Nandakumar G. Salgueiro B. Burman Editor November 2015 ASCII 101759 46 Taxonomy Terminology RTP Grouping

The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.

 draft-ietf-avtext-rtp-grouping-taxonomy-08 INFORMATIONAL INFORMATIONAL IETF art avtext 10.17487/RFC7656 RFC7657 Differentiated Services (Diffserv) and Real-Time Communication D. Black Editor P. Jones November 2015 ASCII 67721 26 Diffserv DSCP RAI RTP

This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.

 draft-ietf-dart-dscp-rtp-10 INFORMATIONAL INFORMATIONAL IETF rai dart 10.17487/RFC7657 RFC7658 Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs) S. Perreault T. Tsou S. Sivakumar T. Taylor October 2015 ASCII 121658 62 NATV2-MIB management information base

This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities.

This document obsoletes RFC 4008. All MIB objects specified in RFC 4008 are included in this version unchanged with only the STATUS changed to deprecated.

 draft-perrault-behave-deprecate-nat-mib-v1-06 RFC4008 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7658 RFC7659 Definitions of Managed Objects for Network Address Translators (NATs) S. Perreault T. Tsou S. Sivakumar T. Taylor October 2015 ASCII 183157 84 MIB management information base NATV2-MIB NAT-MIB basic nat pooled nat carrier-grade nat CGN

This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT-MIB. NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN).

 draft-perrault-behave-natv2-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7659 RFC7660 Diameter Congestion and Filter Attributes L. Bertz S. Manning B. Hirschman October 2015 ASCII 18830 9

This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimal Diameter filter administration.

RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions. It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested.

Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.

The optional attributes defined in this document are forward and backwards compatible with RFC 5777.

 draft-ietf-dime-congestion-flow-attributes-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7660 RFC7661 Updating TCP to Support Rate-Limited Traffic G. Fairhurst A. Sathiaseelan R. Secchi October 2015 ASCII 51267 21 CWV TCP

This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.

This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.

 draft-ietf-tcpm-newcwv-13 RFC2861 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC7661 RFC7662 OAuth 2.0 Token Introspection J. Richer Editor October 2015 ASCII 36591 17 token validation oauth token validation active token inactive token token metadata token status token status check

This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.

 draft-ietf-oauth-introspection-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7662 10.17487/RFC7662 RFC7663 Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) B. Trammell Editor M. Kuehlewind Editor October 2015 ASCII 30588 13 transport layer TCP UDP encapsulation

The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-semi-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7663 RFC7664 Dragonfly Key Exchange D. Harkins Editor November 2015 ASCII 37576 18 elliptic curve PAKE AKE dictionary attack password authentication

This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase. It is resistant to active attack, passive attack, and offline dictionary attack. This document is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-dragonfly-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7664 RFC7665 Service Function Chaining (SFC) Architecture J. Halpern Editor C. Pignataro Editor October 2015 ASCII 74825 32

This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.

 draft-ietf-sfc-architecture-11 INFORMATIONAL INFORMATIONAL IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=7665 10.17487/RFC7665 RFC7666 Management Information Base for Virtual Machines Controlled by a Hypervisor H. Asai M. MacFaden J. Schoenwaelder K. Shima T. Tsou October 2015 ASCII 106260 52 MIB Hypervisor Virtual Machine VM-MIB IANA-STORAGE-MEDIA-TYPE-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor).

 draft-ietf-opsawg-vmm-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=7666 10.17487/RFC7666 RFC7667 RTP Topologies M. Westerlund S. Wenger November 2015 ASCII 122959 48 Real-time Multi-party Mixer Relay SFM Selective Forwarding Middlebox Translator Multicast ASM SSM

This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.

 draft-ietf-avtcore-rtp-topologies-update-10 RFC5117 INFORMATIONAL INFORMATIONAL IETF art avtcore 10.17487/RFC7667 RFC7668 IPv6 over BLUETOOTH(R) Low Energy J. Nieminen T. Savolainen M. Isomaki B. Patil Z. Shelby C. Gomez October 2015 ASCII 52855 21 Bluetooth Low Energy 6lowpan IPv6 Low power

Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. 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 specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.

 draft-ietf-6lo-btle-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7668 RFC7669 Assigning Digital Object Identifiers to RFCs J. Levine October 2015 ASCII 15726 7

This document describes the way that Digital Object Identifiers (DOIs) are assigned to past and future RFCs. The DOI is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion.

 draft-iab-doi-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7669 RFC7670 Generic Raw Public-Key Support for IKEv2 T. Kivinen P. Wouters H. Tschofenig January 2016 ASCII 21350 10 Internet Key Exchange Version 2

The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys. In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This document updates RFC 7296, adding support for other types of raw public keys to IKEv2.

 draft-kivinen-ipsecme-oob-pubkey-14 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7670 RFC7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance V. Dukhovni W. Hardaker October 2015 ASCII 80496 33 DANE TLSA

This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.

 draft-ietf-dane-ops-16 RFC6698 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7671 RFC7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) V. Dukhovni W. Hardaker October 2015 ASCII 87943 34 DANE TLSA SMTP

This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).

 draft-ietf-dane-smtp-with-dane-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7672 RFC7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records T. Finch M. Miller P. Saint-Andre October 2015 ASCII 34193 16

The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.

 draft-ietf-dane-srv-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7673 RFC7674 Clarification of the Flowspec Redirect Extended Community J. Haas Editor October 2015 ASCII 12704 7 bgp flowspec

This document updates RFC 5575 ("Dissemination of Flow Specification Rules") to clarify the formatting of the BGP Flowspec Redirect Extended Community.

 draft-ietf-idr-flowspec-redirect-rt-bis-05 RFC5575 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7674 RFC7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness M. Perumal D. Wing R. Ravindranath T. Reddy M. Thomson October 2015 ASCII 22346 10 WebRTC

To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.

This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.

 draft-ietf-rtcweb-stun-consent-freshness-16 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7675 RFC7676 IPv6 Support for Generic Routing Encapsulation (GRE) C. Pignataro R. Bonica S. Krishnan October 2015 ASCII 21622 11 GRE IPv6

Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.

This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.

 draft-ietf-intarea-gre-ipv6-14 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC7676 RFC7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms T. Hansen November 2015 ASCII 15209 8

This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802.

 draft-hansen-scram-sha256-04 RFC5802 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7677 RFC7678 Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions C. Zhou T. Taylor Q. Sun M. Boucadair October 2015 ASCII 49074 23 DS-Lite Lightweight 4over6 MAP-E IPv4 service continuity IPv6 deployment IPv4 address sharing Diameter Multicast IPv4 over IPv6

During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.

 draft-ietf-dime-4over6-provisioning-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7678 RFC7679 A One-Way Delay Metric for IP Performance Metrics (IPPM) G. Almes S. Kalidindi M. Zekauskas A. Morton Editor January 2016 ASCII 59852 27 Performance Measurement Quality of Service (QoS)

This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete.

 draft-ietf-ippm-2679-bis-05 RFC2679 STD0081 INTERNET STANDARD INTERNET STANDARD IETF tsv ippm 10.17487/RFC7679 RFC7680 A One-Way Loss Metric for IP Performance Metrics (IPPM) G. Almes S. Kalidindi M. Zekauskas A. Morton Editor January 2016 ASCII 47253 22 Performance Measurement Quality of Service (QoS)

This memo defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete.

 draft-ietf-ippm-2680-bis-05 RFC2680 STD0082 INTERNET STANDARD INTERNET STANDARD IETF tsv ippm 10.17487/RFC7680 RFC7681 Email Exchange of Secondary School Transcripts J. Davin October 2015 ASCII 103965 40 Internet Applications email school transcript MIME OpenPGP

A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice.

 draft-davin-eesst-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7681 RFC7682 Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration D. McPherson S. Amante E. Osterweil L. Blunk D. Mitchell December 2015 ASCII 47996 18 Resource Certification Internet Routing Registry IRR Routing Policy Specification Language RPSL

The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.

 draft-ietf-grow-irr-routing-policy-considerations-06 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7682 RFC7683 Diameter Overload Indication Conveyance J. Korhonen Editor S. Donovan Editor B. Campbell L. Morand October 2015 ASCII 96330 42 DOIC

This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC).

 draft-ietf-dime-ovli-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=7683 10.17487/RFC7683 RFC7684 OSPFv2 Prefix/Link Attribute Advertisement P. Psenak H. Gredler R. Shakir W. Henderickx J. Tantsura A. Lindem November 2015 ASCII 33236 15 OSPF-LSA open shortest path first link state advertisement Opaque LSA

OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.

 draft-ietf-ospf-prefix-link-attr-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7684 RFC7685 A Transport Layer Security (TLS) ClientHello Padding Extension A. Langley October 2015 ASCII 7034 4

This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.

 draft-ietf-tls-padding-04 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7685 RFC7686 The ".onion" Special-Use Domain Name J. Appelbaum A. Muffett October 2015 ASCII 13475 7

This document registers the ".onion" Special-Use Domain Name.

 draft-ietf-dnsop-onion-tld-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7686 RFC7687 Report from the Strengthening the Internet (STRINT) Workshop S. Farrell R. Wenning B. Bos M. Blanchet H. Tschofenig December 2015 ASCII 73006 32 IAB W3C STREWS security pervasive monitoring London

The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-strint-report-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7687 RFC7688 GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Y. Lee Editor G. Bernstein Editor November 2015 ASCII 25429 12

This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all 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 optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.

 draft-ietf-ccamp-wson-signal-compatibility-ospf-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7688 RFC7689 Signaling Extensions for Wavelength Switched Optical Networks G. Bernstein Editor S. Xu Y. Lee Editor G. Martinelli H. Harai November 2015 ASCII 32687 16

This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs). Such extensions are applicable 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. This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.

 draft-ietf-ccamp-wson-signaling-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7689 RFC7690 Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) M. Byerly M. Hite J. Jaeggli January 2016 ASCII 19061 9 IPv6 ICMP6 ICMPv6 type 2 PTB

This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load-balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures.

 draft-ietf-v6ops-pmtud-ecmp-problem-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7690 RFC7691 Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members S. Bradner Editor November 2015 ASCII 7197 4

BCP 101 defines the start and end dates for the terms of IETF Administrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct the IAOC to establish more practical start and end dates for terms of IAOC members.

 draft-bradner-iaoc-terms-04 RFC4071 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7691 RFC7692 Compression Extensions for WebSocket T. Yoshino December 2015 ASCII 62411 28 DEFLATE LZ77

This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm.

 draft-ietf-hybi-permessage-compression-28 PROPOSED STANDARD PROPOSED STANDARD IETF art hybi 10.17487/RFC7692 RFC7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) M-J. Saarinen Editor J-P. Aumasson November 2015 ASCII 55532 30 BLAKE2 Cryptographic Hash

This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).

 draft-saarinen-blake2-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7693 RFC7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding J. Reschke November 2015 ASCII 13676 7 HTTP content-encoding

In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.

Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests.

 draft-ietf-httpbis-cice-03 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7694 RFC7695 Distributed Prefix Assignment Algorithm P. Pfister B. Paterson J. Arkko November 2015 ASCII 46244 20 distributed prefix address assignment homenet

This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub-prefixes that are unique and non-overlapping. Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated.

 draft-ietf-homenet-prefix-assignment-08 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC7695 RFC7696 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms R. Housley November 2015 ASCII 50543 19

Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.

 draft-iab-crypto-alg-agility-08 BCP0201 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7696 RFC7697 MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) P. Pan S. Aldrin M. Venkatesan K. Sampath T. Nadeau S. Boutros January 2016 ASCII 66337 36 MPLS-OAM-ID-STD-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 to configure the Operations, Administration, and Maintenance (OAM) identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP).

 draft-ietf-mpls-tp-oam-id-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7697 10.17487/RFC7697 RFC7698 Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks O. Gonzalez de Dios Editor R. Casellas Editor F. Zhang X. Fu D. Ceccarelli I. Hussain November 2015 ASCII 89787 42 DWDM Flexi-Grid GMPLS

To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid).

Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to the GMPLS protocols will be defined in companion documents.

 draft-ietf-ccamp-flexi-grid-fwk-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7698 RFC7699 Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers A. Farrel D. King Y. Li F. Zhang November 2015 ASCII 30463 14 GMPLS RSVP-TE

GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid.

This document updates RFCs 3471 and 6205 by introducing a new label format.

 draft-ietf-ccamp-flexigrid-lambda-label-05 RFC3471 RFC6205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7699 RFC7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames P. Saint-Andre December 2015 ASCII 22898 11 nickname SIP SIMPLE XMPP MSRP XCON chatrooms

This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities.

 draft-ietf-precis-nickname-19 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=7700 10.17487/RFC7700 RFC7701 Multi-party Chat Using the Message Session Relay Protocol (MSRP) A. Niemi M. Garcia-Martin G. Sandbakken December 2015 ASCII 99607 42 messaging message sessions multi-party chat MSRP SIMPLE

The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) 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-chat-18 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC7701 RFC7702 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat P. Saint-Andre S. Ibarra S. Loreto December 2015 ASCII 86457 43 Text Chat Groupchat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension.

 draft-ietf-stox-groupchat-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7702 RFC7703 Experience with Testing of Mapping of Address and Port Using Translation (MAP-T) E. Cordeiro R. Carnier A. Moreiras November 2015 ASCII 126481 56 template

This document describes the testing result of a network utilizing a Mapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.

The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines.

 draft-cordeiro-experience-mapt-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7703 RFC7704 An IETF with Much Diversity and Professional Conduct D. Crocker N. Clark November 2015 ASCII 41359 18

The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions. In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content. Groups with greater diversity make better decisions. Obtaining meaningful diversity requires more than generic good will and statements of principle. Many different behaviors can serve to reduce participant diversity or participation diversity. This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it. The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF.

 draft-crocker-diversity-conduct-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7704 RFC7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute W. George S. Amante November 2015 ASCII 41349 16 as-migration AS-migration AS_migration AS migration IDR BGP

This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.

 draft-ietf-idr-as-migration-06 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7705 RFC7706 Decreasing Access Time to Root Servers by Running One on Loopback W. Kumari P. Hoffman November 2015 ASCII 24234 12

Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.

 draft-ietf-dnsop-root-loopback-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7706 10.17487/RFC7706 RFC7707 Network Reconnaissance in IPv6 Networks F. Gont T. Chown March 2016 ASCII 88281 38

IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.

 draft-ietf-opsec-ipv6-host-scanning-08 RFC5157 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7707 RFC7708 Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator T. Nadeau L. Martini S. Bryant November 2015 ASCII 18881 9 VCCV GAL

The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).

 draft-ietf-pals-vccv-for-gal-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7708 RFC7709 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) A. Malis Editor B. Wilson G. Clapp V. Shukla November 2015 ASCII 20022 9 generalized multiprotocol label switching OTN optical transport networks WSON TDM WDM churn on-demand wavelength rapid setup

Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience.

The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).

 draft-ietf-teas-fast-lsps-requirements-02 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC7709 RFC7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs) W. Kumari O. Gudmundsson P. Ebersman S. Sheng December 2015 ASCII 16352 8

In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.

This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document.

 draft-wkumari-dhc-capport-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7710 RFC7711 PKIX over Secure HTTP (POSH) M. Miller P. Saint-Andre November 2015 ASCII 41302 18 Extensible Messaging and Presence Protocol Jabber federation

Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.

 draft-ietf-xmpp-posh-06 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp 10.17487/RFC7711 RFC7712 Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre M. Miller P. Hancke November 2015 ASCII 49879 24 XMPP Extensible Messaging and Presence Protocol Jabber federation delegation security

This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.

 draft-ietf-xmpp-dna-11 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp 10.17487/RFC7712 RFC7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements M. Mathis B. Briscoe December 2015 ASCII 76797 30 Quality of Service QoS Congestion Control Signaling Protocol Encoding Audit Policing

This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (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, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.

 draft-ietf-conex-abstract-mech-13 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC7713 RFC7714 AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) D. McGrew K. Igoe December 2015 ASCII 95334 48

This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).

 draft-ietf-avtcore-srtp-aes-gcm-17 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC7714 RFC7715 Multipoint LDP (mLDP) Node Protection IJ. Wijnands Editor K. Raza A. Atlas J. Tantsura Q. Zhao January 2016 ASCII 39353 19

This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP). In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.

 draft-ietf-mpls-mldp-node-protection-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7715 RFC7716 Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures J. Zhang L. Giuliano E. Rosen Editor K. Subramanian D. Pacella December 2015 ASCII 52951 22 Multicast

RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.

 draft-ietf-bess-mvpn-global-table-mcast-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7716 RFC7717 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) K. Pentikousis Editor E. Zhang Y. Cui December 2015 ASCII 34960 15

The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.

 draft-ietf-ippm-ipsec-11 RFC4656 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7717 RFC7718 Registries for the One-Way Active Measurement Protocol (OWAMP) A. Morton December 2015 ASCII 14719 7

This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.

 draft-ietf-ippm-owamp-registry-03 RFC4656 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7718 RFC7719 DNS Terminology P. Hoffman A. Sullivan K. Fujiwara December 2015 ASCII 68383 27

The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.

 draft-ietf-dnsop-dns-terminology-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7719 10.17487/RFC7719 RFC7720 DNS Root Name Service Protocol and Deployment Requirements M. Blanchet L-J. Liman December 2015 ASCII 10552 6

The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope.

 draft-iab-2870bis-03 RFC2870 BCP0040 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC7720 RFC7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms A. Cooper F. Gont D. Thaler March 2016 ASCII 43381 18

This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.

 draft-ietf-6man-ipv6-address-generation-privacy-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7721 RFC7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) C. Dearlove T. Clausen December 2015 ASCII 52375 23

This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.

This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.

 draft-ietf-manet-olsrv2-multitopology-07 RFC7188 RFC7631 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7722 RFC7723 Port Control Protocol (PCP) Anycast Addresses S. Kiesel R. Penno January 2016 ASCII 20663 9 Port Control Protocol anycast address anycast server discovery Port Control Protocol server discovery port mapping NAT control firewall control

The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.

 draft-ietf-pcp-anycast-08 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7723 RFC7724 Active DHCPv4 Lease Query K. Kinnear M. Stapp B. Volz N. Russell December 2015 ASCII 66964 28

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".

 draft-ietf-dhc-dhcpv4-active-leasequery-07 RFC6926 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7724 RFC7725 An HTTP Status Code to Report Legal Obstacles T. Bray February 2016 ASCII 9309 5 Hypertext Transfer Protocol

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

 draft-ietf-httpbis-legally-restricted-status-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7725 RFC7726 Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) V. Govindan K. Rajaraman G. Mirsky N. Akiya S. Aldrin January 2016 ASCII 13899 7 RFC5884 MPLS LSP BFD RFC 5884

This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.

 draft-ietf-bfd-rfc5884-clarifications-04 RFC5884 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7726 RFC7727 Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) M. Zhang H. Wen J. Hu January 2016 ASCII 48135 25

The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.

In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined.

 draft-ietf-pwe3-iccp-stp-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7727 RFC7728 RTP Stream Pause and Resume B. Burman A. Akram R. Even M. Westerlund February 2016 ASCII 135619 55 CCM RTCP Feedback Bandwidth PAUSED REFUSED TMMBR TMMBN Mixer MCU

With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104.

 draft-ietf-avtext-rtp-stream-pause-10 RFC5104 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC7728 RFC7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management B. Khasnabish E. Haleplidis J. Hadi Salim Editor December 2015 ASCII 40570 20 ForCES LFB Subsidiary Management Virtualization

Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE. The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.

 draft-ietf-forces-lfb-subsidiary-management-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7729 RFC7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent January 2016 ASCII 17672 8 RPKI BGP Security

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.

 draft-ietf-sidr-rfc6490-bis-05 RFC6490 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7730 RFC7731 Multicast Protocol for Low-Power and Lossy Networks (MPL) J. Hui R. Kelsey February 2016 ASCII 63216 29 6lowpan 802.15.4 IPv6 LLN ROLL mesh network trickle wsn wireless sensor network

This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.

MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.

 draft-ietf-roll-trickle-mcast-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC7731 RFC7732 Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) P. van der Stok R. Cragie February 2016 ASCII 34403 15 routing MPL multicast policy IP networks

The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.

 draft-ietf-roll-admin-local-policy-03 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7732 RFC7733 Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control A. Brandt E. Baccelli R. Cragie P. van der Stok February 2016 ASCII 85372 38 sensor network ad hoc network routing RPL applicability building control home automation IP networks

The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.

 draft-ietf-roll-applicability-home-building-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC7733 RFC7734 Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) D. Allan Editor J. Tantsura D. Fedyk A. Sajassi January 2016 ASCII 23512 11 SPBM Provider Backbone Bridging Provider Edges PBB-EVPN

This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.

 draft-ietf-bess-spbm-evpn-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7734 RFC7735 Tracking Reviews of Documents R. Sparks T. Kivinen January 2016 ASCII 35326 16 review tool requirements

Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows.

 draft-sparks-genarea-review-tracker-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7735 RFC7736 Content Delivery Network Interconnection (CDNI) Media Type Registration K. Ma December 2015 ASCII 13053 7 CDNI CDN Interconnect CDN content delivery content delivery network

This document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.

 draft-ietf-cdni-media-type-06 INFORMATIONAL INFORMATIONAL IETF art cdni 10.17487/RFC7736 RFC7737 Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification N. Akiya G. Swallow C. Pignataro L. Andersson M. Chen January 2016 ASCII 35253 17 MPLS LSP Ping Reply Mode

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values.

 draft-ietf-mpls-lsp-ping-reply-mode-simple-05 RFC7110 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7737 RFC7738 A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS) M. Blanchet A. Schiltknecht P. Shames January 2016 ASCII 14304 8

This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).

 draft-blanchet-ccsds-urn-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7738 RFC7739 Security Implications of Predictable Fragment Identification Values F. Gont February 2016 ASCII 46433 20 attack vulnerability Denial of Service protocol identifiers

IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.

 draft-ietf-6man-predictable-fragment-id-10 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7739 RFC7740 Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication Z. Zhang Y. Rekhter A. Dolganow January 2016 ASCII 18252 8 MVPN Ingress Replication Bidirectional C-flow p-tunnel

RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.

 draft-ietf-bess-mvpn-bidir-ingress-replication-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7740 RFC7741 RTP Payload Format for VP8 Video P. Westin H. Lundin M. Glover J. Uberti F. Galligan March 2016 ASCII 58399 27 RTP V8 WebM

This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.

 draft-ietf-payload-vp8-17 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7741 RFC7742 WebRTC Video Processing and Codec Requirements A.B. Roach March 2016 ASCII 21184 10 MTI mandatory-to-implement

This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.

 draft-ietf-rtcweb-video-06 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7742 RFC7743 Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping J. Luo Editor L. Jin Editor T. Nadeau Editor G. Swallow Editor January 2016 ASCII 39321 18

In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.

 draft-ietf-mpls-lsp-ping-relay-reply-11 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7743 RFC7744 Use Cases for Authentication and Authorization in Constrained Environments L. Seitz Editor S. Gerdes Editor G. Selander M. Mani S. Kumar January 2016 ASCII 72630 30 Internet of Things IoT Smart Object Security

Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.

This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.

Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.

 draft-ietf-ace-usecases-10 INFORMATIONAL INFORMATIONAL IETF sec ace 10.17487/RFC7744 RFC7745 XML Schemas for Reverse DNS Management T. Manderson January 2016 ASCII 17788 10

This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.

 draft-manderson-rdns-xml-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7745 RFC7746 Label Switched Path (LSP) Self-Ping R. Bonica I. Minei M. Conn D. Pacella L. Tomotaki January 2016 ASCII 25146 12

When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.

This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.

LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.

LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.

 draft-ietf-mpls-self-ping-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7746 RFC7747 Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence R. Papneja B. Parise S. Hares D. Lee I. Varlashkin April 2016 ASCII 65341 35 BMWG

BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.

 draft-ietf-bmwg-bgp-basic-convergence-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7747 RFC7748 Elliptic Curves for Security A. Langley M. Hamburg S. Turner January 2016 ASCII 39298 22 elliptic curve cryptography ecc

This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.

 draft-irtf-cfrg-curves-11 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7748 10.17487/RFC7748 RFC7749 The "xml2rfc" Version 2 Vocabulary J. Reschke February 2016 ASCII 109478 76 XML IETF RFC Internet-Draft Vocabulary

This document defines the "xml2rfc" version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.

Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.

This document obsoletes RFC 2629.

 draft-iab-xml2rfcv2-02 RFC2629 RFC7991 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7749 10.17487/RFC7749 RFC7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) J. Hedin G. Mirsky S. Baillargeon February 2016 ASCII 24296 11 IPPM TWAMP Type-P Descriptor

This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.

 draft-ietf-ippm-type-p-monitor-03 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7750 RFC7751 Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) S. Sorce T. Yu March 2016 ASCII 23133 10 Kerberos

This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120.

 draft-ietf-kitten-cammac-04 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7751 RFC7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP H. Gredler Editor J. Medved S. Previdi A. Farrel S. Ray March 2016 ASCII 113130 48 BGP North-Bound API Link-State Topology Controller Multi-Area Multi-AS

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 (TE) information. This is information typically distributed by IGP routing protocols within the network.

This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).

 draft-ietf-idr-ls-distribution-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7752 RFC7753 Port Control Protocol (PCP) Extension for Port-Set Allocation Q. Sun M. Boucadair S. Sivakumar C. Zhou T. Tsou S. Perreault February 2016 ASCII 34550 19 IPv4 service continuity IPv4 address shortage A+P AplusP address plus port MAP Port range Port Range Router MAP-E port set mapping port bulk

In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET.

 draft-ietf-pcp-port-set-13 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7753 RFC7754 Technical Considerations for Internet Service Blocking and Filtering R. Barnes A. Cooper O. Kolkman D. Thaler E. Nordmark March 2016 ASCII 85046 33 Firewall Filter Deep Packet Inspection Domain Name Seizure Web Portal Web Proxy

The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.

 draft-iab-filtering-considerations-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7754 RFC7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments T. Anderson February 2016 ASCII 54648 24 Data Centre Data Center Dual Stack Single Stack IDC IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.

The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.

 draft-ietf-v6ops-siit-dc-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7755 RFC7756 Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode T. Anderson S. Steffann February 2016 ASCII 39291 17 Data Centre Data Center Dual Stack Single Stack IDC IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.

The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.

 draft-ietf-v6ops-siit-dc-2xlat-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7756 RFC7757 Explicit Address Mappings for Stateless IP/ICMP Translation T. Anderson A. Leiva Popper February 2016 ASCII 40938 19 Dual Stack Single Stack IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.

 draft-ietf-v6ops-siit-eam-03 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC7757 RFC7758 Time Capability in NETCONF T. Mizrahi Y. Moses February 2016 ASCII 56330 32 NETCONF network management time clock synchronization

This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients.

 draft-mm-netconf-time-capability-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC7758 RFC7759 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping E. Bellagamba G. Mirsky L. Andersson P. Skoldstrom D. Ward J. Drake February 2016 ASCII 66411 29 LSP-PING MPLS MPLS-TP OAM

This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol.

 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7759 RFC7760 Statement of Work for Extensions to the IETF Datatracker for Author Statistics R. Housley January 2016 ASCII 16816 8

This is the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors.

 draft-housley-sow-author-statistics-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7760 RFC7761 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas R. Parekh Z. Zhang L. Zheng March 2016 ASCII 295255 137

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.

This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.

 draft-ietf-pim-rfc4601bis-06 RFC4601 STD0083 INTERNET STANDARD INTERNET STANDARD IETF rtg pim 10.17487/RFC7761 RFC7762 Initial Assignment for the Content Security Policy Directives Registry M. West January 2016 ASCII 10241 5

This document establishes an Internet Assigned Number Authority (IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content Security Policy Level 2 specification.

 draft-west-webappsec-csp-reg-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7762 RFC7763 The text/markdown Media Type S. Leonard March 2016 ASCII 34580 15

This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.

 draft-ietf-appsawg-text-markdown-12 INFORMATIONAL INFORMATIONAL IETF art appsawg 10.17487/RFC7763 RFC7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations S. Leonard March 2016 ASCII 50910 28 text/markdown

This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied.

 draft-ietf-appsawg-text-markdown-use-cases-07 INFORMATIONAL INFORMATIONAL IETF art appsawg 10.17487/RFC7764 RFC7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart P. Hurtig A. Brunstrom A. Petlund M. Welzl February 2016 ASCII 35361 15 tcp retransmission timer rtor

This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited.

 draft-ietf-tcpm-rtorestart-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC7765 RFC7766 DNS Transport over TCP - Implementation Requirements J. Dickinson S. Dickinson R. Bellis A. Mankin D. Wessels March 2016 ASCII 40616 19 DNS TCP/IP transport

This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.

 draft-ietf-dnsop-5966bis-06 RFC5966 RFC1035 RFC1123 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7766 RFC7767 Application-Initiated Check-Pointing via the Port Control Protocol (PCP) S. Vinapamula S. Sivakumar M. Boucadair T. Reddy February 2016 ASCII 24178 12 serviceability SDN resilience robustness network programmability network API application control service-aware networking automation

This document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.

This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed.

 draft-vinapamula-flow-ha-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7767 RFC7768 Port Management to Reduce Logging in Large-Scale NATs T. Tsou W. Li T. Taylor J. Huang January 2016 ASCII 23442 11

Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low.

 draft-tsou-behave-natx4-log-reduction-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7768 RFC7769 Media Access Control (MAC) Address Withdrawal over Static Pseudowire S. Sivabalan S. Boutros H. Shah S. Aldrin M. Venkatesan February 2016 ASCII 20518 10 PW ACH associated channel

This document specifies a mechanism to signal Media Access Control (MAC) address withdrawal notification using a pseudowire (PW) Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.

 draft-ietf-pals-mpls-tp-mac-wd-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7769 RFC7770 Extensions to OSPF for Advertising Optional Router Capabilities A. Lindem Editor N. Shen JP. Vasseur R. Aggarwal S. Shaffer February 2016 ASCII 32855 15 ospfv2 ospfv3 open shortest path first ri router information lsa link state advertisement

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.

 draft-ietf-ospf-rfc4970bis-07 RFC4970 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7770 RFC7771 Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires A. Malis Editor L. Andersson H. van Helvoort J. Shin L. Wang A. D'Alessandro January 2016 ASCII 19235 9 end-to-end protection linear protection

In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection.

 draft-ietf-pals-ms-pw-protection-04 RFC6870 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7771 RFC7772 Reducing Energy Consumption of Router Advertisements A. Yourtchenko L. Colitti February 2016 ASCII 12555 6

Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.

 draft-ietf-v6ops-reducing-ra-energy-consumption-03 BCP0202 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7772 RFC7773 Authentication Context Certificate Extension S. Santesson March 2016 ASCII 33338 16

This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears.

This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion Markup Language (SAML) assertion.

 draft-santesson-auth-context-extension-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7773 RFC7774 Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 Y. Doi M. Gillmore March 2016 ASCII 21758 10 MPL DHCPv6

This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in an MPL Domain. Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters.

 draft-ietf-roll-mpl-parameter-configuration-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC7774 RFC7775 IS-IS Route Preference for Extended IP and IPv6 Reachability L. Ginsberg S. Litkowski S. Previdi February 2016 ASCII 23624 11

In existing specifications, the route preferences for IPv4/IPv6 Extended Reachability TLVs are not explicitly stated. There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2 Link State Protocol Data Units (LSPs). This document addresses these issues.

 draft-ietf-isis-route-preference-02 RFC5308 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7775 RFC7776 IETF Anti-Harassment Procedures P. Resnick A. Farrel March 2016 ASCII 42853 18 Ombudsman Ombudsperson Ombudsteam

IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.

This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.

 draft-farrresnickel-harassment-10 RFC2418 RFC7437 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7776 RFC7777 Advertising Node Administrative Tags in OSPF S. Hegde R. Shakir A. Smirnov Z. Li B. Decraene March 2016 ASCII 33684 15 open shortest path first

This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to the OSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF.

This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags.

 draft-ietf-ospf-node-admin-tag-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7777 RFC7778 Mobile Communication Congestion Exposure Scenario D. Kutscher F. Mir R. Winter S. Krishnan Y. Zhang CJ. Bernardos March 2016 ASCII 56883 25 congestion exposure mobile communications

This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks.

 draft-ietf-conex-mobile-06 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC7778 RFC7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) H. Rogge E. Baccelli April 2016 ASCII 43953 21 MANET metric ad hoc network routing IP networks OLSR ETT ETX Funkfeuer DAT

This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).

 draft-ietf-manet-olsrv2-dat-metric-12 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7779 RFC7780 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates D. Eastlake 3rd M. Zhang R. Perlman A. Banerjee A. Ghanwani S. Gupta February 2016 ASCII 125037 57 TRILL RBridge IS-IS reachability overload MTU DEI multicast RPF color E-L1FS purge

Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179.

 draft-ietf-trill-rfc7180bis-07 RFC7180 RFC6325 RFC7177 RFC7179 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7780 RFC7781 Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access H. Zhai T. Senevirathne R. Perlman M. Zhang Y. Li February 2016 ASCII 79489 35 virtual RBridge aggregation flip-flopping

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active-active access to such an end station is represented as a virtual RBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations.

 draft-ietf-trill-pseudonode-nickname-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7781 RFC7782 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments M. Zhang R. Perlman H. Zhai M. Durrani S. Gupta February 2016 ASCII 47989 22 LAALP vSwitch MC-LAG DRNI

TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.

This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one host Media Access Control (MAC) address being associated with the multiple RBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.

 draft-ietf-trill-aa-multi-attach-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7782 RFC7783 Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL) T. Senevirathne J. Pathangi J. Hudson February 2016 ASCII 36970 16 Affinity RPF

TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarders provide VLAN-based load sharing with an active-standby model. High-performance applications require an active-active load-sharing model. The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge (also referred to as a virtual Routing Bridge or virtual TRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility to RBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325.

 draft-ietf-trill-cmt-11 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7783 RFC7784 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB D. Kumar S. Salam T. Senevirathne February 2016 ASCII 99471 50 CFM MEP MIP Fault Management

This document specifies the MIB for the OAM (Operations, Administration, and Maintenance) objects for IETF TRILL (Transparent Interconnection of Lots of Links).

 draft-ietf-trill-oam-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7784 RFC7785 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite S. Vinapamula M. Boucadair February 2016 ASCII 20529 9 IPv4 service continuity IPv4 address exhaustion Service Availability High Availability Address sharing IPv6 Reliability IPv4 over IPv6 State migration Stability Disruption Privacy

This document discusses issues induced by the change of the Dual- Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues.

 draft-vinapamula-softwire-dslite-prefix-binding-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7785 RFC7786 TCP Modifications for Congestion Exposure (ConEx) M. Kuehlewind Editor R. Scheffenegger May 2016 ASCII 48439 20

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).

 draft-ietf-conex-tcp-modifications-10 EXPERIMENTAL EXPERIMENTAL IETF tsv conex 10.17487/RFC7786 RFC7787 Distributed Node Consensus Protocol M. Stenberg S. Barth April 2016 ASCII 96466 41 Homenet

This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees. DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol.

 draft-ietf-homenet-dncp-12 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC7787 RFC7788 Home Networking Control Protocol M. Stenberg S. Barth P. Pfister April 2016 ASCII 94146 40 IPv6 Homenet DNCP

This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.

 draft-ietf-homenet-hncp-10 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet http://www.rfc-editor.org/errata_search.php?rfc=7788 10.17487/RFC7788 RFC7789 Impact of BGP Filtering on Inter-Domain Routing Policies C. Cardona P. Francois P. Lucente April 2016 ASCII 38047 16 More-specific prefix Less-specific prefix Autonomous systems Traffic engineering

This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it.

 draft-ietf-grow-filtering-threats-08 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7789 RFC7790 Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) Y. Yoneya T. Nemoto February 2016 ASCII 20806 10

The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping. In addition, both the Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers of PRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters.

 draft-ietf-precis-mappings-12 INFORMATIONAL INFORMATIONAL IETF art precis 10.17487/RFC7790 RFC7791 Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2) D. Migault Editor V. Smyslov March 2016 ASCII 32532 14 MIF Load balancing Load sharing MOBIKE

This document considers a VPN end user establishing an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.

The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.

 draft-mglt-ipsecme-clone-ike-sa-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7791 RFC7792 RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks F. Zhang X. Zhang A. Farrel O. Gonzalez de Dios D. Ceccarelli March 2016 ASCII 20801 12 Flexible-grid Flexible optical grid Optical network Optical trail Optical LSP GMPLS WDM PCE spectrum reservation flexible spectrum

This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.

 draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7792 RFC7793 Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry M. Andrews May 2016 ASCII 7713 6

RFC 6598 specifies that "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure."

This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries from accidentally leaking to the global DNS infrastructure.

 draft-ietf-dnsop-rfc6598-rfc6303-05 BCP0163 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC7793 RFC7794 IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability L. Ginsberg Editor B. Decraene S. Previdi X. Xu U. Chunduri March 2016 ASCII 15925 9 ISIS

This document introduces new sub-TLVs to support advertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.

 draft-ietf-isis-prefix-attributes-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7794 RFC7795 Pseudowire Redundancy on the Switching Provider Edge (S-PE) J. Dong H. Wang February 2016 ASCII 21064 9

This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the Switching Provider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and 6478 is reused. This document does not require any change to the Terminating Provider Edges (T-PEs) of MS-PW.

 draft-ietf-pals-redundancy-spe-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7795 RFC7796 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) Y. Jiang Editor L. Yong M. Paul March 2016 ASCII 52579 26 Etree

This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.

 draft-ietf-l2vpn-vpls-pe-etree-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7796 RFC7797 JSON Web Signature (JWS) Unencoded Payload Option M. Jones February 2016 ASCII 23108 11 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS Digital Signature Message Authentication Code MAC Unencoded Payload

JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.

This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.

 draft-ietf-jose-jws-signing-input-options-09 RFC7519 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7797 RFC7798 RTP Payload Format for High Efficiency Video Coding (HEVC) Y.-K. Wang Y. Sanchez T. Schierl S. Wenger M. M. Hannuksela March 2016 ASCII 209680 86 H.265 : ISO/IEC 23008-2 Single NAL Unit Packet Aggregation Packet Fragmentation Unit Payload Content Information Packet Use of HEVC with Feedback Messages.

This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.

 draft-ietf-payload-rtp-h265-15 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7798 RFC7799 Active and Passive Metrics and Methods (with Hybrid Types In-Between) A. Morton May 2016 ASCII 33717 14 IP Performance Measurements Testing Network Characterization

This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.

 draft-ietf-ippm-active-passive-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7799 RFC7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) M. Jones J. Bradley H. Tschofenig April 2016 ASCII 33625 15 JSON Web Token JWT Proof-of-Possession Holder-of-Key

This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.

 draft-ietf-oauth-proof-of-possession-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7800 RFC7801 GOST R 34.12-2015: Block Cipher "Kuznyechik" V. Dolmatov Editor March 2016 ASCII 25039 14 Kuznyechik Block Cipher

This document is intended to be a source of information about the Russian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (called GOST algorithms).

 draft-dolmatov-kuznyechik-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7801 10.17487/RFC7801 RFC7802 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism S. Emery N. Williams March 2016 ASCII 14118 8

This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.

This document obsoletes RFC 4402 and reclassifies that document as Historic. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations.

 draft-ietf-kitten-rfc4402bis-02 RFC4402 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7802 RFC7803 Changing the Registration Policy for the NETCONF Capability URNs Registry B. Leiba February 2016 ASCII 5133 3

The registration policy for the "Network Configuration Protocol (NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to Standards Track RFCs.

 draft-leiba-netmod-regpolicy-update-02 RFC6241 BCP0203 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7803 RFC7804 Salted Challenge Response HTTP Authentication Mechanism A. Melnikov March 2016 ASCII 39440 18 HTTPAUTH HTTP SASL SCRAM GS2 GSSAPI GSS-API

This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.

 draft-ietf-httpauth-scram-auth-15 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC7804 RFC7805 Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status A. Zimmermann W. Eddy L. Eggert April 2016 ASCII 15754 8

This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013. Additionally, this document reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status.

 draft-ietf-tcpm-undeployed-03 RFC0675 RFC0721 RFC0761 RFC0813 RFC0816 RFC0879 RFC0896 RFC1078 RFC6013 RFC7414 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7805 RFC7806 On Queuing, Marking, and Dropping F. Baker R. Pan April 2016 ASCII 37818 16

This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.

 draft-ietf-aqm-fq-implementation-05 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC7806 RFC7807 Problem Details for HTTP APIs M. Nottingham E. Wilde March 2016 ASCII 31210 16 status HTTP error problem API JSON XML

This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.

 draft-ietf-appsawg-http-problem-03 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC7807 RFC7808 Time Zone Data Distribution Service M. Douglass C. Daboo March 2016 ASCII 113582 56 time zone calendaring scheduling

This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.

 draft-ietf-tzdist-service-11 PROPOSED STANDARD PROPOSED STANDARD IETF art tzdist 10.17487/RFC7808 RFC7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference C. Daboo March 2016 ASCII 28902 13 CalDAV calendaring iCalendar time zone

This document defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.

 draft-ietf-tzdist-caldav-timezone-ref-05 RFC4791 PROPOSED STANDARD PROPOSED STANDARD IETF art tzdist 10.17487/RFC7809 RFC7810 IS-IS Traffic Engineering (TE) Metric Extensions S. Previdi Editor S. Giacalone D. Ward J. Drake Q. Wu May 2016 ASCII 37563 18

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.

This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.

Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.

 draft-ietf-isis-te-metric-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7810 RFC7811 An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) G. Enyedi A. Csaszar A. Atlas C. Bowers A. Gopalan June 2016 ASCII 266847 118 MRT FRR LFA recovery failure routing

This document supports the solution put forth in "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)" (RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessary Maximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.

 draft-ietf-rtgwg-mrt-frr-algorithm-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7811 RFC7812 An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) A. Atlas C. Bowers G. Enyedi June 2016 ASCII 110616 44 MRT FRR LFA recovery failure routing

This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure.

 draft-ietf-rtgwg-mrt-frr-architecture-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7812 RFC7813 IS-IS Path Control and Reservation J. Farkas Editor N. Bragg P. Unbehagen G. Parsons P. Ashwood-Smith C. Bowers June 2016 ASCII 77823 33 IS-IS SPB

IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.

 draft-ietf-isis-pcr-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7813 RFC7814 Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution X. Xu C. Jacquenet R. Raszuk T. Boyes B. Fee March 2016 ASCII 37397 15 Data Center Interconnect Data Center Network Virtual Machine (VM) migration

This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers.

 draft-ietf-bess-virtual-subnet-07 INFORMATIONAL INFORMATIONAL IETF rtg bess 10.17487/RFC7814 RFC7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation T. Kivinen March 2016 ASCII 92959 41 IKE IPsec IoT Constrained

This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.

This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.

 draft-ietf-lwig-ikev2-minimal-05 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC7815 RFC7816 DNS Query Name Minimisation to Improve Privacy S. Bortzmeyer March 2016 ASCII 23941 11

This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.

 draft-ietf-dnsop-qname-minimisation-09 EXPERIMENTAL EXPERIMENTAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7816 10.17487/RFC7816 RFC7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols A. Melnikov March 2016 ASCII 29855 13 SMTP Submission IMAP POP ManageSieve

This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.

 draft-ietf-uta-email-tls-certs-09 RFC2595 RFC3207 RFC3501 RFC5804 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC7817 RFC7818 URN Namespace for MEF Documents M. Jethanandani March 2016 ASCII 8564 5

This document describes the Namespace Identifier (NID) "mef" for Uniform Resource Names (URNs) used to identify resources published by MEF Forum (https://www.mef.net). MEF specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the MEF Assigned Names and Numbers (MANN) registry.

 draft-mahesh-mef-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7818 RFC7819 Privacy Considerations for DHCP S. Jiang S. Krishnan T. Mrugalski April 2016 ASCII 32944 14 DHCP Privacy

DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues.

 draft-ietf-dhc-dhcp-privacy-05 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7819 RFC7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) T. Mizrahi March 2016 ASCII 30611 15 Checksum UDP IPPM timestamping

The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.

 draft-ietf-ippm-checksum-trailer-06 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC7820 RFC7821 UDP Checksum Complement in the Network Time Protocol (NTP) T. Mizrahi March 2016 ASCII 26007 14 NTP UDP Checksum timestamping

The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.

 draft-ietf-ntp-checksum-trailer-07 EXPERIMENTAL EXPERIMENTAL IETF int ntp 10.17487/RFC7821 RFC7822 Network Time Protocol Version 4 (NTPv4) Extension Fields T. Mizrahi D. Mayer March 2016 ASCII 15759 8 NTP extension field

The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).

 draft-ietf-ntp-extension-field-07 RFC5905 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC7822 RFC7823 Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions A. Atlas J. Drake S. Giacalone S. Previdi May 2016 ASCII 23256 10 Traffic Engineering Path Computation

In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.

 draft-ietf-teas-te-express-path-05 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC7823 RFC7824 Privacy Considerations for DHCPv6 S. Krishnan T. Mrugalski S. Jiang May 2016 ASCII 42561 18

DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users. It is intended to be an analysis of the present situation and does not propose any solutions.

 draft-ietf-dhc-dhcpv6-privacy-05 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7824 RFC7825 A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) J. Goldberg M. Westerlund T. Zeng December 2016 ASCII 81878 33 ICE Media Delivery RTP RTCP D-ICE AVP AVPF SAVP SAVPF setup.ice-d-m rtsp-ice-d-m SDP

This document defines a solution for Network Address Translation (NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.

 draft-ietf-mmusic-rtsp-nat-22 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7825 RFC7826 Real-Time Streaming Protocol Version 2.0 H. Schulzrinne A. Rao R. Lanphier M. Westerlund M. Stiemerling Editor December 2016 ASCII 746422 318 mmusic RTSP RTSP/2.0 real-time streaming protocol

This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.

RTSP is an application-layer protocol for the 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-rfc2326bis-40 RFC2326 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7826 RFC7827 The Role of the IRTF Chair L. Eggert March 2016 ASCII 16696 7

This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.

 draft-iab-irtf-chair-description-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7827 RFC7828 The edns-tcp-keepalive EDNS0 Option P. Wouters J. Abley S. Dickinson R. Bellis April 2016 ASCII 24282 11 long-lived dnssec DNS TCP/IP transport

DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.

This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.

 draft-ietf-dnsop-edns-tcp-keepalive-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7828 RFC7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol Y. Nishida P. Natarajan A. Caro P. Amer K. Nielsen April 2016 ASCII 53922 23 SCTP Failover multipath multihoming Potentially Failed

The Stream Control Transmission Protocol (SCTP) supports multihoming. However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed (SCTP-PF) destination state in SCTP Path Management.

This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960.

Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation.

The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver.

 draft-ietf-tsvwg-sctp-failover-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7829 RFC7830 The EDNS(0) Padding Option A. Mayrhofer May 2016 ASCII 9520 5 Domain Name System DNS EDNS EDNS0 Security Encryption Padding

This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.

 draft-ietf-dprive-edns0-padding-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC7830 RFC7831 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture J. Howlett S. Hartman H. Tschofenig J. Schaad May 2016 ASCII 114076 46 Federated Authentication AAA RADIUS Diameter GSS-API EAP SAML

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 access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few 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), the Generic Security Service Application Program Interface (GSS-API), 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-arch-13 INFORMATIONAL INFORMATIONAL IETF sec abfab 10.17487/RFC7831 RFC7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases R. Smith Editor May 2016 ASCII 33640 13 Federated Authentication AAA RADIUS Diameter GSS-API EAP SASL

Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web-based contexts. The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.

 draft-ietf-abfab-usecases-05 INFORMATIONAL INFORMATIONAL IETF sec abfab 10.17487/RFC7832 RFC7833 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML) J. Howlett S. Hartman A. Perez-Mendez Editor May 2016 ASCII 65341 32 ABFAB AAA EAP RADIUS SAML

This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging for Federated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, and Accounting (AAA) scenario, such as network access control.

 draft-ietf-abfab-aaa-saml-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7833 RFC7834 Locator/ID Separation Protocol (LISP) Impact D. Saucez L. Iannone A. Cabellos F. Coras April 2016 ASCII 43168 18

The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.

 draft-ietf-lisp-impact-05 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7834 RFC7835 Locator/ID Separation Protocol (LISP) Threat Analysis D. Saucez L. Iannone O. Bonaventure April 2016 ASCII 45107 19

This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).

 draft-ietf-lisp-threats-15 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7835 RFC7836 Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012 S. Smyshlyaev Editor E. Alekseev I. Oshkin V. Popov S. Leontiev V. Podobaev D. Belyavsky March 2016 ASCII 57463 32 HMAC PRF key agreement VKO key exchange key derivation KDF key tree elliptic curve Weierstrass twisted Edwards TLS IPsec IKE IKEv2

The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.

These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.

 draft-smyshlyaev-gost-usage-19 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7836 RFC7837 IPv6 Destination Option for Congestion Exposure (ConEx) S. Krishnan M. Kuehlewind B. Briscoe C. Ralli May 2016 ASCII 29708 13 Accountability Traffic Management Fairness Resource Sharing Congestion Control Quality of Service QoS Denial of Service

Congestion Exposure (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-destopt-12 EXPERIMENTAL EXPERIMENTAL IETF tsv conex 10.17487/RFC7837 RFC7838 HTTP Alternative Services M. Nottingham P. McManus J. Reschke April 2016 ASCII 42681 20 HTTP ALPN Alternative Services

This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.

 draft-ietf-httpbis-alt-svc-14 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7838 RFC7839 Access-Network-Identifier Option in DHCP S. Bhandari S. Gundavelli M. Grayson B. Volz J. Korhonen June 2016 ASCII 42942 20 Operator-Realm Access-Network-Identifier Access-Technology-Type Access-Point BSSID Operator-Identifier DHCPv4 DHCPv6 Local Mobility Anchor (LMA) Proxy Mobile IPv6 (PMIPv6) Service Set Identifier (SSID)

This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options.

 draft-ietf-dhc-access-network-identifier-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7839 RFC7840 A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol J. Winterbottom H. Tschofenig L. Liess May 2016 ASCII 30696 16 Emergency Call Routing Location HELD

For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function. Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations.

 draft-ietf-ecrit-held-routing-05 RFC5985 RFC6881 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC7840 RFC7841 RFC Streams, Headers, and Boilerplates J. Halpern Editor L. Daigle Editor O. Kolkman Editor May 2016 ASCII 27950 14

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.

 draft-iab-rfc5741bis-02 RFC5741 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7841 10.17487/RFC7841 RFC7842 Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool R. Sparks April 2016 ASCII 13316 7

The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014. This memo captures the requirements for a set of improvements that have been identified during its initial years of community use.

 draft-sparks-genarea-mailarch-improvements-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7842 RFC7843 Port Control Protocol (PCP) Third-Party ID Option A. Ripke R. Winter T. Dietz J. Quittek R. da Silva May 2016 ASCII 30488 14 PCP option third party ID

This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.

The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.

 draft-ietf-pcp-third-party-id-option-08 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7843 RFC7844 Anonymity Profiles for DHCP Clients C. Huitema T. Mrugalski S. Krishnan May 2016 ASCII 62026 26 DHCP DHCPv4 DHCPv6 pervasive monitoring fingerprinting privacy Anonymity MAC Address Randomization Privacy Surveillance

Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.

 draft-ietf-dhc-anonymity-profile-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7844 RFC7845 Ogg Encapsulation for the Opus Audio Codec T. Terriberry R. Lee R. Giles April 2016 ASCII 81168 35 container mapping

This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream.

 draft-ietf-codec-oggopus-14 RFC5334 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC7845 RFC7846 Peer-to-Peer Streaming Tracker Protocol (PPSTP) R. Cruz M. Nunes J. Xia R. Huang Editor J. Taveira D. Lingli May 2016 ASCII 120911 55 structured media peer swarms control live streaming video on demand

This document specifies the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content-streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.

 draft-ietf-ppsp-base-tracker-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ppsp 10.17487/RFC7846 RFC7847 Logical-Interface Support for IP Hosts with Multi-Access Support T. Melia Editor S. Gundavelli Editor May 2016 ASCII 35657 16 Logical-interface virtual-interface Logical interface

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. Logical-interface support is required on the mobile node attached to 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 the logical-interface construct and the specifics on how 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 conjunction with various mobility management features.

 draft-ietf-netext-logical-interface-support-14 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7847 RFC7848 Mark and Signed Mark Objects Mapping G. Lozano June 2016 ASCII 46443 24 Trademark Clearinghouse Signed Mark Data Signed Mark Mark SMD

Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).

One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.

This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.

 draft-ietf-eppext-tmch-smd-06 PROPOSED STANDARD PROPOSED STANDARD IETF art eppext 10.17487/RFC7848 RFC7849 An IPv6 Profile for 3GPP Mobile Devices D. Binet M. Boucadair A. Vizdal G. Chen N. Heatley R. Chandler D. Michaud D. Lopez W. Haeffner May 2016 ASCII 51725 22 IPv4 service continuity address shortage address depletion dual-stack IPv6-only IPv6 introduction IPv6 transition IPv6 migration cellular networks mobile networks PLMN and IPv6 configuration

This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" (RFC 7066).

Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.

 draft-ietf-v6ops-mobile-device-profile-24 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7849 10.17487/RFC7849 RFC7850 Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles S. Nandakumar April 2016 ASCII 15190 7

The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'.

 draft-ietf-mmusic-proto-iana-registration-06 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7850 RFC7851 Peer-to-Peer (P2P) Overlay Diagnostics H. Song X. Jiang R. Even D. Bryan Y. Sun May 2016 ASCII 70591 30 Real-time Applications and Infrastructure P2PSIP Working Group Diagnostics P2P P2PSIP

This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics. It defines extensions to the REsource LOcation And Discovery (RELOAD) base protocol 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.

 draft-ietf-p2psip-diagnostics-22 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC7851 RFC7852 Additional Data Related to an Emergency Call R. Gellens B. Rosen H. Tschofenig R. Marshall J. Winterbottom July 2016 ASCII 239135 113 Additional Call Data Emergency Services Call Information

When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.

The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.

 draft-ietf-ecrit-additional-data-38 RFC6443 RFC6881 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC7852 RFC7853 A URN Namespace for Globus S. Martin S. Tuecke B. McCollam M. Lidman May 2016 ASCII 11530 7

This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources.

 draft-martin-urn-globus-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7853 RFC7854 BGP Monitoring Protocol (BMP) J. Scudder Editor R. Fernando S. Stuart June 2016 ASCII 60953 27 IDR BGP GROW BMP

This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. 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-bmp-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=7854 10.17487/RFC7854 RFC7855 Source Packet Routing in Networking (SPRING) Problem Statement and Requirements S. Previdi Editor C. Filsfils Editor B. Decraene S. Litkowski M. Horneffer R. Shakir May 2016 ASCII 38006 19

The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).

This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.

 draft-ietf-spring-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC7855 RFC7856 Softwire Mesh Management Information Base (MIB) Y. Cui J. Dong P. Wu M. Xu A. Yla-Jaaski May 2016 ASCII 34767 18 Management Information Base MIB SMIv2 mesh

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 a softwire mesh.

 draft-ietf-softwire-mesh-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7856 RFC7857 Updates to Network Address Translation (NAT) Behavioral Requirements R. Penno S. Perreault M. Boucadair Editor S. Sivakumar K. Naito April 2016 ASCII 29255 14 address sharing IPv4 service continuity Carrier Grade NAT CGN LSN NAT traversal RFC4787 RFC5382 RFC5508 DS-Lite NAT64 Address depletion

This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44).

This document updates RFCs 4787, 5382, and 5508.

 draft-ietf-tsvwg-behave-requirements-update-08 RFC4787 RFC5382 RFC5508 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC7857 RFC7858 Specification for DNS over Transport Layer Security (TLS) Z. Hu L. Zhu J. Heidemann A. Mankin D. Wessels P. Hoffman May 2016 ASCII 42138 19 DNS encryption DNS privacy

This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.

This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.

 draft-ietf-dprive-dns-over-tls-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC7858 RFC7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols C. Dearlove May 2016 ASCII 36651 17 Mobile Ad hoc Networking (MANET) MANET TLV OLSRv2 integrity check value ICV ECCSI elliptic curve identity-based signature IBS identity-based encryption IBE

This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC 5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-Based Signature (IBS), defined according to the Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.

 draft-ietf-manet-ibs-05 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7859 RFC7860 HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 J. Merkle Editor M. Lochter April 2016 ASCII 29329 14 SNMP USM HMAC SHA-2

This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified.

 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05 RFC7630 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7860 RFC7861 Remote Procedure Call (RPC) Security Version 3 A. Adamson N. Williams November 2016 ASCII 53813 26 RPCSEC_GSS ONC RPC GSS GSS-API NFS authentication privacy confidentiality encryption mechanism context

This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings. This document updates RFC 5403.

 draft-ietf-nfsv4-rpcsec-gssv3-17 RFC5403 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7861 RFC7862 Network File System (NFS) Version 4 Minor Version 2 Protocol T. Haynes November 2016 ASCII 237870 104 NFSv4.2 pNFS Server-Side Copy Server-Side Clone Labeled NFS

This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O) Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.

 draft-ietf-nfsv4-minorversion2-41 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7862 RFC7863 Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description T. Haynes November 2016 ASCII 144687 87 NFSv4.2 XDR

This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.

 draft-ietf-nfsv4-minorversion2-dot-x-41 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7863 RFC7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility CJ. Bernardos Editor May 2016 ASCII 44225 19 flow mobility NB-IFOM PMIPv6 FMI FMA

Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.

This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.

 draft-ietf-netext-pmipv6-flowmob-18 RFC5213 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7864 RFC7865 Session Initiation Protocol (SIP) Recording Metadata R. Ravindranath P. Ravindran P. Kyzivat May 2016 ASCII 67100 34

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The 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 the Session Recording Server (SRS) and the recording metadata format.

 draft-ietf-siprec-metadata-22 PROPOSED STANDARD PROPOSED STANDARD IETF art siprec 10.17487/RFC7865 RFC7866 Session Recording Protocol L. Portman H. Lum Editor C. Eckel A. Johnston A. Hutton May 2016 ASCII 104535 45 siprec

This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport 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. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document.

 draft-ietf-siprec-protocol-18 PROPOSED STANDARD PROPOSED STANDARD IETF art siprec 10.17487/RFC7866 RFC7867 RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications R. Huang July 2016 ASCII 34297 16

This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.

 draft-ietf-xrblock-rtcp-xr-video-lc-06 PROPOSED STANDARD PROPOSED STANDARD IETF art xrblock 10.17487/RFC7867 RFC7868 Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) D. Savage J. Ng S. Moore D. Slice P. Paluch R. White May 2016 ASCII 179677 80

This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations" (Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International.

 draft-savage-eigrp-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7868 RFC7869 The "vnc" URI Scheme D. Warden I. Iordanov May 2016 ASCII 53002 25 RFB Remote Framebuffer Virtual Network Computing

Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier (URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts.

 draft-warden-appsawg-vnc-scheme-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7869 RFC7870 Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs) Y. Fu S. Jiang J. Dong Y. Chen June 2016 ASCII 53247 27 IPv6

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 Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).

 draft-ietf-softwire-dslite-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7870 RFC7871 Client Subnet in DNS Queries C. Contavalli W. van der Gaast D. Lawrence W. Kumari May 2016 ASCII 67651 30 edns-client-subnet ECS DNS geolocation DNS load-balancing EDNS EDNS0 geolocation privacy

This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.

 draft-ietf-dnsop-edns-client-subnet-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7871 10.17487/RFC7871 RFC7872 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World F. Gont J. Linkova T. Chown W. Liu June 2016 ASCII 30924 15 packet drops

This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.

 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=7872 10.17487/RFC7872 RFC7873 Domain Name System (DNS) Cookies D. Eastlake 3rd M. Andrews May 2016 ASCII 55356 25 denial of service forgery cache poisoning off-path

DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)

 draft-ietf-dnsop-cookies-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7873 RFC7874 WebRTC Audio Codec and Processing Requirements JM. Valin C. Bran May 2016 ASCII 16160 7

This document outlines the audio codec and processing requirements for WebRTC endpoints.

 draft-ietf-rtcweb-audio-11 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7874 RFC7875 Additional WebRTC Audio Codecs for Interoperability S. Proust Editor May 2016 ASCII 26626 12 WebRTC audio codec G.722 AMR AMR-WB

To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser.

This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.

 draft-ietf-rtcweb-audio-codecs-for-interop-06 INFORMATIONAL INFORMATIONAL IETF art rtcweb 10.17487/RFC7875 RFC7876 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks S. Bryant S. Sivabalan S. Soni July 2016 ASCII 21092 10 MPLS

RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.

 draft-ietf-mpls-rfc6374-udp-return-path-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7876 RFC7877 Session Peering Provisioning Framework (SPPF) K. Cartwright V. Bhatia S. Ali D. Schwartz August 2016 ASCII 121553 57 SPPP SIP Peering SED Provisioning

This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider (SSP) data stores. The framework is called the "Session Peering Provisioning Framework" (SPPF). The provisioned data is typically used by network elements for session establishment.

 draft-ietf-drinks-spp-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF art drinks 10.17487/RFC7877 RFC7878 Session Peering Provisioning (SPP) Protocol over SOAP K. Cartwright V. Bhatia J-F. Mule A. Mayrhofer August 2016 ASCII 145284 83 SPPP SIP Peering SED Provisioning

The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider data stores. To utilize this framework, one needs a substrate protocol. Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an \%SPPF- based protocol.

 draft-ietf-drinks-spp-protocol-over-soap-09 PROPOSED STANDARD PROPOSED STANDARD IETF art drinks 10.17487/RFC7878 RFC7879 DTLS-SRTP Handling in SIP Back-to-Back User Agents R. Ravindranath T. Reddy G. Salgueiro V. Pascual P. Ravindran May 2016 ASCII 29648 13 Session Initiation Protocol B2BUA Secure Real-time Transport Datagram Transport Layer Security

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.

 draft-ietf-straw-b2bua-dtls-srtp-12 PROPOSED STANDARD PROPOSED STANDARD IETF art straw 10.17487/RFC7879 RFC7880 Seamless Bidirectional Forwarding Detection (S-BFD) C. Pignataro D. Ward N. Akiya M. Bhatia S. Pallagatti July 2016 ASCII 45987 24 BFD seamless BFD negotiation free segment routing IP

This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.

This document updates RFC 5880.

 draft-ietf-bfd-seamless-base-11 RFC5880 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7880 RFC7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS C. Pignataro D. Ward N. Akiya July 2016 ASCII 16352 8 BFD seamless BFD negotiation free label verification segment routing IP

This document defines procedures for using Seamless Bidirectional Forwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments.

 draft-ietf-bfd-seamless-ip-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7881 RFC7882 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases S. Aldrin C. Pignataro G. Mirsky N. Kumar July 2016 ASCII 35774 15 BFD seamless BFD negotiation free label verification segment routing IP

This document describes various use cases for Seamless Bidirectional Forwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.

These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits of S-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.

 draft-ietf-bfd-seamless-use-case-08 INFORMATIONAL INFORMATIONAL IETF rtg bfd 10.17487/RFC7882 RFC7883 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS L. Ginsberg N. Akiya M. Chen July 2016 ASCII 9331 5

This document defines a means of advertising one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators using the IS-IS Router CAPABILITY TLV.

 draft-ietf-isis-sbfd-discriminator-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7883 RFC7884 OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators C. Pignataro M. Bhatia S. Aldrin T. Ranganath July 2016 ASCII 13612 7 BFD seamless BFD negotiation free label verification segment routing IP

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 and OSPFv3.

 draft-ietf-ospf-sbfd-discriminator-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7884 RFC7885 Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) V. Govindan C. Pignataro July 2016 ASCII 22500 11 RFC5885 L2TPv3 VCCV S-BFD

This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV).

This document updates RFC 5885 by extending the CV Type values and the capability selection.

 draft-ietf-pals-seamless-vccv-03 RFC5885 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7885 RFC7886 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3) V. Govindan C. Pignataro July 2016 ASCII 10878 6 S-BFD

This document defines a new Attribute-Value Pair (AVP) that allows L2TP Control Connection Endpoints (LCCEs) to advertise one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3).

 draft-ietf-l2tpext-sbfd-discriminator-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2tpext 10.17487/RFC7886 RFC7887 Hierarchical Join/Prune Attributes S. Venaas J. Arango I. Kouvelas June 2016 ASCII 17207 8 multicast pim

This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIM Join/Prune message. This document updates RFC 5384 by renaming the encoding type registry specified there.

 draft-ietf-pim-hierarchicaljoinattr-08 RFC5384 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC7887 RFC7888 IMAP4 Non-synchronizing Literals A. Melnikov Editor May 2016 ASCII 17375 9 IMAP LITERAL+ LITERAL- APPENDLIMIT

The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.

This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.

This document obsoletes RFC 2088.

 draft-ietf-imapapnd-rfc2088bis-04 RFC2088 PROPOSED STANDARD PROPOSED STANDARD IETF art imapapnd 10.17487/RFC7888 RFC7889 The IMAP APPENDLIMIT Extension J. SrimushnamBoovaraghamoorthy N. Bisht May 2016 ASCII 13801 7

This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large.

 draft-ietf-imapapnd-appendlimit-extension-10 PROPOSED STANDARD PROPOSED STANDARD IETF art imapapnd 10.17487/RFC7889 RFC7890 Concepts and Terminology for Peer-to-Peer SIP (P2PSIP) D. Bryan P. Matthews E. Shim D. Willis S. Dawkins June 2016 ASCII 45276 19 Distributed Database P2PSIP SIP Server-less DHT

This document defines concepts and terminology for using the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and the SIP usage document defined by the working group.

 draft-ietf-p2psip-concepts-09 INFORMATIONAL INFORMATIONAL IETF art p2psip 10.17487/RFC7890 RFC7891 Explicit Reverse Path Forwarding (RPF) Vector J. Asghar IJ. Wijnands Editor S. Krishnaswamy A. Karan V. Arya June 2016 ASCII 19067 9 Path diversity MoFRR Maximally redundant paths

The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.

This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.

 draft-ietf-pim-explicit-rpf-vector-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC7891 RFC7892 IANA Allocation Procedures for the GMPLS OTN Signal Type Registry Z. Ali A. Bonfanti M. Hartley F. Zhang May 2016 ASCII 7019 4

IANA defined the "OTN Signal Type" subregistry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry in RFC 7139. This document updates the "OTN Signal Type" subregistry to allow registration via Specification Required.

 draft-ietf-ccamp-otn-signal-type-subregistry-05 RFC7139 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7892 RFC7893 Pseudowire Congestion Considerations Y(J) Stein D. Black B. Briscoe June 2016 ASCII 54380 27 PDF 345714 pseudowire congestion TCP friendliness

Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound. Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.

 draft-ietf-pals-congcons-02 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC7893 RFC7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport M. Pritikin C. Wallace June 2016 ASCII 19712 10 Enrollment over Secure Transport

This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol. These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in "PKCS #9: Selected Object Classes and Attribute Types Version 2.0" (RFC 2985). Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity.

 draft-wallace-est-alt-challenge-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7894 RFC7895 YANG Module Library A. Bierman M. Bjorklund K. Watsen June 2016 ASCII 24164 13 NETCONF RESTCONF

This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.

 draft-ietf-netconf-yang-library-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC7895 RFC7896 Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) D. Dhody June 2016 ASCII 9966 5 PCEP PCE IRO

The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.

This document updates RFC 5440 regarding the IRO specification.

 draft-ietf-pce-iro-update-07 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7896 RFC7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) D. Dhody U. Palle R. Casellas June 2016 ASCII 71770 35 PCEP PCE domain subobjects

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. 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 Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers.

 draft-ietf-pce-pcep-domain-sequence-12 EXPERIMENTAL EXPERIMENTAL IETF rtg pce 10.17487/RFC7897 RFC7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) D. Dhody U. Palle V. Kondreddy R. Casellas June 2016 ASCII 34962 18 RSVP-TE domain subobjects

The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.

This document specifies new subobjects to include or exclude Autonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.

 draft-ietf-teas-rsvp-te-domain-subobjects-05 EXPERIMENTAL EXPERIMENTAL IETF rtg teas 10.17487/RFC7898 RFC7899 Multicast VPN State Damping T. Morin Editor S. Litkowski K. Patel Z. Zhang R. Kebler J. Haas June 2016 ASCII 41294 18 dampening multicast vpn damping bgp pim

This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast.

 draft-ietf-bess-multicast-damping-06 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7899 RFC7900 Extranet Multicast in BGP/IP MPLS VPNs Y. Rekhter Editor E. Rosen Editor R. Aggarwal Y. Cai T. Morin June 2016 ASCII 155704 65 Multicast

Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.

 draft-ietf-bess-mvpn-extranet-07 RFC6513 RFC6514 RFC6625 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7900 RFC7901 CHAIN Query Requests in DNS P. Wouters June 2016 ASCII 35252 16 DNSSEC EDNS0 latency

This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.

 draft-ietf-dnsop-edns-chain-query-07 EXPERIMENTAL EXPERIMENTAL IETF ops dnsop 10.17487/RFC7901 RFC7902 Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags E. Rosen T. Morin June 2016 ASCII 14332 7

The BGP-based control procedures for Multicast Virtual Private Networks (MVPNs) make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI) Tunnel" attribute. This document updates RFC 6514.

 draft-ietf-bess-pta-flags-03 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7902 RFC7903 Windows Image Media Types S. Leonard September 2016 ASCII 24094 12

This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics.

 draft-seantek-windows-image-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7903 RFC7904 A SIP Usage for REsource LOcation And Discovery (RELOAD) C. Jennings B. Lowekamp E. Rescorla S. Baset H. Schulzrinne T. Schmidt Editor October 2016 ASCII 41978 20 p2psip p2p sip reload peer-to-peer session initiation distributed session management overlay network SIP registrar

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 and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.

 draft-ietf-p2psip-sip-21 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC7904 RFC7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) A. Langley W. Chang N. Mavrogiannopoulos J. Strombergson S. Josefsson June 2016 ASCII 15575 8 AEAD DTLS

This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

This document updates RFCs 5246 and 6347.

 draft-ietf-tls-chacha20-poly1305-04 RFC5246 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7905 RFC7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes P. Timmel R. Housley S. Turner June 2016 ASCII 145888 68

This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.

 draft-turner-km-attributes-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7906 RFC7908 Problem Definition and Classification of BGP Route Leaks K. Sriram D. Montgomery D. McPherson E. Osterweil B. Dickson June 2016 ASCII 25417 11 BGP BGPSEC Route Leak Route Leak Detection Route Leak Mitigation BGP Security

A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community.

 draft-ietf-grow-route-leak-problem-definition-06 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7908 RFC7909 Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures R. Kisteleki B. Haberman June 2016 ASCII 30493 14

This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) 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. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects.

 draft-ietf-sidr-rpsl-sig-12 RFC2622 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7909 RFC7910 Interoperability between the Virtual Router Redundancy Protocol and PIM W. Zhou June 2016 ASCII 14255 6

This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with the Virtual Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. The mechanism described in this document is based on Cisco IOS software implementation.

 draft-zhou-pim-vrrp-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7910 RFC7911 Advertisement of Multiple Paths in BGP D. Walton A. Retana E. Chen J. Scudder July 2016 ASCII 17537 8 border gateway protocol

This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.

 draft-ietf-idr-add-paths-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7911 RFC7912 Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure A. Melnikov June 2016 ASCII 24086 11 MMHS S/MIME MIXER email

This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures.

 draft-melnikov-mmhs-authorizing-users-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7912 RFC7913 P-Access-Network-Info ABNF Update C. Holmberg June 2016 ASCII 7418 4 Transport PANI ABNF P-Access-Network-Info 3GPP IMS

This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and 'utran-sai-3gpp'. The values are defined in the ABNF but are not included in the list.

 draft-holmberg-dispatch-pani-abnf-03 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7913 RFC7914 The scrypt Password-Based Key Derivation Function C. Percival S. Josefsson August 2016 ASCII 29222 16 PBKDF

This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.

 draft-josefsson-scrypt-kdf-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7914 RFC7915 IP/ICMP Translation Algorithm C. Bao X. Li F. Baker T. Anderson F. Gont June 2016 ASCII 75564 34 SIIT internet protocol control message IPv4 IPv6 Stateless IP/ICMP Translation Algorithm RFC6145bis

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145.

 draft-bao-v6ops-rfc6145bis-07 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7915 10.17487/RFC7915 RFC7916 Operational Management of Loop-Free Alternates S. Litkowski Editor B. Decraene C. Filsfils K. Raza M. Horneffer P. Sarkar July 2016 ASCII 62072 31 IGP LFA policy FRR fast reroute network planning

Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.

This proposal is also applicable to remote-LFA solutions.

 draft-ietf-rtgwg-lfa-manageability-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7916 RFC7917 Advertising Node Administrative Tags in IS-IS P. Sarkar Editor H. Gredler S. Hegde S. Litkowski B. Decraene July 2016 ASCII 23344 11 IGP IS-IS Admin-Tag Traffic Engineering

This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS.

 draft-ietf-isis-node-admin-tag-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7917 RFC7918 Transport Layer Security (TLS) False Start A. Langley N. Modadugu B. Moeller August 2016 ASCII 23825 11

This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip.

 draft-ietf-tls-falsestart-02 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC7918 RFC7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) D. Gillmor August 2016 ASCII 61937 29 Diffie-Hellman Discrete Logarithm Finite Field Transport Layer Security TLS Negotiation

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.

This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).

 draft-ietf-tls-negotiated-ff-dhe-10 RFC2246 RFC4346 RFC4492 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7919 10.17487/RFC7919 RFC7920 Problem Statement for the Interface to the Routing System A. Atlas Editor T. Nadeau Editor D. Ward June 2016 ASCII 28441 12

Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.

This document proposes meeting this need via an Interface to the Routing System (I2RS).

 draft-ietf-i2rs-problem-statement-11 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7920 RFC7921 An Architecture for the Interface to the Routing System A. Atlas J. Halpern S. Hares D. Ward T. Nadeau June 2016 ASCII 100699 40

This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).

 draft-ietf-i2rs-architecture-15 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7921 RFC7922 Interface to the Routing System (I2RS) Traceability: Framework and Information Model J. Clarke G. Salgueiro C. Pignataro June 2016 ASCII 36070 17 I2RS I2RS Traceability I2RS Traceability

This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework. It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes.

 draft-ietf-i2rs-traceability-11 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7922 RFC7923 Requirements for Subscription to YANG Datastores E. Voit A. Clemm A. Gonzalez Prieto June 2016 ASCII 37630 18 pub/sub push updates

This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees.

 draft-ietf-i2rs-pub-sub-requirements-09 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7923 RFC7924 Transport Layer Security (TLS) Cached Information Extension S. Santesson H. Tschofenig July 2016 ASCII 35144 19 TLS Cached Information TLS Cached Info TLS Extension TLS Optimization

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 chain (i.e., the certificates of intermediate CAs up to the root CA).

This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.

 draft-ietf-tls-cached-info-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7924 RFC7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things H. Tschofenig Editor T. Fossati July 2016 ASCII 141911 61 Internet of Things Security TLS Profile DTLS Profile IoT Security DTLS over SMS

A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.

This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.

 draft-ietf-dice-profile-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec dice 10.17487/RFC7925 RFC7926 Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks A. Farrel Editor J. Drake N. Bitar G. Swallow D. Ceccarelli X. Zhang July 2016 ASCII 159905 67 Abstract link Abstract node Abstraction Abstraction layer Aggregation Virtual node Virtual link

In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.

In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.

This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.

 draft-ietf-teas-interconnected-te-info-exchange-07 BCP0206 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg teas 10.17487/RFC7926 RFC7927 Information-Centric Networking (ICN) Research Challenges D. Kutscher Editor S. Eum K. Pentikousis I. Psaras D. Corujo D. Saucez T. Schmidt M. Waehlisch July 2016 ASCII 97724 38 Information centric networking

This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-challenges-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7927 RFC7928 Characterization Guidelines for Active Queue Management (AQM) N. Kuhn Editor P. Natarajan Editor N. Khademi Editor D. Ros July 2016 ASCII 90255 37

Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing. This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.

 draft-ietf-aqm-eval-guidelines-13 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC7928 RFC7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP P. Wouters August 2016 ASCII 44695 20 opportunistic security encrypted email

OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.

 draft-ietf-dane-openpgpkey-12 EXPERIMENTAL EXPERIMENTAL IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=7929 10.17487/RFC7929 RFC7930 Larger Packets for RADIUS over TCP S. Hartman August 2016 ASCII 22676 10 ABFAB

The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.

 draft-ietf-radext-bigger-packets-07 RFC6613 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7930 RFC7931 NFSv4.0 Migration: Specification Update D. Noveck Editor P. Shivam C. Lever B. Baker July 2016 ASCII 133838 55

The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.

 draft-ietf-nfsv4-rfc3530-migration-update-08 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7931 10.17487/RFC7931 RFC7932 Brotli Compressed Data Format J. Alakuijala Z. Szabadka July 2016 ASCII 389979 128

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.

 draft-alakuijala-brotli-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7932 RFC7933 Adaptive Video Streaming over Information-Centric Networking (ICN) C. Westphal Editor S. Lederer D. Posch C. Timmerer A. Azgin W. Liu C. Mueller A. Detti D. Corujo J. Wang M. Montpetit N. Murray August 2016 ASCII 104192 40 ICN CCN NDN DASH adaptive video streaming scalable video streaming IPTV P2P DRM

This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.

 draft-irtf-icnrg-videostreaming-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7933 RFC7934 Host Address Availability Recommendations L. Colitti V. Cerf S. Cheshire D. Schinazi July 2016 ASCII 37124 15 IPv6 IPv4 SLAAC DHCPv6 Prefix Delegation NAT NAT64 464XLAT /64 Address Assignment Addressing

This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.

 draft-ietf-v6ops-host-addr-availability-07 BCP0204 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=7934 10.17487/RFC7934 RFC7935 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure G. Huston G. Michaelson Editor August 2016 ASCII 17952 9

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.

 draft-ietf-sidr-rfc6485bis-05 RFC6485 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7935 RFC7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry T. Hardie July 2016 ASCII 4873 3

This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455.

 draft-hardie-rfc6455-iana-clarification-03 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7936 RFC7937 Content Distribution Network Interconnection (CDNI) Logging Interface F. Le Faucheur Editor G. Bertrand Editor I. Oprescu Editor R. Peterkofsky August 2016 ASCII 139040 63 CDNI Logging CDN Interconnection

This memo specifies the Logging interface between a downstream Content Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.

 draft-ietf-cdni-logging-27 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC7937 RFC7938 Use of BGP for Routing in Large-Scale Data Centers P. Lapukhov A. Premji J. Mitchell Editor August 2016 ASCII 89682 35 BGP ECMP Clos

Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.

 draft-ietf-rtgwg-bgp-routing-large-dc-11 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7938 RFC7939 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres T. Clausen August 2016 ASCII 140619 72 Network Management Management Information Base MIB SMIv2 Routing Neighbor Discovery MANET NHDP-MIB

This document replaces RFC 6779; it contains revisions and extensions to the original document. It 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 extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

 draft-ietf-manet-rfc6779bis-07 RFC6779 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7939 RFC7940 Representing Label Generation Rulesets Using XML K. Davies A. Freytag August 2016 ASCII 170416 82 IDN LGR IDN table variant table

This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.

 draft-ietf-lager-specification-13 PROPOSED STANDARD PROPOSED STANDARD IETF art lager 10.17487/RFC7940 RFC7941 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items M. Westerlund B. Burman R. Even M. Zanaty August 2016 ASCII 39887 17

Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.

 draft-ietf-avtext-sdes-hdr-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC7941 RFC7942 Improving Awareness of Running Code: The Implementation Status Section Y. Sheffer A. Farrel July 2016 ASCII 17273 8

This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

 draft-sheffer-rfc6982bis-03 RFC6982 BCP0205 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7942 RFC7943 A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) F. Gont W. Liu September 2016 ASCII 21161 10 security privacy resiliency attack scanning tracking

This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.

 draft-gont-dhcpv6-stable-privacy-addresses-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7943 RFC7944 Diameter Routing Message Priority S. Donovan August 2016 ASCII 41028 18 Diameter Overload

When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions.

 draft-ietf-dime-drmp-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7944 RFC7945 Information-Centric Networking: Evaluation and Security Considerations K. Pentikousis Editor B. Ohlman E. Davies S. Spirou G. Boggia September 2016 ASCII 95970 38

This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.

 draft-irtf-icnrg-evaluation-methodology-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7945 RFC7946 The GeoJSON Format H. Butler M. Daly A. Doyle S. Gillies S. Hagen T. Schaub August 2016 ASCII 49143 28 JSON Geospatial JavaScript Object Notation

GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. GeoJSON uses a geographic coordinate reference system, World Geodetic System 1984, and units of decimal degrees.

 draft-ietf-geojson-04 PROPOSED STANDARD PROPOSED STANDARD IETF art geojson 10.17487/RFC7946 RFC7947 Internet Exchange BGP Route Server E. Jasinska N. Hilliard R. Raszuk N. Bakker September 2016 ASCII 26589 12 IDR

This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) 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 IXPs, to facilitate simplified interconnection among multiple Internet routers.

 draft-ietf-idr-ix-bgp-route-server-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7947 RFC7948 Internet Exchange BGP Route Server Operations N. Hilliard E. Jasinska R. Raszuk N. Bakker September 2016 ASCII 36787 15 GROW

The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP (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 associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information.

This document describes operational considerations for multilateral interconnections at IXPs.

 draft-ietf-grow-ix-bgp-route-server-operations-05 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7948 RFC7949 OSPFv3 over IPv4 for IPv6 Transition I. Chen A. Lindem R. Atkinson August 2016 ASCII 25554 11 IPv4 transport OSPFv3 transition

This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.

 draft-ietf-ospf-transition-to-ospfv3-12 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7949 RFC7950 The YANG 1.1 Data Modeling Language M. Bjorklund Editor August 2016 ASCII 393155 217 NETCONF XML data modeling

YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).

 draft-ietf-netmod-rfc6020bis-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7950 10.17487/RFC7950 RFC7951 JSON Encoding of Data Modeled with YANG L. Lhotka August 2016 ASCII 32316 20 I-JSON RESTCONF

This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.

 draft-ietf-netmod-yang-json-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7951 RFC7952 Defining and Using Metadata with YANG L. Lhotka August 2016 ASCII 35394 21 metadata annotations YANG extension

This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes.

 draft-ietf-netmod-yang-metadata-07 RFC6110 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7952 RFC7953 Calendar Availability C. Daboo M. Douglass August 2016 ASCII 47971 24 availability calendaring free-busy iCalendar CalDAV

This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.

This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.

 draft-ietf-calext-availability-04 RFC4791 RFC5545 RFC6638 PROPOSED STANDARD PROPOSED STANDARD IETF art calext 10.17487/RFC7953 RFC7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block L. Iannone D. Lewis D. Meyer V. Fuller September 2016 ASCII 26522 12

This document directs IANA to allocate a /32 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 Endpoint Identifier (EID) addressing space.

 draft-ietf-lisp-eid-block-13 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC7954 RFC7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block L. Iannone R. Jorgensen D. Conrad G. Huston September 2016 ASCII 19607 10

This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.

 draft-ietf-lisp-eid-block-mgmnt-07 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7955 RFC7956 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway W. Hao Y. Li A. Qu M. Durrani P. Sivamurugan September 2016 ASCII 62104 28 tenant data center

The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter-subnet traffic forwarding but has the following issues:

1. Sub-optimum forwarding paths for inter-subnet traffic.

2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.

3. A traffic bottleneck at the gateway.

This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.

 draft-ietf-trill-irb-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7956 RFC7957 DISPATCH-Style Working Groups and the SIP Change Process B. Campbell Editor A. Cooper B. Leiba August 2016 ASCII 12097 6 dispatch RAI ART sip-change

RFC 5727 defined several processes for the former Real-time Applications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups.

 draft-campbell-art-rfc5727-update-03 RFC5727 BCP0067 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7957 RFC7958 DNSSEC Trust Anchor Publication for the Root Zone J. Abley J. Schlyter G. Bailey P. Hoffman August 2016 ASCII 26072 14 DNS ICANN IANA KSK

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 the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.

 draft-jabley-dnssec-trust-anchor-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7958 RFC7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP) C. Bormann Z. Shelby Editor August 2016 ASCII 87515 37 CoAP Constrained Application Protocol REST Internet of Things IoT Smart Object Embedded Internet Constrained Node

The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.

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. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.

A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.

 draft-ietf-core-block-21 RFC7252 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC7959 RFC7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows F. Martin Editor E. Lear Editor T. Draegen. Ed. E. Zwicky Editor K. Andersen Editor September 2016 ASCII 58739 27 DMARC SMTP DKIM SPF

Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients. Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them.

 draft-ietf-dmarc-interoperability-18 INFORMATIONAL INFORMATIONAL IETF art dmarc 10.17487/RFC7960 RFC7961 Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV D. Eastlake 3rd L. Yizhou August 2016 ASCII 50012 24 reachability AFN template

This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses. Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses.

 draft-ietf-trill-ia-appsubtlv-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7961 RFC7962 Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures J. Saldana Editor A. Arcia-Moret B. Braem E. Pietrosemoli A. Sathiaseelan M. Zennaro August 2016 ASCII 97574 43 alternative network deployments community networks user-centric networks Wireless Internet Service Providers mainstream network gaia global access to the Internet for all

This document presents a taxonomy of a set of "Alternative Network Deployments" that emerged in the last decade with the aim of bringing Internet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives. They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.

The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.

The classification considers models such as Community Networks, Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives.

 draft-irtf-gaia-alternative-network-deployments-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7962 RFC7963 RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) Z. Ali A. Bonfanti M. Hartley F. Zhang August 2016 ASCII 8665 5 GMPLS

RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2). This document defines new Signal Types for these additional containers.

 draft-ietf-ccamp-additional-signal-type-g709v3-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7963 RFC7964 Solutions for BGP Persistent Route Oscillation D. Walton A. Retana E. Chen J. Scudder September 2016 ASCII 19774 9 BGP churn oscillation

Routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies. This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.

 draft-ietf-idr-route-oscillation-stop-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7964 RFC7965 LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels M. Chen W. Cao A. Takacs P. Pan August 2016 ASCII 38557 16

Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs.

 draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7965 RFC7966 Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements H. Tschofenig J. Korhonen Editor G. Zorn K. Pillay September 2016 ASCII 22186 11 Diameter End-to-End Security

This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).

 draft-ietf-dime-e2e-sec-req-05 INFORMATIONAL INFORMATIONAL IETF ops dime 10.17487/RFC7966 RFC7967 Constrained Application Protocol (CoAP) Option for No Server Response A. Bhattacharyya S. Bandyopadhyay A. Pal T. Bose August 2016 ASCII 40314 18 No-Response

There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.

This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.

 draft-tcs-coap-no-response-option-17 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7967 RFC7968 Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data Y. Li D. Eastlake 3rd W. Hao H. Chen S. Chatterjee August 2016 ASCII 47260 22 VLAN fine-grained label multicast

TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast-path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.

This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.

 draft-ietf-trill-tree-selection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7968 RFC7969 Customizing DHCP Configuration on the Basis of Network Topology T. Lemon T. Mrugalski October 2016 ASCII 46674 20 dhcpv4 dhcpv6 relay-agents (relay agents) multiple subnets subnets links prefixes

DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.

 draft-ietf-dhc-topo-conf-09 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7969 RFC7970 The Incident Object Description Exchange Format Version 2 R. Danyliw November 2016 ASCII 331061 172 incident data format incident report cyber threat indicators computer security incident computer security incident response team CSIRT CERT security data sharing Computer Network Defense Service Provider CNDSP information sharing automated information sharing cyber indicators

The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletes RFCs 5070 and 6685.

 draft-ietf-mile-rfc5070-bis-26 RFC5070 RFC6685 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC7970 RFC7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations M. Stiemerling S. Kiesel M. Scharf H. Seidel S. Previdi October 2016 ASCII 188372 77

Many Internet applications are used to access resources such as pieces of information or server processes that 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 that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.

 draft-ietf-alto-deployments-16 INFORMATIONAL INFORMATIONAL IETF tsv alto 10.17487/RFC7971 RFC7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux September 2016 ASCII 17603 10 EIDR Entertainment Identifier Registry and URN

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.

This document obsoletes RFC 7302.

 draft-pal-eidr-urn-2016-03 RFC7302 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7972 RFC7973 Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation R. Droms P. Duffy November 2016 ASCII 8208 5 6lowpan header compression ethertype

When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment.

 draft-ietf-6lo-ethertype-request-01 INFORMATIONAL INFORMATIONAL IETF int 6lo 10.17487/RFC7973 RFC7974 An Experimental TCP Option for Host Identification B. Williams M. Boucadair D. Wing October 2016 ASCII 48381 20 Policy enforcement Address sharing NAT Host reveal Host-ID

Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed. This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.

 draft-williams-exp-tcp-host-id-opt-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7974 RFC7975 Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection B. Niven-Jenkins Editor R. van Brandenburg Editor October 2016 ASCII 75830 35 HTTP DNS

The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.

 draft-ietf-cdni-redirection-20 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC7975 RFC7976 Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses C. Holmberg N. Biondic G. Salgueiro September 2016 ASCII 17246 8 P- 3GPP IMS

The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.

This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.

 draft-holmberg-dispatch-rfc7315-updates-09 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7976 RFC7977 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) P. Dunkley G. Llewellyn V. Pascual G. Salgueiro R. Ravindranath September 2016 ASCII 52078 28 MSRP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFCs 4975 and 4976.

 draft-pd-dispatch-msrp-websocket-15 RFC4975 RFC4976 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7977 RFC7978 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension D. Eastlake 3rd M. Umair Y. Li September 2016 ASCII 54617 25 tunnel encapsulation

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link. This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178.

 draft-ietf-trill-channel-tunnel-11 RFC7178 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7978 RFC7979 Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries E. Lear Editor R. Housley Editor August 2016 ASCII 81587 37

The U.S. National Telecommunications and Information Administration (NTIA) solicited a request from the Internet Corporation for Assigned Names and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions. After broad consultations, ICANN in turn created the IANA Stewardship Transition Coordination Group. That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. A reference to that response may be found in the introduction, and additional correspondence is included in the Appendix.

 draft-ietf-ianaplan-icg-response-10 INFORMATIONAL INFORMATIONAL IETF gen ianaplan 10.17487/RFC7979 RFC7980 A Framework for Defining Network Complexity M. Behringer A. Retana R. White G. Huston October 2016 ASCII 56510 24 Complicated Fragile Self-organization Trade-off Technical Debt Dependency

Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.

This document summarizes the work of the IRTF's Network Complexity Research Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.

 draft-behringer-ncrg-complexity-framework-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7980 RFC7981 IS-IS Extensions for Advertising Router Information L. Ginsberg S. Previdi M. Chen October 2016 ASCII 20235 10

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletes RFC 4971.

 draft-ietf-isis-rfc4971bis-04 RFC4971 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7981 RFC7982 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) P. Martinsen T. Reddy D. Wing V. Singh September 2016 ASCII 19893 10

A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.

This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages.

 draft-ietf-tram-stun-path-data-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC7982 RFC7983 Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) M. Petit-Huguenin G. Salgueiro September 2016 ASCII 24894 13 TLS STUN TURN TLS TURN Channel Numbers STUN Methods RFC 5764 SRTP-DTLS ZRTP

This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document.

This document updates RFC 5764.

 draft-ietf-avtcore-rfc5764-mux-fixes-11 RFC5764 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC7983 RFC7984 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network O. Johansson G. Salgueiro V. Gurbani D. Worley Editor September 2016 ASCII 21246 10 A record address family preference AAAA record DNS getaddrinfo Happy Eyeballs IPv6 address selection SIP SRV record dual-stack IPv4 IPv6

RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP.

 draft-ietf-sipcore-dns-dual-stack-08 RFC3263 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7984 RFC7985 Security Threats to Simplified Multicast Forwarding (SMF) J. Yi T. Clausen U. Herberg November 2016 ASCII 35822 15 MANET

This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.

In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).

 draft-ietf-manet-smf-sec-threats-06 RFC7186 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC7985 RFC7986 New Properties for iCalendar C. Daboo October 2016 ASCII 45686 23 alarms calendaring iCalendar

This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.

 draft-ietf-calext-extensions-05 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF art calext 10.17487/RFC7986 RFC7987 IS-IS Minimum Remaining Lifetime L. Ginsberg P. Wells B. Decraene T. Przygienda H. Gredler October 2016 ASCII 18295 9

Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected. In certain scenarios, this may cause or exacerbate flooding storms. It is also a possible denial-of-service attack vector. This document defines a backwards-compatible solution to this problem.

 draft-ietf-isis-remaining-lifetime-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7987 RFC7988 Ingress Replication Tunnels in Multicast VPN E. Rosen Editor K. Subramanian Z. Zhang October 2016 ASCII 55979 23

RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.

 draft-ietf-bess-ir-05 RFC6513 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7988 RFC7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks P. Jones G. Salgueiro C. Pearce P. Giralt October 2016 ASCII 103241 45 SIP Session Initiation Protocol troubleshooting Session-ID session identifier H460.27 remote parameter UUID

This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary 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. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP).

This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.

This document obsoletes RFC 7329.

 draft-ietf-insipid-session-id-27 RFC7329 PROPOSED STANDARD PROPOSED STANDARD IETF art insipid 10.17487/RFC7989 RFC7990 RFC Format Framework H. Flanagan December 2016 ASCII 34192 16 Format xml2rfcv3 v3

In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.

 draft-iab-rfc-framework-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7990 RFC7991 The "xml2rfc" Version 3 Vocabulary P. Hoffman December 2016 ASCII 221812 151 v3 xml2rfcv3 format

This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749.

 draft-iab-xml2rfc-04 RFC7749 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7991 10.17487/RFC7991 RFC7992 HTML Format for RFCs J. Hildebrand Editor P. Hoffman December 2016 ASCII 76975 43 html css v3 xml2rfcv3 format

In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft.

 draft-iab-html-rfc-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7992 RFC7993 Cascading Style Sheets (CSS) Requirements for RFCs H. Flanagan December 2016 ASCII 18990 14 v3 xml2rfcv3 format html

The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992).

 draft-iab-rfc-css-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7993 RFC7994 Requirements for Plain-Text RFCs H. Flanagan December 2016 ASCII 15393 8 RFC ASCII format plain-text plain text xml2rfcv3 v3

In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.

 draft-iab-rfc-plaintext-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7994 RFC7995 PDF Format for RFCs T. Hansen Editor L. Masinter M. Hardy December 2016 ASCII 44720 22 Requests for Comment xml2rfcv3 v3 format

This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.

 draft-iab-rfc-use-of-pdf-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7995 RFC7996 SVG Drawings for RFCs: SVG 1.2 RFC N. Brownlee December 2016 ASCII 102678 53 RFC v3 xml2rfcv3 format

This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.

 draft-iab-svg-rfc-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7996 RFC7997 The Use of Non-ASCII Characters in RFCs H. Flanagan Editor December 2016 ASCII 27637 15 PDF 96351 RFC Series UTF-8 ASCII format non-ASCII v3 xml2rfcv3

In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.

This document updates RFC 7322. Please view this document in PDF form to see the full text.

 draft-iab-rfc-nonascii-02 RFC7322 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7997 RFC7998 "xml2rfc" Version 3 Preparation Tool Description P. Hoffman J. Hildebrand December 2016 ASCII 38779 18 xml2rfcv3 v3 format

This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.

 draft-iab-rfcv3-preptool-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7998 RFC7999 BLACKHOLE Community T. King C. Dietzel J. Snijders G. Doering G. Hankins October 2016 ASCII 16794 9 well-known well known RTBH Remotely Triggered Blackholing

This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named "BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.

 draft-ietf-grow-blackholing-03 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7999 RFC8000 Requirements for NFSv4 Multi-Domain Namespace Deployment A. Adamson N. Williams November 2016 ASCII 39064 17 multi-domain multi-domain-capable file system Federated File System FedFS

This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS for user authentication. In most instances, the server must also support identity-mapping services.

 draft-ietf-nfsv4-multi-domain-fs-reqs-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8000 RFC8001 RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information F. Zhang Editor O. Gonzalez de Dios Editor C. Margaria M. Hartley Z. Ali January 2017 ASCII 34732 16

This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).

 draft-ietf-teas-rsvp-te-srlg-collect-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8001 RFC8002 Host Identity Protocol Certificates T. Heer S. Varjonen October 2016 ASCII 26613 13 Hip Certificate Extension

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3).

The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 7401 and obsoletes RFC 6253.

 draft-ietf-hip-rfc6253-bis-09 RFC6253 RFC7401 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8002 RFC8003 Host Identity Protocol (HIP) Registration Extension J. Laganier L. Eggert October 2016 ASCII 34717 16 HIP Host Identity Protocol Host Identity Payload Registration register

This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203.

 draft-ietf-hip-rfc5203-bis-11 RFC5203 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8003 RFC8004 Host Identity Protocol (HIP) Rendezvous Extension J. Laganier L. Eggert October 2016 ASCII 30487 14 HIP Host Identity Protocol Host Identity Payload Rendezvous HIP nodes HIP rendezvous server

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204.

 draft-ietf-hip-rfc5204-bis-08 RFC5204 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8004 RFC8005 Host Identity Protocol (HIP) Domain Name System (DNS) Extension J. Laganier October 2016 ASCII 39146 18 HIP Host Identity Protocol Host Identity Payload DNS Domain Name System

This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205.

 draft-ietf-hip-rfc5205-bis-10 RFC5205 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8005 RFC8006 Content Delivery Network Interconnection (CDNI) Metadata B. Niven-Jenkins R. Murray M. Caulfield K. Ma December 2016 ASCII 126524 66 CDN cascaded CDN cascading CDNs content acquisition content delegation request delegation acquisition protocol delivery restriction delivery policy policy enforcement delivery protocol content expiration geo-fencing geofencing geo fencing geo-blocking geoblocking geo blocking footprint cache control

The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.

 draft-ietf-cdni-metadata-21 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC8006 RFC8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers R. Murray B. Niven-Jenkins December 2016 ASCII 90108 49 CDN pre-position invalidate purge

This document describes the part of the Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN.

 draft-ietf-cdni-control-triggers-15 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC8007 RFC8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics J. Seedorf J. Peterson S. Previdi R. van Brandenburg K. Ma December 2016 ASCII 61956 31 CDNI CDN Interconnect Request Routing

This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.

 draft-ietf-cdni-footprint-capabilities-semantics-20 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC8008 RFC8009 AES Encryption with HMAC-SHA2 for Kerberos 5 M. Jenkins M. Peck K. Burgin October 2016 ASCII 34935 19

This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity.

 draft-ietf-kitten-aes-cts-hmac-sha2-11 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC8009 RFC8010 Internet Printing Protocol/1.1: Encoding and Transport M. Sweet I. McDonald January 2017 ASCII 115605 51 IPP Printer PWG Printer Working Group

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called "application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/or HTTPS. The IPP data model and operation semantics are described in "Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).

 draft-sweet-rfc2910bis-10 RFC2910 RFC3382 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8010 RFC8011 Internet Printing Protocol/1.1: Model and Semantics M. Sweet I. McDonald January 2017 ASCII 535490 221 IPP Printer PWG Printer Working Group

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects, including Printers and Jobs. Jobs optionally support multiple Documents.

IPP semantics allow End Users and Operators to query Printer capabilities; submit Print Jobs; inquire about the status of Print Jobs and Printers; and cancel, hold, and release Print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers.

Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in "Internet Printing Protocol/1.1: Encoding and Transport" (RFC 8010).

This document obsoletes RFCs 2911, 3381, and 3382.

 draft-sweet-rfc2911bis-11 RFC2911 RFC3381 RFC3382 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8011 RFC8012 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) N. Akiya G. Swallow C. Pignataro A. Malis S. Aldrin November 2016 ASCII 49577 23 MPLS LSP Ping and Entropy

Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC 4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where Label Switching Routers (LSRs) apply different load-balancing techniques. One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g., IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based.

This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790.

 draft-ietf-mpls-entropy-lsp-ping-05 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8012 RFC8014 An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) D. Black J. Hudson L. Kreeger M. Lasserre T. Narten December 2016 ASCII 89975 35

This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.

 draft-ietf-nvo3-arch-08 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8014 RFC8015 RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics V. Singh C. Perkins A. Clark R. Huang November 2016 ASCII 29547 15 XRBLOCK

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications.

 draft-ietf-xrblock-independent-burst-gap-discard-03 PROPOSED STANDARD PROPOSED STANDARD IETF art xrblock 10.17487/RFC8015 RFC8016 Mobility with Traversal Using Relays around NAT (TURN) T. Reddy D. Wing P. Patil P. Martinsen November 2016 ASCII 29313 13 IP Address Mobility VoIP ICE STUN RTP TUNNEL

It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.

This document provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes.

 draft-ietf-tram-turn-mobility-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8016 RFC8017 PKCS #1: RSA Cryptography Specifications Version 2.2 K. Moriarty Editor B. Kaliski J. Jonsson A. Rusch November 2016 ASCII 154696 78 RSA public-key cryptosystem RSA signature scheme RSA public key RSA private key PKCS #1 v1.5 RSA-OAEP RSA-PSS Optimal Asymmetric Encryption Padding Probabilistic Signature Scheme

This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.

This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

This document also obsoletes RFC 3447.

 draft-moriarty-pkcs1-03 RFC3447 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8017 RFC8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks Y. Nir V. Smyslov November 2016 ASCII 78293 32 puzzle dos ddos bitcoin

This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task.

 draft-ietf-ipsecme-ddos-protection-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8019 RFC8020 NXDOMAIN: There Really Is Nothing Underneath S. Bortzmeyer S. Huque November 2016 ASCII 22301 10

This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.

 draft-ietf-dnsop-nxdomain-cut-05 RFC1034 RFC2308 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8020 RFC8021 Generation of IPv6 Atomic Fragments Considered Harmful F. Gont W. Liu T. Anderson January 2017 ASCII 25686 12 attack DoS Extension Headers

This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460).

 draft-ietf-6man-deprecate-atomfrag-generation-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC8021 RFC8022 A YANG Data Model for Routing Management L. Lhotka A. Lindem November 2016 ASCII 115083 64 configuration IPv6 router advertisements NETCONF RESTCONF

This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.

 draft-ietf-netmod-routing-cfg-25 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8022 RFC8023 Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions M. Thomas A. Mankin L. Zhang November 2016 ASCII 41899 17

This document provides context and a report on the workshop on "Root Causes and Mitigation of Name Collisions", which took place in London, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.

 draft-thomas-namecollisions-workshop-report-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8023 RFC8024 Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS Y. Jiang Editor Y. Luo E. Mallette Editor Y. Shen W. Cheng November 2016 ASCII 33671 16 PON Protection

Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it.

 draft-ietf-pals-mc-pon-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8024 RFC8025 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch P. Thubert Editor R. Cragie November 2016 ASCII 16342 8 LNN IOT

This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.

 draft-ietf-6lo-paging-dispatch-05 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8025 RFC8026 Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism M. Boucadair I. Farrer November 2016 ASCII 22857 11 Provisioning Softwire IPv4 over IPv6 IPv4 service continuity IPv4 address depletion MAP MAP-T MAP-E DS-Lite Lightweight 4 over 6

In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.

 draft-ietf-softwire-unified-cpe-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8026 RFC8027 DNSSEC Roadblock Avoidance W. Hardaker O. Gudmundsson S. Krishnaswamy November 2016 ASCII 40173 19 DNSSEC Network Problems DNS

This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.

 draft-ietf-dnsop-dnssec-roadblock-avoidance-05 BCP0207 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8027 10.17487/RFC8027 RFC8028 First-Hop Router Selection by Hosts in a Multi-Prefix Network F. Baker B. Carpenter November 2016 ASCII 30987 13

This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861.

 draft-ietf-6man-multi-homed-host-10 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8028 RFC8030 Generic Event Delivery Using HTTP Push M. Thomson E. Damaggio B. Raymor Editor December 2016 ASCII 68069 31 HTTP HTTP2 Push WebPush

This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.

 draft-ietf-webpush-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush 10.17487/RFC8030 RFC8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement Y. Nir S. Josefsson December 2016 ASCII 14969 8 Curve25519 Curve448 Goldilocks Diffie Hellman

This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).

 draft-ietf-ipsecme-safecurves-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8031 RFC8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing C. Holmberg November 2016 ASCII 11915 7 RTP RTCP multiplex rtcp-mux SDP offer answer

This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.

 draft-ietf-avtcore-5761-update-06 RFC5761 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8035 RFC8036 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks N. Cam-Winget Editor J. Hui D. Popa January 2017 ASCII 58383 24 constrained environment smart meter utilities smartgrid secure smartgrid connected energy

This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.

 draft-ietf-roll-applicability-ami-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC8036 RFC8039 Multipath Time Synchronization A. Shpiner R. Tse C. Schelp T. Mizrahi December 2016 ASCII 39763 17 NTP PTP IEEE 1588 multiple paths

Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.

 draft-ietf-tictoc-multi-path-synchronization-07 EXPERIMENTAL EXPERIMENTAL IETF int tictoc 10.17487/RFC8039 RFC8041 Use Cases and Operational Experience with Multipath TCP O. Bonaventure C. Paasch G. Detal January 2017 ASCII 75260 30 TCP MPTCP Middlebox Congestion Control Path Manager Scheduler Proxy Load-Balancer Datacenter Cellular/WiFi Offload Hybrid Access Networks

This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.

 draft-ietf-mptcp-experience-07 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC8041 RFC8042 OSPF Two-Part Metric Z. Zhang L. Wang A. Lindem December 2016 ASCII 18496 9 OSPF Broadcast Interface SPF metrics Radio Networks

This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts. This document updates RFC 2328.

 draft-ietf-ospf-two-part-metric-10 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8042 RFC8043 Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space B. Sarikaya M. Boucadair January 2017 ASCII 35213 16 Neighbor Discovery Duplicate Address Detection ND Relay Agent

This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.

The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.

 draft-sarikaya-6man-sadr-overview-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8043 RFC8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre December 2016 ASCII 71355 34 Extensible Messaging and Presence Protocol XMPP Jabber Session Initiation Protocol SIP SIMPLE presence availability

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248.

 draft-ietf-stox-7248bis-14 RFC7248 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC8048 RFC8051 Applicability of a Stateful Path Computation Element (PCE) X. Zhang Editor I. Minei Editor January 2017 ASCII 58011 24 Stateful PCE Applicability

A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.

 draft-ietf-pce-stateful-pce-app-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8051 RFC8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping J. Gould January 2017 ASCII 22084 11

This document describes the mapping of the Extensible Provisioning Protocol (EPP) statuses with the statuses registered for use in the Registration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP.

 draft-ietf-regext-epp-rdap-status-mapping-04 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8056 RFC8057 Uniform Resource Name (URN) Namespaces for Broadband Forum B. Stark D. Sinicrope W. Lupton January 2017 ASCII 17889 11 URN Broadband Forum BBF

This document describes the Namespace Identifiers (NIDs) "bbf", "broadband-forum-org", and "dslforum-org" for Uniform Resource Names (URNs) used to identify resources published by Broadband Forum (BBF). BBF specifies and manages resources that utilize these three URN identification models. Management activities for these and other resource types are handled by BBF.

 draft-bbf-bbf-urn-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8057 RFC8058 Signaling One-Click Functionality for List Email Headers J. Levine T. Herkula January 2017 ASCII 18219 9 email mailing list

This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.

 draft-levine-herkula-oneclick-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8058 RFC8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments J. Arango S. Venaas I. Kouvelas D. Farinacci January 2017 ASCII 19562 9

This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router).

 draft-ietf-pim-join-attributes-for-lisp-06 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC8059 STD0001 [STD number 1 is retired. It was "Internet Official Protocol Standards". See BCP 9 / RFC 7100 for more information.] STD0002 [Reserved for Assigned Numbers. See RFC 1700 and RFC 3232.] STD0003 Requirements for Internet Hosts RFC1122 RFC1123 STD0004 [Reserved for Router Requirements. See RFC 1812.] STD0005 Internet Protocol RFC0791 RFC0792 RFC0919 RFC0922 RFC0950 RFC1112 STD0006 User Datagram Protocol RFC0768 STD0007 Transmission Control Protocol RFC0793 STD0008 Telnet Protocol RFC0854 RFC0855 STD0009 File Transfer Protocol RFC0959 STD0010 Simple Mail Transfer Protocol RFC0821 RFC0974 RFC1869 RFC1870 STD0011 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES RFC0822 STD0012 [Reserved for Network Time Protocol (NTP). See RFC 1305.] STD0013 Domain Name System RFC1034 RFC1035 STD0014 [Was Mail Routing and the Domain System. Now Historic.] STD0015 [Was Simple Network Management Protocol. Now Historic.] STD0016 Structure of Management Information RFC1155 RFC1212 STD0017 Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC1213 STD0018 [Was Exterior Gateway Protocol (RFC 904). Now Historic.] STD0019 NetBIOS Service Protocols RFC1001 RFC1002 STD0020 Echo Protocol RFC0862 STD0021 Discard Protocol RFC0863 STD0022 Character Generator Protocol RFC0864 STD0023 Quote of the Day Protocol RFC0865 STD0024 Active users RFC0866 STD0025 Daytime Protocol RFC0867 STD0026 Time Protocol RFC0868 STD0027 Telnet Binary Transmission RFC0856 STD0028 Telnet Echo Option RFC0857 STD0029 Telnet Suppress Go Ahead Option RFC0858 STD0030 Telnet Status Option RFC0859 STD0031 Telnet Timing Mark Option RFC0860 STD0032 Telnet Extended Options: List Option RFC0861 STD0033 The TFTP Protocol (Revision 2) RFC1350 STD0034 [Was Routing Information Protocol (RIP). Replaced by STD 56.] STD0035 ISO Transport Service on top of the TCP Version: 3 RFC1006 STD0036 Transmission of IP and ARP over FDDI Networks RFC1390 STD0037 Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC0826 STD0038 A Reverse Address Resolution Protocol RFC0903 STD0039 [Was BBN Report 1822 (IMP/Host Interface). Now Historic.] STD0040 Host Access Protocol specification RFC0907 STD0041 A Standard for the Transmission of IP Datagrams over Ethernet Networks RFC0894 STD0042 Standard for the transmission of IP datagrams over experimental Ethernet networks RFC0895 STD0043 Standard for the transmission of IP datagrams over IEEE 802 networks RFC1042 STD0044 DCN Local-Network Protocols RFC0891 STD0045 Internet Protocol on Network System's HYPERchannel: Protocol Specification RFC1044 STD0046 Transmitting IP traffic over ARCNET networks RFC1201 STD0047 Nonstandard for transmission of IP datagrams over serial lines: SLIP RFC1055 STD0048 Standard for the transmission of IP datagrams over NetBIOS networks RFC1088 STD0049 Standard for the transmission of 802.2 packets over IPX networks RFC1132 STD0050 [Reserved for Definitions of Managed Objects for the Ethernet-like Interface Types. See RFC 3638.] STD0051 The Point-to-Point Protocol (PPP) RFC1661 RFC1662 STD0052 The Transmission of IP Datagrams over the SMDS Service RFC1209 STD0053 Post Office Protocol - Version 3 RFC1939 STD0054 OSPF Version 2 RFC2328 STD0055 Multiprotocol Interconnect over Frame Relay RFC2427 STD0056 RIP Version 2 RFC2453 STD0057 RIP Version 2 Protocol Applicability Statement RFC1722 STD0058 Structure of Management Information Version 2 (SMIv2) RFC2578 RFC2579 RFC2580 STD0059 Remote Network Monitoring Management Information Base RFC2819 STD0060 SMTP Service Extension for Command Pipelining RFC2920 STD0061 A One-Time Password System RFC2289 STD0062 Simple Network Management Protocol Version 3 (SNMPv3) RFC3411 RFC3412 RFC3413 RFC3414 RFC3415 RFC3416 RFC3417 RFC3418 STD0063 UTF-8, a transformation format of ISO 10646 RFC3629 STD0064 RTP: A Transport Protocol for Real-Time Applications RFC3550 STD0065 RTP Profile for Audio and Video Conferences with Minimal Control RFC3551 STD0066 Uniform Resource Identifier (URI): Generic Syntax RFC3986 STD0067 XDR: External Data Representation Standard RFC4506 STD0068 Augmented BNF for Syntax Specifications: ABNF RFC5234 STD0069 The Extensible Provisioning Protocol (EPP) RFC5730 RFC5731 RFC5732 RFC5733 RFC5734 STD0070 Cryptographic Message Syntax (CMS) RFC5652 STD0071 SMTP Service Extension for 8-bit MIME Transport RFC6152 STD0072 Message Submission for Mail RFC6409 STD0073 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages RFC6522 STD0074 Automated Updates of DNS Security (DNSSEC) Trust Anchors RFC5011 STD0075 Extension Mechanisms for DNS (EDNS(0)) RFC6891 STD0076 DomainKeys Identified Mail (DKIM) Signatures RFC6376 STD0077 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information RFC7011 STD0078 Simple Network Management Protocol (SNMP) Security RFC5343 RFC5590 RFC5591 RFC6353 STD0079 Internet Key Exchange Protocol Version 2 (IKEv2) RFC7296 STD0080 ASCII format for network interchange RFC0020 STD0081 A One-Way Delay Metric for IP Performance Metrics (IPPM) RFC7679 STD0082 A One-Way Loss Metric for IP Performance Metrics (IPPM) RFC7680 STD0083 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) RFC7761 ./queue2.xml0000664000764400076440000014775313041743722012325 0ustar iustyiusty
draft-ietf-rtcweb-data-channel-13.txt 2015-01-08 MISSREF*R(1G) draft-ietf-tsvwg-sctp-ndata NOT-RECEIVED draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-tsvwg-sctp-dtls-encaps IN-QUEUE draft-ietf-rtcweb-security NOT-RECEIVED draft-ietf-rtcweb-security-arch NOT-RECEIVED draft-ietf-rtcweb-jsep NOT-RECEIVED draft-ietf-mmusic-sctp-sdp NOT-RECEIVED R. Jesup, S. Loreto, M. Tuexen WebRTC Data Channels 36549 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-data-protocol-09.txt 2015-01-08 MISSREF*R(1G) draft-ietf-tsvwg-sctp-dtls-encaps IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-tsvwg-sctp-ndata NOT-RECEIVED draft-ietf-rtcweb-security NOT-RECEIVED draft-ietf-rtcweb-security-arch NOT-RECEIVED draft-ietf-rtcweb-jsep NOT-RECEIVED draft-ietf-mmusic-sctp-sdp NOT-RECEIVED R. Jesup, S. Loreto, M. Tuexen WebRTC Data Channel Establishment Protocol 28411 Real-Time Communication in WEB-browsers yes draft-ietf-tsvwg-sctp-dtls-encaps-09.txt 2015-01-26 MISSREF*R(1G) draft-ietf-tsvwg-sctp-ndata NOT-RECEIVED M. Tuexen, R. Stewart, R. Jesup, S. Loreto DTLS Encapsulation of SCTP Packets 20211 Transport Area Working Group yes draft-ietf-rtcweb-rtp-usage-26.txt 2015-07-01 MISSREF*R(1G) draft-ietf-avtcore-multi-media-rtp-session IN-QUEUE draft-ietf-avtcore-rtp-circuit-breakers IN-QUEUE draft-ietf-avtcore-rtp-multi-stream IN-QUEUE draft-ietf-avtcore-rtp-multi-stream-optimisation IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation NOT-RECEIVED draft-ietf-ietf-rtcweb-fec NOT-RECEIVED draft-ietf-rtcweb-overview NOT-RECEIVED draft-ietf-rtcweb-security NOT-RECEIVED draft-ietf-rtcweb-security-arch NOT-RECEIVED C. Perkins, M. Westerlund, J. Ott Web Real-Time Communication (WebRTC: Media Transport and Use of RTP 123242 Real-Time Communication in WEB-browsers yes draft-ietf-bfcpbis-rfc4582bis-16.txt 2015-11-23 MISSREF*R(1G) draft-ietf-bfcpbis-rfc4583bis NOT-RECEIVED G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel The Binary Floor Control Protocol (BFCP) 225320 Binary Floor Control Protocol Bis yes draft-ietf-avtcore-rtp-multi-stream-11.txt 2015-12-14 MISSREF*R(1G) draft-ietf-avtcore-multi-media-rtp-session IN-QUEUE draft-ietf-avtcore-rtp-multi-stream-optimisation IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation NOT-RECEIVED J. Lennox, M. Westerlund, Q. Wu, C. Perkins Sending Multiple RTP Streams in a Single RTP Session 74438 Audio/Video Transport Core Maintenance yes draft-ietf-netconf-call-home-17.txt 2015-12-28 REF*R draft-ietf-netconf-restconf IN-QUEUE K. Watsen NETCONF Call Home and RESTCONF Call Home 32365 Network Configuration yes draft-ietf-avtcore-multi-media-rtp-session-13.txt 2015-12-28 MISSREF*R(1G) draft-ietf-avtcore-rtp-multi-stream IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation NOT-RECEIVED M. Westerlund, C. Perkins, J. Lennox Sending Multiple Types of Media in a Single RTP Session 38919 Audio/Video Transport Core Maintenance yes draft-ietf-clue-framework-25.txt 2016-01-14 MISSREF*R(1G) draft-ietf-clue-datachannel NOT-RECEIVED draft-ietf-clue-data-model-schema IN-QUEUE draft-ietf-clue-protocol NOT-RECEIVED draft-ietf-clue-signaling NOT-RECEIVED M. Duckworth, Ed., A. Pepperell, S. Wenger Framework for Telepresence Multi-Streams 186803 ControLling mUltiple streams for tElepresence yes draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt 2016-03-09 MISSREF*R(2G) draft-ietf-avtcore-rtp-multi-stream IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE J. Lennox, M. Westerlund, Q. Wu, C. Perkins Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback 46256 Audio/Video Transport Core Maintenance yes draft-ietf-rtcweb-alpn-04.txt 2016-05-12 MISSREF*R(1G) draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-security-arch NOT-RECEIVED M. Thomson Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) 15355 Real-Time Communication in WEB-browsers yes draft-ietf-mmusic-msid-15.txt 2016-07-12 MISSREF*R(1G) draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-rtcweb-jsep NOT-RECEIVED H. Alvestrand WebRTC MediaStream Identification in the Session Description Protocol 35897 Multiparty Multimedia Session Control yes draft-ietf-avtext-splicing-notification-09.txt 2016-08-03 MISSREF*R(1G) draft-ietf-avtcore-rfc5285-bis NOT-RECEIVED J. Xia, R. Even, R. Huang, L. Deng RTP/RTCP extension for RTP Splicing Notification 45559 Audio/Video Transport Extensions yes draft-ietf-mmusic-mux-exclusive-10.txt 2016-08-09 MISSREF*R(1G) draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation NOT-RECEIVED C. Holmberg Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 25385 Multiparty Multimedia Session Control yes draft-ietf-clue-data-model-schema-17.txt 2016-08-15 MISSREF*R(1G) draft-ietf-clue-datachannel NOT-RECEIVED draft-ietf-clue-framework IN-QUEUE draft-ietf-clue-protocol NOT-RECEIVED R. Presta, S. Pietro Romano An XML Schema for the CLUE data model 151635 ControLling mUltiple streams for tElepresence yes draft-ietf-avtcore-rtp-circuit-breakers-18.txt 2016-08-18 AUTH48*R http://www.rfc-editor.org/auth48/rfc8083 draft-ietf-tsvwg-circuit-breaker IN-QUEUE C. Perkins, V. Singh Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions 67470 Audio/Video Transport Core Maintenance yes draft-ietf-tsvwg-rtcweb-qos-18.txt 2016-08-22 MISSREF*R(1G) draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security NOT-RECEIVED draft-ietf-rtcweb-transports IN-QUEUE P. Jones, S. Dhesikan, C. Jennings, D. Druta DSCP Packet Markings for WebRTC QoS 26177 Transport Area Working Group yes draft-ietf-jose-cfrg-curves-06.txt 2016-08-22 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8037 draft-irtf-cfrg-eddsa IN-QUEUE I. Liusvaara CFRG ECDH and signatures in JOSE 23960 Javascript Object Signing and Encryption yes draft-ietf-pce-pcep-service-aware-13.txt 2016-09-27 MISSREF*R(1G) draft-ietf-pce-stateful-pce NOT-RECEIVED D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). 62016 Path Computation Element yes draft-ietf-tsvwg-gre-in-udp-encap-19.txt 2016-10-03 AUTH48*R http://www.rfc-editor.org/auth48/rfc8086 draft-ietf-tsvwg-rfc5405bis IN-QUEUE L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert GRE-in-UDP Encapsulation 57893 Transport Area Working Group yes draft-ietf-avtext-rid-09.txt 2016-10-19 MISSREF*R(1G) draft-ietf-mmusic-sdp-bundle-negotiation NOT-RECEIVED A. Roach, S. Nandakumar, P. Thatcher RTP Stream Identifier Source Description (SDES) 19604 Audio/Video Transport Extensions yes draft-ietf-rtcweb-transports-17.txt 2016-10-27 MISSREF*R(1G) draft-ietf-avtcore-rtp-circuit-breakers IN-QUEUE draft-ietf-ice-rfc5245bis NOT-RECEIVED draft-ietf-mmusic-ice-dualstack-fairness NOT-RECEIVED draft-ietf-mmusic-sctp-sdp NOT-RECEIVED draft-ietf-rmcat-cc-requirements IN-QUEUE draft-ietf-rtcweb-alpn IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-overview NOT-RECEIVED draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security NOT-RECEIVED draft-ietf-rtcweb-security-arch NOT-RECEIVED draft-ietf-tsvwg-rtcweb-qos IN-QUEUE draft-ietf-tsvwg-sctp-dtls-encaps IN-QUEUE draft-ietf-tsvwg-sctp-ndata NOT-RECEIVED H. Alvestrand Transports for WebRTC 41832 Real-Time Communication in WEB-browsers yes draft-ietf-netconf-restconf-18.txt 2016-10-31 AUTH48 http://www.rfc-editor.org/auth48/rfc8040 A. Bierman, M. Bjorklund, K. Watsen RESTCONF Protocol 248399 Network Configuration yes draft-ietf-hip-rfc5206-bis-14.txt 2016-11-02 AUTH48 http://www.rfc-editor.org/auth48/rfc8046 T. Henderson, Ed., C. Vogt, J. Arkko Host Mobility with the Host Identity Protocol 93122 Host Identity Protocol yes draft-ietf-hip-multihoming-12.txt 2016-11-02 AUTH48*R http://www.rfc-editor.org/auth48/rfc8047 draft-ietf-hip-rfc5206-bis IN-QUEUE T. Henderson, Ed., C. Vogt, J. Arkko Host Multihoming with the Host Identity Protocol 62130 Host Identity Protocol yes draft-ietf-radext-ip-port-radius-ext-17.txt 2016-11-07 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8045 draft-ietf-radext-datatypes IN-QUEUE D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar RADIUS Extensions for IP Port Configuration and Reporting 83183 RADIUS EXTensions yes draft-ietf-mpls-rfc4379bis-09.txt 2016-11-07 AUTH48 http://www.rfc-editor.org/auth48/rfc8029 K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures 172990 Multiprotocol Label Switching yes draft-ietf-radext-datatypes-08.txt 2016-11-14 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8044 A. DeKok Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) 73312 RADIUS EXTensions yes draft-ietf-cose-msg-24.txt 2016-11-28 IANA*A*R draft-irtf-cfrg-eddsa IN-QUEUE J. Schaad CBOR Object Signing and Encryption (COSE) 263255 CBOR Object Signing and Encryption yes draft-ietf-pals-rfc4447bis-05.txt 2016-11-29 AUTH48 http://www.rfc-editor.org/auth48/rfc8077 L. Martini, Ed., G. Heron, Ed. Pseudowire Setup and Maintenance using the Label Distribution Protocol 76769 Pseudowire And LDP-enabled Services yes draft-ietf-l3sm-l3vpn-service-model-19.txt 2016-11-30 RFC-EDITOR*R draft-ietf-netconf-restconf IN-QUEUE S. Litkowski, L. Tomotaki, K. Ogaki YANG Data Model for L3VPN service delivery 279956 L3VPN Service Model yes draft-ietf-netconf-yang-patch-14.txt 2016-12-02 EDIT*R draft-ietf-netconf-restconf IN-QUEUE A. Bierman, M. Bjorklund, K. Watsen YANG Patch Media Type 74446 Network Configuration yes draft-ietf-appsawg-mdn-3798bis-16.txt 2016-12-05 RFC-EDITOR T. Hansen, Ed., A. Melnikov, Ed. Message Disposition Notification 80000 ART Area General Application Working Group yes draft-ietf-kitten-rfc6112bis-03.txt 2016-12-05 AUTH48 http://www.rfc-editor.org/auth48/rfc8062 L. Zhu, P. Leach, S. Hartman, S. Emery, Ed. Anonymity Support for Kerberos 41668 Common Authentication Technology Next Generation yes draft-ietf-nfsv4-scsi-layout-10.txt 2016-12-06 EDIT C. Hellwig Parallel NFS (pNFS) SCSI Layout 71886 Network File System Version 4 yes draft-ietf-eppext-keyrelay-12.txt 2016-12-06 RFC-EDITOR R. Ribbers, M. Groeneweg, M. Gieben, A. Verschuren Key Relay Mapping for the Extensible Provisioning Protocol 33995 Registration Protocols Extensions yes draft-ietf-p2psip-share-10.txt 2016-12-07 EDIT A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch A Usage for Shared Resources in RELOAD (ShaRe) 45871 Peer-to-Peer Session Initiation Protocol yes draft-ietf-core-http-mapping-17.txt 2016-12-19 EDIT A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk Guidelines for HTTP-to-CoAP Mapping Implementations 91549 Constrained RESTful Environments yes draft-ietf-justfont-toplevel-06.txt 2016-12-19 EDIT C. Lilley The font Top Level Type 35891 Font Top Level Media Type yes draft-ietf-6man-default-iids-16.txt 2016-12-19 EDIT F. Gont, A. Cooper, D. Thaler, W. Liu Recommendation on Stable IPv6 Interface Identifiers 19475 IPv6 Maintenance yes draft-ietf-appsawg-file-scheme-16.txt 2016-12-19 EDIT M. Kerwin The file URI Scheme 36765 ART Area General Application Working Group yes draft-ietf-6lo-dispatch-iana-registry-07.txt 2016-12-19 RFC-EDITOR S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt 6lowpan ESC Dispatch Code Points and Guidelines 17947 IPv6 over Networks of Resource-constrained Nodes yes draft-ietf-mmusic-sdp-mux-attributes-16.txt 2016-12-20 MISSREF*R(1G) draft-ietf-mmusic-sdp-bundle-negotiation NOT-RECEIVED S. Nandakumar A Framework for SDP Attributes when Multiplexing 234454 Multiparty Multimedia Session Control yes draft-ietf-straw-b2bua-rtcp-17.txt 2016-12-22 EDIT L. Miniero, S. Garcia Murillo, V. Pascual Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) 47217 Sip Traversal Required for Applications to Work yes draft-ietf-kitten-pkinit-freshness-07.txt 2016-12-22 EDIT M. Short, Ed., S. Moore, P. Miller Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension 16046 Common Authentication Technology Next Generation yes draft-ietf-curdle-dnskey-eddsa-03.txt 2017-01-09 EDIT*R draft-irtf-cfrg-eddsa IN-QUEUE O. Sury, R. Edmonds EdDSA for DNSSEC 14434 CURves, Deprecating and a Little more Encryption yes draft-ietf-savi-mix-15.txt 2017-01-09 EDIT J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed. SAVI for Mixed Address Assignment Methods Scenario 23533 Source Address Validation Improvements yes draft-ietf-dnsop-maintain-ds-06.txt 2017-01-09 EDIT O. Gudmundsson, P. Wouters Managing DS records from parent via CDS/CDNSKEY 21329 Domain Name System Operations yes draft-ietf-idr-deprecate-30-31-129-02.txt 2017-01-09 EDIT*R draft-ietf-idr-large-community IN-QUEUE J. Snijders Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 243 5706 Inter-Domain Routing yes draft-ietf-idr-large-community-12.txt 2017-01-09 EDIT J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard BGP Large Communities 17707 Inter-Domain Routing yes draft-ietf-sidr-bgpsec-pki-profiles-21.txt 2017-01-09 MISSREF*R(1G) draft-ietf-sidr-bgpsec-protocol IN-QUEUE draft-ietf-sidr-bgpsec-algs NOT-RECEIVED M. Reynolds, S. Turner, S. Kent A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests 28349 Secure Inter-Domain Routing yes draft-ietf-avtext-avpf-ccm-layered-04.txt 2017-01-10 EDIT S. Wenger, J. Lennox, B. Burman, M. Westerlund Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs 25884 Audio/Video Transport Extensions yes draft-ietf-sidr-origin-validation-signaling-11.txt 2017-01-11 EDIT P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush BGP Prefix Origin Validation State Extended Community 12654 Secure Inter-Domain Routing yes draft-ietf-sidr-bgpsec-protocol-22.txt 2017-01-18 MISSREF*A*R(1G) draft-ietf-idr-bgp-extended-messages NOT-RECEIVED draft-ietf-sidr-bgpsec-algs NOT-RECEIVED draft-ietf-sidr-bgpsec-pki-profiles IN-QUEUE M. Lepinski, Ed., K. Sriram, Ed. BGPsec Protocol Specification 114311 Secure Inter-Domain Routing yes draft-ietf-rtgwg-rlfa-node-protection-13.txt 2017-01-20 EDIT P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski Remote-LFA Node Protection and Manageability 50094 Routing Area Working Group yes draft-ietf-curdle-cms-chacha20-poly1305-06.txt 2017-01-23 EDIT*A R. Housley Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) 17030 CURves, Deprecating and a Little more Encryption yes
draft-ietf-ipfix-mib-variable-export-10.txt 2015-11-30 AUTH48 http://www.rfc-editor.org/auth48/rfc8038 P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder Exporting MIB Variables using the IPFIX Protocol 186118 IETF - NON WORKING GROUP yes draft-ietf-forces-interfelfb-06.txt 2016-07-05 AUTH48 http://www.rfc-editor.org/auth48/rfc8013 D. Joachimpillai, J. Hadi Salim ForCES Inter-FE LFB 54732 IETF - NON WORKING GROUP yes draft-weis-gdoi-iec62351-9-10.txt 2016-11-08 AUTH48 http://www.rfc-editor.org/auth48/rfc8052 B. Weis, M. Seewald, H. Falk GDOI Protocol Support for IEC 62351 Security Services 54459 IETF - NON WORKING GROUP yes draft-murchison-nntp-compress-06.txt 2016-11-30 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8054 K. Murchison, J. Elie Network News Transfer Protocol (NNTP) Extension for Compression 52367 IETF - NON WORKING GROUP yes draft-holmberg-dispatch-received-realm-12.txt 2016-12-05 AUTH48 http://www.rfc-editor.org/auth48/rfc8055 C. Holmberg, Y. Jiang Session Initiation Protocol (SIP) Via header field parameter to indicate received realm 28065 IETF - NON WORKING GROUP yes
draft-ietf-payload-rtp-howto-14.txt 2014-01-23 RFC-EDITOR*R draft-ietf-avtcore-rtp-circuit-breakers IN-QUEUE M. Westerlund How to Write an RTP Payload Format 159341 Audio/Video Transport Payloads yes draft-ietf-rmcat-cc-requirements-09.txt 2014-12-12 MISSREF*R(1G) draft-ietf-rtcweb-overview NOT-RECEIVED draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-jsep NOT-RECEIVED draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security NOT-RECEIVED draft-ietf-rtcweb-security-arch NOT-RECEIVED R. Jesup, Z. Sarker, Ed. Congestion Control Requirements for Interactive Real-Time Media 27484 RTP Media Congestion Avoidance Techniques yes draft-ietf-lisp-introduction-13.txt 2015-04-23 MISSREF*R(1G) draft-ietf-lisp-ddt NOT-RECEIVED draft-ietf-lisp-lcaf IN-QUEUE draft-ietf-lisp-sec NOT-RECEIVED A. Cabellos-Aparicio, D. Saucez, Ed. An Architectural Introduction to the Locator/ID Separation Protocol (LISP) 66992 Locator/ID Separation Protocol yes draft-ietf-aqm-ecn-benefits-08.txt 2015-12-01 AUTH48*R http://www.rfc-editor.org/auth48/rfc8087 draft-ietf-tsvwg-rfc5405bis IN-QUEUE G. Fairhurst, M. Welzl The Benefits of using Explicit Congestion Notification (ECN) 49094 Active Queue Management and Packet Scheduling yes draft-ietf-lwig-cellular-06.txt 2016-01-04 MISSREF*R(1G) draft-ietf-core-resource-directory NOT-RECEIVED draft-ietf-core-senml NOT-RECEIVED J. Arkko, A. Eriksson, A. Keranen Building Power-Efficient CoAP Devices for Cellular Networks 39751 Light-Weight Implementation Guidance yes draft-ietf-aqm-fq-codel-06.txt 2016-04-03 MISSREF*R(1G) draft-ietf-aqm-codel NOT-RECEIVED T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm 56362 Active Queue Management and Packet Scheduling yes draft-ietf-aqm-docsis-pie-02.txt 2016-04-05 AUTH48*R http://www.rfc-editor.org/auth48/rfc8034 draft-ietf-aqm-pie IN-QUEUE G. White, R. Pan A PIE-Based AQM for DOCSIS Cable Modems 32275 Active Queue Management and Packet Scheduling yes draft-ietf-tsvwg-circuit-breaker-15.txt 2016-05-17 AUTH48*R http://www.rfc-editor.org/auth48/rfc8084 draft-ietf-tsvwg-rfc5405bis IN-QUEUE G. Fairhurst Network Transport Circuit Breakers 67370 Transport Area Working Group yes draft-ietf-i2rs-protocol-security-requirements-17.txt 2016-10-03 MISSREF*R(1G) draft-ietf-i2rs-security-environment-reqs NOT-RECEIVED S. Hares, D. Migault, J. Halpern I2RS Security Related Requirements 45947 Interface to the Routing System yes draft-ietf-aqm-pie-10.txt 2016-10-25 AUTH48 http://www.rfc-editor.org/auth48/rfc8033 R. Pan, P. Natarajan, F. Baker, G. White PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem 55319 Active Queue Management and Packet Scheduling yes draft-ietf-lisp-crypto-10.txt 2016-10-28 RFC-EDITOR*R draft-ietf-lisp-lcaf IN-QUEUE D. Farinacci, B. Weis LISP Data-Plane Confidentiality 44512 Locator/ID Separation Protocol yes draft-ietf-tsvwg-rfc5405bis-19.txt 2016-11-13 AUTH48*R http://www.rfc-editor.org/auth48/rfc8085 draft-ietf-tsvwg-circuit-breaker IN-QUEUE L. Eggert, G. Fairhurst, G. Shepherd UDP Usage Guidelines 153158 Transport Area Working Group yes draft-ietf-httpauth-mutual-algo-07.txt 2016-11-14 EDIT*A*R draft-ietf-httpauth-mutual IN-QUEUE Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms 32733 Hypertext Transfer Protocol Authentication yes draft-ietf-httpauth-extension-09.txt 2016-11-15 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8053 Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku HTTP Authentication Extensions for Interactive Clients 65279 Hypertext Transfer Protocol Authentication yes draft-ietf-lisp-lcaf-22.txt 2016-12-02 RFC-EDITOR D. Farinacci, D. Meyer, J. Snijders LISP Canonical Address Format (LCAF) 90497 Locator/ID Separation Protocol yes draft-ietf-6man-ipv6-mibs-obsolete-02.txt 2016-12-06 EDIT*A B. Fenner Republishing the IPV6-specific MIB modules as obsolete 116225 IPv6 Maintenance yes draft-ietf-i2rs-ephemeral-state-23.txt 2016-12-07 MISSREF*R(1G) draft-ietf-netconf-restconf IN-QUEUE draft-ietf-i2rs-security-environment-reqs NOT-RECEIVED draft-ietf-i2rs-protocol-security-requirements IN-QUEUE J. Haas, S. Hares I2RS Ephemeral State Requirements 25012 Interface to the Routing System yes draft-ietf-taps-transports-14.txt 2016-12-09 EDIT G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed. Services provided by IETF transport protocols and congestion control mechanisms 127101 Transport Services yes draft-ietf-6lo-privacy-considerations-04.txt 2016-12-15 RFC-EDITOR D. Thaler Privacy Considerations for IPv6 Adaptation Layer Mechanisms 22490 IPv6 over Networks of Resource-constrained Nodes yes draft-ietf-siprec-callflows-08.txt 2016-12-19 EDIT R. Ravindranath, P. Ravindran, P. Kyzivat Session Initiation Protocol (SIP) Recording Call Flows 64818 SIP Recording yes draft-ietf-ice-dualstack-fairness-07.txt 2016-12-23 MISSREF*R(1G) draft-ietf-ice-rfc5245bis NOT-RECEIVED P. Martinsen, T. Reddy, P. Patil ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines 23178 Interactive Connectivity Establishment yes draft-ietf-httpauth-mutual-11.txt 2017-01-06 EDIT*A*R draft-ietf-httpauth-extension IN-QUEUE Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku Mutual Authentication Protocol for HTTP 130718 Hypertext Transfer Protocol Authentication yes draft-ietf-sidr-bgpsec-ops-16.txt 2017-01-09 MISSREF*R(2G) draft-ietf-sidr-bgpsec-protocol IN-QUEUE R. Bush BGPsec Operational Considerations 19863 Secure Inter-Domain Routing yes draft-ietf-dprive-dnsodtls-15.txt 2017-01-17 EDIT T. Reddy, D. Wing, P. Patil Specification for DNS over Datagram Transport Layer Security (DTLS) 31290 DNS PRIVate Exchange yes draft-ietf-tsvwg-diffserv-intercon-14.txt 2017-01-19 EDIT R. Geib, Ed., D. Black Diffserv-Interconnection classes and practice 51222 Transport Area Working Group yes draft-ietf-ospf-ttz-06.txt 2017-01-19 EDIT*A H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu OSPF Topology-Transparent Zone 61631 Open Shortest Path First IGP yes draft-ietf-sidr-adverse-actions-04.txt 2017-01-23 MISSREF*R(2G) draft-ietf-sidr-bgpsec-pki-profiles IN-QUEUE draft-ietf-sidr-bgpsec-protocol IN-QUEUE S. Kent, D. Ma Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) 63913 Secure Inter-Domain Routing yes
draft-moriarty-pkcs5-v2dot1-04.txt 2016-09-20 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8018 K. Moriarty, Ed., B. Kaliski, A. Rusch PKCS #5: Password-Based Cryptography Specification Version 2.1 74631 IETF - NON WORKING GROUP yes draft-ieee-urn-03.txt 2016-12-05 AUTH48 http://www.rfc-editor.org/auth48/rfc8069 A. Thomas URN Namespace for IEEE 10808 IETF - NON WORKING GROUP yes draft-leiba-3967upd-downref-03.txt 2016-12-09 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8067 B. Leiba Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level 6362 IETF - NON WORKING GROUP yes draft-wilde-json-seq-suffix-03.txt 2017-01-04 EDIT E. Wilde A Media Type Structured Syntax Suffix for JSON Text Sequences 9883 IETF - NON WORKING GROUP yes draft-adid-urn-03.txt 2017-01-19 EDIT J. Wold Advertising Digital Identification (Ad-ID) URN Namespace Definition 11002 IETF - NON WORKING GROUP yes draft-holmberg-dispatch-mcptt-rp-namespace-05.txt 2017-01-23 EDIT*A C. Holmberg, J. Axell IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk service 11522 IETF - NON WORKING GROUP yes
draft-iab-ccg-appoint-process-03.txt 2017-01-04 EDIT R. Housley Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) 12029 IAB yes draft-iab-carisreport-02.txt 2017-01-05 EDIT K. Moriarty, M. Ford Coordinating Attack Response at Internet Scale (CARIS) Workshop Report 36365 IAB yes
draft-irtf-cfrg-eddsa-08.txt 2016-10-18 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8032 S. Josefsson, I. Liusvaara Edwards-curve Digital Signature Algorithm (EdDSA) 104698 Crypto Forum Research Group yes
draft-farinacci-lisp-rig-05.txt 2015-04-21 MISSREF*R(1G) draft-ietf-lisp-ddt NOT-RECEIVED D. Farinacci, A. Jain, I. Kouvelas, D. Lewis LISP-DDT Referral Internet Groper (RIG) 23423 INDEPENDENT N/A
./queue.html0000664000764400076440000021542313041750265012375 0ustar iustyiusty Current Queue » RFC Editor

Publication Queue

[About this page]  [Summary statistics]  [List of all active clusters]

Found 98 records

Current stateWeeks in stateWeeks in queueDraft name (Authors) ClusterPagesSubmitted
EDIT*A*R		2.110.1draft-ietf-httpauth-mutual-algo-07
Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku		C305162016-11-14
EDIT*R		7.17.6draft-ietf-netconf-yang-patch-14
A. Bierman, M. Bjorklund, K. Watsen		C279432016-12-02
EDIT		6.97.0draft-ietf-nfsv4-scsi-layout-10
C. Hellwig		292016-12-06
EDIT*A		7.07.0draft-ietf-6man-ipv6-mibs-obsolete-02
B. Fenner		642016-12-06
EDIT		6.16.9draft-ietf-p2psip-share-10
A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch		202016-12-07
EDIT		6.66.6draft-ietf-taps-transports-14
G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.		532016-12-09
EDIT		5.15.1draft-ietf-6man-default-iids-16
F. Gont, A. Cooper, D. Thaler, W. Liu		92016-12-19
EDIT		5.15.1draft-ietf-siprec-callflows-08
R. Ravindranath, P. Ravindran, P. Kyzivat		332016-12-19
EDIT		4.75.1draft-ietf-justfont-toplevel-06
C. Lilley		172016-12-19
EDIT		5.05.1draft-ietf-appsawg-file-scheme-16
M. Kerwin		182016-12-19
EDIT		5.05.1draft-ietf-core-http-mapping-17
A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk		432016-12-19
EDIT		4.74.7draft-ietf-kitten-pkinit-freshness-07
M. Short, Ed., S. Moore, P. Miller		82016-12-22
EDIT		4.74.7draft-ietf-straw-b2bua-rtcp-17
L. Miniero, S. Garcia Murillo, V. Pascual		192016-12-22
EDIT		2.12.9draft-wilde-json-seq-suffix-03
E. Wilde		52017-01-04
EDIT		2.72.9draft-iab-ccg-appoint-process-03
R. Housley		62017-01-04
EDIT		2.72.7draft-iab-carisreport-02
K. Moriarty, M. Ford		152017-01-05
EDIT*A*R		2.12.6draft-ietf-httpauth-mutual-11
Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku		C305572017-01-06
EDIT*R		1.92.1draft-ietf-curdle-dnskey-eddsa-03
O. Sury, R. Edmonds		C29782017-01-09
EDIT		1.92.1draft-ietf-dnsop-maintain-ds-06
O. Gudmundsson, P. Wouters		102017-01-09
EDIT		1.92.1draft-ietf-idr-large-community-12
J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard		C30792017-01-09
EDIT		2.12.1draft-ietf-savi-mix-15
J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.		112017-01-09
EDIT*R		1.92.1draft-ietf-idr-deprecate-30-31-129-02
J. Snijders		C30732017-01-09
EDIT		2.02.0draft-ietf-avtext-avpf-ccm-layered-04
S. Wenger, J. Lennox, B. Burman, M. Westerlund		112017-01-10
EDIT		1.91.9draft-ietf-sidr-origin-validation-signaling-11
P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush		62017-01-11
EDIT		1.01.0draft-ietf-dprive-dnsodtls-15
T. Reddy, D. Wing, P. Patil		132017-01-17
EDIT		0.70.7draft-ietf-tsvwg-diffserv-intercon-14
R. Geib, Ed., D. Black		222017-01-19
EDIT*A		0.70.7draft-ietf-ospf-ttz-06
H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu		282017-01-19
EDIT		0.10.7draft-adid-urn-03
J. Wold		72017-01-19
EDIT		0.60.6draft-ietf-rtgwg-rlfa-node-protection-13
P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski		212017-01-20
EDIT*A		0.10.1draft-holmberg-dispatch-mcptt-rp-namespace-05
C. Holmberg, J. Axell		62017-01-23
EDIT*A		0.10.1draft-ietf-curdle-cms-chacha20-poly1305-06
R. Housley		82017-01-23
RFC-EDITOR*R		1.6156.7draft-ietf-payload-rtp-howto-14
M. Westerlund		C238612014-01-23
RFC-EDITOR*R		1.612.6draft-ietf-lisp-crypto-10
D. Farinacci, B. Weis		C251212016-10-28
RFC-EDITOR*R		0.07.9draft-ietf-l3sm-l3vpn-service-model-19
S. Litkowski, L. Tomotaki, K. Ogaki		C2791612016-11-30
RFC-EDITOR		1.67.6draft-ietf-lisp-lcaf-22
D. Farinacci, D. Meyer, J. Snijders		C251472016-12-02
RFC-EDITOR		0.17.1draft-ietf-appsawg-mdn-3798bis-16
T. Hansen, Ed., A. Melnikov, Ed.		372016-12-05
RFC-EDITOR		1.07.0draft-ietf-eppext-keyrelay-12
R. Ribbers, M. Groeneweg, M. Gieben, A. Verschuren		192016-12-06
RFC-EDITOR		0.15.7draft-ietf-6lo-privacy-considerations-04
D. Thaler		92016-12-15
RFC-EDITOR		0.15.1draft-ietf-6lo-dispatch-iana-registry-07
S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt		92016-12-19
AUTH48		5.760.1draft-ietf-ipfix-mib-variable-export-10
P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder		802015-11-30
AUTH48*R		0.160.0draft-ietf-aqm-ecn-benefits-08
G. Fairhurst, M. Welzl		C238212015-12-01
AUTH48*R		6.042.0draft-ietf-aqm-docsis-pie-02
G. White, R. Pan		C290152016-04-05
AUTH48*R		0.936.0draft-ietf-tsvwg-circuit-breaker-15
G. Fairhurst		C238272016-05-17
AUTH48		12.029.0draft-ietf-forces-interfelfb-06
D. Joachimpillai, J. Hadi Salim		252016-07-05
AUTH48*R		0.922.7draft-ietf-avtcore-rtp-circuit-breakers-18
C. Perkins, V. Singh		C238252016-08-18
AUTH48*R		0.116.1draft-ietf-tsvwg-gre-in-udp-encap-19
L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert		C238252016-10-03
AUTH48		6.013.0draft-ietf-aqm-pie-10
R. Pan, P. Natarajan, F. Baker, G. White		C290272016-10-25
AUTH48		4.912.1draft-ietf-netconf-restconf-18
A. Bierman, M. Bjorklund, K. Watsen		1332016-10-31
AUTH48*R		5.111.9draft-ietf-hip-multihoming-12
T. Henderson, Ed., C. Vogt, J. Arkko		C295242016-11-02
AUTH48		5.111.9draft-ietf-hip-rfc5206-bis-14
T. Henderson, Ed., C. Vogt, J. Arkko		C295372016-11-02
AUTH48		2.911.1draft-ietf-mpls-rfc4379bis-09
K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen		732016-11-07
AUTH48		1.711.0draft-weis-gdoi-iec62351-9-10
B. Weis, M. Seewald, H. Falk		252016-11-08
AUTH48*R		0.910.3draft-ietf-tsvwg-rfc5405bis-19
L. Eggert, G. Fairhurst, G. Shepherd		C238582016-11-13
AUTH48		0.78.0draft-ietf-pals-rfc4447bis-05
L. Martini, Ed., G. Heron, Ed.		342016-11-29
AUTH48		1.97.1draft-holmberg-dispatch-received-realm-12
C. Holmberg, Y. Jiang		142016-12-05
AUTH48		0.97.1draft-ieee-urn-03
A. Thomas		62016-12-05
AUTH48		1.07.1draft-ietf-kitten-rfc6112bis-03
L. Zhu, P. Leach, S. Hartman, S. Emery, Ed.		172016-12-05
AUTH48-DONE*R		5.022.1draft-ietf-jose-cfrg-curves-06
I. Liusvaara		C297132016-08-22
AUTH48-DONE		0.018.0draft-moriarty-pkcs5-v2dot1-04
K. Moriarty, Ed., B. Kaliski, A. Rusch		332016-09-20
AUTH48-DONE		1.014.0draft-irtf-cfrg-eddsa-08
S. Josefsson, I. Liusvaara		C297592016-10-18
AUTH48-DONE*R		0.711.1draft-ietf-radext-ip-port-radius-ext-17
D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar		C303392016-11-07
AUTH48-DONE		0.110.1draft-ietf-radext-datatypes-08
A. DeKok		C303392016-11-14
AUTH48-DONE		0.110.0draft-ietf-httpauth-extension-09
Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku		C305292016-11-15
AUTH48-DONE		0.07.9draft-murchison-nntp-compress-06
K. Murchison, J. Elie		252016-11-30
AUTH48-DONE		0.96.6draft-leiba-3967upd-downref-03
B. Leiba		32016-12-09
MISSREF*R(1G)		110.4110.6draft-ietf-rmcat-cc-requirements-09
R. Jesup, Z. Sarker, Ed.		C238122014-12-12
MISSREF*R(1G)		104.9106.7draft-ietf-rtcweb-data-protocol-09
R. Jesup, S. Loreto, M. Tuexen		C238132015-01-08
MISSREF*R(1G)		106.1106.7draft-ietf-rtcweb-data-channel-13
R. Jesup, S. Loreto, M. Tuexen		C238162015-01-08
MISSREF*R(1G)		99.6104.1draft-ietf-tsvwg-sctp-dtls-encaps-09
M. Tuexen, R. Stewart, R. Jesup, S. Loreto		C238102015-01-26
MISSREF*R(1G)		91.992.0draft-farinacci-lisp-rig-05
D. Farinacci, A. Jain, I. Kouvelas, D. Lewis		C251122015-04-21
MISSREF*R(1G)		91.691.7draft-ietf-lisp-introduction-13
A. Cabellos-Aparicio, D. Saucez, Ed.		C251272015-04-23
MISSREF*R(1G)		81.781.9draft-ietf-rtcweb-rtp-usage-26
C. Perkins, M. Westerlund, J. Ott		C238452015-07-01
MISSREF*R(1G)		59.161.1draft-ietf-bfcpbis-rfc4582bis-16
G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel		C272902015-11-23
MISSREF*R(1G)		42.058.1draft-ietf-avtcore-rtp-multi-stream-11
J. Lennox, M. Westerlund, Q. Wu, C. Perkins		C238272015-12-14
MISSREF*R(1G)		56.156.1draft-ietf-avtcore-multi-media-rtp-session-13
M. Westerlund, C. Perkins, J. Lennox		C238162015-12-28
MISSREF*R(1G)		55.055.1draft-ietf-lwig-cellular-06
J. Arkko, A. Eriksson, A. Keranen		C280162016-01-04
MISSREF*R(1G)		53.753.7draft-ietf-clue-framework-25
M. Duckworth, Ed., A. Pepperell, S. Wenger		C281842016-01-14
MISSREF*R(1G)		42.142.3draft-ietf-aqm-fq-codel-06
T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet		C288232016-04-03
MISSREF*R(1G)		31.736.7draft-ietf-rtcweb-alpn-04
M. Thomson		C23872016-05-12
MISSREF*R(1G)		27.928.0draft-ietf-mmusic-msid-15
H. Alvestrand		C238182016-07-12
MISSREF*R(1G)		23.724.9draft-ietf-avtext-splicing-notification-09
J. Xia, R. Even, R. Huang, L. Deng		C298212016-08-03
MISSREF*R(1G)		23.724.0draft-ietf-mmusic-mux-exclusive-10
C. Holmberg		C238122016-08-09
MISSREF*R(1G)		19.923.1draft-ietf-clue-data-model-schema-17
R. Presta, S. Pietro Romano		C281772016-08-15
MISSREF*R(1G)		22.122.1draft-ietf-tsvwg-rtcweb-qos-18
P. Jones, S. Dhesikan, C. Jennings, D. Druta		C238112016-08-22
MISSREF*R(1G)		16.717.0draft-ietf-pce-pcep-service-aware-13
D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki		C299302016-09-27
MISSREF*R(1G)		6.116.1draft-ietf-i2rs-protocol-security-requirements-17
S. Hares, D. Migault, J. Halpern		C279212016-10-03
MISSREF*R(1G)		13.113.9draft-ietf-avtext-rid-09
A. Roach, S. Nandakumar, P. Thatcher		C23892016-10-19
MISSREF*R(1G)		12.612.7draft-ietf-rtcweb-transports-17
H. Alvestrand		C238202016-10-27
MISSREF*R(1G)		6.16.9draft-ietf-i2rs-ephemeral-state-23
J. Haas, S. Hares		C279112016-12-07
MISSREF*R(1G)		3.05.0draft-ietf-mmusic-sdp-mux-attributes-16
S. Nandakumar		C238962016-12-20
MISSREF*R(1G)		4.64.6draft-ietf-ice-dualstack-fairness-07
P. Martinsen, T. Reddy, P. Patil		C238102016-12-23
MISSREF*R(1G)		1.92.1draft-ietf-sidr-bgpsec-pki-profiles-21
M. Reynolds, S. Turner, S. Kent		C306122017-01-09
MISSREF*A*R(1G)		0.90.9draft-ietf-sidr-bgpsec-protocol-22
M. Lepinski, Ed., K. Sriram, Ed.		C306442017-01-18
MISSREF*R(2G)		4.945.9draft-ietf-avtcore-rtp-multi-stream-optimisation-12
J. Lennox, M. Westerlund, Q. Wu, C. Perkins		C238182016-03-09
MISSREF*R(2G)		0.92.1draft-ietf-sidr-bgpsec-ops-16
R. Bush		C30692017-01-09
MISSREF*R(2G)		0.10.1draft-ietf-sidr-adverse-actions-04
S. Kent, D. Ma		C306252017-01-23
REF*R		12.056.1draft-ietf-netconf-call-home-17
K. Watsen		C279142015-12-28
IANA*A*R		0.18.1draft-ietf-cose-msg-24
J. Schaad		C2971212016-11-28


×
./index.html0000664000764400076440000012024413041750266012355 0ustar iustyiusty » RFC Editor

The RFC series

contains technical and organizational documents about the Internet, including the specifications and policy documents produced by four streams: the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), and Independent Submissions.

Browse the RFC Index

HTML (ascending) • HTML (descending) • TXT • XML
Note: These files are large.

Browse RFCs by Status

Internet Standard

Draft Standard • Proposed Standard

Best Current Practice

Informational • Experimental • Historic

Uncategorized (Early RFCs)

• • • • •

Official Internet Protocol Standards

RFC Status Changes


×
./update-package.include0000664000764400076440000000710413041750266014577 0ustar iustyiustydraft-ietf-rtcweb-data-channel-13.txt draft-ietf-rtcweb-data-protocol-09.txt draft-ietf-tsvwg-sctp-dtls-encaps-09.txt draft-ietf-rtcweb-rtp-usage-26.txt draft-ietf-bfcpbis-rfc4582bis-16.txt draft-ietf-avtcore-rtp-multi-stream-11.txt draft-ietf-netconf-call-home-17.txt draft-ietf-avtcore-multi-media-rtp-session-13.txt draft-ietf-clue-framework-25.txt draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt draft-ietf-rtcweb-alpn-04.txt draft-ietf-mmusic-msid-15.txt draft-ietf-avtext-splicing-notification-09.txt draft-ietf-mmusic-mux-exclusive-10.txt draft-ietf-clue-data-model-schema-17.txt draft-ietf-avtcore-rtp-circuit-breakers-18.txt draft-ietf-tsvwg-rtcweb-qos-18.txt draft-ietf-jose-cfrg-curves-06.txt draft-ietf-pce-pcep-service-aware-13.txt draft-ietf-tsvwg-gre-in-udp-encap-19.txt draft-ietf-avtext-rid-09.txt draft-ietf-rtcweb-transports-17.txt draft-ietf-netconf-restconf-18.txt draft-ietf-hip-rfc5206-bis-14.txt draft-ietf-hip-multihoming-12.txt draft-ietf-radext-ip-port-radius-ext-17.txt draft-ietf-mpls-rfc4379bis-09.txt draft-ietf-radext-datatypes-08.txt draft-ietf-cose-msg-24.txt draft-ietf-pals-rfc4447bis-05.txt draft-ietf-l3sm-l3vpn-service-model-19.txt draft-ietf-netconf-yang-patch-14.txt draft-ietf-appsawg-mdn-3798bis-16.txt draft-ietf-kitten-rfc6112bis-03.txt draft-ietf-nfsv4-scsi-layout-10.txt draft-ietf-eppext-keyrelay-12.txt draft-ietf-p2psip-share-10.txt draft-ietf-core-http-mapping-17.txt draft-ietf-justfont-toplevel-06.txt draft-ietf-6man-default-iids-16.txt draft-ietf-appsawg-file-scheme-16.txt draft-ietf-6lo-dispatch-iana-registry-07.txt draft-ietf-mmusic-sdp-mux-attributes-16.txt draft-ietf-straw-b2bua-rtcp-17.txt draft-ietf-kitten-pkinit-freshness-07.txt draft-ietf-curdle-dnskey-eddsa-03.txt draft-ietf-savi-mix-15.txt draft-ietf-dnsop-maintain-ds-06.txt draft-ietf-idr-deprecate-30-31-129-02.txt draft-ietf-idr-large-community-12.txt draft-ietf-sidr-bgpsec-pki-profiles-21.txt draft-ietf-avtext-avpf-ccm-layered-04.txt draft-ietf-sidr-origin-validation-signaling-11.txt draft-ietf-sidr-bgpsec-protocol-22.txt draft-ietf-rtgwg-rlfa-node-protection-13.txt draft-ietf-curdle-cms-chacha20-poly1305-06.txt draft-ietf-ipfix-mib-variable-export-10.txt draft-ietf-forces-interfelfb-06.txt draft-weis-gdoi-iec62351-9-10.txt draft-murchison-nntp-compress-06.txt draft-holmberg-dispatch-received-realm-12.txt draft-ietf-payload-rtp-howto-14.txt draft-ietf-rmcat-cc-requirements-09.txt draft-ietf-lisp-introduction-13.txt draft-ietf-aqm-ecn-benefits-08.txt draft-ietf-lwig-cellular-06.txt draft-ietf-aqm-fq-codel-06.txt draft-ietf-aqm-docsis-pie-02.txt draft-ietf-tsvwg-circuit-breaker-15.txt draft-ietf-i2rs-protocol-security-requirements-17.txt draft-ietf-aqm-pie-10.txt draft-ietf-lisp-crypto-10.txt draft-ietf-tsvwg-rfc5405bis-19.txt draft-ietf-httpauth-mutual-algo-07.txt draft-ietf-httpauth-extension-09.txt draft-ietf-lisp-lcaf-22.txt draft-ietf-6man-ipv6-mibs-obsolete-02.txt draft-ietf-i2rs-ephemeral-state-23.txt draft-ietf-taps-transports-14.txt draft-ietf-6lo-privacy-considerations-04.txt draft-ietf-siprec-callflows-08.txt draft-ietf-ice-dualstack-fairness-07.txt draft-ietf-httpauth-mutual-11.txt draft-ietf-sidr-bgpsec-ops-16.txt draft-ietf-dprive-dnsodtls-15.txt draft-ietf-tsvwg-diffserv-intercon-14.txt draft-ietf-ospf-ttz-06.txt draft-ietf-sidr-adverse-actions-04.txt draft-moriarty-pkcs5-v2dot1-04.txt draft-ieee-urn-03.txt draft-leiba-3967upd-downref-03.txt draft-wilde-json-seq-suffix-03.txt draft-adid-urn-03.txt draft-holmberg-dispatch-mcptt-rp-namespace-05.txt draft-iab-ccg-appoint-process-03.txt draft-iab-carisreport-02.txt draft-irtf-cfrg-eddsa-08.txt draft-farinacci-lisp-rig-05.txt ./draft-ietf-netconf-call-home-17.txt0000664000764400076440000007715512636266372016711 0ustar iustyiusty NETCONF Working Group K. Watsen Internet-Draft Juniper Networks Intended status: Standards Track December 22, 2015 Expires: June 24, 2016 NETCONF Call Home and RESTCONF Call Home draft-ietf-netconf-call-home-17 Abstract This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in this document contains placeholder references for this draft. Please apply the following replacement: o "XXXX" --> the assigned RFC value for this draft This document contains references to another draft in progress, both in the Normative References section, as well as in body text throughout. Please update the following reference to reflect its final RFC assignment: o draft-ietf-netconf-restconf Artwork in this document contains placeholder values for ports pending IANA assignment from "draft-ietf-netconf-call-home". Please apply the following replacements: o "PORT-X" --> the assigned port value for "netconf-ch-ssh" o "PORT-Y" --> the assigned port value for "netconf-ch-tls" o "PORT-Z" --> the assigned port value for "restconf-ch-tls" Watsen Expires June 24, 2016 [Page 1] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 24, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.4. Relation to RFC 4253 . . . . . . . . . . . . . . . . . . 5 1.5. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 5 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 6 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 3.2. Configuration Data Model . . . . . . . . . . . . . . . . 8 4. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 8 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 8 4.2. Configuration Data Model . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 Watsen Expires June 24, 2016 [Page 2] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. NETCONF Call Home supports both of the secure transports used by the NETCONF protocol [RFC6241], SSH and TLS. The NETCONF protocol's binding to SSH is defined in [RFC6242]. The NETCONF protocol's binding to TLS is defined in [RFC7589]. RESTCONF Call Home only supports TLS, the same as the RESTCONF protocol [draft-ietf-netconf-restconf]. The RESTCONF protocol's binding to TLS is defined in [draft-ietf-netconf-restconf]. The SSH protocol is defined in [RFC4253]. The TLS protocol is defined in [RFC5246]. Both the SSH and TLS protocols are layered on top of the TCP protocol, which is defined in [RFC793]. Both NETCONF Call Home and RESTCONF Call Home preserve all but one of the client/server roles in their respective protocol stacks, as compared to client initiated NETCONF and RESTCONF connections. The one and only role reversal that occurs is at the TCP layer; that is, which peer is the TCP-client and which is the TCP-server. For example, a network element is traditionally the TCP-server. However, when calling home, the network element becomes the TCP- client. The network element's secure transport layer roles (SSH- server, TLS-server) and its application layer roles (NETCONF-server, RESTCONF-server) both remain the same. Having consistency in both the secure transport layer (SSH, TLS) and application layer (NETCONF, RESTCONF) roles conveniently enables deployed network management infrastructure to support call home also. For instance, existing certificate chains and user authentication mechanisms are unaffected by call home. Watsen Expires June 24, 2016 [Page 3] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 1.1. Motivation Call home is generally useful for both the initial deployment and on- going management of networking elements. Here are some scenarios enabled by call home: o The network element may proactively call home after being powered on for the first time in order to register itself with its management system. o The network element may access the network in a way that dynamically assigns it an IP address, but does not register its assigned IP address to a mapping service (e.g., dynamic DNS). o The network element may be deployed behind a firewall that implements network address translation (NAT) for all internal network IP addresses. o The network element may be deployed behind a firewall that doesn't allow any management access to the internal network. o The network element may be configured in "stealth mode" and thus doesn't have any open ports for the management system to connect to. o The operator may prefer to have network elements initiate management connections, believing it is easier to secure one open port in the data center than to have an open port on each network element in the network. 1.2. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.3. Applicability Statement The techniques described in this document are suitable for network management scenarios such as the ones described in Section 1.1. However, these techniques are only defined for NETCONF Call Home and RESTCONF Call Home, as described in this document. The reason for this restriction is that different protocols have different security assumptions. The NETCONF and RESTCONF protocols require clients and servers to verify the identity of the other party. This requirement is specified for the NETCONF protocol in Watsen Expires June 24, 2016 [Page 4] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 Section 2.2 of [RFC6241], and is specified for the RESTCONF protocol in Sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). This contrasts with the base SSH and TLS protocols, which do not require programmatic verification of the other party (section 9.3.4 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). In such circumstances, allowing the SSH/TLS server to contact the SSH/TLS client would open new vulnerabilities. Any use of call home with SSH/TLS for purposes other than NETCONF or RESTCONF will need a thorough contextual risk assessment. A risk assessment for this RFC is in the Security Considerations section (Section 5). 1.4. Relation to RFC 4253 This document uses the SSH Transport Layer Protocol [RFC4253] with the exception that the statement "The client initiates the connection" made in Section 4 (Connection Setup) does not apply. Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 5). 1.5. The NETCONF/RESTCONF Convention Throughout the remainder of this document, the term "NETCONF/ RESTCONF" is used as an abbreviation in place of the text "the NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not intended to require or to imply that a client or server must implement both the NETCONF standard and the RESTCONF standard. 2. Solution Overview The diagram below illustrates call home from a protocol layering perspective: Watsen Expires June 24, 2016 [Page 5] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 NETCONF/RESTCONF NETCONF/RESTCONF Server Client | | | 1. TCP | |----------------------------------->| | | | | | 2. SSH/TLS | |<-----------------------------------| | | | | | 3. NETCONF/RESTCONF | |<-----------------------------------| | | Note: arrows point from the "client" to the "server" at each protocol layer This diagram makes the following points: 1. The NETCONF/RESTCONF server begins by initiating a TCP connection to the NETCONF/RESTCONF client. 2. Using this TCP connection, the NETCONF/RESTCONF client initiates a SSH/TLS session to the NETCONF/RESTCONF server. 3. Using this SSH/TLS session, the NETCONF/RESTCONF client initates a NETCONF/RESTCONF session to the NETCONF/RESTCONF server. 3. The NETCONF or RESTCONF Client The term "client" is defined in [RFC6241], Section 1.1 "client". In the context of network management, the NETCONF/RESTCONF client might be a network management system. 3.1. Protocol Operation C1 The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client MUST support accepting TCP connections on the IANA-assigned ports defined in Section 6, but MAY be configured to listen to a different port. C2 The NETCONF/RESTCONF client accepts an incoming TCP connection request and a TCP connection is established. Watsen Expires June 24, 2016 [Page 6] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 C3 Using this TCP connection, the NETCONF/RESTCONF client starts either the SSH-client [RFC4253] or the TLS-client [RFC5246] protocol. For example, assuming the use of the IANA-assigned ports, the SSH-client protocol is started when the connection is accepted on port PORT-X and the TLS-client protocol is started when the connection is accepted on either port PORT-Y or PORT-Z. C4 If using TLS, the NETCONF/RESTCONF client MUST advertise "peer_allowed_to_send", as defined by [RFC6520]. This is required so NETCONF/RESTCONF servers can depend on it being there for call home connections, when keep-alives are needed the most. C5 As part of establishing an SSH or TLS connection, the NETCONF/ RESTCONF client MUST validate the server's presented host key or certificate. This validation MAY be accomplished by certificate path validation or by comparing the host key or certificate to a previously trusted or "pinned" value. If a certificate is presented and it contains revocation checking information, the NETCONF/RESTCONF client SHOULD check the revocation status of the certificate. If it is determined that a certificate has been revoked, the client MUST immediately close the connection. C6 If certificate path validation is used, the NETCONF/RESTCONF client MUST ensure that the presented certificate has a valid chain of trust to a preconfigured issuer certificate, and that the presented certificate encodes an "identifier" [RFC6125] that the client had awareness of prior to the connection attempt. How identifiers are encoded in certificates MAY be determined by a policy associated with the certificate's issuer. For instance, a given issuer may be known to only sign IDevID certificates [Std-802.1AR-2009] having a unique identifier (e.g., serial number) in the X.509 certificate's "CommonName" field. C7 After the server's host key or certificate is validated, the SSH or TLS protocol proceeds as normal to establish a SSH or TLS connection. When performing client authentication with the NETCONF/RESTCONF server, the NETCONF/RESTCONF client MUST ensure to only use credentials that it had previously associated for the NETCONF/RESTCONF server's presented host key or server certificate. C8 Once the SSH or TLS connection is established, the NETCONF/ RESTCONF client starts either the NETCONF-client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] protocol. Assuming the use of the IANA-assigned ports, the NETCONF-client protocol is started when the connection is accepted on either port PORT-X or PORT-Y and the RESTCONF-client protocol is started when the connection is accepted on port PORT-Z. Watsen Expires June 24, 2016 [Page 7] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 3.2. Configuration Data Model How a NETCONF or RESTCONF client is configured is outside the scope of this document. For instance, such configuration might be used to enable listening for call home connections, configuring trusted certificate issuers, or configuring identifiers for expected connections. 4. The NETCONF or RESTCONF Server The term "server" is defined in [RFC6241], Section 1.1 "server". In the context of network management, the NETCONF/RESTCONF server might be a network element or a device. 4.1. Protocol Operation S1 The NETCONF/RESTCONF server initiates a TCP connection request to the NETCONF/RESTCONF client. The server MUST support connecting to one of the IANA-assigned ports defined in Section 6, but MAY be configured to connect to a different port. Using the IANA- assigned ports, the server connects to port PORT-X for NETCONF over SSH, port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF over TLS. S2 The TCP connection request is accepted and a TCP connection is established. S3 Using this TCP connection, the NETCONF/RESTCONF server starts either the SSH-server [RFC4253] or the TLS-server [RFC5246] protocol, depending on how it is configured. For example, assuming the use of the IANA-assigned ports, the SSH-server protocol is used after connecting to the remote port PORT-X and the TLS-server protocol is used after connecting to one of the remote ports PORT-Y or PORT-Z. S4 As part of establishing the SSH or TLS connection, the NETCONF/ RESTCONF server will send its host key or certificate to the client. If a certificate is sent, the server MUST also send all intermediate certificates leading up to a well known and trusted issuer. How to send a list of certificates is defined for SSH in [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. S5 Establishing an SSH or TLS session requires server authentication of client credentials in all cases except with RESTCONF, where some client authentication schemes occur after the secure transport connection (TLS) has been established. If transport Watsen Expires June 24, 2016 [Page 8] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 (SSH or TLS) level client authentication is required, and the client is unable to successfully authenticate itself to the server in an amount of time defined by local policy, the server MUST close the connection. S6 Once the SSH or TLS connection is established, the NETCONF/ RESTCONF server starts either the NETCONF-server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] protocol, depending on how it is configured. Assuming the use of the IANA-assigned ports, the NETCONF-server protocol is used after connecting to remote port PORT-X or PORT-Y, and the RESTCONF-server protocol is used after connecting to remote port PORT-Z. S7 If a persistent connection is desired, the NETCONF/RESTCONF server, as the connection initiator, SHOULD actively test the aliveness of the connection using a keep-alive mechanism. For TLS based connections, the NETCONF/RESTCONF server SHOULD send HeartbeatRequest messages, as defined by [RFC6520]. For SSH based connections, per Section 4 of [RFC4254], the NETCONF/ RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with a purposely nonexistent "request name" value (e.g., keepalive@ietf.org) and the "want reply" value set to '1'. 4.2. Configuration Data Model How a NETCONF or RESTCONF server is configured is outside the scope of this document. This includes configuration that might be used to specify hostnames, IP addresses, ports, algorithms, or other relevant parameters. That said, a YANG [RFC6020] model for configuring NETCONF and RESTCONF servers, including call home, is provided in [draft-ietf-netconf-server-model]. 5. Security Considerations The security considerations described in [RFC6242] and [RFC7589], and by extension [RFC4253], [RFC5246], and [draft-ietf-netconf-restconf] apply here as well. This RFC deviates from standard SSH and TLS usage by having the SSH/ TLS server initiate the underlying TCP connection. This reversal is incongruous with [RFC4253], which says "the client initiates the connection" and also [RFC6125], which says "the client MUST construct a list of acceptable reference identifiers, and MUST do so independently of the identifiers presented by the service." Risks associated with these variances are centered around server authentication and the inability for clients to compare an independently constructed reference identifier to one presented by Watsen Expires June 24, 2016 [Page 9] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 the server. To mitigate these risks, this RFC requires that the NETCONF/RESTCONF client validate the server's SSH host key or certificate, by certificate path validation to a preconfigured issuer certificate, or by comparing the host key or certificate to a previously trusted or "pinned" value. Furthermore, when a certificate is used, this RFC requires that the client be able to match an identifier encoded in the presented certificate with an identifier the client was preconfigured to expect (e.g., serial number). For cases when the NETCONF/RESTCONF server presents an X.509 certificate, NETCONF/RESTCONF clients should ensure that the preconfigured issuer certificate used for certificate path validation is unique to the manufacturer of the server. That is, the certificate should not belong to a 3rd-party certificate authority that might issue certificates for more than one manufacturer. This is especially important when a client authentication mechanism passing a shared secret (e.g., a password) to the server is used. Not doing so could otherwise lead to a case where the client sends the shared secret to another server that happens to have the same identity (e.g., serial number) as the server the client was configured to expect. Considerations not associated with server authentication follow next. Internet facing hosts running NETCONF or RESTCONF call home will be fingerprinted via scanning tools such as `zmap` [zmap]. Both SSH and TLS provide many ways in which a host can be fingerprinted. SSH and TLS servers are fairly mature and able to withstand attacks, but SSH and TLS clients may not be as robust. Implementers and deployments need to ensure that software update mechanisms are provided so that vulnerabilities can be fixed in a timely fashion. An attacker could launch a denial of service (DoS) attack on the NETCONF/RESTCONF client by having it perform computationally expensive operations, before deducing that the attacker doesn't possess a valid key. For instance, in TLS 1.3 [draft-ietf-tls-tls13], the ClientHello message contains a Key Share value based on an expensive asymmetric key operation. Common precautions mitigating DoS attacks are recommended, such as temporarily blacklisting the source address after a set number of unsuccessful login attempts. When using call home with the RESTCONF protocol, special care is required when using some HTTP authentication schemes, especially the Basic [RFC7617] and Digest [RFC7616] schemes, which convey a shared secret (e.g., a password). Implementations and deployments should be Watsen Expires June 24, 2016 [Page 10] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 sure to review the Security Considerations section in the RFC for any HTTP client authentication scheme used. 6. IANA Considerations This RFC requests that IANA assigns three TCP port numbers in the "Registered Port Numbers" range with the service names "netconf-ch- ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be the default ports for NETCONF Call Home and RESTCONF Call Home protocols. Below is the registration template following the rules in [RFC6335]. Service Name: netconf-ch-ssh Transport Protocol(s): TCP Assignee: IESG Contact: IETF Chair Description: NETCONF Call Home (SSH) Reference: RFC XXXX Port Number: PORT-X Service Name: netconf-ch-tls Transport Protocol(s): TCP Assignee: IESG Contact: IETF Chair Description: NETCONF Call Home (TLS) Reference: RFC XXXX Port Number: PORT-Y Service Name: restconf-ch-tls Transport Protocol(s): TCP Assignee: IESG Contact: IETF Chair Description: RESTCONF Call Home (TLS) Reference: RFC XXXX Port Number: PORT-Z 7. Acknowledgements The author would like to thank the following for lively discussions on list and in the halls (ordered by last name): Jari Arkko, Andy Bierman, Martin Bjorklund, Ben Campbell, Spencer Dawkins, Mehmet Ersue, Stephen Farrell, Wes Hardaker, Stephen Hanna, David Harrington, Jeffrey Hutzelman, Simon Josefsson, Radek Krejci, Suresh Krishnan, Barry Leiba, Alan Luchuk, Kathleen Moriarty, Mouse, Russ Mundy, Tom Petch, Peter Saint-Andre, Joseph Salowey, Juergen Schoenwaelder, Martin Stiemerling, Joe Touch, Hannes Tschofenig, Sean Turner, and Bert Wijnen. Watsen Expires June 24, 2016 [Page 11] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 8. References 8.1. Normative References [draft-ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ieft-netconf-restconf-04 (work in progress), 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, . [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, . Watsen Expires June 24, 2016 [Page 12] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, . [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015, . [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, September 1981, . 8.2. Informative References [draft-ietf-netconf-server-model] Watsen, K. and J. Schoenwaelder, "NETCONF Server Configuration Model", 2014, . [draft-ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", 2015, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Watsen Expires June 24, 2016 [Page 13] Internet-Draft NETCONF Call Home and RESTCONF Call Home December 2015 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, . [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, . [Std-802.1AR-2009] IEEE SA-Standards Board, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009, . [zmap] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMap: Fast Internet-Wide Scanning and its Security Applications", 2013, . In proceedings of the 22nd USENIX Security Symposium Author's Address Kent Watsen Juniper Networks EMail: kwatsen@juniper.net Watsen Expires June 24, 2016 [Page 14] ./draft-adid-urn-03.txt0000664000764400076440000002537213037477073014157 0ustar iustyiustyInternet Engineering Task Force (IETF) J. Wold Internet Draft Advertising Digital Identification Intended status: Informational January 17, 2017 Expires: July 17, 2017 Advertising Digital Identification (Ad-ID) URN Namespace Definition draft-adid-urn-03.txt Abstract Advertising Digital Identification (Ad-ID) Identifiers are used identifying Advertising Assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) "adid" for Ad-ID Identifiers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Wold Expires July 17, 2017 [Page 1] Internet-Draft Ad-ID URN Namespace Definition November 16, 2016 Table of Contents 1. Introduction...................................................2 2. URN Namespace Definition Template..............................2 3. Namespace Considerations.......................................5 4. Community Considerations.......................................6 5. Security Considerations........................................6 6. IANA Considerations............................................6 7. References.....................................................6 7.1. Normative References......................................6 7.2. Informative References....................................7 1. Introduction This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for Ad-ID Identifiers. Ad-ID is the industry standard for identifying advertising assets across all media platforms (over the air, on-line, over the top, mobile, place based). Ad-ID Identifiers are unique codes for each creative advertising asset. Those unique codes are applied to all media. Ad-ID Identifiers are an eleven character ASCII string except for High Definition (HD) or Three-Dimensional (3D) codes, which have an H or D in the 12th character. Ad-ID also provides descriptive metadata about the advertisement. The metadata includes the advertiser, brand, product, commercial title, product categorization, and other essential data about the advertisement. The metadata can be retrieved by using the unique code. [Ad-ID-INTRO] provides additional background information. 2. URN Namespace Definition Template The namespace definition according to the template in [RFC3406] is as follows: Namespace ID: Wold Expires July 17, 2017 [Page 2] Internet-Draft Ad-ID URN Namespace Definition November 16, 2016 adid Registration Information: Version 1 2016-03-22 Declared registrant of the namespace: Name: Advertising Digital Identification, LLC Address: Advertising Digital Identification, LLC 11020 David Taylor Drive, Suite 305 Charlotte, NC 28262-1103 USA Contact: URL: http://www.ad-id.org/contact Email: cs@ad-id.org Declaration of syntactic structure: The identifier structure is as follows: An Ad-ID Identifier consists of a unique eleven character string or a unique twelve character string (video codes only). This string is divided into three parts: 1. A four-character alphanumeric Company Prefix, not starting with "0" 2. A seven-character alphanumeric code 3. An optional one-character Video Format Identifier. H - High Definition D - Three-Dimensional Wold Expires July 17, 2017 [Page 3] Internet-Draft Ad-ID URN Namespace Definition November 16, 2016 The URN representation URN-ADID of an Ad-ID Identifier conforms to the syntax (expressed using ABNF (as specified in [RFC5234]) : URN-ADID = "urn:adid:" full-adid-identifier full-adid-identifier = full-adid-prefix full-adid-code [full-adid-suffix] full-adid-prefix = (ALPHA / %x31-39) 3*alphanum full-adid-code = 7*alphanum full-adid-suffix = "H" / "D" alphanum = ALPHA / DIGIT Examples: Standard Definition: urn:adid:ABCD0001000 High Definition: urn:adid:ABCD0001000H Relevant ancillary documentation: [SMPTERP2092-1] specifies Advertising Digital Identifier (Ad-ID) Representations. Identifier uniqueness considerations: The Registrar (Advertising Digital Identification, LLC) is responsible for managing the assignment of the Ad-ID Identifier and shall ensure the uniqueness by checking the identifier against the list of existing ids. Ad-ID assigns the identifier, adid, in such a way that the uniqueness of the 'adid' will be maintained. Furthermore, an Ad- ID Identifier is associated with a single URN-ADID. Identifier persistence considerations: The assignment process guarantees that 'adids' are not reassigned or reused and the binding between the id and its resource is permanent. By reference this URN namespace inherits those rules Process of identifier assignment: Wold Expires July 17, 2017 [Page 4] Internet-Draft Ad-ID URN Namespace Definition November 16, 2016 Ad-IDs are generated by Ad-ID's proprietary registration procedures. Process for identifier resolution: Ad-ID URNs are resolved via URN resolvers run under Ad-ID's responsibility. Rules for Lexical Equivalence: Lexical equivalence of URN-ADID is defined by case-insensitive string match. Conformance with URN Syntax: As specified above, the syntax of URN-ADID is a subset of the URN syntax specified in [RFC2141]. Validation mechanism: The validity of an URN-ADID can be checked using Ad-ID's web services. For more information on Ad-ID's web services, please refer to the following links: http://www.ad-id.org/user-support/faqs/faq-category/web-services http://www.ad-id.org/ad-id-web-services-api-guide Scope: Ad-ID Identifiers are centrally registered, globally unique identifiers of advertising assets, used worldwide. 3. Namespace Considerations Ad-ID Identifiers are intended for use in Internet applications, where URNs are routinely used to identify audiovisual resources. There is no direct mapping from Ad-ID Identifiers to existing URN namespaces Wold Expires July 17, 2017 [Page 5] Internet-Draft Ad-ID URN Namespace Definition November 16, 2016 4. Community Considerations The primary registrants of Ad-ID Identifiers are advertisers and agencies. Ad-ID Identifiers can be used by anyone to unambiguously identify advertising assets and retrieve underlying metadata. The primary benefits of its use are greater transparency and accountability in the advertising marketplace, help eliminate costly errors associated with the inconsistent use of advertising asset identifiers throughout the advertising supply chain, and enable more granular audience measurement across multiple platforms. 5. Security Considerations This document specifies the syntax of the Ad-ID-URN namespace and makes no security representations. Note however that failure to conform to the syntactic and lexical equivalence rules specified in [RFC3406] when using an Ad-ID Identifier as a criterion for accessing restricted resources can result in granting unauthorized access. 6. IANA Considerations This document defines a URN NID registration that is to be entered into the IANA registry of URN NIDs. It specifically requests the Ad-ID NID. 7. References 7.1. Normative References [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [SMPTERP2092-1] Society of Motion Picture and Television Engineers, "Advertising Digital Identifier (Ad-ID) Representations", SMPTE RP 2092-1:2015. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC5234] IETF. January 2008. Augmented BNF for Syntax Specifications: ABNF. Wold Expires July 17, 2017 [Page 6] Internet-Draft Ad-ID URN Namespace Definition November 16, 2016 7.2. Informative References [Ad-ID-INTRO] Ad-ID Identifiers are an eleven character ASCII string except for High Definition (HD) or Three-Dimensional (3D) codes, which have an H or D in the 12th character. Ad-ID may have Complimentary Definition Codes (CDC's), which are matching SD, HD and/or 3D codes where only the 12th character of the code varies. This only applies to Video codes. For example, a video with a standard format and high definition format would have a single code for each format. Standard: ABCD1234000 High Definition: ABCD1234000H More information: http://www.ad-id.org/how-it-works/ad-id-structure Advertising Digital Identification, http://www.ad-id.org/ Authors' Addresses Jarrett Wold. Advertising Digital Identification (Ad-ID) 708 Third Avenue, New York, NY 10017 Email: jwold@ad-id.org Wold Expires July 17, 2017 [Page 7] ./draft-ietf-kitten-pkinit-freshness-07.txt0000664000764400076440000003725612720675333020176 0ustar iustyiusty Kitten Working Group M. Short, Ed. Internet-Draft S. Moore Intended status: Standards Track P. Miller Expires: November 24, 2016 Microsoft Corporation May 23, 2016 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension draft-ietf-kitten-pkinit-freshness-07 Abstract This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension [RFC4556] to exchange an opaque data blob that a KDC can validate to ensure that the client is currently in possession of the private key during a PKINIT AS exchange. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 24, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Short, et al. Expires November 24, 2016 [Page 1] Internet-Draft PKINIT Freshness May 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Kerberos message flow using KRB_AS_REQ without pre- authentication . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Generation of KRB_AS_REQ Message . . . . . . . . . . . . 4 2.2. Generation of KRB_ERROR Message . . . . . . . . . . . . . 4 2.3. Generation of KRB_AS_REQ Message . . . . . . . . . . . . 4 2.4. Receipt of KRB_AS_REQ Message . . . . . . . . . . . . . . 4 2.5. Receipt of second KRB_ERROR Message . . . . . . . . . . . 5 3. PreAuthentication Data Types . . . . . . . . . . . . . . . . 5 4. Extended PKAuthenticator . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Interoperability Considerations . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Kerberos PKINIT extension [RFC4556] defines two schemes for using asymmetric cryptography in a Kerberos preauthenticator. One uses Diffie-Hellman key exchange and the other depends on public key encryption. The public key encryption scheme is less commonly used for two reasons: o Elliptic Curve Cryptography (ECC) Support for PKINIT [RFC5349] only specified Elliptic Curve Diffie-Hellman (ECDH) key agreement, so it cannot be used for public key encryption. o Public key encryption requires certificates with an encryption key, that is not deployed on many existing smart cards. In the Diffie-Hellman exchange, the client uses its private key only to sign the AuthPack structure (specified in Section 3.2.1 of [RFC4556]), that is performed before any traffic is sent to the KDC. Thus a client can generate requests with future times in the PKAuthenticator, and then send those requests at those future times. Unless the time is outside the validity period of the client's certificate, the KDC will validate the PKAuthenticator and return a TGT the client can use without possessing the private key. Short, et al. Expires November 24, 2016 [Page 2] Internet-Draft PKINIT Freshness May 2016 As a result, a client performing PKINIT with the Diffie-Hellman key exchange does not prove current possession of the private key being used for authentication. It proves only prior use of that key. Ensuring that the client has current possession of the private key requires that the signed PKAuthenticator data include information that the client could not have predicted. 1.1. Kerberos message flow using KRB_AS_REQ without pre-authentication Today, password-based AS exchanges [RFC4120] often begin with the client sending a KRB_AS_REQ without pre-authentication. When the principal requires pre-authentication, the KDC responds with a KRB_ERROR containing information needed to complete an AS exchange, such as the supported encryption types and salt values. This message flow is illustrated below: KDC Client <---- AS-REQ without pre-authentication KRB-ERROR ----> <---- AS-REQ AS-REP ----> <---- TGS-REQ TGS-REP ----> Figure 1 We can use a similar message flow with PKINIT, allowing the KDC to provide a token for the client to include in its KRB_AS_REQ to ensure that the PA_PK_AS_REQ [RFC4556] was not pregenerated. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Message Exchanges The following summarizes the message flow with extensions to [RFC4120] and [RFC4556] required to support a KDC-provided freshness token during the initial request for a ticket: 1. The client generates a KRB_AS_REQ as specified in Section 2.9.3 of [RFC4120] that contains no PA_PK_AS_REQ and includes a freshness token request. Short, et al. Expires November 24, 2016 [Page 3] Internet-Draft PKINIT Freshness May 2016 2. The KDC generates a KRB_ERROR as specified in Section 3.1.3 of [RFC4120] providing a freshness token. 3. The client receives the error as specified in Section 3.1.4 of [RFC4120], extracts the freshness token, and includes it as part of the KRB_AS_REQ as specified in [RFC4120] and [RFC4556]. 4. The KDC receives and validates the KRB_AS_REQ as specified in Section 3.2.2 of [RFC4556], then additionally validates the freshness token. 5. The KDC and client continue as specified in [RFC4120] and [RFC4556]. 2.1. Generation of KRB_AS_REQ Message The client indicates support of freshness tokens by adding a padata element with padata-type PA_AS_FRESHNESS and padata-value of an empty octet string. 2.2. Generation of KRB_ERROR Message The KDC will respond with a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_REQUIRED [RFC4120] adding a padata element with padata-type PA_AS_FRESHNESS and padata-value of the freshness token to the METHOD-DATA object. 2.3. Generation of KRB_AS_REQ Message After the client receives the KRB-ERROR message containing a freshness token, it extracts the PA_AS_FRESHNESS padata-value field of the PA-DATA structure as an opaque data blob. The PA_AS_FRESHNESS padata-value field of the PA-DATA structure SHALL then be added as an opaque blob in the freshnessToken field when the client generates the PKAuthenticator specified in Section 4 for the PA_PK_AS_REQ message. This ensures that the freshness token value will be included in the signed data portion of the KRB_AS_REQ value. 2.4. Receipt of KRB_AS_REQ Message If the realm requires freshness and the PA_PK_AS_REQ message does not contain the freshness token, the KDC MUST return a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_FAILED [RFC4120] with a padata element with padata-type PA_AS_FRESHNESS and padata-value of the freshness token to the METHOD-DATA object. When the PA_PK_AS_REQ message contains a freshness token, after validating the PA_PK_AS_REQ message normally, the KDC will validate Short, et al. Expires November 24, 2016 [Page 4] Internet-Draft PKINIT Freshness May 2016 the freshnessToken value in the PKAuthenticator in an implementation- specific way. If the freshness token is not valid, the KDC MUST return a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_EXPIRED [RFC6113]. The e-data field of the error contains a METHOD-DATA object [RFC4120] which specifies a valid PA_AS_FRESHNESS padata-value. Since the freshness tokens are validated by KDCs in the same realm, standardizing the contents of the freshness token is not a concern for interoperability. 2.5. Receipt of second KRB_ERROR Message If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it SHOULD retry using the new freshness token. 3. PreAuthentication Data Types The following are the new PreAuthentication data types: +----------------------+-------------------+ | Padata and Data Type | Padata-type Value | +----------------------+-------------------+ | PA_AS_FRESHNESS | 150 | +----------------------+-------------------+ 4. Extended PKAuthenticator Short, et al. Expires November 24, 2016 [Page 5] Internet-Draft PKINIT Freshness May 2016 The PKAuthenticator structure specified in Section 3.2.1 of [RFC4556] is extended to include a new freshnessToken as follows: PKAuthenticator ::= SEQUENCE { cusec [0] INTEGER (0..999999), ctime [1] KerberosTime, -- cusec and ctime are used as in [RFC4120], for -- replay prevention. nonce [2] INTEGER (0..4294967295), -- Chosen randomly; this nonce does not need to -- match with the nonce in the KDC-REQ-BODY. paChecksum [3] OCTET STRING OPTIONAL, -- MUST be present. -- Contains the SHA1 checksum, performed over -- KDC-REQ-BODY. ..., freshnessToken [4] OCTET STRING OPTIONAL, -- PA_AS_FRESHNESS padata value as recieved from the -- KDC. MUST be present if sent by KDC ... } 5. Acknowledgements Douglas E. Engert, Sam Hartman, Henry B. Hotz, Nikos Mavrogiannopoulos, Martin Rex, Nico Williams, and Tom Yu were key contributors to the discovery of the freshness issue in PKINIT. Sam Hartman, Greg Hudson, Jeffrey Hutzelman, Nathan Ide, Benjamin Kaduk, Bryce Nordgren, Magnus Nystrom, Nico Williams and Tom Yu reviewed the document and provided suggestions for improvements. 6. IANA Considerations IANA is requested to assign numbers for PA_AS_FRESHNESS listed in the Kerberos Parameters registry Pre-authentication and Typed Data as follows: +------+-----------------+------------+ | Type | Value | Reference | +------+-----------------+------------+ | 150 | PA_AS_FRESHNESS | [This RFC] | +------+-----------------+------------+ Short, et al. Expires November 24, 2016 [Page 6] Internet-Draft PKINIT Freshness May 2016 7. Security Considerations The freshness token SHOULD include signing, encrypting or sealing data from the KDC to determine authenticity and prevent tampering. Freshness tokens serve to guarantee that the client had the key when constructing the AS-REQ. They are not required to be single use tokens or bound to specific AS exchanges. Part of the reason the token is opaque is to allow KDC implementers the freedom to add additional functionality as long as the "freshness" guarantee remains. 8. Interoperability Considerations Since the client treats the KDC-provided data blob as opaque, changing the contents will not impact existing clients. Thus extensions to the freshness token do not impact client interoperability. Clients SHOULD NOT reuse freshness tokens across multiple exchanges. There is no guarantee that a KDC will allow a once-valid token to be used again. Thus clients that do not retry with a new freshness token may not be compatible with KDCs, depending on how they choose to implement freshness validation. Since upgrading clients takes time, implementers may consider allowing both freshness-token based exchanges and "legacy" exchanges without use of freshness tokens. However, until freshness tokens are required by the realm, the existing risks of pre-generated PKAuthenticators will remain. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, . [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, DOI 10.17487/RFC4556, June 2006, . Short, et al. Expires November 24, 2016 [Page 7] Internet-Draft PKINIT Freshness May 2016 [RFC5349] Zhu, L., Jaganathan, K., and K. Lauter, "Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 5349, DOI 10.17487/RFC5349, September 2008, . [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/RFC6113, April 2011, . Authors' Addresses Michiko Short (editor) Microsoft Corporation USA Email: michikos@microsoft.com Seth Moore Microsoft Corporation USA Email: sethmo@microsoft.com Paul Miller Microsoft Corporation USA Email: paumil@microsoft.com Short, et al. Expires November 24, 2016 [Page 8] ./draft-farinacci-lisp-rig-05.txt0000664000764400076440000005557712444047451016125 0ustar iustyiusty Internet Engineering Task Force D. Farinacci Internet-Draft lispers.net Intended status: Experimental A. Jain Expires: June 18, 2015 Juniper Networks I. Kouvelas D. Lewis cisco Systems December 15, 2014 LISP-DDT Referral Internet Groper (RIG) draft-farinacci-lisp-rig-05 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 18, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Farinacci, et al. Expires June 18, 2015 [Page 1] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Details . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 B.1. Changes to draft-farinacci-lisp-rig-05.txt . . . . . . . 10 B.2. Changes to draft-farinacci-lisp-rig-04.txt . . . . . . . 10 B.3. Changes to draft-farinacci-lisp-rig-03.txt . . . . . . . 11 B.4. Changes to draft-farinacci-lisp-rig-02.txt . . . . . . . 11 B.5. Changes to draft-farinacci-lisp-rig-01.txt . . . . . . . 11 B.6. Changes to draft-farinacci-lisp-rig-00.txt . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction LISP [RFC6830] specifies an architecture and mechanism for replacing the semantics of an address currently used by IP with two separate name spaces: Endpoint IDs (EIDs), used within sites, and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, the Locator/ID Separation Protocol (LISP) defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. This document focuses on the LISP-DDT [LISP-DDT] mapping database system. The 'rig' is a manual management tool to query LISP-DDT mapping database hierarchy. It can be run by all devices which implement LISP, including ITRs, ETRs, PITRs, PETRs, Map-Resolvers, Map-Servers, and LISP-DDT nodes, as well as by a host system at either a LISP- capable or non-LISP-capable site. Farinacci, et al. Expires June 18, 2015 [Page 2] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 The LISP-DDT 'rig' tool is similar to the 'lig' [RFC6835] tool in that they are both diagnostic tools to query a database. However, 'rig' is used to find Map-Servers serving an EID-prefix, specifically within a LISP-DDT mapping database framework. And 'lig' can be used on top of any mapping database system to retrieve locators used for packet encapsulation. 3. Definition of Terms Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value (or an address encoded by [LISP-LCAF]) used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called a "LEID". Throughout this document, any references to "EID" refers to an LEID. Extended EID (XEID): A LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where "private" address space is used. See "Using Virtualization and Segmentation with LISP" in [RFC6830] for more discussion of Instance IDs. Routing Locator (RLOC): A RLOC is an IPv4 [RFC0791] or IPv6 [RFC2460] address of an egress tunnel router (ETR). A RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically- aggregatable blocks that are assigned to a site at each point to Farinacci, et al. Expires June 18, 2015 [Page 3] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. DDT Node: A network infrastructure component responsible for specific XEID-prefix and for delegation of more-specific sub- prefixes to other DDT nodes. DDT Client: A network infrastructure component that sends Map- Request messages and implements the iterative following of Map- Referral results. Typically, a DDT client will be a Map Resolver but it is also possible for an ITR to implement DDT client functionality. A DDT client can be a device that is originating 'rig' requests. DDT Map Server: A DDT node that also implements Map Server functionality (forwarding Map-Requests and/or returning Map- Replies if offering proxy-mode service) for a subset of its delegated prefixes. DDT Map Resolver: A network infrastructure element that accepts a Map-Request, adds the XEID to its lookup queue, then queries one or more DDT nodes for the requested EID, following returned referrals until it receives one with the the ms-ack action. This indicates that the Map-Request has been sent to a Map-Server that will forward it to an ETR that, in turn, will provide a Map-Reply to the original sender. A DDT Map Resolver maintains both a cache of Map-Referral message results containing RLOCs for DDT nodes responsible for XEID-prefixes of interest (termed the "referral cache") plus a lookup queue of XEIDs that are being resolved through iterative querying of DDT nodes. Encapsulated Map-Request: A LISP Map-Request carried within an Encapsulated Control Message, which has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally-routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR as documented in [RFC6833]. Map-Referral: A LISP message sent by a DDT node when it receives a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. The Map-Referral message includes a "referral", a set of RLOCs for DDT nodes that have more information about the sub- prefix; a DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs to obtain either an answer or Farinacci, et al. Expires June 18, 2015 [Page 4] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 another referral to DDT nodes responsible for a more-specific XEID-prefix. Authoritative XEID-prefix: An XEID-prefix delegated to a DDT node and for which the DDT node may provide further delegations of more-specific sub-prefixes. 4. Basic Overview The LISP Delegated Database Tree [LISP-DDT], is 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. Map-Resolvers send Map-Requests to the DDT hierarchy and maintain referral-caches by receiving Map-Referral messages from DDT nodes. Map-Resolvers follow the DDT hierarchy for a given EID lookup based on the EID-prefix and delegation referrals contained in the Map- Referral messages. The intention of rig is to perform the same operation of a Map-Resolver but used as a management tool for the network administrator. When the rig command is run, an Encapsulated Control Message Map- Request is sent for a destination EID. When a LISP-DDT Map-Referral is returned, the contents are displayed to the user. The information displayed includes: o A delegated EID-prefix configured in a DDT-node or a configured site EID-prefix in a DDT Map-Server that matches the requested EID. o The type of DDT-node which sent the Map-Referral. o The action code and TTL set by the sender of the Map-Referral. o The referral RLOC addresses from the Map-Referral message. o A round-trip-time estimate for the ECM-Map-Request/Map-Referral message exchange. A possible syntax for a rig command MAY be: rig [instance-id ] to [follow-all-referrals] Farinacci, et al. Expires June 18, 2015 [Page 5] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 Parameter description: [instance-id >]: is the instance-ID portion of the Extended EID used as VPN identifier or for other future purposes. When the DDT hierarchy is not configured with instance-IDs, this argument is omitted from the command line. : is either a Fully Qualified Domain Name or a destination EID that is being queried in the LISP-DDT mapping database. : is the RLOC address of any DDT-node in the DDT hierarchy. This can be the DDT root node, a DDT transit node, or a DDT Map-Server. [follow-all-referrals]: when this keyword is used each referral RLOC is queried so rig can descend the entire DDT hierarchy starting from the node . When this keyword is not used, one of the referral RLOCs will be selected to descend a branch of the DDT hierarchy. The rig utility not only shows branches of the delegation hierarchy but can also report: o When a DDT Map-Server would forward a Map-Request to the ETRs at a registered LISP site. This is known as a 'ms-acknowledgement' action. o When a DDT Map-Server sends a negative referral indicating a requested EID is configured but not registered to the mapping database system. This is known as an 'ms-not-registered' action. o When a DDT node is sending referrals for a transit or leaf node in the hierarchy. These are known as 'node-referral' and 'ms- referral' actions, respectively. o When a DDT-node finds a hole in the address space that has not been allocated or configured in the delegation hierarchy. This is typically associated with a hole in a DDT node's configured authoritative prefix. This is known as a 'delegation-hole' action. o When a DDT-node finds a hole in the address space that has not been allocated or configured in the delegation hierarchy at all. This is typically associated with a hole that is outside of a DDT node's authoritative prefix. This is known as 'non-authoritative' action. Refer to [LISP-DDT] for more detail about Map-Referral actions. Farinacci, et al. Expires June 18, 2015 [Page 6] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 5. Implementation Details The cisco LISP prototype implementations on IOS and NX-OS has rig support for IPv4 and IPv6 EIDs in either the default instance or a non-zero instance-ID. The IOS syntax is: rig [instance-id ] to [follow-all-referrals] The NX-OS syntax is: rig [instance-id ] | { | }} to { | { | }} Here is some sample IOS output: Router# rig 12.0.1.1 to 1.1.1.1 Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms EID-prefix: [0] 12.0.0.0/16, ttl: 1440 referrals: 2.2.2.2 Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms EID-prefix: [0] 12.0.1.0/24, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Farinacci, et al. Expires June 18, 2015 [Page 7] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 Router# rig 12.0.1.1 to 1.1.1.1 follow-all-referrals Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms EID-prefix: [0] 12.0.0.0/16, ttl: 1440 referrals: 2.2.2.2 Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms EID-prefix: [0] 12.0.1.0/24, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Send Map-Request to DDT-node 5.5.5.5 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 No more referrals to pursue. Here is some sample NX-OS output: Router# rig 12.0.1.1 to 1.1.1.1 rig LISP-DDT hierarchy for EID [0] 12.0.1.1 Send Map-Request to DDT-node 1.1.1.1 ... replied, rtt: 0.003509 secs EID-prefix [0] *, ttl: 1440, action: node-referral, referrals: 2.2.2.2, priority/weight: 0/0 Send Map-Request to DDT-node 2.2.2.2 ... replied, rtt: 0.003173 secs EID-prefix [0] 12.0.0.0/20, ttl: 1440, action: node-referral, referrals: 3.3.3.3, priority/weight: 0/0 Send Map-Request to DDT-node 3.3.3.3 ... replied, rtt: 0.004145 secs EID-prefix [0] 12.0.1.0/24, ttl: 1440, action: node-referral, referrals: 5.5.5.5, priority/weight: 0/0 6.6.6.6, priority/weight: 0/0 Send Map-Request to DDT-node 6.6.6.6 ... replied, rtt: 0.005800 secs EID-prefix [0] 12.0.1.0/28, ttl: 1440, action: ms-ack, referrals: 5.5.5.5, priority/weight: 0/0 6.6.6.6, priority/weight: 0/0 Farinacci, et al. Expires June 18, 2015 [Page 8] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 6. Security Considerations The use of rig does not affect the security of the LISP infrastructure as it is simply a tool that facilities diagnostic querying. See [RFC6830], [LISP-DDT], [RFC6833], and [LISP-THREATS] for descriptions of the security properties of the LISP infrastructure. LISP rig provides easy access to the information in the public mapping database. Therefore, it is important to protect the mapping information for private use. This can be provided by disallowing access to specific mapping entries or to place such entries in a private mapping database system. 7. IANA Considerations This document makes no request of the IANA. 8. References 8.1. Normative References [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-04.txt (work in progress), September 2014. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013. Farinacci, et al. Expires June 18, 2015 [Page 9] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 8.2. Informative References [LISP-LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in progress), . [LISP-THREATS] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Threats Analysis", draft-ietf-lisp-threats-09.txt (work in progress), April 2014. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Appendix A. Acknowledgments The authors would like to thank Damien Saucez and Fabio Maino for their ideas and comments. Appreciation goes to Joel Halpern, Luigi Iannone, and Nevil Brownlee for progressing this document to Informational RFC. Appendix B. Document Change Log B.1. Changes to draft-farinacci-lisp-rig-05.txt o Draft posted December 2014. o Changes that reflect comments from Damien so we can move this draft to Informational RFC. B.2. Changes to draft-farinacci-lisp-rig-04.txt o Draft posted July 2014. o Added LISP-DDT basic operation description in the Basic Overview section. o Fix editorial comments from Luigi Iannone. Farinacci, et al. Expires June 18, 2015 [Page 10] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 B.3. Changes to draft-farinacci-lisp-rig-03.txt o Draft posted March 2014. o Resetting timer for expired draft. B.4. Changes to draft-farinacci-lisp-rig-02.txt o Draft posted September 2013. o Resetting timer for expired draft. o Update author affliations and reference RFCs. B.5. Changes to draft-farinacci-lisp-rig-01.txt o Draft posted March 2012. o Updated reference to LISP-DDT". B.6. Changes to draft-farinacci-lisp-rig-00.txt o Initial draft posted March 2012. Authors' Addresses Dino Farinacci lispers.net San Jose, California USA Phone: 408-718-2001 Email: farinacci@gmail.com Amit Jain Juniper Networks San Jose, California USA Email: atjain@juniper.net Farinacci, et al. Expires June 18, 2015 [Page 11] Internet-Draft LISP-DDT Referral Internet Groper (RIG) December 2014 Isidor Kouvelas cisco Systems Tasman Ave. San Jose, California USA Email: kouvelas@cisco.com Darrel Lewis cisco Systems Tasman Ave. San Jose, California USA Email: darlewis@cisco.com Farinacci, et al. Expires June 18, 2015 [Page 12] ./draft-ietf-curdle-cms-chacha20-poly1305-06.txt0000664000764400076440000004120613040155526020263 0ustar iustyiusty Internet-Draft R. Housley Intended status: Standards Track Vigil Security Expires: 19 July 2017 19 January 2017 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) Abstract This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 July 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 1] Internet-Draft 19 January 2017 1. Introduction This document specifies the conventions for using ChaCha20-Poly1305 Authenticated Encryption with the Cryptographic Message Syntax (CMS) [CMS] authenticated-enveloped-data content type [AUTHENV]. ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 2008. It is a refinement of Salsa20, which is one of the ciphers in the eSTREAM portfolio [ESTREAM]. ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key and a 96-bit nonce. [FORIETF] provides a detailed algorithm description, examples, and test vectors of ChaCha20. Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator designed by D. J. Bernstein. Poly1305 produces a 16-byte authentication tag; it requires a 256-bit, single-use key. [FORIETF] also provides a detailed algorithm description, examples, and test vectors of Poly1305. ChaCha20 and Poly1305 have been designed for high performance software implementations. They can typically be implemented with few resources and inexpensive operations, making them suitable on a wide range of systems. They have also been designed to minimize leakage of information through side channels. 1.1. The ChaCha20 and Poly1305 AEAD Construction ChaCha20 and Poly1305 have been combined to create an Authenticated Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is described [FORIETF]. AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, and an arbitrary length additional authenticated data (AAD). As the name implies, a nonce value cannot be used securely more than once with the same key. AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same length as the plaintext and a 128-bit authentication tag. AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar to the encryption processing. Of course, the roles of ciphertext and plaintext are reversed, so the ChaCha20 encryption function is applied to the ciphertext, producing the plaintext. The Poly1305 function is run over the AAD and the ciphertext, not the plaintext, and the resulting authentication tag is bitwise compared to the received authentication tag. The message is authenticated if and Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 2] Internet-Draft 19 January 2017 only if the calculated and received authentication tags match. 1.2. ASN.1 CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS]. 2. Key Management The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key destroys the security guarantees. It can be extremely difficult to use a statically configured AEAD_CHACHA20_POLY1305 key and never repeat a nonce value; however, the CMS authenticated-enveloped-data content type supports four key management techniques that allow a fresh AEAD_CHACHA20_POLY1305 key to be used as the content- authenticated-encryption key for a single protected content: Key Transport: the fresh content-authenticated-encryption key is encrypted in the recipient's public key; Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key- encryption key, then the fresh content-authenticated-encryption key is encrypted in the pairwise symmetric key; Symmetric Key-Encryption Keys: the fresh content-authenticated- encryption key is encrypted in a previously distributed symmetric key-encryption key; and Passwords: the fresh content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value. In addition to these four general key management techniques, CMS supports other key management techniques. See Section 6.2.5 of [CMS]. Since the properties of these key management techniques are unknown, no statement about their support of fresh content- authenticated-encryption keys can be made. Designers and implementers must perform their own analysis if one of these other key management techniques is supported. Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 3] Internet-Draft 19 January 2017 3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData This section specifies the conventions employed by CMS implementations that support the authenticated-enveloped-data content type and the AEAD_CHACHA20_POLY1305 algorithm. The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The AEAD_CHACHA20_POLY1305 algorithm is used to authenticate the attributes located in the AuthEnvelopedData authAttrs field, if any are present, encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field, and to provide the message authentication code (MAC) located in the AuthEnvelopedData mac field. The authenticated attributes are DER encoded to produce the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm. The ciphertext and the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 algorithm. Note that the MAC, which is called the authentication tag in [FORIETF], provides integrity protection for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent. Neither the plaintext content nor the optional AAD inputs need to be padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm. There is one algorithm identifier for the AEAD_CHACHA20_POLY1305 algorithm: id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) TBD1 } The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain a AEADChaCha20Poly1305Nonce: AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the CMS, the content-authenticated-encryption key is normally used for a single content. Within the scope of any content-authenticated- encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values. 4. S/MIME Capabilities Attribute Section 2.5.2 of RFC 5751 [MSG] defines the SMIMECapabilities Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 4] Internet-Draft 19 January 2017 attribute, which is used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. When constructing a CMS signed-data content type, compliant software MAY include the SMIMECapabilities signed attribute to announce support for the AEAD_CHACHA20_POLY1305 algorithm. The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305 algorithm MUST include the id-alg-AEADChaCha20Poly1305 object identifier in the capabilityID field and MUST omit the parameters field. The DER encoding of a SMIMECapability SEQUENCE is the same as the DER encoding of an AlgorithmIdentifier. The DER encoding for the AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in hexadecimal) is: 30 0c 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? {{{ Correct above after IANA assigns the object identifier. }}} 5. IANA Considerations IANA is requested to add the following entry in the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry: TBD1 id-alg-AEADChaCha20Poly1305 [This Document] IANA is requested to add the following entry in the SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry: TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document] 6. Security Considerations The CMS AuthEnvelopedData provides all of the tools needed to avoid reuse of the same nonce value under the same key. See the discussion in Section 2 of this document. RFC 7539 [FORIETF] describes the consequences of using a nonce value more than once: Consequences of repeating a nonce: If a nonce is repeated, then both the one-time Poly1305 key and the keystream are identical between the messages. This reveals the XOR of the plaintexts, because the XOR of the plaintexts is equal to the XOR of the ciphertexts. When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always the same size as the original plaintext. Some other mechanism needs to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 5] Internet-Draft 19 January 2017 of the size of the plaintext is a concern. The amount of encrypted data possible in a single invocation of AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of the size of the block counter field in the ChaCha20 block function. This gives a total of 247,877,906,880 octets, which likely to be sufficient to handle the size of any CMS content type. Note that ciphertext length field in the authentication buffer will accomodate 2^64 octets, which is much larger than necessary. The AEAD_CHACHA20_POLY1305 construction is a novel composition of ChaCha20 and Poly1305. A security analysis of this composition is given in [PROCTER]. Implementations must randomly generate content-authenticated- encryption keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area. 7. Acknowledgements Thanks to Jim Schaad, Daniel Migault, Stephen Farrell, Yoav Nir, and Niclas Comstedt for their review and insightful comments. 8. Normative References [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007. [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, May 2015. [MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 6] Internet-Draft 19 January 2017 [X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2015. [X690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2015. 9. Informative References [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 2008, . [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., Gilbert, H., Johansson, T., Parker, M., Preneel, B., Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio (rev. 1)", September 2008, . [POLY1305] Bernstein, D., "The Poly1305-AES message-authentication code.", March 2005, . [PROCTER] Procter, G., "A Security Analysis of the Composition of ChaCha20 and Poly1305", August 2014, . [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Recommendations for Security", BCP 106, RFC 4086, June 2005. Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 7] Internet-Draft 19 January 2017 Appendix: ASN.1 Module CMS-AEADChaCha20Poly1305 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) TBD2 } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS CONTENT-ENCRYPTION FROM AlgorithmInformation-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) }; -- EXPORTS All AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::= { cea-AEADChaCha20Poly1305, ... } cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= { IDENTIFIER id-alg-AEADChaCha20Poly1305 PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } } id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) TBD1 } AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) END Author's Address Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Housley Using AEAD_CHACHA20_POLY1305 with CMS [Page 8] ./draft-holmberg-dispatch-mcptt-rp-namespace-05.txt0000664000764400076440000002640213040341030021514 0ustar iustyiusty Network Working Group C. Holmberg Internet-Draft J. Axell Intended status: Informational Ericsson Expires: July 24, 2017 January 20, 2017 IANA Registration of New Session Initiation Protocol (SIP) Resource- Priority Namespace for Mission Critical Push To Talk service draft-holmberg-dispatch-mcptt-rp-namespace-05 Abstract This document creates an additional Session Initiation Protocol (SIP) Resource-Priority namespace to meet the requirements of the 3GPP defined Mission Critical Push To Talk, and places this namespace in the IANA registry. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 24, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Holmberg & Axell Expires July 24, 2017 [Page 1] Internet-Draft MCPTT R-P namespace January 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. New SIP Resource-Priority Namespaces Created . . . . . . . . 3 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 3.2. The MCPTT namespaces . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The Third Generation Partnership Project (3GPP) has defined a Mission Critical Push To Talk (MCPTT) over LTE service [TS.3GPP.22.179] . The MCPTT service supports an enhanced PTT service, suitable for mission critical scenarios, based upon 3GPP Evolved Packet System (EPS) services. The requirements for the MCPTT service defined within 3GPP can also form the basis for a non-mission critical Push To Talk (PTT) service. The MCPTT service is intended to support communication between several users (a group call), where each user can gain permission to talk in an arbitrated manner. However, the MCPTT service also supports private calls between pairs of users. MCPTT is primarily targeted to provide a professional Push To Talk service to e.g., public safety, transport companies, utilities or industrial and nuclear plants. In addition to this, a commercial PTT service for non-professional use (e.g., groups of people on holiday) may be delivered through an MCPTT system. Based on their operational model, the performance and MCPTT features in use vary per user organization, where functionality which is more mission critical specific (e.g., Imminent Peril Call) might not be available to commercial customers. The MCPTT service provides its users with different priorities for the access to network resources in order to provide means to prioritize between calls when resources are scarce. These priorities take into account among other things the priority and role of the caller, the priority and type of the group, and the situation in which the call is made. The SIP level call control procedures using these namespaces are specified in [TS.3GPP.24.379]. The namespaces defined here will Holmberg & Axell Expires July 24, 2017 [Page 2] Internet-Draft MCPTT R-P namespace January 2017 support a wide range of queuing options. The namespaces correspond to what can be supported over the 3GPP Rx interface, defined in [TS.3GPP.29.214]. The usage of the namespaces can be tailored to the needs of the operator. The mechanism to do this is to configure which values a specific user is allowed to use. This configuration is specified in [TS.3GPP.24.384]. High priority calls when there is danger of life, for either the public safety worker or any other human, need to be set up immediately and thus require preemption. Other calls may be less sensitive in call set-up time but have a high priority once established. For these calls a queueing mechanism is more appropriate. The MCPTT data transfer service currently under development can benefit from a queueing mechanism. Another example is video only calls that are not critical in call set-up time, but where keeping the call is important. This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the 3GPP defined Mission Critical Push To Talk, and places these namespaces in the IANA registry. 2. Applicability This document defines namespaces applicable for MCPTT services defined by 3GPP that use the network services of a 3GPP defined LTE network. The use of this namespace outside such networks is undefined. 3. New SIP Resource-Priority Namespaces Created 3.1. Introduction This document introduces the MCPTT namespaces mcpttp and mcpttq, the name coming from the 3GPP defined Mission Critical Push To Talk service. 3.2. The MCPTT namespaces The mcpttp namespace uses the priority levels listed below from lowest to highest priority. mcpttp.0 (lowest priority) mcpttp.1 mcpttp.2 mcpttp.3 mcpttp.4 mcpttp.5 Holmberg & Axell Expires July 24, 2017 [Page 3] Internet-Draft MCPTT R-P namespace January 2017 mcpttp.6 mcpttp.7 mcpttp.8 mcpttp.9 mcpttp.10 mcpttp.11 mcpttp.12 mcpttp.13 mcpttp.14 mcpttp.15 (highest priority) Intended algorithm for mcpttp is preemption. New Warning code: No. New SIP response code: No. The mcpttq namespace uses the priority levels listed below from lowest to highest priority. mcpttq.0 (lowest priority) mcpttq.1 mcpttq.2 mcpttq.3 mcpttq.4 mcpttq.5 mcpttq.6 mcpttq.7 mcpttq.8 mcpttq.9 mcpttq.10 mcpttq.11 mcpttq.12 mcpttq.13 mcpttq.14 mcpttq.15 (highest priority) Intended algorithm for mcpttq is queuing. New Warning code: No. New SIP response code: No. 4. Security Considerations This document does not have any impact on the security of the SIP MCPTT protocol. Its purpose is purely administrative in nature. Holmberg & Axell Expires July 24, 2017 [Page 4] Internet-Draft MCPTT R-P namespace January 2017 5. IANA Considerations Abiding by the rules established within [RFC4412] and [RFC7134] , this is an Informative RFC creating two new namespaces, their associated priority-values, and intended algorithms. 6. Acknowledgments The authors would like to thank Bob Fredericks, Baruh Hason, Mary Barnes and Keith Drage for comments and discussions. 7. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-dispatch-mcptt-rp-namespace-04. o - Editorial changes based on gen-art review. Renderin of authors name and address fixed. Changes from draft-holmberg-dispatch-mcptt-rp-namespace-03. o - Editorial changes based on sec- and opt- directorate reviews. Changes from draft-holmberg-dispatch-mcptt-rp-namespace-01. o - Removal of Conventions section. o - Editorial changes. Changes from draft-holmberg-dispatch-mcptt-rp-namespace-00. o - The two namespaces have been spelt out explicitly. o - The numbering of priority levels is changed from 1-16 to 0-15. o - Address of one author has changed. 8. Normative References [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, DOI 10.17487/RFC4412, February 2006, . [RFC7134] Rosen, B., "The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review"", RFC 7134, DOI 10.17487/RFC7134, March 2014, . Holmberg & Axell Expires July 24, 2017 [Page 5] Internet-Draft MCPTT R-P namespace January 2017 [TS.3GPP.22.179] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Mission Critical Push To Talk (MCPTT) over LTE; Stage 1", 3GPP TS 22.179 13.3.0, December 2015. [TS.3GPP.29.214] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Rx reference point;", 3GPP TS 29.314 13.7.0, September 2016. [TS.3GPP.24.379] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mission Critical Push To Talk (MCPTT) call control; Protocol specification;", 3GPP TS 24.379 13.2.0, September 2016. [TS.3GPP.24.384] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mission Critical Push To Talk (MCPTT) configuration management; Protocol specification", 3GPP TS 24.384 13.2.0, September 2016. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Joergen Axell Ericsson Groenlandsgatan 31 Stockholm 16480 Sweden Email: jorgen.axell@ericsson.com Holmberg & Axell Expires July 24, 2017 [Page 6] ./draft-ietf-curdle-dnskey-eddsa-03.txt0000664000764400076440000003414213025157761017217 0ustar iustyiusty Internet Engineering Task Force O. Sury Internet-Draft CZ.NIC Intended status: Standards Track R. Edmonds Expires: June 20, 2017 Fastly December 17, 2016 EdDSA for DNSSEC draft-ietf-curdle-dnskey-eddsa-03 Abstract This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 20, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Sury & Edmonds Expires June 20, 2017 [Page 1] Internet-Draft EdDSA for DNSSEC December 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . 2 4. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . 3 5. Algorithm Number for DS, DNSKEY and RRSIG Resource Records . 3 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6.1. Ed25519 Examples . . . . . . . . . . . . . . . . . . . . 3 6.2. Ed448 Examples . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction DNSSEC, which is broadly defined in [RFC4033], [RFC4034], and [RFC4035], uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently, the most popular signature algorithm in use is RSA. GOST ([RFC5933]) and NIST-specified elliptic curve cryptography ([RFC6605]) are also standardized. [I-D.irtf-cfrg-eddsa] describes the elliptic curve signature system EdDSA and recommends two curves, Ed25519 and Ed448. This document defines the use of DNSSEC's DS, DNSKEY, and RRSIG resource records (RRs) with a new signing algorithm, Edwards-curve Digital Signature Algorithm (EdDSA) using a choice of two instances: Ed25519 and Ed448. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. DNSKEY Resource Records An Ed25519 public key consists of a 32-octet value, which is encoded into the Public Key field of a DNSKEY resource record as a simple bit string. The generation of a public key is defined in Section 5.1.5 in [I-D.irtf-cfrg-eddsa]. Sury & Edmonds Expires June 20, 2017 [Page 2] Internet-Draft EdDSA for DNSSEC December 2016 An Ed448 public key consists of a 57-octet value, which is encoded into the Public Key field of a DNSKEY resource record as a simple bit string. The generation of a public key is defined in Section 5.2.5 in [I-D.irtf-cfrg-eddsa]. 4. RRSIG Resource Records An Ed25519 signature consists of a 64-octet value, which is encoded into the Signature field of an RRSIG resource record as a simple bit string. The Ed25519 signature algorithm is described in Section 5.1.6 and verification of the Ed25519 signature is described in Section 5.1.7 in [I-D.irtf-cfrg-eddsa]. An Ed448 signature consists of a 114-octet value, which is encoded into the Signature field of an RRSIG resource record as a simple bit string. The Ed448 signature algorithm is described in Section 5.2.6 and verification of the Ed448 signature is described in Section 5.2.7 in [I-D.irtf-cfrg-eddsa]. 5. Algorithm Number for DS, DNSKEY and RRSIG Resource Records The algorithm number associated with the use of Ed25519 in DS, DNSKEY and RRSIG resource records is TBD1. The algorithm number associated with the use of Ed448 in DS, DNSKEY and RRSIG resource records is TBD2. This registration is fully defined in the IANA Considerations section. 6. Examples 6.1. Ed25519 Examples Sury & Edmonds Expires June 20, 2017 [Page 3] Internet-Draft EdDSA for DNSSEC December 2016 This section needs an update after the algorithm number for Ed25519 is assigned. Private-key-format: v1.2 Algorithm: TBD1 (ED25519) PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI= example.com. 3600 IN DNSKEY 257 3 TBD1 ( l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= ) example.com. 3600 IN DS 3613 TBD1 2 ( 3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79 a304b ) example.com. 3600 IN MX 10 mail.example.com. example.com. 3600 IN RRSIG MX 3 3600 ( 1440021600 1438207200 3613 example.com. ( Edk+IB9KNNWg0HAjm7FazXyrd5m3Rk8zNZbvNpAcM+eysqcUOMIjWoevFkj H5GaMWeG96GUVZu6ECKOQmemHDg== ) This section needs an update after the algorithm number for Ed25519 is assigned. Private-key-format: v1.2 Algorithm: TBD1 (ED25519) PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY= example.com. 3600 IN DNSKEY 257 3 TBD1 ( zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= ) example.com. 3600 IN DS 35217 TBD1 2 ( 401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c 6614c ) example.com. 3600 IN MX 10 mail.example.com. example.com. 3600 IN RRSIG MX 3 3600 ( 1440021600 1438207200 35217 example.com. ( 5LL2obmzdqjWI+Xto5eP5adXt/T5tMhasWvwcyW4L3SzfcRawOle9bodhC+ oip9ayUGjY9T/rL4rN3bOuESGDA== ) 6.2. Ed448 Examples Sury & Edmonds Expires June 20, 2017 [Page 4] Internet-Draft EdDSA for DNSSEC December 2016 This section needs an update after the algorithm number for Ed448 is assigned. Private-key-format: v1.2 Algorithm: TBD2 (ED448) PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x 8wWbDDct/U3FhYWA example.com. 3600 IN DNSKEY 257 3 TBD2 ( 3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx 1FYYUcJKm1MDpJtIA ) example.com. 3600 IN DS 9713 TBD2 2 ( 6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2 b19c7 ) example.com. 3600 IN MX 10 mail.example.com. example.com. 3600 IN RRSIG MX 3 3600 ( 1440021600 1438207200 9713 example.com. ( Nmc0rgGKpr3GKYXcB1JmqqS4NYwhmechvJTqVzt3jR+Qy/lSLFoIk1L+9e3 9GPL+5tVzDPN3f9kAwiu8KCuPPjtl227ayaCZtRKZuJax7n9NuYlZJIusX0 SOIOKBGzG+yWYtz1/jjbzl5GGkWvREUCUA ) This section needs an update after the algorithm number for Ed448 is assigned. Private-key-format: v1.2 Algorithm: TBD2 (ED448) PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO 2BlZdz4hdSTkOdOA example.com. 3600 IN DNSKEY 257 3 TBD2 ( kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN Lp5HlHAMy12VoISsA ) example.com. 3600 IN DS 38353 TBD2 2 ( 645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba 28af4 ) example.com. 3600 IN MX 10 mail.example.com. example.com. 3600 IN RRSIG MX 3 3600 ( 1440021600 1438207200 38353 example.com. ( +JjANio/LIzp7osmMYE5XD3H/YES8kXs5Vb9H8MjPS8OAGZMD37+LsCIcjg 5ivt0d4Om/UaqETEAsJjaYe56CEQP5lhRWuD2ivBqE0zfwJTyp4WqvpULbp vaukswvv/WNEFxzEYQEIm9+xDlXj4pMAMA ) Sury & Edmonds Expires June 20, 2017 [Page 5] Internet-Draft EdDSA for DNSSEC December 2016 7. Acknowledgements Some of the material in this document is copied liberally from [RFC6605]. The authors of this document wish to thank Jan Vcelak, Pieter Lexis, Kees Monshouwer, Simon Josefsson, Paul Hoffman and others for a review of this document. 8. IANA Considerations This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following entries have been added to the registry: +--------------+---------------+---------------+ | Number | TBD1 | TBD2 | | Description | Ed25519 | Ed448 | | Mnemonic | ED25519 | ED448 | | Zone Signing | Y | Y | | Trans. Sec. | * | * | | Reference | This document | This document | +--------------+---------------+---------------+ * There has been no determination of standardization of the use of this algorithm with Transaction Security. 9. Security Considerations The security considerations of [I-D.irtf-cfrg-eddsa] and [RFC7748]are inherited in the usage of Ed25519 and Ed448 in DNSSEC. Ed25519 is intended to operate at around the 128-bit security level, and Ed448 at around the 224-bit security level. A sufficiently large quantum computer would be able to break both. Reasonable projections of the abilities of classical computers conclude that Ed25519 is perfectly safe. Ed448 is provided for those applications with relaxed performance requirements and where there is a desire to hedge against analytical attacks on elliptic curves. These assessments could, of course, change in the future if new attacks that work better than the ones known today are found. A private key used for a DNSSEC zone MUST NOT be used for any other purpose than for that zone. Otherwise cross-protocol or cross- application attacks are possible. Sury & Edmonds Expires June 20, 2017 [Page 6] Internet-Draft EdDSA for DNSSEC December 2016 10. References 10.1. Normative References [I-D.irtf-cfrg-eddsa] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 (work in progress), August 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . 10.2. Informative References [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 2010, . [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, . Sury & Edmonds Expires June 20, 2017 [Page 7] Internet-Draft EdDSA for DNSSEC December 2016 Authors' Addresses Ondrej Sury CZ.NIC Milesovska 1136/5 Praha 130 00 CZ Email: ondrej.sury@nic.cz Robert Edmonds Fastly Atlanta, Georgia US Email: edmonds@mycre.ws Sury & Edmonds Expires June 20, 2017 [Page 8] ./draft-holmberg-dispatch-received-realm-12.txt0000664000764400076440000006664113020617405020721 0ustar iustyiusty SIPCORE Working Group C. Holmberg Internet-Draft Ericsson Intended status: Standards Track J. Jiang Expires: June 6, 2017 China Mobile December 3, 2016 Session Initiation Protocol (SIP) Via header field parameter to indicate received realm draft-holmberg-dispatch-received-realm-12.txt Abstract This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "received-realm", which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received, using a network realm value associated with the adjacent network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 6, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Holmberg & Jiang Expires June 6, 2017 [Page 1] Internet-Draft received realm December 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Use-Case: Transit Network Application Services . . . . . 3 1.3. Use-Case: Transit Network Routing . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Via 'received-realm' header field parameter . . . . . . . . . 5 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Operator Identifier . . . . . . . . . . . . . . . . . . . 5 5.3. JWS Header . . . . . . . . . . . . . . . . . . . . . . . 5 5.4. JWS Payload . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. JWS Serialization . . . . . . . . . . . . . . . . . . . . 7 5.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.6.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 5.6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 7 5.7. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 8 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Behavior of a SIP entity acting as a network entry point 8 6.3. Behavior of a SIP entity consuming the received-network value . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. 'received-realm' Via header field parameter . . . . . . . 9 8.2. JSON Web Token Claims Registration . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction 1.1. General When Session Initiation Protocol (SIP) [RFC3261] sessions are established between networks belonging to different operators, or between interconnected networks belonging to the same operator (or enterprise), the SIP requests associated with the session might traverse transit networks. Holmberg & Jiang Expires June 6, 2017 [Page 2] Internet-Draft received realm December 2016 Such transit networks might provide different kinds of services. In order to provide such services, a transit network often needs to know to which operator (or enterprise) the adjacent upstream network from which the SIP session initiation request is received belongs. This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "received-realm", which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received, using a network realm value associated with the adjacent network. NOTE: As the adjacent network can be an enterprise network, an Inter Operator Identifier (IOI) cannot be used to identity the network, as IOIs are not defined for enterprise networks. The following sections describe use-cases where the information is needed. 1.2. Use-Case: Transit Network Application Services The 3rd Generation Partnership Project (3GPP) TS 23.228 [TS.3GPP.23.228] specifies how an IP Multimedia Subsystem (IMS) network can be used to provide transit functionality. An operator can use its IMS network to provide transit functionality e.g., to non-IMS customers, to enterprise networks, and to other network operators. The transit network operator can provide application services to the networks for which it is providing transit functionality. Transit application services are typically not provided on a per user basis, as the transit network does not have access to the user profiles of the networks for which the application services are provided. Instead, the application services are provided per served network. When a SIP entity that provides application services (e.g., an Application Server) within a transit network receives a SIP request, in order to apply the correct services, it needs to know the adjacent upstream network from which the SIP request is received. 1.3. Use-Case: Transit Network Routing A transit network operator normally interconnects to many different operators, including other transit network operators, and provides transit routing of SIP requests received from one operator network towards the destination. The destination can be within an operator network to which the transit network operator has a direct interconnect, or within an operator network that only can be reached via one or more interconnected transit operators. Holmberg & Jiang Expires June 6, 2017 [Page 3] Internet-Draft received realm December 2016 For each customer, i.e., interconnected network operator, for which the transit network operator routes SIP requests towards the requested destination, a set of transit routing polices are defined. These policies are used to determine how a SIP request shall be routed towards the requested destination to meet the agreement the transit network operator has with its customer. When a SIP entity that performs the transit routing functionality receives a SIP request, in order to apply the correct set of transit routing policies, it needs to know from which of its customers, i.e., adjacent upstream network, the SIP request is received. 2. Applicability The mechanism defined in this specification MUST only be used by SIP entities that are able to verify from which adjacent upstream network a SIP request is received. The mechanism for verifying from which adjacent upstream network a SIP request is received is outside the scope of this specification. Such mechanism might be based for instance on receiving the SIP request on an authenticated Virtual Private Network (VPN), receiving the SIP request on a specific IP address, or on a specific network access. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 4. Definitions SIP entity: SIP User Agent (UA), or SIP proxy, as defined in RFC 3261. Adjacent upstream SIP network: The adjacent SIP network in the direction from which a SIP request is received. Network entry point: A SIP entity on the border of network, which receives SIP requests from adjacent upstream networks. Inter Operator Identifier (IOI): A globally unique identifier to correlate billing information generated within the IP Multimedia Subsystem (IMS). JWS: JSON Web Signature, as defined in [RFC7515]. Holmberg & Jiang Expires June 6, 2017 [Page 4] Internet-Draft received realm December 2016 5. Via 'received-realm' header field parameter 5.1. General The Via 'received-realm' header field parameter value is represented as a combination of an operator identifier, whose value represents the adjacent network, and a serialized JSON Web Signature (JWS) [RFC7515]. The JWS Payload consists of the operator identifier and other SIP information element values. The procedures for encoding the JWS and calculating the signature are defined in [RFC7515]. As the JWS Payload information is found in other SIP information elements, the JWS Payload is detached from the serialized JWS conveyed in the header field parameter, as described in Appendix F of [RFC7515]. The operator identifier and the serialized JWS are separated using a colon character. 5.2. Operator Identifier The Operator Identifier is a token value that represents the adjacent operator. The scope of the value is only within the network that inserts the value. The Operator Identifier value is case-insensitive. 5.3. JWS Header The following header parameters MUST be included in the JWS. o The "typ" parameter MUST have a "JWT" value. o The "alg" parameter MUST have the value of the algorithm used to calculate the JWS. NOTE: Operators need to agree on the set of supported algorithms for calculating the JWT signature. NOTE: The "alg" parameter values for specific algorithms are listed in the IANA JSON Web Signature and Encryption Algorithms sub-registry of the JSON Object Signing and Encryption (JOSE) registry. Operators need to use algorithms for which an associated "alg" parameter value has been registered. The procedures for defining new values are defined in [RFC7518]. Holmberg & Jiang Expires June 6, 2017 [Page 5] Internet-Draft received realm December 2016 Example: { "typ":"JWT", "alg":"HS256" } 5.4. JWS Payload The following claims MUST be included in the JWS Payload: o The "sip_from_tag" claim has the value of the From 'tag' header field parameter of the SIP message. o The "sip_date" claim has the value of the Date header field in the SIP message, encoded in JSON NumericDate format [RFC7519]. o The "sip_callid" claim has have value of the Call-ID header field in the SIP message. o The "sip_cseq_num" claim has the numeric value of the CSeq header field in the SIP message. o the "sip_via_branch" claim has value of the Via branch header field parameter of the Via header field, in the SIP message, to which the received-realm header field parameter is attached. o the "sip_via_opid" claim has value of the operator identifier part of the Via received-realm header field parameter of the Via header field, in the SIP message, to which the received-realm header field parameter is attached. Example: { "sip_from_tag":"1928301774", "sip_date":1472815523, "sip_callid":"a84b4c76e66710@pc33.atlanta.com", "sip_cseq_num":"314159", "sip_via_branch":"z9hG4bK776asdhds", "sip_via_opid":"myoperator" } Holmberg & Jiang Expires June 6, 2017 [Page 6] Internet-Draft received realm December 2016 5.5. JWS Serialization As the JWS Payload is not carried in the received-realm parameter, in order to make sure that the sender and the receiver construct the JWS Payload object in the same way, the JSON representation of the JWS Payload object it MUST be computed as follows: o All claims MUST be encoded using lower case characters. o The claims MUST be in the same order as listed in [Section 5.4]. o All claims except "sip_date" MUST be encoded as StringOrURI JSON string value [RFC7519]. o The "sip_date" claim MUST be encoded as a JSON NumericDate value [RFC7519]. o The JWS Payload MUST follow the rules for the construction of the thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3 Step 1 only. Example: NOTE: Line breaks for display purpose only {"sip_from_tag":"1928301774","sip_date":1472815523, "sip_callid":"a84b4c76e66710@pc33.atlanta.com","sip_cseq_num":"314159", "sip_via_branch":"z9hG4bK776asdhds","sip_via_opid":"myoperator"} 5.6. Syntax 5.6.1. General This section describes the syntax extensions to the ABNF syntax defined in [RFC3261], by defining a new Via header field parameter, "received-realm". The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL", "LDQUOT", "RDQUOT" and "ALPHA" are defined in [RFC3261]. "DIGIT" is defined in [RFC5234]. 5.6.2. ABNF Holmberg & Jiang Expires June 6, 2017 [Page 7] Internet-Draft received realm December 2016 via-params =/ received-realm received-realm = "received-realm" EQUAL LDQUOT op-id COLON jws RDQUOT op-id = token jws = header ".." signature header = 1*base64-char signature = 1*base64-char base64-char = ALPHA / DIGIT / "/" / "+" EQUAL, COLON, token, LDQUOT, RDQUOT, ALPHA and DIGIT as defined in [RFC3261]. NOTE: The two adjacent dots in the jws part is due to the detached payload being replaced by an empty string [RFC7515]. 5.7. Example Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776; received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1N.. dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk" NOTE: Line breaks for display purpose only 6. User Agent and Proxy behavior 6.1. General This section describes how a SIP entity, acting as an entry point to a network, uses the "received-realm" Via header field parameter. 6.2. Behavior of a SIP entity acting as a network entry point When a SIP entity, acting as a network entry point, forwards a SIP request, or initiates a SIP request on its own (e.g., a PSTN gateway), the SIP entity adds a Via header field to the SIP request, according to the procedures in RFC 3261 [RFC3261]. In addition, if the SIP entity is able to assert the adjacent upstream network, and if the SIP entity is aware of a network realm value defined for that network, the SIP entity can add a "received-realm" Via header field parameter, conveying the network realm value as the operator identifier (Section 5.2) part of the header field parameter, to the Via header field added to the SIP request. In addition the SIP entity MUST also calculate a JWS (Section 5.4) and add the calculated JWS Header and JWS Signature as the jws part of the Via header field parameter. Holmberg & Jiang Expires June 6, 2017 [Page 8] Internet-Draft received realm December 2016 6.3. Behavior of a SIP entity consuming the received-network value When a SIP entity receives a Via 'received-network' header field parameter, and intends to perform actions based on the header field parameter value, it MUST first re-calculate the JWS and check whether the result matches the JWS received. If there is not a match, the SIP entity MUST discard the received 'received-network' header field parameter. The SIP entity MAY take also take additional actions (e.g., rejecting the SIP request) based on local policy. 7. Example Operator 1 T_EP T_AS - INVITE ------> Via: SIP/2.0/UDP IP_UA -- INVITE ----------------------------> Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776; received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW 1gFWFOEjXk" Via: SIP/2.0/UDP IP_UA; received=IP_UA <- 200 OK ---------------------------- Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776; received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW 1gFWFOEjXk" Via: SIP/2.0/UDP IP_UA; received=IP_UA <- 200 OK------ Via: SIP/2.0/UDP IP_UA; received=IP_UA 8. IANA Considerations 8.1. 'received-realm' Via header field parameter This specification defines a new Via header field parameter called received-realm in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by [RFC3968]. The syntax is defined in Section 5.6. The required information is: Holmberg & Jiang Expires June 6, 2017 [Page 9] Internet-Draft received realm December 2016 Predefined Header Field Parameter Name Values Reference ---------------------- --------------------- ---------- --------- Via received-realm No RFCXXXX 8.2. JSON Web Token Claims Registration This specification defines new JSON Web Token claims in the "JSON Web Token Claims" sub-registry as per the registry created by [RFC7519]. Claim Name: "sip_from_tag" Claim : SIP From tag header field parameter value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_date" Claim Description: SIP Date header field value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_callid" Claim Description: SIP Call-Id header field value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_cseq_num" Claim Description: SIP CSeq numeric header field parameter value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_via_branch" Claim Description: SIP Via branch header field parameter value Change Controller: IESG Holmberg & Jiang Expires June 6, 2017 [Page 10] Internet-Draft received realm December 2016 Specification Document(s): RFC XXXX, RFC 3261 9. Security Considerations As the received-realm Via header field parameter can be used to trigger applications, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity. The received-realm Via header field parameter is inserted, signed, verified and consumed within an operator network. The operator MUST discard parameters received from another network, and the parameter MUST only be inserted by SIP entities that are able to verify from which adjacent upstream network a SIP request is received. The operator also needs to take great care in ensuring that the key used to calculate the JWS signature value is only known by the network entities signing and adding the JWS signature to the received-realm Via header field parameter of a SIP message, and to network entities verifying and consuming the parameter value. The operator MUST use a key management policy that protects agains unauthorised access to the stored keys within nodes where they keys associated with the JWS signature are stored, and that protects against crypto analysis attacks using captured data sent on the wire. A SIP entity MUST NOT use the adjacent network information if there is a mismatch between the JWS signature received in the SIP header field and the JWS signature calculated by the receiving entity. Generic security considerations for JWS are defined in [RFC7515]. 10. Acknowledgments Thanks to Adam Roach and Richard Barnes for providing comments and feedback on the document. Francis Dupoint performed the Gen-ART review. 11. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-dispatch-received-realm-11 o Editorial change based on IESG review. Changes from draft-holmberg-dispatch-received-realm-10 o Changes based on IESG review. Holmberg & Jiang Expires June 6, 2017 [Page 11] Internet-Draft received realm December 2016 o Changes based on SecDIR review. o Changes based on IANA Service Operator review. Changes from draft-holmberg-dispatch-received-realm-09 o Reference to RFC 2104 removed. Changes from draft-holmberg-dispatch-received-realm-08 o Editorial fixed based on Gen-ART review. o Editorial fixes based on comments from IANA Service Operator review. o - Quotes removed from sip_date value. Changes from draft-holmberg-dispatch-received-realm-07 o Editorial changes. Changes from draft-holmberg-dispatch-received-realm-06 o Changes based on AD review by Ben Campbell: o - operator-id added to JSON Payload Changes from draft-holmberg-dispatch-received-realm-05 o Editorial fixes. Changes from draft-holmberg-dispatch-received-realm-04 o JSON serialization procedure added. Changes from draft-holmberg-dispatch-received-realm-03 o ABNF correction. Changes from draft-holmberg-dispatch-received-realm-02 o JWT replaced with JWS. o Appendix F of RFC 7515 applied. Changes from draft-holmberg-dispatch-received-realm-01 o Define received-realm parameter value as a JSON Web Token (JWT). Holmberg & Jiang Expires June 6, 2017 [Page 12] Internet-Draft received realm December 2016 Changes from draft-holmberg-dispatch-received-realm-00 o New version due to expiration of previous version. Changes from draft-holmberg-received-realm-04 o Changed IETF WG from sipcore do dispatch. o HMAC value added to the parameter. Changes from draft-holmberg-received-realm-03 o New version due to expiration. Changes from draft-holmberg-received-realm-02 o New version due to expiration. Changes from draft-holmberg-received-realm-01 o New version due to expiration. Changes from draft-holmberg-received-realm-00 o New version due to expiration. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Holmberg & Jiang Expires June 6, 2017 [Page 13] Internet-Draft received realm December 2016 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . 12.2. Informative References [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [TS.3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 14.1.0, September 2016. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Yi Jiang China Mobile No.32 Xuanwumen West Street Beijing Xicheng District 100053 P.R. China Email: jiangyi@chinamobile.com Holmberg & Jiang Expires June 6, 2017 [Page 14] ./draft-ietf-netconf-restconf-18.txt0000664000764400076440000074511713004452035016653 0ustar iustyiusty Network Working Group A. Bierman Internet-Draft YumaWorks Intended status: Standards Track M. Bjorklund Expires: April 30, 2017 Tail-f Systems K. Watsen Juniper Networks October 27, 2016 RESTCONF Protocol draft-ietf-netconf-restconf-18 Abstract This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bierman, et al. Expires April 30, 2017 [Page 1] Internet-Draft RESTCONF October 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.4. NETCONF Notifications . . . . . . . . . . . . . . . . 7 1.1.5. Terms . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.6. URI Template and Examples . . . . . . . . . . . . . . 10 1.1.7. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 10 1.2. Subset of NETCONF Functionality . . . . . . . . . . . . . 11 1.3. Data Model Driven API . . . . . . . . . . . . . . . . . . 11 1.4. Coexistence with NETCONF . . . . . . . . . . . . . . . . 12 1.5. RESTCONF Extensibility . . . . . . . . . . . . . . . . . 13 2. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 15 2.1. Integrity and Confidentiality . . . . . . . . . . . . . . 15 2.2. HTTPS with X.509v3 Certificates . . . . . . . . . . . . . 15 2.3. Certificate Validation . . . . . . . . . . . . . . . . . 15 2.4. Authenticated Server Identity . . . . . . . . . . . . . . 15 2.5. Authenticated Client Identity . . . . . . . . . . . . . . 16 3. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Root Resource Discovery . . . . . . . . . . . . . . . . . 17 3.2. RESTCONF Media Types . . . . . . . . . . . . . . . . . . 19 3.3. API Resource . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. {+restconf}/data . . . . . . . . . . . . . . . . . . 20 3.3.2. {+restconf}/operations . . . . . . . . . . . . . . . 20 3.3.3. {+restconf}/yang-library-version . . . . . . . . . . 21 3.4. Datastore Resource . . . . . . . . . . . . . . . . . . . 21 3.4.1. Edit Collision Prevention . . . . . . . . . . . . . . 22 3.5. Data Resource . . . . . . . . . . . . . . . . . . . . . . 23 3.5.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . 24 3.5.2. Entity-Tag . . . . . . . . . . . . . . . . . . . . . 24 3.5.3. Encoding Data Resource Identifiers in the Request URI 24 3.5.4. Default Handling . . . . . . . . . . . . . . . . . . 28 3.6. Operation Resource . . . . . . . . . . . . . . . . . . . 28 3.6.1. Encoding Operation Resource Input Parameters . . . . 29 3.6.2. Encoding Operation Resource Output Parameters . . . . 34 3.6.3. Encoding Operation Resource Errors . . . . . . . . . 36 3.7. Schema Resource . . . . . . . . . . . . . . . . . . . . . 37 3.8. Event Stream Resource . . . . . . . . . . . . . . . . . . 38 3.9. Errors YANG Data Template . . . . . . . . . . . . . . . . 39 4. RESTCONF Methods . . . . . . . . . . . . . . . . . . . . . . 39 4.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Bierman, et al. Expires April 30, 2017 [Page 2] Internet-Draft RESTCONF October 2016 4.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.4. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.4.1. Create Resource Mode . . . . . . . . . . . . . . . . 42 4.4.2. Invoke Operation Mode . . . . . . . . . . . . . . . . 44 4.5. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.6. PATCH . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.6.1. Plain Patch . . . . . . . . . . . . . . . . . . . . . 47 4.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.8. Query Parameters . . . . . . . . . . . . . . . . . . . . 49 4.8.1. The "content" Query Parameter . . . . . . . . . . . . 50 4.8.2. The "depth" Query Parameter . . . . . . . . . . . . . 51 4.8.3. The "fields" Query Parameter . . . . . . . . . . . . 51 4.8.4. The "filter" Query Parameter . . . . . . . . . . . . 52 4.8.5. The "insert" Query Parameter . . . . . . . . . . . . 53 4.8.6. The "point" Query Parameter . . . . . . . . . . . . . 54 4.8.7. The "start-time" Query Parameter . . . . . . . . . . 54 4.8.8. The "stop-time" Query Parameter . . . . . . . . . . . 55 4.8.9. The "with-defaults" Query Parameter . . . . . . . . . 55 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1. Request URI Structure . . . . . . . . . . . . . . . . . . 57 5.2. Message Encoding . . . . . . . . . . . . . . . . . . . . 58 5.3. RESTCONF Metadata . . . . . . . . . . . . . . . . . . . . 59 5.3.1. XML Metadata Encoding Example . . . . . . . . . . . . 60 5.3.2. JSON Metadata Encoding Example . . . . . . . . . . . 60 5.4. Return Status . . . . . . . . . . . . . . . . . . . . . . 61 5.5. Message Caching . . . . . . . . . . . . . . . . . . . . . 61 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1. Server Support . . . . . . . . . . . . . . . . . . . . . 62 6.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 62 6.3. Subscribing to Receive Notifications . . . . . . . . . . 64 6.3.1. NETCONF Event Stream . . . . . . . . . . . . . . . . 65 6.4. Receiving Event Notifications . . . . . . . . . . . . . . 65 7. Error Reporting . . . . . . . . . . . . . . . . . . . . . . . 67 7.1. Error Response Message . . . . . . . . . . . . . . . . . 68 8. RESTCONF Module . . . . . . . . . . . . . . . . . . . . . . . 70 9. RESTCONF Monitoring . . . . . . . . . . . . . . . . . . . . . 77 9.1. restconf-state/capabilities . . . . . . . . . . . . . . . 77 9.1.1. Query Parameter URIs . . . . . . . . . . . . . . . . 78 9.1.2. The "defaults" Protocol Capability URI . . . . . . . 78 9.2. restconf-state/streams . . . . . . . . . . . . . . . . . 79 9.3. RESTCONF Monitoring Module . . . . . . . . . . . . . . . 79 10. YANG Module Library . . . . . . . . . . . . . . . . . . . . . 83 10.1. modules-state/module . . . . . . . . . . . . . . . . . . 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 11.1. The "restconf" Relation Type . . . . . . . . . . . . . . 84 11.2. YANG Module Registry . . . . . . . . . . . . . . . . . . 84 11.3. Media Types . . . . . . . . . . . . . . . . . . . . . . 85 11.3.1. Media Type application/yang-data+xml . . . . . . . . 85 Bierman, et al. Expires April 30, 2017 [Page 3] Internet-Draft RESTCONF October 2016 11.3.2. Media Type application/yang-data+json . . . . . . . 86 11.4. RESTCONF Capability URNs . . . . . . . . . . . . . . . . 88 11.5. Registration of "restconf" URN sub-namespace . . . . . . 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 91 14.2. Informative References . . . . . . . . . . . . . . . . . 94 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 94 A.1. v17 to v18 . . . . . . . . . . . . . . . . . . . . . . . 94 A.2. v16 to v17 . . . . . . . . . . . . . . . . . . . . . . . 94 A.3. v15 to v16 . . . . . . . . . . . . . . . . . . . . . . . 95 A.4. v14 to v15 . . . . . . . . . . . . . . . . . . . . . . . 95 A.5. v13 - v14 . . . . . . . . . . . . . . . . . . . . . . . . 96 A.6. v12 - v13 . . . . . . . . . . . . . . . . . . . . . . . . 98 A.7. v11 - v12 . . . . . . . . . . . . . . . . . . . . . . . . 98 A.8. v10 - v11 . . . . . . . . . . . . . . . . . . . . . . . . 98 A.9. v09 - v10 . . . . . . . . . . . . . . . . . . . . . . . . 99 A.10. v08 - v09 . . . . . . . . . . . . . . . . . . . . . . . . 101 A.11. v07 - v08 . . . . . . . . . . . . . . . . . . . . . . . . 101 A.12. v06 - v07 . . . . . . . . . . . . . . . . . . . . . . . . 102 A.13. v05 - v06 . . . . . . . . . . . . . . . . . . . . . . . . 102 A.14. v04 - v05 . . . . . . . . . . . . . . . . . . . . . . . . 102 A.15. v03 - v04 . . . . . . . . . . . . . . . . . . . . . . . . 103 A.16. v02 - v03 . . . . . . . . . . . . . . . . . . . . . . . . 103 A.17. v01 - v02 . . . . . . . . . . . . . . . . . . . . . . . . 104 A.18. v00 - v01 . . . . . . . . . . . . . . . . . . . . . . . . 105 A.19. bierman:restconf-04 to ietf:restconf-00 . . . . . . . . . 106 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 106 Appendix C. Example YANG Module . . . . . . . . . . . . . . . . 106 C.1. example-jukebox YANG Module . . . . . . . . . . . . . . . 107 Appendix D. RESTCONF Message Examples . . . . . . . . . . . . . 112 D.1. Resource Retrieval Examples . . . . . . . . . . . . . . . 112 D.1.1. Retrieve the Top-level API Resource . . . . . . . . . 112 D.1.2. Retrieve The Server Module Information . . . . . . . 113 D.1.3. Retrieve The Server Capability Information . . . . . 115 D.2. Edit Resource Examples . . . . . . . . . . . . . . . . . 116 D.2.1. Create New Data Resources . . . . . . . . . . . . . . 116 D.2.2. Detect Resource Entity-Tag Change . . . . . . . . . . 117 D.2.3. Edit a Datastore Resource . . . . . . . . . . . . . . 118 D.2.4. Replace a Datastore Resource . . . . . . . . . . . . 119 D.2.5. Edit a Data Resource . . . . . . . . . . . . . . . . 120 D.3. Query Parameter Examples . . . . . . . . . . . . . . . . 120 D.3.1. "content" Parameter . . . . . . . . . . . . . . . . . 120 D.3.2. "depth" Parameter . . . . . . . . . . . . . . . . . . 124 D.3.3. "fields" Parameter . . . . . . . . . . . . . . . . . 127 D.3.4. "insert" Parameter . . . . . . . . . . . . . . . . . 128 D.3.5. "point" Parameter . . . . . . . . . . . . . . . . . . 129 Bierman, et al. Expires April 30, 2017 [Page 4] Internet-Draft RESTCONF October 2016 D.3.6. "filter" Parameter . . . . . . . . . . . . . . . . . 130 D.3.7. "start-time" Parameter . . . . . . . . . . . . . . . 131 D.3.8. "stop-time" Parameter . . . . . . . . . . . . . . . . 131 D.3.9. "with-defaults" Parameter . . . . . . . . . . . . . . 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 133 1. Introduction There is a need for standard mechanisms to allow Web applications to access the configuration data, state data, data-model-specific RPC operations, and event notifications within a networking device, in a modular and extensible manner. This document defines an HTTP [RFC7230] based protocol called RESTCONF, for configuring data defined in YANG version 1 [RFC6020] or YANG version 1.1 [RFC7950], using the datastore concepts defined in NETCONF [RFC6241]. NETCONF defines configuration datastores and a set of Create, Retrieve, Update, Delete (CRUD) operations that can be used to access these datastores. NETCONF also defines a protocol for invoking these operations. The YANG language defines the syntax and semantics of datastore content, configuration, state data, RPC operations, and event notifications. RESTCONF uses HTTP methods to provide CRUD operations on a conceptual datastore containing YANG-defined data, which is compatible with a server which implements NETCONF datastores. If a RESTCONF server is co-located with a NETCONF server, then there are protocol interactions with the NETCONF protocol, which are described in Section 1.4. The RESTCONF server MAY provide access to specific datastores using operation resources, as described in Section 3.6. The RESTCONF protocol does not specify any mandatory operation resources. The semantics of each operation resource determine if and how datastores are accessed. Configuration data and state data are exposed as resources that can be retrieved with the GET method. Resources representing configuration data can be modified with the DELETE, PATCH, POST, and PUT methods. Data is encoded with either XML [W3C.REC-xml-20081126] or JSON [RFC7159]. Data-model-specific RPC operations defined with the YANG "rpc" or "action" statements can be invoked with the POST method. Data-model- specific event notifications defined with the YANG "notification" statement can be accessed. Bierman, et al. Expires April 30, 2017 [Page 5] Internet-Draft RESTCONF October 2016 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1.1. NETCONF The following terms are defined in [RFC6241]: o candidate configuration datastore o configuration data o datastore o configuration datastore o running configuration datastore o startup configuration datastore o state data o user 1.1.2. HTTP The following terms are defined in [RFC3986]: o fragment o path o query The following terms are defined in [RFC7230]: o header field o message-body o request-line o request URI o status-line Bierman, et al. Expires April 30, 2017 [Page 6] Internet-Draft RESTCONF October 2016 The following terms are defined in [RFC7231]: o method o request o resource The following terms are defined in [RFC7232]: o entity-tag 1.1.3. YANG The following terms are defined in [RFC7950]: o action o container o data node o key leaf o leaf o leaf-list o list o mandatory node o ordered-by user o presence container o RPC operation o top-level data node 1.1.4. NETCONF Notifications The following terms are defined in [RFC5277]: o notification replay Bierman, et al. Expires April 30, 2017 [Page 7] Internet-Draft RESTCONF October 2016 1.1.5. Terms The following terms are used within this document: o API resource: the resource that models the RESTCONF root resource and the sub-resources to access YANG-defined content. It is defined with the YANG data template named "yang-api" in the "ietf-restconf" module. o client: a RESTCONF client o data resource: a resource that models a YANG data node. It is defined with YANG data definition statements. o datastore resource: the resource that models a programmatic interface using NETCONF datastore concepts. By default, RESTCONF methods access a unified view of the underlying datastore implementation on the server. It is defined as a sub-resource within the API resource. o edit operation: a RESTCONF operation on a data resource using either a POST, PUT, PATCH, or DELETE method. This is not the same as the NETCONF edit operation (i.e., one of the values for the "nc:operation" attribute: "create", "replace", "merge", "delete", or "remove"). o event stream resource: This resource represents an SSE (Server- Sent Events) event stream. The content consists of text using the media type "text/event-stream", as defined by the SSE [W3C.REC-eventsource-20150203] specification. Event stream contents are described in Section 3.8. o media-type: HTTP uses Internet media types [RFC2046] in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation. o NETCONF client: a client which implements the NETCONF protocol. Called "client" in [RFC6241]. o NETCONF server: a server which implements the NETCONF protocol. Called "server" in [RFC6241]. o operation: the conceptual RESTCONF operation for a message, derived from the HTTP method, request URI, header fields, and message-body. Bierman, et al. Expires April 30, 2017 [Page 8] Internet-Draft RESTCONF October 2016 o operation resource: a resource that models a data-model-specific operation, that is defined with a YANG "rpc" or "action" statement. It is invoked with the POST method. o patch: a PATCH method on the target datastore or data resource. The media type of the message-body content will identify the patch type in use. o plain patch: a specific media type for use with the PATCH method, defined in Section 4.6.1, that can be used for simple merge operations. It is specified by a request Content-Type of "application/yang-data+xml" or "application/yang-data+json". o query parameter: a parameter (and its value if any), encoded within the query component of the request URI. o resource type: one of the RESTCONF resource classes defined in this document. One of "api", "datastore", "data", "operation", "schema", or "event stream". o RESTCONF capability: An optional RESTCONF protocol feature supported by the server, which is identified by an IANA registered NETCONF Capability URI, and advertised with an entry in the "capability" leaf-list defined in Section 9.3. o RESTCONF client: a client which implements the RESTCONF protocol. o RESTCONF server: a server which implements the RESTCONF protocol. o retrieval request: a request using the GET or HEAD methods. o schema resource: a resource that used by the client to retrieve a YANG schema with the GET method. It has a representation with the media type "application/yang". o server: a RESTCONF server o stream list: the set of data resource instances that describe the event stream resources available from the server. This information is defined in the "ietf-restconf-monitoring" module as the "stream" list. It can be retrieved using the target resource "{+restconf}/data/ietf-restconf-monitoring:restconf-state/streams/ stream". The stream list contains information about each stream, such as the URL to retrieve the event stream data. o stream resource: An event stream resource. Bierman, et al. Expires April 30, 2017 [Page 9] Internet-Draft RESTCONF October 2016 o target resource: the resource that is associated with a particular message, identified by the "path" component of the request URI. o yang-data extension: A YANG external statement that conforms to the "yang-data" extension statement found in Section 8. The yang- data extension is used to define YANG data structures that are meant to be used as YANG data templates. These data structures are not intended to be implemented as part of a configuration datastore or as operational state within the server, so normal YANG data definition statements cannot be used. o YANG data template: a schema for modeling protocol message components as conceptual data structure using YANG. This allows the messages to be defined in an encoding-independent manner. Each YANG data template is defined with the "yang-data" extension, found in Section 8. Representations of instances conforming to a particular YANG data template can be defined for YANG. The XML representation is defined in YANG version 1.1 [RFC7950], and supported with the "application/yang-data+xml" media type. The JSON representation is defined in JSON Encoding of Data Modeled with YANG [RFC7951], and supported with the "application/ yang-data+json" media type. 1.1.6. URI Template and Examples Throughout this document, the URI template [RFC6570] syntax "{+restconf}" is used to refer to the RESTCONF root resource outside of an example. See Section 3.1 for details. For simplicity, all of the examples in this document use "/restconf" as the discovered RESTCONF API root path. Many of the examples throughout the document are based on the "example-jukebox" YANG module, defined in Appendix C.1. Many protocol header lines and message-body text within examples throughout the document are split into multiple lines for display purposes only. When a line ends with backslash ('\') as the last character, the line is wrapped for display purposes. It is to be considered to be joined to the next line by deleting the backslash, the following line break, and the leading whitespace of the next line. 1.1.7. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: Bierman, et al. Expires April 30, 2017 [Page 10] Internet-Draft RESTCONF October 2016 o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration data (read-write), "ro" state data (read-only), and "x" operation resource (executable) o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 1.2. Subset of NETCONF Functionality RESTCONF does not need to mirror the full functionality of the NETCONF protocol, but it does need to be compatible with NETCONF. RESTCONF achieves this by implementing a subset of the interaction capabilities provided by the NETCONF protocol, for instance, by eliminating datastores and explicit locking. RESTCONF uses HTTP methods to implement the equivalent of NETCONF operations, enabling basic CRUD operations on a hierarchy of conceptual resources. The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data resources represented by YANG data models. These basic edit operations allow the running configuration to be altered by a RESTCONF client. RESTCONF is not intended to replace NETCONF, but rather provide an HTTP interface that follows Representational State Transfer (REST) principles [rest-dissertation], and is compatible with the NETCONF datastore model. 1.3. Data Model Driven API RESTCONF combines the simplicity of the HTTP protocol with the predictability and automation potential of a schema-driven API. Knowing the YANG modules used by the server, a client can derive all management resource URLs and the proper structure of all RESTCONF requests and responses. This strategy obviates the need for responses provided by the server to contain Hypermedia as the Engine of Application State (HATEOAS) links, originally described in Roy Fielding's doctoral dissertation [rest-dissertation], because the client can determine the links it needs from the YANG modules. Bierman, et al. Expires April 30, 2017 [Page 11] Internet-Draft RESTCONF October 2016 RESTCONF utilizes the YANG Library [RFC7895] to allow a client to discover the YANG module conformance information for the server, in case the client wants to use it. The server can optionally support retrieval of the YANG modules it uses, as identified in its YANG library. See Section 3.7 for details. The URIs for data-model-specific RPC operations and datastore content are predictable, based on the YANG module definitions. The RESTCONF protocol operates on a conceptual datastore defined with the YANG data modeling language. The server lists each YANG module it supports using the "ietf-yang-library" YANG module, defined in [RFC7895]. The server MUST implement the "ietf-yang-library" module, which MUST identify all the YANG modules used by the server, in the "modules-state/module" list. The conceptual datastore contents, data-model-specific RPC operations and event notifications are identified by this set of YANG modules. The classification of data as configuration or non-configuration is derived from the YANG "config" statement. Data ordering behavior is derived from the YANG "ordered-by" statement. Non-configuration data is also called "state data". The RESTCONF datastore editing model is simple and direct, similar to the behavior of the :writable-running capability in NETCONF. Each RESTCONF edit of a data resource within the datastore resource is activated upon successful completion of the edit. 1.4. Coexistence with NETCONF RESTCONF can be implemented on a device that supports the NETCONF protocol. The following figure shows the system components if a RESTCONF server is co-located with a NETCONF server: +-----------+ +-----------------+ | Web app | <-------> | | +-----------+ RESTCONF | network device | | | +-----------+ | +-----------+ | | NETCONF | <-------> | | datastore | | | Client | NETCONF | | | | +-----------+ | +-----------+ | +-----------------+ Bierman, et al. Expires April 30, 2017 [Page 12] Internet-Draft RESTCONF October 2016 The following figure shows the system components if a RESTCONF server is implemented in a device that does not have a NETCONF server: +-----------+ +-----------------+ | Web app | <-------> | | +-----------+ RESTCONF | network device | | | +-----------------+ There are interactions between the NETCONF protocol and RESTCONF protocol related to edit operations. It is possible that locks are in use on a RESTCONF server, even though RESTCONF cannot manipulate locks. In such a case, the RESTCONF protocol will not be granted write access to data resources within a datastore. If the NETCONF server supports :writable-running, all edits to configuration nodes in {+restconf}/data are performed in the running configuration datastore. The URI template "{+restconf}" is defined in Section 1.1.6. Otherwise, if the device supports :candidate, all edits to configuration nodes in {+restconf}/data are performed in the candidate configuration datastore. The candidate MUST be automatically committed to running immediately after each successful edit. Any edits from other sources that are in the candidate datastore will also be committed. If a confirmed commit procedure is in progress by any NETCONF client, then any new commit will act as the confirming commit. If the NETCONF server is expecting a "persist-id" parameter to complete the confirmed commit procedure then the RESTCONF edit operation MUST fail with a "409 Conflict" status-line. There error-tag "in-use" is returned in this case. The error-tag value "resource-denied" is used in this case. If the NETCONF server supports :startup, the RESTCONF server MUST automatically update the non-volatile startup configuration datastore, after the running datastore has been altered as a consequence of a RESTCONF edit operation. If a datastore that would be modified by a RESTCONF operation has an active lock from a NETCONF client, the RESTCONF edit operation MUST fail with a "409 Conflict" status-line. There error-tag "in-use" is returned in this case. 1.5. RESTCONF Extensibility There are two extensibility mechanisms built into RESTCONF: o protocol version Bierman, et al. Expires April 30, 2017 [Page 13] Internet-Draft RESTCONF October 2016 o optional capabilities This document defines version 1 of the RESTCONF protocol. If a future version of this protocol is defined, then that document will specify how the new version of RESTCONF is identified. It is expected that a different RESTCONF root resource will be used which will be located using a different link relation (See Section 3.1). The server will advertise all protocol versions that it supports in its host-meta data. In this example, the server supports both RESTCONF version 1 and a fictitious version 2. The client might send: GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml The server might respond: HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn RESTCONF also supports a server-defined list of optional capabilities, which are listed by a server using the "ietf-restconf-monitoring" module defined in Section 9.3. This document defines several query parameters in Section 4.8. Each optional parameter has a corresponding capability URI defined in Section 9.1.1 that is advertised by the server if supported. The "capabilities" list can identify any sort of server extension. Currently this extension mechanism is used to identify optional query parameters that are supported, but it is not limited to that purpose. For example, the "defaults" URI defined in Section 9.1.2 specifies a mandatory URI identifying server defaults handling behavior. A new sub-resource type could be identified with a capability if it is optional to implement. Mandatory protocol features and new resource types require a new revision of the RESTCONF protocol. Bierman, et al. Expires April 30, 2017 [Page 14] Internet-Draft RESTCONF October 2016 2. Transport Protocol 2.1. Integrity and Confidentiality HTTP [RFC7230] is an application layer protocol that may be layered on any reliable transport-layer protocol. RESTCONF is defined on top of HTTP, but due to the sensitive nature of the information conveyed, RESTCONF requires that the transport-layer protocol provides both data integrity and confidentiality. A RESTCONF server MUST support the TLS protocol [RFC5246], and SHOULD adhere to [RFC7525]. The RESTCONF protocol MUST NOT be used over HTTP without using the TLS protocol. RESTCONF does not require a specific version of HTTP. However, it is RECOMMENDED that at least HTTP/1.1 [RFC7230] be supported by all implementations. 2.2. HTTPS with X.509v3 Certificates Given the nearly ubiquitous support for HTTP over TLS [RFC7230], RESTCONF implementations MUST support the "https" URI scheme, which has the IANA assigned default port 443. RESTCONF servers MUST present an X.509v3 based certificate when establishing a TLS connection with a RESTCONF client. The use of X.509v3 based certificates is consistent with NETCONF over TLS [RFC7589]. 2.3. Certificate Validation The RESTCONF client MUST either use X.509 certificate path validation [RFC5280] to verify the integrity of the RESTCONF server's TLS certificate, or match the server's TLS certificate with a certificate obtained by a trusted mechanism (e.g., a pinned certificate). If X.509 certificate path validation fails, and the presented X.509 certificate does not match a certificate obtained by a trusted mechanism, the connection MUST be terminated, as described in Section 7.2.1 of [RFC5246]. 2.4. Authenticated Server Identity The RESTCONF client MUST check the identity of the server according to Section 3.1 of [RFC2818]. Bierman, et al. Expires April 30, 2017 [Page 15] Internet-Draft RESTCONF October 2016 2.5. Authenticated Client Identity The RESTCONF server MUST authenticate client access to any protected resource. If the RESTCONF client is not authenticated, the server SHOULD send an HTTP response with "401 Unauthorized" status-line, as defined in Section 3.1 of [RFC7235]. The error-tag value "access-denied" is used in this case. To authenticate a client, a RESTCONF server SHOULD require TLS client certificate based authentication (Section 7.4.6 of [RFC5246]). If certificate based authentication is not feasible (e.g., because one cannot build the required PKI for clients) then an HTTP authentication MAY be used. In the latter case, one of the HTTP authentication schemes defined in the HTTP Authentication Scheme Registry (Section 5.1 in [RFC7235]) MUST be used. A server MAY also support the combination of both client certificates and an HTTP client authentication scheme, with the determination of how to process this combination left as an implementation decision. The RESTCONF client identity derived from the authentication mechanism used is hereafter known as the "RESTCONF username" and subject to the NETCONF Access Control Module (NACM) [RFC6536]. When a client certificate is presented, the RESTCONF username MUST be derived using the algorithm defined in Section 7 of [RFC7589]. For all other cases, when HTTP authentication is used, the RESTCONF username MUST be provided by the HTTP authentication scheme used. 3. Resources The RESTCONF protocol operates on a hierarchy of resources, starting with the top-level API resource itself (Section 3.1). Each resource represents a manageable component within the device. A resource can be considered as a collection of data and the set of allowed methods on that data. It can contain nested child resources. The child resource types and methods allowed on them are data-model- specific. A resource has a representation associated with a media type identifier, as represented by the "Content-Type" header field in the HTTP response message. A resource has one or more representations, each associated with a different media type. When a representation of a resource is sent in an HTTP message, the associated media type is given in the "Content-Type" header. A resource can contain zero or more nested resources. A resource can be created and deleted independently of its parent resource, as long as the parent resource exists. Bierman, et al. Expires April 30, 2017 [Page 16] Internet-Draft RESTCONF October 2016 The RESTCONF resources are accessed via a set of URIs defined in this document. The set of YANG modules supported by the server will determine the data model specific RPC operations, top-level data nodes, and event notification messages supported by the server. The RESTCONF protocol does not include a data resource discovery mechanism. Instead, the definitions within the YANG modules advertised by the server are used to construct an RPC operation or data resource identifier. 3.1. Root Resource Discovery In line with the best practices defined by [RFC7320], RESTCONF enables deployments to specify where the RESTCONF API is located. When first connecting to a RESTCONF server, a RESTCONF client MUST determine the root of the RESTCONF API. There MUST be exactly one "restconf" link relation returned by the device. The client discovers this by getting the "/.well-known/host-meta" resource ([RFC6415]) and using the element containing the "restconf" attribute : Example returning /restconf: The client might send: GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml The server might respond: HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn After discovering the RESTCONF API root, the client MUST use this value as the initial part of the path in the request URI, in any subsequent request for a RESTCONF resource. In this example, the client would use the path "/restconf" as the RESTCONF root resource. Example returning /top/restconf: Bierman, et al. Expires April 30, 2017 [Page 17] Internet-Draft RESTCONF October 2016 The client might send: GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml The server might respond: HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn In this example, the client would use the path "/top/restconf" as the RESTCONF root resource. The client can now determine the operation resources supported by the the server. In this example a custom "play" operation is supported: The client might send: GET /top/restconf/operations HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Cache-Control: no-cache Last-Modified: Sun, 22 Apr 2016 01:00:14 GMT Content-Type: application/yang-data+json { "operations" : { "example-jukebox:play" : [null] } } If the Extensible Resource Descriptor (XRD) contains more than one link relation, then only the relation named "restconf" is relevant to this specification. Note that any given endpoint (host:port) can only support one RESTCONF server, due to the root resource discovery mechanism. This limits the number of RESTCONF servers that can run concurrently on a host, since each server must use a different port. Bierman, et al. Expires April 30, 2017 [Page 18] Internet-Draft RESTCONF October 2016 3.2. RESTCONF Media Types The RESTCONF protocol defines two application specific media types to identify representations of data which conforms to the schema for a particular YANG construct. This document defines media types for XML and JSON serialization of YANG data. Other documents MAY define other media types for different serializations of YANG data. The "application/ yang-data+xml" media-type is defined in Section 11.3.1. The "application/yang-data+json" media-type is defined in Section 11.3.2. 3.3. API Resource The API resource contains the RESTCONF root resource for the RESTCONF datastore and operation resources. It is the top-level resource located at {+restconf} and has the media type "application/ yang-data+xml" or "application/yang-data+json". YANG Tree Diagram for an API Resource: +---- {+restconf} +---- data | ... +---- operations? | ... +--ro yang-library-version string The "yang-api" YANG data template is defined using the "yang-data" extension in the "ietf-restconf" module, found in Section 8. It specifies the structure and syntax of the conceptual child resources within the API resource. The API resource can be retrieved with the GET method. The {+restconf} root resource name used in responses representing the root of the "ietf-restconf" module MUST identify the "ietf-restconf" YANG module. For example, a request to GET the root resource "/restconf" in JSON format will return a representation of the API resource named "ietf-restconf:restconf". This resource has the following child resources: Bierman, et al. Expires April 30, 2017 [Page 19] Internet-Draft RESTCONF October 2016 +----------------------+--------------------------------+ | Child Resource | Description | +----------------------+--------------------------------+ | data | Contains all data resources | | operations | Data-model-specific operations | | yang-library-version | ietf-yang-library module date | +----------------------+--------------------------------+ RESTCONF API Resource 3.3.1. {+restconf}/data This mandatory resource represents the combined configuration and state data resources that can be accessed by a client. It cannot be created or deleted by the client. The datastore resource type is defined in Section 3.4. Example: This example request by the client would retrieve only the non- configuration data nodes that exist within the "library" resource, using the "content" query parameter (see Section 4.8.1). GET /restconf/data/example-jukebox:jukebox/library\ ?content=nonconfig HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+xml 42 59 374 3.3.2. {+restconf}/operations This optional resource is a container that provides access to the data-model-specific RPC operations supported by the server. The server MAY omit this resource if no data-model-specific RPC operations are advertised. Bierman, et al. Expires April 30, 2017 [Page 20] Internet-Draft RESTCONF October 2016 Any data-model-specific RPC operations defined in the YANG modules advertised by the server MUST be available as child nodes of this resource. The access point for each RPC operation is represented as an empty leaf. If an operation resource is retrieved, the empty leaf representation is returned by the server. Operation resources are defined in Section 3.6. 3.3.3. {+restconf}/yang-library-version This mandatory leaf identifies the revision date of the "ietf-yang-library" YANG module that is implemented by this server. Note that the revision date for the module version found in [RFC7895] is used. Example: GET /restconf/yang-library-version HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+xml \ 2016-06-21\ 3.4. Datastore Resource The "{+restconf}/data" subtree represents the datastore resource, which is a collection of configuration data and state data nodes. This resource type is an abstraction of the system's underlying datastore implementation. The client uses it to edit and retrieve data resources, as the conceptual root of all configuration and state data that is present on the device. Configuration edit transaction management and configuration persistence are handled by the server and not controlled by the Bierman, et al. Expires April 30, 2017 [Page 21] Internet-Draft RESTCONF October 2016 client. A datastore resource can be written directly with the POST and PATCH methods. Each RESTCONF edit of a datastore resource is saved to non-volatile storage by the server, if the server supports non-volatile storage of configuration data, as described in Section 1.4. If the datastore resource represented by the "{+restconf}/data" subtree is retrieved, then the datastore and its contents are returned by the server. The datastore is represented by a node named "data" in the "ietf-restconf" module namespace. 3.4.1. Edit Collision Prevention Two edit collision detection and prevention mechanisms are provided in RESTCONF for the datastore resource: a timestamp and an entity- tag. Any change to configuration data resources updates the timestamp and entity tag of the datastore resource. In addition, the RESTCONF server MUST return an error if the datastore is locked by an external source (e.g., NETCONF server). 3.4.1.1. Timestamp The last change time is maintained and the "Last-Modified" ([RFC7232], Section 2.2) header field is returned in the response for a retrieval request. The "If-Unmodified-Since" header field ([RFC7232], Section 3.4) can be used in edit operation requests to cause the server to reject the request if the resource has been modified since the specified timestamp. The server SHOULD maintain a last-modified timestamp for the datastore resource, defined in Section 3.4. This timestamp is only affected by configuration child data resources, and MUST NOT be updated for changes to non-configuration child data resources. Last- modified timestamps for data resources are discussed in Section 3.5. If the RESTCONF server is colocated with a NETCONF server, then the last-modified timestamp MUST be for the "running" datastore. Note that it is possible other protocols can cause the last-modified timestamp to be updated. Such mechanisms are out of scope for this document. 3.4.1.2. Entity-Tag The server MUST maintain a unique opaque entity-tag for the datastore resource and MUST return it in the "ETag" ([RFC7232], Section 2.3) header in the response for a retrieval request. The client MAY use an "If-Match" header in edit operation requests to cause the server Bierman, et al. Expires April 30, 2017 [Page 22] Internet-Draft RESTCONF October 2016 to reject the request if the resource entity-tag does not match the specified value. The server MUST maintain an entity-tag for the top-level {+restconf}/data resource. This entity-tag is only affected by configuration data resources, and MUST NOT be updated for changes to non-configuration data. Entity-tags for data resources are discussed in Section 3.5. Note that each representation (e.g., XML vs. JSON) requires a different entity-tag. If the RESTCONF server is colocated with a NETCONF server, then this entity-tag MUST be for the "running" datastore. Note that it is possible other protocols can cause the entity-tag to be updated. Such mechanisms are out of scope for this document. 3.4.1.3. Update Procedure Changes to configuration data resources affect the timestamp and entity-tag for that resource, any ancestor data resources, and the datastore resource. For example, an edit to disable an interface might be done by setting the leaf "/interfaces/interface/enabled" to "false". The "enabled" data node and its ancestors (one "interface" list instance, and the "interfaces" container) are considered to be changed. The datastore is considered to be changed when any top-level configuration data node is changed (e.g., "interfaces"). 3.5. Data Resource A data resource represents a YANG data node that is a descendant node of a datastore resource. Each YANG-defined data node can be uniquely targeted by the request-line of an HTTP method. Containers, leafs, leaf-list entries, list entries, anydata and anyxml nodes are data resources. The representation maintained for each data resource is the YANG defined subtree for that node. HTTP methods on a data resource affect both the targeted data node and all its descendants, if any. A data resource can be retrieved with the GET method. Data resources are accessed via the "{+restconf}/data" URI. This sub-tree is used to retrieve and edit data resources. Bierman, et al. Expires April 30, 2017 [Page 23] Internet-Draft RESTCONF October 2016 3.5.1. Timestamp For configuration data resources, the server MAY maintain a last- modified timestamp for the resource, and return the "Last-Modified" header field when it is retrieved with the GET or HEAD methods. The "Last-Modified" header field can be used by a RESTCONF client in subsequent requests, within the "If-Modified-Since" and "If-Unmodified-Since" header fields. If maintained, the resource timestamp MUST be set to the current time whenever the resource or any configuration resource within the resource is altered. If not maintained, then the resource timestamp for the datastore MUST be used instead. If the RESTCONF server is colocated with a NETCONF server, then the last-modified timestamp for a configuration data resource MUST represent the instance within the "running" datastore. This timestamp is only affected by configuration data resources, and MUST NOT be updated for changes to non-configuration data. 3.5.2. Entity-Tag For configuration data resources, the server SHOULD maintain a resource entity-tag for each resource, and return the "ETag" header field when it is retrieved as the target resource with the GET or HEAD methods. If maintained, the resource entity-tag MUST be updated whenever the resource or any configuration resource within the resource is altered. If not maintained, then the resource entity-tag for the datastore MUST be used instead. The "ETag" header field can be used by a RESTCONF client in subsequent requests, within the "If-Match" and "If-None-Match" header fields. This entity-tag is only affected by configuration data resources, and MUST NOT be updated for changes to non-configuration data. If the RESTCONF server is colocated with a NETCONF server, then the entity- tag for a configuration data resource MUST represent the instance within the "running" datastore. 3.5.3. Encoding Data Resource Identifiers in the Request URI In YANG, data nodes can be identified with an absolute XPath expression, defined in [XPath], starting from the document root to the target resource. In RESTCONF, URI-encoded path expressions are used instead. Bierman, et al. Expires April 30, 2017 [Page 24] Internet-Draft RESTCONF October 2016 A predictable location for a data resource is important, since applications will code to the YANG data model module, which uses static naming and defines an absolute path location for all data nodes. A RESTCONF data resource identifier is encoded from left to right, starting with the top-level data node, according to the "api-path" rule in Section 3.5.3.1. The node name of each ancestor of the target resource node is encoded in order, ending with the node name for the target resource. If a node in the path is defined in another module than its parent node, or its parent is the datastore, then the module name followed by a colon character (":") MUST be prepended to the node name in the resource identifier. See Section 3.5.3.1 for details. If a data node in the path expression is a YANG leaf-list node, then the leaf-list value MUST be encoded according to the following rules: o The identifier for the leaf-list MUST be encoded using one path segment [RFC3986]. o The path segment is constructed by having the leaf-list name, followed by an "=" character, followed by the leaf-list value. (e.g., /restconf/data/top-leaflist=fred). o The leaf-list value is specified as a string, using the canonical representation for the YANG data type. Any reserved characters MUST be percent-encoded, according to [RFC3986], section 2.1 and 2.5. o YANG 1.1 allows duplicate leaf-list values for non-configuration data. In this case there is no mechanism to specify the exact matching leaf-list instance. o The comma (',') character is percent-encoded [RFC3986], even though multiple key values are not possible for a leaf-list. This is more consistent and avoids special processing rules. If a data node in the path expression is a YANG list node, then the key values for the list (if any) MUST be encoded according to the following rules: o The key leaf values for a data resource representing a YANG list MUST be encoded using one path segment [RFC3986]. o If there is only one key leaf value, the path segment is constructed by having the list name, followed by an "=" character, followed by the single key leaf value. Bierman, et al. Expires April 30, 2017 [Page 25] Internet-Draft RESTCONF October 2016 o If there are multiple key leaf values, the path segment is constructed by having the list name, followed by the value of each leaf identified in the "key" statement, encoded in the order specified in the YANG "key" statement. Each key leaf value except the last one is followed by a comma character. o The key value is specified as a string, using the canonical representation for the YANG data type. Any reserved characters MUST be percent-encoded, according to [RFC3986], section 2.1 and 2.5. The comma (',') character MUST be percent-encoded if it is present in the key value. o All the components in the "key" statement MUST be encoded. Partial instance identifiers are not supported. o Missing key values are not allowed, so two consecutive commas are interpreted as a comma, followed by a zero-length string, followed by a comma. For example, "list1=foo,,baz" would be interpreted as a list named "list1" with 3 key values, and the second key value is a zero-length string. o Note that non-configuration lists are not required to define keys. In this case, a single list instance cannot be accessed. o The "list-instance" ABNF rule defined in Section 3.5.3.1 represents the syntax of a list instance identifier. Examples: container top { list list1 { key "key1 key2 key3"; ... list list2 { key "key4 key5"; ... leaf X { type string; } } } leaf-list Y { type uint32; } } For the above YANG definition, the container "top" is defined in the "example-top" YANG module, and a target resource URI for leaf "X" would be encoded as follows: Bierman, et al. Expires April 30, 2017 [Page 26] Internet-Draft RESTCONF October 2016 /restconf/data/example-top:top/list1=key1,key2,key3/\ list2=key4,key5/X For the above YANG definition, a target resource URI for leaf-list "Y" would be encoded as follows: /restconf/data/example-top:top/Y=instance-value The following example shows how reserved characters are percent- encoded within a key value. The value of "key1" contains a comma, single-quote, double-quote, colon, double-quote, space, and forward slash. (,'":" /). Note that double-quote is not a reserved character and does not need to be percent-encoded. The value of "key2" is the empty string, and the value of "key3" is the string "foo". Example URL: /restconf/data/example-top:top/list1=%2C%27"%3A"%20%2F,,foo 3.5.3.1. ABNF For Data Resource Identifiers The "api-path" Augmented Backus-Naur Form (ABNF) syntax is used to construct RESTCONF path identifiers. Note that this syntax is used for all resources, and the API path starts with the RESTCONF root resource. Data resources are required to be identified under the subtree "+{restconf}/data". An identifier is not allowed to start with the case-insensitive string "XML", according to YANG identifier rules. The syntax for "api-identifier" and "key-value" MUST conform to the JSON identifier encoding rules in Section 4 of [RFC7951]: The RESTCONF root resource path is required. Additional sub-resource identifiers are optional. The characters in a key value string are constrained, and some characters need to be percent-encoded, as described in Section 3.5.3. Bierman, et al. Expires April 30, 2017 [Page 27] Internet-Draft RESTCONF October 2016 api-path = root *("/" (api-identifier / list-instance)) root = string ;; replacement string for {+restconf} api-identifier = [module-name ":"] identifier module-name = identifier list-instance = api-identifier "=" key-value *("," key-value) key-value = string ;; constrained chars are percent-encoded string = identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") 3.5.4. Default Handling RESTCONF requires that a server report its default handling mode (see Section 9.1.2 for details). If the optional "with-defaults" query parameter is supported by the server, a client may use it to control retrieval of default values (see Section 4.8.9 for details). If a leaf or leaf-list is missing from the configuration and there is a YANG-defined default for that data resource, then the server MUST use the YANG-defined default as the configured value. If the target of a GET method is a data node that represents a leaf or leaf-list that has a default value, and the leaf or leaf-list has not been instantiated yet, the server MUST return the default value(s) that are in use by the server. In this case, the server MUST ignore its basic-mode, described in Section 4.8.9, and return the default value. If the target of a GET method is a data node that represents a container or list that has any child resources with default values, for the child resources that have not been given value yet, the server MAY return the default values that are in use by the server, in accordance with its reported default handing mode and query parameters passed by the client. 3.6. Operation Resource An operation resource represents an RPC operation defined with the YANG "rpc" statement or a data-model-specific action defined with a Bierman, et al. Expires April 30, 2017 [Page 28] Internet-Draft RESTCONF October 2016 YANG "action" statement. It is invoked using a POST method on the operation resource. An RPC operation is invoked as: POST {+restconf}/operations/ The field identifies the module name and rpc identifier string for the desired operation. For example, if "module-A" defined a "reset" rpc operation, then invoking the operation would be requested as follows: POST /restconf/operations/module-A:reset HTTP/1.1 Server: example.com An action is invoked as: POST {+restconf}/data// where contains the path to the data node where the action is defined, and is the name of the action. For example, if "module-A" defined a "reset-all" action in the container "interfaces", then invoking this action would be requested as follows: POST /restconf/data/module-A:interfaces/reset-all HTTP/1.1 Server: example.com If the RPC operation is invoked without errors, and if the "rpc" or "action" statement has no "output" section, the response message MUST NOT include a message-body, and MUST send a "204 No Content" status- line instead. All operation resources representing RPC operations supported by the server MUST be identified in the {+restconf}/operations subtree defined in Section 3.3.2. Operation resources representing YANG actions are not identified in this subtree since they are invoked using a URI within the {+restconf}/data subtree. 3.6.1. Encoding Operation Resource Input Parameters If the "rpc" or "action" statement has an "input" section then instances of these input parameters are encoded in the module namespace where the "rpc" or "action" statement is defined, in an XML element or JSON object named "input", which is in the module namespace where the "rpc" or "action" statement is defined. Bierman, et al. Expires April 30, 2017 [Page 29] Internet-Draft RESTCONF October 2016 If the "rpc" or "action" statement has an "input" section and the "input" object tree contains any child data nodes which are considered mandatory nodes, then a message-body MUST be sent by the client in the request. If the "rpc" or "action" statement has an "input" section and the "input" object tree does not contain any child nodes which are considered mandatory nodes, then a message-body MAY be sent by the client in the request. If the "rpc" or "action" statement has no "input" section, the request message MUST NOT include a message-body. Examples: The following YANG module is used for the RPC operation examples in this section. Bierman, et al. Expires April 30, 2017 [Page 30] Internet-Draft RESTCONF October 2016 module example-ops { namespace "https://example.com/ns/example-ops"; prefix "ops"; organization "Example, Inc."; contact "support at example.com"; description "Example Operations Data Model Module"; revision "2016-07-07" { description "Initial version."; reference "example.com document 3-3373"; } rpc reboot { input { leaf delay { units seconds; type uint32; default 0; } leaf message { type string; } leaf language { type string; } } } rpc get-reboot-info { output { leaf reboot-time { units seconds; type uint32; } leaf message { type string; } leaf language { type string; } } } } The following YANG module is used for the YANG action examples in this section. Bierman, et al. Expires April 30, 2017 [Page 31] Internet-Draft RESTCONF October 2016 module example-actions { yang-version 1.1; namespace "https://example.com/ns/example-actions"; prefix "act"; import ietf-yang-types { prefix yang; } organization "Example, Inc."; contact "support at example.com"; description "Example Actions Data Model Module"; revision "2016-07-07" { description "Initial version."; reference "example.com document 2-9973"; } revision "2016-03-10"; container interfaces { list interface { key name; leaf name { type string; } action reset { input { leaf delay { units seconds; type uint32; default 0; } } } action get-last-reset-time { output { leaf last-reset { type yang:date-and-time; mandatory true; } } } } } } RPC Input Example: Bierman, et al. Expires April 30, 2017 [Page 32] Internet-Draft RESTCONF October 2016 The client might send the following POST request message to invoke the "reboot" RPC operation: POST /restconf/operations/example-ops:reboot HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml 600 Going down for system maintenance en-US The server might respond: HTTP/1.1 204 No Content Date: Mon, 25 Apr 2016 11:01:00 GMT Server: example-server The same example request message is shown here using JSON encoding: POST /restconf/operations/example-ops:reboot HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-ops:input" : { "delay" : 600, "message" : "Going down for system maintenance", "language" : "en-US" } } Action Input Example: The client might send the following POST request message to invoke the "reset" action: POST /restconf/data/example-actions:interfaces/\ interface=eth0/reset HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml 600 The server might respond: Bierman, et al. Expires April 30, 2017 [Page 33] Internet-Draft RESTCONF October 2016 HTTP/1.1 204 No Content Date: Mon, 25 Apr 2016 11:01:00 GMT Server: example-server The same example request message is shown here using JSON encoding: POST /restconf/data/example-actions:interfaces/\ interface=eth0/reset HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-actions:input" : { "delay" : 600 } } 3.6.2. Encoding Operation Resource Output Parameters If the "rpc" or "action" statement has an "output" section then instances of these output parameters are encoded in the module namespace where the "rpc" or "action" statement is defined, in an XML element or JSON object named "output", which is in the module namespace where the "rpc" or "action" statement is defined. If the RPC operation is invoked without errors, and if the "rpc" or "action" statement has an "output" section and the "output" object tree contains any child data nodes which are considered mandatory nodes, then a response message-body MUST be sent by the server in the response. If the RPC operation is invoked without errors, and if the "rpc" or "action" statement has an "output" section and the "output" object tree does not contain any child nodes which are considered mandatory nodes, then a response message-body MAY be sent by the server in the response. The request URI is not returned in the response. Knowledge of the request URI may be needed to associate the output with the specific "rpc" or "action" statement used in the request. Examples: RPC Output Example: The "example-ops" YANG module defined in Section 3.6.1 is used for this example. Bierman, et al. Expires April 30, 2017 [Page 34] Internet-Draft RESTCONF October 2016 The client might send the following POST request message to invoke the "get-reboot-info" operation: POST /restconf/operations/example-ops:get-reboot-info HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: HTTP/1.1 200 OK Date: Mon, 25 Apr 2016 11:10:30 GMT Server: example-server Content-Type: application/yang-data+json { "example-ops:output" : { "reboot-time" : 30, "message" : "Going down for system maintenance", "language" : "en-US" } } The same response is shown here using XML encoding: HTTP/1.1 200 OK Date: Mon, 25 Apr 2016 11:10:30 GMT Server: example-server Content-Type: application/yang-data+xml 30 Going down for system maintenance en-US Action Output Example: The "example-actions" YANG module defined in Section 3.6.1 is used for this example. The client might send the following POST request message to invoke the "get-last-reset-time" action: POST /restconf/data/example-actions:interfaces/\ interface=eth0/get-last-reset-time HTTP/1.1 Host: example.com Accept: application/yang-data+json Bierman, et al. Expires April 30, 2017 [Page 35] Internet-Draft RESTCONF October 2016 The server might respond: HTTP/1.1 200 OK Date: Mon, 25 Apr 2016 11:10:30 GMT Server: example-server Content-Type: application/yang-data+json { "example-actions:output" : { "last-reset" : "2015-10-10T02:14:11Z" } } 3.6.3. Encoding Operation Resource Errors If any errors occur while attempting to invoke the operation or action, then an "errors" media type is returned with the appropriate error status. If the RPC operation input is not valid, or the RPC operation is invoked but errors occur, then a message-body MUST be sent by the server, containing an "errors" resource, as defined in Section 3.9. A detailed example of an operation resource error response can be found in Section 3.6.3. Using the "reboot" RPC operation from the example in Section 3.6.1, the client might send the following POST request message: POST /restconf/operations/example-ops:reboot HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml -33 Going down for system maintenance en-US The server might respond with an "invalid-value" error: HTTP/1.1 400 Bad Request Date: Mon, 25 Apr 2016 11:10:30 GMT Server: example-server Content-Type: application/yang-data+xml Bierman, et al. Expires April 30, 2017 [Page 36] Internet-Draft RESTCONF October 2016 protocol invalid-value /ops:input/ops:delay Invalid input parameter The same response is shown here in JSON encoding: HTTP/1.1 400 Bad Request Date: Mon, 25 Apr 2016 11:10:30 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-restconf:errors" : { "error" : [ { "error-type" : "protocol", "error-tag" : "invalid-value", "error-path" : "/example-ops:input/delay", "error-message" : "Invalid input parameter", } ] } } 3.7. Schema Resource The server can optionally support retrieval of the YANG modules it supports. If retrieval is supported, then the "schema" leaf MUST be present in the associated "module" list entry, defined in [RFC7895]. To retrieve a YANG module, a client first needs to get the URL for retrieving the schema, which is stored in the "schema" leaf. Note that there is no required structure for this URL. The URL value shown below is just an example. The client might send the following GET request message: GET /restconf/data/ietf-yang-library:modules-state/\ module=example-jukebox,2016-08-15/schema HTTP/1.1 Host: example.com Accept: application/yang-data+json Bierman, et al. Expires April 30, 2017 [Page 37] Internet-Draft RESTCONF October 2016 The server might respond: HTTP/1.1 200 OK Date: Thu, 11 Feb 2016 11:10:30 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-yang-library:schema" : "https://example.com/mymodules/example-jukebox/2016-08-15" } Next the client needs to retrieve the actual YANG schema. The client might send the following GET request message: GET https://example.com/mymodules/example-jukebox/\ 2016-08-15 HTTP/1.1 Host: example.com Accept: application/yang The server might respond: HTTP/1.1 200 OK Date: Thu, 11 Feb 2016 11:10:31 GMT Server: example-server Content-Type: application/yang module example-jukebox { // contents of YANG module deleted for this example... } 3.8. Event Stream Resource An "event stream" resource represents a source for system generated event notifications. Each stream is created and modified by the server only. A client can retrieve a stream resource or initiate a long-poll server sent event stream, using the procedure specified in Section 6.3. An event stream functions according to the NETCONF Notifications specification [RFC5277]. The available streams can be retrieved from the stream list, which specifies the syntax and semantics of the stream resources. Bierman, et al. Expires April 30, 2017 [Page 38] Internet-Draft RESTCONF October 2016 3.9. Errors YANG Data Template The "errors" YANG data template models a collection of error information that is sent as the message-body in a server response message, if an error occurs while processing a request message. It is not considered as a resource type because no instances can be retrieved with a GET request. The "ietf-restconf" YANG module contains the "yang-errors" YANG data template, that specifies the syntax and semantics of an "errors" container within a RESTCONF response. RESTCONF error handling behavior is defined in Section 7. 4. RESTCONF Methods The RESTCONF protocol uses HTTP methods to identify the CRUD operations requested for a particular resource. The following table shows how the RESTCONF operations relate to NETCONF protocol operations and for the NETCONF operation, the "nc:operation" attribute. +----------+-----------------------------------------------+ | RESTCONF | NETCONF | +----------+-----------------------------------------------+ | OPTIONS | none | | HEAD | none | | GET | , | | POST | (nc:operation="create") | | POST | invoke an RPC operation | | PUT | (nc:operation="create/replace") | | PATCH | (nc:operation="merge") | | DELETE | (nc:operation="delete") | +----------+-----------------------------------------------+ CRUD Methods in RESTCONF The "remove" edit operation attribute for the NETCONF RPC operation is not supported by the HTTP DELETE method. The resource must exist or the DELETE method will fail. The PATCH method is equivalent to a "merge" edit operation when using a plain patch (see Section 4.6.1); other media-types may provide more granular control. Access control mechanisms are used to limit what CRUD operations can be used. In particular, RESTCONF is compatible with the NETCONF Access Control Model (NACM) [RFC6536], as there is a specific mapping between RESTCONF and NETCONF operations. The resource path needs to Bierman, et al. Expires April 30, 2017 [Page 39] Internet-Draft RESTCONF October 2016 be converted internally by the server to the corresponding YANG instance-identifier. Using this information, the server can apply the NACM access control rules to RESTCONF messages. The server MUST NOT allow any RESTCONF operation for any resources that the client is not authorized to access. Implementation of all methods (except PATCH [RFC5789]) are defined in [RFC7231]. This section defines the RESTCONF protocol usage for each HTTP method. 4.1. OPTIONS The OPTIONS method is sent by the client to discover which methods are supported by the server for a specific resource (e.g., GET, POST, DELETE, etc.). The server MUST implement this method. The "Accept-Patch" header field MUST be supported and returned in the response to the OPTIONS request, as defined in [RFC5789]. 4.2. HEAD The RESTCONF server MUST support the HEAD method. The HEAD method is sent by the client to retrieve just the header fields (which contain the metadata for a resource) that would be returned for the comparable GET method, without the response message-body. It is supported for all resources that support the GET method. The request MUST contain a request URI that contains at least the root resource. The same query parameters supported by the GET method are supported by the HEAD method. The access control behavior is enforced as if the method was GET instead of HEAD. The server MUST respond the same as if the method was GET instead of HEAD, except that no response message-body is included. 4.3. GET The RESTCONF server MUST support the GET method. The GET method is sent by the client to retrieve data and metadata for a resource. It is supported for all resource types, except operation resources. The request MUST contain a request URI that contains at least the root resource. The server MUST NOT return any data resources for which the user does not have read privileges. If the user is not authorized to read the target resource, an error response containing a "401 Unauthorized" Bierman, et al. Expires April 30, 2017 [Page 40] Internet-Draft RESTCONF October 2016 status-line SHOULD be returned. The error-tag value "access-denied" is returned in this case. A server MAY return a "404 Not Found" status-line, as described in section 6.5.3 in [RFC7231]. The error- tag value "invalid-value" is returned in this case. If the user is authorized to read some but not all of the target resource, the unauthorized content is omitted from the response message-body, and the authorized content is returned to the client. If any content is returned to the client, then the server MUST send a valid response message-body. More than one element MUST NOT be returned for XML encoding. If multiple elements are sent in a JSON message-body, then they MUST be sent as a JSON array. In this case any timestamp or entity-tag returned in the response MUST be associated with the first element returned. If a retrieval request for a data resource representing a YANG leaf- list or list object identifies more than one instance, and XML encoding is used in the response, then an error response containing a "400 Bad Request" status-line MUST be returned by the server. The error-tag value "invalid-value" is used in this case. Note that a non-configuration list is not required to defined any keys. In this case, retrieval of a single list instance is not possible. If a retrieval request for a data resource represents an instance that does not exist, then an error response containing a "404 Not Found" status-line MUST be returned by the server. The error-tag value "invalid-value" is used in this case. If the target resource of a retrieval request is for an operation resource then a "405 Method Not Allowed" status-line MUST be returned by the server. The error-tag value "operation-not-supported" is used in this case. Note that the way that access control is applied to data resources may not be completely compatible with HTTP caching. The Last- Modified and ETag header fields maintained for a data resource are not affected by changes to the access control rules for that data resource. It is possible for the representation of a data resource that is visible to a particular client to be changed without detection via the Last-Modified or ETag values. Example: The client might request the response header fields for an XML representation of the a specific "album" resource: Bierman, et al. Expires April 30, 2017 [Page 41] Internet-Draft RESTCONF October 2016 GET /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:02:40 GMT Server: example-server Content-Type: application/yang-data+xml Cache-Control: no-cache ETag: "a74eefc993a2b" Last-Modified: Mon, 23 Apr 2016 11:02:14 GMT Wasting Light jbox:alternative 2011 Refer to Appendix D.1 for more resource retrieval examples. 4.4. POST The RESTCONF server MUST support the POST method. The POST method is sent by the client to create a data resource or invoke an operation resource. The server uses the target resource type to determine how to process the request. +-----------+------------------------------------------------+ | Type | Description | +-----------+------------------------------------------------+ | Datastore | Create a top-level configuration data resource | | Data | Create a configuration data child resource | | Operation | Invoke an RPC operation | +-----------+------------------------------------------------+ Resource Types that Support POST 4.4.1. Create Resource Mode If the target resource type is a datastore or data resource, then the POST is treated as a request to create a top-level resource or child resource, respectively. The message-body is expected to contain the content of a child resource to create within the parent (target resource). The message-body MUST contain exactly one instance of the Bierman, et al. Expires April 30, 2017 [Page 42] Internet-Draft RESTCONF October 2016 expected data resource. The data-model for the child tree is the subtree as defined by YANG for the child resource. The "insert" Section 4.8.5 and "point" Section 4.8.6 query parameters MUST be supported by the POST method for datastore and data resources. These parameters are only allowed if the list or leaf- list is ordered-by user. If the POST method succeeds, a "201 Created" status-line is returned and there is no response message-body. A "Location" header field identifying the child resource that was created MUST be present in the response in this case. If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "resource-denied" is used in this case. If the user is not authorized to create the target resource, an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is used in this case. A server MAY return a "404 Not Found" status-line, as described in section 6.5.3 in [RFC7231]. The error-tag value "invalid-value" is used in this case. All other error responses are handled according to the procedures defined in Section 7. Example: To create a new "jukebox" resource, the client might send: POST /restconf/data HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:jukebox" : {} } If the resource is created, the server might respond as follows: HTTP/1.1 201 Created Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Location: https://example.com/restconf/data/\ example-jukebox:jukebox Last-Modified: Mon, 23 Apr 2016 17:01:00 GMT ETag: "b3a3e673be2" Refer to Appendix D.2.1 for more resource creation examples. Bierman, et al. Expires April 30, 2017 [Page 43] Internet-Draft RESTCONF October 2016 4.4.2. Invoke Operation Mode If the target resource type is an operation resource, then the POST method is treated as a request to invoke that operation. The message-body (if any) is processed as the operation input parameters. Refer to Section 3.6 for details on operation resources. If the POST request succeeds, a "200 OK" status-line is returned if there is a response message-body, and a "204 No Content" status-line is returned if there is no response message-body. If the user is not authorized to invoke the target operation, an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is used in this case. A server MAY return a "404 Not Found" status-line, as described in section 6.5.3 in [RFC7231]. All other error responses are handled according to the procedures defined in Section 7. Example: In this example, the client is invoking the "play" operation defined in the "example-jukebox" YANG module. A client might send a "play" request as follows: POST /restconf/operations/example-jukebox:play HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:input" : { "playlist" : "Foo-One", "song-number" : 2 } } The server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2016 17:50:00 GMT Server: example-server 4.5. PUT The RESTCONF server MUST support the PUT method. The PUT method is sent by the client to create or replace the target data resource. A request message-body MUST be present, representing the new data Bierman, et al. Expires April 30, 2017 [Page 44] Internet-Draft RESTCONF October 2016 resource, or the server MUST return "400 Bad Request" status-line. The error-tag value "invalid-value" is used in this case. Both the POST and PUT methods can be used to create data resources. The difference is that for POST, the client does not provide the resource identifier for the resource that will be created. The target resource for the POST method for resource creation is the parent of the new resource. The target resource for the PUT method for resource creation is the new resource. The PUT method MUST be supported for data and datastore resources. A PUT on the datastore resource is used to replace the entire contents of the datastore. A PUT on a data resource only replaces that data resource within the datastore. The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the PUT method for data resources. These parameters are only allowed if the list or leaf-list is ordered-by user. Consistent with [RFC7231], if the PUT request creates a new resource, a "201 Created" status-line is returned. If an existing resource is modified, a "204 No Content" status-line is returned. If the user is not authorized to create or replace the target resource an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is used in this case. A server MAY return a "404 Not Found" status-line, as described in section 6.5.3 in ^RFC7231^. The error-tag value "invalid-value" is used in this case. All other error responses are handled according to the procedures defined in ^error-reporting^. If the target resource represents a YANG leaf-list, then the PUT method MUST NOT change the value of the leaf-list instance. If the target resource represents a YANG list instance, then the key leaf values in message-body representation MUST be the same as the key leaf values in the request URI. The PUT method MUST NOT be used to change the key leaf values for a data resource instance. Example: An "album" child resource defined in the "example-jukebox" YANG module is replaced or created if it does not already exist. Bierman, et al. Expires April 30, 2017 [Page 45] Internet-Draft RESTCONF October 2016 To replace the "album" resource contents, the client might send as follows: PUT /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:album" : [ { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011 } ] } If the resource is updated, the server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2016 17:04:00 GMT Server: example-server Last-Modified: Mon, 23 Apr 2016 17:04:00 GMT ETag: "b27480aeda4c" The same request is shown here using XML encoding: PUT /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml Wasting Light jbox:alternative 2011 Refer to Appendix D.2.4 for an example using the PUT method to replace the contents of the datastore resource. 4.6. PATCH The RESTCONF server MUST support the PATCH method for a plain patch, and MAY support additional media types. The PATCH media types supported by a server can be discovered by the client by sending an Bierman, et al. Expires April 30, 2017 [Page 46] Internet-Draft RESTCONF October 2016 OPTIONS request, and examining the Accept-Patch header field in the response. (see Section 4.1). RESTCONF uses the HTTP PATCH method defined in [RFC5789] to provide an extensible framework for resource patching mechanisms. Each patch mechanism needs a unique media type. This document defines one patch mechanism (Section 4.6.1). Another patch mechanism, the YANG PATCH mechanism, is defined in [I-D.ietf-netconf-yang-patch]. Other patch mechanisms may be defined by future specifications. If the target resource instance does not exist, the server MUST NOT create it. If the PATCH request succeeds, a "200 OK" status-line is returned if there is a message-body, and "204 No Content" is returned if no response message-body is sent. If the user is not authorized to alter the target resource an error response containing a "403 Forbidden" status-line SHOULD be returned. A server MAY return a "404 Not Found" status-line, as described in section 6.5.3 in [RFC7231]. The error-tag value "invalid-value" is used in this case. All other error responses are handled according to the procedures defined in Section 7. 4.6.1. Plain Patch The plain patch mechanism merges the contents of the message-body with the target resource. The message-body for a plain patch MUST be present and MUST be represented by the media type "application/ yang-data+xml" or "application/yang-data+json". Plain patch can be used to create or update, but not delete, a child resource within the target resource. Please see [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting the ability to delete child resources. The YANG Patch Media Type allows multiple sub-operations (e.g., merge, delete) within a single PATCH method. If the target resource represents a YANG leaf-list, then the PATCH method MUST NOT change the value of the leaf-list instance. If the target resource represents a YANG list instance, then the key leaf values in message-body representation MUST be the same as the key leaf values in the request URI. The PATCH method MUST NOT be used to change the key leaf values for a data resource instance. Bierman, et al. Expires April 30, 2017 [Page 47] Internet-Draft RESTCONF October 2016 After the plain patch is processed by the server a response will be returned to the client, as specified in Section 4.6. Example: To replace just the "year" field in the "album" resource (instead of replacing the entire resource with the PUT method), the client might send a plain patch as follows. PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If-Match: "b8389233a4c" Content-Type: application/yang-data+xml 2011 If the field is updated, the server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2016 17:49:30 GMT Server: example-server Last-Modified: Mon, 23 Apr 2016 17:49:30 GMT ETag: "b2788923da4c" 4.7. DELETE The RESTCONF server MUST support the DELETE method. The DELETE method is used to delete the target resource. If the DELETE request succeeds, a "204 No Content" status-line is returned. If the user is not authorized to delete the target resource then an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is returned in this case. A server MAY return a "404 Not Found" status-line, as described in section 6.5.3 in [RFC7231]. The error-tag value "invalid-value" is returned in this case. All other error responses are handled according to the procedures defined in Section 7. If the target resource represents a configuration leaf-list or list data node, then it MUST represent a single YANG leaf-list or list instance. The server MUST NOT use the DELETE method to delete more than one such instance. Example: Bierman, et al. Expires April 30, 2017 [Page 48] Internet-Draft RESTCONF October 2016 To delete the "album" resource with the key "Wasting Light", the client might send: DELETE /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If the resource is deleted, the server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2016 17:49:40 GMT Server: example-server 4.8. Query Parameters Each RESTCONF operation allows zero or more query parameters to be present in the request URI. The specific parameters that are allowed depends on the resource type, and sometimes the specific target resource used, in the request. o Query parameters can be given in any order. o Each parameter can appear at most once in a request URI. o If more than one instance of a query parameter is present, then a "400 Bad Request" status-line MUST be returned by the server. The error-tag value "invalid-value" is returned in this case. o A default value may apply if the parameter is missing. o Query parameter names and values are case-sensitive o A server MUST return an error with a '400 Bad Request' status-line if a query parameter is unexpected. The error-tag value "invalid-value" is returned in this case. Bierman, et al. Expires April 30, 2017 [Page 49] Internet-Draft RESTCONF October 2016 +---------------+---------+-----------------------------------------+ | Name | Methods | Description | +---------------+---------+-----------------------------------------+ | content | GET, | Select config and/or non-config data | | | HEAD | resources | | depth | GET, | Request limited sub-tree depth in the | | | HEAD | reply content | | fields | GET, | Request a subset of the target resource | | | HEAD | contents | | filter | GET, | Boolean notification filter for event | | | HEAD | stream resources | | insert | POST, | Insertion mode for ordered-by user data | | | PUT | resources | | point | POST, | Insertion point for ordered-by user | | | PUT | data resources | | start-time | GET, | Replay buffer start time for event | | | HEAD | stream resources | | stop-time | GET, | Replay buffer stop time for event | | | HEAD | stream resources | | with-defaults | GET, | Control retrieval of default values | | | HEAD | | +---------------+---------+-----------------------------------------+ RESTCONF Query Parameters Refer to Appendix D.3 for examples of query parameter usage. If vendors define additional query parameters, they SHOULD use a prefix (such as the enterprise or organization name) for query parameter names in order to avoid collisions with other parameters. 4.8.1. The "content" Query Parameter The "content" parameter controls how descendant nodes of the requested data nodes will be processed in the reply. The allowed values are: +-----------+-----------------------------------------------------+ | Value | Description | +-----------+-----------------------------------------------------+ | config | Return only configuration descendant data nodes | | nonconfig | Return only non-configuration descendant data nodes | | all | Return all descendant data nodes | +-----------+-----------------------------------------------------+ Bierman, et al. Expires April 30, 2017 [Page 50] Internet-Draft RESTCONF October 2016 This parameter is only allowed for GET methods on datastore and data resources. A "400 Bad Request" status-line is returned if used for other methods or resource types. If this query parameter is not present, the default value is "all". This query parameter MUST be supported by the server. 4.8.2. The "depth" Query Parameter The "depth" parameter is used to limit the depth of subtrees returned by the server. Data nodes with a depth value greater than the "depth" parameter are not returned in a response for a GET method. The requested data node has a depth level of '1'. If the "fields" parameter (Section 4.8.3) is used to select descendant data nodes, then these nodes and all their ancestor nodes have a depth value of 1. (This has the effect of including the nodes specified by the fields, even if the "depth" value is less than the actual depth level of the specified fields.) Any other child node has a depth value that is 1 greater than its parent. The value of the "depth" parameter is either an integer between 1 and 65535, or the string "unbounded". "unbounded" is the default. This parameter is only allowed for GET methods on API, datastore, and data resources. A "400 Bad Request" status-line is returned if it used for other methods or resource types. By default, the server will include all sub-resources within a retrieved resource, which have the same resource type as the requested resource. The exception is the datastore resource. If this resource type is retrieved then by default the datastore and all child data resources are returned. If the "depth" query parameter URI is listed in the "capability" leaf-list in Section 9.3, then the server supports the "depth" query parameter. 4.8.3. The "fields" Query Parameter The "fields" query parameter is used to optionally identify data nodes within the target resource to be retrieved in a GET method. The client can use this parameter to retrieve a subset of all nodes in a resource. The server will return a message-body representing the target resource, with descendant nodes pruned as specified in the Bierman, et al. Expires April 30, 2017 [Page 51] Internet-Draft RESTCONF October 2016 "fields-expr" value. The server does not return a set of separate sub-resources. A value of the "fields" query parameter matches the following rule: fields-expr = path '(' fields-expr ')' / path ';' fields-expr / path path = api-identifier [ '/' path ] "api-identifier" is defined in Section 3.5.3.1. ";" is used to select multiple nodes. For example, to retrieve only the "genre" and "year" of an album, use: "fields=genre;year". Parentheses are used to specify sub-selectors of a node. Note that there is no path separator character '/' between a "path" field and left parenthesis character '('. For example, assume the target resource is the "album" list. To retrieve only the "label" and "catalogue-number" of the "admin" container within an album, use: "fields=admin(label;catalogue-number)". "/" is used in a path to retrieve a child node of a node. For example, to retrieve only the "label" of an album, use: "fields=admin/label". This parameter is only allowed for GET methods on api, datastore, and data resources. A "400 Bad Request" status-line is returned if used for other methods or resource types. If the "fields" query parameter URI is listed in the "capability" leaf-list in Section 9.3, then the server supports the "fields" parameter. 4.8.4. The "filter" Query Parameter The "filter" parameter is used to indicate which subset of all possible events are of interest. If not present, all events not precluded by other parameters will be sent. This parameter is only allowed for GET methods on an event stream resource. A "400 Bad Request" status-line is returned if used for other methods or resource types. The format of this parameter is an XPath 1.0 expression [XPath], and is evaluated in the following context: Bierman, et al. Expires April 30, 2017 [Page 52] Internet-Draft RESTCONF October 2016 o The set of namespace declarations is the set of prefix and namespace pairs for all supported YANG modules, where the prefix is the YANG module name, and the namespace is as defined by the "namespace" statement in the YANG module. o The function library is the core function library defined in XPath 1.0, plus any functions defined by the data model. o The set of variable bindings is empty. o The context node is the root node. The filter is used as defined in [RFC5277], Section 3.6. If the boolean result of the expression is true when applied to the conceptual "notification" document root, then the event notification is delivered to the client. If the "filter" query parameter URI is listed in the "capability" leaf-list in Section 9.3, then the server supports the "filter" query parameter. 4.8.5. The "insert" Query Parameter The "insert" parameter is used to specify how a resource should be inserted within a ordered-by user list. The allowed values are: +--------+----------------------------------------------------------+ | Value | Description | +--------+----------------------------------------------------------+ | first | Insert the new data as the new first entry. | | last | Insert the new data as the new last entry. | | before | Insert the new data before the insertion point, as | | | specified by the value of the "point" parameter. | | after | Insert the new data after the insertion point, as | | | specified by the value of the "point" parameter. | +--------+----------------------------------------------------------+ The default value is "last". This parameter is only supported for the POST and PUT methods. It is also only supported if the target resource is a data resource, and that data represents a YANG list or leaf-list that is ordered-by user. Bierman, et al. Expires April 30, 2017 [Page 53] Internet-Draft RESTCONF October 2016 If the values "before" or "after" are used, then a "point" query parameter for the insertion parameter MUST also be present, or a "400 Bad Request" status-line is returned. The "insert" query parameter MUST be supported by the server. 4.8.6. The "point" Query Parameter The "point" parameter is used to specify the insertion point for a data resource that is being created or moved within an ordered-by user list or leaf-list. The value of the "point" parameter is a string that identifies the path to the insertion point object. The format is the same as a target resource URI string. This parameter is only supported for the POST and PUT methods. It is also only supported if the target resource is a data resource, and that data represents a YANG list or leaf-list that is ordered-by user. If the "insert" query parameter is not present, or has a value other than "before" or "after", then a "400 Bad Request" status-line is returned. This parameter contains the instance identifier of the resource to be used as the insertion point for a POST or PUT method. The "point" query parameter MUST be supported by the server. 4.8.7. The "start-time" Query Parameter The "start-time" parameter is used to trigger the notification replay feature defined in [RFC5277] and indicate that the replay should start at the time specified. If the stream does not support replay, per the "replay-support" attribute returned by stream list entry for the stream resource, then the server MUST return a "400 Bad Request" status-line. The value of the "start-time" parameter is of type "date-and-time", defined in the "ietf-yang" YANG module [RFC6991]. This parameter is only allowed for GET methods on a text/event-stream data resource. A "400 Bad Request" status-line is returned if used for other methods or resource types. If this parameter is not present, then a replay subscription is not being requested. It is not valid to specify start times that are Bierman, et al. Expires April 30, 2017 [Page 54] Internet-Draft RESTCONF October 2016 later than the current time. If the value specified is earlier than the log can support, the replay will begin with the earliest available notification. A client can obtain a server's current time by examining the "Date" header field that the server returns in response messages, according to [RFC7231]. If this query parameter is supported by the server, then the "replay" query parameter URI MUST be listed in the "capability" leaf-list in Section 9.3, anf the "stop-time" query parameter MUST also be supported by the server. If the "replay-support" leaf has the value 'true' in the "stream" entry (defined in Section 9.3) then the server MUST support the "start-time" and "stop-time" query parameters for that stream. 4.8.8. The "stop-time" Query Parameter The "stop-time" parameter is used with the replay feature to indicate the newest notifications of interest. This parameter MUST be used with and have a value later than the "start-time" parameter. The value of the "stop-time" parameter is of type "date-and-time", defined in the "ietf-yang" YANG module [RFC6991]. This parameter is only allowed for GET methods on a text/event-stream data resource. A "400 Bad Request" status-line is returned if used for other methods or resource types. If this parameter is not present, the notifications will continue until the subscription is terminated. Values in the future are valid. If this query parameter is supported by the server, then the "replay" query parameter URI MUST be listed in the "capability" leaf-list in Section 9.3, and the "start-time" query parameter MUST also be supported by the server. If the "replay-support" leaf is present in the "stream" entry (defined in Section 9.3) then the server MUST support the "start-time" and "stop-time" query parameters for that stream. 4.8.9. The "with-defaults" Query Parameter The "with-defaults" parameter is used to specify how information about default data nodes should be returned in response to GET requests on data resources. Bierman, et al. Expires April 30, 2017 [Page 55] Internet-Draft RESTCONF October 2016 If the server supports this capability, then it MUST implement the behavior in Section 4.5.1 of [RFC6243], except applied to the RESTCONF GET operation, instead of the NETCONF operations. +-------------------+-----------------------------------------------+ | Value | Description | +-------------------+-----------------------------------------------+ | report-all | All data nodes are reported | | trim | Data nodes set to the YANG default are not | | | reported | | explicit | Data nodes set to the YANG default by the | | | client are reported | | report-all-tagged | All data nodes are reported and defaults are | | | tagged | +-------------------+-----------------------------------------------+ If the "with-defaults" parameter is set to "report-all" then the server MUST adhere to the defaults reporting behavior defined in Section 3.1 of [RFC6243]. If the "with-defaults" parameter is set to "trim" then the server MUST adhere to the defaults reporting behavior defined in Section 3.2 of [RFC6243]. If the "with-defaults" parameter is set to "explicit" then the server MUST adhere to the defaults reporting behavior defined in Section 3.3 of [RFC6243]. If the "with-defaults" parameter is set to "report-all-tagged" then the server MUST adhere to the defaults reporting behavior defined in Section 3.4 of [RFC6243]. Metadata is reported by the server as specified in Section 5.3. The XML encoding for the "default" attribute sent by the server for default nodes is defined in section 6 of [RFC6243]. The JSON encoding for the "default" attribute MUST use the same values as defined in [RFC6243], but encoded according to the rules in [RFC7952]. The module name "ietf-netconf-with-defaults" MUST be used for the "default" attribute. If the "with-defaults" parameter is not present then the server MUST adhere to the defaults reporting behavior defined in its "basic-mode" parameter for the "defaults" protocol capability URI, defined in Section 9.1.2. If the server includes the "with-defaults" query parameter URI in the "capability" leaf-list in Section 9.3, then the "with-defaults" query parameter MUST be supported. Bierman, et al. Expires April 30, 2017 [Page 56] Internet-Draft RESTCONF October 2016 Since the server does not report the "also-supported" parameter as described in section 4.3 of [RFC6243], it is possible that some values for the "with-defaults" parameter will not be supported. If the server does not support the requested value of the "with-defaults" parameter, the server MUST return a response with a "400 Bad Request" status-line. The error-tag value "invalid-value" is used in this case. 5. Messages The RESTCONF protocol uses HTTP messages. A single HTTP message corresponds to a single protocol method. Most messages can perform a single task on a single resource, such as retrieving a resource or editing a resource. The exception is the PATCH method, which allows multiple datastore edits within a single message. 5.1. Request URI Structure Resources are represented with URIs following the structure for generic URIs in [RFC3986]. A RESTCONF operation is derived from the HTTP method and the request URI, using the following conceptual fields: //? ^ ^ ^ ^ | | | | method entry resource query M M O O M=mandatory, O=optional where: is the HTTP method is the RESTCONF root resource is the Target Resource URI is the query parameter list o method: the HTTP method identifying the RESTCONF operation requested by the client, to act upon the target resource specified in the request URI. RESTCONF operation details are described in Section 4. Bierman, et al. Expires April 30, 2017 [Page 57] Internet-Draft RESTCONF October 2016 o entry: the root of the RESTCONF API configured on this HTTP server, discovered by getting the "/.well-known/host-meta" resource, as described in Section 3.1. o resource: the path expression identifying the resource that is being accessed by the RESTCONF operation. If this field is not present, then the target resource is the API itself, represented by the YANG data template named "yang-api", found in Section 8. o query: the set of parameters associated with the RESTCONF message, as defined in section 3.4 of [RFC3986]. RESTCONF parameters have the familiar form of "name=value" pairs. Most query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URI. The server MUST list the optional query parameter URIs it supports in the "capabilities" list defined in Section 9.3. There is a specific set of parameters defined, although the server MAY choose to support query parameters not defined in this document. The contents of the any query parameter value MUST be encoded according to [RFC3986], Section 3.4. Any reserved characters MUST be percent-encoded, according to [RFC3986], section 2.1 and 2.5. Note that the fragment component not used by the RESTCONF protocol. The fragment is excluded from the target URI by a server, as described in section 5.1 of [RFC7230]. When new resources are created by the client, a "Location" header field is returned, which identifies the path of the newly created resource. The client uses this exact path identifier to access the resource once it has been created. The "target" of a RESTCONF operation is a resource. The "path" field in the request URI represents the target resource for the RESTCONF operation. Refer to Appendix D for examples of RESTCONF Request URIs. 5.2. Message Encoding RESTCONF messages are encoded in HTTP according to [RFC7230]. The "utf-8" character set is used for all messages. RESTCONF message content is sent in the HTTP message-body. Content is encoded in either JSON or XML format. A server MUST support one of either XML or JSON encoding. A server MAY support both XML and JSON encoding. A client will need to support both XML and JSON to interoperate with all RESTCONF servers. Bierman, et al. Expires April 30, 2017 [Page 58] Internet-Draft RESTCONF October 2016 XML encoding rules for data nodes are defined in [RFC7950]. The same encoding rules are used for all XML content. JSON encoding rules are defined in [RFC7951]. Additional JSON encoding rules for metadata are defined in [RFC7952]. This encoding is valid JSON, but also has special encoding rules to identify module namespaces and provide consistent type processing of YANG data. Request input content encoding format is identified with the Content- Type header field. This field MUST be present if a message-body is sent by the client. The server MUST support the "Accept" header field and "406 Not Acceptable" status-line, as defined in [RFC7231]. The response output content encoding formats that the client will accept are identified with the Accept header field in the request. If it is not specified, the request input encoding format SHOULD be used, or the server MAY choose any supported content encoding format. If there was no request input, then the default output encoding is XML or JSON, depending on server preference. File extensions encoded in the request are not used to identify format encoding. A client can determine if the RESTCONF server supports an encoding format by sending a request using a specific format in the Content- Type and/or Accept header field. If the server does not support the requested input encoding for a request, then it MUST return an error response with a '415 Unsupported Media Type' status-line. If the server does not support any of the requested output encodings for a request, then it MUST return an error response with a '406 Not Acceptable' status-line. 5.3. RESTCONF Metadata The RESTCONF protocol needs to support retrieval of the same metadata that is used in the NETCONF protocol. Information about default leafs, last-modified timestamps, etc. are commonly used to annotate representations of the datastore contents. With the XML encoding, the metadata is encoded as attributes in XML, according to section 3.3 of [W3C.REC-xml-20081126]. With the JSON encoding, the metadata is encoded as specified in [RFC7952]. The following examples are based on the example in Appendix D.3.9. The "report-all-tagged" mode for the "with-defaults" query parameter requires that a "default" attribute be returned for default nodes. This example shows that attribute for the "mtu" leaf . Bierman, et al. Expires April 30, 2017 [Page 59] Internet-Draft RESTCONF October 2016 5.3.1. XML Metadata Encoding Example GET /restconf/data/interfaces/interface=eth1 ?with-defaults=report-all-tagged HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond as follows. HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Content-Type: application/yang-data+xml eth1 1500 up 5.3.2. JSON Metadata Encoding Example Note that RFC 6243 defines the "default" attribute with XSD, not YANG, so the YANG module name has to be assigned instead of derived from the YANG module. The value "ietf-netconf-with-defaults" is assigned for JSON metadata encoding. GET /restconf/data/interfaces/interface=eth1\ ?with-defaults=report-all-tagged HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond as follows. Bierman, et al. Expires April 30, 2017 [Page 60] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Content-Type: application/yang-data+json { "example:interface" : [ { "name" : "eth1", "mtu" : 1500, "@mtu" : { "ietf-netconf-with-defaults:default" : true }, "status" : "up" } ] } 5.4. Return Status Each message represents some sort of resource access. An HTTP "status-line" header field is returned for each request. If a "4xx" range status code is returned in the status-line, then the error information SHOULD be returned in the response, according to the format defined in Section 7.1. If a "5xx" range status code is returned in the status-line, then the error information MAY be returned in the response, according to the format defined in Section 7.1. If a 1xx, 2xx, or 3xx range status code is returned in the status-line, then error information MUST NOT be returned in the response, since these ranges do not represent error conditions. 5.5. Message Caching Since the datastore contents change at unpredictable times, responses from a RESTCONF server generally SHOULD NOT be cached. The server MUST include a "Cache-Control" header field in every response that specifies whether the response should be cached. Instead of relying on HTTP caching, the client SHOULD track the "ETag" and/or "Last-Modified" header fields returned by the server for the datastore resource (or data resource if the server supports it). A retrieval request for a resource can include the "If-None-Match" and/or "If-Modified-Since" header fields, which will cause the server to return a "304 Not Modified" status-line if the resource has not changed. The client MAY use the HEAD method to retrieve just the message header fields, which SHOULD include the Bierman, et al. Expires April 30, 2017 [Page 61] Internet-Draft RESTCONF October 2016 "ETag" and "Last-Modified" header fields, if this metadata is maintained for the target resource. Note that the way that access control is applied to data resources the values in the Last-Modified and ETag headers maintained for a data resource may not be reliable, as described in Section 4.3. 6. Notifications The RESTCONF protocol supports YANG-defined event notifications. The solution preserves aspects of NETCONF Event Notifications [RFC5277] while utilizing the Server-Sent Events [W3C.REC-eventsource-20150203] transport strategy. 6.1. Server Support A RESTCONF server MAY support RESTCONF notifications. Clients may determine if a server supports RESTCONF notifications by using the HTTP method OPTIONS, HEAD, or GET on the stream list. The server does not support RESTCONF notifications if an HTTP error code is returned (e.g., "404 Not Found" status-line). 6.2. Event Streams A RESTCONF server that supports notifications will populate a stream resource for each notification delivery service access point. A RESTCONF client can retrieve the list of supported event streams from a RESTCONF server using the GET method on the stream list. The "restconf-state/streams" container definition in the "ietf-restconf-monitoring" module (defined in Section 9.3) is used to specify the structure and syntax of the conceptual child resources within the "streams" resource. For example: The client might send the following request: GET /restconf/data/ietf-restconf-monitoring:restconf-state/\ streams HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might send the following response: HTTP/1.1 200 OK Content-Type: application/yang-data+xml Bierman, et al. Expires April 30, 2017 [Page 62] Internet-Draft RESTCONF October 2016 NETCONF default NETCONF event stream true \ 2007-07-08T00:00:00Z\ xml https://example.com/streams/NETCONF\ json https://example.com/streams/NETCONF-JSON\ SNMP SNMP notifications false xml https://example.com/streams/SNMP syslog-critical Critical and higher severity true 2007-07-01T00:00:00Z xml \ https://example.com/streams/syslog-critical\ Bierman, et al. Expires April 30, 2017 [Page 63] Internet-Draft RESTCONF October 2016 6.3. Subscribing to Receive Notifications RESTCONF clients can determine the URL for the subscription resource (to receive notifications) by sending an HTTP GET request for the "location" leaf with the stream list entry. The value returned by the server can be used for the actual notification subscription. The client will send an HTTP GET request for the URL returned by the server with the "Accept" type "text/event-stream". The server will treat the connection as an event stream, using the Server Sent Events [W3C.REC-eventsource-20150203] transport strategy. The server MAY support query parameters for a GET method on this resource. These parameters are specific to each event stream. For example: The client might send the following request: GET /restconf/data/ietf-restconf-monitoring:restconf-state/\ streams/stream=NETCONF/access=xml/location HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might send the following response: HTTP/1.1 200 OK Content-Type: application/yang-data+xml \ https://example.com/streams/NETCONF\ The RESTCONF client can then use this URL value to start monitoring the event stream: GET /streams/NETCONF HTTP/1.1 Host: example.com Accept: text/event-stream Cache-Control: no-cache Connection: keep-alive A RESTCONF client MAY request that the server compress the events using the HTTP header field "Accept-Encoding". For instance: Bierman, et al. Expires April 30, 2017 [Page 64] Internet-Draft RESTCONF October 2016 GET /streams/NETCONF HTTP/1.1 Host: example.com Accept: text/event-stream Cache-Control: no-cache Connection: keep-alive Accept-Encoding: gzip, deflate 6.3.1. NETCONF Event Stream The server SHOULD support the "NETCONF" event stream defined in section 3.2.3 of [RFC5277]. The notification messages for this stream are encoded in XML. The server MAY support additional streams which represent the semantic content of the NETCONF event stream, but using a representation with a different media type. The server MAY support the "start-time", "stop-time", and "filter" query parameters, defined in Section 4.8. Refer to Appendix D.3.6 for filter parameter examples. 6.4. Receiving Event Notifications RESTCONF notifications are encoded according to the definition of the event stream. The structure of the event data is based on the "notification" element definition in Section 4 of [RFC5277]. It MUST conform to the schema for the "notification" element in Section 4 of [RFC5277] using the XML namespace as defined in the XSD as follows: urn:ietf:params:xml:ns:netconf:notification:1.0 For JSON encoding purposes, the module name for the "notification" element is "ietf-restconf". Two child nodes within the "notification" container are expected, representing the event time and the event payload. The "eventTime" node is defined within the same XML namespace as the "notification" element. It is defined to be within the "ietf-restconf" module namespace for JSON encoding purposes. The name and namespace of the payload element are determined by the YANG module containing the notification-stmt representing the notification message. In the following example, the YANG module "example-mod" is used: Bierman, et al. Expires April 30, 2017 [Page 65] Internet-Draft RESTCONF October 2016 module example-mod { namespace "http://example.com/event/1.0"; prefix ex; notification event { leaf event-class { type string; } container reporting-entity { leaf card { type string; } } leaf severity { type string; } } } An example SSE event notification encoded using XML: data: data: 2013-12-21T00:01:00Z data: data: fault data: data: Ethernet0 data: data: major data: data: An example SSE event notification encoded using JSON: data: { data: "ietf-restconf:notification" : { data: "eventTime" : "2013-12-21T00:01:00Z", data: "example-mod:event" : { data: "event-class" : "fault", data: "reporting-entity" : { "card" : "Ethernet0" }, data: "severity" : "major" data: } data: } data: } Alternatively, since neither XML nor JSON are whitespace sensitive, the above messages can be encoded onto a single line. For example: For example: Bierman, et al. Expires April 30, 2017 [Page 66] Internet-Draft RESTCONF October 2016 XML: data: 2013-12-21T00:01:00ZfaultEthernet0\ major JSON: data: {"ietf-restconf:notification":{"eventTime":"2013-12-21\ T00:01:00Z","example-mod:event":{"event-class": "fault","repor\ tingEntity":{"card":"Ethernet0"},"severity":"major"}}} The SSE specifications supports the following additional fields: event, id and retry. A RESTCONF server MAY send the "retry" field and, if it does, RESTCONF clients SHOULD use it. A RESTCONF server SHOULD NOT send the "event" or "id" fields, as there are no meaningful values that could be used for them that would not be redundant to the contents of the notification itself. RESTCONF servers that do not send the "id" field also do not need to support the HTTP header field "Last-Event-Id". RESTCONF servers that do send the "id" field SHOULD support the "start-time" query parameter as the preferred means for a client to specify where to restart the event stream. 7. Error Reporting HTTP status codes are used to report success or failure for RESTCONF operations. The error information that NETCONF error responses contain in the element is adapted for use in RESTCONF, and an data tree information is returned for "4xx" and "5xx" class of status codes. Since an operation resource is defined with a YANG "rpc" statement, and an action is defined with a YANG "action" statement, a mapping from the NETCONF value to the HTTP status code is needed. The specific error-tag and response code to use are data-model- specific and might be contained in the YANG "description" statement for the "action" or "rpc" statement. Bierman, et al. Expires April 30, 2017 [Page 67] Internet-Draft RESTCONF October 2016 +-------------------------+-----------------+ | error-tag | status code | +-------------------------+-----------------+ | in-use | 409 | | invalid-value | 400, 404 or 406 | | (request) too-big | 413 | | (response) too-big | 400 | | missing-attribute | 400 | | bad-attribute | 400 | | unknown-attribute | 400 | | bad-element | 400 | | unknown-element | 400 | | unknown-namespace | 400 | | access-denied | 401, 403 | | lock-denied | 409 | | resource-denied | 409 | | rollback-failed | 500 | | data-exists | 409 | | data-missing | 409 | | operation-not-supported | 405 or 501 | | operation-failed | 412 or 500 | | partial-operation | 500 | | malformed-message | 400 | +-------------------------+-----------------+ Mapping from error-tag to status code 7.1. Error Response Message When an error occurs for a request message on any resource type, and the status code that will be returned is in the "4xx" range (except for status code "403 Forbidden"), then the server SHOULD send a response message-body containing the information described by the "yang-errors" YANG data template within the "ietf-restconf" module, found in Section 8. The Content-Type of this response message MUST be "application/yang-data", plus optionally a structured syntax name suffix. The client SHOULD specify the desired encoding(s) for response messages by specifying the appropriate media-type(s) in the Accept header. If the client did not specify an Accept header, then the same structured syntax name suffix used in the request message SHOULD be used, or the server MAY choose any supported message encoding format. If there is no request message the server MUST select "application/yang-data+xml" or "application/yang-data+json", depending on server preference. All of the examples in this document, except for the one below, assume that XML encoding will be returned if there is an error. Bierman, et al. Expires April 30, 2017 [Page 68] Internet-Draft RESTCONF October 2016 YANG Tree Diagram for data: +---- errors +---- error* +---- error-type enumeration +---- error-tag string +---- error-app-tag? string +---- error-path? instance-identifier +---- error-message? string +---- error-info? The semantics and syntax for RESTCONF error messages are defined with the "yang-errors" YANG data template extension, found in Section 8. Examples: The following example shows an error returned for an "lock-denied" error that can occur if a NETCONF client has locked a datastore. The RESTCONF client is attempting to delete a data resource. Note that an Accept header field is used to specify the desired encoding for the error message. There would be no response message-body content if this operation was successful. DELETE /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: HTTP/1.1 409 Conflict Date: Mon, 23 Apr 2016 17:11:00 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-restconf:errors" : { "error" : [ { "error-type" : "protocol", "error-tag" : "lock-denied", "error-message" : "Lock failed, lock already held" } ] } } Bierman, et al. Expires April 30, 2017 [Page 69] Internet-Draft RESTCONF October 2016 The following example shows an error returned for a "data-exists" error on a data resource. The "jukebox" resource already exists so it cannot be created. The client might send: POST /restconf/data/example-jukebox:jukebox HTTP/1.1 Host: example.com The server might respond: HTTP/1.1 409 Conflict Date: Mon, 23 Apr 2016 17:11:00 GMT Server: example-server Content-Type: application/yang-data+xml protocol data-exists \ /rc:restconf/rc:data/jbox:jukebox Data already exists, cannot create new resource 8. RESTCONF Module The "ietf-restconf" module defines conceptual definitions within an extension and two groupings, which are not meant to be implemented as datastore contents by a server. E.g., the "restconf" container is not intended to be implemented as a top-level data node (under the "/restconf/data" URI). Note that the "ietf-restconf" module does not have any protocol- accessible objects, so no YANG tree diagram is shown. RFC Ed.: update the date below with the date of RFC publication and remove this note. file "ietf-restconf@2016-08-15.yang" module ietf-restconf { Bierman, et al. Expires April 30, 2017 [Page 70] Internet-Draft RESTCONF October 2016 yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-restconf"; prefix "rc"; organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Author: Andy Bierman Author: Martin Bjorklund Author: Kent Watsen "; description "This module contains conceptual YANG specifications for basic RESTCONF media type definitions used in RESTCONF protocol messages. Note that the YANG definitions within this module do not represent configuration data of any kind. The 'restconf-media-type' YANG extension statement provides a normative syntax for XML and JSON message encoding purposes. Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: remove this note Bierman, et al. Expires April 30, 2017 [Page 71] Internet-Draft RESTCONF October 2016 // Note: extracted from draft-ietf-netconf-restconf-17.txt // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2016-08-15 { description "Initial revision."; reference "RFC XXXX: RESTCONF Protocol."; } extension yang-data { argument name { yin-element true; } description "This extension is used to specify a YANG data template which represents conceptual data defined in YANG. It is intended to describe hierarchical data independent of protocol context or specific message encoding format. Data definition statements within a yang-data extension specify the generic syntax for the specific YANG data template, whose name is the argument of the yang-data extension statement. Note that this extension does not define a media-type. A specification using this extension MUST specify the message encoding rules, including the content media type. The mandatory 'name' parameter value identifies the YANG data template that is being defined. It contains the template name. This extension is ignored unless it appears as a top-level statement. It MUST contain data definition statements that result in exactly one container data node definition. An instance of a YANG data template can thus be translated into an XML instance document, whose top-level element corresponds to the top-level container. The module name and namespace value for the YANG module using the extension statement is assigned to instance document data conforming to the data definition statements within this extension. The sub-statements of this extension MUST follow the 'data-def-stmt' rule in the YANG ABNF. Bierman, et al. Expires April 30, 2017 [Page 72] Internet-Draft RESTCONF October 2016 The XPath document root is the extension statement itself, such that the child nodes of the document root are represented by the data-def-stmt sub-statements within this extension. This conceptual document is the context for the following YANG statements: - must-stmt - when-stmt - path-stmt - min-elements-stmt - max-elements-stmt - mandatory-stmt - unique-stmt - ordered-by - instance-identifier data type The following data-def-stmt sub-statements are constrained when used within a yang-data-resource extension statement. - The list-stmt is not required to have a key-stmt defined. - The if-feature-stmt is ignored if present. - The config-stmt is ignored if present. - The available identity values for any 'identityref' leaf or leaf-list nodes is limited to the module containing this extension statement, and the modules imported into that module. "; } rc:yang-data yang-errors { uses errors; } rc:yang-data yang-api { uses restconf; } grouping errors { description "A grouping that contains a YANG container representing the syntax and semantics of a YANG Patch errors report within a response message."; container errors { description "Represents an error report returned by the server if a request results in an error."; Bierman, et al. Expires April 30, 2017 [Page 73] Internet-Draft RESTCONF October 2016 list error { description "An entry containing information about one specific error that occurred while processing a RESTCONF request."; reference "RFC 6241, Section 4.3"; leaf error-type { type enumeration { enum transport { description "The transport layer"; } enum rpc { description "The rpc or notification layer"; } enum protocol { description "The protocol operation layer"; } enum application { description "The server application layer"; } } mandatory true; description "The protocol layer where the error occurred."; } leaf error-tag { type string; mandatory true; description "The enumerated error tag."; } leaf error-app-tag { type string; description "The application-specific error tag."; } leaf error-path { type instance-identifier; description "The YANG instance identifier associated with the error node."; } leaf error-message { Bierman, et al. Expires April 30, 2017 [Page 74] Internet-Draft RESTCONF October 2016 type string; description "A message describing the error."; } anydata error-info { description "This anydata value MUST represent a container with zero or more data nodes representing additional error information."; } } } } grouping restconf { description "Conceptual grouping representing the RESTCONF root resource."; container restconf { description "Conceptual container representing the RESTCONF root resource."; container data { description "Container representing the datastore resource. Represents the conceptual root of all state data and configuration data supported by the server. The child nodes of this container can be any data resource which are defined as top-level data nodes from the YANG modules advertised by the server in the ietf-yang-library module."; } container operations { description "Container for all operation resources. Each resource is represented as an empty leaf with the name of the RPC operation from the YANG rpc statement. For example, the 'system-restart' RPC operation defined in the 'ietf-system' module would be represented as an empty leaf in the 'ietf-system' namespace. This is a conceptual leaf, and will not actually be found in the module: Bierman, et al. Expires April 30, 2017 [Page 75] Internet-Draft RESTCONF October 2016 module ietf-system { leaf system-reset { type empty; } } To invoke the 'system-restart' RPC operation: POST /restconf/operations/ietf-system:system-restart To discover the RPC operations supported by the server: GET /restconf/operations In XML the YANG module namespace identifies the module: In JSON the YANG module name identifies the module: { 'ietf-system:system-restart' : [null] } "; } leaf yang-library-version { type string { pattern '\d{4}-\d{2}-\d{2}'; } config false; mandatory true; description "Identifies the revision date of the ietf-yang-library module that is implemented by this RESTCONF server. Indicates the year, month, and day in YYYY-MM-DD numeric format."; } } } } Bierman, et al. Expires April 30, 2017 [Page 76] Internet-Draft RESTCONF October 2016 9. RESTCONF Monitoring The "ietf-restconf-monitoring" module provides information about the RESTCONF protocol capabilities and event streams available from the server. A RESTCONF server MUST implement the "ietf-restconf-monitoring" module. YANG tree diagram for "ietf-restconf-monitoring" module: +--ro restconf-state +--ro capabilities | +--ro capability* inet:uri +--ro streams +--ro stream* [name] +--ro name string +--ro description? string +--ro replay-support? boolean +--ro replay-log-creation-time? yang:date-and-time +--ro access* [encoding] +--ro encoding string +--ro location inet:uri 9.1. restconf-state/capabilities This mandatory container holds the RESTCONF protocol capability URIs supported by the server. The server MAY maintain a last-modified timestamp for this container, and return the "Last-Modified" header field when this data node is retrieved with the GET or HEAD methods. Note that the last-modified timestamp for the datastore resource is not affected by changes to this subtree. The server SHOULD maintain an entity-tag for this container, and return the "ETag" header field when this data node is retrieved with the GET or HEAD methods. Note that the entity-tag for the datastore resource is not affected by changes to this subtree. The server MUST include a "capability" URI leaf-list entry for the "defaults" mode used by the server, defined in Section 9.1.2. The server MUST include a "capability" URI leaf-list entry identifying each supported optional protocol feature. This includes optional query parameters and MAY include other capability URIs defined outside this document. Bierman, et al. Expires April 30, 2017 [Page 77] Internet-Draft RESTCONF October 2016 9.1.1. Query Parameter URIs A new set of RESTCONF Capability URIs are defined to identify the specific query parameters (defined in Section 4.8) supported by the server. The server MUST include a "capability" leaf-list entry for each optional query parameter that it supports. +------------+--------+---------------------------------------------+ | Name | Sectio | URI | | | n | | +------------+--------+---------------------------------------------+ | depth | 4.8.2 | urn:ietf:params:restconf:capability:depth:1 | | | | .0 | | fields | 4.8.3 | urn:ietf:params:restconf:capability:fields: | | | | 1.0 | | filter | 4.8.4 | urn:ietf:params:restconf:capability:filter: | | | | 1.0 | | replay | 4.8.7 | urn:ietf:params:restconf:capability:replay: | | | 4.8.8 | 1.0 | | with- | 4.8.9 | urn:ietf:params:restconf:capability:with- | | defaults | | defaults:1.0 | +------------+--------+---------------------------------------------+ RESTCONF Query Parameter URIs 9.1.2. The "defaults" Protocol Capability URI This URI identifies the "basic-mode" defaults handling mode that is used by the server for processing default leafs in requests for data resources. This protocol capability URI MUST be supported by the server, and MUST be listed in the "capability" leaf-list in Section 9.3. +----------+--------------------------------------------------+ | Name | URI | +----------+--------------------------------------------------+ | defaults | urn:ietf:params:restconf:capability:defaults:1.0 | +----------+--------------------------------------------------+ RESTCONF defaults capability URI The URI MUST contain a query parameter named "basic-mode" with one of the values listed below: Bierman, et al. Expires April 30, 2017 [Page 78] Internet-Draft RESTCONF October 2016 +------------+------------------------------------------------------+ | Value | Description | +------------+------------------------------------------------------+ | report-all | No data nodes are considered default | | trim | Values set to the YANG default-stmt value are | | | default | | explicit | Values set by the client are never considered | | | default | +------------+------------------------------------------------------+ The "basic-mode" definitions are specified in the "With-Defaults Capability for NETCONF" [RFC6243]. If the "basic-mode" is set to "report-all" then the server MUST adhere to the defaults handling behavior defined in Section 2.1 of [RFC6243]. If the "basic-mode" is set to "trim" then the server MUST adhere to the defaults handling behavior defined in Section 2.2 of [RFC6243]. If the "basic-mode" is set to "explicit" then the server MUST adhere to the defaults handling behavior defined in Section 2.3 of [RFC6243]. Example: (split for display purposes only) urn:ietf:params:restconf:capability:defaults:1.0? basic-mode=explicit 9.2. restconf-state/streams This optional container provides access to the event streams supported by the server. The server MAY omit this container if no event streams are supported. The server will populate this container with a stream list entry for each stream type it supports. Each stream contains a leaf called "events" which contains a URI that represents an event stream resource. Stream resources are defined in Section 3.8. Notifications are defined in Section 6. 9.3. RESTCONF Monitoring Module The "ietf-restconf-monitoring" module defines monitoring information for the RESTCONF protocol. Bierman, et al. Expires April 30, 2017 [Page 79] Internet-Draft RESTCONF October 2016 The "ietf-yang-types" and "ietf-inet-types" modules from [RFC6991] are used by this module for some type definitions. RFC Ed.: update the date below with the date of RFC publication and remove this note. file "ietf-restconf-monitoring@2016-08-15.yang" module ietf-restconf-monitoring { namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring"; prefix "rcmon"; import ietf-yang-types { prefix yang; } import ietf-inet-types { prefix inet; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Author: Andy Bierman Author: Martin Bjorklund Author: Kent Watsen "; description "This module contains monitoring information for the RESTCONF protocol. Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; Bierman, et al. Expires April 30, 2017 [Page 80] Internet-Draft RESTCONF October 2016 // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: remove this note // Note: extracted from draft-ietf-netconf-restconf-17.txt // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2016-08-15 { description "Initial revision."; reference "RFC XXXX: RESTCONF Protocol."; } container restconf-state { config false; description "Contains RESTCONF protocol monitoring information."; container capabilities { description "Contains a list of protocol capability URIs"; leaf-list capability { type inet:uri; description "A RESTCONF protocol capability URI."; } } container streams { description "Container representing the notification event streams supported by the server."; reference "RFC 5277, Section 3.4, element."; list stream { key name; description "Each entry describes an event stream supported by the server."; leaf name { type string; description "The stream name"; reference "RFC 5277, Section 3.4, element."; } Bierman, et al. Expires April 30, 2017 [Page 81] Internet-Draft RESTCONF October 2016 leaf description { type string; description "Description of stream content"; reference "RFC 5277, Section 3.4, element."; } leaf replay-support { type boolean; default false; description "Indicates if replay buffer supported for this stream. If 'true', then the server MUST support the 'start-time' and 'stop-time' query parameters for this stream."; reference "RFC 5277, Section 3.4, element."; } leaf replay-log-creation-time { when "../replay-support" { description "Only present if notification replay is supported"; } type yang:date-and-time; description "Indicates the time the replay log for this stream was created."; reference "RFC 5277, Section 3.4, element."; } list access { key encoding; min-elements 1; description "The server will create an entry in this list for each encoding format that is supported for this stream. The media type 'text/event-stream' is expected for all event streams. This list identifies the sub-types supported for this stream."; leaf encoding { type string; description "This is the secondary encoding format within the 'text/event-stream' encoding used by all streams. The type 'xml' is supported for XML encoding. Bierman, et al. Expires April 30, 2017 [Page 82] Internet-Draft RESTCONF October 2016 The type 'json' is supported for JSON encoding."; } leaf location { type inet:uri; mandatory true; description "Contains a URL that represents the entry point for establishing notification delivery via server sent events."; } } } } } } 10. YANG Module Library The "ietf-yang-library" module defined in [RFC7895] provides information about the YANG modules and submodules used by the RESTCONF server. Implementation is mandatory for RESTCONF servers. All YANG modules and submodules used by the server MUST be identified in the YANG module library. 10.1. modules-state/module This mandatory list contains one entry for each YANG data model module supported by the server. There MUST be an instance of this list for every YANG module that is used by the server. The contents of this list are defined in the "module" YANG list statement in [RFC7895]. Note that there are no protocol accessible objects in the "ietf-restconf" module to implement, but it is possible that a server will list the "ietf-restconf" module in the YANG library if it is imported (directly or indirectly) by an implemented module. 11. IANA Considerations Bierman, et al. Expires April 30, 2017 [Page 83] Internet-Draft RESTCONF October 2016 11.1. The "restconf" Relation Type This specification registers the "restconf" relation type in the Link Relation Type Registry defined by [RFC5988]: Relation Name: restconf Description: Identifies the root of RESTCONF API as configured on this HTTP server. The "restconf" relation defines the root of the API defined in RFCXXXX. Subsequent revisions of RESTCONF will use alternate relation values to support protocol versioning. Reference: RFCXXXX ` 11.2. YANG Module Registry This document registers two URIs as namespaces in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested: URI: urn:ietf:params:xml:ns:yang:ietf-restconf Registrant Contact: The NETMOD WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring Registrant Contact: The NETMOD WG of the IETF. XML: N/A, the requested URI is an XML namespace. This document registers two YANG modules in the YANG Module Names registry [RFC6020]: name: ietf-restconf namespace: urn:ietf:params:xml:ns:yang:ietf-restconf prefix: rc // RFC Ed.: replace XXXX with RFC number and remove this note reference: RFCXXXX name: ietf-restconf-monitoring namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring prefix: rcmon // RFC Ed.: replace XXXX with RFC number and remove this note reference: RFCXXXX Bierman, et al. Expires April 30, 2017 [Page 84] Internet-Draft RESTCONF October 2016 11.3. Media Types 11.3.1. Media Type application/yang-data+xml Type name: application Subtype name: yang-data+xml Required parameters: None Optional parameters: None Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [RFC7950]. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG defined data structures. Fragment identifier considerations: Fragment identifiers for this type are not defined. All YANG data nodes are Bierman, et al. Expires April 30, 2017 [Page 85] Internet-Draft RESTCONF October 2016 accessible as resources using the path in the request URI. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no 11.3.2. Media Type application/yang-data+json Type name: application Subtype name: yang-data+json Required parameters: None Optional parameters: None Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [RFC7951]. A data annotation is encoded according to [RFC7952]. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Bierman, et al. Expires April 30, 2017 [Page 86] Internet-Draft RESTCONF October 2016 Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG defined data structures. Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as specified for the "application/json" media type. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Bierman, et al. Expires April 30, 2017 [Page 87] Internet-Draft RESTCONF October 2016 Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no 11.4. RESTCONF Capability URNs [Note to RFC Editor: The RESTCONF Protocol Capability Registry does not yet exist; Need to ask IANA to create it; remove this note for publication ] This document defines a registry for RESTCONF capability identifiers. The name of the registry is "RESTCONF Capability URNs". The review policy for this registry is "IETF Review". The registry shall record for each entry: o the name of the RESTCONF capability. By convention, this name begins with the colon ':' character. o the URN for the RESTCONF capability. This document registers several capability identifiers in "RESTCONF Capability URNs" registry: Index Capability Identifier ------------------------ :defaults urn:ietf:params:restconf:capability:defaults:1.0 :depth urn:ietf:params:restconf:capability:depth:1.0 :fields urn:ietf:params:restconf:capability:fields:1.0 :filter urn:ietf:params:restconf:capability:filter:1.0 :replay urn:ietf:params:restconf:capability:replay:1.0 :with-defaults urn:ietf:params:restconf:capability:with-defaults:1.0 Bierman, et al. Expires April 30, 2017 [Page 88] Internet-Draft RESTCONF October 2016 11.5. Registration of "restconf" URN sub-namespace IANA has registered a new URN sub-namespace within the IETF URN Sub- namespace for Registered Protocol Parameter Identifiers defined in [RFC3553]. Registry Name: restconf Specification: RFC XXXX // RFC Ed.: replace XXXX with RFC number and remove this note Repository: RESTCONF Capability URNs registry (Section 11.4) Index value: Sub-parameters MUST be specified in UTF-8, using standard URI encoding where necessary. 12. Security Considerations Section 2.1 states "A RESTCONF server MUST support the TLS protocol [RFC5246]". This language leaves open the possibility that a RESTCONF server might also support future versions of the TLS protocol. Of specific concern, TLS 1.3 [I-D.ietf-tls-tls13] introduces support for 0-RTT handshakes that can lead to security issues for REST APIs, as described in the Appendix of the TLS 1.3 specification. It is therefore RECOMMENDED that RESTCONF servers do not support 0-RTT at all (not even for idempotent requests) until an update to this RFC guides otherwise. Section 2.5 recommends TLS client certificate based authentication, but allows the use of any authentication scheme defined in the HTTP Authentication Scheme Registry. Implementations need to be aware that the strength of these methods vary greatly, and that some may be considered experimental. Selection of any of these schemes SHOULD be performed after reading the Security Considerations section of the RFC associated with the scheme's registry entry. The "ietf-restconf-monitoring" YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre- configured subset of all available NETCONF protocol operations and content. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The RESTCONF protocol uses the NETCONF access control model [RFC6536], which provides the means to Bierman, et al. Expires April 30, 2017 [Page 89] Internet-Draft RESTCONF October 2016 restrict access for particular RESTCONF users to a preconfigured subset of all available RESTCONF protocol operations and content. This section provides security considerations for the resources defined by the RESTCONF protocol. Security considerations for HTTPS are defined in [RFC7230]. RESTCONF does not specify which YANG modules a server needs to support, except the "ietf-restconf-monitoring" module. Security considerations for the other modules manipulated by RESTCONF can be found in the documents defining those YANG modules. Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping and false data injection attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. There are many patterns of attack that have been observed through operational practice with existing management interfaces. It would be wise for implementers to research them, and take them into account when implementing this protocol. Different environments may well allow different rights prior to and then after authentication. When a RESTCONF operation is not properly authorized, the RESTCONF server MUST return a "401 Unauthorized" status-line. Note that authorization information can be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection. Note that it is possible for a client to detect configuration changes in data resources it is not authorized to access by monitoring changes in the ETag and Last- Modified header fields returned by the server for the datastore resource. A RESTCONF server implementation SHOULD attempt to prevent system disruption due to excessive resource consumption required to fulfill edit requests via the POST, PUT, and PATCH methods. It may be possible to construct an attack on such a RESTCONF server, which attempts to consume all available memory or other resource types. 13. Acknowledgements The authors would like to thank the following people for their contributions to this document: Ladislav Lhotka, Juergen Schoenwaelder, Rex Fernando, Robert Wilton, and Jonathan Hansford. The authors would like to thank the following people for their excellent technical reviews of this document: Mehmet Ersue, Mahesh Jethanandani, Qin Wu, Joe Clarke, Bert Wijnen, Ladislav Lhotka, Rodney Cummings, Frank Xialiang, Tom Petch, Robert Sparks, Balint Bierman, et al. Expires April 30, 2017 [Page 90] Internet-Draft RESTCONF October 2016 Uveges, Randy Presuhn, Sue Hares, Mark Nottingham, Benoit Claise, Dale Worley, and Lionel Morand. Contributions to this material by Andy Bierman are based upon work supported by the United States Army, Space & Terrestrial Communications Directorate (S&TCD) under Contract No. W15P7T- 13-C-A616. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of The Space & Terrestrial Communications Directorate (S&TCD). 14. References 14.1. Normative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and T. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010. Bierman, et al. Expires April 30, 2017 [Page 91] Internet-Draft RESTCONF October 2016 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, June 2011. [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC 6415, October 2011. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. Bierman, et al. Expires April 30, 2017 [Page 92] Internet-Draft RESTCONF October 2016 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, July 2014. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015, . [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, June 2016. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016, . [W3C.REC-eventsource-20150203] Hickson, I., "Server-Sent Events", World Wide Web Consortium Recommendation REC-eventsource-20150203, February 2015, . [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . [XPath] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, . Bierman, et al. Expires April 30, 2017 [Page 93] Internet-Draft RESTCONF October 2016 14.2. Informative References [I-D.ietf-netconf-yang-patch] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch Media Type", draft-ietf-netconf-yang-patch-12 (work in progress), October 2016. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-18 (work in progress), October 2016. [rest-dissertation] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Appendix A. Change Log -- RFC Ed.: remove this section before publication. The RESTCONF issue tracker can be found here: https://github.com/ netconf-wg/restconf/issues A.1. v17 to v18 o addressed IESG review comments and clarifications o addressed Alexey's DISCUSS items o made Cache-Control MUST support, not SHOULD support o add example for PUT on a datastore o add IANA section for "restconf" URN sub-namespace o clarify media type file extensions A.2. v16 to v17 o various clarifications from NETCONF WG mailing list o updated YANG 1.1 and YANG/JSON references to RFC numbers o fixed notification namespace and eventTime name bug Bierman, et al. Expires April 30, 2017 [Page 94] Internet-Draft RESTCONF October 2016 o changed media type application/yang-data-xml to application/yang- data+xml o update fragment identifier considerations section for application/ yang-data+xml o clarify HTTP version requirements A.3. v15 to v16 o changed media type application/yang-data to application/yang-data- xml o changed header to header field o added linewrap convention in terminology and applied in many examples o clarified DELETE for leaf-list and list o clarified URI format for lists without keys or duplicate leaf- lists o added 'yang-data extension' term and clarified 'YANG data template' term o clarified that the fragment component is not part of the request URI, per HTTP o clarified request URI "api-path" syntax o clarified many examples A.4. v14 to v15 o added text for HTTP/2 usage o changed media type definitions per review comments o added some clarifications and typos o added error-tag mapping for 406 and 412 errors o added clarifications based on ops-dir review by Lionel Morand o clarified PUT and POST differences for creating a data resource o clarify PUT for a datastore resource Bierman, et al. Expires April 30, 2017 [Page 95] Internet-Draft RESTCONF October 2016 o added clarifications from Gen-Art review by Robert Sparks o clarified terminology in many places A.5. v13 - v14 This release addresses github issues #61, #62, #63, #65, #66, and #67. o change term 'server' to 'NETCONF server' o add term 'RESTCONF server' also called 'server' o change term 'client' to 'NETCONF client' o add term 'RESTCONF client' also called 'client' o remove unused YANG terms o clarified operation resource and schema resource terms o clarified abstract and intro: RESTCONF uses NETCONF datastore concepts o removed term 'protocol operation'; use 'RPC operation' instead o clarified edit operation from NETCONF as nc:operation o clarified retrieval of an operation resource o remove ETag and Last-Modified requirements for /modules-state and /modules-state/module objects, since these are not configuration data nodes o clarified Last-Modified and ETag requirements for datastore and data resources o clarified defaults retrieval for leaf and leaf-list target resources o clarified request message-body for operation resources o clarified query parameters for GET also allowed for HEAD o clarified error handling for query parameters o clarified XPath function library for "filter" parameter Bierman, et al. Expires April 30, 2017 [Page 96] Internet-Draft RESTCONF October 2016 o added example for 'edit a data resource' o added term 'notification replay' from RFC 5277 o clarified unsupported encoding format error handling o change term 'meta-data' to 'metadata' o clarified RESTCONF metadata definition o clarified error info not returned for 1xx, 2xx, and 3xx ranges o clarified operations description in ietf-restconf module o clarified Acknowledgements section o clarified some examples o update some references o update RFC 2119 boilerplate o remove requirements that simply restate HTTP requirements o remove Pragma: no-cache from examples since RFC 7234 says this pragma is not defined for responses o remove suggestion MAY send Pragma: no-cache in response o remove table of HTTP status codes used in RESTCONF o changed media type names so they conform to RFC 6838 o clarified too-big error-tag conversion o update SSE reference o clarify leaf-list identifier encoding o removed all media types except yang-data o changed restconf-media-type extension to be more generic yang-data extension Bierman, et al. Expires April 30, 2017 [Page 97] Internet-Draft RESTCONF October 2016 A.6. v12 - v13 o fix YANG library module examples (now called module-state) o fix terminology idnit issue o removed RFC 2818 reference (changed citation to RFC 7230) A.7. v11 - v12 o clarify query parameter requirements o move filter query section to match table order in sec. 4.8 o clarify that depth default is entire subtree for datastore resource o change ietf-restconf to YANG 1.1 to use anydata instead of anyxml o made implementation of timestamps optional since ETags are mandatory o removed confusing text about data resource definition revision date o clarify that errors should be returned for any resource type o clarified media subtype (not type) for error response o clarified client SHOULD (not MAY) specify errors format in Accept header o clarified terminology in many sections A.8. v10 - v11 o change term 'operational data' to 'state data' o clarify :startup behavior o clarify X.509 security text o change '403 Forbidden' to '401 Unauthorized' for GET error o clarify MUST have one "restconf" link relation o clarify that NV-storage is not mandatory Bierman, et al. Expires April 30, 2017 [Page 98] Internet-Draft RESTCONF October 2016 o clarify how "Last-Modified" and "ETag" header info can be used by a client o clarify meaning of mandatory parameter o fix module name in action examples o clarify operation resource request needs to be known to parse the output o clarify ordered-by user terminology o fixed JSON example in D.1.1 A.9. v09 - v10 o address review comments: github issue #36 o removed intro text about no knowledge of NETCONF needed o clarified candidate and confirmed-commit behavior in sec. 1.3 o clarified that a RESTCONF server MUST support TLS o clarified choice of 403 or 404 error o fixed forward references to URI template (w/reference at first use) o added reference to HTML5 o made error terminology more consistent o clarified that only 1 list or leaf-list instance can be returned in an XML response message-body o clarified that more than 1 instance must not be created by a POST method o clarified that PUT cannot be used to change a leaf-list value or any list key values o clarified that PATCH cannot be used to change a leaf-list value or any list key values o clarified that DELETE should not be used to delete more than one instance of a leaf-list or list Bierman, et al. Expires April 30, 2017 [Page 99] Internet-Draft RESTCONF October 2016 o update JSON RFC reference o specified that leaf-list instances are data resources o specified how a leaf-list instance identifier is constructed o fixed get-schema example o clarified that if no Accept header the server SHOULD return the type specified in RESTCONF, but MAY return any media-type, according to HTTP rules o clarified that server SHOULD maintain timestamp and etag for data resources o clarified default for content query parameter o moved terminology section earlier in doc to avoid forward usage o clarified intro text wrt/ interactions with NETCONF and access to specific datastores o clarified server implementation requirements for YANG defaults o clarified that Errors is not a resource, just a media type o clarified that HTTP without TLS MUST NOT be used o add RESTCONF Extensibility section to make it clear how RESTCONF will be extended in the future o add text warning that NACM does not work with HTTP caching o remove sec. 5.2 Message Headers o remove 202 Accepted from list of used status-lines -- not allowed o made implementation of OPTIONS MUST instead of SHOULD o clarified that successful PUT for altering data returns 204 o fixed "point" parameter example o added example of alternate value for root resource discovery o added YANG action examples o fixed some JSON examples Bierman, et al. Expires April 30, 2017 [Page 100] Internet-Draft RESTCONF October 2016 o changed default value for content query parameter to "all" o changed empty container JSON encoding from "[null]" to "{}" o added mandatory /restconf/yang-library-version leaf to advertise revision-date of the YANG library implemented by the server o clarified URI encoding rules for leaf-list o clarified sec. 2.2 wrt/ certificates and TLS o added update procedure for entity tag and timestamp A.10. v08 - v09 o fix introduction text regarding implementation requirements for the ietf-yang-library o clarified HTTP authentication requirements o fix host-meta example o changed list key encoding to clarify that quoted strings are not allowed. Percent-encoded values are used if quotes would be required. A missing key is treated as a zero-length string o Fixed example of percent-encoded string to match YANG model o Changed streams examples to align with naming already used A.11. v07 - v08 o add support for YANG 1.1 action statement o changed mandatory encoding from XML to XML or JSON o fix syntax in fields parameter definition o add meta-data encoding examples for XML and JSON o remove RFC 2396 references and update with 3986 o change encoding of a key so quoted string are not used, since they are already percent-encoded. A zero-length string is not encoded (/list=foo,,baz) o Add example of percent-encoded key value Bierman, et al. Expires April 30, 2017 [Page 101] Internet-Draft RESTCONF October 2016 A.12. v06 - v07 o fixed all issues identified in email from Jernej Tuljak in netconf email 2015-06-22 o fixed error example bug where error-urlpath was still used. Changed to error-path. o added mention of YANG Patch and informative reference o added support for YANG 1.1, specifically support for anydata and actions o removed the special field value "*", since it is no longer needed A.13. v05 - v06 o fixed RESTCONF issue #23 (ietf-restconf-monitoring bug) A.14. v04 - v05 o changed term 'notification event' to 'event notification' o removed intro text about framework and meta-model o removed early mention of API resources o removed term unified datastore and cleaned up text about NETCONF datastores o removed text about not immediate persistence of edits o removed RESTCONF-specific data-resource-identifier typedef and its usage o clarified encoding of key leafs o changed several examples from JSON to XML encoding o made 'insert' and 'point' query parameters mandatory to implement o removed ":insert" capability URI o renamed stream/encoding to stream/access o renamed stream/encoding/type to stream/access/encoding o renamed stream/encoding/events to stream/access/location Bierman, et al. Expires April 30, 2017 [Page 102] Internet-Draft RESTCONF October 2016 o changed XPath from informative to normative reference o changed rest-dissertation from normative to informative reference o changed example-jukebox playlist 'id' from a data-resource- identifier to a leafref pointing at the song name A.15. v03 - v04 o renamed 'select' to 'fields' (#1) o moved collection resource and page capability to draft-ietf- netconf-restconf-collection-00 (#3) o added mandatory "defaults" protocol capability URI (#4) o added optional "with-defaults" query parameter URI (#4) o clarified authentication procedure (#9) o moved ietf-yang-library module to draft-ietf-netconf-yang- library-00 (#13) o clarified that JSON encoding of module name in a URI MUST follow the netmod-yang-json encoding rules (#14) o added restconf-media-type extension (#15) o remove "content" query parameter URI and made this parameter mandatory (#16) o clarified datastore usage o changed lock-denied error example o added with-defaults query parameter example o added term "RESTCONF Capability" o changed NETCONF Capability URI registry usage to new RESTCONF Capability URI Registry usage A.16. v02 - v03 o added collection resource o added "page" query parameter capability Bierman, et al. Expires April 30, 2017 [Page 103] Internet-Draft RESTCONF October 2016 o added "limit" and "offset" query parameters, which are available if the "page" capability is supported o added "stream list" term o fixed bugs in some examples o added "encoding" list within the "stream" list to allow different URLs for XML and JSON encoding. o made XML MUST implement and JSON MAY implement for servers o re-add JSON notification examples (previously removed) o updated JSON references A.17. v01 - v02 o moved query parameter definitions from the YANG module back to the plain text sections o made all query parameters optional to implement o defined query parameter capability URI o moved 'streams' to new YANG module (ietf-restconf-monitoring) o added 'capabilities' container to new YANG module (ietf-restconf- monitoring) o moved 'modules' container to new YANG module (ietf-yang-library) o added new leaf 'module-set-id' (ietf-yang-library) o added new leaf 'conformance' (ietf-yang-library) o changed 'schema' leaf to type inet:uri that returns the location of the YANG schema (instead of returning the schema directly) o changed 'events' leaf to type inet:uri that returns the location of the event stream resource (instead of returning events directly) o changed examples for yang.api resource since the monitoring information is no longer in this resource o closed issue #1 'select parameter' since no objections to the proposed syntax Bierman, et al. Expires April 30, 2017 [Page 104] Internet-Draft RESTCONF October 2016 o closed "encoding of list keys" issue since no objection to new encoding of list keys in a target resource URI. o moved open issues list to the issue tracker on github A.18. v00 - v01 o fixed content=nonconfig example (non-config was incorrect) o closed open issue 'message-id'. There is no need for a message-id field, and RFC 2392 does not apply. o closed open issue 'server support verification'. The headers used by RESTCONF are widely supported. o removed encoding rules from section on RESTCONF Meta-Data. This is now defined in "I-D.lhotka-netmod-yang-json". o added media type application/yang.errors to map to errors YANG grouping. Updated error examples to use new media type. o closed open issue 'additional datastores'. Support may be added in the future to identify new datastores. o closed open issue 'PATCH media type discovery'. The section on PATCH has an added sentence on the Accept-Patch header. o closed open issue 'YANG to resource mapping'. Current mapping of all data nodes to resources will be used in order to allow mandatory DELETE support. The PATCH operation is optional, as well as the YANG Patch media type. o closed open issue '_self links for HATEOAS support'. It was decided that they are redundant because they can be derived from the YANG module for the specific data. o added explanatory text for the 'select' parameter. o added RESTCONF Path Resolution section for discovering the root of the RESTCONF API using the /.well-known/host-meta. o added an "error" media type to for structured error messages o added Secure Transport section requiring TLS o added Security Considerations section o removed all references to "REST-like" Bierman, et al. Expires April 30, 2017 [Page 105] Internet-Draft RESTCONF October 2016 A.19. bierman:restconf-04 to ietf:restconf-00 o updated open issues section Appendix B. Open Issues -- RFC Ed.: remove this section before publication. The RESTCONF issues are tracked on github.com: https://github.com/netconf-wg/restconf/issues Appendix C. Example YANG Module The example YANG module used in this document represents a simple media jukebox interface. YANG Tree Diagram for "example-jukebox" Module +--rw jukebox! +--rw library | +--rw artist* [name] | | +--rw name string | | +--rw album* [name] | | +--rw name string | | +--rw genre? identityref | | +--rw year? uint16 | | +--rw admin | | | +--rw label? string | | | +--rw catalogue-number? string | | +--rw song* [name] | | +--rw name string | | +--rw location string | | +--rw format? string | | +--rw length? uint32 | +--ro artist-count? uint32 | +--ro album-count? uint32 | +--ro song-count? uint32 +--rw playlist* [name] | +--rw name string | +--rw description? string | +--rw song* [index] | +--rw index uint32 | +--rw id instance-identifier +--rw player +--rw gap? decimal64 rpcs: Bierman, et al. Expires April 30, 2017 [Page 106] Internet-Draft RESTCONF October 2016 +---x play +--ro input +--ro playlist string +--ro song-number uint32 C.1. example-jukebox YANG Module module example-jukebox { namespace "http://example.com/ns/example-jukebox"; prefix "jbox"; organization "Example, Inc."; contact "support at example.com"; description "Example Jukebox Data Model Module"; revision "2016-08-15" { description "Initial version."; reference "example.com document 1-4673"; } identity genre { description "Base for all genre types"; } // abbreviated list of genre classifications identity alternative { base genre; description "Alternative music"; } identity blues { base genre; description "Blues music"; } identity country { base genre; description "Country music"; } identity jazz { base genre; description "Jazz music"; } identity pop { base genre; description "Pop music"; } identity rock { base genre; description "Rock music"; Bierman, et al. Expires April 30, 2017 [Page 107] Internet-Draft RESTCONF October 2016 } container jukebox { presence "An empty container indicates that the jukebox service is available"; description "Represents a jukebox resource, with a library, playlists, and a play operation."; container library { description "Represents the jukebox library resource."; list artist { key name; description "Represents one artist resource within the jukebox library resource."; leaf name { type string { length "1 .. max"; } description "The name of the artist."; } list album { key name; description "Represents one album resource within one artist resource, within the jukebox library."; leaf name { type string { length "1 .. max"; } description "The name of the album."; } leaf genre { type identityref { base genre; } description "The genre identifying the type of music on the album."; Bierman, et al. Expires April 30, 2017 [Page 108] Internet-Draft RESTCONF October 2016 } leaf year { type uint16 { range "1900 .. max"; } description "The year the album was released"; } container admin { description "Administrative information for the album."; leaf label { type string; description "The label that released the album."; } leaf catalogue-number { type string; description "The album's catalogue number."; } } list song { key name; description "Represents one song resource within one album resource, within the jukebox library."; leaf name { type string { length "1 .. max"; } description "The name of the song"; } leaf location { type string; mandatory true; description "The file location string of the media file for the song"; } leaf format { type string; description "An identifier string for the media type for the file associated with the Bierman, et al. Expires April 30, 2017 [Page 109] Internet-Draft RESTCONF October 2016 'location' leaf for this entry."; } leaf length { type uint32; units "seconds"; description "The duration of this song in seconds."; } } // end list 'song' } // end list 'album' } // end list 'artist' leaf artist-count { type uint32; units "songs"; config false; description "Number of artists in the library"; } leaf album-count { type uint32; units "albums"; config false; description "Number of albums in the library"; } leaf song-count { type uint32; units "songs"; config false; description "Number of songs in the library"; } } // end library list playlist { key name; description "Example configuration data resource"; leaf name { type string; description "The name of the playlist."; } leaf description { type string; description "A comment describing the playlist."; } Bierman, et al. Expires April 30, 2017 [Page 110] Internet-Draft RESTCONF October 2016 list song { key index; ordered-by user; description "Example nested configuration data resource"; leaf index { // not really needed type uint32; description "An arbitrary integer index for this playlist song."; } leaf id { type instance-identifier; mandatory true; description "Song identifier. Must identify an instance of /jukebox/library/artist/album/song/name."; } } } container player { description "Represents the jukebox player resource."; leaf gap { type decimal64 { fraction-digits 1; range "0.0 .. 2.0"; } units "tenths of seconds"; description "Time gap between each song"; } } } rpc play { description "Control function for the jukebox player"; input { leaf playlist { type string; mandatory true; description "playlist name"; } leaf song-number { type uint32; mandatory true; Bierman, et al. Expires April 30, 2017 [Page 111] Internet-Draft RESTCONF October 2016 description "Song number in playlist to play"; } } } } Appendix D. RESTCONF Message Examples The examples within this document use the normative YANG module "ietf-restconf" defined in Section 8 and the non-normative example YANG module "example-jukebox" defined in Appendix C.1. This section shows some typical RESTCONF message exchanges. D.1. Resource Retrieval Examples D.1.1. Retrieve the Top-level API Resource The client starts by retrieving the RESTCONF root resource: GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml The server might respond: HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn The client may then retrieve the top-level API resource, using the root resource "/restconf". GET /restconf HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond as follows: Bierman, et al. Expires April 30, 2017 [Page 112] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-restconf:restconf" : { "data" : {}, "operations" : {}, "yang-library-version" : "2016-06-21" } } To request that the response content to be encoded in XML, the "Accept" header can be used, as in this example request: GET /restconf HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server will return the same conceptual data either way, which might be as follows : HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+xml 2016-06-21 D.1.2. Retrieve The Server Module Information It is possible the YANG library module will change over time. The client can retrieve the revision date of the ietf-yang-library supported by the server from the API resource, as described in the previous section. In this example the client is retrieving the modules information from the server in JSON format: GET /restconf/data/ietf-yang-library:modules-state HTTP/1.1 Host: example.com Accept: application/yang-data+json Bierman, et al. Expires April 30, 2017 [Page 113] Internet-Draft RESTCONF October 2016 The server might respond as follows: HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Cache-Control: no-cache Last-Modified: Sun, 22 Apr 2016 01:00:14 GMT Content-Type: application/yang-data+json { "ietf-yang-library:modules-state" : { "module-set-id" : "5479120c17a619545ea6aff7aa19838b036ebbd7", "module" : [ { "name" : "foo", "revision" : "2012-01-02", "schema" : "https://example.com/modules/foo/2012-01-02", "namespace" : "http://example.com/ns/foo", "feature" : [ "feature1", "feature2" ], "deviation" : [ { "name" : "foo-dev", "revision" : "2012-02-16" } ], "conformance-type" : "implement" }, { "name" : "ietf-yang-library", "revision" : "2016-06-21", "schema" : "https://example.com/modules/\ ietf-yang-library/2016-06-21", "namespace" : "urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type" : "implement" }, { "name" : "foo-types", "revision" : "2012-01-05", "schema" : "https://example.com/modules/foo-types/2012-01-05", "namespace" : "http://example.com/ns/foo-types", "conformance-type" : "import" }, { "name" : "bar", "revision" : "2012-11-05", "schema" : "https://example.com/modules/bar/2012-11-05", Bierman, et al. Expires April 30, 2017 [Page 114] Internet-Draft RESTCONF October 2016 "namespace" : "http://example.com/ns/bar", "feature" : [ "bar-ext" ], "conformance-type" : "implement", "submodule" : [ { "name" : "bar-submod1", "revision" : "2012-11-05", "schema" : "https://example.com/modules/bar-submod1/2012-11-05" }, { "name" : "bar-submod2", "revision" : "2012-11-05", "schema" : "https://example.com/modules/bar-submod2/2012-11-05" } ] } ] } } D.1.3. Retrieve The Server Capability Information In this example the client is retrieving the capability information from the server in XML format, and the server supports all the RESTCONF query parameters, plus one vendor parameter: GET /restconf/data/ietf-restconf-monitoring:restconf-state/\ capabilities HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond as follows: HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:02:00 GMT Server: example-server Cache-Control: no-cache Last-Modified: Sun, 22 Apr 2016 01:00:14 GMT Content-Type: application/yang-data+xml Bierman, et al. Expires April 30, 2017 [Page 115] Internet-Draft RESTCONF October 2016 \ urn:ietf:params:restconf:capability:defaults:1.0?\ basic-mode=explicit\ \ urn:ietf:params:restconf:capability:with-defaults:1.0\ \ urn:ietf:params:restconf:capability:depth:1.0\ \ urn:ietf:params:restconf:capability:fields:1.0\ \ urn:ietf:params:restconf:capability:filter:1.0\ \ urn:ietf:params:restconf:capability:start-time:1.0\ \ urn:ietf:params:restconf:capability:stop-time:1.0\ \ http://example.com/capabilities/myparam\ D.2. Edit Resource Examples D.2.1. Create New Data Resources To create a new "artist" resource within the "library" resource, the client might send the following request. POST /restconf/data/example-jukebox:jukebox/library HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:artist" : [ { "name" : "Foo Fighters" } ] } Bierman, et al. Expires April 30, 2017 [Page 116] Internet-Draft RESTCONF October 2016 If the resource is created, the server might respond as follows: HTTP/1.1 201 Created Date: Mon, 23 Apr 2016 17:02:00 GMT Server: example-server Location: https://example.com/restconf/data/\ example-jukebox:jukebox/library/artist=Foo%20Fighters Last-Modified: Mon, 23 Apr 2016 17:02:00 GMT ETag: "b3830f23a4c" To create a new "album" resource for this artist within the "jukebox" resource, the client might send the following request: POST /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml Wasting Light 2011 If the resource is created, the server might respond as follows: HTTP/1.1 201 Created Date: Mon, 23 Apr 2016 17:03:00 GMT Server: example-server Location: https://example.com/restconf/data/\ example-jukebox:jukebox/library/artist=Foo%20Fighters/\ album=Wasting%20Light Last-Modified: Mon, 23 Apr 2016 17:03:00 GMT ETag: "b8389233a4c" D.2.2. Detect Resource Entity-Tag Change In this example, the server just supports the datastore last-changed timestamp. After the previous request, the client has cached the "Last-Modified" header and the Location header from the response to provide in the following request to patch an "album" list entry with key value "Wasting Light". Only the "genre" field is being updated. Bierman, et al. Expires April 30, 2017 [Page 117] Internet-Draft RESTCONF October 2016 PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light/\ genre HTTP/1.1 Host: example.com If-Unmodified-Since: Mon, 23 Apr 2016 17:03:00 GMT Content-Type: application/yang-data+json { "example-jukebox:genre" : "example-jukebox:alternative" } In this example the datastore resource has changed since the time specified in the "If-Unmodified-Since" header. The server might respond: HTTP/1.1 412 Precondition Failed Date: Mon, 23 Apr 2016 19:01:00 GMT Server: example-server Last-Modified: Mon, 23 Apr 2016 17:45:00 GMT ETag: "b34aed893a4c" D.2.3. Edit a Datastore Resource In this example, assume there is a top-level data resource named "system" from the example-system module, and this container has a child leaf called "enable-jukebox-streaming": container system { leaf enable-jukebox-streaming { type boolean; } } In this example PATCH is used by the client to modify 2 top-level resources at once, in order to enable jukebox streaming and add an "album" sub-resource to each of 2 "artist" resources: PATCH /restconf/data HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml Bierman, et al. Expires April 30, 2017 [Page 118] Internet-Draft RESTCONF October 2016 true Foo Fighters One by One 2012 Nick Cave and the Bad Seeds Tender Prey 1988 D.2.4. Replace a Datastore Resource In this example, the entire configuration datastore contents are being replaced. Any child nodes not present in the element but present in the server will be deleted. PUT /restconf/data HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml Bierman, et al. Expires April 30, 2017 [Page 119] Internet-Draft RESTCONF October 2016 Foo Fighters One by One 2012 Nick Cave and the Bad Seeds Tender Prey 1988 D.2.5. Edit a Data Resource In this example, the client modifies one data node by adding an "album" sub-resource by sending a PATCH for the data resource: PATCH /restconf/data/example-jukebox:jukebox/library/\ artist=Nick%20Cave%20and%20the%20Bad%20Seeds HTTP/1.1 Host: example.com Content-Type: application/yang-data+xml Nick Cave and the Bad Seeds The Good Son 1990 D.3. Query Parameter Examples D.3.1. "content" Parameter The "content" parameter is used to select the type of data child resources (configuration and/or not configuration) that are returned by the server for a GET method request. Bierman, et al. Expires April 30, 2017 [Page 120] Internet-Draft RESTCONF October 2016 In this example, a simple YANG list that has configuration and non- configuration child resources. container events list event { key name; leaf name { type string; } leaf description { type string; } leaf event-count { type uint32; config false; } } } Example 1: content=all To retrieve all the child resources, the "content" parameter is set to "all", or omitted, since this is the default value. The client might send: GET /restconf/data/example-events:events?\ content=all HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: Bierman, et al. Expires April 30, 2017 [Page 121] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:11:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+json { "example-events:events" : { "event" : [ { "name" : "interface-up", "description" : "Interface up notification count", "event-count" : 42 }, { "name" : "interface-down", "description" : "Interface down notification count", "event-count" : 4 } ] } } Example 2: content=config To retrieve only the configuration child resources, the "content" parameter is set to "config". Note that the "ETag" and "Last-Modified" headers are only returned if the content parameter value is "config". GET /restconf/data/example-events:events?\ content=config HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: Bierman, et al. Expires April 30, 2017 [Page 122] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:11:30 GMT Server: example-server Last-Modified: Mon, 23 Apr 2016 13:01:20 GMT ETag: "eeeada438af" Cache-Control: no-cache Content-Type: application/yang-data+json { "example-events:events" : { "event" : [ { "name" : "interface-up", "description" : "Interface up notification count" }, { "name" : "interface-down", "description" : "Interface down notification count" } ] } } Example 3: content=nonconfig To retrieve only the non-configuration child resources, the "content" parameter is set to "nonconfig". Note that configuration ancestors (if any) and list key leafs (if any) are also returned. The client might send: GET /restconf/data/example-events:events?\ content=nonconfig HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: Bierman, et al. Expires April 30, 2017 [Page 123] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:11:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+json { "example-events:events" : { "event" : [ { "name" : "interface-up", "event-count" : 42 }, { "name" : "interface-down", "event-count" : 4 } ] } } D.3.2. "depth" Parameter The "depth" parameter is used to limit the number of levels of child resources that are returned by the server for a GET method request. The depth parameter starts counting levels at the level of the target resource that is specified, so that a depth level of "1" includes just the target resource level itself. A depth level of "2" includes the target resource level and its child nodes. This example shows how different values of the "depth" parameter would affect the reply content for retrieval of the top-level "jukebox" data resource. Example 1: depth=unbounded To retrieve all the child resources, the "depth" parameter is not present or set to the default value "unbounded". GET /restconf/data/example-jukebox:jukebox?\ depth=unbounded HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: HTTP/1.1 200 OK Bierman, et al. Expires April 30, 2017 [Page 124] Internet-Draft RESTCONF October 2016 Date: Mon, 23 Apr 2016 17:11:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+json { "example-jukebox:jukebox" : { "library" : { "artist" : [ { "name" : "Foo Fighters", "album" : [ { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011, "song" : [ { "name" : "Wasting Light", "location" : "/media/foo/a7/wasting-light.mp3", "format" : "MP3", "length" : 286 }, { "name" : "Rope", "location" : "/media/foo/a7/rope.mp3", "format" : "MP3", "length" : 259 } ] } ] } ] }, "playlist" : [ { "name" : "Foo-One", "description" : "example playlist 1", "song" : [ { "index" : 1, "id" : "/example-jukebox:jukebox/library\ /artist[name='Foo Figthers']\ /album[name='Wasting Light']\ /song[name=Rope']" }, Bierman, et al. Expires April 30, 2017 [Page 125] Internet-Draft RESTCONF October 2016 { "index" : 2, "id" : "/example-jukebox:jukebox/library\ /artist[name='Foo Figthers']\ /album[name='Wasting Light']\ /song[name=Bridge Burning']" } ] } ], "player" : { "gap" : 0.5 } } } Example 2: depth=1 To determine if 1 or more resource instances exist for a given target resource, the value one is used. GET /restconf/data/example-jukebox:jukebox?depth=1 HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:11:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+json { "example-jukebox:jukebox" : {} } Example 3: depth=3 To limit the depth level to the target resource plus 2 child resource layers the value "3" is used. GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond: Bierman, et al. Expires April 30, 2017 [Page 126] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:11:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+json { "example-jukebox:jukebox" : { "library" : { "artist" : {} }, "playlist" : [ { "name" : "Foo-One", "description" : "example playlist 1", "song" : {} } ], "player" : { "gap" : 0.5 } } } D.3.3. "fields" Parameter In this example the client is retrieving the datastore resource in JSON format, but retrieving only the "modules-state/module" list, and only the "name" and "revision" nodes from each list entry. Note that top node returned by the server matches the target resource node (which is "data" in this example). The "module-set-id" leaf is not returned because it is not selected in the fields expression. GET /restconf/data?fields=ietf-yang-library:modules-state/\ module(name;revision) HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond as follows. [RFC Editor Note: Adjust the date for ietf-restconf-monitoring below to the date in the published ietf-restconf-monitoring YANG module, and remove this note.] Bierman, et al. Expires April 30, 2017 [Page 127] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-restconf:data" : { "ietf-yang-library:modules-state" : { "module" : [ { "name" : "example-jukebox", "revision" : "2015-06-04" }, { "name" : "ietf-inet-types", "revision" : "2013-07-15" }, { "name" : "ietf-restconf-monitoring", "revision" : "2016-03-16" }, { "name" : "ietf-yang-library", "revision" : "2016-06-21" }, { "name" : "ietf-yang-types", "revision" : "2013-07-15" } ] } } } D.3.4. "insert" Parameter In this example, a new first song entry in the "Foo-One" playlist is being created. Request from client: Bierman, et al. Expires April 30, 2017 [Page 128] Internet-Draft RESTCONF October 2016 POST /restconf/data/example-jukebox:jukebox/\ playlist=Foo-One?insert=first HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:song" : [ { "index" : 1, "id" : "/example-jukebox:jukebox/library\ /artist[name='Foo Figthers']\ /album[name='Wasting Light']\ /song[name=Rope']" } ] } Response from server: HTTP/1.1 201 Created Date: Mon, 23 Apr 2016 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2016 13:01:20 GMT Location: https://example.com/restconf/data/\ example-jukebox:jukebox/playlist=Foo-One/song=1 ETag: "eeeada438af" D.3.5. "point" Parameter In this example, the client is inserting a new song entry in the "Foo-One" playlist after the first song. Request from client: Bierman, et al. Expires April 30, 2017 [Page 129] Internet-Draft RESTCONF October 2016 POST /restconf/data/example-jukebox:jukebox/\ playlist=Foo-One?insert=after&point=\ %2Fexample-jukebox%3Ajukebox\ %2Fplaylist%3DFoo-One%2Fsong%3D1 HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:song" : [ { "index" : 2, "id" : "/example-jukebox:jukebox/library\ /artist[name='Foo Figthers']\ /album[name='Wasting Light']\ /song[name=Bridge Burning']" } ] } Response from server: HTTP/1.1 201 Created Date: Mon, 23 Apr 2016 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2016 13:01:20 GMT Location: https://example.com/restconf/data/\ example-jukebox:jukebox/playlist=Foo-One/song=2 ETag: "abcada438af" D.3.6. "filter" Parameter The following URIs show some examples of notification filter specifications: Bierman, et al. Expires April 30, 2017 [Page 130] Internet-Draft RESTCONF October 2016 // filter = /event/event-class='fault' GET /streams/NETCONF?filter=%2Fevent%2Fevent-class%3D'fault' // filter = /event/severity<=4 GET /streams/NETCONF?filter=%2Fevent%2Fseverity%3C%3D4 // filter = /linkUp|/linkDown GET /streams/SNMP?filter=%2FlinkUp%7C%2FlinkDown // filter = /*/reporting-entity/card!='Ethernet0' GET /streams/NETCONF?\ filter=%2F*%2Freporting-entity%2Fcard%21%3D'Ethernet0' // filter = /*/email-addr[contains(.,'company.com')] GET /streams/critical-syslog?\ filter=%2F*%2Femail-addr[contains(.%2C'company.com')] // Note: the module name is used as prefix. // filter = (/example-mod:event1/name='joe' and // /example-mod:event1/status='online') GET /streams/NETCONF?\ filter=(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and\ %20%2Fexample-mod%3Aevent1%2Fstatus%3D'online') // To get notifications from just two modules (e.g., m1 + m2) // filter=(/m1:* or /m2:*) GET /streams/NETCONF?filter=(%2Fm1%3A*%20or%20%2Fm2%3A*) D.3.7. "start-time" Parameter The following URI shows an example of the "start-time" query parameter: // start-time = 2014-10-25T10:02:00Z GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z D.3.8. "stop-time" Parameter The following URI shows an example of the "stop-time" query parameter: // start-time = 2014-10-25T10:02:00Z // stop-time = 2014-10-25T12:31:00Z GET /mystreams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\ &stop-time=2014-10-25T12%3A31%3A00Z Bierman, et al. Expires April 30, 2017 [Page 131] Internet-Draft RESTCONF October 2016 D.3.9. "with-defaults" Parameter Assume the server implements the module "example" defined in Appendix A.1 of [RFC6243]. Assume the server's datastore is as defined in Appendix A.2 of [RFC6243]. If the server defaults-uri basic-mode is "trim", the the following request for interface "eth1" might be as follows: Without query parameter: GET /restconf/data/example:interfaces/interface=eth1 HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond as follows. HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Content-Type: application/yang-data+json { "example:interface" : [ { "name" : "eth1", "status" : "up" } ] } Note that the "mtu" leaf is missing because it is set to the default "1500", and the server defaults handling basic-mode is "trim". With query parameter: GET /restconf/data/example:interfaces/interface=eth1\ ?with-defaults=report-all HTTP/1.1 Host: example.com Accept: application/yang-data+json The server might respond as follows. Bierman, et al. Expires April 30, 2017 [Page 132] Internet-Draft RESTCONF October 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2016 17:01:00 GMT Server: example-server Content-Type: application/yang-data+json { "example:interface" : [ { "name" : "eth1", "mtu" : 1500, "status" : "up" } ] } Note that the server returns the "mtu" leaf because the "report-all" mode was requested with the "with-defaults" query parameter. Authors' Addresses Andy Bierman YumaWorks Email: andy@yumaworks.com Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Kent Watsen Juniper Networks Email: kwatsen@juniper.net Bierman, et al. Expires April 30, 2017 [Page 133] ./draft-iab-carisreport-02.txt0000664000764400076440000010701513033502650015516 0ustar iustyiusty Network K. Moriarty Internet-Draft Dell EMC Corporation Intended status: Informational M. Ford Expires: July 9, 2017 Internet Society January 05, 2017 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report draft-iab-carisreport-02 Abstract This report documents the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 9, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Moriarty & Ford Expires July 9, 2017 [Page 1] Internet-Draft CARIS January 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Sessions and Panel Groups . . . . . . . . . . . . . . . . . . 4 2.1. Coordination between CSIRTs and Attack Response Mitigation Efforts . . . . . . . . . . . . . . . . . . . 4 2.2. Scaling Response to DDoS and Botnets Effectively and Safely . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. DNS & RIRs: Attack Response and Mitigation . . . . . . . 8 2.4. Trust Privacy and Data Markings Panel . . . . . . . . . . 9 3. Workshop Themes . . . . . . . . . . . . . . . . . . . . . . . 11 4. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. RIR and DNS Provider Resources . . . . . . . . . . . . . 11 4.2. Education and Guidance . . . . . . . . . . . . . . . . . 11 4.3. Transport Options . . . . . . . . . . . . . . . . . . . . 12 4.4. Updated Template for Information Exchange Groups . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Informative References . . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix B. Workshop Attendees . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Internet Architecture Board (IAB) and the Internet Society (ISOC) hosted a day-long Coordinating Attack Response at Internet Scale (CARIS) workshop on 18 June 2015 in coordination with the Forum for Incident Response and Security Teams (FIRST) Conference in Berlin. The workshop included members of the FIRST community, attack response working group representatives, network and security operators, Regional Internet Registry (RIR) representatives, researchers, vendors, and representatives from standardisation communities. Key goals of the workshop were to improve mutual awareness, understanding, and coordination among the diverse participating organizations. The workshop also aimed to provide the attendees with greater awareness of existing efforts to mitigate specific types of attacks, and greater understanding of the options available to collaborate and engage with these efforts. Moriarty & Ford Expires July 9, 2017 [Page 2] Internet-Draft CARIS January 2017 The day-long workshop included a mix of invited talks and panel discussion sessions with opportunities to collaborate throughout, taking full advantage of the tremendous value of having these diverse communities with common goals in one room. There were approximately 50 participants engaged in the CARIS workshop. Attendance at the workshop was by invitation only. Prior to the workshop, existing attack-mitigation working groups were asked to complete a survey. The data gathered through this questionnaire, including how third parties can participate in or contribute to the attack-mitigation working group, was shared with all of the participants at the workshop to better enable collaboration [ISOC]. Attendees were also selected from submissions of 2-page position papers that included some key insight or challenge relevant to the broader group. Paper topics included research topics related to attack mitigation or information sharing/exchange, success stories, lessons learned, and more in-depth studies on specific topics such as privacy or trust. The program committee received 25 papers and 19 template submissions. The template submissions will be maintained by the Internet Society and as a result of the workshop they will be amended to provide additional value to the computer security incident response teams (CSIRTs) and attack response communities/operators on their information exchange capabilities. The CARIS participants found the template submissions to be very useful in coordinating their future attack mitigation efforts. This is a new initiative and is open for the global community and hosted in a neutral location. All submissions are available online and linked from the agenda [AGENDA]. The workshop talks and panels involved full participation from attendees who were required to read all the submitted materials. The panels were organized to spur conversation between specific groups to see if progress could be made towards more efficient and effective attack mitigation efforts. See [KME1] and [KME2] for additional information on possible approaches to accomplish more effective attack response and information exchanges with methods that require fewer analysts. The workshop was run under the Chatham House Rule to facilitate the exchange of sensitive information involved with incident response. As such, there was no recording, but minutes were taken and used to aid in the generation of this report. Comments will not be attributed to any particular attendee, nor will organizations be named in association with any discussion topics that were not made public through submission templates or papers by the submitter and organization. Moriarty & Ford Expires July 9, 2017 [Page 3] Internet-Draft CARIS January 2017 2. Sessions and Panel Groups After an initial presentation to set the stage and elaborate the goals of the workshop, the day was divided into five sessions as follows. 1. Coordination between CSIRTs and attack response mitigation efforts 2. Scaling response to DDoS and botnets effectively and safely 3. Infrastructure: DNS and RIR providers and researchers 4. Trust and Privacy with the exchange of potentially sensitive information 5. Implications for Internet architecture and next steps The remainder of this report will provide more detail on each of these sessions. 2.1. Coordination between CSIRTs and Attack Response Mitigation Efforts The first panel session on Coordination between CSIRTs and attack mitigation efforts included representatives from several organizations that submitted templates describing their organization's attack mitigation efforts. This panel was purposefully a cross section of organizations attending to see if there were new opportunities to collaborate and improve efficiency thereby better scaling attack mitigation. The panelists described their efforts with the following questions in mind: o What is the use case for their organization? o Where are they focusing their efforts? o How can others engage with their organization? o Who participates in their organization today? For each of the following organizations, additional information can be found in their template submissions [ISOC]. The following summaries are to be read in the context of the workshop and not as stand alone descriptions for each organization. These summaries are a result of the workshop discussions. Moriarty & Ford Expires July 9, 2017 [Page 4] Internet-Draft CARIS January 2017 o ENISA is the European Network and Information Security Agency [ENISA]. While ENISA provides support for the community in the form of education, training and collaboration on security and attack mitigation, it does not offer a service for attack response or mitigation. o The Anti-Phishing Working Group (APWG) offered examples of operator driven exchanges focused on specific use cases that involve hundreds of participating organizations daily. The APWG operates a data clearinghouse and provides infrastructure to support meaningful data exchanges and maintains a current set of data through these interactions. More can be learned on the APWG web site [APWG] in addition to their template submission. o The Research and Education Networking Information Sharing and Analysis Center (Ren-ISAC) employs an interesting operational model that scales well through automation, exchanging actionable information between 500 universities and automatically implementing controls. Since many universities cannot respond to incidents in real-time due to a scarcity of resources, REN-ISAC leverages a small number of analysts to accomplish the task of protecting many universities through automation. The key to the success of their project is providing tools that allow organizations to make use of incident data operationally. They are currently working to develop open-source tools to track metrics more formally [REN-ISAC]. o CERT.br is the Brazilian Computer Emergency Response Team (CERT) and they have made impressive progress in a short amount of time. CERT.br is the national focal point for incident reporting, collection and dissemination of threat and attack trend information in Brazil. CERT.br works to increase awareness and incident-handling capabilities in country as well as assisting to establish new CSIRTs. In addition to providing training and awareness campaigns, they distribute network security honeypots and have a primary focus on network monitoring. CERT.br requires active participation from third parties wishing to collaborate and exchange data with them [CERT.BR]. o MyCERT's mission is to address the security concerns of Malaysian Internet users and reduce the probability of successful attacks [MYCERT]. They have been operational since 1997. MyCERT is responsible for incident handling of unauthorised intrusions, identity theft, DDoS attacks, etc. MyCERT handles computer security incidents in Malaysia, provides malware research, and technical coordination. In addition to incident response and coordination activities, MyCERT members provide talks and training, as well as local and regional security exercises. Moriarty & Ford Expires July 9, 2017 [Page 5] Internet-Draft CARIS January 2017 MyCERT also provides incident alerts and advisories on vulnerabilities, breaches, etc. o The CERT Coordination Center (CERT/CC) has been operational since 1998 on an international and national scale [CERTCC]. They have long been known for their software vulnerability work and the national vulnerability database in the US (Common Vulnerabilities and Exposures - CVEs) and informing organizations of vulnerabilities. CERT/CC helps to coordinate between vendors and researchers for improved collaborations. CERT/CC provides guidance on dealing with the aftermath of incidents, risk assessment best practice, bug bounties, and other incident related areas. Highlights from the panel discussion: o Passive surveillance by state actors has impacted incident response activities due to the erosion of trust between communities. o Government involvement in information exchange efforts hasn't been productive, despite lots of discussion there have not been useful outcomes. o There is more interest in consuming feeds of information than sharing information. o Ego has been a big issue for improving data sharing, as have reputation-related concerns when sharing or receiving data. o There is a perception of weakness around organizations who do share attack information in some regions. o Sharing in isolation doesn't help, it must lead to operational return on investment. o Language barriers have been an issue for some national CSIRTs. o Sharing too much information leads to capacity and resource issues for receiving organizations. Organizations directly receiving feeds can often misinterpret data and think they are under attack when it is not the case. Operational models are preferred where data exchanges have a direct impact on improving the efficiency of a small number of analysts to impact many. o Privacy regulations restricting some organizations from sharing IP address information have had an impact on the effectiveness of Moriarty & Ford Expires July 9, 2017 [Page 6] Internet-Draft CARIS January 2017 incident data exchanges. ENISA is currently running a study on this impact (this point was raised by several attendees). o Too many efforts are using data just for blocking attacks and not for operational mitigation and elimination of vulnerabilities as part of their incident response effort. Note: Operational efforts stand out in that they do eliminate threats and update data warehouses. o Involvement of vendors is needed to better scale attack response. This is not seen as a need by all groups, but some sharing groups with an operational focus are looking for improved efficiencies to leverage a small number of analysts more productively. Analysts are a limited resource in this technical area of expertise. o Enterprises don't want more security boxes in their networks as they don't have the resources to manage them, so involving vendors doesn't mean deploying more equipment, but improving automated controls and the elimination of threats wherever possible. False positives are still an issue, which can be problematic for some automation activities. 2.2. Scaling Response to DDoS and Botnets Effectively and Safely The first invited talk at the workshop provided an interesting history of Distributed Denial of Service (DDoS) attacks and the evolution of botnets as well as the methods to combat these threats. The paper by Dave Dittrich [DD1] is available to learn more of this history: this section of the report will focus on the workshop discussion in an effort to benefit from the workshop attendees' thoughts concerning how to better scale our response to these threats. Key points from the discussion: o Of the attack types discussed, DDoS and botnets appear to be the furthest along in terms of efficient and effective response. Other efforts can learn from this experience. There has not been any interaction between these two attack types that may benefit from information exchange tied to remediation activities since botnets can be the source of DDoS attacks. o There is a disparity between short-term mitigation goals and actual eradication of DDoS and botnet threats. The question was raised: how do we normalize the same data in different ways to serve different goals? In other words, DDoS traffic is often the result of botnets, but the data is not shared between the service Moriarty & Ford Expires July 9, 2017 [Page 7] Internet-Draft CARIS January 2017 providers and vendors responding to DDoS threats and those actively mitigating and eradicating botnets. o There are ad-hoc trust groups within the OpSec community today: the Cybercrime Response Advisory Group (CRAG) is one example. o Filtering and triage is an issue, but this is a solvable problem. o The IETF DDOS Open Threat Signaling (DOTS) working group was discussed and compared to a previous effort, Real-time Inter- network defense (RID) [RFC6545]. It was stated that the two are similar, except DOTS makes use of current data formats and protocols and has the support of multiple DDoS vendors. One of the goals of DOTS is to have this solution be the "glue" between vendors to communicate shared data using standard formats and protocols developed in open source tools. o The IETF Interface to Network Security Functions (I2NSF) effort was discussed to explore ways to leverage infrastructure to combat DDoS attacks. o Vendors discussed existing capabilities for DDoS mitigation, while data sharing groups discussed their mitigation activities related to botnets (see the submissions under the heading 'Panel on Scaling Attack Response for DDoS and BotNets' in the workshop agenda [AGENDA]). o Trust and reputation of data sources is still a concern. o One of the exchange groups has a goal of "automated takedowns" for botnets. However, they think they will always have a need for manual intervention. o The need for multiple levels of trust seemed to be prevalent among those participating in the panel discussion. Intelligence agencies erode trust (this was also mentioned in the first panel in terms of surveillance activities from governments). o Although trust was discussed in this panel and there are concerns, it was noted that trust is not as big a barrier for DDoS and botnet mitigation and this is likely due to the operational experience of the participants. 2.3. DNS & RIRs: Attack Response and Mitigation This session was a shift from other sessions in the day as the panelists were infrastructure providers for those combating attacks. This session was of interest to see how attack and incident Moriarty & Ford Expires July 9, 2017 [Page 8] Internet-Draft CARIS January 2017 responders could better collaborate with DNS infrastructure organisations and RIRs. These groups have not interacted in the past and it was interesting to see the collaboration opportunities since the workshop participants rely on these services to do their jobs. From the panelists' perspective, DNS and RIRs are separate worlds, where they spend a lot of time trying to educate policymakers about how they work together to make the Internet work. Key discussion points: o The use of passive DNS in attack mitigation was described. o RIRs discussed the data they maintain and provide, including worldwide BGP update data and root DNS server data. These datasets are available to share with researchers and could be of interest to those working on attack response. The current way the data is made available does not scale and ideas were discussed in the workshop to improve the scalability should this become a more widely used resource. o Some of the global RIRs already actively coordinate with incident responders in their region. In some cases they do facilitate information sharing as well as provide education and training. Data shared out by RIRs is anonymized. o A concern was raised regarding overlapping efforts and a request was made for the IETF and ISOC to pay attention to this and help. This workshop was one step toward that in bringing together this diverse community. The participants wished to see this type of event repeated for future cross area collaboration between the diverse set of groups that often only meet within their silo. o Standards for APIs to access data consistently from RIRs and scoring methods were discussed as possible ways to scale trust. Questions were raised as to how this might be possible. One might receive unverifiable data about a network. They may be able to verify the source's identity, verify route origins, but won't be able to verify the provenance of data. 2.4. Trust Privacy and Data Markings Panel Why don't organizations share data? It seems to be a mix of privacy, legal, technical/mundane, cultural, and communication issues. There are also concerns about sharing proprietary data with competitors. Having said that, most of these reasons were dismissed as bogus by the more operationally focused participants in the workshop. Lawyers need contextual education for the intersection of law and technology. Moriarty & Ford Expires July 9, 2017 [Page 9] Internet-Draft CARIS January 2017 Sensitive data is still an issue as one can't control what others do with data once it is shared. Key points from the panel discussion: o Operationally focused groups do retain/rate/re-mark confidence levels based upon the submitter's reputation. o The Traffic Light Protocol (TLP) [TLP] was discussed. While TLP is useful to some groups who exchange data, others find that it is not granular enough for their needs. o In many cases when data is shared the user never knows, and there is no way to manage that disclosure. o Trust is personal. When sharing circles get too large, trust breaks down. The personal relationship aspect of information sharing communities was emphasized by several who are actively exchanging data. This was a very prevalent theme. o A point of comparison was made with consumer goods and it was observed that trademarks are a byproduct of the Industrial Revolution. The question was raised: does trust need branding? o Participants observing noted that there appear to be cabals operating the groups based on the current trust notions. This was not disputed. o Transparency is vital to maintain trust. o Participants working on automation have found a need to share with organizations of all sizes as well as a need to share both synchronously and asynchronously. In an automated model, they must ensure data sources are 'authorized' and these efforts have encountered questions about anonymization as well as regional regulatory perspectives as they vary. o Another automation effort found that people have different upper limits for trust group scale, which is sometimes based on individualized knowledge of other participants and having a comfort level with them. Social interaction (beer) is a common thread amongst sharing partners to build trust relationships. The relationships are formed between individuals and not necessarily between organizations. o It's rare for any single piece of information to be clearly identifiable as private or public. The temptation is to say Moriarty & Ford Expires July 9, 2017 [Page 10] Internet-Draft CARIS January 2017 information isn't personally identifiable information (PII). In aggregate, however, non-PII can become PII. o There was common agreement that reputation is fundamental. 3. Workshop Themes During the course of the day, a couple of themes recurred in the discussions. Firstly, in order to better scale attack response through improvements to the efficiency and effectiveness of information exchanges: 1. Data exchanges should not be just for the purpose of creating blacklists that could be redundant efforts. 2. Involving service providers and vendors to better coordinate and scale response is key. Secondly, information security practitioners are a scarce resource: 1. Training and education was discussed to improve this gap, both to train information security professionals and others in IT on basic network and system hygiene. 2. Leveraging resources to better scale response, using fewer resources is critical. 4. Next Steps 4.1. RIR and DNS Provider Resources Workshop participants expressed an interest in expanded information on the resources and assistance offered by the RIRs and DNS providers. Participants are going to define what is needed. 4.2. Education and Guidance Another recurring theme was the lack of knowledge in the community of basic security principles such as ingress and egress filtering explained in BCP38 [RFC2827]. The CSIRTs, operators, and vendors of attack mitigation tools found this particularly frustrating. As a result, follow up activities may include determining if security guidance BCPs require updates or to determine whether there are opportunities to educate people on these basic principles already documented by the IETF. Moriarty & Ford Expires July 9, 2017 [Page 11] Internet-Draft CARIS January 2017 4.3. Transport Options One of the more lively discussions was the need for better transports for information exchange. Real-time Inter-network Defense (RID) [RFC6545] was written more than 10 years ago. While the patterns established in RID still show promise, there are updated solutions being worked on. One such solution is in the IETF DOTS working group, that has an approach similar to RID with updated formats and protocols to meet the demands of today's DDoS attacks. While Trusted Automated eXchange of Indicator Information (TAXII - another transport option) is just in transition to OASIS, its base is similar to RID in its use of SOAP-like messaging, which will likely prevent it from scaling to the demands of the Internet. Vendors also cited several interoperability challenges of TAXII in workshop discussions. Alternatively, XMPP-Grid has been proposed in the IETF Security Automation and Continuous Monitoring (SACM) working group and it offers promise as the data exchange protocol for deployment at scale. XMPP [RFC6120] inherently meets the requirements for today's information exchanges with features such as publish/subscribe, federation, and use of a control channel. XMPP-Grid is gaining traction with at least 10 vendors using it in their products and several more planning to add support [I-D.appala-mile-xmpp-grid]. Review and discussion of this draft would be helpful as it transitions to the Managed Incident Lightweight Exchange (MILE) working group as an outcome of the workshop. REST was also brought up as a needed interface because of the low barrier to use [REST]. The IETF MILE Working Group has discussed a draft detailing a common RESTful interface (ROLIE) that could be used with any data format and this may also be of interest [I-D.ietf-mile-rolie]. 4.4. Updated Template for Information Exchange Groups One of the submission options was for organizations actively exchanging data to submit a form describing their work to reduce computer security incidents. The CSIRTs, in particular, liked having access to this information in a neutral location like the Internet Society. However, they wanted to see amendments to the format to improve its usefulness. There was a desire to have this used by additional information exchange groups, thereby creating a living library to improve awareness of how to become a member, benefit from, or contribute to the success of the attack response and CSIRT information exchange platforms. 5. Security Considerations The CARIS workshop was focused on security and methods to improve the effectiveness and efficiency of attack response to enable better scaling. This report provides a summary of the workshop discussions Moriarty & Ford Expires July 9, 2017 [Page 12] Internet-Draft CARIS January 2017 and identifies some outcomes to improve security. As such, no additional considerations are provided in this section. 6. Informative References [AGENDA] "Agenda: Coordinating Attack Response at Internet Scale (CARIS) Workshop", 2015, . [APWG] "APWG Homepage", 2015, . [CERT.BR] "Brazilian National Computer Emergency Response Team Homepage", 2015, . [CERTCC] "CERT Coordination Center Homepage", 2015, . [DD1] Dittrich, D., "Taking Down Botnets - Background", April 2015, . [ENISA] "European Union Agency for Network and Information Security Homepage", 2015, . [I-D.appala-mile-xmpp-grid] Cam-Winget, N., Appala, S., and S. Pope, "XMPP Protocol Extensions for Use with IODEF", draft-appala-mile-xmpp- grid-00 (work in progress), October 2015. [I-D.ietf-mile-rolie] Field, J., Banghart, S., and D. Waltermire, "Resource- Oriented Lightweight Information Exchange", draft-ietf- mile-rolie-03 (work in progress), July 2016. [ISOC] "CARIS Workshop Template Submissions", 2015, . [KME1] Moriarty, K., "Transforming Expectations for Threat- Intelligence Sharing", August 2013, . [KME2] Moriarty, K., "Kathleen Moriarty Blog Series", July 2015, . [MYCERT] "Malaysia Computer Emergency Response Team Homepage", 2015, . Moriarty & Ford Expires July 9, 2017 [Page 13] Internet-Draft CARIS January 2017 [REN-ISAC] "Research and Education Networking Information Sharing and Analysis Center Homepage", 2015, . [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, DOI 10.17487/RFC6545, April 2012, . [TLP] "Traffic Light Protocol (TLP) Matrix and Frequently Asked Questions", 2015, . Appendix A. Acknowledgements Thanks are due to the members of the program committee (in alphabetical order) for their efforts to make the CARIS workshop possible and a productive session with cross area expertise: Matthew Ford (Internet Society, UK), Ted Hardie (Google, USA), Joe Hildebrand (Cisco, USA), Eliot Lear (Cisco, Switzerland), Kathleen M. Moriarty (EMC Corporation, USA), Andrew Sullivan (Dyn, USA), Brian Trammell (ETH Zurich, Switzerland). Thanks are also due to the CARIS workshop sponsors: o FIRST provided a room and excellent facilities in partnership with their annual conference in Berlin. o The Internet Society hosted the social event, a boat ride through the canals of Berlin. o EMC Corporation provided lunch, snacks and coffee throughout the day to keep the attendees going. Moriarty & Ford Expires July 9, 2017 [Page 14] Internet-Draft CARIS January 2017 Appendix B. Workshop Attendees In alphabetical order by first name, workshop attendees were: Adli Wahid, Alexey Melnikov, Andrew Sullivan, Arnold Sykosch, Brian Trammell, Chris Morrow, Cristine Hoepers, Dario Forte, Dave Cridland, Dave Dittrich, Eliot Lear, Foy Shiver, Frank Xialiang, Graciella Martinez, Jessica Stienberger, Jim Duncan, Joe Hildebrand, John Bond, John Graham-Cummings, John Kristoff, Kathleen Moriarty, Klaus Steding-Jessen, Linda Dunbar, Marco Obiso, Martin Stiemerling, Mat Ford, Merike Kaeo, Michael Daly, Mio Suzuki, Mirjam Kuehne, Mr. Fu TianFu , Nancy Cam-Winget, Nik Teague, Pat Cain, Roland Dobbins, Roman Danyliw, Rosella Mattioli, Sandeep Bhatt , Scott Pinkerton, Sharifah Roziah Mohd Kassim, Stuart Murdoch, Takeshi Takahashi, Ted Hardie, Tobias Gondrom, Tom Millar, Tomas Sander, Ulrich Seldeslachts, Valerie Duncan, Wes Young Authors' Addresses Kathleen M. Moriarty Dell EMC Corporation 176 South Street Hopkinton, MA United States Email: Kathleen.Moriarty@dell.com Mat Ford Internet Society Galerie Jean-Malbuisson 15 Geneva Switzerland Email: ford@isoc.org Moriarty & Ford Expires July 9, 2017 [Page 15] ./draft-ietf-kitten-rfc6112bis-03.txt0000664000764400076440000012130413013166156016436 0ustar iustyiusty Network Working Group L. Zhu Internet-Draft P. Leach Obsoletes: 6112 (if approved) Microsoft Corporation Updates: 4120, 4121, 4556 (if approved) S. Hartman Intended status: Standards Track Painless Security Expires: May 20, 2017 S. Emery, Ed. Oracle November 16, 2016 Anonymity Support for Kerberos draft-ietf-kitten-rfc6112bis-03 Abstract This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as historic. RFC 6112 contained errors and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 20, 2017. Zhu, et al. Expires May 20, 2017 [Page 1] Internet-Draft Kerberos Anonymity Support November 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Changes Since RFC 6112 . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . 5 4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . 6 4.2. Anonymity Support in TGS Exchange . . . . . . . . . . . . 8 4.3. Subsequent Exchanges and Protocol Actions Common to AS and TGS for Anonymity Support . . . . . . . . . . . . . . 10 5. Interoperability Requirements . . . . . . . . . . . . . . . . 10 6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . 10 7. PKINIT Client Contribution to the Ticket Session Key . . . 11 7.1. Combining Two Protocol Keys . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 Zhu, et al. Expires May 20, 2017 [Page 2] Internet-Draft Kerberos Anonymity Support November 2016 11.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction In certain situations, the Kerberos [RFC4120] client may wish to authenticate a server and/or protect communications without revealing the client's own identity. For example, consider an application that provides read access to a research database and that permits queries by arbitrary requesters. A client of such a service might wish to authenticate the service, to establish trust in the information received from it, but might not wish to disclose the client's identity to the service for privacy reasons. Extensions to Kerberos are specified in this document by which a client can authenticate the Key Distribution Center (KDC) and request an anonymous ticket. The client can use the anonymous ticket to authenticate the server and protect subsequent client-server communications. By using the extensions defined in this specification, the client can request an anonymous ticket where the client may reveal the client's identity to the client's own KDC, or the client can hide the client's identity completely by using anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) as defined in Section 4.1. Using the returned anonymous ticket, the client remains anonymous in subsequent Kerberos exchanges thereafter to KDCs on the cross-realm authentication path and to the server with which it communicates. In this specification, the client realm in the anonymous ticket is the anonymous realm name when anonymous PKINIT is used to obtain the ticket. The client realm is the client's real realm name if the client is authenticated using the client's long-term keys. Note that a membership in a realm can imply a member of the community represented by the realm. The interaction with Generic Security Service Application Program Interface (GSS-API) is described after the protocol description. This specification replaces [RFC6112] to correct technical errors in that specification. RFC 6112 is classified as historic; implementation of RFC 6112 is NOT RECOMMENDED: existing implementations comply with this specification and not RFC 6112. Zhu, et al. Expires May 20, 2017 [Page 3] Internet-Draft Kerberos Anonymity Support November 2016 1.1. Changes Since RFC 6112 In Section 7, the pepper2 string, "KeyExchange", is corrected to comply with the string actually used by implementations. The requirement for the anonymous option to be used when an anonymous ticket is used in a TGS request is reduced from a MUST to a SHOULD. At least one implementation does not require this and is not necessary that both be used as an indicator of request type. Corrected the authorization data type name, AD-INITIAL-VERIFIED-CAS, referenced in this document. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definitions The anonymous Kerberos realm name is defined as a well-known realm name based on [RFC6111], and the value of this well-known realm name is the literal "WELLKNOWN:ANONYMOUS". The anonymous Kerberos principal name is defined as a well-known Kerberos principal name based on [RFC6111]. The value of the name- type field is KRB_NT_WELLKNOWN [RFC6111], and the value of the name- string field is a sequence of two KerberosString components: "WELLKNOWN", "ANONYMOUS". The anonymous ticket flag is defined as bit 16 (with the first bit being bit 0) in the TicketFlags: TicketFlags ::= KerberosFlags -- anonymous(16) -- TicketFlags and KerberosFlags are defined in [RFC4120] This is a new ticket flag that is used to indicate that a ticket is an anonymous one. An anonymous ticket is a ticket that has all of the following properties: o The cname field contains the anonymous Kerberos principal name. Zhu, et al. Expires May 20, 2017 [Page 4] Internet-Draft Kerberos Anonymity Support November 2016 o The crealm field contains the client's realm name or the anonymous realm name. o The anonymous ticket contains no information that can reveal the client's identity. However, the ticket may contain the client realm, intermediate realms on the client's authentication path, and authorization data that may provide information related to the client's identity. For example, an anonymous principal that is identifiable only as being in a particular group of users can be implemented using authorization data. Such authorization data, if included in the anonymous ticket, would disclose that the client is a member of the group observed. o The anonymous ticket flag is set. The anonymous KDC option is defined as bit 16 (with the first bit being bit 0) in the KDCOptions: KDCOptions ::= KerberosFlags -- anonymous(16) -- KDCOptions and KerberosFlags are defined in [RFC4120] As described in Section 4, the anonymous KDC option is set to request an anonymous ticket in an Authentication Service (AS) request or a Ticket Granting Service (TGS) request. 4. Protocol Description In order to request an anonymous ticket, the client sets the anonymous KDC option in an AS request or a TGS request. The rest of this section is organized as follows: it first describes protocol actions specific to AS exchanges, then it describes those of TGS exchanges. These are then followed by the description of protocol actions common to both AS and TGS and those in subsequent exchanges. 4.1. Anonymity Support in AS Exchange The client requests an anonymous ticket by setting the anonymous KDC option in an AS exchange. The Kerberos client can use the client's long-term keys, the client's X.509 certificates [RFC4556], or any other pre-authentication data, Zhu, et al. Expires May 20, 2017 [Page 5] Internet-Draft Kerberos Anonymity Support November 2016 to authenticate to the KDC and request an anonymous ticket in an AS exchange where the client's identity is known to the KDC. If the client in the AS request is anonymous, the anonymous KDC option MUST be set in the request. Otherwise, the KDC MUST return a KRB-ERROR message with the code KDC_ERR_BADOPTION. If the client is anonymous and the KDC does not have a key to encrypt the reply (this can happen when, for example, the KDC does not support PKINIT [RFC4556]), the KDC MUST return an error message with the code KDC_ERR_NULL_KEY [RFC4120]. When policy allows, the KDC issues an anonymous ticket. If the client name in the request is the anonymous principal, the client realm (crealm) in the reply is the anonymous realm, otherwise, the client realm is the realm of the AS. As specified by [RFC4120], the client name and the client realm in the EncTicketPart of the reply MUST match with the corresponding client name and the client realm of the KDC reply; the client MUST use the client name and the client realm returned in the KDC-REP in subsequent message exchanges when using the obtained anonymous ticket. The KDC MUST NOT reveal the client's identity in the authorization data of the returned ticket when populating the authorization data in a returned anonymous ticket. The AD_INITIAL_VERIFIED_CAS authorization data, as defined in [RFC4556], contains the issuer name of the client certificate. This authorization is not applicable and MUST NOT be present in the returned anonymous ticket when anonymous PKINIT is used. When the client is authenticated (i.e., anonymous PKINIT is not used), if it is undesirable to disclose such information about the client's identity, the AD_INITIAL_VERIFIED_CAS authorization data SHOULD be removed from the returned anonymous ticket. The client can use the client's key to mutually authenticate with the KDC and request an anonymous Ticket Granting Ticket (TGT) in the AS request. In that case, the reply key is selected as normal, according to Section 3.1.3 of [RFC4120]. 4.1.1. Anonymous PKINIT This sub-section defines anonymous PKINIT. As described earlier in this section, the client can request an anonymous ticket by authenticating to the KDC using the client's identity; alternatively, without revealing the client's identity to the KDC, the Kerberos client can request an anonymous ticket as Zhu, et al. Expires May 20, 2017 [Page 6] Internet-Draft Kerberos Anonymity Support November 2016 follows: the client sets the client name as the anonymous principal in the AS exchange and provides PA_PK_AS_REQ pre-authentication data [RFC4556] where the signerInfos field of the SignedData [RFC5652] of the PA_PK_AS_REQ is empty, and the certificates field is absent. Because the anonymous client does not have an associated asymmetric key pair, the client MUST choose the Diffie-Hellman key agreement method by filling in the Diffie-Hellman domain parameters in the clientPublicValue [RFC4556]. This use of the anonymous client name in conjunction with PKINIT is referred to as anonymous PKINIT. If anonymous PKINIT is used, the realm name in the returned anonymous ticket MUST be the anonymous realm. Upon receiving the anonymous PKINIT request from the client, the KDC processes the request, according to Section 3.1.2 of [RFC4120]. The KDC skips the checks for the client's signature and the client's public key (such as the verification of the binding between the client's public key and the client name), but performs otherwise applicable checks, and proceeds as normal, according to [RFC4556]. For example, the AS MUST check if the client's Diffie-Hellman domain parameters are acceptable. The Diffie-Hellman key agreement method MUST be used and the reply key is derived according to Section 3.2.3.1 of [RFC4556]. If the clientPublicValue is not present in the request, the KDC MUST return a KRB-ERROR with the code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556]. If all goes well, an anonymous ticket is generated, according to Section 3.1.3 of [RFC4120], and PA_PK_AS_REP [RFC4556] pre-authentication data is included in the KDC reply, according to [RFC4556]. If the KDC does not have an asymmetric key pair, it MAY reply anonymously or reject the authentication attempt. If the KDC replies anonymously, the signerInfos field of the SignedData [RFC5652] of PA_PK_AS_REP in the reply is empty, and the certificates field is absent. The server name in the anonymous KDC reply contains the name of the TGS. Upon receipt of the KDC reply that contains an anonymous ticket and PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then authenticate the KDC based on the KDC's signature in the PA_PK_AS_REP. If the KDC's signature is missing in the KDC reply (the reply is anonymous), the client MUST reject the returned ticket if it cannot authenticate the KDC otherwise. A KDC that supports anonymous PKINIT MUST indicate the support of PKINIT, according to Section 3.4 of [RFC4556]. In addition, such a KDC MUST indicate support for anonymous PKINIT by including a padata element of padata-type PA_PKINIT_KX and empty padata-value when including PA-PK-AS-REQ in an error reply. When included in a KDC error, PA_PKINIT_KX indicates support for anonymous PKINIT. As discussed in Section 7, when included in an AS- Zhu, et al. Expires May 20, 2017 [Page 7] Internet-Draft Kerberos Anonymity Support November 2016 REP, PA_PKINIT_KX proves that the KDC and client both contributed to the session key for any use of Diffie-Hellman key agreement with PKINIT. Note that in order to obtain an anonymous ticket with the anonymous realm name, the client MUST set the client name as the anonymous principal in the request when requesting an anonymous ticket in an AS exchange. Anonymous PKINIT is the only way via which an anonymous ticket with the anonymous realm as the client realm can be generated in this specification. 4.2. Anonymity Support in TGS Exchange The client requests an anonymous ticket by setting the anonymous KDC option in a TGS exchange, and in that request the client can use a normal Ticket Granting Ticket (TGT) with the client's identity, or an anonymous TGT, or an anonymous cross-realm TGT. If the client uses a normal TGT, the client's identity is known to the TGS. Note that the client can completely hide the client's identity in an AS exchange using anonymous PKINIT, as described in the previous section. If the ticket in the PA-TGS-REQ of the TGS request is an anonymous one, the anonymous KDC option SHOULD be set in the request. When policy allows, the KDC issues an anonymous ticket. If the ticket in the TGS request is an anonymous one, the client name and the client realm are copied from that ticket; otherwise, the ticket in the TGS request is a normal ticket, the returned anonymous ticket contains the client name as the anonymous principal and the client realm as the true realm of the client. In all cases, according to [RFC4120] the client name and the client realm in the EncTicketPart of the reply MUST match with the corresponding client name and the client realm of the anonymous ticket in the reply; the client MUST use the client name and the client realm returned in the KDC-REP in subsequent message exchanges when using the obtained anonymous ticket. The TGS MUST NOT reveal the client's identity in the authorization data of the returned ticket. When propagating authorization data in the ticket or in the enc-authorization-data field of the request, the TGS MUST ensure that the client confidentiality is not violated in the returned anonymous ticket. The TGS MUST process the authorization data recursively, according to Section 5.2.6 of [RFC4120], beyond the container levels such that all embedded authorization elements are interpreted. The TGS SHOULD NOT populate identity-based authorization data into an anonymous ticket in that Zhu, et al. Expires May 20, 2017 [Page 8] Internet-Draft Kerberos Anonymity Support November 2016 such authorization data typically reveals the client's identity. The specification of a new authorization data type MUST specify the processing rules of the authorization data when an anonymous ticket is returned. If there is no processing rule defined for an authorization data element or the authorization data element is unknown, the TGS MUST process it when an anonymous ticket is returned as follows: o If the authorization data element may reveal the client's identity, it MUST be removed unless otherwise specified. o If the authorization data element, that could reveal the client's identity, is intended to restrict the use of the ticket or limit the rights otherwise conveyed in the ticket, it cannot be removed in order to hide the client's identity. In this case, the authentication attempt MUST be rejected, and the TGS MUST return an error message with the code KDC_ERR_POLICY. Note this is applicable to both critical and optional authorization data. o If the authorization data element is unknown, the TGS MAY remove it, or transfer it into the returned anonymous ticket, or reject the authentication attempt, based on local policy for that authorization data type unless otherwise specified. If there is no policy defined for a given unknown authorization data type, the authentication MUST be rejected. The error code is KDC_ERR_POLICY when the authentication is rejected. The AD_INITIAL_VERIFIED_CAS authorization data, as defined in [RFC4556], contains the issuer name of the client certificate. If it is undesirable to disclose such information about the client's identity, the AD_INITIAL_VERIFIED_CAS authorization data SHOULD be removed from an anonymous ticket. The TGS encodes the name of the previous realm into the transited field, according to Section 3.3.3.2 of [RFC4120]. Based on local policy, the TGS MAY omit the previous realm, if the cross realm TGT is an anonymous one, in order to hide the authentication path of the client. The unordered set of realms in the transited field, if present, can reveal which realm may potentially be the realm of the client or the realm that issued the anonymous TGT. The anonymous Kerberos realm name MUST NOT be present in the transited field of a ticket. The true name of the realm that issued the anonymous ticket MAY be present in the transited field of a ticket. Zhu, et al. Expires May 20, 2017 [Page 9] Internet-Draft Kerberos Anonymity Support November 2016 4.3. Subsequent Exchanges and Protocol Actions Common to AS and TGS for Anonymity Support In both AS and TGS exchanges, the realm field in the KDC request is always the realm of the target KDC, not the anonymous realm when the client requests an anonymous ticket. Absent other information, the KDC MUST NOT include any identifier in the returned anonymous ticket that could reveal the client's identity to the server. Unless anonymous PKINIT is used, if a client requires anonymous communication, then the client MUST check to make sure that the ticket in the reply is actually anonymous by checking the presence of the anonymous ticket flag in the flags field of the EncKDCRepPart. This is because KDCs ignore unknown KDC options. A KDC that does not understand the anonymous KDC option will not return an error, but will instead return a normal ticket. The subsequent client and server communications then proceed as described in [RFC4120]. Note that the anonymous principal name and realm are only applicable to the client in Kerberos messages, the server cannot be anonymous in any Kerberos message per this specification. A server accepting an anonymous service ticket may assume that subsequent requests using the same ticket originate from the same client. Requests with different tickets are likely to originate from different clients. Upon receipt of an anonymous ticket, the transited policy check is performed in the same way as that of a normal ticket if the client's realm is not the anonymous realm; if the client realm is the anonymous realm, absent other information any realm in the authentication path is allowed by the cross-realm policy check. 5. Interoperability Requirements Conforming implementations MUST support the anonymous principal with a non-anonymous realm, and they MAY support the anonymous principal with the anonymous realm using anonymous PKINIT. 6. GSS-API Implementation Notes GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to represent the anonymous identity. In addition, Section 2.1.1 of [RFC1964] defines the single string representation of a Kerberos Zhu, et al. Expires May 20, 2017 [Page 10] Internet-Draft Kerberos Anonymity Support November 2016 principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. The anonymous principal with the anonymous realm corresponds to the GSS- API anonymous principal. A principal with the anonymous principal name and a non-anonymous realm is an authenticated principal; hence, such a principal does not correspond to the anonymous principal in GSS-API with the GSS_C_NT_ANONYMOUS name type. The [RFC1964] name syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the anonymous principal name with a non-anonymous realm name and for displaying and exporting these names. In addition, this syntax must be used along with the name type GSS_C_NT_ANONYMOUS for displaying and exporting the anonymous principal with the anonymous realm. At the GSS-API [RFC2743] level, an initiator/client requests the use of an anonymous principal with the anonymous realm by asserting the "anonymous" flag when calling GSS_Init_Sec_Context(). The GSS-API implementation MAY provide implementation-specific means for requesting the use of an anonymous principal with a non-anonymous realm. GSS-API does not know or define "anonymous credentials", so the (printable) name of the anonymous principal will rarely be used by or relevant for the initiator/client. The printable name is relevant for the acceptor/server when performing an authorization decision based on the initiator name that is returned from the acceptor side upon the successful security context establishment. A GSS-API initiator MUST carefully check the resulting context attributes from the initial call to GSS_Init_Sec_Context() when requesting anonymity, because (as in the GSS-API tradition and for backwards compatibility) anonymity is just another optional context attribute. It could be that the mechanism doesn't recognize the attribute at all or that anonymity is not available for some other reasons -- and in that case the initiator MUST NOT send the initial security context token to the acceptor, because it will likely reveal the initiators identity to the acceptor, something that can rarely be "un-done". Portable initiators are RECOMMENDED to use default credentials whenever possible, and request anonymity only through the input anon_req_flag [RFC2743] to GSS_Init_Sec_Context(). 7. PKINIT Client Contribution to the Ticket Session Key The definition in this section was motivated by protocol analysis of anonymous PKINIT (defined in this document) in building secure channels [RFC6113] and subsequent channel bindings [RFC5056]. In order to enable applications of anonymous PKINIT to form secure channels, all implementations of anonymous PKINIT need to meet the Zhu, et al. Expires May 20, 2017 [Page 11] Internet-Draft Kerberos Anonymity Support November 2016 requirements of this section. There is otherwise no connection to the rest of this document. PKINIT is useful for constructing secure channels. To ensure that an active attacker cannot create separate channels to the client and KDC with the same known key, it is desirable that neither the KDC nor the client unilaterally determine the ticket session key. The specific reason why the ticket session key is derived jointly is discussed at the end of this section. To achieve that end, a KDC conforming to this definition MUST encrypt a randomly generated key, called the KDC contribution key, in the PA_PKINIT_KX padata (defined next in this section). The KDC contribution key is then combined with the reply key to form the ticket session key of the returned ticket. These two keys are then combined using the KRB-FX-CF2 operation defined in Section 7.1, where K1 is the KDC contribution key, K2 is the reply key, the input pepper1 is American Standard Code for Information Interchange (ASCII) [ASAX34] string "PKINIT", and the input pepper2 is ASCII string "KEYEXCHANGE". PA_PKINIT_KX 147 -- padata for PKINIT that contains an encrypted -- KDC contribution key. PA-PKINIT-KX ::= EncryptedData -- EncryptionKey -- Contains an encrypted key randomly -- generated by the KDC (known as the KDC contribution key). -- Both EncryptedData and EncryptionKey are defined in [RFC4120] The PA_PKINIT_KX padata MUST be included in the KDC reply when anonymous PKINIT is used; it SHOULD be included if PKINIT is used with the Diffie-Hellman key exchange but the client is not anonymous; it MUST NOT be included otherwise (e.g., when PKINIT is used with the public key encryption as the key exchange). The padata-value field of the PA-PKINIT-KX type padata contains the DER [X.680] [X.690] encoding of the Abstract Syntax Notation One (ASN.1) type PA-PKINIT-KX. The PA-PKINIT-KX structure is an EncryptedData. The cleartext data being encrypted is the DER-encoded KDC contribution key randomly generated by the KDC. The encryption key is the reply key and the key usage number is KEY_USAGE_PA_PKINIT_KX (44). The client then decrypts the KDC contribution key and verifies the ticket session key in the returned ticket is the combined key of the KDC contribution key and the reply key as described above. A conforming client MUST reject anonymous PKINIT authentication if the PA_PKINIT_KX padata is not present in the KDC reply or if the ticket session key of the returned ticket is not the combined key of the KDC Zhu, et al. Expires May 20, 2017 [Page 12] Internet-Draft Kerberos Anonymity Support November 2016 contribution key and the reply key when PA-PKINIT-KX is present in the KDC reply. This protocol provides a binding between the party which generated the session key and the DH exchange used to generate the reply key. Hypothetically, if the KDC did not use PA-PKINIT-KX, the client and KDC would perform a DH key exchange to determine a shared key, and that key would be used as a reply key. The KDC would then generate a ticket with a session key encrypting the reply with the DH agreement. A MITM attacker would just decrypt the session key and ticket using the DH key from the attacker-KDC DH exchange, and re-encrypt it using the key from the attacker-client DH exchange, while keeping a copy of the session key and ticket. This protocol binds the ticket to the DH exchange and prevents the MITM attack by requiring the session key to be created in a way that can be verified by the client. 7.1. Combining Two Protocol Keys KRB-FX-CF2() combines two protocol keys based on the pseudo-random() function defined in [RFC3961]. Given two input keys, K1 and K2, where K1 and K2 can be of two different enctypes, the output key of KRB-FX-CF2(), K3, is derived as follows: KRB-FX-CF2(protocol key, protocol key, octet string, octet string) -> (protocol key) PRF+(K1, pepper1) -> octet-string-1 PRF+(K2, pepper2) -> octet-string-2 KRB-FX-CF2(K1, K2, pepper1, pepper2) -> random-to-key(octet-string-1 ^ octet-string-2) Where ^ denotes the exclusive-OR operation. PRF+() is defined as follows: PRF+(protocol key, octet string) -> (octet string) PRF+(key, shared-info) -> pseudo-random( key, 1 || shared-info ) || pseudo-random( key, 2 || shared-info ) || pseudo-random( key, 3 || shared-info ) || ... Here the counter value 1, 2, 3, and so on are encoded as a one-octet integer. The pseudo-random() operation is specified by the enctype of the protocol key. PRF+() uses the counter to generate enough bits as needed by the random-to-key() [RFC3961] function for the encryption type specified for the resulting key; unneeded bits are removed from the tail. Zhu, et al. Expires May 20, 2017 [Page 13] Internet-Draft Kerberos Anonymity Support November 2016 8. Security Considerations Since KDCs ignore unknown options, a client requiring anonymous communication needs to make sure that the returned ticket is actually anonymous. This is because a KDC that does not understand the anonymous option would not return an anonymous ticket. By using the mechanism defined in this specification, the client does not reveal the client's identity to the server but the client identity may be revealed to the KDC of the server principal (when the server principal is in a different realm than that of the client), and any KDC on the cross-realm authentication path. The Kerberos client MUST verify the ticket being used is indeed anonymous before communicating with the server, otherwise, the client's identity may be revealed unintentionally. In cases where specific server principals must not have access to the client's identity (for example, an anonymous poll service), the KDC can define server-principal-specific policy that ensures any normal service ticket can NEVER be issued to any of these server principals. If the KDC that issued an anonymous ticket were to maintain records of the association of identities to an anonymous ticket, then someone obtaining such records could breach the anonymity. Additionally, the implementations of most (for now all) KDC's respond to requests at the time that they are received. Traffic analysis on the connection to the KDC will allow an attacker to match client identities to anonymous tickets issued. Because there are plaintext parts of the tickets that are exposed on the wire, such matching by a third-party observer is relatively straightforward. A service that is authenticated by the anonymous principals may be able to infer the identity of the client by examining and linking quasi-static protocol information such as the IP address from which a request is received, or by linking multiple uses of the same anonymous ticket. Two mechanisms, the FAST facility with the hide-client-names option in [RFC6113] and the Kerberos5 starttls option [STARTTLS], protect the client identity so that an attacker would never be able to observe the client identity sent to the KDC. Transport or network layer security between the client and the server will help prevent tracking of a particular ticket to link a ticket to a user. In addition, clients can limit how often a ticket is reused to minimize ticket linking. The client's real identity is not revealed when the client is authenticated as the anonymous principal. Application servers MAY reject the authentication in order to, for example, prevent information disclosure or as part of Denial of Service (DoS) Zhu, et al. Expires May 20, 2017 [Page 14] Internet-Draft Kerberos Anonymity Support November 2016 prevention. Application servers MUST avoid accepting anonymous credentials in situations where they must record the client's identity; for example, when there must be an audit trail. 9. Acknowledgments JK Jaganathan helped editing early revisions of this document. Clifford Neuman contributed the core notions of this document. Ken Raeburn reviewed the document and provided suggestions for improvements. Martin Rex wrote the text for GSS-API considerations. Nicolas Williams reviewed the GSS-API considerations section and suggested ideas for improvements. Sam Hartman and Nicolas Williams were great champions of this work. Miguel Garcia and Phillip Hallam-Baker reviewed the document and provided helpful suggestions. In addition, the following individuals made significant contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia. Greg Hudson and Robert Sparks had provided helpful text in the bis version of the draft. 10. IANA Considerations This document defines an 'anonymous' Kerberos well-known name and an 'anonymous' Kerberos well-known realm based on [RFC6111]. IANA has added these two values to the Kerberos naming registries that are created in [RFC6111]. Note to IANA: Please update the following Kerberos Parameters registries: o Well-Known Kerberos Principal Names o Well-Known Kerberos Realm Names o Pre-authentication and Typed Data to reference this document instead of RFC6112. Zhu, et al. Expires May 20, 2017 [Page 15] Internet-Draft Kerberos Anonymity Support November 2016 11. References 11.1. Normative References [ASAX34] American Standards Institute, "American Standard Code for Information Interchange", ASA X3.4-1963, June 1963. [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, DOI 10.17487/RFC1964, June 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, . [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 2005, . [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, . [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, DOI 10.17487/RFC4556, June 2006, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", RFC 6111, April 2011. [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for Kerberos", RFC 6112, April 2011. [X.680] "Abstract Syntax Notation One (ASN.1): Specification of Basic Notation", ITU-T Recommendation X.680: ISO/IEC International Standard 8824-1:1998, 1997. Zhu, et al. Expires May 20, 2017 [Page 16] Internet-Draft Kerberos Anonymity Support November 2016 [X.690] "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690 ISO/IEC International Standard 8825-1:1998, 1997. 11.2. Informative References [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, April 2011. [STARTTLS] Josefsson, S., "Using Kerberos V5 over the Transport Layer Security (TLS) protocol", Work in Progress, August 2010. Authors' Addresses Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US EMail: larry.zhu@microsoft.com Paul Leach Microsoft Corporation One Microsoft Way Redmond, WA 98052 US EMail: paulle@microsoft.com Sam Hartman Painless Security EMail: hartmans-ietf@mit.edu Shawn Emery (editor) Oracle EMail: shawn.emery@oracle.com Zhu, et al. Expires May 20, 2017 [Page 17] ./draft-iab-ccg-appoint-process-03.txt0000664000764400076440000002737513033255743017064 0ustar iustyiusty Internet Architecture Board R. Housley Internet-Draft Vigil Security Intended status: Informational 4 January 2017 Expires: 4 July 2017 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) draft-iab-ccg-appoint-process-03 Abstract This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA Trademarks and the IANA domain names. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Housley Expires 4 July 2017 [Page 1] Internet-Draft CCG Representative Procedures 4 January 2017 1. Introduction The IANA IPR Community Agreement [1] was one of the many documents that was part of the IANA Stewardship Transition. It calls for the creation of the Community Coordination Group (CCG) to provide guidance and advice to the IETF Trust regarding the stewardship of the IANA Intellectual Property, which is the IANA trademarks and the IANA domain names. The CCG is comprised of nine individuals, called the CCG Representatives. The three operational communities (the Names Community, the Numbers Community, and the Protocol Parameters Community) each appoint three CCG Representatives. Each operational community has the right to change any of its CCG Representatives upon written notice to the other operational communities and the IETF Trust. An operational community may remove or replace its CCG Representatives at any time and in its sole discretion. The means and procedures by which an operational community chooses to select, appoint, and remove its own CCG Representatives are determined solely by that operational community. Each Operational Community appoints one of its CCG Representatives as a co-chair of the CCG, and that co-chair is empowered to speak on behalf of its operational community regarding the IANA Intellectual property. An Operational Community has the right to change its CCG co-chair upon written notice to the other operational communities and the IETF Trust. An operational community may remove or replace its CCG co-chair at any time and in its sole discretion. This document outlines the procedures for the IETF to select, appoint, and remove the three CCG Representatives for the Protocol Parameter Community. In addition, this document outlines the procedures for the selection of the co-chair among those CCG Representatives. 2. Desirable Qualifications for CCG Representatives Candidates for the CCG Representative position for the Protocol Parameters Community should have a demonstrable involvement in the IETF and a solid understanding of the various ways that the IETF makes use of protocol parameter registries. Candidates should be familiar with the ways that the IETF community depends upon the IANA trademarks and the IANA domain names. Candidates are expected to be able to call on others in the IETF community, as required, to ensure that the IETF Trust receives the highest quality advice available. Housley Expires 4 July 2017 [Page 2] Internet-Draft CCG Representative Procedures 4 January 2017 Candidates are expected to possess clearly demonstrated technical competence relating to the management of IANA protocol parameter registries. Candidates are also expected to be able to understand the ways that IANA registries are used by the Names Community and the Numbers Community. 3. CCG Representative Selection Procedures The three CCG Representatives for the Protocol Parameters Community serve at the pleasure of the IAB. 3.1. Duration of Appointment Each of the CCG Representatives is expected to serve for at least a year, and appointments ought to be staggered to avoid simultaneous replacement of all of the CCG Representatives at the same time. Each year the IAB will seek input from the IETF community to determine whether a personnel change is appropriate. 3.2. Nominations and Eligibility When the IAB decides to appoint a new person as a CCG Representative, the IAB will make a public call for nominations on the ietf-announce@ietf.org mailing list. The public call will specify the manner by which nominations will be accepted and the means by which the list of nominees will be published for IETF community feedback. Self-nominations are permitted. Each nomination must include the name and contact information for each candidate. The details about the candidate's background and qualifications for the position should be provided with the nomination. Trustees of the IETF Trust are not eligible for nomination. All other IETF participants, including working group chairs, IETF NomCom members, IAB members, and IESG members are eligible for nomination. IAB members who accept a nomination shall recuse themselves from selection discussions. 3.3. Selection The IAB will publish the list of people that have accepted their nomination or nominated themselves. Feedback from the IETF community will be considered by the IAB in making a selection. The IAB will keep any feedback that is received confidential. The IAB will consider potential conflicts with a CCG Representative position and any other positions held by the nominated candidates. Housley Expires 4 July 2017 [Page 3] Internet-Draft CCG Representative Procedures 4 January 2017 After considering the IETF community feedback, potential conflicts, and any other appropriate information that is available, the IAB shall vote to select the best qualified CCG Representative. 4. CCG Representative Removal Procedures If there are concerns with the performance of an IAB-appointed CCG Representative, the IETF community can request that the IAB consider removal. Such a request must be sent by email to iab-chair@iab.org. The request must include a statement of justification for the removal of the CCG Representative, including all relevant and appropriate supporting documentation. The IAB shall respond to the request within six weeks. If an IAB member is serving in any of the CCG Representative positions, regardless of the operational community that the IAB member represents, that IAB member shall be recused from any investigation, discussion, and vote to determine what action to take. If the CCG Representative is removed, then the open position is to be filled according to Section 3 of this document. 5. CCG Representative Co-Chair Selection Procedures Whenever there is a change to the list of people that are serving as CCG Representatives for the Protocol Parameters Community, the sitting CCG Representatives shall use a procedure of their own choosing to select the co-chair. The co-chair selection shall be confirmed by the IAB, and then the IAB shall announce the co-chair selection to the IETF community, the IETF Trust, and the CCG Representatives from the other operational communities. At any time, for any reason, the list of people that are serving as CCG Representatives for the Protocol Parameters Community, may revisit the selection of co-chair. If a different selection is made, the new selection shall be confirmed by the IAB, and then the IAB shall announce the co-chair selection to the IETF community, the IETF Trust, and the CCG Representatives from the other operational communities. As part of the confirmation process, the IAB shall consider potential conflicts of interest of the candidate for co-chair. 6. Initial Appointments Since three CCG Representatives needed to be in place at midnight on 30 September 2016 when the IANA Stewardship Transition took place, Housley Expires 4 July 2017 [Page 4] Internet-Draft CCG Representative Procedures 4 January 2017 the IAB quickly appointed three individuals that were heavily involved in the transition. The three individuals agreed to serve until the appointment procedures could be adopted and employed. Using the procedures in this document, the IAB will appoint three CCG Representatives before the second IETF meeting in 2017. To encourage the staggered replacement, at least one of those appointed will be replaced before the second IETF meeting in 2018, that is, one year after the first set of CCG Representatives are appointed by the process in this document. 7. Reporting by the CCG Representatives to the IAB CCG Representatives shall deliver reports to the IAB within a reasonable time frame, providing whenever possible the opportunity to obtain advice regarding open IANA Intellectual Property issues. While no specific time periods for reporting are mandated, CCG Representatives are expected to keep the IAB informed of CCG activities. Reports from the CCG Representatives will be made publicly available, except for comments about individuals. These reports will typically be part of the minutes of the IAB meeting where they are discussed. 8. IANA Considerations This document has no actions for IANA. 9. Security Considerations This document does not describe any technical protocols and has no implications for network security. 10. Informative References [1] IANA IPR Community Agreement, 21 September 2016, . 11. Acknowledgements Many thanks to Ted Hardie, Alissa Cooper, Brian Carpenter, Andrew Sullivan, Dave Crocker, John Klensin, Dave Thaler, and Martin Thomson for the valuable review and comments. Housley Expires 4 July 2017 [Page 5] Internet-Draft CCG Representative Procedures 4 January 2017 12. IAB Members at the time of this writing {{{ RFC Editor: Please insert the list of IAB members at the time this document is approved for publication. }}} Author's Address Russ Housley 918 Spring Knoll Drive Herndon, VA 20170 USA Email: housley@vigilsec.com Housley Expires 4 July 2017 [Page 6] ./draft-ietf-netconf-yang-patch-14.txt0000664000764400076440000022131613015104601017040 0ustar iustyiusty Network Working Group A. Bierman Internet-Draft YumaWorks Intended status: Standards Track M. Bjorklund Expires: May 26, 2017 Tail-f Systems K. Watsen Juniper Networks November 22, 2016 YANG Patch Media Type draft-ietf-netconf-yang-patch-14 Abstract This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 26, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bierman, et al. Expires May 26, 2017 [Page 1] Internet-Draft YANG Patch November 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.4. RESTCONF . . . . . . . . . . . . . . . . . . . . . . 5 1.1.5. YANG Patch . . . . . . . . . . . . . . . . . . . . . 5 1.1.6. Examples . . . . . . . . . . . . . . . . . . . . . . 5 1.1.7. Tree Diagram Notations . . . . . . . . . . . . . . . 6 2. YANG Patch . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Target Resource . . . . . . . . . . . . . . . . . . . . . 7 2.2. yang-patch Request . . . . . . . . . . . . . . . . . . . 8 2.3. yang-patch-status Response . . . . . . . . . . . . . . . 9 2.4. Target Data Node . . . . . . . . . . . . . . . . . . . . 10 2.5. Edit Operations . . . . . . . . . . . . . . . . . . . . . 11 2.6. Successful Edit Response Handling . . . . . . . . . . . . 11 2.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 11 2.8. yang-patch RESTCONF Capability . . . . . . . . . . . . . 12 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4.1. YANG Module Registry . . . . . . . . . . . . . . . . . . 21 4.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1. Media Type application/yang-patch+xml . . . . . . . . 21 4.2.2. Media Type application/yang-patch+json . . . . . . . 23 4.3. RESTCONF Capability URNs . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Normative References . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 27 B.1. v12 to v13 . . . . . . . . . . . . . . . . . . . . . . . 27 B.2. v11 to v12 . . . . . . . . . . . . . . . . . . . . . . . 27 B.3. v10 to v11 . . . . . . . . . . . . . . . . . . . . . . . 28 B.4. v09 to v10 . . . . . . . . . . . . . . . . . . . . . . . 28 B.5. v08 to v09 . . . . . . . . . . . . . . . . . . . . . . . 28 B.6. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 29 B.7. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 29 B.8. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 29 B.9. v04 to v05 . . . . . . . . . . . . . . . . . . . . . . . 29 B.10. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 30 B.11. v02 to v03 . . . . . . . . . . . . . . . . . . . . . . . 30 B.12. v01 to v02 . . . . . . . . . . . . . . . . . . . . . . . 30 B.13. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 30 B.14. bierman:yang-patch-00 to ietf:yang-patch-00 . . . . . . . 31 Bierman, et al. Expires May 26, 2017 [Page 2] Internet-Draft YANG Patch November 2016 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 31 Appendix D. Example YANG Module . . . . . . . . . . . . . . . . 31 D.1. YANG Patch Examples . . . . . . . . . . . . . . . . . . . 32 D.1.1. Add Resources: Error . . . . . . . . . . . . . . . . 32 D.1.2. Add Resources: Success . . . . . . . . . . . . . . . 36 D.1.3. Insert list entry example . . . . . . . . . . . . . . 38 D.1.4. Move list entry example . . . . . . . . . . . . . . . 40 D.1.5. Edit datastore resource example . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction There is a need for standard mechanisms to patch datastores defined in [RFC6241], which contain conceptual data that conforms to schema specified with YANG [RFC7950]. An "ordered edit list" approach is needed to provide RESTCONF client developers with more precise RESTCONF client control of the edit procedure than existing mechanisms found in [I-D.ietf-netconf-restconf]. This document defines a media type for a YANG-based editing mechanism that can be used with the HTTP PATCH method [RFC5789]. YANG Patch is designed to support the RESTCONF protocol, defined in [I-D.ietf-netconf-restconf]. This document only specifies the use of the YANG Patch media type with the RESTCONF protocol. It may be possible to use YANG Patch with other protocols besides RESTCONF. This is outside the scope of this document. For any protocol which supports the YANG Patch media type, if the entire patch document cannot be successfully applied, then the server MUST NOT apply any of the changes. It may be possible to use YANG Patch with datastore types other than a configuration datastore. This is outside the scope of this document. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1.1. NETCONF The following terms are defined in [RFC6241]: o configuration data o datastore o configuration datastore Bierman, et al. Expires May 26, 2017 [Page 3] Internet-Draft YANG Patch November 2016 o protocol operation o running configuration datastore o state data o user 1.1.2. HTTP The following terms are defined in [RFC7230]: o header field o message-body o query o request URI The following terms are defined in [RFC7231]: o method o request o resource 1.1.3. YANG The following terms are defined in [RFC7950]: o container o data node o leaf o leaf-list o list o RPC operation (now called protocol operation) Bierman, et al. Expires May 26, 2017 [Page 4] Internet-Draft YANG Patch November 2016 1.1.4. RESTCONF The following terms are defined in [I-D.ietf-netconf-restconf]: o application/yang-data+xml o application/yang-data+json o data resource o datastore resource o patch o RESTCONF capability o target resource o YANG data template 1.1.5. YANG Patch The following terms are used within this document: o RESTCONF client: a client which implements the RESTCONF protocol. o RESTCONF server: a server which implements the RESTCONF protocol. o YANG Patch: a conceptual edit request using the "yang-patch" YANG Patch template, defined in Section 3. In HTTP, refers to a PATCH method where a representation uses either the media type "application/yang-patch+xml" or "application/yang-patch+json". o YANG Patch Status: a conceptual edit status response using the YANG "yang-patch-status" YANG data template, defined in Section 3. In HTTP, refers to a response message for a PATCH method, where it has a representation with either the media type "application/ yang-data+xml" or "application/yang-data+json". o YANG Patch template: this is similar to a YANG data template, except it has a representation with the media type "application/ yang-patch+xml" or "application/yang-patch+json". 1.1.6. Examples Some protocol message lines within examples throughout the document are split into multiple lines for display purposes only. When a line ends with backslash ('\') as the last character, the line is wrapped Bierman, et al. Expires May 26, 2017 [Page 5] Internet-Draft YANG Patch November 2016 for display purposes. It is to be considered to be joined to the next line by deleting the backslash, the following line break, and the leading whitespace of the next line. 1.1.7. Tree Diagram Notations A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration data (read-write), "ro" state data (read-only), and "x" operation resource (executable) o Symbols after data node names: "?" means an optional node and "*" denotes a "list" and "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. YANG Patch A "YANG Patch" is an ordered list of edits that are applied to the target datastore by the RESTCONF server. The specific fields are defined in the YANG module in Section 3. The YANG Patch operation is invoked by the RESTCONF client by sending a PATCH method request with a representation using either the "application/yang-patch+xml" or "application/yang-patch+json" media type. This message-body representing the YANG Patch input parameters MUST be present. YANG Patch has some features that are not possible with the PATCH method in RESTCONF: o YANG Patch allows multiple sub-resources to be edited within the same PATCH method. o YANG Patch allows more precise edit operations than RESTCONF. There are 7 operations supported (create, delete, insert, merge, move, replace, remove). Bierman, et al. Expires May 26, 2017 [Page 6] Internet-Draft YANG Patch November 2016 o YANG Patch uses an edit list with an explicit processing order. The edits are processed in client-specified order, and error processing can be precise even when multiple errors occur in the same patch request. The YANG Patch "patch-id" may be useful for debugging, and SHOULD be present in any audit audit logging records generated by the RESTCONF server for a patch. The RESTCONF server MUST return the Accept-Patch header field in an OPTIONS response, as specified in [RFC5789], which includes the media type for YANG Patch. This is needed by a client to determine the message encoding formats supported by the server (e.g., XML, JSON, or both). An example is shown in Figure 1. Accept-Patch: application/yang-patch+xml,application/yang-patch+json Figure 1: Example Accept-Patch header Note that YANG Patch can only edit data resources. The PATCH method cannot be used to replace the datastore resource. Although the "ietf-yang-patch" YANG module is written using YANG version 1.1 [RFC7950], an implementation of YANG Patch can be used with content defined in YANG version 1 [RFC6020] as well. A YANG Patch can be encoded in XML format according to [W3C.REC-xml-20081126]. It can also be encoded in JSON, according to "JSON Encoding of Data Modeled with YANG" [RFC7951]. If any meta- data needs to be sent in a JSON message, it is encoded according to "Defining and Using Metadata with YANG" [RFC7952]. 2.1. Target Resource The YANG Patch operation uses the RESTCONF target resource URI to identify the resource that will be patched. This can be the datastore resource itself, i.e., "{+restconf}/data", to edit top- level configuration data resources, or it can be a configuration data resource within the datastore resource, e.g., "{+restconf}/data/ ietf-interfaces:interfaces", to edit sub-resources within a top-level configuration data resource. The target resource MUST identify exactly one resource instance. If more than one resource instance is identified, then the request MUST NOT be processed, and a "400 Bad Request" error response MUST be sent by the server. If the target resource does not identify any existing resource instance then the request MUST NOT be processed, and a "404 Not Found" error response MUST be sent by the server. Bierman, et al. Expires May 26, 2017 [Page 7] Internet-Draft YANG Patch November 2016 Each edit with a YANG Patch identifies a target data node for the associated edit. This is described in Section 2.4. 2.2. yang-patch Request A YANG patch is optionally identified by a unique "patch-id" and it may have an optional comment. A patch is an ordered collection of edits. Each edit is identified by an "edit-id" and it has an edit operation (create, delete, insert, merge, move, replace, remove) that is applied to the target resource. Each edit can be applied to a sub-resource "target" within the target resource. If the operation is "insert" or "move", then the "where" parameter indicates how the node is inserted or moved. For values "before" and "after", the "point" parameter specifies the data node insertion point. The merge, replace, create, delete, and remove edit operations have the exact same meaning as defined for the "operation" attribute in section 7.2 of [RFC6241]. Each edit within a YANG Patch MUST identify exactly one data resource instance. If an edit represents more than one resource instance, then the request MUST NOT be processed, and a "400 Bad Request" error response MUST be sent by the server. If the edit does not identify any existing resource instance, and the operation for the edit is not "create", then the request MUST NOT be processed, and a "404 Not Found" error response MUST be sent by the server. A "yang-patch-status" response MUST be sent by the server identifying the edit(s) that are not valid. YANG Patch does not provide any access to specific datastores. It is an implementation detail how a server processes an edit if it is co- located with a NETCONF server that does provide access to individual datastores. A complete datastore cannot be replaced in the same manner as provided by the "copy-config" operation defined in section 7.3 of [RFC6241]. Only the specified nodes in a YANG Patch are affected. A message-body representing the YANG Patch is sent by the RESTCONF client to specify the edit operation request. When used with the HTTP PATCH method, this data is identified by the YANG Patch media type. YANG tree diagram for "yang-patch" Container Bierman, et al. Expires May 26, 2017 [Page 8] Internet-Draft YANG Patch November 2016 +---- yang-patch +---- patch-id string +---- comment? string +---- edit* [edit-id] +---- edit-id string +---- operation enumeration +---- target target-resource-offset +---- point? target-resource-offset +---- where? enumeration +---- value? 2.3. yang-patch-status Response A message-body representing the YANG Patch Status is returned to the RESTCONF client to report the detailed status of the edit operation. When used with the HTTP PATCH method, this data is identified by the YANG Patch Status media type, and the syntax specification is defined in Section 3. YANG tree diagram for "yang-patch-status" Container: Bierman, et al. Expires May 26, 2017 [Page 9] Internet-Draft YANG Patch November 2016 +---- yang-patch-status +---- patch-id string +---- (global-status)? | +--:(global-errors) | | +---- errors | | +---- error* | | +---- error-type enumeration | | +---- error-tag string | | +---- error-app-tag? string | | +---- error-path? instance-identifier | | +---- error-message? string | | +---- error-info? | +--:(ok) | +---- ok? empty +---- edit-status +---- edit* [edit-id] +---- edit-id string +---- (edit-status-choice)? +--:(ok) | +---- ok? empty +--:(errors) +---- errors +---- error* +---- error-type enumeration +---- error-tag string +---- error-app-tag? string +---- error-path? instance-identifier +---- error-message? string +---- error-info? 2.4. Target Data Node The target data node for each edit operation is determined by the value of the target resource in the request and the "target" leaf within each "edit" entry. If the target resource specified in the request URI identifies a datastore resource, then the path string in the "target" leaf is treated as an absolute path expression identifying the target data node for the corresponding edit. The first node specified in the "target" leaf is a top-level data node defined within a YANG module. The "target" leaf MUST NOT contain a single forward slash "/", since this would identify the datastore resource, not a data resource. If the target resource specified in the request URI identifies a configuration data resource, then the path string in the "target" leaf is treated as a relative path expression. The first node specified in the "target" leaf is a child configuration data node of Bierman, et al. Expires May 26, 2017 [Page 10] Internet-Draft YANG Patch November 2016 the data node associated with the target resource. If the "target" leaf contains a single forward slash "/", then the target data node is the target resource data node. 2.5. Edit Operations Each YANG patch edit specifies one edit operation on the target data node. The set of operations is aligned with the NETCONF edit operations, but also includes some new operations. +-----------+-------------------------------------------------------+ | Operation | Description | +-----------+-------------------------------------------------------+ | create | create a new data resource if it does not already | | | exist or error | | delete | delete a data resource if it already exists or error | | insert | insert a new user-ordered data resource | | merge | merge the edit value with the target data resource; | | | create if it does not already exist | | move | re-order the target data resource | | replace | replace the target data resource with the edit value | | remove | remove a data resource if it already exists | +-----------+-------------------------------------------------------+ YANG Patch Edit Operations 2.6. Successful Edit Response Handling If a YANG Patch is completed without errors, the RESTCONF server MUST return a "yang-patch-status" message with a global-status choice set to 'ok'. The RESTCONF server will save the running datastore to non-volatile storage if it supports non-volatile storage, and if the running datastore contents have changed, as specified in [I-D.ietf-netconf-restconf]. Refer to Appendix D.1.2 for a example of a successful YANG Patch response. 2.7. Error Handling If a well-formed, schema-valid YANG Patch message is received, then the RESTCONF server will process the supplied edits in ascending order. The following error modes apply to the processing of this edit list: Bierman, et al. Expires May 26, 2017 [Page 11] Internet-Draft YANG Patch November 2016 If a YANG Patch is completed with errors, the RESTCONF server SHOULD return a "yang-patch-status" message. It is possible (e.g., within a distributed implementation), that an invalid request will be rejected before the YANG patch edits are processed. In this case, the server MUST send the appropriate HTTP error response instead. Refer to Appendix D.1.1 for a example of an error YANG Patch response. 2.8. yang-patch RESTCONF Capability A URI is defined to identify the YANG Patch extension to the base RESTCONF protocol. If the RESTCONF server supports the YANG Patch media type, then the "yang-patch" RESTCONF capability defined in Section 4.3 MUST be present in the "capability" leaf-list in the "ietf-restconf-monitoring" module defined in [I-D.ietf-netconf-restconf]. 3. YANG Module The "ietf-yang-patch" module defines conceptual definitions with the 'yang-data' extension statements, which are not meant to be implemented as datastore contents by a RESTCONF server. The "ietf-restconf" module from [I-D.ietf-netconf-restconf] is used by this module for the 'yang-data' extension definition. RFC Ed.: update the date below with the date of RFC publication and remove this note. file "ietf-yang-patch@2016-11-09.yang" module ietf-yang-patch { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-patch"; prefix "ypatch"; import ietf-restconf { prefix rc; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Author: Andy Bierman Bierman, et al. Expires May 26, 2017 [Page 12] Internet-Draft YANG Patch November 2016 Author: Martin Bjorklund Author: Kent Watsen "; description "This module contains conceptual YANG specifications for the YANG Patch and YANG Patch Status data structures. Note that the YANG definitions within this module do not represent configuration data of any kind. The YANG grouping statements provide a normative syntax for XML and JSON message encoding purposes. Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: remove this note // Note: extracted from draft-ietf-netconf-yang-patch-14.txt // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2016-11-09 { description "Initial revision."; reference "RFC XXXX: YANG Patch Media Type."; } typedef target-resource-offset { type string; description "Contains a data resource identifier string representing a sub-resource within the target resource. Bierman, et al. Expires May 26, 2017 [Page 13] Internet-Draft YANG Patch November 2016 The document root for this expression is the target resource that is specified in the protocol operation (e.g., the URI for the PATCH request). This string is encoded according the same rules as a data resource identifier in a RESTCONF Request URI."; // RFC Ed.: replace "draft-ietf-netconf-restconf" below // with RFC XXXX, where XXXX is the number of the RESTCONF RFC, // and remove this note. reference "draft-ietf-netconf-restconf, section 3.5.3"; } rc:yang-data "yang-patch" { uses yang-patch; } rc:yang-data "yang-patch-status" { uses yang-patch-status; } grouping yang-patch { description "A grouping that contains a YANG container representing the syntax and semantics of a YANG Patch edit request message."; container yang-patch { description "Represents a conceptual sequence of datastore edits, called a patch. Each patch is given a client-assigned patch identifier. Each edit MUST be applied in ascending order, and all edits MUST be applied. If any errors occur, then the target datastore MUST NOT be changed by the patch operation. YANG datastore validation is performed before any edits have been applied to the running datastore. It is possible for a datastore constraint violation to occur due to any node in the datastore, including nodes not included in the edit list. Any validation errors MUST be reported in the reply message."; reference Bierman, et al. Expires May 26, 2017 [Page 14] Internet-Draft YANG Patch November 2016 "RFC 7950, section 8.3."; leaf patch-id { type string; mandatory true; description "An arbitrary string provided by the client to identify the entire patch. Error messages returned by the server pertaining to this patch will be identified by this patch-id value. A client SHOULD attempt to generate unique patch-id values to distinguish between transactions from multiple clients in any audit logs maintained by the server."; } leaf comment { type string; description "An arbitrary string provided by the client to describe the entire patch. This value SHOULD be present in any audit logging records generated by the server for the patch."; } list edit { key edit-id; ordered-by user; description "Represents one edit within the YANG Patch request message. The edit list is applied in the following manner: - The first edit is conceptually applied to a copy of the existing target datastore, e.g., the running configuration datastore. - Each ascending edit is conceptually applied to the result of the previous edit(s). - After all edits have been successfully processed, the result is validated according to YANG constraints. - If successful, the server will attempt to apply the result to the target datastore. "; leaf edit-id { type string; description "Arbitrary string index for the edit. Error messages returned by the server pertaining Bierman, et al. Expires May 26, 2017 [Page 15] Internet-Draft YANG Patch November 2016 to a specific edit will be identified by this value."; } leaf operation { type enumeration { enum create { description "The target data node is created using the supplied value, only if it does not already exist. The 'target' leaf identifies the data node to be created, not the parent data node."; } enum delete { description "Delete the target node, only if the data resource currently exists, otherwise return an error."; } enum insert { description "Insert the supplied value into a user-ordered list or leaf-list entry. The target node must represent a new data resource. If the 'where' parameter is set to 'before' or 'after', then the 'point' parameter identifies the insertion point for the target node."; } enum merge { description "The supplied value is merged with the target data node."; } enum move { description "Move the target node. Reorder a user-ordered list or leaf-list. The target node must represent an existing data resource. If the 'where' parameter is set to 'before' or 'after', then the 'point' parameter identifies the insertion point to move the target node."; } enum replace { description "The supplied value is used to replace the target data node."; } enum remove { description Bierman, et al. Expires May 26, 2017 [Page 16] Internet-Draft YANG Patch November 2016 "Delete the target node if it currently exists."; } } mandatory true; description "The datastore operation requested for the associated edit entry"; } leaf target { type target-resource-offset; mandatory true; description "Identifies the target data node for the edit operation. If the target has the value '/', then the target data node is the target resource. The target node MUST identify a data resource, not the datastore resource."; } leaf point { when "(../operation = 'insert' or ../operation = 'move') " + "and (../where = 'before' or ../where = 'after')" { description "Point leaf only applies for insert or move operations, before or after an existing entry."; } type target-resource-offset; description "The absolute URL path for the data node that is being used as the insertion point or move point for the target of this edit entry."; } leaf where { when "../operation = 'insert' or ../operation = 'move'" { description "Where leaf only applies for insert or move operations."; } type enumeration { enum before { description "Insert or move a data node before the data resource identified by the 'point' parameter."; } enum after { description Bierman, et al. Expires May 26, 2017 [Page 17] Internet-Draft YANG Patch November 2016 "Insert or move a data node after the data resource identified by the 'point' parameter."; } enum first { description "Insert or move a data node so it becomes ordered as the first entry."; } enum last { description "Insert or move a data node so it becomes ordered as the last entry."; } } default last; description "Identifies where a data resource will be inserted or moved. YANG only allows these operations for list and leaf-list data nodes that are ordered-by user."; } anydata value { when "../operation = 'create' " + "or ../operation = 'merge' " + "or ../operation = 'replace' " + "or ../operation = 'insert'" { description "Value node only used for create, merge, replace, and insert operations"; } description "Value used for this edit operation. The anydata 'value' contains the target resource associated with the 'target' leaf. For example, suppose the target node is a YANG container named foo: container foo { leaf a { type string; } leaf b { type int32; } } The 'value' node contains one instance of foo: Bierman, et al. Expires May 26, 2017 [Page 18] Internet-Draft YANG Patch November 2016 some value 42 "; } } } } // grouping yang-patch grouping yang-patch-status { description "A grouping that contains a YANG container representing the syntax and semantics of YANG Patch status response message."; container yang-patch-status { description "A container representing the response message sent by the server after a YANG Patch edit request message has been processed."; leaf patch-id { type string; description "The patch-id value used in the request. If there was no patch-id present in the request then this field will not be present."; } choice global-status { description "Report global errors or complete success. If there is no case selected then errors are reported in the edit-status container."; case global-errors { uses rc:errors; description "This container will be present if global errors that are unrelated to a specific edit occurred."; } leaf ok { type empty; Bierman, et al. Expires May 26, 2017 [Page 19] Internet-Draft YANG Patch November 2016 description "This leaf will be present if the request succeeded and there are no errors reported in the edit-status container."; } } container edit-status { description "This container will be present if there are edit-specific status responses to report. If all edits succeeded and the 'global-status' returned is 'ok', then a server MAY omit this container"; list edit { key edit-id; description "Represents a list of status responses, corresponding to edits in the YANG Patch request message. If an edit entry was skipped or not reached by the server, then this list will not contain a corresponding entry for that edit."; leaf edit-id { type string; description "Response status is for the edit list entry with this edit-id value."; } choice edit-status-choice { description "A choice between different types of status responses for each edit entry."; leaf ok { type empty; description "This edit entry was invoked without any errors detected by the server associated with this edit."; } case errors { uses rc:errors; description "The server detected errors associated with the edit identified by the same edit-id value."; Bierman, et al. Expires May 26, 2017 [Page 20] Internet-Draft YANG Patch November 2016 } } } } } } // grouping yang-patch-status } 4. IANA Considerations 4.1. YANG Module Registry This document registers one URI as a namespace in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-yang-patch Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. This document registers one YANG module in the YANG Module Names registry [RFC6020]. name: ietf-yang-patch namespace: urn:ietf:params:xml:ns:yang:ietf-yang-patch prefix: ypatch // RFC Ed.: replace XXXX with RFC number and remove this note reference: RFC XXXX 4.2. Media Types 4.2.1. Media Type application/yang-patch+xml Type name: application Subtype name: yang-patch+xml Required parameters: None Optional parameters: None // RFC Ed.: replace 'XXXX' with the real RFC number, // and remove this note Encoding considerations: 8-bit Bierman, et al. Expires May 26, 2017 [Page 21] Internet-Draft YANG Patch November 2016 The utf-8 charset is always used for this type. Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [RFC7950]. In addition, the "yang-patch" YANG Patch template found in [RFCXXXX] defines the structure of a YANG Patch request. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize the YANG Patch data structure. Fragment identifier considerations: Same as for application/xml Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Bierman, et al. Expires May 26, 2017 [Page 22] Internet-Draft YANG Patch November 2016 Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no 4.2.2. Media Type application/yang-patch+json Type name: application Subtype name: yang-patch+json Required parameters: None Optional parameters: None // RFC Ed.: replace draft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace draft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace 'XXXX' with the real RFC number, // and remove this note Encoding considerations: 8-bit The utf-8 charset is always used for this type. Each conceptual YANG data node is encoded according to [draft-ietf-netmod-yang-json]. A data annotation is encoded according to [draft-ietf-netmod-yang-metadata] In addition, the "yang-patch" YANG Patch template found in [RFCXXXX] defines the structure of a YANG Patch request. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual Bierman, et al. Expires May 26, 2017 [Page 23] Internet-Draft YANG Patch November 2016 // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize the YANG Patch data structure. Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as specified for the "application/json" media type. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Bierman, et al. Expires May 26, 2017 [Page 24] Internet-Draft YANG Patch November 2016 Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no 4.3. RESTCONF Capability URNs This document registers one capability identifier in "RESTCONF Protocol Capability URNs" registry Index Capability Identifier ------------------------ :yang-patch urn:ietf:params:restconf:capability:yang-patch:1.0 5. Security Considerations The YANG Patch media type does not introduce any significant new security threats, beyond what is described in [I-D.ietf-netconf-restconf]. This document defines edit processing instructions for a variant of the PATCH method, as used within the RESTCONF protocol. Message integrity is provided by the RESTCONF protocol. There is no additional capability to validate that a patch has not been altered. It may be possible to use YANG Patch with other protocols besides RESTCONF, which is outside the scope of this document. For RESTCONF, both the client and server MUST be authenticated, according to section 2 of [I-D.ietf-netconf-restconf]. It is important for RESTCONF server implementations to carefully validate all the edit request parameters in some manner. If the entire YANG Patch request cannot be completed, then no configuration changes to the system are done. A PATCH request MUST be applied atomically, as specified in section 2 of [RFC5789]. A RESTCONF server implementation SHOULD attempt to prevent system disruption due to incremental processing of the YANG Patch edit list. It may be possible to construct an attack on such a RESTCONF server, which relies on the edit processing order mandated by YANG Patch. A server SHOULD apply only the fully validated configuration to the underlying system. For example, an edit list which deleted an interface and then recreated it could cause system disruption if the edit list was incrementally applied. Bierman, et al. Expires May 26, 2017 [Page 25] Internet-Draft YANG Patch November 2016 A RESTCONF server implementation SHOULD attempt to prevent system disruption due to excessive resource consumption required to fulfill YANG Patch edit requests. It may be possible to construct an attack on such a RESTCONF server, which attempts to consume all available memory or other resource types. 6. Normative References [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Bierman, et al. Expires May 26, 2017 [Page 26] Internet-Draft YANG Patch November 2016 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016, . [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . Appendix A. Acknowledgements The authors would like to thank the following people for their contributions to this document: Rex Fernando. Contributions to this material by Andy Bierman are based upon work supported by the The Space & Terrestrial Communications Directorate (S&TCD) under Contract No. W15P7T-13-C-A616. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of The Space & Terrestrial Communications Directorate (S&TCD). Appendix B. Change Log -- RFC Ed.: remove this section before publication. The YANG Patch issue tracker can be found here: https://github.com/ netconf-wg/yang-patch/issues B.1. v12 to v13 o clarifications based on IESG reviews B.2. v11 to v12 o clarify target resource must exist o fix errors in some examples o change application/yang-patch-xml to application/yang-patch+xml o clarified some section titles Bierman, et al. Expires May 26, 2017 [Page 27] Internet-Draft YANG Patch November 2016 o clarified error responses for multiple edit instances o made patch-id field mandatory o referenced NETCONF operation attribute B.3. v10 to v11 o change application/yang-patch to application/yang-patch-xml o change server to RESTCONF server and remove NETCONF server term o change client to RESTCONF client and remove NETCONF client term o clarified that YANG 1.0 content can be used in a YANG Patch implementation o clarified more terminology o fixed missing keys in edit examples o added insert list example B.4. v09 to v10 o change yang-patch+xml to yang-patch o clarify application/yang-patch+json media type o add edit datastore example o change data-resource-offset typedef so it is consistent for XML and JSON B.5. v08 to v09 o change RFC 7158 reference to RFC 7159 reference o change RFC 2616 reference to RFC 7230 reference o remove unused HTTP terms o remove import-by-revision of ietf-restconf; not needed o change application/yang.patch media type to application/yang-patch o remove application/yang.patch-status media type; use application/ yang-data instead Bierman, et al. Expires May 26, 2017 [Page 28] Internet-Draft YANG Patch November 2016 B.6. v07 to v08 o clarified target datastore and target data node terms o clarified that target leaf can be single forward slash '/' o added Successful edit response handling section o clarified that YANG Patch draft is for RESTCONF protocol only but may be defined for other protocols outside this document o clarified that YANG Patch draft is for configuration datastores only but may be defined for other datastore types outside this document o fixed typos B.7. v06 to v07 o converted YANG module to YANG 1.1 o changed anyxml value to anydata value o updated import revision date for ietf-restconf o updated revision date for ietf-yang-patch because import-by- revision date needed to be changed B.8. v05 to v06 o changed errors example so a full request and error response is shown in XML format o fixed error-path to match instance-identifier encoding for both XML and JSON o added references for YANG to JSON and YANG Metadata drafts o clarified that YANG JSON drafts are used for encoding, not plain JSON B.9. v04 to v05 o updated reference to RESTCONF Bierman, et al. Expires May 26, 2017 [Page 29] Internet-Draft YANG Patch November 2016 B.10. v03 to v04 o removed NETCONF specific text o changed data-resource-offset typedef from a relative URI to an XPath absolute path expression o clarified insert operation o removed requirement that edits MUST be applied in ascending order o change SHOULD keep datastore unchanged on error to MUST (this is required by HTTP PATCH) o removed length restriction on 'comment' leaf o updated YANG tree for example-jukebox library B.11. v02 to v03 o added usage of restconf-media-type extension to map the yang-patch and yang-patch-status groupings to media types o added yang-patch RESTCONF capability URI o Added sub-section for terms used from RESTCONF o filled in security considerations section B.12. v01 to v02 o Reversed order of change log o Clarified anyxml structure of "value" parameter within a YANG patch request (github issue #1) o Updated RESTCONF reference o Added note to open issues section to check github instead B.13. v00 to v01 o Added text requiring support for Accept-Patch header field, and removed 'Identification of YANG Patch capabilities' open issue. o Removed 'location' leaf from yang-patch-status grouping Bierman, et al. Expires May 26, 2017 [Page 30] Internet-Draft YANG Patch November 2016 o Removed open issue 'Protocol independence' because the location leaf was removed. o Removed open issue 'RESTCONF coupling' because there is no concern about a normative reference to RESTCONF. There may need to be a YANG 1.1 mechanism to allow protocol template usage (instead of grouping wrapper). o Removed open issue 'Is the delete operation needed'. It was decided that both delete and remove should remain as operations and clients can choose which one to use. This is not an implementation burden on the server. o Removed open issue 'global-errors needed'. It was decided that they are needed as defined because the global is needed and the special key value for edit=global error only allows for 1 global error. o Removed open issue 'Is location leaf needed'. It was decided that it is not needed so this leaf has been removed. o Removed open issue 'Bulk editing support in yang-patch-status'. The 'location' leaf has been removed so this issue is no longer applicable. o Removed open issue 'Edit list mechanism'. Added text to the 'edit' list description-stmt about how the individual edits must be processed. There is no concern about duplicate edits which cause intermediate results to be altered by subsequent edits in the same edit list. B.14. bierman:yang-patch-00 to ietf:yang-patch-00 o Created open issues section Appendix C. Open Issues -- RFC Ed.: remove this section before publication. Refer to the github issue tracker for any open issues: https://github.com/netconf-wg/yang-patch/issues Appendix D. Example YANG Module The example YANG module used in this document represents a simple media jukebox interface. The "example-jukebox" YANG module is defined in [I-D.ietf-netconf-restconf]. Bierman, et al. Expires May 26, 2017 [Page 31] Internet-Draft YANG Patch November 2016 YANG tree diagram for "example-jukebox" Module: +--rw jukebox! +--rw library | +--rw artist* [name] | | +--rw name string | | +--rw album* [name] | | +--rw name string | | +--rw genre? identityref | | +--rw year? uint16 | | +--rw admin | | | +--rw label? string | | | +--rw catalogue-number? string | | +--rw song* [name] | | +--rw name string | | +--rw location string | | +--rw format? string | | +--rw length? uint32 | +--ro artist-count? uint32 | +--ro album-count? uint32 | +--ro song-count? uint32 +--rw playlist* [name] | +--rw name string | +--rw description? string | +--rw song* [index] | +--rw index uint32 | +--rw id leafref +--rw player +--rw gap? decimal64 rpcs: +---x play +--ro input +--ro playlist string +--ro song-number uint32 D.1. YANG Patch Examples This section includes RESTCONF examples. Most examples are shown in JSON encoding [RFC7159], and some are shown in XML encoding [W3C.REC-xml-20081126]. D.1.1. Add Resources: Error The following example shows several songs being added to an existing album. Each edit contains one song. The first song already exists, so an error will be reported for that edit. The rest of the edits Bierman, et al. Expires May 26, 2017 [Page 32] Internet-Draft YANG Patch November 2016 were not attempted, since the first edit failed. The XML encoding is used in this example. Request from the RESTCONF client: Bierman, et al. Expires May 26, 2017 [Page 33] Internet-Draft YANG Patch November 2016 PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Accept: application/yang-data+xml Content-Type: application/yang-patch+xml add-songs-patch edit1 create /song=Bridge%20Burning Bridge Burning /media/bridge_burning.mp3 MP3 288 edit2 create /song=Rope Rope /media/rope.mp3 MP3 259 edit3 create /song=Dear%20Rosemary Dear Rosemary /media/dear_rosemary.mp3 MP3 269 Bierman, et al. Expires May 26, 2017 [Page 34] Internet-Draft YANG Patch November 2016 XML Response from the RESTCONF server: HTTP/1.1 409 Conflict Date: Mon, 23 Apr 2012 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT Content-Type: application/yang-data+xml add-songs-patch edit1 application data-exists /jb:jukebox/jb:library /jb:artist[jb:name='Foo Fighters'] /jb:album[jb:name='Wasting Light'] /jb:song[jb:name='Burning Light'] Data already exists, cannot be created JSON Response from the RESTCONF server: The following response is shown in JSON format to highlight the difference in the "error-path" object encoding. For JSON, the instance-identifier encoding in the "JSON Encoding of YANG Data" draft is used. Bierman, et al. Expires May 26, 2017 [Page 35] Internet-Draft YANG Patch November 2016 HTTP/1.1 409 Conflict Date: Mon, 23 Apr 2012 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT Content-Type: application/yang-data+json { "ietf-yang-patch:yang-patch-status" : { "patch-id" : "add-songs-patch", "edit-status" : { "edit" : [ { "edit-id" : "edit1", "errors" : { "error" : [ { "error-type": "application", "error-tag": "data-exists", "error-path": "/example-jukebox:jukebox/library\ /artist[name='Foo Fighters']\ /album[name='Wasting Light']\ /song[name='Burning Light']", "error-message": "Data already exists, cannot be created" } ] } } ] } } } D.1.2. Add Resources: Success The following example shows several songs being added to an existing album. o Each of 2 edits contains one song. o Both edits succeed and new sub-resources are created Request from the RESTCONF client: Bierman, et al. Expires May 26, 2017 [Page 36] Internet-Draft YANG Patch November 2016 PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light \ HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-patch+json { "ietf-yang-patch:yang-patch" : { "patch-id" : "add-songs-patch-2", "edit" : [ { "edit-id" : "edit1", "operation" : "create", "target" : "/song=Rope", "value" : { "song" : [ { "name" : "Rope", "location" : "/media/rope.mp3", "format" : "MP3", "length" : 259 } ] } }, { "edit-id" : "edit2", "operation" : "create", "target" : "/song=Dear%20Rosemary", "value" : { "song" : [ { "name" : "Dear Rosemary", "location" : "/media/dear_rosemary.mp3", "format" : "MP3", "length" : 269 } ] } } ] } } Response from the RESTCONF server: Bierman, et al. Expires May 26, 2017 [Page 37] Internet-Draft YANG Patch November 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT Content-Type: application/yang-data+json { "ietf-yang-patch:yang-patch-status" : { "patch-id" : "add-songs-patch-2", "ok" : [null] } } D.1.3. Insert list entry example The following example shows a song being inserted within an existing playlist. Song "6" in playlist "Foo-One" is being inserted after song "5" in the playlist. The operation succeeds, so a non-error reply example can be shown. Bierman, et al. Expires May 26, 2017 [Page 38] Internet-Draft YANG Patch November 2016 Request from the RESTCONF client: PATCH /restconf/data/example-jukebox:jukebox/\ playlist=Foo-One HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-patch+json { "ietf-yang-patch:yang-patch" : { "patch-id" : "move-song-patch", "comment" : "Insert song 6 after song 5", "edit" : [ { "edit-id" : "edit1", "operation" : "insert", "target" : "/song=6", "point" : "/song=5", "where" : "after", "value" : { "example-jukebox:song" : [ { "name" : "Dear Prudence", "location" : "/media/dear_prudence.mp3", "format" : "MP3", "length" : 236 } ] } } ] } } Response from the RESTCONF server: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT Content-Type: application/yang-data+json { "ietf-yang-patch:yang-patch-status" : { "patch-id" : "move-song-patch", "ok" : [null] } } Bierman, et al. Expires May 26, 2017 [Page 39] Internet-Draft YANG Patch November 2016 D.1.4. Move list entry example The following example shows a song being moved within an existing playlist. Song "1" in playlist "Foo-One" is being moved after song "3" in the playlist. Note that no "value" parameter is needed for a "move" operation. The operation succeeds, so a non-error reply example can be shown. Request from the RESTCONF client: PATCH /restconf/data/example-jukebox:jukebox/\ playlist=Foo-One HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-patch+json { "ietf-yang-patch:yang-patch" : { "patch-id" : "move-song-patch", "comment" : "Move song 1 after song 3", "edit" : [ { "edit-id" : "edit1", "operation" : "move", "target" : "/song=1", "point" : "/song=3", "where" : "after" } ] } } Response from the RESTCONF server: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT Content-Type: application/yang-data+json { "ietf-restconf:yang-patch-status" : { "patch-id" : "move-song-patch", "ok" : [null] } } Bierman, et al. Expires May 26, 2017 [Page 40] Internet-Draft YANG Patch November 2016 D.1.5. Edit datastore resource example The following example shows how 3 top-level data nodes from different modules can be edited at the same time. Example module "foo" defines leaf X. Example module "bar" defines container Y, with child leafs A and B. Example module "baz" defines list Z, with key C and child leafs D and E. Request from the RESTCONF client: Bierman, et al. Expires May 26, 2017 [Page 41] Internet-Draft YANG Patch November 2016 PATCH /restconf/data HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-patch+json { "ietf-yang-patch:yang-patch" : { "patch-id" : "datastore-patch-1", "comment" : "Edit 3 top-level data nodes at once", "edit" : [ { "edit-id" : "edit1", "operation" : "create", "target" : "/foo:X", "value" : { "foo:X" : 42 } }, { "edit-id" : "edit2", "operation" : "merge", "target" : "/bar:Y", "value" : { "bar:Y" : { "A" : "test1", "B" : 99 } } }, { "edit-id" : "edit3", "operation" : "replace", "target" : "/baz:Z=2", "value" : { "baz:Z" : [ { "C" : 2, "D" : 100, "E" : false } ] } } ] } } Response from the RESTCONF server: Bierman, et al. Expires May 26, 2017 [Page 42] Internet-Draft YANG Patch November 2016 HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 13:02:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT Content-Type: application/yang-data+json { "ietf-yang-patch:yang-patch-status" : { "patch-id" : "datastore-patch-1", "ok" : [null] } } Authors' Addresses Andy Bierman YumaWorks Email: andy@yumaworks.com Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Kent Watsen Juniper Networks Email: kwatsen@juniper.net Bierman, et al. Expires May 26, 2017 [Page 43] ./draft-ieee-urn-03.txt0000664000764400076440000002507013013073172014142 0ustar iustyiusty Network Working Group A. Thomas Internet-Draft IEEE Intended status: Informational Expires: April 16, 2017 November 16, 2016 URN Namespace for IEEE draft-ieee-urn-03 Abstract This document describes the Namespace Identifier (NID) 'ieee' for Uniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE). IEEE specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 26, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Thomas Expires April 26, 2017 [Page 1] Internet-Draft Namespace for IEEE November 2016 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction The Institute of Electrical and Electronic Engineers (IEEE) is an organization whose objectives include the educational and technical advancement of electrical and electronic engineering, telecommunications, computer engineering and allied disciplines. Within IEEE, standardization activities are organized into sponsors, such as the LAN/MAN Stadnards Commitee, and then working groups such as 802.1 and 802.3. See http://standards.ieee.org. As part of these specifications efforts, there is a need to identify identifiers in a managed namespace that are unique and persistent. To ensure that this namespace's uniqueness is absolute, a registration of a specific Unified Resource Name (URN) URN Syntax [RFC2141] Namespace Identifier (NID) for use by IEEE is being specified in this document, in full conformance with the NID registration process specified in URN Namespace Definition Mechanism [RFC3406]. 1.1. Terminology +---------+---------------------------------------------------+ | Acronym | Meaning | +---------+---------------------------------------------------+ | IEEE | Institute of Electrical and Electronics Engineers | | | | | NID | Namespace Identifier | | | | | URN | Uniform Resource Name | +---------+---------------------------------------------------+ 2. URN Specification for IEEE Namespace ID: ieee Registration information: registration version number: 1 Thomas Expires April 16, 2017 [Page 2] Internet-Draft Namespace for IEEE November 2016 registration date: 2016-09-26 (Note to RFC Editor: Please update the registration date when this request gets accepted and remove this instruction) Declared registrant of the namespace: Registering organization: Name: Institute of Electrical and Electronics Engineers Address: 445 Hoes Lane Piscataway, NJ 08854 USA Designated contact: Angela Thomas Role: Manager, IEEE Registration Authority Email: ieee-registration-authority@ieee.org Declaration of syntactic structure: The Namespace Specific String (NSS) of all URNs that use the IEEE NID will have the following structure: urn:ieee:{IEEEresource}:{ResourceSpecificString} where the "IEEEresource" is a US-ASCII string that conforms to the URN syntax requirements [RFC2141] and defines a specific class of resource type. Each resource type has a specific labeling scheme Thomas Expires April 16, 2017 [Page 2] Internet-Draft Namespace for IEEE November 2016 that is covered by "ResourceSpecificString", which also conforms to the naming requirements of [RFC2141]. IEEE maintains a registration authority, the IEEE Registration Authority (IEEE RA), that will manage the assignment of "IEEEresource" and the specific registration values assigned for each resource class. Relevant ancillary documentation: The IEEE Registration Authority (IEEE RA) provides information on the registered resources and the registrations for each. More information about this registry and the procedures to be followed are available at: http://standards.ieee.org/develop/regauth/tut/ieeeurn.pdf Identifier uniqueness considerations: The IEEE RA will manage resources using the IEEE NID and will be the authority for managing the resources and subsequent strings associated. In the associated procedures, IEEE RA will ensure the uniqueness of the strings themselves or shall permit secondary responsibility for management of well-defined sub-trees. Identifier persistence considerations: IEEE will update documentation of the registered uses of the IEEE NID as needed. This will be structured such that each "IEEEresource" will have a separate description and registration table. The registration tables and information are published and maintained by the IEEE RA on its web site. Process of identifier assignment: IEEE RA will provide procedures for registration of each type of resource that it maintains. Process of identifier resolution: The namespace is not listed with an RDS; this is not relevant. Rules for Lexical Equivalence: The strings used as values of "IEEEresource" and "ResourceSpecificString" are case-insensitive. Thomas Expires April 16, 2017 [Page 3] Internet-Draft Namespace for IEEE November 2016 Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. URN assignment will be handled by procedures implemented in support of IEEE activities. Scope: Global 3. Examples The following examples are representative URNs that could be assigned by IEEE RA. While support for YANG [RFC6020],[RFC7950] was a driver for the creation of the namespace, the following are not necessarily the strings that would be assigned. urn:ieee:std:802.5:yang urn:ieee:foobar 4. Security Considerations There are no additional security considerations other than those normally associated with the use and resolution of URNs in general, which are described in Functional Requirements for URN [RFC1737], URN Syntax [RFC2141], and URN Namespace Definition Mechanism [RFC3406]. 5. IANA Considerations This document adds a new entry ("ieee") in the urn-namespace registry. This is the defining document. When published, the entry can be found in the "Uniform Resource Names (URN) Namespaces" registry available from the IANA site (http://www.iana.org) and any associated mirrors. 6. References 6.1. Normative References [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, October 2002, . [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, . Thomas Expires April 16, 2017 [Page 4] Internet-Draft Namespace for IEEE November 2016 6.2. Informative References [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, DOI 10.17487/RFC1737, December 1994, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Acknowledgements The IEEE Registration Authority Committee (RAC) is the oversight committee for the IEEE Registration Authority. The content of this document has been coordinated with the RAC. The technical contact from the RAC was: Glenn Parsons Email: glenn.parsons@ericsson.com Authors' Addresses Angela Thomas IEEE Registration Authority 445 Hoes Lane Piscataway, NJ 08854 USA Phone: +1 732 465 6481 Email: a.n.thomas@ieee.org Thomas Expires April 16, 2017 [Page 5] ./draft-ietf-forces-interfelfb-06.txt0000664000764400076440000015271412735547552017010 0ustar iustyiusty Internet Engineering Task Force D. Joachimpillai Internet-Draft Verizon Intended status: Standards Track J. Hadi Salim Expires: January 2, 2017 Mojatatu Networks July 1, 2016 ForCES Inter-FE LFB draft-ietf-forces-interfelfb-06 Abstract This document describes how to extend the ForCES LFB topology across FEs by defining the Inter-FE LFB Class. The Inter-FE LFB Class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification. The document focuses on Ethernet transport. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 2, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 1] Internet-Draft ForCES Inter-FE LFB July 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Scope And Use Cases . . . . . . . . . . . . . . . . . 4 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Sample Use Cases . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Basic IPv4 Router . . . . . . . . . . . . . . . . . . 4 3.2.1.1. Distributing The Basic IPv4 Router . . . . . . . 6 3.2.2. Arbitrary Network Function . . . . . . . . . . . . . 7 3.2.2.1. Distributing The Arbitrary Network Function . . . 8 4. Inter-FE LFB Overview . . . . . . . . . . . . . . . . . . . . 8 4.1. Inserting The Inter-FE LFB . . . . . . . . . . . . . . . 9 5. Inter-FE Ethernet Connectivity . . . . . . . . . . . . . . . 10 5.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . . . 10 5.1.1. MTU Consideration . . . . . . . . . . . . . . . . . . 11 5.1.2. Quality Of Service Considerations . . . . . . . . . . 11 5.1.3. Congestion Considerations . . . . . . . . . . . . . . 11 5.2. Inter-FE Ethernet Encapsulation . . . . . . . . . . . . . 12 6. Detailed Description of the Ethernet inter-FE LFB . . . . . . 13 6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 14 6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . 15 6.2. Components . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IEEE Assignment Considerations . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Terminology and Conventions Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 2] Internet-Draft ForCES Inter-FE LFB July 2016 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Definitions This document depends on the terminology defined in several ForCES documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] [RFC7391] [RFC7408] for the sake of contextual clarity. Control Engine (CE) Forwarding Engine (FE) FE Model LFB (Logical Functional Block) Class (or type) LFB Instance LFB Model LFB Metadata ForCES Component LFB Component ForCES Protocol Layer (ForCES PL) ForCES Protocol Transport Mapping Layer (ForCES TML) 2. Introduction In the ForCES architecture, a packet service can be modelled by composing a graph of one or more LFB instances. The reader is referred to the details in the ForCES Model [RFC5812]. The ForCES model describes the processing within a single Forwarding Element (FE) in terms of logical forwarding blocks (LFB), including provision for the Control Element (CE) to establish and modify that processing sequence, and the parameters of the individual LFBs. Under some circumstance, it would be beneficial to be able to extend this view, and the resulting processing across more than one FE. This may be in order to achieve scale by splitting the processing Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 3] Internet-Draft ForCES Inter-FE LFB July 2016 across elements, or to utilize specialized hardware available on specific FEs. Given that the ForCES inter-LFB architecture calls for the ability to pass metadata between LFBs, it is imperative therefore to define mechanisms to extend that existing feature and allow passing the metadata between LFBs across FEs. This document describes how to extend the LFB topology across FEs i.e inter-FE connectivity without needing any changes to the ForCES definitions. It focuses on using Ethernet as the interconnection between FEs. 3. Problem Scope And Use Cases The scope of this document is to solve the challenge of passing ForCES defined metadata alongside packet data across FEs (be they physical or virtual) for the purpose of distributing the LFB processing. 3.1. Assumptions o The FEs involved in the Inter-FE LFB belong to the same Network Element(NE) and are within a single administrative private network which is in close proximity. o The FEs are already interconnected using Ethernet. We focus on Ethernet because it is a very common setup as an FE interconnect. Other higher transports (such as UDP over IP) or lower transports could be defined to carry the data and metadata, but these cases are not addressed in this document. 3.2. Sample Use Cases To illustrate the problem scope we present two use cases where we start with a single FE running all the LFBs functionality then split it into multiple FEs achieving the same end goals. 3.2.1. Basic IPv4 Router A sample LFB topology depicted in Figure 1 demonstrates a service graph for delivering basic IPv4 forwarding service within one FE. For the purpose of illustration, the diagram shows LFB classes as graph nodes instead of multiple LFB class instances. Since the illustration on Figure 1 is meant only as an exercise to showcase how data and metadata are sent down or upstream on a graph of LFB instances, it abstracts out any ports in both directions and Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 4] Internet-Draft ForCES Inter-FE LFB July 2016 talks about a generic ingress and egress LFB. Again, for illustration purposes, the diagram does not show exception or error paths. Also left out are details on Reverse Path Filtering, ECMP, multicast handling etc. In other words, this is not meant to be a complete description of an IPv4 forwarding application; for a more complete example, please refer the LFBlib document [RFC6956]. The output of the ingress LFB(s) coming into the IPv4 Validator LFB will have both the IPv4 packets and, depending on the implementation, a variety of ingress metadata such as offsets into the different headers, any classification metadata, physical and virtual ports encountered, tunnelling information etc. These metadata are lumped together as "ingress metadata". Once the IPv4 validator vets the packet (example ensures that no expired TTL etc), it feeds the packet and inherited metadata into the IPv4 unicast LPM LFB. +----+ | | IPv4 pkt | | IPv4 pkt +-----+ +---+ +------------->| +------------->| | | | | + ingress | | + ingress |IPv4 | IPv4 pkt | | | metadata | | metadata |Ucast+------------>| +--+ | +----+ |LPM | + ingress | | | +-+-+ IPv4 +-----+ + NHinfo +---+ | | | Validator metadata IPv4 | | | LFB NextHop| | | LFB | | | | | | IPv4 pkt | | | + {ingress | +---+ + NHdetails} Ingress metadata | LFB +--------+ | | Egress | | <--+ |<-----------------+ | LFB | +--------+ Figure 1: Basic IPv4 packet service LFB topology The IPv4 unicast LPM LFB does a longest prefix match lookup on the IPv4 FIB using the destination IP address as a search key. The result is typically a next hop selector which is passed downstream as metadata. Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 5] Internet-Draft ForCES Inter-FE LFB July 2016 The Nexthop LFB receives the IPv4 packet with an associated next hop info metadata. The NextHop LFB consumes the NH info metadata and derives from it a table index to look up the next hop table in order to find the appropriate egress information. The lookup result is used to build the next hop details to be used downstream on the egress. This information may include any source and destination information (for our purposes, MAC addresses to use) as well as egress ports. [Note: It is also at this LFB where typically the forwarding TTL decrementing and IP checksum recalculation occurs.] The details of the egress LFB are considered out of scope for this discussion. Suffice it is to say that somewhere within or beyond the Egress LFB the IPv4 packet will be sent out a port (Ethernet, virtual or physical etc). 3.2.1.1. Distributing The Basic IPv4 Router Figure 2 demonstrates one way the router LFB topology in Figure 1 may be split across two FEs (eg two ASICs). Figure 2 shows the LFB topology split across FEs after the IPv4 unicast LPM LFB. Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 6] Internet-Draft ForCES Inter-FE LFB July 2016 FE1 +-------------------------------------------------------------+ | +----+ | | +----------+ | | | | | Ingress | IPv4 pkt | | IPv4 pkt +-----+ | | | LFB +-------------->| +------------->| | | | | | + ingress | | + ingress |IPv4 | | | +----------+ metadata | | metadata |Ucast| | | ^ +----+ |LPM | | | | IPv4 +--+--+ | | | Validator | | | LFB | | +---------------------------------------------------|---------+ | IPv4 packet + {ingress + NHinfo} metadata FE2 | +---------------------------------------------------|---------+ | V | | +--------+ +--------+ | | | Egress | IPv4 packet | IPv4 | | | <-----+ LFB |<----------------------+NextHop | | | | |{ingress + NHdetails} | LFB | | | +--------+ metadata +--------+ | +-------------------------------------------------------------+ Figure 2: Split IPv4 packet service LFB topology Some proprietary inter-connect (example Broadcom HiGig over XAUI [brcm-higig]) are known to exist to carry both the IPv4 packet and the related metadata between the IPv4 Unicast LFB and IPv4 NextHop LFB across the two FEs. This document defines the inter-FE LFB, a standard mechanism for encapsulating, generating, receiving and decapsulating packets and associated metadata FEs over Ethernet. 3.2.2. Arbitrary Network Function In this section we show an example of an arbitrary Network Function which is more coarse grained in terms of functionality. Each Network Function may constitute more than one LFB. FE1 +-------------------------------------------------------------+ | +----+ | | +----------+ | | | Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 7] Internet-Draft ForCES Inter-FE LFB July 2016 | | Network | pkt |NF2 | pkt +-----+ | | | Function +-------------->| +------------->| | | | | 1 | + NF1 | | + NF1/2 |NF3 | | | +----------+ metadata | | metadata | | | | ^ +----+ | | | | | +--+--+ | | | | | | | | +---------------------------------------------------|---------+ V Figure 3: A Network Function Service Chain within one FE The setup in Figure 3 is a typical of most packet processing boxes where we have functions like DPI, NAT, Routing, etc connected in such a topology to deliver a packet processing service to flows. 3.2.2.1. Distributing The Arbitrary Network Function The setup in Figure 3 can be split out across 3 FEs instead of as demonstrated in Figure 4. This could be motivated by scale out reasons or because different vendors provide different functionality which is plugged-in to provide such functionality. The end result is to have the same packet service delivered to the different flows passing through. FE1 FE2 +----------+ +----+ FE3 | Network | pkt |NF2 | pkt +-----+ | Function +-------------->| +------------->| | | 1 | + NF1 | | + NF1/2 |NF3 | +----------+ metadata | | metadata | | ^ +----+ | | | +--+--+ | V Figure 4: A Network Function Service Chain Distributed Across Multiple FEs 4. Inter-FE LFB Overview We address the inter-FE connectivity requirements by defining the inter-FE LFB class. Using a standard LFB class definition implies no change to the basic ForCES architecture in the form of the core LFBs (FE Protocol or Object LFBs). This design choice was made after considering an alternative approach that would have required changes Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 8] Internet-Draft ForCES Inter-FE LFB July 2016 to both the FE Object capabilities (SupportedLFBs) as well LFBTopology component to describe the inter-FE connectivity capabilities as well as runtime topology of the LFB instances. 4.1. Inserting The Inter-FE LFB The distributed LFB topology described in Figure 2 is re-illustrated in Figure 5 to show the topology location where the inter-FE LFB would fit in. As can be observed in Figure 5, the same details passed between IPv4 unicast LPM LFB and the IPv4 NH LFB are passed to the egress side of the Inter-FE LFB. This information is illustrated as multiplicity of inputs into the egress InterFE LFB instance. Each input represents a unique set of selection information. FE1 +-------------------------------------------------------------+ | +----------+ +----+ | | | Ingress | IPv4 pkt | | IPv4 pkt +-----+ | | | LFB +-------------->| +------------->| | | | | | + ingress | | + ingress |IPv4 | | | +----------+ metadata | | metadata |Ucast| | | ^ +----+ |LPM | | | | IPv4 +--+--+ | | | Validator | | | | LFB | | | | IPv4 pkt + metadata | | | {ingress + NHinfo} | | | | | | | +..--+..+ | | | |..| | | | | +-V--V-V--V-+ | | | Egress | | | | InterFE | | | | LFB | | | +------+----+ | +---------------------------------------------------|---------+ | Ethernet Frame with: | IPv4 packet data and metadata {ingress + NHinfo + Inter FE info} FE2 | +---------------------------------------------------|---------+ | +..+.+..+ | | |..|.|..| | | +-V--V-V--V-+ | | | Ingress | | Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 9] Internet-Draft ForCES Inter-FE LFB July 2016 | | InterFE | | | | LFB | | | +----+------+ | | | | | IPv4 pkt + metadata | | {ingress + NHinfo} | | | | | +--------+ +----V---+ | | | Egress | IPv4 packet | IPv4 | | | <-----+ LFB |<----------------------+NextHop | | | | |{ingress + NHdetails} | LFB | | | +--------+ metadata +--------+ | +-------------------------------------------------------------+ Figure 5: Split IPv4 forwarding service with Inter-FE LFB The egress of the inter-FE LFB uses the received packet and metadata to select details for encapsulation when sending messages towards the selected neighboring FE. These details include what to communicate as the source and destination FEs (abstracted as MAC addresses as described in Section 5.2); in addition the original metadata may be passed along with the original IPv4 packet. On the ingress side of the inter-FE LFB the received packet and its associated metadata are used to decide the packet graph continuation. This includes which of the original metadata and which next LFB class instance to continue processing on. In the illustrated Figure 5, an IPv4 Nexthop LFB instance is selected and appropriate metadata is passed on to it. The ingress side of the inter-FE LFB consumes some of the information passed and passes on the IPv4 packet alongside with the ingress and NHinfo metadata to the IPv4 NextHop LFB as was done earlier in both Figure 1 and Figure 2. 5. Inter-FE Ethernet Connectivity Section 5.1 describes some of the issues related to using Ethernet as the transport and how we mitigate them. Section 5.2 defines a payload format that is to be used over Ethernet. An existing implementation of this specification on top of Linux Traffic Control [linux-tc] is described in [tc-ife]. 5.1. Inter-FE Ethernet Connectivity Issues There are several issues that may occur due to using direct Ethernet encapsulation that need consideration. Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 10] Internet-Draft ForCES Inter-FE LFB July 2016 5.1.1. MTU Consideration Because we are adding data to existing Ethernet frames, MTU issues may arise. We recommend: o To use large MTUs when possible (example with jumbo frames). o Limit the amount of metadata that could be transmitted; our definition allows for filtering of select metadata to be encapsulated in the frame as described in Section 6. We recommend sizing the egress port MTU so as to allow space for maximum size of the metadata total size to allow between FEs. In such a setup, the port is configured to "lie" to the upper layers by claiming to have a lower MTU than it is capable of. MTU setting can be achieved by ForCES control of the port LFB(or other config). In essence, the control plane when explicitly making a decision for the MTU settings of the egress port is implicitly deciding how much metadata will be allowed. Caution needs to be exercised on how low the resulting reported link MTU could be: For IPv4 packets the minimum size is 64 octets [RFC 791] and for IPv6 the minimum size is 1280 octets [RFC2460]. 5.1.2. Quality Of Service Considerations A raw packet arriving at the Inter-FE LFB (from upstream LFB Class instances) may have COS metadatum indicating how it should be treated from a Quality of Service perspective. The resulting Ethernet frame will be eventually (preferentially) treated by a downstream LFB(typically a port LFB instance) and their COS marks will be honored in terms of priority. In other words the presence of the Inter-FE LFB does not change the COS semantics 5.1.3. Congestion Considerations Most of the traffic passing through FEs that utilize the Inter-FE LFB is expected to be IP based, which is generally assumed to be congestion controlled [draft-ietf-tsvwg-rfc5405bis]. For example if congestion causes a TCP packet annotated with additional ForCES metadata to be dropped between FEs, the sending TCP can be expected to react in the same fashion as if that packet had been dropped at a different point on its path where ForCES is not involved. For this reason, additional Inter-FE congestion control mechanisms are not specified. However, the increased packet size due to addition of ForCES metadata is likely to require additional bandwidth on inter-FE links by comparison to what would be required to carry the same traffic Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 11] Internet-Draft ForCES Inter-FE LFB July 2016 without ForCES metadata. Therefore, traffic engineering SHOULD be done when deploying Inter-FE encapsulation. Furthermore, the Inter-FE LFB MUST only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion. These are Controlled Environments, as defined by Section 3.6 of [draft-ietf-tsvwg-rfc5405bis]. Additional measures SHOULD be imposed to restrict the impact of Inter-FE encapsulated traffic on other traffic; example: o rate limiting at an upstream LFB all Inter-FE LFB traffic o managed circuit breaking[circuit-b]. o Isolating the Inter-FE traffic either via dedicated interfaces or VLANs. 5.2. Inter-FE Ethernet Encapsulation The Ethernet wire encapsulation is illustrated in Figure 6. The process that leads to this encapsulation is described in Section 6. The resulting frame is 32 bit aligned. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inter-FE ethertype | Metadata length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV encoded Metadata ~~~..............~~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV encoded Metadata ~~~..............~~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original packet data ~~................~~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Packet format definition The Ethernet header (illustrated in Figure 6) has the following semantics: Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 12] Internet-Draft ForCES Inter-FE LFB July 2016 o The Destination MAC Address is used to identify the Destination FEID by the CE policy (as described in Section 6). o The Source MAC Address is used to identify the Source FEID by the CE policy (as described in Section 6). o The Ethernet type is used to identify the frame as inter-FE LFB type. Ethertype TBA1 is to be used (XXX: Note to RFC editor - update when available). o The 16-bit metadata length is used to described the total encoded metadata length (including the 16 bits used to encode the metadata length). o One or more 16-bit TLV encoded Metadatum follows the metadata length field. The TLV type identifies the Metadata id. ForCES IANA-defined Metadata ids will be used. All TLVs will be 32 bit aligned. We recognize that using a 16 bit TLV restricts the metadata id to 16 bits instead of ForCES-defined component ID space of 32 bits if an ILV is used. However, at the time of publication we believe this is sufficient to carry all the info we need; the TLV approach has been selected because it saves us 4 bytes per Metadatum transferred as compared to the ILV approach. o The original packet data payload is appended at the end of the metadata as shown. 6. Detailed Description of the Ethernet inter-FE LFB The Ethernet inter-FE LFB has two LFB input port groups and three LFB output ports as shown in Figure 7. The inter-FE LFB defines two components used in aiding processing described in Section 6.2. +-----------------+ Inter-FE LFB | | Encapsulated | OUT2+--> decapsulated Packet -------------->|IngressInGroup | + metadata Ethernet Frame | | | | raw Packet + | OUT1+--> Encapsulated Ethernet -------------->|EgressInGroup | Frame Metadata | | | EXCEPTIONOUT +--> ExceptionID, packet | | + metadata +-----------------+ Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 13] Internet-Draft ForCES Inter-FE LFB July 2016 Figure 7: Inter-FE LFB 6.1. Data Handling The Inter-FE LFB (instance) can be positioned at the egress of a source FE. Figure 5 illustrates an example source FE in the form of FE1. In such a case an Inter-FE LFB instance receives, via port group EgressInGroup, a raw packet and associated metadata from the preceding LFB instances. The input information is used to produce a selection of how to generate and encapsulate the new frame. The set of all selections is stored in the LFB component IFETable described further below. The processed encapsulated Ethernet Frame will go out on OUT1 to a downstream LFB instance when processing succeeds or to the EXCEPTIONOUT port in the case of a failure. The Inter-FE LFB (instance) can be positioned at the ingress of a receiving FE. Figure 5 illustrates an example destination FE in the form of FE1. In such a case an Inter-FE LFB receives, via an LFB port in the IngressInGroup, an encapsulated Ethernet frame. Successful processing of the packet will result in a raw packet with associated metadata IDs going downstream to an LFB connected on OUT2. On failure the data is sent out EXCEPTIONOUT. 6.1.1. Egress Processing The egress Inter-FE LFB receives packet data and any accompanying Metadatum at an LFB port of the LFB instance's input port group labelled EgressInGroup. The LFB implementation may use the incoming LFB port (within LFB port group EgressInGroup) to map to a table index used to lookup the IFETable table. If lookup is successful, a matched table row which has the InterFEinfo details is retrieved with the tuple {optional IFEtype, optional StatId, Destination MAC address(DSTFE), Source MAC address(SRCFE), optional metafilters}. The metafilters lists define a whitelist of which Metadatum are to be passed to the neighboring FE. The inter-FE LFB will perform the following actions using the resulting tuple: o Increment statistics for packet and byte count observed at corresponding IFEStats entry. Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 14] Internet-Draft ForCES Inter-FE LFB July 2016 o When MetaFilterList is present, then walk each received Metadatum and apply against the MetaFilterList. If no legitimate metadata is found that needs to be passed downstream then the processing stops and send the packet and metadata out the EXCEPTIONOUT port with exceptionID of EncapTableLookupFailed [RFC6956]. o Check that the additional overhead of the Ethernet header and encapsulated metadata will not exceed MTU. If it does, increment the error packet count statistics and send the packet and metadata out the EXCEPTIONOUT port with exceptionID of FragRequired [RFC6956]. o Create the Ethernet header o Set the Destination MAC address of the Ethernet header with value found in the DSTFE field. o Set the Source MAC address of the Ethernet header with value found in the SRCFE field. o If the optional IFETYPE is present, set the Ethernet type to the value found in IFETYPE. If IFETYPE is absent then the standard Inter-FE LFB Ethernet type TBA1 is used (XXX: Note to RFC editor - update when available). o Encapsulate each allowed Metadatum in a TLV. Use the Metaid as the "type" field in the TLV header. The TLV should be aligned to 32 bits. This means you may need to add padding of zeroes at the end of the TLV to ensure alignment. o Update the Metadata length to the sum of each TLV's space plus 2 bytes (for the Metadata length field 16 bit space). The resulting packet is sent to the next LFB instance connected to the OUT1 LFB-port; typically a port LFB. In the case of a failed lookup the original packet and associated metadata is sent out the EXCEPTIONOUT port with exceptionID of EncapTableLookupFailed [RFC6956]. Note that the EXCEPTIONOUT LFB port is merely an abstraction and implementation may in fact drop packets as described above. 6.1.2. Ingress Processing An ingressing inter-FE LFB packet is recognized by inspecting the ethertype, and optionally the destination and source MAC addresses. A matching packet is mapped to an LFB instance port in the IngressInGroup. The IFETable table row entry matching the LFB Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 15] Internet-Draft ForCES Inter-FE LFB July 2016 instance port may have optionally programmed metadata filters. In such a case the ingress processing should use the metadata filters as a whitelist of what metadatum is to be allowed. o Increment statistics for packet and byte count observed. o Look at the metadata length field and walk the packet data extracting from the TLVs the metadata values. For each Metadatum extracted, in the presence of metadata filters, the metaid is compared against the relevant IFETable row metafilter list. If the Metadatum is recognized, and is allowed by the filter, the corresponding implementation Metadatum field is set. If an unknown Metadatum id is encountered, or if the metaid is not in the allowed filter list the implementation is expected to ignore it, increment the packet error statistic and proceed processing other Metadatum. o Upon completion of processing all the metadata, the inter-FE LFB instance resets the data point to the original payload (i.e skips the IFE header information). At this point the original packet that was passed to the egress Inter-FE LFB at the source FE is reconstructed. This data is then passed along with the reconstructed metadata downstream to the next LFB instance in the graph. In the case of processing failure of either ingress or egress positioning of the LFB, the packet and metadata are sent out the EXCEPTIONOUT LFB port with appropriate error id. Note that the EXCEPTIONOUT LFB port is merely an abstraction and implementation may in fact drop packets as described above. 6.2. Components There are two LFB components accessed by the CE. The reader is asked to refer to the definitions in Figure 8. The first component, populated by the CE, is an array known as the IFETable table. The array rows are made up of IFEInfo structure. The IFEInfo structure constitutes: optional IFETYPE, optionally present StatId, Destination MAC address(DSTFE), Source MAC address(SRCFE), optionally present array of allowed Metaids (MetaFilterList). The second component(ID 2), populated by the FE and read by the CE, is an indexed array known as the IFEStats table. Each IFEStats row which carries statistics information in the structure bstats. Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 16] Internet-Draft ForCES Inter-FE LFB July 2016 A note about the StatId relationship between the IFETable table and IFEStats table: An implementation may choose to map between an IFETable row and IFEStats table row using the StatId entry in the matching IFETable row. In that case the IFETable StatId must be present. Alternative implementation may map at provisioning time an IFETable row to IFEStats table row. Yet another alternative implementation may choose not to use the IFETable row StatId and instead use the IFETable row index as the IFEStats index. For these reasons the StatId component is optional. 6.3. Inter-FE LFB XML Model PacketAny Arbitrary Packet InterFEFrame Ethernet Frame with encapsulate IFE information bstats Basic stats bytes The total number of bytes seen uint64 packets The total number of packets seen uint32 Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 17] Internet-Draft ForCES Inter-FE LFB July 2016 errors The total number of packets with errors uint32 IFEInfo Describing IFE table row Information IFETYPE the ethernet type to be used for outgoing IFE frame uint16 StatId the Index into the stats table uint32 DSTFE the destination MAC address of destination FE byte[6] SRCFE the source MAC address used for the source FE byte[6] MetaFilterList the allowed metadata filter table Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 18] Internet-Draft ForCES Inter-FE LFB July 2016 uint32 IFE This LFB describes IFE connectivity parameterization 1.0 EgressInGroup The input port group of the egress side. It expects any type of Ethernet frame. PacketAny IngressInGroup The input port group of the ingress side. It expects an interFE encapsulated Ethernet frame. InterFEFrame Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 19] Internet-Draft ForCES Inter-FE LFB July 2016 OUT1 The output port of the egress side. InterFEFrame OUT2 The output port of the Ingress side. PacketAny EXCEPTIONOUT The exception handling path PacketAny ExceptionID Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 20] Internet-Draft ForCES Inter-FE LFB July 2016 IFETable the table of all InterFE relations IFEInfo IFEStats the stats corresponding to the IFETable table bstats Figure 8: Inter-FE LFB XML 7. Acknowledgements The authors would like to thank Joel Halpern and Dave Hood for the stimulating discussions. Evangelos Haleplidis shepherded and contributed to improving this document. Alia Atlas was the AD sponsor of this document and did a tremendous job of critiquing it. The authors are grateful to Joel Halpern and Sue Hares in their roles as the Routing Area reviewers in shaping the content of this document. David Black put a lot of effort in making sure congestion control considerations are sane. Russ Housley did the Gen-ART review and Joe Touch did the TSV area. Shucheng LIU (Will) did the OPS review. Suresh Krishnan helped us provide clarity during the IESG review. The authors are appreciative of the efforts Stephen Farrell put in fixing the security section. 8. IANA Considerations This memo includes one IANA request within the registry https:// www.iana.org/assignments/forces Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 21] Internet-Draft ForCES Inter-FE LFB July 2016 The request is for the sub-registry "Logical Functional Block (LFB) Class Names and Class Identifiers" to request for the reservation of LFB class name IFE with LFB classid 18 with version 1.0. +--------------+---------+---------+-------------------+------------+ | LFB Class | LFB | LFB | Description | Reference | | Identifier | Class | Version | | | | | Name | | | | +--------------+---------+---------+-------------------+------------+ | 18 | IFE | 1.0 | An IFE LFB to | This | | | | | standardize | document | | | | | inter-FE LFB for | | | | | | ForCES Network | | | | | | Elements | | +--------------+---------+---------+-------------------+------------+ Logical Functional Block (LFB) Class Names and Class Identifiers 9. IEEE Assignment Considerations This memo includes a request for a new ethernet protocol type as described in Section 5.2. 10. Security Considerations The FEs involved in the Inter-FE LFB belong to the same Network Device (NE) and are within the scope of a single administrative Ethernet LAN private network. While trust of policy in the control and its treatment in the datapath exists already, an Inter-FE LFB implementation SHOULD support security services provided by Media Access Control Security(MACsec)[ieee8021ae]. MACsec is not currently sufficiently widely deployed in traditional packet processing hardware although present in newer versions of the Linux kernel (which will be widely deployed) [linux-macsec]. Over time we would expect that most FEs will be able to support MACsec. MACsec provides security services such as message authentication service and optional confidentiality service. The services can be configured manually or automatically using MACsec Key Agreement(MKA) over IEEE 802.1x [ieee8021x] Extensible Authentication Protocol (EAP) framework. It is expected FE implementations are going to start with shared keys configured from the control plane but progress to automated key management. The following are the MACsec security mechanisms that need to be in place for the InterFE LFB: Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 22] Internet-Draft ForCES Inter-FE LFB July 2016 o Security mechanisms are NE-wide for all FEs. Once the security is turned on depending upon the chosen security level (Authentication, Confidentiality), it will be in effect for the inter-FE LFB for the entire duration of the session. o An operator SHOULD configure the same security policies for all participating FEs in the NE cluster. This will ensure uniform operations and avoid unnecessary complexity in policy configuration. In other words, the Security Association Keys(SAKs) should be pre-shared. When using MKA, FEs must identify themselves with a shared Connectivity Association Key (CAK) and Connectivity Association Key Name (CKN). EAP-TLS SHOULD be used as the EAP method. o An operator SHOULD configure the strict validation mode i.e all non-protected, invalid or non-verifiable frames MUST be dropped. It should be noted that given the above choices, if an FE is compromised, an entity running on the FE would be able to fake inter- FE or modify its content causing bad outcomes. 11. References 11.1. Normative References [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/ RFC5810, March 2010, . [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, DOI 10.17487/ RFC5811, March 2010, . [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, DOI 10.17487/RFC5812, March 2010, . [RFC7391] Hadi Salim, J., "Forwarding and Control Element Separation (ForCES) Protocol Extensions", RFC 7391, DOI 10.17487/ RFC7391, October 2014, . Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 23] Internet-Draft ForCES Inter-FE LFB July 2016 [RFC7408] Haleplidis, E., "Forwarding and Control Element Separation (ForCES) Model Extension", RFC 7408, DOI 10.17487/RFC7408, November 2014, . [draft-ietf-tsvwg-rfc5405bis] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", Nov 2015, . [ieee8021ae] , "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, Aug 2006. [ieee8021x] , "IEEE standard for local and metropolitan area networks - port-based network access control.", IEEE 802.1X-2010, 2010. 11.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, . [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library", RFC 6956, DOI 10.17487/RFC6956, June 2013, . [brcm-higig] , "HiGig", . [circuit-b] Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 24] Internet-Draft ForCES Inter-FE LFB July 2016 Fairhurst, G., "Network Transport Circuit Breakers", Feb 2016, . [linux-macsec] Dubroca, S., "MACsec: Encryption for the wired LAN", netdev 11, Feb 2016. [linux-tc] Hadi Salim, J., "Linux Traffic Control Classifier-Action Subsystem Architecture", netdev 01, Feb 2015. [tc-ife] Hadi Salim, J. and D. Joachimpillai, "Distributing Linux Traffic Control Classifier-Action Subsystem", netdev 01, Feb 2015. [vxlan-udp] , "iproute2 and kernel code (drivers/net/vxlan.c)", . Authors' Addresses Damascane M. Joachimpillai Verizon 60 Sylvan Rd Waltham, Mass. 02451 USA Email: damascene.joachimpillai@verizon.com Jamal Hadi Salim Mojatatu Networks Suite 200, 15 Fitzgerald Rd. Ottawa, Ontario K2H 9G1 Canada Email: hadi@mojatatu.com Joachimpillai & Hadi SaliExpires January 2, 2017 [Page 25] ./draft-ietf-6lo-dispatch-iana-registry-07.txt0000664000764400076440000004303313022346263020436 0ustar iustyiusty 6lo S. Chakrabarti Internet-Draft Updates: 4944, 6282 (if approved) G. Montenegro Intended status: Standards Track Microsoft Expires: June 11, 2017 R. Droms J. Woodyatt Google December 8, 2016 6lowpan ESC Dispatch Code Points and Guidelines draft-ietf-6lo-dispatch-iana-registry-07 Abstract RFC4944 defines the ESC dispatch type to allow for additional dispatch octets in the 6lowpan header. The value of the ESC dispatch type was updated by RFC6282, however, its usage was not defined either in RFC6282 or in RFC4944. This document updates RFC4944 and RFC6282 by defining the ESC extension octet code points including registration of entries for known use cases at the time of writing of this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 11, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Chakrabarti, et al. Expires June 11, 2017 [Page 1] Internet-Draft IANA-6lo-dispatch December 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage of ESC dispatch octets . . . . . . . . . . . . . . . . . 3 3.1. Interaction with other RFC4944 implementations . . . . . . 4 3.2. ESC Extension Octets Typical Sequence . . . . . . . . . . . 5 3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 6 3.4. NALP and ESC dispatch types . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Chakrabarti, et al. Expires June 11, 2017 [Page 2] Internet-Draft IANA-6lo-dispatch December 2016 1. Introduction [RFC4944] section 5.1 defines the dispatch header and types. The ESC type is defined for using additional dispatch octets in the 6lowpan header. RFC 6282 modifies the value of the ESC dispatch type and that value is recorded in IANA registry [6LOWPAN-IANA]. However, the octets and usage following the ESC dispatch type are not defined in either [RFC4944] and [RFC6282]. In recent years with 6lowpan deployments, implementations and standards organizations have started using the ESC extension octets. This highlights the need for an updated IANA registration policy. The following sections record the ITU-T specification for ESC dispatch octet code points as an existing known usage and propose the definition of ESC extension octets for future applications. The document also requests IANA actions for the first extension octet following the ESC dispatch type. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Usage of ESC dispatch octets RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type for extension of dispatch octets. RFC 6282 [RFC6282] subsequently modified its value to [01 000000]. This document specifies that the first octet following the ESC dispatch type be used for extension type (extended dispatch values). Subsequent octets are left unstructured for the specific use of the extension type: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESC | ESC EXT Type | Extended Dispatch Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Frame Format with ESC dispatch type ESC: The left-most octet is the ESC dispatch type containing Chakrabarti, et al. Expires June 11, 2017 [Page 3] Internet-Draft IANA-6lo-dispatch December 2016 '01000000' ESC Extension Type (EET): It is the first octet following the ESC dispatch type. Extension type defines the payload for the additional dispatch octets. The values are from 0 to 255. Values 0 and 255 are reserved for future use. The remaining values from 1 to 254 are assigned by IANA. The EET values are similar to dispatch values in the 6lowpan header except they are preceded by the ESC dispatch type. Thus, ESC extension types and dispatch values are using orthogonal code spaces. Though not desirable, multiple ESC dispatch types MAY appear in a 6lowpan header. Section 3.1 describes how to handle an unknown ESC dispatch type. Extended Dispatch Payload (EDP): This part of the frame format must be defined by the corresponding extension type. A specification is required to define each usage of extension type and its corresponding Extension Payload. For the sake of interoperability, specifications of extension octets MUST NOT redefine the existing ESC Extension Type codes. Section 5.1 in RFC4944 indicates that the Extension Type field may contain additional dispatch values larger than 63, as corrected by [4944-ERRATA]. For the sake of interoperability, the new dispatch type (EET) MUST NOT modify the behavior of existing dispatch types [RFC4944]. 3.1. Interaction with other RFC4944 implementations It is expected that existing implementations of RFC4944 are not capable of processing ESC extension data octets as defined in this document. However, implementers have to assume that existing implementation that attempt to process an EET unknown to them will simply drop the packet or ignore the ESC dispatch octets. If an implementation following this document, during processing of the received packet reaches an ESC dispatch type for which it does not understand the extension octets (EET), it MUST drop that packet. However, it is important to clarify that a router node SHOULD forward a 6lowpan packet with the EET octets as long as it does not attempt to process any unknown ESC extension octets. Multiple ESC extension octets may appear in a packet. The ESC dispatch types can appear as the first, last or middle dispatch octets. However, a packet will get dropped by any node that does not understand the EET at the beginning of the packet. Placing an EET toward the front of the packet has a greater probability of causing the packet to be dropped than placing the same EET later in the packet. Placement of an EET later in the packet increases the chance Chakrabarti, et al. Expires June 11, 2017 [Page 4] Internet-Draft IANA-6lo-dispatch December 2016 that a legacy device will recognize and successfully process some dispatch type [RFC4944] before the EET. In this case, the legacy device will ignore the EET instead of dropping the entire packet. 3.2. ESC Extension Octets Typical Sequence ESC Extension octets sequence and order with respect to 6LoWPAN Mesh header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC dispatch type is present, ESC dispatch types MUST appear before the LOWPAN_IPHC dispatch type in order to maintain backward compatibility with RFC6282 section 3.2. The following diagrams provide examples of ESC extension octet usages: A LoWPAN encapsulated IPv6 Header compressed packet: +-------+------+--------+--------+-----------------+--------+ | ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld | +-------+------+--------+--------+-----------------+--------+ A LoWPAN_IPHC Header, Mesh header and an ESC extension octet: +-----+-----+-----+----+------+-------+---------------+------+ |M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld| +-----+-----+-----+----+------+-------+---------------+------+ A Mesh header with ESC dispatch types +-------+-------+-----+-----+-------+ | M Typ | M Hdr | ESC | EET |EDP | +-------+-------+-----+-----+-------+ With Fragment header +-------+-------+--------+------+-----+-----+-------+ | M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP | +-------+-------+--------+------+-----+-----+-------+ ESC dispatch type as a LowPAN encapsulation +--------+--------+--------+ | ESC | EET | EDP | +--------+--------+--------+ Figure 2: A 6lowpan packet with ESC dispatch types Chakrabarti, et al. Expires June 11, 2017 [Page 5] Internet-Draft IANA-6lo-dispatch December 2016 3.3. ITU-T G.9903 ESC type usage The ESC dispatch type is used in [G3-PLC] to provide native mesh routing and bootstrapping functionalities. The ITU-T recommendation [G3-PLC] section 9.4.2.3 defines commands which are formatted like ESC Extension type fields. The command ID values are 0x01 to 0x1F. The frame format is defined as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| ESC | Command ID | Command Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: G.9903 Frame Format with ESC dispatch type 3.4. NALP and ESC dispatch types According to RFC4944 [RFC4944] section 5.1, NALP dispatch octets are reserved for use as a kind of escape code for identification of non- 6lowpan payloads. Since ESC dispatch types are part of 6lowpan dispatch types (extended), they are orthogonal to NALP octets. This document clarifies that NALP dispatch codes only provide an escape method for non-6LoWPAN payloads when they appear as the initial octet of a LoWPAN encapsulation, and that the potential meaning of their appearance in any other location is reserved for future use. 4. IANA Considerations This document requests IANA to register the 'ESC Extension Type' values per the policy 'Specification Required' [RFC5226], following the same policy as in the IANA Considerations section of [RFC4944]. For each Extension Type (except the Reserved values) the specification MUST define corresponding Extended Dispatch Payload frame octets for the receiver implementation to read the ESC dispatch types in an interoperable fashion. [RFC5226] section 4.1 also indicates that "Specification Required" calls for a Designated Expert review of the public specification requesting registration of the ESC Extension Type values. The allocation of code points should follow the guidelines on "Usage Chakrabarti, et al. Expires June 11, 2017 [Page 6] Internet-Draft IANA-6lo-dispatch December 2016 of ESC dispatch octets" and the typical example sections. ESC Extension type code points MUST be used in conjunction with 6lo protocols following [RFC4944] or its derivatives. The requesting document MUST specify how the ESC dispatch octets will be used along with 6LOWPAN headers in their use cases. The initial values for the 'ESC Extension Type' fields are: +-------+---------------------------------+---------------+ | Value | Description | Reference | +-------+---------------------------------+---------------+ | 0 | Reserved for future use | This document | | | | | | 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| | | Command IDs | ITU-T G.9905 | | | | | | 32-254| Unassigned | This document | | |(Reserved for future IANA | | | | Assignment-- Spec Required) | | | | | | | 255 | Reserved for future use | This document | +-------+---------------------------------+---------------+ Figure 4: Initial Values for IANA Registry 5. Security Considerations There are no additional security threats due to the assignments of ESC dispatch type usage described in this document. Furthermore, this document forbids defining any extended dispatch values or extension types that modify the behavior of existing Dispatch types. 6. Acknowledgements The authors would like to thank the members of the 6lo WG for their comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys, Cedric Lavenu, Pascal Thubert for discussions regarding the bits allocation issues, which led to this document. Jonathan Hui and Robert Cragie provided extensive reviews and guidance for interoperability. The authors acknowledge the comments from the following people that helped shape this document: Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana, Scott Mansfield, Dale Worley and Russ Housley. Thanks to Brian Haberman, our document shepherd, for guidance in the IANA Considerations section. Chakrabarti, et al. Expires June 11, 2017 [Page 7] Internet-Draft IANA-6lo-dispatch December 2016 This document was produced using the xml2rfc tool. 7. References 7.1. Normative References [4944-ERRATA] "https://www.rfc-editor.org/errata_search.php?rfc=4944". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . 7.2. Informative References [6LOWPAN-IANA] "https://www.iana.org/assignments/_6lowpan-parameters/ _6lowpan-parameters.xhtml". [6loCHART] "https://datatracker.ietf.org/wg/6lo/charter". [G3-PLC] "http://www.itu.int/rec/T-REC-G.9903-201402-I". [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . Chakrabarti, et al. Expires June 11, 2017 [Page 8] Internet-Draft IANA-6lo-dispatch December 2016 Authors' Addresses Samita Chakrabarti San Jose, CA USA Email: samitac.ietf@gmail.com Gabriel Montenegro Microsoft USA Email: gabriel.montenegro@microsoft.com Ralph Droms USA Email: rdroms.ietf@gmail.com James Woodyatt Google Mountain View, CA USA Email: jhw@google.com Chakrabarti, et al. Expires June 11, 2017 [Page 9] ./draft-ietf-hip-multihoming-12.txt0000664000764400076440000017126212777022757016520 0ustar iustyiusty Network Working Group T. Henderson, Ed. Internet-Draft University of Washington Intended status: Standards Track C. Vogt Expires: April 13, 2017 Independent J. Arkko Ericsson October 10, 2016 Host Multihoming with the Host Identity Protocol draft-ietf-hip-multihoming-12 Abstract This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 13, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Henderson, et al. Expires April 13, 2017 [Page 1] Internet-Draft HIP Multihoming October 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Multiple Addresses . . . . . . . . . . . . . . . . . 6 4.2.2. Multiple Security Associations . . . . . . . . . . . 6 4.2.3. Host Multihoming for Fault Tolerance . . . . . . . . 7 4.2.4. Host Multihoming for Load Balancing . . . . . . . . . 9 4.2.5. Site Multihoming . . . . . . . . . . . . . . . . . . 10 4.2.6. Dual Host Multihoming . . . . . . . . . . . . . . . . 10 4.2.7. Combined Mobility and Multihoming . . . . . . . . . . 11 4.2.8. Initiating the Protocol in R1, I2, or R2 . . . . . . 11 4.2.9. Using LOCATOR_SETs across Addressing Realms . . . . . 13 4.3. Interaction with Security Associations . . . . . . . . . 13 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 14 5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 16 5.3. Verifying Address Reachability . . . . . . . . . . . . . 18 5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative references . . . . . . . . . . . . . . . . . . 21 9.2. Informative references . . . . . . . . . . . . . . . . . 22 Appendix A. Document Revision History . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction and Scope The Host Identity Protocol [RFC7401] (HIP) supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities. When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) are instead bound to representations of these host identities, and the IP addresses are only used for packet forwarding. However, each host must also know at least one IP address at which its peers are reachable. Initially, these IP addresses are the ones used during the HIP base exchange. Henderson, et al. Expires April 13, 2017 [Page 2] Internet-Draft HIP Multihoming October 2016 One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. Basic host mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case in which a host has a single address and changes its network point- of-attachment while desiring to preserve the HIP-enabled security association. Host multihoming is somewhat of a dual case to host mobility, in that a host may simultaneously have more than one network point-of-attachment. There are potentially many variations of host multihoming possible. [I-D.ietf-hip-rfc5206-bis] specifies the format of the HIP parameter (LOCATOR_SET parameter) used to convey IP addressing information between peers, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for an address verification mechanism. The scope of this document encompasses messaging and elements of procedure for some basic host multihoming scenarios of interest. Another variation of multihoming that has been heavily studied is site multihoming. Solutions for host multihoming in multihomed IPv6 networks have been specified by the IETF shim6 working group. The shim6 protocol [RFC5533] bears many architectural similarities to HIP but there are differences in the security model and in the protocol. While HIP can potentially be used with transports other than the ESP transport format [RFC7402], this document largely assumes the use of ESP and leaves other transport formats for further study. Finally, making underlying IP multihoming transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP multihoming address change, are outside the scope of this document. This specification relies on implementing Section 4 (LOCATOR_SET Parameter Format) and Section 5 (Processing Rules) of [I-D.ietf-hip-rfc5206-bis] as a starting point for this implementation. 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following terms used in this document are defined in [I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred locator, and Credit Based Authorization. Henderson, et al. Expires April 13, 2017 [Page 3] Internet-Draft HIP Multihoming October 2016 3. Protocol Model The protocol model for HIP support of host multihoming extends the model for host mobility described in Section 3 of [I-D.ietf-hip-rfc5206-bis]. This section only highlights the differences. In host multihoming, a host has multiple locators simultaneously rather than sequentially, as in the case of mobility. By using the LOCATOR_SET parameter defined in [I-D.ietf-hip-rfc5206-bis], a host can inform its peers of additional (multiple) locators at which it can be reached. When multiple locators are available and announced to the peer, a host can designate a particular locator as a "preferred" locator, meaning that the host prefers that its peer send packets to the designated address before trying an alternative address. Although this document defines a basic mechanism for multihoming, it does not define all possible policies and procedures, such as which locators to choose when more than one is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC6724]), and the implications of multihoming on transport protocols. 4. Protocol Overview In this section, we briefly introduce a number of usage scenarios for HIP multihoming. These scenarios assume that HIP is being used with the ESP transport [RFC7402], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC7401], the use of the ESP transport format [RFC7402], and the HIP mobility specification [I-D.ietf-hip-rfc5206-bis]. However, for the (relatively) uninitiated reader, it is most important to keep in mind that in HIP the actual payload traffic is protected with ESP, and that the ESP Security Parameter Index (SPI) acts as an index to the right host-to- host context. 4.1. Background The multihoming scenarios can be explained in contrast to the non- multihoming case described in the base protocol specification. We review the pertinent details here. In the base specification when used with the ESP transport format, the HIP base exchange will set up a single SA in each direction. The IP addresses associated with the SAs are the same as those used to convey the HIP packets. For data traffic, a security policy database (SPD) and security association database (SAD) will likely exist, following the IPsec architecture. One distinction between HIP and IPsec, however, is that the host IDs, Henderson, et al. Expires April 13, 2017 [Page 4] Internet-Draft HIP Multihoming October 2016 and not the IP addresses, are conceptually used as selectors in the SPD. In the outbound direction, as a result of SPD processing, when an outbound SA is selected, the correct IP destination address for the peer must also be assigned. Therefore, outbound SAs are conceptually associated with the peer IP address that must be used as the destination IP address below the HIP layer. In the inbound direction, the IP addresses may be used as selectors in the SAD to look up the SA, but they are not strictly required; the ESP SPI may be used alone. To summarize, in the non-multihoming case, there is only one source IP address, one destination IP address, one inbound SA, and one outbound SA. The HIP readdressing protocol [I-D.ietf-hip-rfc5206-bis] is an asymmetric protocol in which a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. IP address and ESP SPI information is carried in Locator data structures in a HIP parameter called a LOCATOR_SET. The HIP mobility specification [I-D.ietf-hip-rfc5206-bis] describes how the LOCATOR_SET is carried in a HIP UPDATE packet. To summarize the mobility elements of procedure, as background for multihoming, the basic idea of host mobility is to communicate a local IP address change to the peer when active HIP-maintained SAs are in use. To do so, the IP address must be conveyed, any association between the IP address and an inbound SA (via the SPI index) may be conveyed, and protection against flooding attacks must be ensured. The association of an IP address with an SPI is performed by a Locator of type 1, which is a concatenation of an ESP SPI with an IP address. An address verification method is specified in [I-D.ietf-hip-rfc5206-bis]. It is expected that addresses learned in multihoming scenarios also are subject to the same verification rules. The scenarios at times describe addresses as being in either an ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a host, newly-learned addresses of the peer must be verified before put into active service, and addresses removed by the peer are put into a deprecated state. Under limited conditions described in [I-D.ietf-hip-rfc5206-bis], an UNVERIFIED address may be used. With this background, we next describe additional protocol to facilitate scenarios in which one or both hosts have multiple IP addresses available. Increasingly, this is the common case with network-connected hosts on the Internet. Henderson, et al. Expires April 13, 2017 [Page 5] Internet-Draft HIP Multihoming October 2016 4.2. Usage Scenarios 4.2.1. Multiple Addresses Hosts may have multiple IP addresses within different address families (IPv4 and IPv6) and scopes available to support HIP messaging and HIP-enabled SAs. The multiple addresses may be on a single or multiple network interfaces. It is outside of the scope of this document to specify how a host decides which of possibly multiple addresses may be used to support a HIP association. Some IP addresses may be held back from usage due to privacy, security, or cost considerations. When multiple IP addresses are shared with a peer, the procedures described in the HIP mobility specification [I-D.ietf-hip-rfc5206-bis] allow for a host to set a Preferred bit, requesting that one of the multiple addresses be preferred for control- or data-plane traffic. It is also permitted to leave the Preferred bit unset for all addresses, allowing the peer to make address selection decisions. Hosts that use link-local addresses as source addresses in their HIP handshakes may not be reachable by a mobile peer. Such hosts SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR_SET parameter. To support mobility, as described in the HIP mobility specification [I-D.ietf-hip-rfc5206-bis], the LOCATOR_SET may be sent in a HIP UPDATE packet. To support multihoming, the LOCATOR_SET may also be sent in R1, I2, or R2 packets defined in the HIP protocol specification [RFC7401]. The reason to consider to send LOCATOR_SET parameters in the base exchange packets is to convey all usable addresses for fault-tolerance or load balancing considerations. 4.2.2. Multiple Security Associations When multiple addresses are available between peer hosts, a question that arises is whether to use one or multiple SAs. The intent of this specification is to support different use cases but to leave the policy decision to the hosts. When one host has n addresses and the other host has m addresses, it is possible to set up as many as (n * m) SAs in each direction. In such a case, every combination of source and destination IP address would have a unique SA, and the possibility of reordering of datagrams on each SA will be lessened (ESP SAs may have an anti- replay window [RFC4303] sensitive to reordering). However, the downside to creating a mesh of SAs is the signaling overhead required Henderson, et al. Expires April 13, 2017 [Page 6] Internet-Draft HIP Multihoming October 2016 (for exchanging UPDATE messages conveying ESP_INFO parameters) and the state maintenance required in the SPD/SAD. For load balancing, when multiple paths are to be used in parallel, it may make sense to create different SAs for different paths. In this use case, while a full mesh of 2 * (n * m) SAs may not be required, it may be beneficial to create one SA pair per load- balanced path to avoid anti-replay window issues. For fault tolerance, it is more likely that a single SA can be used and multiple IP addresses associated with that SA, and the alternative addresses used only upon failure detection of the addresses in use. Techniques for path failure detection are outside the scope of this specification. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator. In summary, whether and how a host decides to leverage additional addresses in a load-balancing or fault-tolerant manner is outside the scope of the specification (although the academic literature on multipath TCP schedulers may provide guidance on how to design such a policy). However, in general, this document recommends that for fault tolerance, it is likely sufficient to use a single SA pair for all addresses, and for load balancing, to support a different SA pair for all active paths being balanced across. 4.2.3. Host Multihoming for Fault Tolerance A (mobile or stationary) host may have more than one interface or global address. The host may choose to notify the peer host of the additional interface or address by using the LOCATOR_SET parameter. The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet, or may be conveyed, after the base exchange completes in an UPDATE packet. When more than one locator is provided to the peer host, the host MAY indicate which locator is preferred (the locator on which the host prefers to receive traffic). By default, the address that a host uses in the base exchange is its preferred locator (for the address family and address scope in use during the base exchange) until indicated otherwise. It may be the case that the host does not express any preferred locators. In the multihoming case, the sender may also have multiple valid locators from which to source traffic. In practice, a HIP association in a multihoming configuration may have both a preferred peer locator and a preferred local locator. The host should try to use the peer's preferred locator unless policy or other circumstances Henderson, et al. Expires April 13, 2017 [Page 7] Internet-Draft HIP Multihoming October 2016 prevent such usage. A preferred local locator may be overridden if source address selection rules on the destination address (peer's preferred locator) suggest the use of a different source address. Although the protocol may allow for configurations in which there is an asymmetric number of SAs between the hosts (e.g., one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is suggested that inbound and outbound SAs be created pairwise between hosts. When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should be also rekeyed at that time. Section 4.3 discusses the interaction between addresses and security associations in more detail. Consider the case of two hosts, one single-homed and one multihomed. The multihomed host may decide to inform the single-homed host about its other address(es). It may choose to do so as follows. If the multihomed host wishes to convey the additional address(es) for fault tolerance, it should include all of its addresses in Locator records, indicating the Traffic Type, Locator Type, and Preferred Locator for each address. If it wishes to bind any particular address to an existing SPI, it may do so by using a Locator of Type 1 as specified in the HIP mobility specification [I-D.ietf-hip-rfc5206-bis]. It does not need to rekey the existing SA or request additional SAs at this time. Figure 1 illustrates this scenario. Note that the conventions for message parameter notations in figures (use of parentheses and brackets) is defined in Section 2.2 of [RFC7401]. Multi-homed Host Peer Host UPDATE(LOCATOR_SET, SEQ) -----------------------------------> UPDATE(ACK) <----------------------------------- Figure 1: Basic Multihoming Scenario In this scenario, the peer host associates the multiple addresses with the SA pair between it and the multihomed host. It may also undergo address verification procedures to transition the addresses to ACTIVE state. For inbound data traffic, it may choose to use the addresses along with the SPI as selectors. For outbound data traffic, it must choose among the available addresses of the multihomed host, considering the state of address verification [I-D.ietf-hip-rfc5206-bis] of each address, and also considering available information about whether an address is in a working state. Henderson, et al. Expires April 13, 2017 [Page 8] Internet-Draft HIP Multihoming October 2016 4.2.4. Host Multihoming for Load Balancing A multihomed host may decide to set up new SA pairs corresponding to new addresses, for the purpose of load balancing. The decision to load balance and the mechanism for splitting load across multiple SAs is out of scope of this document. The scenario can be supported by sending the LOCATOR_SET parameter with one or more ESP_INFO parameters to initiate new ESP SAs. To do this, the multihomed host sends a LOCATOR_SET with an ESP_INFO, indicating the request for a new SA by setting the OLD SPI value to zero, and the NEW SPI value to the newly created incoming SPI. A Locator Type of "1" is used to associate the new address with the new SPI. The LOCATOR_SET parameter also contains a second Type "1" locator, that of the original address and SPI. To simplify parameter processing and avoid explicit protocol extensions to remove locators, each LOCATOR_SET parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). The multihomed host waits for a corresponding ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. As in the mobility case, the peer host must perform an address verification before actively using the new address. Figure 2 illustrates this scenario. Multi-homed Host Peer Host UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN]) -----------------------------------> UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> Figure 2: Host Multihoming for Load Balancing In multihoming scenarios, it is important that hosts receiving UPDATEs associate them correctly with the destination address used in the packet carrying the UPDATE. When processing inbound LOCATOR_SETs that establish new security associations on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR_SET as the local address to which the LOCATOR_SET plus ESP_INFO is targeted. This is because hosts may send UPDATEs with the same (locator) IP address to different peer addresses -- this has the effect of creating multiple inbound SAs implicitly affiliated with different peer source addresses. Henderson, et al. Expires April 13, 2017 [Page 9] Internet-Draft HIP Multihoming October 2016 4.2.5. Site Multihoming A host may have an interface that has multiple globally routable IP addresses. Such a situation may be a result of the site having multiple upper Internet Service Providers, or just because the site provides all hosts with both IPv4 and IPv6 addresses. The host should stay reachable at all or any subset of the currently available global routable addresses, independent of how they are provided. This case is handled the same as if there were different IP addresses, described above in Section 4.2.3 and Section 4.2.4. Note that a single interface may have addresses corresponding to site multihoming while the host itself may also have multiple network interfaces. Note that a host may be multihomed and mobile simultaneously, and that a multihomed host may want to protect the location of some of its interfaces while revealing the real IP address of some others. This document does not presently additional site multihoming extensions to HIP; such extensions are for further study. 4.2.6. Dual Host Multihoming Consider the case in which both hosts are multihomed and would like to notify the peer of an additional address after the base exchange completes. It may be the case that both hosts choose to simply announce the second address in a LOCATOR_SET parameter using an UPDATE message exchange. It may also be the case that one or both hosts decide to ask for new SA pairs to be created using the newly announced address. In the case that both hosts request this, the result will be a full mesh of SAs as depicted in Figure 3. In such a scenario, consider that host1, which used address addr1a in the base exchange to set up SPI1a and SPI2a, wants to add address addr1b. It would send an UPDATE with LOCATOR_SET (containing the address addr1b) to host2, using destination address addr2a, and a new ESP_INFO, and a new set of SPIs would be added between hosts 1 and 2 (call them SPI1b and SPI2b; not shown in the figure). Next, consider host2 deciding to add addr2b to the relationship. Host2 must select one of host1's addresses towards which to initiate an UPDATE. It may choose to initiate an UPDATE to addr1a, addr1b, or both. If it chooses to send to both, then a full mesh (four SA pairs) of SAs would exist between the two hosts. This is the most general case; the protocol is flexible enough to accommodate this choice. Henderson, et al. Expires April 13, 2017 [Page 10] Internet-Draft HIP Multihoming October 2016 -<- SPI1a -- -- SPI2a ->- host1 < > addr1a <---> addr2a < > host2 ->- SPI2a -- -- SPI1a -<- addr1b <---> addr2a (second SA pair) addr1a <---> addr2b (third SA pair) addr1b <---> addr2b (fourth SA pair) Figure 3: Dual Multihoming Case in which Each Host Uses LOCATOR_SET to Add a Second Address 4.2.7. Combined Mobility and Multihoming Mobile hosts may be simultaneously mobile and multihomed, i.e., have multiple mobile interfaces. Furthermore, if the interfaces use different access technologies, it is fairly likely that one of the interfaces may appear stable (retain its current IP address) while some other(s) may experience mobility (undergo IP address change). The use of LOCATOR_SET plus ESP_INFO should be flexible enough to handle most such scenarios, although more complicated scenarios have not been studied so far. 4.2.8. Initiating the Protocol in R1, I2, or R2 A Responder host MAY include a LOCATOR_SET parameter in the R1 packet that it sends to the Initiator. This parameter MUST be protected by the R1 signature. If the R1 packet contains LOCATOR_SET parameters with a new Preferred locator, the Initiator SHOULD directly set the new Preferred locator to status ACTIVE without performing address verification first, and MUST send the I2 packet to the new Preferred locator. The I1 destination address and the new Preferred locator may be identical. All new non-preferred locators must still undergo address verification once the base exchange completes. It is also possible for the host to send the LOCATOR_SET without any Preferred bits set, in which case the exchange will continue as normal and the newly-learned addresses will be in an UNVERIFIED state at the initiator. Henderson, et al. Expires April 13, 2017 [Page 11] Internet-Draft HIP Multihoming October 2016 Initiator Responder R1 with LOCATOR_SET <----------------------------------- record additional addresses change responder address I2 sent to newly indicated preferred address -----------------------------------> (process normally) R2 <----------------------------------- (process normally, later verification of non-preferred locators) Figure 4: LOCATOR_SET Inclusion in R1 An Initiator MAY include one or more LOCATOR_SET parameters in the I2 packet, independent of whether or not there was a LOCATOR_SET parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR_SET parameters, the Responder MUST still send the R2 packet to the source address of the I2. The new Preferred locator, if set, SHOULD be identical to the I2 source address. If the I2 packet contains LOCATOR_SET parameters, all new locators must undergo address verification as usual, and the ESP traffic that subsequently follows should use the Preferred locator. Initiator Responder I2 with LOCATOR_SET -----------------------------------> (process normally) record additional addresses R2 sent to source address of I2 <----------------------------------- (process normally) Figure 5: LOCATOR_SET Inclusion in I2 The I1 and I2 may be arriving from different source addresses if the LOCATOR_SET parameter is present in R1. In this case, implementations simultaneously using multiple pre-created R1s, indexed by Initiator IP addresses, may inadvertently fail the puzzle solution of I2 packets due to a perceived puzzle mismatch. See, for instance, the example in Appendix A of [RFC7401]. As a solution, the Responder's puzzle indexing mechanism must be flexible enough to accommodate the situation when R1 includes a LOCATOR_SET parameter. Henderson, et al. Expires April 13, 2017 [Page 12] Internet-Draft HIP Multihoming October 2016 Finally, the R2 may be used to carry the LOCATOR_SET parameter. In this case, the LOCATOR_SET is covered by the HIP_MAC_2 and HIP_SIGNATURE. Including LOCATOR_SET in R2 as opposed to R1 may have some advantages when a host prefers not to divulge additional locators until after the I2 is successfully processed. When the LOCATOR_SET parameter is sent in an UPDATE packet, then the receiver will respond with an UPDATE acknowledgment. When the LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base exchange retransmission mechanism will confirm its successful delivery. 4.2.9. Using LOCATOR_SETs across Addressing Realms It is possible for HIP associations to use these mechanisms to migrate their HIP associations and security associations from addresses in the IPv4 addressing realm to IPv6 or vice versa. It may be possible for a state to arise in which both hosts are only using locators in different addressing realms, but in such a case, some type of mechanism for interworking between the different realms must be employed; such techniques are outside the scope of the present text. 4.3. Interaction with Security Associations A host may establish any number of security associations (or SPIs) with a peer. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing, or to perform load balancing. A basic property of HIP SAs is that the inbound IP address is not used to lookup the incoming SA. However, the use of different source and destination addresses typically leads to different paths, with different latencies in the network, and if packets were to arrive via an arbitrary destination IP address (or path) for a given SPI, the reordering due to different latencies may cause some packets to fall outside of the ESP anti-replay window. For this reason, HIP provides a mechanism to affiliate destination addresses with inbound SPIs, when there is a concern that anti-replay windows might be violated. In this sense, we can say that a given inbound SPI has an "affinity" for certain inbound IP addresses, and this affinity is communicated to the peer host. Each physical interface SHOULD have a separate SA, unless the ESP anti-replay window is extended or disabled. Moreover, even when the destination addresses used for a particular SPI are held constant, the use of different source interfaces may also cause packets to fall outside of the ESP anti-replay window, since the path traversed is often affected by the source address or Henderson, et al. Expires April 13, 2017 [Page 13] Internet-Draft HIP Multihoming October 2016 interface used. A host has no way to influence the source interface on which a peer sends its packets on a given SPI. A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI. For this reason, a host may find it useful to change its SPI or at least reset its ESP anti-replay window when the peer host readdresses. 5. Processing Rules Basic processing rules for the LOCATOR_SET parameter are specified in [I-D.ietf-hip-rfc5206-bis]. This document focuses on multihoming- specific rules. 5.1. Sending LOCATOR_SETs The decision of when to send a LOCATOR_SET, and which addresses to include, is a local policy issue. [I-D.ietf-hip-rfc5206-bis] recommends that a host "send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association, and (when it) assumes that the change is going to last at least for a few seconds." It is possible to delay the exposure of additional locators to the peer, and to send data from previously unannounced locators, as might arise in certain mobility or multihoming situations. When a host decides to inform its peers about changes in its IP addresses, it has to decide how to group the various addresses with SPIs. If hosts are deployed in an operational environment in which HIP-aware NATs and firewalls (that may perform parameter inspection) exist, and different such devices may exist on different paths, hosts may take that knowledge into consideration about how addresses are grouped, and may send the same LOCATOR_SET in separate UPDATEs on the different paths. However, more detailed guidelines about how to operate in the presence of such HIP-aware NATs and firewalls is a topic for further study. Since each SPI is associated with a different Security Association, the grouping policy may also be based on ESP anti-replay protection considerations. In the typical case, simply basing the grouping on actual kernel level physical and logical interfaces may be the best policy. Grouping policy is outside of the scope of this document. Locators corresponding to tunnel interfaces (e.g. IPsec tunnel interfaces or Mobile IP home addresses) or other virtual interfaces MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid announcing such locators as preferred locators if more direct paths may be obtained by instead preferring locators from non-tunneling interfaces if such locators provide a more direct path to the HIP peer. Henderson, et al. Expires April 13, 2017 [Page 14] Internet-Draft HIP Multihoming October 2016 [I-D.ietf-hip-rfc5206-bis] specifies that hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. Link-local addresses MAY be announced to peers that are known to be neighbors on the same link, such as when the IP destination address of a peer is also link-local. The announcement of link-local addresses in this case is a policy decision; link-local addresses used as Preferred locators will create reachability problems when the host moves to another link. In any case, link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link. Once the host has decided on the groups and assignment of addresses to the SPIs, it creates a LOCATOR_SET parameter that serves as a complete representation of the addresses and associated SPIs intended for active use. We now describe a few cases introduced in Section 4. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that separate the HIP control plane from data plane traffic). Other mobility and multihoming cases are possible but are left for further experimentation. 1. Host multihoming (addition of an address). We only describe the simple case of adding an additional address to a (previously) single-homed, non-mobile host. The host MAY choose to simply announce this address to the peer, for fault tolerance. To do this, the multihomed host creates a LOCATOR_SET parameter including the existing address and SPI as a Type "1" Locator, and the new address as a Type "0" Locator. The host sends this in an UPDATE message with SEQ parameter, which is acknowledged by the peer. 2. The host MAY set up a new SA pair between this new address and an address of the peer host. To do this, the multihomed host creates a new inbound SA and creates a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI field of "0", a NEW SPI field corresponding to the new SPI, and a KEYMAT Index as selected by local policy. The host adds to the UPDATE message a LOCATOR_SET with two Type "1" Locators: the original address and SPI active on the association, and the new address and new SPI being added (with the SPI matching the NEW SPI contained in the ESP_INFO). The Preferred bit SHOULD be set depending on the policy to tell the peer host which of the two locators is preferred. The UPDATE also contains a SEQ parameter and optionally a DIFFIE_HELLMAN parameter, and follows rekeying procedures with respect to this new address. The UPDATE message SHOULD be sent to the peer's Preferred address with a source address corresponding to the new locator. Henderson, et al. Expires April 13, 2017 [Page 15] Internet-Draft HIP Multihoming October 2016 The sending of multiple LOCATOR_SETs is unsupported. Note that the inclusion of LOCATOR_SET in an R1 packet requires the use of Type "0" locators since no SAs are set up at that point. 5.2. Handling Received LOCATOR_SETs A host SHOULD be prepared to receive a LOCATOR_SET parameter in the following HIP packets: R1, I2, R2, and UPDATE. This document describes sending both ESP_INFO and LOCATOR_SET parameters in an UPDATE. The ESP_INFO parameter is included when there is a need to rekey or key a new SPI, and can otherwise be included for the possible benefit of HIP-aware middleboxes. The LOCATOR_SET parameter contains a complete map of the locators that the host wishes to make or keep active for the HIP association. In general, the processing of a LOCATOR_SET depends upon the packet type in which it is included. Here, we describe only the case in which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are sent in an UPDATE message; other cases are for further study. The steps below cover each of the cases described in Section 5.1. The processing of ESP_INFO and LOCATOR_SET parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host SHOULD first process the ESP_INFO before the LOCATOR_SET, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type "1" locator will only contain a reference to the new SPI. When a host receives a validated HIP UPDATE with a LOCATOR_SET and ESP_INFO parameter, it processes the ESP_INFO as follows. The ESP_INFO parameter indicates whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of middleboxes. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter: 1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for middleboxes) and no rekeying is necessary. 2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW SPI is a different non-zero value, the existing SA is being rekeyed and the host follows HIP ESP rekeying procedures by creating a new outbound SA with an SPI corresponding to the NEW SPI, with no addresses bound to this SPI. Note that locators in the LOCATOR_SET parameter will reference this new SPI instead of the old SPI. Henderson, et al. Expires April 13, 2017 [Page 16] Internet-Draft HIP Multihoming October 2016 3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new non-zero value, then a new SA is being requested by the peer. This case is also treated like a rekeying event; the receiving host must create a new SA and respond with an UPDATE ACK. 4. (deprecating the SA) If the OLD SPI indicates an existing SPI and the NEW SPI is zero, the SA is being deprecated and all locators uniquely bound to the SPI are put into the DEPRECATED state. If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped. Next, the locators in the LOCATOR_SET parameter are processed. For each locator listed in the LOCATOR_SET parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it may be allowed that the host runs HIP with itself. For each Type "1" address listed in the LOCATOR_SET parameter, the host checks whether the address is already bound to the SPI indicated. If the address is already bound, its lifetime is updated. If the status of the address is DEPRECATED, the status is changed to UNVERIFIED. If the address is not already bound, the address is added, and its status is set to UNVERIFIED. If there exist remaining addresses corresponding to the SPI that were NOT listed in the LOCATOR_SET parameter, the host sets the status of such addresses to DEPRECATED. For each Type "0" address listed in the LOCATOR_SET parameter, if the status of the address is DEPRECATED, or the address was not previously known, the status is changed to UNVERIFIED. The host MAY choose to associate this address with one or more SAs. The association with different SAs is a local policy decision, unless the peer has indicated that the address is Preferred, in which case the address should be put into use on a SA that is prioritized in the security policy database. As a result, at the end of processing, the addresses listed in the LOCATOR_SET parameter have either a state of UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR_SET parameter have a state of DEPRECATED. Once the host has processed the locators, if the LOCATOR_SET parameter contains a new Preferred locator, the host SHOULD initiate a change of the Preferred locator. This requires that the host first verifies reachability of the associated address, and only then changes the Preferred locator; see Section 5.4. Henderson, et al. Expires April 13, 2017 [Page 17] Internet-Draft HIP Multihoming October 2016 If a host receives a locator with an unsupported Locator Type, and when such a locator is also declared to be the Preferred locator for the peer, the host SHOULD send a NOTIFY error with a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field containing the locator(s) that the receiver failed to process. Otherwise, a host MAY send a NOTIFY error if a (non-preferred) locator with an unsupported Locator Type is received in a LOCATOR_SET parameter. 5.3. Verifying Address Reachability Address verification is defined in [I-D.ietf-hip-rfc5206-bis]. When address verification is in progress for a new Preferred locator, the host SHOULD select a different locator listed as ACTIVE, if one such locator is available, to continue communications until address verification completes. Alternatively, the host MAY use the new Preferred locator while in UNVERIFIED status to the extent Credit- Based Authorization permits. Credit-Based Authorization is explained in [I-D.ietf-hip-rfc5206-bis]. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE. 5.4. Changing the Preferred Locator A host MAY want to change the Preferred outgoing locator for different reasons, e.g., because traffic information or ICMP error messages indicate that the currently used preferred address may have become unreachable. Another reason may be due to receiving a LOCATOR_SET parameter that has the "P" bit set. To change the Preferred locator, the host initiates the following procedure: 1. If the new Preferred locator has ACTIVE status, the Preferred locator is changed and the procedure succeeds. 2. If the new Preferred locator has UNVERIFIED status, the host starts to verify its reachability. The host SHOULD use a different locator listed as ACTIVE until address verification completes if one such locator is available. Alternatively, the host MAY use the new Preferred locator, even though in UNVERIFIED status, to the extent Credit-Based Authorization permits. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE and its use is no longer governed by Credit-Based Authorization. 3. If the peer host has not indicated a preference for any address, then the host picks one of the peer's ACTIVE addresses randomly Henderson, et al. Expires April 13, 2017 [Page 18] Internet-Draft HIP Multihoming October 2016 or according to policy. This case may arise if, for example, ICMP error messages that deprecate the Preferred locator arrive, but the peer has not yet indicated a new Preferred locator. 4. If the new Preferred locator has DEPRECATED status and there is at least one non-deprecated address, the host selects one of the non-deprecated addresses as a new Preferred locator and continues. If the selected address is UNVERIFIED, the address verification procedure described above will apply. 6. Security Considerations This document extends the scope of host mobility solutions defined in [I-D.ietf-hip-rfc5206-bis] to include also host multihoming, and as a result, many of the same security considerations for mobility also pertain to multihoming. In particular, [I-D.ietf-hip-rfc5206-bis] describes how HIP host mobility is resistant to different types of impersonation attacks and DoS attacks. The security considerations for this document are similar to those of [I-D.ietf-hip-rfc5206-bis] because the strong authentication capabilities for mobility also carry over to end-host multihoming. [RFC4218] provides a threat analysis for IPv6 multihoming, and the remainder of this section first describes how HIP host multihoming addresses those previously described threats, and then discusses some additional security considerations. The high-level threats discussed in [RFC4218] involve redirection attacks for the purposes of packet recording, data manipulation, and availability. There are a few types of attackers to consider: on- path attackers, off-path attackers, and malicious hosts. [RFC4218] also makes the comment that in identifier/locator split solutions such as HIP, application security mechanisms should be tied to the identifier, not the locator, and attacks on the identifier mechanism and on the mechanism binding locators to the identifier are of concern. This document does not consider the former issue (application layer security bindings) to be within scope. The latter issue (locator bindings to identifier) is directly addressed by the cryptographic protections of the HIP protocol, in that locators associated to an identifier are listed in HIP packets that are signed using the identifier key. Section 3.1 of [RFC4218] lists several classes of security configurations in use in the Internet. HIP maps to the fourth (strong identifier) and fifth ("leap-of-faith") categories, the latter being associated with the optional opportunistic mode of HIP operation. The remainder of Section 3 describe existing security Henderson, et al. Expires April 13, 2017 [Page 19] Internet-Draft HIP Multihoming October 2016 problems in the Internet, and comments that the goal of a multihoming solution is not to solve them specifically but rather not to make any of them worse. HIP multihoming should not increase the severity of the identified risks. One concern for both HIP mobility and multihoming is the susceptibility of the mechanisms to misuse for flooding based redirections due to a malicious host. The mechanisms described in [I-D.ietf-hip-rfc5206-bis] for address verification are important in this regard. Regarding the new types of threats introduced by multihoming (Section 4 of [RFC4218]), HIP multihoming should not introduce new concerns. Classic and premeditated redirection are prevented by the strong authentication in HIP messages. Third-party denial-of-service attacks are prevented by the address verification mechanism. Replay attacks can be avoided via use of replay protection in Encapsulating Security Payload (ESP) Security Associations (SAs). In addition, accepting packets from unknown locators is protected by either the strong authentication in the HIP control packets, or by the ESP-based encryption in use for data packets. The HIP mechanisms are designed to limit the ability to introduce DoS on the mechanisms themselves (Section 7 of [RFC4218]). Care is taken in the HIP base exchange to avoid creating state or performing much work before hosts can authenticate one another. A malicious host involved in HIP multihoming with another host might attempt to misuse the mechanisms for multihoming by, for instance, increasing the state required or inducing a resource limitation attack by sending too many candidate locators to the peer host. Therefore, implementations supporting the multihoming extensions should consider to avoid accepting large numbers of peer locators, and to rate limit any UPDATE messages being exchanged. The exposure of a host's IP addresses through HIP mobility and multihoming extensions may raise the following privacy concern. The administrator of a host may be trying to hide its location in some context through the use of a VPN or other virtual interfaces. Similar privacy issues also arise in other frameworks such as WebRTC and are not specific to HIP. Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges. Finally, some implementations of VPN tunneling have experienced instances of 'leakage' of flows that were intended to have been protected by a security tunnel but are instead sent in the clear, perhaps because some of the addresses used fall outside of the range of addresses configured for the tunnel in the security policy or association database. Implementers are advised to take steps to ensure that the usage of multiple addresses between hosts does not Henderson, et al. Expires April 13, 2017 [Page 20] Internet-Draft HIP Multihoming October 2016 cause accidental leakage of some data session traffic outside of the ESP-protected envelope. 7. IANA Considerations This document has no requests for IANA actions. 8. Authors and Acknowledgments This document contains content that was originally included in RFC5206. Pekka Nikander and Jari Arkko originated RFC5206, and Christian Vogt and Thomas Henderson (editor) later joined as co- authors. Also in RFC5206, Greg Perkins contributed the initial draft of the security section, and Petri Jokela was a co-author of the initial individual submission. The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document. Concepts from a paper on host multihoming across address families, by Samu Varjonen, Miika Komu, and Andrei Gurtov, contributed to this revised version. 9. References 9.1. Normative references [I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-13 (work in progress), September 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . Henderson, et al. Expires April 13, 2017 [Page 21] Internet-Draft HIP Multihoming October 2016 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . 9.2. Informative references [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, October 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, . Henderson, et al. Expires April 13, 2017 [Page 22] Internet-Draft HIP Multihoming October 2016 Appendix A. Document Revision History To be removed upon publication +----------+--------------------------------------------------------+ | Revision | Comments | +----------+--------------------------------------------------------+ | draft-00 | Initial version with multihoming text imported from | | | RFC5206. | | | | | draft-01 | Document refresh; no other changes. | | | | | draft-02 | Document refresh; no other changes. | | | | | draft-03 | Document refresh; no other changes. | | | | | draft-04 | Document refresh; no other changes. | | | | | draft-05 | Move remaining multihoming material from RFC5206-bis | | | to this document | | | | | | Update lingering references to LOCATOR parameter to | | | LOCATOR_SET | | | | | draft-06 | Document refresh with updated references. | | | | | draft-07 | Document refresh; no other changes. | | | | | draft-08 | issues 3 and 11: Address complaints of complexity due | | | to full mesh of SAs for multihoming. | | | | | | issue 5: Improve draft based on recommendations for | | | cross-family handovers in paper by Varjonen et. al. | | | | | | issue 7: Clarify and distinguish between load | | | balancing and fault tolerance use cases. | | | | | draft-09 | Update author affiliations, IPR boilerplate to | | | trust200902, and one stale reference. | | | | | draft-10 | Improve security considerations section by reviewing | | | RFC 4218. | | | | | | Clarified comment about applicability of shim6. | | | | | draft-11 | Editorial improvements based on last call comments. | | | | | draft-12 | Added section about locator privacy concerns to the | Henderson, et al. Expires April 13, 2017 [Page 23] Internet-Draft HIP Multihoming October 2016 | | Security Considerations section. | | | | | | Added section about relationship to split tunnel | | | issues to the Security Considerations section. | | | | | | Editorial improvements based on last call comments. | +----------+--------------------------------------------------------+ Authors' Addresses Thomas R. Henderson (editor) University of Washington Campus Box 352500 Seattle, WA USA EMail: tomhend@u.washington.edu Christian Vogt Independent 3473 North First Street San Jose, CA 95134 USA EMail: mail@christianvogt.net Jari Arkko Ericsson JORVAS FIN-02420 FINLAND Phone: +358 40 5079256 EMail: jari.arkko@piuha.net Henderson, et al. Expires April 13, 2017 [Page 24] ./draft-ietf-6lo-privacy-considerations-04.txt0000664000764400076440000005373213005725633020571 0ustar iustyiusty Network Working Group D. Thaler Internet-Draft Microsoft Intended status: Informational October 31, 2016 Expires: May 4, 2017 Privacy Considerations for IPv6 Adaptation Layer Mechanisms draft-ietf-6lo-privacy-considerations-04 Abstract This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link layer protocols, and provides advice to protocol designers on how to address such threats in adaptation layer specifications for IPv6 over such links. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Thaler Expires May 4, 2017 [Page 1] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Amount of Entropy Needed in Global Addresses . . . . . . . . 3 3. Potential Approaches . . . . . . . . . . . . . . . . . . . . 4 3.1. IEEE-Identifier-Based Addresses . . . . . . . . . . . . . 5 3.2. Short Addresses . . . . . . . . . . . . . . . . . . . . . 5 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction RFC 6973 [RFC6973] discusses privacy considerations for Internet protocols, and Section 5.2 of that document covers a number of privacy-specific threats. In the context of IPv6 addresses, Section 3 of [RFC7721] provides further elaboration on the applicability of the privacy threats. When interface identifiers (IIDs) are generated without sufficient entropy compared to the link lifetime, devices and users can become vulnerable to the various threats discussed there, including: o Correlation of activities over time, if the same identifier is used for traffic over period of time o Location tracking, if the same interface identifier is used with different prefixes as a device moves between different networks o Device-specific vulnerability exploitation, if the identifier helps identify a vendor or version or protocol and hence suggests what types of attacks to try o Address scanning, which enables all of the above attacks by off- link attackers. (On some Non-Broadcast Multi-Access (NBMA) links where all nodes aren't already privy to all on-link addresses, address scans might also be done by on-link attackers, but in most cases address scans are not an interesting threat from on-link attackers and thus address scans generally apply only to routable addresses.) For example, for links that may last for years, "enough" bits of entropy means at least 46 or so bits (see Section 2 for why) in a routable address; ideally all 64 bits of the IID should be used, although historically some bits have been excluded for reasons discussed in [RFC7421]. Link-local addresses can also be susceptible Thaler Expires May 4, 2017 [Page 2] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 to the same privacy threats from off-link attackers, since experience shows they are often leaked by upper-layer protocols such as SMTP, SIP, or DNS. For these reasons, [I-D.ietf-6man-default-iids] recommends using an address generation scheme in [RFC7217], rather than addresses generated from a fixed link-layer address. Furthermore, to mitigate the threat of correlation of activities over time on long-lived links, [RFC4941] specifies the notion of a "temporary" address to be used for transport sessions (typically locally-initiated outbound traffic to the Internet) that should not be linkable to a more permanent identifier such as a DNS name, user name, or fixed link-layer address. Indeed, the default address selection rules [RFC6724] now prefer temporary addresses by default for outgoing connections. If a device needs to simultaneously support unlinkable traffic as well as traffic that is linkable to such a stable identifier, this necessitates supporting simultaneous use of multiple addresses per device. 2. Amount of Entropy Needed in Global Addresses In terms of privacy threats discussed in [RFC7721], the one with the need for the most entropy is address scans of routable addresses. To mitigate address scans, one needs enough entropy to make the probability of a successful address probe be negligible. Typically this is measured in the length of time it would take to have a 50% probability of getting at least one hit. Address scans often rely on sending a packet such as a TCP SYN or ICMP Echo Request, and determining whether the reply is an ICMP unreachable error (if no host exists with that address) or a TCP response or ICMP Echo Reply (if a host exists), or neither in which case nothing is known for certain. Many privacy-sensitive devices support a "stealth mode" as discussed in Section 5 of [RFC7288] or are behind a network firewall that will drop unsolicited inbound traffic (e.g., TCP SYNs, ICMP Echo Requests, etc.) and thus no TCP RST or ICMP Echo Reply will be sent. In such cases, and when the device does not listen on a well-known TCP or UDP port known to the scanner, the effectiveness of an address scan is limited by the ability to get ICMP unreachable errors, since the attacker can only infer the presence of a host based on the absense of an ICMP unreachable error. Generation of ICMP unreachable errors is typically rate limited to 2 per second (the default in routers such as Cisco routers running IOS 12.0 or later). Such a rate results in taking about a year to completely scan 26 bits of space. Thaler Expires May 4, 2017 [Page 3] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 The actual math is as follows. Let 2^N be the number of devices on the subnet. Let 2^M be the size of the space to scan (i.e., M bits of entropy). Let S be the number of scan attempts. The formula for a 50% chance of getting at least one hit in S attempts is: P(at least one success) = 1 - (1 - 2^N/2^M)^S = 1/2. Assuming 2^M >> S, this simplifies to: S * 2^N/2^M = 1/2, giving S = 2^(M-N-1), or M = N + 1 + log_2(S). Using a scan rate of 2 per second, this results in the following rule of thumb: Bits of entropy needed = log_2(# devices per link) + log_2(seconds of link lifetime) + 2 For example, for a network with at most 2^16 devices on the same long-lived link, and the average lifetime of a link being 8 years (2^28 seconds) or less, this results in a need for at least 46 bits of entropy (16+28+2) so that an address scan would need to be sustained for longer than the lifetime of the link to have a 50% chance of getting a hit. Although 46 bits of entropy may be enough to provide privacy in such cases, 59 or more bits of entropy would be needed if addresses are used to provide security against attacks such as spoofing, as CGAs [RFC3972] and HBAs [RFC5535] do, since attacks are not limited by ICMP rate limiting but by the processing power of the attacker. See those RFCs for more discussion. If, on the other hand, the devices being scanned for respond to unsolicited inbound packets, then the address scan is not limited by the ICMP unreachable rate limit in routers, since an adversary can determine the presence of a host without them. In such cases, more bits of entropy would be needed to provide the same level of protection. 3. Potential Approaches The table below shows the number of bits of entropy currently available in various technologies: +---------------+--------------------------+--------------------+ | Technology | Reference | Bits of Entropy | +---------------+--------------------------+--------------------+ | 802.15.4 | [RFC4944] | 16+ or any EUI-64 | | Bluetooth LE | [RFC7668] | 48 | | DECT ULE | [I-D.ietf-6lo-dect-ule] | 40 or any EUI-48 | | MS/TP | [I-D.ietf-6lo-6lobac] | 7 or 64 | | ITU-T G.9959 | [RFC7428] | 8 | | NFC | [I-D.ietf-6lo-nfc] | 5 | +---------------+--------------------------+--------------------+ Thaler Expires May 4, 2017 [Page 4] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 Such technologies generally support either IEEE identifiers or so called "Short Addresses", or both, as link layer addresses. We discuss each in turn. 3.1. IEEE-Identifier-Based Addresses Some technologies allow the use of IEEE EUI-48 or EUI-64 identifiers, or allow using an arbitrary 64-bit identifier. Using such an identifier to construct IPv6 addresses makes it easy to use the normal LOWPAN_IPHC encoding with stateless compression, allowing such IPv6 addresses to be fully elided in common cases. Global addresses with interface identifiers formed from IEEE identifiers can have insufficient entropy to mitigate address scans unless the IEEE identifier itself has sufficient entropy, and enough bits of entropy are carried over into the IPv6 address to sufficiently mitigate the threats. Privacy threats other than "Correlation over time" can be mitigated using per-network randomized link-layer addresses with enough entropy compared to the link lifetime. A number of such proposals can be found at , and Section 10.8 of [BTCorev4.1] specifies one for Bluetooth. Using routable IPv6 addresses derived from such link-layer addresses would be roughly equivalent to those specified in [RFC7217]. Correlation over time (for all addresses, not just routable addresses) can be mitigated if the link-layer address itself changes often enough, such as each time the link is established, if the link lifetime is short. For further discussion, see [I-D.huitema-6man-random-addresses]. Another potential concern is that of efficiency, such as avoiding Duplicate Address Detection (DAD) all together when IPv6 addresses are IEEE-identifier-based. Appendix A of [RFC4429] provides an analysis of address collision probability based on the number of bits of entropy. A simple web search on "duplicate MAC addresses" will show that collisions do happen with MAC addresses, and thus based on the analysis in [RFC4429], using sufficient bits of entropy in random addresses can provide greater protection against collision than using MAC addresses. 3.2. Short Addresses A routable IPv6 address with an interface identifier formed from the combination of a "Short Address" and a set of well-known constant bits (such as padding with 0's) lacks sufficient entropy to mitigate address scanning unless the link lifetime is extremely short. Furthermore, an adversary could also use statistical methods to Thaler Expires May 4, 2017 [Page 5] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 determine the size of the L2 address space and thereby make some inference regarding the underlying technology on a given link, and target further attacks accordingly. When Short Addresses are desired on links that are not guaranteed to have a short enough lifetime, the mechanism for constructing an IPv6 interface identifier from a Short Address could be designed to sufficiently mitigate the problem. For example, if all nodes on a given L2 network have a shared secret (such as the key needed to get on the layer-2 network), the 64-bit IID might be generated using a one-way hash that includes (at least) the shared secret together with the Short Address. The use of such a hash would result in the IIDs being spread out among the full range of IID address space, thus mitigating address scans, while still allowing full stateless compression/elision. For long-lived links, "temporary" addresses might even be generated in the same way by (for example) also including in the hash the Version Number from the Authoritative Border Router Option (Section 4.3 of [RFC6775]), if any. This would allow changing temporary addresses whenever the Version Number is changed, even if the set of prefix or context information is unchanged. In summary, any specification using Short Addresses should carefully construct an IID generation mechanism so as to provide sufficient entropy compared to the link lifetime. 4. Recommendations The following are recommended for adaptation layer specifications: o Security (privacy) sections should say how address scans are mitigated. An address scan might be mitigated by having a link always be short-lived, or might be mitigated by having a large number of bits of entropy in routable addresses, or some combination. Thus, a specification should explain what the maximum lifetime of a link is in practice, and show how the number of bits of entropy is sufficient given that lifetime. o Technologies should define a way to include sufficient bits of entropy in the IPv6 interface identifier, based on the maximum link lifetime. Specifying that randomized link-layer addresses can be used is one easy way to do so, for technologies that support such identifiers. o Specifications should not simply construct an IPv6 interface identifier by padding a short address with a set of other well- known constant bits, unless the link lifetime is guaranteed to be Thaler Expires May 4, 2017 [Page 6] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 extremely short or the short address is allocated by the network (rather than being constant in the node). This also applies to link-local addresses if the same short address is used independent of network and is unique enough to allow location tracking. o Specifications should make sure that an IPv6 address can change over long periods of time. For example, the interface identifier might change each time a device connects to the network (if connections are short), or might change each day (if connections can be long). This is necessary to mitigate correlation over time. o If a device can roam between networks, and more than a few bits of entropy exist in the IPv6 interface identifier, then make sure that the interface identifier can vary per network as the device roams. This is necessary to mitigate location tracking. 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations This entire document is about security considerations and how to specify possible mitigations. 7. Informative References [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . Thaler Expires May 4, 2017 [Page 7] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI 10.17487/RFC5535, June 2009, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI 10.17487/RFC7288, June 2014, . [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, . [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, . [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, . Thaler Expires May 4, 2017 [Page 8] Internet-Draft IPv6-over-foo Privacy Considerations October 2016 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and S. LIU, "Recommendation on Stable IPv6 Interface Identifiers", draft-ietf-6man-default-iids-16 (work in progress), September 2016. [I-D.ietf-6lo-6lobac] Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over MS/TP Networks", draft-ietf- 6lo-6lobac-05 (work in progress), June 2016. [I-D.ietf-6lo-dect-ule] Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. Barthel, "Transmission of IPv6 Packets over DECT Ultra Low Energy", draft-ietf-6lo-dect-ule-07 (work in progress), October 2016. [I-D.ietf-6lo-nfc] Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 Packets over Near Field Communication", draft-ietf-6lo- nfc-05 (work in progress), October 2016. [I-D.huitema-6man-random-addresses] Huitema, C., "Implications of Randomized Link Layers Addresses for IPv6 Address Assignment", draft-huitema- 6man-random-addresses-03 (work in progress), March 2016. [BTCorev4.1] Bluetooth Special Interest Group, "Bluetooth Core Specification Version 4.1", December 2013, . Author's Address Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA Email: dthaler@microsoft.com Thaler Expires May 4, 2017 [Page 9] ./draft-ietf-l3sm-l3vpn-service-model-19.txt0000664000764400076440000104262413010133714020040 0ustar iustyiusty L3SM Working Group S. Litkowski Internet-Draft Orange Business Services Intended status: Standards Track L. Tomotaki Expires: May 8, 2017 Verizon K. Ogaki KDDI November 04, 2016 YANG Data Model for L3VPN service delivery draft-ietf-l3sm-l3vpn-service-model-19 Abstract This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 Provider Provisioned VPN service. The document is limited to the BGP PE-based VPNs as described in [RFC4026], [RFC4110] and [RFC4364]. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IPVPN service configuration components. It will be up to a management system to take this as an input and use specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Litkowski, et al. Expires May 8, 2017 [Page 1] Internet-Draft l3vpn-svc-cfg November 2016 This Internet-Draft will expire on May 8, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Layer 3 IP VPN service model . . . . . . . . . . . . . . . . 7 5. Service data model usage . . . . . . . . . . . . . . . . . . 8 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 9 6.1. Features and augmentation . . . . . . . . . . . . . . . . 16 6.2. VPN service overview . . . . . . . . . . . . . . . . . . 17 6.2.1. VPN service topology . . . . . . . . . . . . . . . . 17 6.2.1.1. Route Target allocation . . . . . . . . . . . . . 17 6.2.1.2. Any to any . . . . . . . . . . . . . . . . . . . 18 6.2.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 18 6.2.1.4. Hub and Spoke disjoint . . . . . . . . . . . . . 19 6.2.2. Cloud access . . . . . . . . . . . . . . . . . . . . 20 6.2.3. Multicast service . . . . . . . . . . . . . . . . . . 22 6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 24 6.3. Site overview . . . . . . . . . . . . . . . . . . . . . . 25 6.3.1. Devices and locations . . . . . . . . . . . . . . . . 26 6.3.2. Site network accesses . . . . . . . . . . . . . . . . 27 6.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 28 6.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 28 6.3.2.3. Inheritance of parameters between site and site- network-access . . . . . . . . . . . . . . . . . 29 6.4. Site role . . . . . . . . . . . . . . . . . . . . . . . . 30 6.5. Site belonging to multiple VPNs . . . . . . . . . . . . . 30 6.5.1. Site vpn flavor . . . . . . . . . . . . . . . . . . . 30 6.5.1.1. Single VPN attachment : site-vpn-flavor-single . 30 Litkowski, et al. Expires May 8, 2017 [Page 2] Internet-Draft l3vpn-svc-cfg November 2016 6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi . . 31 6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub . . . . 31 6.5.1.4. NNI : site-vpn-flavor-nni . . . . . . . . . . . . 33 6.5.2. Attaching a site to a VPN . . . . . . . . . . . . . . 34 6.5.2.1. Reference a VPN . . . . . . . . . . . . . . . . . 35 6.5.2.2. VPN policy . . . . . . . . . . . . . . . . . . . 35 6.6. Deciding where to connect the site . . . . . . . . . . . 38 6.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 39 6.6.2. Constraint/parameter: Site location . . . . . . . . . 39 6.6.3. Constraint/parameter: access type . . . . . . . . . . 41 6.6.4. Constraint: access diversity . . . . . . . . . . . . 41 6.6.5. Impossible access placement . . . . . . . . . . . . . 47 6.6.6. Examples of access placement . . . . . . . . . . . . 48 6.6.6.1. Multihoming . . . . . . . . . . . . . . . . . . . 48 6.6.6.2. Site offload . . . . . . . . . . . . . . . . . . 50 6.6.6.3. Parallel links . . . . . . . . . . . . . . . . . 56 6.6.6.4. SubVPN with multihoming . . . . . . . . . . . . . 57 6.6.7. Route Distinguisher and VRF allocation . . . . . . . 61 6.7. Site network access availability . . . . . . . . . . . . 62 6.8. Traffic protection . . . . . . . . . . . . . . . . . . . 63 6.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 64 6.9.1. Authentication . . . . . . . . . . . . . . . . . . . 64 6.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 64 6.10. Management . . . . . . . . . . . . . . . . . . . . . . . 65 6.11. Routing protocols . . . . . . . . . . . . . . . . . . . . 66 6.11.1. Dual stack handling . . . . . . . . . . . . . . . . 66 6.11.2. Direct LAN connection onto SP network . . . . . . . 67 6.11.3. Direct LAN connection onto SP network with redundancy . . . . . . . . . . . . . . . . . . . . . 67 6.11.4. Static routing . . . . . . . . . . . . . . . . . . . 68 6.11.5. RIP routing . . . . . . . . . . . . . . . . . . . . 68 6.11.6. OSPF routing . . . . . . . . . . . . . . . . . . . . 68 6.11.7. BGP routing . . . . . . . . . . . . . . . . . . . . 70 6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 71 6.12.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 72 6.12.2.1. QoS classification . . . . . . . . . . . . . . . 72 6.12.2.2. QoS profile . . . . . . . . . . . . . . . . . . 75 6.12.3. Multicast . . . . . . . . . . . . . . . . . . . . . 79 6.13. Enhanced VPN features . . . . . . . . . . . . . . . . . . 79 6.13.1. Carrier's Carrier . . . . . . . . . . . . . . . . . 79 6.14. External ID references . . . . . . . . . . . . . . . . . 81 6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 81 6.15.1. Defining NNI with option A flavor . . . . . . . . . 83 6.15.2. Defining NNI with option B flavor . . . . . . . . . 86 6.15.3. Defining NNI with option C flavor . . . . . . . . . 88 7. Service model usage example . . . . . . . . . . . . . . . . . 90 8. Interaction with Other YANG Modules . . . . . . . . . . . . . 95 Litkowski, et al. Expires May 8, 2017 [Page 3] Internet-Draft l3vpn-svc-cfg November 2016 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 153 11. Contribution . . . . . . . . . . . . . . . . . . . . . . . . 154 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 154 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 154 14.1. Changes between versions -18 and-19 . . . . . . . . . . 154 14.2. Changes between versions -17 and-18 . . . . . . . . . . 155 14.3. Changes between versions -16 and-17 . . . . . . . . . . 155 14.4. Changes between versions -15 and-16 . . . . . . . . . . 156 14.5. Changes between versions -13 and-14 . . . . . . . . . . 156 14.6. Changes between versions -12 and-13 . . . . . . . . . . 156 14.7. Changes between versions -11 and-12 . . . . . . . . . . 156 14.8. Changes between versions -09 and-10 . . . . . . . . . . 156 14.9. Changes between versions -08 and-09 . . . . . . . . . . 157 14.10. Changes between versions -07 and-08 . . . . . . . . . . 157 14.11. Changes between versions -06 and-07 . . . . . . . . . . 157 14.12. Changes between versions -05 and-06 . . . . . . . . . . 157 14.13. Changes between versions -04 and-05 . . . . . . . . . . 158 14.14. Changes between versions -02 and-03 . . . . . . . . . . 158 14.15. Changes between versions -01 and-02 . . . . . . . . . . 158 14.16. Changes between versions -00 and-01 . . . . . . . . . . 159 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 159 15.1. Normative References . . . . . . . . . . . . . . . . . . 159 15.2. Informative References . . . . . . . . . . . . . . . . . 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161 1. Introduction This document defines a Layer 3 VPN service data model written in YANG. The model defines service configuration elements that can be used in communication protocols between customers and network operators. Those elements can be used also as input to automated control and configuration applications. 1.1. Terminology The following terms are defined in [RFC6241] and are not redefined here: o client o configuration data o server o state data Litkowski, et al. Expires May 8, 2017 [Page 4] Internet-Draft l3vpn-svc-cfg November 2016 The following terms are defined in [RFC7950] and are not redefined here: o augment o data model o data node The terminology for describing YANG data models is found in [RFC7950]. This document presents some configuration examples using XML representation. 1.2. Tree diagram A simplified graphical representation of the data model is presented in Section 6. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. Acronyms AAA: Authentication, Authorization, Accounting. ACL: Access Control List. ASM: Any-Source Multicast. BFD: Bidirectional Forwarding Detection. Litkowski, et al. Expires May 8, 2017 [Page 5] Internet-Draft l3vpn-svc-cfg November 2016 BGP: Border Gateway Protocol. CE: Customer Edge. CLI: Command Line Interface. CsC: Carrier's Carrier. CSP: Cloud Service Provider. DHCP: Dynamic Host Configuration Protocol. IGMP: Internet Group Management Protocol. LAN: Local Area Network. MLD: Multicast Listener Discovery. MTU: Maximum Transmission Unit. NAT: Network Address Translation. NNI: Network to Network Interface. OAM: Operation Administration and Management. OSPF: Open Shortest Path First. OSS: Operations Support System. PE: Provider Edge. POP: Point Of Presence. PIM: Protocol Independent Multicast. QoS: Quality Of Service. RIP: Routing Information Protocol. RD: Route Distinguisher. RP: Rendez-vous Point. RT: Route Target. SLA: Service Level Agreement. Litkowski, et al. Expires May 8, 2017 [Page 6] Internet-Draft l3vpn-svc-cfg November 2016 SLAAC: Stateless Address AutoConfiguration. SP: Service Provider. SSM: Source-Specific Multicast. VPN: Virtual Private Network. VRF: VPN Routing and Forwarding. VRRP: Virtual Router Redundancy Protocol. 3. Definitions Customer Edge (CE) Device: Equipment that is dedicated to a particular customer and is directly connected (at layer 3) to one or more PE devices via attachment circuits. A CE is usually located at the customer premises, and is usually dedicated to a single VPN, although it may support multiple VPNs if each one has separate attachment circuits. Provider Edge (PE) Device: Equipment managed by the Service Provider (SP) that can support multiple VPNs for different customers, and is directly connected (at layer 3) to one or more CE devices via attachment circuits. A PE is usually located at an SP point of presence (PoP) and is managed by the SP. PE-Based VPNs: The PE devices know that certain traffic is VPN traffic. They forward the traffic (through tunnels) based on the destination IP address of the packet, and optionally on based on other information in the IP header of the packet. The PE devices are themselves the tunnel endpoints. The tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels). 4. Layer 3 IP VPN service model A layer 3 IPVPN service is a collection of sites that are authorized to exchange traffic between each other over a shared IP infrastructure. This layer 3 VPN service model aims at providing a common understanding on how the corresponding IP VPN service is to be deployed over the shared infrastructure. This service model is limited to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364]. Litkowski, et al. Expires May 8, 2017 [Page 7] Internet-Draft l3vpn-svc-cfg November 2016 5. Service data model usage L3VPN-SVC | MODEL | | +------------------+ +-----+ | Orchestration | < --- > | OSS | +------------------+ +-----+ | | +----------------+ | | Config manager | | +----------------+ | | | | Netconf/CLI ... | | +------------------------------------------------+ Network +++++++ + AAA + +++++++ ++++++++ Bearer ++++++++ ++++++++ ++++++++ + CE A + ------- + PE A + + PE B + ---- + CE B + ++++++++ Cnct ++++++++ ++++++++ ++++++++ Site A Site B The idea of the L3 IPVPN service model is to propose an abstracted interface between customers and network operators to manage configuration of components of a L3VPN service. A typical usage is to use this model as an input for an orchestration layer who will be responsible to translate it to orchestrated configuration of network elements who will be part of the service. The network elements can be routers, but also servers (like AAA), and not limited to these examples. The configuration of network elements can be done by the CLI, or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf]) coupled with specific configuration YANG data models (BGP, VRF, BFD ...) or any other way. The usage of this service model is not limited to this example, it can be used by any component of the management system but not directly by network elements. Litkowski, et al. Expires May 8, 2017 [Page 8] Internet-Draft l3vpn-svc-cfg November 2016 6. Design of the Data Model The YANG module is divided in two main containers : vpn-services, sites. The vpn-service under vpn-services defines global parameters for the VPN service for a specific customer. A site is composed of at least one site-network-access and may have multiple site-network-access in case of multihoming. The site- network-access attachment is done through a bearer with an IP connection on top. The bearer refers to properties of the attachment that are below layer 3 while the connection refers to layer 3 protocol oriented properties. The bearer may be allocated dynamically by the service provider and the customer may provide some constraints or parameters to drive the placement. Authorization of traffic exchange is done through what we call a VPN policy or VPN service topology defining routing exchange rules between sites. The figure below describe the overall structure of the YANG module: module: ietf-l3vpn-svc +--rw l3vpn-svc +--rw vpn-services | +--rw vpn-service* [vpn-id] | +--rw vpn-id svc-id | +--rw customer-name? string | +--rw vpn-service-topology? identityref | +--rw cloud-accesses {cloud-access}? | | +--rw cloud-access* [cloud-identifier] | | +--rw cloud-identifier string | | +--rw (list-flavor)? | | | +--:(permit-any) | | | | +--rw permit-any? empty | | | +--:(deny-any-except) | | | | +--rw permit-site* leafref | | | +--:(permit-any-except) | | | +--rw deny-site* leafref | | +--rw authorized-sites | | | +--rw authorized-site* [site-id] | | | +--rw site-id leafref | | +--rw denied-sites | | | +--rw denied-site* [site-id] | | | +--rw site-id leafref | | +--rw address-translation | | +--rw nat44 Litkowski, et al. Expires May 8, 2017 [Page 9] Internet-Draft l3vpn-svc-cfg November 2016 | | +--rw enabled? boolean | | +--rw nat44-customer-address? inet:ipv4-address | +--rw multicast {multicast}? | | +--rw enabled? boolean | | +--rw customer-tree-flavors | | | +--rw tree-flavor* identityref | | +--rw rp | | +--rw rp-group-mappings | | | +--rw rp-group-mapping* [id] | | | +--rw id uint16 | | | +--rw provider-managed | | | | +--rw enabled? boolean | | | | +--rw rp-redundancy? boolean | | | | +--rw optimal-traffic-delivery? boolean | | | +--rw rp-address? inet:ip-address | | | +--rw groups | | | +--rw group* [id] | | | +--rw id uint16 | | | +--rw (group-format)? | | | +--:(startend) | | | | +--rw group-start? inet:ip-address | | | | +--rw group-end? inet:ip-address | | | +--:(singleaddress) | | | +--rw group-address? inet:ip-address | | +--rw rp-discovery | | +--rw rp-discovery-type? identityref | | +--rw bsr-candidates | | +--rw bsr-candidate-address* inet:ip-address | +--rw carrierscarrier? boolean {carrierscarrier}? | +--rw extranet-vpns {extranet-vpn}? | +--rw extranet-vpn* [vpn-id] | +--rw vpn-id svc-id | +--rw local-sites-role? identityref +--rw sites +--rw site* [site-id] +--rw site-id svc-id +--rw requested-site-start? yang:date-and-time +--rw requested-site-stop? yang:date-and-time +--rw locations | +--rw location* [location-id] | +--rw location-id svc-id | +--rw address? string | +--rw postal-code? string | +--rw state? string | +--rw city? string | +--rw country-code? string +--rw devices | +--rw device* [device-id] Litkowski, et al. Expires May 8, 2017 [Page 10] Internet-Draft l3vpn-svc-cfg November 2016 | +--rw device-id svc-id | +--rw location? leafref | +--rw management | +--rw address-family? address-family | +--rw address? inet:ip-address +--rw site-diversity {site-diversity}? | +--rw groups | +--rw group* [group-id] | +--rw group-id string +--rw management | +--rw type? identityref +--rw vpn-policies | +--rw vpn-policy* [vpn-policy-id] | +--rw vpn-policy-id svc-id | +--rw entries* [id] | +--rw id svc-id | +--rw filter | | +--rw (lan)? | | +--:(prefixes) | | | +--rw ipv4-lan-prefix* inet:ipv4-prefix {ipv4}? | | | +--rw ipv6-lan-prefix* inet:ipv6-prefix {ipv6}? | | +--:(lan-tag) | | +--rw lan-tag* string | +--rw vpn | +--rw vpn-id leafref | +--rw site-role? identityref +--rw site-vpn-flavor? identityref +--rw maximum-routes | +--rw address-family* [af] | +--rw af address-family | +--rw maximum-routes? uint32 +--rw security | +--rw authentication | +--rw encryption {encryption}? | +--rw enabled? boolean | +--rw layer enumeration | +--rw encryption-profile | +--rw (profile)? | +--:(provider-profile) | | +--rw profile-name? string | +--:(customer-profile) | +--rw algorithm? string | +--rw (key-type)? | +--:(psk) | | +--rw preshared-key? string | +--:(pki) +--rw service | +--rw qos {qos}? Litkowski, et al. Expires May 8, 2017 [Page 11] Internet-Draft l3vpn-svc-cfg November 2016 | | +--rw qos-classification-policy | | | +--rw rule* [id] | | | +--rw id uint16 | | | +--rw (match-type)? | | | | +--:(match-flow) | | | | | +--rw match-flow | | | | | +--rw dscp? inet:dscp | | | | | +--rw dot1p? uint8 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix | | | | | +--rw l4-src-port? inet:port-number | | | | | +--rw target-sites* svc-id | | | | | +--rw l4-src-port-range | | | | | | +--rw lower-port? inet:port-number | | | | | | +--rw upper-port? inet:port-number | | | | | +--rw l4-dst-port? inet:port-number | | | | | +--rw l4-dst-port-range | | | | | | +--rw lower-port? inet:port-number | | | | | | +--rw upper-port? inet:port-number | | | | | +--rw protocol-field? union | | | | +--:(match-application) | | | | +--rw match-application? identityref | | | +--rw target-class-id? string | | +--rw qos-profile | | +--rw (qos-profile)? | | +--:(standard) | | | +--rw profile? string | | +--:(custom) | | +--rw classes {qos-custom}? | | +--rw class* [class-id] | | +--rw class-id string | | +--rw rate-limit? uint8 | | +--rw latency | | | +--rw (flavor)? | | | ... | | +--rw jitter | | | +--rw (flavor)? | | | ... | | +--rw bandwidth | | +--rw guaranteed-bw-percent? uint8 | | +--rw end-to-end? empty | +--rw carrierscarrier {carrierscarrier}? | | +--rw signalling-type? enumeration | +--rw multicast {multicast}? | +--rw multicast-site-type? enumeration | +--rw multicast-address-family Litkowski, et al. Expires May 8, 2017 [Page 12] Internet-Draft l3vpn-svc-cfg November 2016 | | +--rw ipv4? boolean {ipv4}? | | +--rw ipv6? boolean {ipv6}? | +--rw protocol-type? enumeration +--rw traffic-protection {fast-reroute}? | +--rw enabled? boolean +--rw routing-protocols | +--rw routing-protocol* [type] | +--rw type identityref | +--rw ospf {rtg-ospf}? | | +--rw address-family* address-family | | +--rw area-address? yang:dotted-quad | | +--rw metric? uint16 | | +--rw sham-links {rtg-ospf-sham-link}? | | +--rw sham-link* [target-site] | | +--rw target-site svc-id | | +--rw metric? uint16 | +--rw bgp {rtg-bgp}? | | +--rw autonomous-system? uint32 | | +--rw address-family* address-family | +--rw static | | +--rw cascaded-lan-prefixes | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}? | | | +--rw lan inet:ipv4-prefix | | | +--rw lan-tag? string | | | +--rw next-hop inet:ipv4-address | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}? | | +--rw lan inet:ipv6-prefix | | +--rw lan-tag? string | | +--rw next-hop inet:ipv6-address | +--rw rip {rtg-rip}? | | +--rw address-family* address-family | +--rw vrrp {rtg-vrrp}? | +--rw address-family* address-family +--ro actual-site-start? yang:date-and-time +--ro actual-site-stop? yang:date-and-time +--rw site-network-accesses +--rw site-network-access* [site-network-access-id] +--rw site-network-access-id svc-id +--rw site-network-access-type? identityref +--rw (location-flavor) | +--:(location) | | +--rw location-reference? leafref | +--:(device) | +--rw device-reference? leafref +--rw access-diversity {site-diversity}? | +--rw groups | | +--rw group* [group-id] | | +--rw group-id string Litkowski, et al. Expires May 8, 2017 [Page 13] Internet-Draft l3vpn-svc-cfg November 2016 | +--rw constraints | +--rw constraint* [constraint-type] | +--rw constraint-type identityref | +--rw target | +--rw (target-flavor)? | +--:(id) | | +--rw group* [group-id] | | ... | +--:(all-accesses) | | +--rw all-other-accesses? empty | +--:(all-groups) | +--rw all-other-groups? empty +--rw bearer | +--rw requested-type {requested-type}? | | +--rw requested-type? string | | +--rw strict? boolean | +--rw always-on? boolean {always-on}? | +--rw bearer-reference? string {bearer-reference}? +--rw ip-connection | +--rw ipv4 {ipv4}? | | +--rw address-allocation-type? identityref | | +--rw number-of-dynamic-address? uint8 | | +--rw dhcp-relay | | | +--rw customer-dhcp-servers | | | +--rw server-ip-address* inet:ipv4-address | | +--rw addresses | | +--rw provider-address? inet:ipv4-address | | +--rw customer-address? inet:ipv4-address | | +--rw mask? uint8 | +--rw ipv6 {ipv6}? | | +--rw address-allocation-type? identityref | | +--rw number-of-dynamic-address? uint8 | | +--rw dhcp-relay | | | +--rw customer-dhcp-servers | | | +--rw server-ip-address* inet:ipv6-address | | +--rw addresses | | +--rw provider-address? inet:ipv6-address | | +--rw customer-address? inet:ipv6-address | | +--rw mask? uint8 | +--rw oam | +--rw bfd {bfd}? | +--rw enabled? boolean | +--rw (holdtime)? | +--:(profile) | | +--rw profile-name? string | +--:(fixed) | +--rw fixed-value? uint32 +--rw security Litkowski, et al. Expires May 8, 2017 [Page 14] Internet-Draft l3vpn-svc-cfg November 2016 | +--rw authentication | +--rw encryption {encryption}? | +--rw enabled? boolean | +--rw layer enumeration | +--rw encryption-profile | +--rw (profile)? | +--:(provider-profile) | | +--rw profile-name? string | +--:(customer-profile) | +--rw algorithm? string | +--rw (key-type)? | +--:(psk) | | ... | +--:(pki) +--rw service | +--rw svc-input-bandwidth? uint32 | +--rw svc-output-bandwidth? uint32 | +--rw svc-mtu? uint16 | +--rw qos {qos}? | | +--rw qos-classification-policy | | | +--rw rule* [id] | | | +--rw id uint16 | | | +--rw (match-type)? | | | | +--:(match-flow) | | | | | +--rw match-flow | | | | | ... | | | | +--:(match-application) | | | | +--rw match-application? identityref | | | +--rw target-class-id? string | | +--rw qos-profile | | +--rw (qos-profile)? | | +--:(standard) | | | +--rw profile? string | | +--:(custom) | | +--rw classes {qos-custom}? | | +--rw class* [class-id] | | ... | +--rw carrierscarrier {carrierscarrier}? | | +--rw signalling-type? enumeration | +--rw multicast {multicast}? | +--rw multicast-site-type? enumeration | +--rw multicast-address-family | | +--rw ipv4? boolean {ipv4}? | | +--rw ipv6? boolean {ipv6}? | +--rw protocol-type? enumeration +--rw routing-protocols | +--rw routing-protocol* [type] | +--rw type identityref Litkowski, et al. Expires May 8, 2017 [Page 15] Internet-Draft l3vpn-svc-cfg November 2016 | +--rw ospf {rtg-ospf}? | | +--rw address-family* address-family | | +--rw area-address? yang:dotted-quad | | +--rw metric? uint16 | | +--rw sham-links {rtg-ospf-sham-link}? | | +--rw sham-link* [target-site] | | +--rw target-site svc-id | | +--rw metric? uint16 | +--rw bgp {rtg-bgp}? | | +--rw autonomous-system? uint32 | | +--rw address-family* address-family | +--rw static | | +--rw cascaded-lan-prefixes | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}? | | | +--rw lan inet:ipv4-prefix | | | +--rw lan-tag? string | | | +--rw next-hop inet:ipv4-address | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}? | | +--rw lan inet:ipv6-prefix | | +--rw lan-tag? string | | +--rw next-hop inet:ipv6-address | +--rw rip {rtg-rip}? | | +--rw address-family* address-family | +--rw vrrp {rtg-vrrp}? | +--rw address-family* address-family +--rw availability | +--rw access-priority? uint32 +--rw vpn-attachment +--rw (attachment-flavor) +--:(vpn-policy-id) | +--rw vpn-policy-id? leafref +--:(vpn-id) +--rw vpn-id? leafref +--rw site-role? identityref 6.1. Features and augmentation The model implements a lot of features allowing implementations to be modular. As example, an implementation may support only IPv4 VPNs (ipv4 feature), IPv6 (ipv6 feature), or both (by advertising both features). The routing protocols proposed to the customer may also be enabled through features. This model proposes also some features for more advanced options like : extranet-vpn support (Section 6.2.4), site diversity (Section 6.6), qos (Section 6.12.2), ... In addition, as for any YANG model, this service model can be augmented to implement new behaviors or specific features. For Litkowski, et al. Expires May 8, 2017 [Page 16] Internet-Draft l3vpn-svc-cfg November 2016 example, this model proposes different options for the IP address assignment, if those options are not filling all requirements, new options can be added through augmentation. 6.2. VPN service overview A vpn-service list item contains generic informations about the VPN service. The vpn-id of the vpn-service refers to an internal reference for this VPN service, while customer name refers to a more explicit reference to the customer. This identifier is purely internal to the organization responsible for the VPN service. 6.2.1. VPN service topology The type of VPN service topology is required for configuration. Current proposal supports: any-to-any, hub and spoke (where hubs can exchange traffic), and hub and spoke disjoint (where hubs cannot exchange traffic). New topologies could be added by augmentation. By default, any-to-any VPN service topology is used. 6.2.1.1. Route Target allocation Layer 3 PE-based VPN is built using route-targets as described in [RFC4364]. It is expected the management system to allocate automatically a set of route-targets upon a VPN service creation request. How the management system allocates route-targets is out of scope of the document but multiple ways could be envisaged as described below. Management system <-------------------------------------------------> Request RT +-----------------------+ Topo a2a +----------+ RESTCONF | | -----> | | User ------------- | Service Orchestration | |NetworkOSS| l3vpn-svc | | <----- | | model +-----------------------+ Response +----------+ RT1,RT2 In the example above, a service orchestration, owning the instantiation of this service model, request route-targets to the network OSS. Based on the requested VPN service topology, the network OSS replies with one or multiple route-targets. The interface between this service orchestration and network OSS is out of scope of this document. Litkowski, et al. Expires May 8, 2017 [Page 17] Internet-Draft l3vpn-svc-cfg November 2016 +---------------------------+ RESTCONF | | User ------------- | Service Orchestration | l3vpn-svc | | model | | | RT pool : 10:1->10:10000 | | RT pool : 20:50->20:5000 | +---------------------------+ In the example above, a service orchestration, owning the instantiation of this service model, owns one or more pools of route- target (specified by service provider) that can be allocated. Based on the requested VPN service topology, it will allocate one or multiple route-targets from the pool. The mechanism displayed above are just examples and should not be considered as an exhaustive list of solutions. 6.2.1.2. Any to any +------------------------------------------------------------+ | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 | | | | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 | +------------------------------------------------------------+ Figure - Any-to-any VPN service topology In the any-to-any VPN service topology, all VPN sites can communicate between each other without any restriction. It is expected that the management system that receives an any-to-any IPVPN service request through this model needs to assign and then configure the VRF and route-targets on the appropriate PEs. In the any-to-any case, in general a single route-target is required and every VRF imports and exports this route-target. 6.2.1.3. Hub and Spoke +-------------------------------------------------------------+ | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | | +----------------------------------+ | | | +----------------------------------+ | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | +-------------------------------------------------------------+ Figure - Hub and Spoke VPN service topology Litkowski, et al. Expires May 8, 2017 [Page 18] Internet-Draft l3vpn-svc-cfg November 2016 In the hub and spoke VPN service topology, all spoke sites can communicate only with Hub sites but not between each other, and hubs can also communicate between each other. It is expected that the management system that owns an any to any IPVPN service request through this model, needs to assign and then configure the VRF and route-targets on the appropriate PEs. In the hub and spoke case, in general a two route-targets are required (one route-target for Hub routes, one route-target for spoke routes). A Hub VRF, connecting Hub sites, will export Hub routes with Hub route-target, and will import Spoke routes through Spoke route-target. It will also import the Hub route-target to allow Hub to Hub communication. A Spoke VRF, connecting Spoke sites, will export Spoke routes with Spoke route- target, and will import Hub routes through Hub route-target. The management system MUST take into account Hub and Spoke connections constraints. For example, if a management system decides to mesh a spoke site and a hub site on the same PE, it needs to mesh connections in different VRFs as displayed in the figure below. Hub_Site ------- (VRF_Hub) PE1 (VRF_Spoke) / | Spoke_Site1 -------------------+ | | Spoke_Site2 -----------------------+ 6.2.1.4. Hub and Spoke disjoint +-------------------------------------------------------------+ | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | +--------------------------+ +-------------------------------+ | | +--------------------------+ +-------------------------------+ | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | +-------------------------------------------------------------+ Figure - Hub and Spoke disjoint VPN service topology In the Hub and Spoke disjoint VPN service topology, all Spoke sites can communicate only with Hub sites but not between each other and Hubs cannot communicate between each other. It is expected that the management system that owns an any to any IPVPN service request through this model, needs to assign and then configure the VRF and route-targets on the appropriate PEs. In the Hub and Spoke case, two route-targets are required (one route-target for Hub routes, one route-target for Spoke routes). A Hub VRF, connecting Hub sites, will export Hub routes with Hub route-target, and will import Spoke Litkowski, et al. Expires May 8, 2017 [Page 19] Internet-Draft l3vpn-svc-cfg November 2016 routes through Spoke route-target. A Spoke VRF, connecting Spoke sites, will export Spoke routes with Spoke route-target, and will import Hub routes through Hub route-target. The management system MUST take into account Hub and Spoke connections constraints as in the previous case. Hub and Spoke disjoint can also be seen as multiple Hub and Spoke VPNs (one per Hub) sharing with a common set of Spoke sites. 6.2.2. Cloud access The proposed model provides a cloud access configuration through the cloud-access container. The usage of cloud-access is targeted for public cloud. An Internet access can also be considered as a public cloud access service. The cloud-access container provides parameters for network address translations and authorization rules. A private cloud access may be addressed through NNIs as described in Section 6.15. A cloud identifier is used to reference the target service. This identifier is local to each administration. The model allows for source address translation before accessing the cloud. IPv4 to IPv4 address translation (nat44) is the only supported option but other options can be added through augmentation. If IP source address translation is required to access the cloud, the enabled leaf MUST be set to true in the "nat44" container. An IP address may be provided in the customer-address leaf, in case the customer is providing the IP address to be used for the cloud access. If the service provider is providing this address, the customer- address is not necessary as it can be picked from a service provider pool. By default, all sites in the IPVPN MUST be authorized to access to the cloud. In case restrictions are required, a user MAY configure the permit-site or deny-site leaf-list. The "permit-site" defines the list of sites authorized for cloud access. The "deny-site" defines the list of sites denied for cloud access. The model supports both "deny any except" and "permit any except" authorization. How the restrictions will be configured on network elements is out of scope of this document. Litkowski, et al. Expires May 8, 2017 [Page 20] Internet-Draft l3vpn-svc-cfg November 2016 IPVPN ++++++++++++++++++++++++++++++++ +++++++++++ + Site 3 + --- + Cloud1 + + Site 1 + +++++++++++ + + + Site 2 + --- ++++++++++++ + + + Internet + + Site 4 + ++++++++++++ ++++++++++++++++++++++++++++++++ | ++++++++++ + Cloud2 + ++++++++++ In the example above, we may configure the global VPN to access Internet by creating a cloud-access pointing to the cloud identifier for the Internet service. No authorized-sites will be configured as all sites are required to access the Internet. The "address- translation/nat44/enabled" leaf will be set to true. 123456487 INTERNET true If Site1 and Site2 requires access to Cloud1, a new cloud-access will be created pointing to the cloud identifier of Cloud1. The "permit- site" leaf-list will be filled with a reference to Site1 and Site2. Litkowski, et al. Expires May 8, 2017 [Page 21] Internet-Draft l3vpn-svc-cfg November 2016 123456487 Cloud1 site1 site2 If all sites except Site1 requires access to Cloud2, a new cloud- access will be created pointing to the cloud identifier of Cloud2. The "deny-site" leaf-list will be filled with a reference to Site1. 123456487 Cloud2 site1 6.2.3. Multicast service Multicast in IP VPN is described in [RFC6513]. If multicast support is required for an IPVPN, some global multicast parameters are required as input of the service request. The user of this model will need to fill the flavor of trees that will be used by customer within the IPVPN (Customer tree). The proposed model supports bidirectional, shared and source-based trees (and can be augmented). Multiple flavors of tree can be supported simultaneously. Litkowski, et al. Expires May 8, 2017 [Page 22] Internet-Draft l3vpn-svc-cfg November 2016 Operator network ______________ / \ | | (SSM tree) | Recv (IGMPv3) -- Site2 ------- PE2 | | PE1 --- Site1 --- Source1 | | \ | | -- Source2 | | (ASM tree) | Recv (IGMPv2) -- Site3 ------- PE3 | | | (SSM tree) | Recv (IGMPv3) -- Site4 ------- PE4 | | / | Recv (IGMPv2) -- Site5 -------- | (ASM tree) | | | \_______________/ In case of an ASM flavor requested, this model requires to fill the rp and rp-discovery parameters. Multiple RP to group mappings can be created using the rp-group-mappings container. For each mapping, the RP service can be managed by the service provider using the leaf "provider-managed/enabled" set to true. In case of provider managed RP, the user can request a rendez-vous point redundancy and/or an optimal traffic delivery. Those parameters will help the service provider to select the appropriate technology or architecture to fulfill the customer service requirement: for instance, in case of a request for an optimal traffic delivery, a service provider may use Anycast-RP or RP-tree to SPT switchover architectures. In case of a customer managed RP, the RP address must be filled in the RP to group mappings using the "rp-address" leaf. This leaf is not needed for a provider managed RP. User can define a specific rp-discovery mechanism like: auto-rp, static-rp, bsr-rp modes. By default, the model considers static-rp if ASM is requested. A single rp-discovery mechanism is allowed for the VPN. The "rp-discovery" container can be used for both provider and customer managed RPs. In case of a provider managed RP, if the user wants to use bsr-rp as a discovery protocol, a service provider should consider the provider managed rp-group-mappings for the bsr-rp configuration. The service provider will then configure its selected RPs to be bsr-rp-candidates. In case of a customer managed RP and a bsr-rp discovery mechanism, the rp-address provided will be considered as bsr-rp candidate. Litkowski, et al. Expires May 8, 2017 [Page 23] Internet-Draft l3vpn-svc-cfg November 2016 6.2.4. Extranet VPNs There are some cases where a particular VPN needs to access to resources (servers, hosts ...) that are external. These resources may be located in another VPN. +-----------+ +-----------+ / \ / \ SiteA -- | VPN A | --- | VPN B | --- SiteB \ / \ / (Shared +-----------+ +-----------+ resources) In the figure above, VPN B has some resources on Site B that need to be available to some customers/partners. VPN A must be able to access those VPN B resources. Such VPN connection scenario can be achieved by the VPN policy defined in Section 6.5.2.2. But there are some simple cases where a particular VPN (VPN A) needs to access to all resources in a VPN B. The model provides an easy way to setup this connection using the "extranet-vpns" container. The "extranet-vpns" container defines a list of VPNs a particular VPN wants to access. The "extranet-vpns" must be used on customer VPNs accessing extranet resources in another VPN. In the figure above, in order to give access for VPN A to VPN B, extranet-vpns container needs to be configured under VPN A with an entry corresponding to VPN B and there is no service configuration requirement on VPN B. Readers should note that even if there is no configuration requirement on VPN B, if VPN A lists VPN B as extranet, all sites in VPN B will gain access to all sites in VPN A. The "site-role" leaf defines the role of the local VPN sites in the target extranet VPN service topology. Site roles are defined in Section 6.4. Based on this, the requirements described in Section 6.4 regarding the site-role leaf are also applicable here. In the example below, VPN A accesses to VPN B resources through an extranet connection, a Spoke role is required for VPN A sites as sites from VPN A must not be able to communicate between each other through the extranet VPN connection. Litkowski, et al. Expires May 8, 2017 [Page 24] Internet-Draft l3vpn-svc-cfg November 2016 VPNB hub-Spoke VPNA any-to-any VPNB spoke-role This model does not define how the extranet configuration will be achieved. Any more complex VPN interconnection scenario (e.g. only part of sites of VPN A accessing only part of sites of VPN B) needs to be achieved using the vpn attachment defined in Section 6.5.2 and especially the VPN policy defined in Section 6.5.2.2. 6.3. Site overview A site represents a connection of a customer office to one or more VPN services. +-------------+ / \ +------------------+ +-----| VPN1 | | | | \ / | New York Office | ----- (site) -----+ +-------------+ | | | +-------------+ +------------------+ | / \ +-----| VPN2 | \ / +-------------+ A site is composed of some characteristics : o Unique identifier (site-id): to uniquely identify the site within the overall network infrastructure. The identifier is a string allowing to any encoding for the local administration of the VPN service. Litkowski, et al. Expires May 8, 2017 [Page 25] Internet-Draft l3vpn-svc-cfg November 2016 o Locations (locations): site location information to allow easy retrieval on nearest available resources. A site may be composed of multiple locations. o Devices: the customer can request one or more customer premise equipments from the service provider for a particular site. o Management (management): defines the model of management of the site, for example : co-managed, customer managed or provider managed. o Site network accesses (site-network-accesses): defines the list of network accesses associated to the sites and their properties : especially bearer, connection and service parameters. A site-network-access represents an IP logical connection of a site. A site may have multiple site-network-accesses. +------------------+ Site | |----------------------------------- | |****** (site-network-access#1) ****** | New York Office | | |****** (site-network-access#2) ****** | |----------------------------------- +------------------+ Multiple site-network-accesses are used for instance in case of multihoming. Some other meshing cases may also involve multiple site-network-accesses. The site configuration is viewed as a global entity, we assume that it is mostly the role of the management to split the parameters between the different elements within the network. For example, in the case of the site-network-access configuration, the management system needs to split the overall parameters between the PE configuration and the CE configuration. 6.3.1. Devices and locations A site may be composed of multiple locations. All the locations will need to be configured as part of the "locations" container and list. A typical example of multilocation site is an headquarter in a city composed of multiple buildings. Those buildings may be located in different parts of the city and may be linked by intra-city fibers (customer metropolitan area network). In such a case, when Litkowski, et al. Expires May 8, 2017 [Page 26] Internet-Draft l3vpn-svc-cfg November 2016 connecting to a VPN service, the customer may ask for multihoming based on its distributed locations. New York Site +------------------+ Site | +--------------+ |----------------------------------- | | Manhattan | |****** (site-network-access#1) ****** | +--------------+ | | +--------------+ | | | Brooklyn | |****** (site-network-access#2) ****** | +--------------+ | | |----------------------------------- +------------------+ A customer may also request some premise equipments (CEs) to the service provider through the "devices" container. Requesting a CE implies a provider-managed or co-managed model. A particular device must be ordered to a particular already configured location. This would help the service provider to send the device to the appropriate postal address. In a multilocation site, a customer may for example request a CE for each location on the site where multihoming must be implemented. In the figure above, one device may be requested for the Manhattan location and one other for the Brooklyn location. By using devices and locations, the user can influence the multihoming scenario he wants to implement: single CE, dual CE... 6.3.2. Site network accesses As mentioned, a site may be multihomed. Each IP network access for a site is defined in the site-network-accesses list. The site-network- access defines how the site is connected on the network and is split into three main classes of parameters: o bearer: defines requirements of the attachment (below Layer 3). o connection: defines Layer 3 protocol parameters of the attachment. o availability: defines the site availability policy. The availability parameters are defined in Section 6.7 The site-network-access has a specific type (site-network-access- type). This documents defines two types : Litkowski, et al. Expires May 8, 2017 [Page 27] Internet-Draft l3vpn-svc-cfg November 2016 o point-to-point: describes a point to point connection between the service provider and the customer. o multipoint: describes a multipoint connection between the service provider and the customer. The type of site-network-access may have an impact on the parameters offered to the customer, e.g., a service provider may not offer encryption for multipoint accesses. Deciding what parameter is supported for point-to-point and/or multipoint accesses is up to the provider and is out of scope of this document. Some containers proposed in the model may require extension in order to work properly for multipoint accesses. 6.3.2.1. Bearer The "bearer" container defines the requirements for the site attachment to the provider network that are below Layer 3. The bearer parameters will help to determine the access media to be used. This is further described in Section 6.6.3. 6.3.2.2. Connection The "ip-connection" container defines the protocol parameters of the attachment (IPv4 and IPv6). Depending on the management mode, it refers to the PE-CE addressing or CE to customer LAN addressing. In any case, it describes the provider to customer responsibility boundary. For a customer managed site, it refers to the PE-CE connection. For a provider managed site, it refers to the CE to LAN connection. 6.3.2.2.1. IP addressing An IP subnet can be configured for either layer 3 protocols. For a dual stack connection, two subnets will be provided, one for each address family. The address-allocation-type determines how the address allocation needs to be done. The current model proposes five ways of IP address allocation: o provider-dhcp: the provider will provide DHCP service for customer equipments, this is can be applied to either IPv4 and IPv6 containers. o provider-dhcp-relay: the provider will provide DHCP relay service for customer equipments, this is applicable to both IPv4 and IPv6 Litkowski, et al. Expires May 8, 2017 [Page 28] Internet-Draft l3vpn-svc-cfg November 2016 addressing. The customer needs to fill DHCP server list to be used. o static-address: Addresses will be assigned manually, this is applicable to both IPv4 and IPv6 addressing. o slaac: enables stateless address autoconfiguration ([RFC4862]). This is applicable only for IPv6. o provider-dhcp-slaac: the provider will provide DHCP service for customer equipments as well as stateless address autoconfiguration. This is applicable only for IPv6. In the dynamic addressing mechanism, it is expected from the service provider to provide at least the IP address, mask and default gateway information. 6.3.2.2.2. OAM A customer may require a specific IP connectivity fault detection mechanism on the IP connection. The model supports BFD as a fault detection mechanism. This can be extended with other mechanisms by augmentation. The provider can propose some profiles to the customer depending of the service level the customer wants to achieve. Profile names must be communicated to the customer. This communication is out of scope of this document. Some fixed values for the holdtime period may also be imposed by the customer if the provider enables it. The OAM container can easily be augmented by other mechanisms, especially work from LIME Working Group may be reused. 6.3.2.3. Inheritance of parameters between site and site-network-access Some parameters can be configured both at the site level at the site- network-access level: e.g. routing, services, security... Inheritance applies when parameters are defined at site level. If a parameter is configured at both site and access level, the access level parameter MUST override the site level parameter. Those parameters will be described later in the document. In terms of provisionning impact, it will be up to the implementation to decide of the appropriate behavior when modifying existing configurations. But the service provider will need to communicate to the user about the impact of using inheritance. For example, if we consider that a site has already provisionned three site-network- accesses, what will happen if customer is changing a service parameter at site level ? An implementation of this model may update Litkowski, et al. Expires May 8, 2017 [Page 29] Internet-Draft l3vpn-svc-cfg November 2016 the service parameters of all already provisionned site-network- accesses (with potential impact on live traffic) or it may take into account this new parameter only for the new sites. 6.4. Site role A VPN has a particular service topology as described in Section 6.2.1. As a consequence, each site belonging to a VPN is assigned with a particular role in this topology. The site-role defines the role of the site in a particular VPN topology. In the any-to-any VPN service topology, all sites MUST have the same role which is any-to-any-role. In the hub-spoke or hub-spoke-disjoint VPN service topology, sites MUST have a hub-role or a spoke-role. 6.5. Site belonging to multiple VPNs 6.5.1. Site vpn flavor A site may be part of one or multiple VPNs. The site flavor defines the way the VPN multiplexing is done. The current version of the model supports four flavors: o site-vpn-flavor-single: the site belongs to only one VPN. o site-vpn-flavor-multi: the site belongs to multiple VPNs and all the logical accesses of the sites belongs to the same set of VPNs. o site-vpn-flavor-sub: the site belongs to multiple VPNs with multiple logical accesses. Each logical access may map to different VPNs (one or many). o site-vpn-flavor-nni: the site represents an option A NNI. 6.5.1.1. Single VPN attachment : site-vpn-flavor-single The figure below describes the single VPN attachment. The site connects to only one VPN. Litkowski, et al. Expires May 8, 2017 [Page 30] Internet-Draft l3vpn-svc-cfg November 2016 +--------+ +------------------+ Site / \ | |-----------------------------| | | |***(site-network-access#1)***| VPN1 | | New York Office | | | | |***(site-network-access#2)***| | | |-----------------------------| | +------------------+ \ / +--------+ 6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi The figure below describes a site connected to multiple VPNs. +---------+ +---/----+ \ +------------------+ Site / | \ | | |--------------------------------- | |VPN B| | |***(site-network-access#1)******* | | | | New York Office | | | | | | |***(site-network-access#2)******* \ | / | |-----------------------------| VPN A+-----|---+ +------------------+ \ / +--------+ In the example above, the New York office is multihomed, both logical accesses are using the same VPN attachment rules. Both logical accesses are connected to VPN A and VPN B. Reaching VPN A or VPN B from New York office will be based on destination based routing. Having the same destination reachable from the two VPNs may cause routing troubles. This would be the role of the customer administration to ensure the appropriate mapping of its prefixes in each VPN. 6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub The figure below describes a subVPN attachment. The site connects to multiple VPNs but each logical access is attached to a particular set of VPN. A typical use case of subVPN is a customer site used by multiple affiliates with private resources for each affiliates that cannot be shared (communication is prevented between the affiliates). It is similar than having separate sites instead that the customer wants to share some physical components while keeping a strong communication isolation between affiliates. In the example, the access#1 is attached to VPN B while the access#2 is attached to VPNA. Litkowski, et al. Expires May 8, 2017 [Page 31] Internet-Draft l3vpn-svc-cfg November 2016 +------------------+ Site +--------+ | |----------------------------------/ \ | |****(site-network-access#1)******| VPN B | | New York Office | \ / | | +--------+ | | +--------+ | | / \ | |****(site-network-access#2)******| VPN A | | | \ / | | +--------+ | |----------------------------------- +------------------+ MultiVPN can be implemented in addition to subVPN, as a consequence, each site-network-access can access to multiple VPNs. In the example below, access#1 is mapped to VPN B and VPN C, while access#2 is mapped to VPN A and VPN D. +------------------+ Site +-----+ | |----------------------------------/ +----+ | |****(site-network-access#1)******| VPN B/ \ | New York Office | \ | VPN C | | | +----\ / | | +-----+ | | | | +------+ | | / +-----+ | |****(site-network-access#2)******| VPN A/ \ | | \ | VPN D | | | +------\ / | |----------------------------------- +---+ +------------------+ Multihoming is also possible with subVPN, in this case, site-network- accesses are grouped, and a particular group will access to the same set of VPNs. In the example below, access#1 and #2 are part of the same group (multihomed together) and are mapped to VPN B and C, in addition access#3 and #4 are part of the same group (multihomed together) and are mapped to VPN A and D. Litkowski, et al. Expires May 8, 2017 [Page 32] Internet-Draft l3vpn-svc-cfg November 2016 +------------------+ Site +-----+ | |----------------------------------/ +----+ | |****(site-network-access#1)******| VPNB / \ | New York Office |****(site-network-access#2)******\ | VPN C | | | +----\ / | | +-----+ | | | | +------+ | | / +-----+ | |****(site-network-access#3)******| VPNA / \ | |****(site-network-access#4)****** \ | VPN D | | | +------\ / | |----------------------------------- +---+ +------------------+ In terms of service configuration, subVPN can be achieved by requesting the site-network-access to use the same bearer (see Section 6.6.4 and Section 6.6.6.4 for more details). 6.5.1.4. NNI : site-vpn-flavor-nni Some Network to Network Interface (NNI) scenario may be modeled using the site container (see Section 6.15.1). Using the site container to model an NNI is only one possible option for NNI (see Section 6.15). This option is called option A by reference to the option A NNI defined in [RFC4364]. It is helpful for the service provider to identify that the requested VPN connection is not a regular site but a NNI as specific default device configuration parameters may be applied in case of NNI (e.g. ACLs, routing policies...). Litkowski, et al. Expires May 8, 2017 [Page 33] Internet-Draft l3vpn-svc-cfg November 2016 SP A SP B --------------------- -------------------- / \ / \ | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + (VRF1)--(VPN1)----(VRF1) + | | + ASBR + + ASBR + | | + (VRF2)--(VPN2)----(VRF2) + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + (VRF1)--(VPN1)----(VRF1) + | | + ASBR + + ASBR + | | + (VRF2)--(VPN2)----(VRF2) + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / -------------------- ------------------- The figure above describes an option A NNI scenario that can be modeled using the site container. In order to connect its customer VPN (VPN1 and VPN2) on the SP B network, SP A may request the creation of some site-network-accesses to SP B. The site-vpn-flavor- nni will be used to inform SP B that this is an NNI and not a regular customer site. The site-vpn-flavor-nni may be multihomed and multiVPN as well. 6.5.2. Attaching a site to a VPN Due to the multiple site-vpn flavors, the attachment of a site to an IPVPN is done at the site-network-access (logical access) level through the vpn-attachment container. The vpn-attachment container is mandatory. The model provides two ways of attachment: o By referencing directly the target VPN. o By referencing a VPN policy for more complex attachments. A choice is implemented to allow user to choose the best fitting flavor. Litkowski, et al. Expires May 8, 2017 [Page 34] Internet-Draft l3vpn-svc-cfg November 2016 6.5.2.1. Reference a VPN Referencing a vpn-id provides an easy way to attach a particular logical access to a VPN. This is the best way in case of single VPN attachment or subVPN with single VPN attachment per logical access. When referencing a vpn-id, the site-role must be added to express the role of the site in the target VPN service topology. SITE1 LA1 VPNA spoke-role LA2 VPNB spoke-role The example above describes a subVPN case where a site SITE1 has two logical accesses (LA1 and LA2) with LA1 attached to VPNA and LA2 attached to VPNB. 6.5.2.2. VPN policy The vpn-policy helps to express a multiVPN scenario where a logical access belongs to multiple VPNs. Multiple VPN policies can be created to handle the subVPN case where each logical access is part of a different set of VPNs. As a site can belong to multiple VPNs, the vpn-policy may be composed of multiple entries. A filter can be applied to specify that only some LANs of the site should be part of a particular VPN. Each time a site (or LAN) is attached to a VPN, the user must precisely describe its role (site-role) within the target VPN service topology. Litkowski, et al. Expires May 8, 2017 [Page 35] Internet-Draft l3vpn-svc-cfg November 2016 +--------------------------------------------------------------+ | Site1 ------ PE7 | +-------------------------+ [VPN2] | | | +-------------------------+ | | Site2 ------ PE3 PE4 ------ Site3 | +----------------------------------+ | | | +------------------------------------------------------------+ | | Site4 ------ PE5 | PE6 ------ Site5 | | | | | | [VPN3] | | +------------------------------------------------------------+ | | | +---------------------------+ In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It will play a hub-role in VPN2 and an any-to-any role in VPN3. We can express such multiVPN scenario as follows: Litkowski, et al. Expires May 8, 2017 [Page 36] Internet-Draft l3vpn-svc-cfg November 2016 Site5 POLICY1 ENTRY1 VPN2 hub-role ENTRY2 VPN3 any-to-any-role LA1 POLICY1 Now, if a more granular VPN attachment is necessary, filtering can be used. For example, if LAN1 from Site5 must be attached to VPN2 as Hub and LAN2 must be attached to VPN3, the following configuration can be used: Litkowski, et al. Expires May 8, 2017 [Page 37] Internet-Draft l3vpn-svc-cfg November 2016 Site5 POLICY1 ENTRY1 LAN1 VPN2 hub-role ENTRY2 LAN2 VPN3 any-to-any-role LA1 POLICY1 6.6. Deciding where to connect the site The management system will have to determine where to connect each site-network-access of a particular site to the provider network (PE, aggregation switch ...). The current model proposes parameters and constraints that can influence the meshing of the site-network-access. The management system SHOULD honor the customer constraints, if the constraint is too strict and can not be filled, the management system Litkowski, et al. Expires May 8, 2017 [Page 38] Internet-Draft l3vpn-svc-cfg November 2016 MUST not provision the site and SHOULD provide an information to the user. How the information is provided is out of scope of the document. It would then be up to the user to relax the constraint or not. Parameters are just hints for the management system for service placement. In addition to parameters and constraints, the management system decision MAY be based on any other internal constraint that are up to the service provider: least load, distance ... 6.6.1. Constraint: Device In case of provider-management or co-management, one or more devices have been ordered by the customer. The customer may force a particular site-network-access to be connected on a particular device he ordered. New York Site +------------------+ Site | +--------------+ |----------------------------------- | | Manhattan | | | | CE1********* (site-network-access#1) ****** | +--------------+ | | +--------------+ | | | Brooklyn CE2********* (site-network-access#2) ****** | +--------------+ | | |----------------------------------- +------------------+ In the figure above, the site-network-access#1 is associated to CE1 in the service request. The service provider must ensure the provisionning of this connection. 6.6.2. Constraint/parameter: Site location The location information provided in this model MAY be used by a management system to determine the target PE to mesh the site (service provider side). A particular location must be associated to each site network access when configuring it. The service provider MUST honor the termination of the access on the location associated with the site network access (customer side). The country-code in the site-location SHOULD be expressed as an ISO ALPHA-2 code. Litkowski, et al. Expires May 8, 2017 [Page 39] Internet-Draft l3vpn-svc-cfg November 2016 The site-network-access location is determined by the "location- flavor". In case of provider-managed or co-managed site, the user is expected to configure a "device-reference" (device case) that will bind the site-network-access to a particular device the customer ordered. As each device is already associated to a particular location, in such case the location information is retrieved from the device location. In case of customer-managed site, the user is expected to configure a "location-reference" (location case), this provides a reference to an existing configured location and will help the placement. PoP#1 (New York) +---------+ | PE1 | Site #1 ---... | PE2 | (Atlantic City) | PE3 | +---------+ PoP#2 (Washington) +---------+ | PE4 | | PE5 | | PE6 | +---------+ PoP#3 (Philadelphia) +---------+ | PE7 | Site #2 CE#1---... | PE2 | (Reston) | PE9 | +---------+ In the example above, Site#1 is a customer managed site with a location L1, while Site#2 is a provider-managed site for which a CE#1 was ordered, Site#2 is configured with L2 as location. When configuring a site-network-access for Site#1, the user will need to reference the location L1, so the management system will know that the access will need to terminate on this location. Then this management system may mesh Site#1 on a PE in the Philadelphia PoP for distance reason. It may also take into account resources available on PEs to determine the exact target PE (e.g. least loaded). Regarding Site#2, the user is expected to configure the site-network- access with a device-reference to CE#1, so the management system will know that the access must terminate on the location of CE#1 and must be connected to CE#1. For placing the service provider side of the access connection, in case of shortest distance PE used, it may mesh Site #2 on the Washington PoP. Litkowski, et al. Expires May 8, 2017 [Page 40] Internet-Draft l3vpn-svc-cfg November 2016 6.6.3. Constraint/parameter: access type The management system needs to elect the access media to connect the site to the customer (for example : xDSL, leased line, Ethernet backhaul ...). The customer may provide some parameters/constraints that will provide hints to the management system. The bearer container information SHOULD be used as first input : o The "requested-type" provides an information about the media type the customer would like. If the "strict" leaf is equal to "true", this MUST be considered as a strict constraint, so the management system cannot connect the site with another media type. If the "strict" leaf is equal to "false" (default), if the requested-type cannot be fulfilled, the management system can select another type. The supported media types SHOULD be communicated by the service provider to the customer by a mechanism that is out of scope of the document. o The "always-on" leaf defines a strict constraint: if set to "true", the management system MUST elect a media type which is always-on (this means no dial access type). o The "bearer-reference" is used in case the customer has already ordered a network connection to the service provider apart of the IPVPN site and wants to reuse this connection. The string used in an internal reference from the service provider describing the already available connection. This is also a strict requirement that cannot be relaxed. How the reference is given to the customer is out of scope of the document but as a pure example, when the customer ordered the bearer (through a process out of this model), the service provider may had provided the bearer reference that can be used for provisionning services on top. Any other internal parameters from the service provider can be used in addition. The management system MAY use other parameters such as the requested svc-input-bandwidth and svc-output-bandwidth to help to decide the access type to be used. 6.6.4. Constraint: access diversity Each site-network-access may have one or more constraints that would drive the placement of the access. By default, the model assumes no constraint but is expected allocation of a unique bearer per site- network-access. In order to help the different placement scenarios, a site-network- access may be tagged using one or multiple group identifiers. The Litkowski, et al. Expires May 8, 2017 [Page 41] Internet-Draft l3vpn-svc-cfg November 2016 group identifier is a string so it can accommodate both explicit naming of a group of sites (e.g. "multihomed-set1" or "subVPN") or a numbered identifier (e.g. 12345678). The meaning of each group-id is local to each customer administrator. And the management system MUST ensure that different customers can use the same group-ids. One or more group-ids can also be defined at the site-level, as a consequence, all site-network-accesses under the site MUST inherit the group-ids of the site they are belonging to. When, in addition to the site group-ids, some group-ids are defined at the site- network-access level, the management system MUST consider the union of all groups (site level and site network access level) for this particular site-network-access. For an already configured site-network-access, each constraint MUST be expressed against a targeted set of site-network-accesses, this site-network-access MUST never be taken into account in the targeted set: e.g. "My site-network-access S must not be connected on the same PoP as the site-network-accesses that are part of group 10". The set of site-network-accesses against which the constraint is evaluated can be expressed as a list of groups or "all-other- accesses" or "all-other-groups". The "all-other-accesses" option means that the current site-network-access constraint MUST be evaluated against all the other site-network-accesses belonging to the current site. The "all-other-groups" option means that the constraint MUST be evaluated against all groups the current site- network-access is not belonging to. The current model proposes multiple constraint-types: pe-diverse: the current site-network-access MUST not be connected to the same PE as the targeted site-network-accesses. pop-diverse: the current site-network-access MUST not be connected to the same PoP as the targeted site-network-accesses. linecard-diverse: the current site-network-access MUST not be connected to the same linecard as the targeted site-network- accesses. bearer-diverse: the current site-network-access MUST NOT use common bearer components compared to bearers used by the targeted site-network-accesses. "bearer-diverse" provides some level of diversity at the access level. As an example, two "bearer- diverse" site-network-accesses must not use the same DSLAM or BAS or layer 2 switch... same-pe: the current site-network-access MUST be connected to the same PE as the targeted site-network-accesses. Litkowski, et al. Expires May 8, 2017 [Page 42] Internet-Draft l3vpn-svc-cfg November 2016 same-bearer: the current site-network-access MUST be connected using the same bearer as the targeted site-network-accesses. These constraint-types can be extended through augmentation. Each constraint is expressed as "The site-network-access S must be (e.g. pe-diverse, pop-diverse) from these site-network-accesses". The group-id used to target some site-network-accesses may be the same as the one used by the current site-network-access. This eases configuration of scenarios where a group of site-network-access has a constraint between each other. As an example if we want a set of sites (site#1 up to #5) to be connected on different PEs, we can tag them with the same group-id and express a pe-diverse constraint for this group-id. SITE1 1 10 pe-diverse 10 VPNA spoke-role SITE2 Litkowski, et al. Expires May 8, 2017 [Page 43] Internet-Draft l3vpn-svc-cfg November 2016 1 10 pe-diverse 10 VPNA spoke-role ... SITE5 1 10 pe-diverse 10 Litkowski, et al. Expires May 8, 2017 [Page 44] Internet-Draft l3vpn-svc-cfg November 2016 VPNA spoke-role The group-id used to target some site-network-accesses may be also different than the one used by the current site-network-access. This can be used to express that a group of site has some constraints against another group of sites, but there is no constraint within the group. As an example, if we consider a set of 6 sites with two sets and we want to ensure that a site in the first set must be pop- diverse from a site in the second set. SITE1 1 10 pop-diverse 20 VPNA spoke-role Litkowski, et al. Expires May 8, 2017 [Page 45] Internet-Draft l3vpn-svc-cfg November 2016 SITE2 1 10 pop-diverse 20 VPNA spoke-role ... SITE5 1 20 pop-diverse 10 Litkowski, et al. Expires May 8, 2017 [Page 46] Internet-Draft l3vpn-svc-cfg November 2016 VPNA spoke-role SITE6 1 20 pop-diverse 10 VPNA spoke-role 6.6.5. Impossible access placement Some impossible placement scenarios may be created through the proposed configuration framework. Impossible scenarios could come from too restrictive constraints leading to impossible placement in the network or conflicting constraints that would also lead to impossible placement. An example of conflicting rules would be to request a site-network-access#1 to be pe-diverse from a site-network- Litkowski, et al. Expires May 8, 2017 [Page 47] Internet-Draft l3vpn-svc-cfg November 2016 access#2 and to request at the same time that site-network-access#2 to be on the same PE as site-network-access#1. When the management system cannot determine the placement of a site-network-access, it SHOULD return an error message indicating that placement was not possible. 6.6.6. Examples of access placement 6.6.6.1. Multihoming The customer wants to create a multihomed site. The site will be composed of two site-network-accesses and the customer wants the two site-network-accesses to be meshed on different PoPs for resiliency purpose. PoP#1 +-------+ +---------+ | | | PE1 | | |---site_network_access#1 ---- | PE2 | | | | PE3 | | | +---------+ | Site#1| | | PoP#2 | | +---------+ | | | PE4 | | |---site_network_access#2 ---- | PE5 | | | | PE6 | | | +---------+ +-------+ This scenario can be expressed in the following way: SITE1 1 10 pop-diverse Litkowski, et al. Expires May 8, 2017 [Page 48] Internet-Draft l3vpn-svc-cfg November 2016 20 VPNA spoke-role 2 20 pop-diverse 10 VPNA spoke-role But it can also be expressed as: Litkowski, et al. Expires May 8, 2017 [Page 49] Internet-Draft l3vpn-svc-cfg November 2016 SITE1 1 pop-diverse VPNA spoke-role 2 pop-diverse VPNA spoke-role 6.6.6.2. Site offload The customer has six branch offices in a particular region and he wants to prevent to have all branch offices to be connected on the same PE. He wants to express that three branch offices cannot be connected on the same linecard. And the other branch offices must be connected on Litkowski, et al. Expires May 8, 2017 [Page 50] Internet-Draft l3vpn-svc-cfg November 2016 a different PoP. Those other branch offices cannot also be connected on the same linecard. PoP#1 +---------+ | PE1 | Office#1 ---... | PE2 | Office#2 ---... | PE3 | Office#3 ---... | PE4 | +---------+ PoP#2 +---------+ Office#4 ---... | PE4 | Office#5 ---... | PE5 | Office#6 ---... | PE6 | +---------+ This scenario can be expressed in the following way: o We need to create two sets of sites: set#1 composed of Office#1 up to 3, set#2 composed of Office#4 up to 6. o Sites within set#1 must be pop-diverse from sites within set#2 and vice versa. o Sites within set#1 must be linecard-diverse from other sites in set#1 (same for set#2). SITE1 1 10 pop-diverse Litkowski, et al. Expires May 8, 2017 [Page 51] Internet-Draft l3vpn-svc-cfg November 2016 20 linecard-diverse 10 VPNA spoke-role SITE2 1 10 pop-diverse 20 linecard-diverse 10 Litkowski, et al. Expires May 8, 2017 [Page 52] Internet-Draft l3vpn-svc-cfg November 2016 VPNA spoke-role SITE3 1 10 pop-diverse 20 linecard-diverse 10 VPNA spoke-role SITE4 Litkowski, et al. Expires May 8, 2017 [Page 53] Internet-Draft l3vpn-svc-cfg November 2016 1 20 pop-diverse 10 linecard-diverse 20 VPNA spoke-role SITE5 1 20 pop-diverse Litkowski, et al. Expires May 8, 2017 [Page 54] Internet-Draft l3vpn-svc-cfg November 2016 10 linecard-diverse 20 VPNA spoke-role SITE6 1 20 pop-diverse 10 linecard-diverse 20 Litkowski, et al. Expires May 8, 2017 [Page 55] Internet-Draft l3vpn-svc-cfg November 2016 VPNA spoke-role 6.6.6.3. Parallel links To increase its site bandwidth at a cheaper cost, a customer wants to order two parallel site-network-accesses that will be connected to the same PE. *******SNA1********** Site 1 *******SNA2********** PE1 This scenario can be expressed in the following way: SITE1 1 PE-linkgrp-1 same-pe PE-linkgrp-1 Litkowski, et al. Expires May 8, 2017 [Page 56] Internet-Draft l3vpn-svc-cfg November 2016 VPNB spoke-role 2 PE-linkgrp-1 same-pe PE-linkgrp-1 VPNB spoke-role 6.6.6.4. SubVPN with multihoming A customer has site which is dualhomed. The dualhoming must be done on two different PEs. The customer wants also to implement two subVPNs on those multihomed accesses. Litkowski, et al. Expires May 8, 2017 [Page 57] Internet-Draft l3vpn-svc-cfg November 2016 +------------------+ Site +-----+ | |----------------------------------/ +----+ | |****(site-network-access#1)******| VPNB / \ | New York Office |****(site-network-access#2)*************| VPN C | | | +----\ / | | +-----+ | | | | +------+ | | / +-----+ | |****(site-network-access#3)******| VPNB / \ | |****(site-network-access#4)**************| VPN C | | | +------\ / | |----------------------------------- +---+ +------------------+ This scenario can be expressed in the following way: o The site will have 4 site network accesses (2 subVPN coupled with dual homing). o Site-network-access#1 and #3 will correspond to the multihoming of the subVPN B. A PE-diverse constraint is required between them. o Site-network-access#2 and #4 will correspond to the multihoming of the subVPN C. A PE-diverse constraint is required between them. o To ensure proper usage of the same bearer for the subVPN, site- network-access #1 and #2 must share the same bearer as site- network-access #3 and #4. SITE1 1 dualhomed-1 pe-diverse dualhomed-2 Litkowski, et al. Expires May 8, 2017 [Page 58] Internet-Draft l3vpn-svc-cfg November 2016 same-bearer dualhomed-1 VPNB spoke-role 2 dualhomed-1 pe-diverse dualhomed-2 same-bearer dualhomed-1 VPNC spoke-role Litkowski, et al. Expires May 8, 2017 [Page 59] Internet-Draft l3vpn-svc-cfg November 2016 3 dualhomed-2 pe-diverse dualhomed-1 same-bearer dualhomed-2 VPNB spoke-role 4 dualhomed-2 pe-diverse dualhomed-1 Litkowski, et al. Expires May 8, 2017 [Page 60] Internet-Draft l3vpn-svc-cfg November 2016 same-bearer dualhomed-2 VPNC spoke-role 6.6.7. Route Distinguisher and VRF allocation The route-distinguisher is a critical parameter of PE-based L3VPNs as described in [RFC4364] that allows to distinguish common addressing plans in different VPNs. As for route-targets, it is expected that a management system will allocate a VRF on the target PE and a route- distinguisher for this VRF. If a VRF already exists on the target PE, and the VRF fulfils the connectivity constraints for the site, there is no need to recreate another VRF and the site MAY be meshed within this existing VRF. How the management system checks that an existing VRF fulfils the connectivity constraints for a site is out of scope of this document. If no such a VRF exists on the target PE, the management system has to initiate a new VRF creation on the target PE and has to allocate a new route-distinguisher for this new VRF. The management system MAY apply a per-VPN or per-VRF allocation policy for the route-distinguisher depending on the service provider policy. In a per-VPN allocation policy, all VRFs (dispatched on multiple PEs) within a VPN will share the same route distinguisher value. In a per-VRF model, all VRFs should always have a unique route-distinguisher value. Some other allocation policies are also possible, and this document does not restrict the allocation policies to be used. Litkowski, et al. Expires May 8, 2017 [Page 61] Internet-Draft l3vpn-svc-cfg November 2016 The allocation of route-distinguishers MAY be done in the same way as route-targets. The example provided in Section 6.2.1.1 could be reused. Note that a service provider MAY configure a target PE for an automated allocation of route-distinguishers. In this case, there will be no need for any backend system to allocate a route- distinguisher value. 6.7. Site network access availability A site may be multihomed, meaning it has multiple site-network-access points. Placement constraints defined in previous sections will help to ensure physical diversity. When the site-network-accesses are placed on the network, a customer may want to use a particular routing policy on those accesses. The "site-network-access/availability" container defines parameters for the site redundancy. The "access-priority" leaf defines a preference for a particular access. This preference is used to model loadbalancing or primary/backup scenarios. The higher the access- priority the higher the preference will be. The figure below describes how the access-priority attribute can be used. Hub#1 LAN (Primary/backup) Hub#2 LAN (Loadsharing) | | | access-priority 1 access-priority 1 | |--- CE1 ------- PE1 PE3 --------- CE3 --- | | | | | |--- CE2 ------- PE2 PE4 --------- CE4 --- | | access-priority 2 access-priority 1 | PE5 | | | CE5 | Spoke#1 site (Single-homed) In the figure above, Hub#2 requires loadsharing so all the site- network-accesses must use the same access-priority value. On the Litkowski, et al. Expires May 8, 2017 [Page 62] Internet-Draft l3vpn-svc-cfg November 2016 contrary, as Hub#1 requires primary/backup, an higher access-priority will be configured on the primary access. More complex scenarios can be modeled. Let's consider a Hub site with five accesses to the network (A1,A2,A3,A4,A5). The customer wants to loadshare its traffic on A1,A2 in the nominal situation. If A1 and A2 fails, he wants to loadshare its traffic on A3 and A4, and finally if A1 to A4 are down, he wants to use A5. We can model it easily by configuring the following access-priorities: A1=100, A2=100, A3=50, A4=50, A5=10. The access-priority has some limitation. A scenario like the previous one with five accesses but with the constraint of having traffic loadshared between A3 and A4 in case of A1 OR A2 being down is not achievable. But the authors consider that the access-priority covers most of the deployment use cases and the model can still be extended by augmentation to support additional use cases. 6.8. Traffic protection The service model supports the ability to protect the traffic for a site. A protection provides a better availability to multihoming by, for example, using local-repair techniques in case of failures. The associated level of service guarantee would be based on an agreement between customer and service provider and is out of scope of this document. Site#1 Site#2 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3 | | | | | | CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4 / / CE5 ----+ Site#3 In the figure above, we consider an IPVPN service with three sites including two dual homed sites (site#1 and #2). For dual homed sites, we consider PE1-CE1 and PE3-CE3 as primary, and PE2-CE2,PE4-CE4 as backup for the example (even if protection also applies to loadsharing scenarios). In order to protect Site#2 against a failure, user may set the "traffic-protection/enabled" leaf to true for site#2. How the Litkowski, et al. Expires May 8, 2017 [Page 63] Internet-Draft l3vpn-svc-cfg November 2016 traffic protection will be implemented is out of scope of the document. But as an example, in such a case, if we consider traffic coming from a remote site (site#1 or site#3), where the primary path is to use PE3 as egress PE. PE3 may have preprogrammed a backup forwarding entry pointing to backup path (through PE4-CE4) for all prefixes going through PE3-CE3 link. How the backup path is computed is out of scope of the document. When PE3-CE3 link fails, traffic is still received by PE3 but PE3 switch automatically traffic to the backup entry, path will so be PE1-P1-(...)-P3-PE3-PE4-CE4 until remote PEs reconverge and use PE4 as the egress PE. 6.9. Security The "security" container defines customer specific security parameters for the site. The security options supported in the model are limited but may be extended by augmentation. 6.9.1. Authentication The current model does not support any authentication parameters for the site connection, but such parameters may be added in the "authentication" container through augmentation. 6.9.2. Encryption A traffic encryption can be requested on the connection. It may be performed at layer 2 or layer 3 by selecting the appropriate enumeration in "layer" leaf. For example, a service provider may use IPSec when a customer is requesting layer 3 encryption. The encryption profile can be a service provider defined profile or a customer specific. When a service provider profile is used and a key (e.g. a preshared key) is allocated by the provider to be used by a customer, the service provider should provide a way to communicate the key in a secured way to the customer. When a customer profile is used, the model supports only preshared key for authentication with the preshared key provided through the NETCONF or RESTCONF request. A secure channel must be used to ensure that the preshared key cannot be intercepted. It may be necessary for the customer to change the preshared key on a regular basis for security reasons. To perform a key change, the user can request to the service provider by submitting a new preshared key for the site configuration (as displayed below). This mechanism may not to be hitless. Litkowski, et al. Expires May 8, 2017 [Page 64] Internet-Draft l3vpn-svc-cfg November 2016 SITE1 1 MY_NEW_KEY An hitless key change mechanism may be added through augmentation. Other key management methodology may be added through augmentation. A "pki" empty container has been created to help support of PKI through augmentation. 6.10. Management The model proposes three types of common management options: o provider-managed: the CE router is managed only by the provider. In this model, the responsibility boundary between SP and customer is between CE and customer network. o customer-managed: the CE router is managed only by the customer. In this model, the responsibility boundary between SP and customer is between PE and CE. o co-managed: the CE router is primarly managed by the provider and in addition SP lets customer accessing the CE for some configuration/monitoring purpose. In the co-managed mode the responsibility boundary is the same as the provider-managed model. Based on the management model, different security options MAY be derived. In case of "co-managed", the model proposes some options to define the management address family (IPv4 or IPv6) and the associated management address. Litkowski, et al. Expires May 8, 2017 [Page 65] Internet-Draft l3vpn-svc-cfg November 2016 6.11. Routing protocols Routing-protocol defines which routing protocol must be activated between the provider and the customer router. The current model supports: bgp, rip, ospf, static, direct, vrrp. The routing protocol defined applies at the provider to customer boundary. Depending on the management of the management model, it may apply to the PE-CE boundary or CE to customer boundary. In case of a customer managed site, the routing-protocol defined will be activated between the PE and the CE router managed by the customer. In case of a provider managed site, the routing-protocol defined will be activated between the CE managed by the SP and the router or LAN belonging to the customer. In this case, it is expected that the PE- CE routing will be configured based on the service provider rules as both are managed by the same entity. Rtg protocol 192.0.2.0/24 ----- CE ----------------- PE1 Customer managed site Rtg protocol Customer router ----- CE ----------------- PE1 Provider managed site All the examples below will refer to a customer managed site case. 6.11.1. Dual stack handling All routing protocol types support dual stack by using address-family leaf-list. Example of Dual stack using the same routing protocol: static ipv4 ipv6 Litkowski, et al. Expires May 8, 2017 [Page 66] Internet-Draft l3vpn-svc-cfg November 2016 Example of Dual stack using two different routing protocols: rip ipv4 ospf ipv6 6.11.2. Direct LAN connection onto SP network Routing-protocol "direct" SHOULD be used when a customer LAN is directly connected to the provider network and must be advertised in the IPVPN. LAN attached directly to provider network: 192.0.2.0/24 ----- PE1 In this case, the customer has a default route to the PE address. 6.11.3. Direct LAN connection onto SP network with redundancy Routing-protocol "vrrp" SHOULD be used when a customer LAN is directly connected to the provider network and must be advertised in the IPVPN and LAN redundancy is expected. LAN attached directly to provider network with LAN redundancy: 192.0.2.0/24 ------ PE1 | +--- PE2 In this case, the customer has a default route to the service provider network. Litkowski, et al. Expires May 8, 2017 [Page 67] Internet-Draft l3vpn-svc-cfg November 2016 6.11.4. Static routing Routing-protocol "static" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IPVPN. Static rtg 192.0.2.0/24 ------ CE -------------- PE | | | Static route 192.0.2.0/24 nh CE Static route 0.0.0.0/0 nh PE In this case, the customer has a default route to the service provider network. 6.11.5. RIP routing Routing-protocol "rip" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IPVPN. For IPv4, the model assumes usage of RIP version 2. In case of dual stack routing requested through this model, the management system will be responsible to configure rip (including right version number) and associated address-families on network elements. RIP rtg 192.0.2.0/24 ------ CE -------------- PE 6.11.6. OSPF routing Routing-protocol "ospf" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IPVPN. It can be used to extend an existing OSPF network and interconnect different areas. See [RFC4577] for more details. +---------------------+ | | OSPF | | OSPF area 1 | | area 2 (OSPF | | (OSPF area 1) --- CE ---------- PE PE ----- CE --- area 2) | | +---------------------+ Litkowski, et al. Expires May 8, 2017 [Page 68] Internet-Draft l3vpn-svc-cfg November 2016 The model also proposes an option to create an OSPF sham-link between two sites sharing the same area and having a backdoor link. The sham-link is created by referencing the target site sharing the same OSPF area. The management system will be responsible to check if there is already a shamlink configured for this VPN and area between the same pair of PEs. If there is no existing shamlink, the management system will provision it. This shamlink MAY be reused by other sites. +------------------------+ | | | | | PE (--shamlink--)PE | | | | | +----|----------------|--+ | OSPF area1 | OSPF area 1 | | CE1 CE2 | | (OSPF area1) (OSPF area1) | | +----------------+ Regarding Dual stack support, user MAY specify both IPv4 and IPv6 address families, if both protocols should be routed through OSPF. As OSPF uses separate protocol instances for IPv4 and IPv6, the management system will need to configure both ospf version 2 and version 3 on the PE-CE link. Example of OSPF routing parameters in service model. ospf 0.0.0.1 ipv4 ipv6 Litkowski, et al. Expires May 8, 2017 [Page 69] Internet-Draft l3vpn-svc-cfg November 2016 Example of PE configuration done by management system: router ospf 10 area 0.0.0.1 interface Ethernet0/0 ! router ospfv3 10 area 0.0.0.1 interface Ethernet0/0 ! 6.11.7. BGP routing Routing-protocol "bgp" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IPVPN. BGP rtg 192.0.2.0/24 ------ CE -------------- PE The session addressing will be derived from connection parameters as well as internal knowledge of SP. In case of dual stack access, user MAY request BGP routing for both IPv4 and IPv6 by specifying both address-families. It will be up to SP and management system to determine how to decline the configuration (two BGP sessions, single, multisession ...). The service configuration below activates BGP on PE-CE link for both IPv4 and IPv6. BGP activation requires SP to know the address of the customer peer. "static-address" allocation type for the IP connection MUST be used. bgp 65000 ipv4 ipv6 This service configuration can be derived by management system into multiple flavors depending on SP flavor. Litkowski, et al. Expires May 8, 2017 [Page 70] Internet-Draft l3vpn-svc-cfg November 2016 Example #1 of PE configuration done by management system (single session IPv4 transport session): router bgp 100 neighbor 203.0.113.2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET-NH-IPV6 out Example #2 of PE configuration done by management system (two sessions): router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 2001::2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 2001::2 activate Example #3 of PE configuration done by management system (multisession): router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 203.0.113.2 multisession per-af address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET-NH-IPV6 out 6.12. Service The service defines service parameters associated with the site. 6.12.1. Bandwidth The service bandwidth refers to the bandwidth requirement between PE and CE (WAN link bandwidth). The requested bandwidth is expressed as svc-input-bandwidth and svc-output-bandwidth in bits per seconds. Input/output direction is using customer site as reference: input bandwidth means download bandwidth for the site, and output bandwidth means upload bandwidth for the site. Litkowski, et al. Expires May 8, 2017 [Page 71] Internet-Draft l3vpn-svc-cfg November 2016 The service bandwidth is only configurable at site-network-access level. Using a different input and output bandwidth will allow service provider to know if customer allows for asymmetric bandwidth access like ADSL. It can also be used to set rate-limit in a different way upload and download on a symmetric bandwidth access. The bandwidth is a service bandwidth: expressed primarily as IP bandwidth but if the customer enables MPLS for carrier's carrier, this becomes MPLS bandwidth. 6.12.2. QoS The model proposes to define QoS parameters in an abstracted way: o qos-classification-policy: define a set of ordered rules to classify customer traffic. o qos-profile: QoS scheduling profile to be applied. 6.12.2.1. QoS classification QoS classification rules are handled by qos-classification-policy. The qos-classification-policy is an ordered list of rules that match a flow or application and set the appropriate target class of service (target-class-id). The user can define the match using an application reference or a more specific flow definition (based layer 3 source and destination address, layer 4 ports, layer 4 protocol). When a flow definition is used, the user can use a target-sites leaf- list to identify the destination of a flow rather than using destination IP addresses. In such a case, an association between the site abstraction and the IP addresses used by this site must be done dynamically. How this association is done is out of scope of this document and an implementation may not support this criterion and should advertise a deviation in this case. A rule that does not have a match statement is considered as a match-all rule. A service provider may implement a default terminal classification rule if the customer does not provide it. It will be up to the service provider to determine its default target class. The current model defines some applications but new application identities may be added through augmentation. The exact meaning of each application identity is up to the service provider, so it will be necessary for the service provider to advise customer on usage of application matching. Where the classification is done depends on the SP implementation of the service, but classification concerns the flow coming from the customer site and entering the network. Litkowski, et al. Expires May 8, 2017 [Page 72] Internet-Draft l3vpn-svc-cfg November 2016 Provider network +-----------------------+ 192.0.2.0/24 198.51.100.0/24 ---- CE --------- PE Traffic flow ----------> In the figure above, the management system should implement the classification rule: o in the ingress direction on the PE interface, if the CE is customer managed. o in the ingress direction on the CE interface connected to customer LAN, if the CE is provider managed. The figure below describes a sample service description of qos- classification for a site : Litkowski, et al. Expires May 8, 2017 [Page 73] Internet-Draft l3vpn-svc-cfg November 2016 1 192.0.2.0/24 203.0.113.1/32 80 tcp DATA2 2 192.0.2.0/24 203.0.113.1/32 21 tcp DATA2 3 p2p DATA3 4 DATA1 In the example above: o HTTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32 will be classified in DATA2. o FTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32 will be classified in DATA2. o Peer to peer traffic will be classified in DATA3. o All other traffic will be classified in DATA1. Litkowski, et al. Expires May 8, 2017 [Page 74] Internet-Draft l3vpn-svc-cfg November 2016 The order of rules is really important. The management system responsible for translating those rules in network element configuration MUST keep the same processing order in network element configuration. The order of rule is defined by the "id" leaf. The lowest "id" MUST be processed first. 6.12.2.2. QoS profile User can choose between standard profile provided by the operator or custom profile. The qos-profile defines the traffic scheduling policy to be used by the service provider. Provider network +-----------------------+ 192.0.2.0/24 198.51.100.0/24 ---- CE --------- PE \ / qos-profile In case of provider managed or co-managed connection, the provider should ensure scheduling according to the requested policy in both traffic directions (SP to customer and customer to SP). As example of implementation, a device scheduling policy may be implemented both at PE and CE side on the WAN link. In case of customer managed connection, the provider is only responsible to ensure scheduling from SP network to the customer site. As example of implementation, a device scheduling policy may be implemented only at PE side on the WAN link towards the customer. A custom qos-profile is defined as a list of class of services and associated properties. The properties are: o rate-limit: used to rate-limit the class of service. The value is expressed as a percentage of the global service bandwidth. When the qos-profile is implemented at CE side the svc-output-bandwidth is taken into account as reference. When it is implemented at PE side, the svc-input-bandwidth is used. o latency: used to define the latency constraint of the class. The latency constraint can be expressed as the lowest possible latency or a latency boundary expressed in milliseconds. How this latency constraint will be fulfilled is up to the service provider implementation: a strict priority queueing may be used on the access and in the core network, and/or a low latency routing may be created for this traffic class. Litkowski, et al. Expires May 8, 2017 [Page 75] Internet-Draft l3vpn-svc-cfg November 2016 o jitter: used to define the jitter constraint of the class. The jitter constraint can be expressed as the lowest possible jitter or a jitter boundary expressed in microseconds. How this jitter constraint will be fulfilled is up to the service provider implementation: a strict priority queueing may be used on the access and in the core network, and/or a jitter-aware routing may be created for this traffic class. o bandwidth: used to define a guaranteed amount of bandwidth for the class of service. It is expressed as a percentage. The guaranteed-bw-percent uses available bandwidth as a reference. When the qos-profile is implemented at CE side the svc-output- bandwidth is taken into account as reference. When it is implemented at PE side, the svc-input-bandwidth is used. By default, the bandwidth reservation is only guaranteed at the access level. The user can use the "end-to-end" leaf to request an end-to-end bandwidth reservation including the MPLS transport network. Some constraints may not be offered by a service provider, in this case a deviation should be advertised. In addition, due to the network conditions, some constraints may not be completely fulfilled by the service provider, in this case, the service provider should advise the customer about the limitations. How this communication is done is out of scope of this document. Example of service configuration using a standard qos profile: Litkowski, et al. Expires May 8, 2017 [Page 76] Internet-Draft l3vpn-svc-cfg November 2016 1245HRTFGJGJ154654 100000000 100000000 PLATINUM 555555AAAA2344 2000000 2000000 GOLD Example of service configuration using a custom qos profile: Litkowski, et al. Expires May 8, 2017 [Page 77] Internet-Draft l3vpn-svc-cfg November 2016 Site1 100000000 100000000 REAL_TIME 10 DATA1 70 80 DATA2 200 5 The custom qos-profile for site1 defines a REAL_TIME class with a lowest possible latency constraint. It defines also two data classes DATA1 and DATA2. The two classes express a latency boundary Litkowski, et al. Expires May 8, 2017 [Page 78] Internet-Draft l3vpn-svc-cfg November 2016 constraint as well as a bandwidth reservation. As the REAL_TIME class is rate-limited to 10% of the service bandwidth (10% of 100Mbps = 10Mbps). In case of congestion, the REAL_TIME traffic can go up to 10Mbps (let's assume that only 5Mbps are consumed). DATA1 and DATA2 will share the remaining bandwidth (95Mbps) according to their percentage. So the DATA1 class will be served with at least 76Mbps of bandwidth while the DATA2 class will be served with at least 4.75Mbps. The latency boundary information of the data class may help the service provider to define a specific buffer tuning or a specific routing within the network. The maximum percentage to be used is not limited by this model but MUST be limited by the management system according to the policies authorized by the service provider. 6.12.3. Multicast The multicast section defines the type of site in the customer multicast service topology: source, receiver, or both. These parameters will help management system to optimize the multicast service. User can also define the type of multicast relation with the customer: router (requires a protocol like PIM), host (IGMP or MLD), or both. Address family (IPv4 or IPv6 or both) can also be defined. 6.13. Enhanced VPN features 6.13.1. Carrier's Carrier In case of Carrier's Carrier ([RFC4364]), a customer may want to build MPLS service using an IPVPN to carry its traffic. Litkowski, et al. Expires May 8, 2017 [Page 79] Internet-Draft l3vpn-svc-cfg November 2016 LAN customer1 | | CE1 | | ------------- (vrf_cust1) CE1_ISP1 | ISP1 PoP | MPLS link | ------------- | (vrf ISP1) PE1 (...) Provider backbone PE2 (vrf ISP1) | | ------------ | | MPLS link | ISP1 PoP CE2_ISP1 (vrf_cust1) |------------- | CE2 | Lan customer1 In the figure above, ISP1 resells IPVPN service but has no core network infrastructure between its PoPs. ISP1 uses an IPVPN as core network infrastructure (belonging to another provider) between its PoPs. In order to support CsC, the VPN service must be declared MPLS support using the "carrierscarrier" leaf set to true in vpn-service. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run an MPLS signalling protocol. This configuration is done at the site level. In the proposed model, LDP or BGP can be used as the MPLS signalling protocol. In case of LDP, an IGP routing protocol MUST also be Litkowski, et al. Expires May 8, 2017 [Page 80] Internet-Draft l3vpn-svc-cfg November 2016 activated. In case of BGP signalling, BGP MUST also be configured as routing-protocol. In case Carrier's Carrier is enabled, the requested svc-mtu will refer to the MPLS MTU and not to the IP MTU. 6.14. External ID references The service model sometimes refers to external information through identifiers. As an example, to order a cloud-access to a particular Cloud Service Provider (CSP), the model uses an identifier to refer to the targeted CSP. In case, a customer is using directly this service model as an API (through REST or NETCONF for example) to order a particular service, the service provider should provide a list of authorized identifiers. In case of cloud-access, the service provider will provide the identifiers associated of each available CSP. The same applies to other identifiers like std-qos-profile, oam profile-name, provider-profile for encryption ... How an SP provides those identifiers meaning to the customer is out of scope of this document. 6.15. Defining NNIs An autonomous system is a single network or group of networks that is controlled by a common system administration group and that uses a single, clearly defined routing protocol. In some cases, VPNs need to span across different autonomous systems in different geographic areas or across different service providers. The connection between autonomous systems is established by the Service Providers and is seamless to the customer. Some examples are: Partnership between service providers (carrier, cloud ...) to extend their VPN service seamlessly, or internal administrative boundary within a single service provider (Backhaul vs Core vs Datacenter ...). NNIs (Network to Network Interfaces) have to be defined to extend the VPNs across multiple autonomous systems. [RFC4364] defines multiple flavors of VPN NNI implementations. Each implementation has different pros/cons that are outside the scope of this document. As an example: In an Inter-AS Option A, ASBR peers are connected by multiple interfaces with at least one interface which VPN spans the two autonomous systems. These ASBRs associate each interface with a VPN routing and forwarding (VRF) instance and a Border Gateway Protocol (BGP) session to signal unlabeled IP prefixes. As a result, traffic between the back-to-back VRFs is IP. Litkowski, et al. Expires May 8, 2017 [Page 81] Internet-Draft l3vpn-svc-cfg November 2016 In this scenario, the VPNs are isolated from each other, and because the traffic is IP, QoS mechanisms that operate on IP traffic can be applied to achieve customer Service Level Agreements (SLAs). -------- -------------- ----- / \ / \ / \ | Cloud | | | | | | Provider | ----NNI---- | | ---NNI---| DC | | #1 | | | | | \ / | | \ / -------- | | ---- | | -------- | My network | ----------- / \ | | / \ | Cloud | | | | | | Provider | ----NNI---- | |---NNI---| L3VPN | | #2 | | | | Partner | \ / | | | | -------- | | | | \ / | | -------------- \ / | ---------- | NNI | | ------------------- / \ | | | | | | | L3VPN partner | | | \ / ------------------ The figure above describes a service provider network "My network" that has several NNIs. This network uses NNI to: o increase its footprint by relying on L3VPN partners. o connect its own datacenter services to the customer IPVPN. o enable customer to access to its private resources located in private cloud owned by some cloud service providers. Litkowski, et al. Expires May 8, 2017 [Page 82] Internet-Draft l3vpn-svc-cfg November 2016 6.15.1. Defining NNI with option A flavor AS A AS B --------------------- -------------------- / \ / \ | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + (VRF1)--(VPN1)----(VRF1) + | | + ASBR + + ASBR + | | + (VRF2)--(VPN2)----(VRF2) + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + (VRF1)--(VPN1)----(VRF1) + | | + ASBR + + ASBR + | | + (VRF2)--(VPN2)----(VRF2) + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / -------------------- ------------------- In option A, the two ASes are connected between each other with physical links on Autonomous System Border Routers (ASBR). There may be multiple physical connections between the ASes for a resiliency purpose. A VPN connection, physical or logical (on top of physical), is created for each VPN that needs to cross the AS boundary. A back- to-back VRF model is so created. This VPN connection can be seen as a site from a service model perspective. Let's say that AS B wants to extend some VPN connection for VPN C on AS A. Administrator of AS B can use this service model to order a site on AS A. All connection scenarios could be realized using the current model features. As an example, the figure above, where two physical connections are involved with logical connections per VPN on top, could be seen as a dualhomed subVPN scenario. And for example, administrator from AS B will be able to choose the appropriate routing protocol (e.g. ebgp) to dynamically exchange routes between ASes. Litkowski, et al. Expires May 8, 2017 [Page 83] Internet-Draft l3vpn-svc-cfg November 2016 This document assumes that option A NNI flavor SHOULD reuse the existing VPN site modeling. Example: a customer wants from its cloud service provider A to attach its virtual network N to an existing IPVPN (VPN1) he has from a L3VPN service provider B. CSP A L3VPN SP B ----------------- -------------------- / \ / \ | | | | | | VM --| ++++++++ NNI ++++++++ |---- VPN1 | | + +_________+ + | Site#1 | |--------(VRF1)---(VPN1)--(VRF1)+ | | | + ASBR + + ASBR + | | | + +_________+ + | | | ++++++++ ++++++++ | | VM --| | | |---- VPN1 | |Virtual | | | Site#2 | |Network | | | | VM --| | | |---- VPN1 | | | | | Site#3 \ / \ / ---------------- ------------------- | | VPN1 Site#4 The cloud service provider or the customer may use our L3VPN service model exposed by service provider B to create the VPN connectivity. We could consider that, as the NNI is shared, the physical connection (bearer) between CSP A and SP B already exists. CSP A may request through a service model a new site creation with a single site- network-access (single homing used in the diagram). As placement constraint, CSP A may use the existing bearer reference it has from SP A to force the placement of the VPN NNI on the existing link. The XML below describes what could be the configuration request to SP B: Litkowski, et al. Expires May 8, 2017 [Page 84] Internet-Draft l3vpn-svc-cfg November 2016 CSP_A_attachment NY US site-vpn-flavor-nni bgp 500 ipv4 CSP_A_VN1 static-address 203.0.113.1 203.0.113.2 30 450000000 450000000 VPN1 any-to-any-role customer-managed The case described above is different from the cloud-access container usage as the cloud-access provides a public cloud access while this Litkowski, et al. Expires May 8, 2017 [Page 85] Internet-Draft l3vpn-svc-cfg November 2016 example enables access to private resources located in a cloud service provider network. 6.15.2. Defining NNI with option B flavor AS A AS B --------------------- -------------------- / \ / \ | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + + + + | | + ASBR +<---mpebgp--->+ ASBR + | | + + + + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + + + + | | + ASBR +<---mpebgp--->+ ASBR + | | + + + + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / -------------------- ------------------- In option B, the two ASes are connected between each other with physical links on Autonomous System Border Routers (ASBR). There may be multiple physical connections between the ASes for a resiliency purpose. The VPN "connection" between ASes is done by exchanging VPN routes through MP-BGP. There are multiple flavors of implementations of such NNI, for example: 1. The NNI is a provider internal NNI between a backbone and a DC. There is enough trust between the domains to not filter the VPN routes. So all the VPN routes are exchanged. Route target filtering may be implemented to save some unnecessary route states. Litkowski, et al. Expires May 8, 2017 [Page 86] Internet-Draft l3vpn-svc-cfg November 2016 2. The NNI is used between providers that agreed to exchange VPN routes for specific route-targets only. Each provider is authorized to use the route-target values from the other provider. 3. The NNI is used between providers that agreed to exchange VPN routes for specific route-targets only. Each provider has its own route-target scheme. So a customer spanning the two networks will have different route-target in each network for a particular VPN. Case 1 does not require any service modeling, as the protocol enables dynamic exchange of necessary VPN routes. Case 2 requires to maintain some route-target filtering policy on ASBRs. From a service modeling point of view, it is necessary to agree on the list of route target to authorize. In case 3, both ASes need to agree on the VPN route-target to exchange and in addition how to map a VPN route-target from AS A to the corresponding route-target in AS B (and vice-versa). Those modelings are currently out of scope of this document. Litkowski, et al. Expires May 8, 2017 [Page 87] Internet-Draft l3vpn-svc-cfg November 2016 Cloud SP L3VPN SP B A ----------------- -------------------- / \ / \ | | | | | | VM --| ++++++++ NNI ++++++++ |---- VPN1 | | + +_________+ + | Site#1 | |-------+ + + + | | | + ASBR +<-mpebgp->+ ASBR + | | | + +_________+ + | | | ++++++++ ++++++++ | | VM --| | | |---- VPN1 | |Virtual | | | Site#2 | |Network | | | | VM --| | | |---- VPN1 | | | | | Site#3 \ / | | ---------------- | | \ / ------------------- | | VPN1 Site#4 The example above describes an NNI connection between the service provider network B and a cloud service provider A. Both service providers do not trust themselves and use a different route-target allocation policy. So, in term of implementation, the customer VPN has a different route-target in each network (RT A in CSP A and RT B is CSP B). In order to connect the customer virtual network in CSP A to the customer IPVPN (VPN1) in SP B network, CSP A should request SP B to open the customer VPN on the NNI (accept the appropriate RT). Who does the RT translation is up to an agreement between the two service providers: SP B may permit CSP A to request VPN (RT) translation. 6.15.3. Defining NNI with option C flavor Litkowski, et al. Expires May 8, 2017 [Page 88] Internet-Draft l3vpn-svc-cfg November 2016 AS A AS B --------------------- -------------------- / \ / \ | | | | | | | | | | | | | ++++++++ Multihop ebgp++++++++ | | + + + + | | + + + + | | + RGW +<---mpebgp--->+ RGW + | | + + + + | | + + + + | | ++++++++ ++++++++ | | | | | | | | | | | | | | | | | | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + + + + | | + ASBR + + ASBR + | | + + + + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | | | | | | ++++++++ InterAS link ++++++++ | | + +_____________ + + | | + + + + | | + ASBR + + ASBR + | | + + + + | | + +______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / -------------------- ------------------- From a VPN service perspective, option C NNI is very similar to option B as an MP-BGP session is used to exchange VPN routes between the ASes. The difference is that the forwarding and control plane are on different nodes, so the MP-BGP is multihop between routing gateway (RGW) nodes. Litkowski, et al. Expires May 8, 2017 [Page 89] Internet-Draft l3vpn-svc-cfg November 2016 Modeling option B and C will be identical from a VPN service point of view. 7. Service model usage example As explained in Section 5, this service model is intended to be instantiated at a management layer and is not intended to be used directly on network elements. The management system serves as a central point of configuration of the overall service. This section provides an example on how a management system can use this model to configure an IPVPN service on network elements. The example wants to achieve the provisionning of a VPN service for 3 sites using Hub and Spoke VPN service topology. One of the sites will be dual homed and loadsharing is expected. +-------------------------------------------------------------+ | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 | | | +----------------------------------+ | | | | | +----------------------------------+ | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 | +-------------------------------------------------------------+ The following XML describes the overall simplified service configuration of this VPN. 12456487 hub-spoke When receiving the request for provisioning the VPN service, the management system will internally (or through communication with another OSS component) allocates VPN route-targets. In this specific case two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The output below describes the configuration of Spoke1. Spoke_Site1 NY US bgp Litkowski, et al. Expires May 8, 2017 [Page 90] Internet-Draft l3vpn-svc-cfg November 2016 500 ipv4 ipv6 Spoke_Site1 20 pe-diverse 10 static-address 203.0.113.254 203.0.113.2 24 static-address 2001:db8::1 2001:db8::2 64 Litkowski, et al. Expires May 8, 2017 [Page 91] Internet-Draft l3vpn-svc-cfg November 2016 450000000 450000000 12456487 spoke-role provider-managed When receiving the request for provisioning Spoke1 site, the management system MUST allocate network resources for this site. It MUST first determine the target network elements to provision the access, and especially the PE router (and may be an aggregation switch). As described in Section 6.6, the management system SHOULD use the location information and SHOULD use the access-diversity constraint to find the appropriate PE. In this case, we consider Spoke1 requires PE diversity with Hub and that management system allocate PEs based on lowest distance. Based on the location information, the management system finds the available PEs in the nearest area of the customer and picks one that fits the access- diversity constraint. When the PE is chosen, the management system needs to allocate interface resources on the node. One interface is selected from the PE available pool. The management system can start provisioning the PE node by using any mean (Netconf, CLI, ...). The management system will check if a VRF is already present that fits the needs. If not, it will provision the VRF: Route distinguisher will come from internal allocation policy model, route-targets are coming from the vpn-policy configuration of the site (management system allocated some RTs for the VPN). As the site is a Spoke site (site-role), the management system knows which RT must be imported and exported. As the site is provider managed, some management route-targets may also be added (100:5000). Standard provider VPN policies MAY also be added in the configuration. Litkowski, et al. Expires May 8, 2017 [Page 92] Internet-Draft l3vpn-svc-cfg November 2016 Example of generated PE configuration: ip vrf Customer1 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration route-distinguisher 100:3123234324 route-target import 100:1 route-target import 100:5000 <---- Standard SP configuration route-target export 100:2 for provider managed ! When the VRF has been provisioned, the management system can start configuring the access on the PE using the allocated interface information. IP addressing is chosen by the management system. One address will be picked from an allocated subnet for the PE, another will be used for the CE configuration. Routing protocols will also be configured between PE and CE and due to provider managed model, the choice is up to service provider: BGP was chosen for the example. This choice is independant of the routing protocol chosen by customer. For the CE - LAN part, BGP will be used as requested in the service model. Peering addresses will be derived from those of the connection. As CE is provider managed, CE AS number can be automatically allocated by the management system. Some provider standard configuration templates may also be added. Litkowski, et al. Expires May 8, 2017 [Page 93] Internet-Draft l3vpn-svc-cfg November 2016 Example of generated PE configuration: interface Ethernet1/1/0.10 encapsulation dot1q 10 ip vrf forwarding Customer1 ip address 198.51.100.1 255.255.255.252 <---- Comes from automated allocation ipv6 address 2001:db8::10:1/64 ip access-group STD-PROTECT-IN <---- Standard SP config ! router bgp 100 address-family ipv4 vrf Customer1 neighbor 198.51.100.2 remote-as 65000 <---- Comes from automated allocation neighbor 198.51.100.2 route-map STD in <---- Standard SP config neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config ! address-family ipv6 vrf Customer1 neighbor 2001:db8::0A10:2 remote-as 65000 <---- Comes from automated allocation neighbor 2001:db8::0A10:2 route-map STD in <---- Standard SP config neighbor 2001:db8::0A10:2 filter-list 10 in <---- Standard SP config ! ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2 ! Static route for provider administration of CE ! As the CE router is not reachable at this stage, the management system can produce a complete CE configuration that can be uploaded to the node by manual operation before sending the CE to customer premise. The CE configuration will be built as for the PE. Based on the CE type (vendor/model) allocated to the customer and bearer information, the management system knows which interface must be configured on the CE. PE-CE link configuration is expected to be handled automatically using the service provider OSS as both resources are managed internally. CE to LAN interface parameters like IP addressing are derived from ip-connection taking into account how management system distributes addresses between PE and CE within the subnet. This will allow to produce a plug'n'play configuration for the CE. Litkowski, et al. Expires May 8, 2017 [Page 94] Internet-Draft l3vpn-svc-cfg November 2016 Example of generated CE configuration: interface Loopback10 description "Administration" ip address 192.0.2.1 255.255.255.255 ! interface FastEthernet10 description "WAN" ip address 198.51.100.2 255.255.255.252 <---- Comes from automated allocation ipv6 address 2001:db8::0A10:2/64 ! interface FastEthernet11 description "LAN" ip address 203.0.113.254 255.255.255.0 <---- Comes from ip-connection ipv6 address 2001:db8::1/64 ! router bgp 65000 address-family ipv4 redistribute static route-map STATIC2BGP <---- Standard SP configuration neighbor 198.51.100.1 remote-as 100 <---- Comes from automated allocation neighbor 203.0.113.2 remote-as 500 <---- Comes from ip-connection address-family ipv6 redistribute static route-map STATIC2BGP <---- Standard SP configuration neighbor 2001:db8::0A10:1 remote-as 100 <---- Comes from automated allocation neighbor 2001:db8::2 remote-as 500 <---- Comes from ip-connection ! route-map STATIC2BGP permit 10 match tag 10 ! 8. Interaction with Other YANG Modules As expressed in Section 5, this service module is intended to be instantiated in management system and not directly on network elements. It will be the role of the management system to configure the network elements. The management system may be modular, so the component instantiating the service model (let's call it service component) and Litkowski, et al. Expires May 8, 2017 [Page 95] Internet-Draft l3vpn-svc-cfg November 2016 the component responsible for network element configuration (let's call it configuration component) may be different. L3VPN-SVC | service model | | +----------------------+ | Service component | service datastore +----------------------+ | | +----------------------+ +----| Config component |-------+ / +----------------------+ \ Network / / \ \ Configuration / / \ \ models / / \ \ +++++++ ++++++++ ++++++++ +++++++ + CEA + ------- + PE A + + PE B + ----- + CEB + Config +++++++ ++++++++ ++++++++ +++++++ datastore Site A Site B In the previous sections, we provided some example of translation of service provisioning request to router configuration lines as an illustration. In the NETCONF/YANG ecosystem, it will be expected NETCONF/YANG to be used between configuration component and network elements to configure the requested service on these elements. In this framework, it is expected from standardization to also work on specific configuration YANG modelization of service components on network elements. There will be a strong relation between the abstracted view provided by this service model and the detailed configuration view that will be provided by specific configuration models for network elements. Authors of this document are expecting definition of YANG models for network elements on this non exhaustive list of items: o VRF definition including VPN policy expression. o Physical interface. o IP layer (IPv4, IPv6). o QoS: classification, profiles... Litkowski, et al. Expires May 8, 2017 [Page 96] Internet-Draft l3vpn-svc-cfg November 2016 o Routing protocols: support of configuration of all protocols listed in the document, as well as routing policies associated with these protocols. o Multicast VPN. o Network Address Translation. o ... Example of VPN site request at service level using this model: Site A static-address 203.0.113.254 203.0.113.2 24 VPNPOL1 static 198.51.100.0/30 203.0.113.2 customer-managed Litkowski, et al. Expires May 8, 2017 [Page 97] Internet-Draft l3vpn-svc-cfg November 2016 VPNPOL1 1 VPN1 any-to-any-role In the service example above, it is expected that the service component requests to the configuration component of the management system the configuration of the service elements. If we consider that service component selected a PE (PE A) as target PE for the site, the configuration component will need to push the configuration to PE A. The configuration component will use several YANG data models to define the configuration to be applied to PE A. The XML configuration of PE-A may look like this: eth0 ianaift:ethernetCsmacd Link to CEA. 203.0.113.254 24 true VRF_CustA l3vpn:vrf VRF for CustomerA 100:1546542343 Litkowski, et al. Expires May 8, 2017 [Page 98] Internet-Draft l3vpn-svc-cfg November 2016 100:1 100:1 eth0 rt:static st0 198.51.100.0/30 203.0.113.2 9. YANG Module file "ietf-l3vpn-svc@2016-11-04.yang" module ietf-l3vpn-svc { namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; prefix l3vpn-svc; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } Litkowski, et al. Expires May 8, 2017 [Page 99] Internet-Draft l3vpn-svc-cfg November 2016 organization "IETF L3SM Working Group"; contact "WG List: <mailto:l3sm@ietf.org> Editor: L3SM WG Chairs: Adrian Farrel, Qin Wu "; description "The YANG module defines a generic service configuration model for Layer 3 VPN common across all of the vendor implementations."; revision 2016-11-03 { description "Initial document"; reference "RFC XXXX"; } /* Features */ feature cloud-access { description "Allow VPN to connect to a Cloud Service provider."; } feature multicast { description "Enables multicast capabilities in a VPN"; } feature ipv4 { description "Enables IPv4 support in a VPN"; } feature ipv6 { description "Enables IPv6 support in a VPN"; } feature carrierscarrier { description "Enables support of carrier's carrier"; Litkowski, et al. Expires May 8, 2017 [Page 100] Internet-Draft l3vpn-svc-cfg November 2016 } feature extranet-vpn { description "Enables support of extranet VPNs"; } feature site-diversity { description "Enables support of site diversity constraints"; } feature encryption { description "Enables support of encryption"; } feature qos { description "Enables support of Class of Services"; } feature qos-custom { description "Enables support of custom qos profile"; } feature rtg-bgp { description "Enables support of BGP routing protocol."; } feature rtg-rip { description "Enables support of RIP routing protocol."; } feature rtg-ospf { description "Enables support of OSPF routing protocol."; } feature rtg-ospf-sham-link { description "Enables support of OSPF sham-links."; } feature rtg-vrrp { description "Enables support of VRRP routing protocol."; } feature fast-reroute { description "Enables support of Fast Reroute."; } feature bfd { description "Enables support of BFD."; Litkowski, et al. Expires May 8, 2017 [Page 101] Internet-Draft l3vpn-svc-cfg November 2016 } feature always-on { description "Enables support for always-on access constraint."; } feature requested-type { description "Enables support for requested-type access constraint."; } feature bearer-reference { description "Enables support for bearer-reference access constraint."; } /* Typedefs */ typedef svc-id { type string; description "Defining a type of service component identificators."; } typedef template-id { type string; description "Defining a type of service template identificators."; } typedef address-family { type enumeration { enum ipv4 { description "IPv4 address family"; } enum ipv6 { description "IPv6 address family"; } } description "Defining a type for address-family."; } Litkowski, et al. Expires May 8, 2017 [Page 102] Internet-Draft l3vpn-svc-cfg November 2016 /* Identities */ identity site-network-access-type { description "Base identity for site-network-access type"; } identity point-to-point { base site-network-access-type; description "Identity for point-to-point connection"; } identity multipoint { base site-network-access-type; description "Identity for multipoint connection Example : ethernet broadcast segment"; } identity placement-diversity { description "Base identity for site placement constraints"; } identity bearer-diverse { base placement-diversity; description "Identity for bearer diversity. The bearers should not use common elements."; } identity pe-diverse { base placement-diversity; description "Identity for PE diversity"; } identity pop-diverse { base placement-diversity; description "Identity for POP diversity"; } identity linecard-diverse { base placement-diversity; description "Identity for linecard diversity"; } identity same-pe { base placement-diversity; description "Identity for having sites connected Litkowski, et al. Expires May 8, 2017 [Page 103] Internet-Draft l3vpn-svc-cfg November 2016 on the same PE"; } identity same-bearer { base placement-diversity; description "Identity for having sites connected using the same bearer"; } identity customer-application { description "Base identity for customer application"; } identity web { base customer-application; description "Identity for web application (e.g. HTTP,HTTPS)"; } identity mail { base customer-application; description "Identity for mail applications"; } identity file-transfer { base customer-application; description "Identity for file transfer applications ( e.g. FTP, SFTP, ...)"; } identity database { base customer-application; description "Identity for database applications"; } identity social { base customer-application; description "Identity for social network applications"; } identity games { base customer-application; description "Identity for gaming applications"; } identity p2p { base customer-application; description "Identity for peer to peer applications"; Litkowski, et al. Expires May 8, 2017 [Page 104] Internet-Draft l3vpn-svc-cfg November 2016 } identity network-management { base customer-application; description "Identity for management applications (e.g. telnet syslog, snmp ...)"; } identity voice { base customer-application; description "Identity for voice applications"; } identity video { base customer-application; description "Identity for video conference applications"; } identity site-vpn-flavor { description "Base identity for the site VPN service flavor."; } identity site-vpn-flavor-single { base site-vpn-flavor; description "Base identity for the site VPN service flavor. Used when the site belongs to only one VPN."; } identity site-vpn-flavor-multi { base site-vpn-flavor; description "Base identity for the site VPN service flavor. Used when a logical connection of a site belongs to multiple VPNs."; } identity site-vpn-flavor-sub { base site-vpn-flavor; description "Base identity for the site VPN service flavor. Used when a site has multiple logical connections. Each of the connection may belong to different multiple VPNs."; } identity site-vpn-flavor-nni { base site-vpn-flavor; description Litkowski, et al. Expires May 8, 2017 [Page 105] Internet-Draft l3vpn-svc-cfg November 2016 "Base identity for the site VPN service flavor. Used to describe a NNI option A connection."; } identity management { description "Base identity for site management scheme."; } identity co-managed { base management; description "Base identity for comanaged site."; } identity customer-managed { base management; description "Base identity for customer managed site."; } identity provider-managed { base management; description "Base identity for provider managed site."; } identity address-allocation-type { description "Base identity for address-allocation-type for PE-CE link."; } identity provider-dhcp { base address-allocation-type; description "Provider network provides DHCP service to customer."; } identity provider-dhcp-relay { base address-allocation-type; description "Provider network provides DHCP relay service to customer."; } identity provider-dhcp-slaac { base address-allocation-type; description "Provider network provides DHCP service to customer as well as SLAAC."; } identity static-address { base address-allocation-type; description "Provider to customer addressing is static."; Litkowski, et al. Expires May 8, 2017 [Page 106] Internet-Draft l3vpn-svc-cfg November 2016 } identity slaac { base address-allocation-type; description "Use IPv6 SLAAC."; } identity site-role { description "Base identity for site type."; } identity any-to-any-role { base site-role; description "Site in a any to any IPVPN."; } identity spoke-role { base site-role; description "Spoke Site in a Hub & Spoke IPVPN."; } identity hub-role { base site-role; description "Hub Site in a Hub & Spoke IPVPN."; } identity vpn-topology { description "Base identity for VPN topology."; } identity any-to-any { base vpn-topology; description "Identity for any to any VPN topology."; } identity hub-spoke { base vpn-topology; description "Identity for Hub'n'Spoke VPN topology."; } identity hub-spoke-disjoint { base vpn-topology; description "Identity for Hub'n'Spoke VPN topology where Hubs cannot talk between each other."; Litkowski, et al. Expires May 8, 2017 [Page 107] Internet-Draft l3vpn-svc-cfg November 2016 } identity multicast-tree-type { description "Base identity for multicast tree type."; } identity ssm-tree-type { base multicast-tree-type; description "Identity for SSM tree type."; } identity asm-tree-type { base multicast-tree-type; description "Identity for ASM tree type."; } identity bidir-tree-type { base multicast-tree-type; description "Identity for BiDir tree type."; } identity multicast-rp-discovery-type { description "Base identity for rp discovery type."; } identity auto-rp { base multicast-rp-discovery-type; description "Base identity for auto-rp discovery type."; } identity static-rp { base multicast-rp-discovery-type; description "Base identity for static type."; } identity bsr-rp { base multicast-rp-discovery-type; description "Base identity for BDR discovery type."; } identity routing-protocol-type { description "Base identity for routing-protocol type."; } Litkowski, et al. Expires May 8, 2017 [Page 108] Internet-Draft l3vpn-svc-cfg November 2016 identity ospf { base routing-protocol-type; description "Identity for OSPF protocol type."; } identity bgp { base routing-protocol-type; description "Identity for BGP protocol type."; } identity static { base routing-protocol-type; description "Identity for static routing protocol type."; } identity rip { base routing-protocol-type; description "Identity for RIP protocol type."; } identity vrrp { base routing-protocol-type; description "Identity for VRRP protocol type. This is to be used when LAn are directly connected to provider Edge routers."; } identity direct { base routing-protocol-type; description "Identity for direct protocol type. ."; } identity protocol-type { description "Base identity for protocol field type."; } identity tcp { base protocol-type; description "TCP protocol type."; Litkowski, et al. Expires May 8, 2017 [Page 109] Internet-Draft l3vpn-svc-cfg November 2016 } identity udp { base protocol-type; description "UDP protocol type."; } identity icmp { base protocol-type; description "icmp protocol type."; } identity icmp6 { base protocol-type; description "icmp v6 protocol type."; } identity gre { base protocol-type; description "GRE protocol type."; } identity ipip { base protocol-type; description "IPinIP protocol type."; } identity hop-by-hop { base protocol-type; description "Hop by Hop IPv6 header type."; } identity routing { base protocol-type; description "Routing IPv6 header type."; } identity esp { base protocol-type; description "ESP header type."; } identity ah { base protocol-type; description "AH header type."; } Litkowski, et al. Expires May 8, 2017 [Page 110] Internet-Draft l3vpn-svc-cfg November 2016 /* Groupings */ grouping vpn-service-cloud-access { container cloud-accesses { if-feature cloud-access; list cloud-access { key cloud-identifier; leaf cloud-identifier { type string; description "Identification of cloud service. Local admin meaning."; } choice list-flavor { case permit-any { leaf permit-any { type empty; description "Allow all sites."; } } case deny-any-except { leaf-list permit-site { type leafref { path "/l3vpn-svc/sites/site/site-id"; } description "Site ID to be authorized."; } } case permit-any-except { leaf-list deny-site { type leafref { path "/l3vpn-svc/sites/site/site-id"; } description "Site ID to be denied."; } } description "Choice for cloud access policy."; } Litkowski, et al. Expires May 8, 2017 [Page 111] Internet-Draft l3vpn-svc-cfg November 2016 container authorized-sites { list authorized-site { key site-id; leaf site-id { type leafref { path "/l3vpn-svc/sites/site/site-id"; } description "Site ID."; } description "List of authorized sites."; } description "Configuration of authorized sites"; } container denied-sites { list denied-site { key site-id; leaf site-id { type leafref { path "/l3vpn-svc/sites/site/site-id"; } description "Site ID."; } description "List of denied sites."; } description "Configuration of denied sites"; } container address-translation { container nat44 { leaf enabled { type boolean; default false; description "Control if address translation is required or not."; } leaf nat44-customer-address { type inet:ipv4-address; must "../enabled = 'true'" { description "Applicable only if Litkowski, et al. Expires May 8, 2017 [Page 112] Internet-Draft l3vpn-svc-cfg November 2016 address translation is enabled."; } description "Address to be used for translation. This is to be used in case customer is providing the address."; } description "IPv4 to IPv4 translation."; } description "Container for NAT"; } description "Cloud access configuration."; } description "Container for cloud access configurations"; } description "grouping for vpn cloud definition"; } grouping multicast-rp-group-cfg { choice group-format { case startend { leaf group-start { type inet:ip-address; description "First group address."; } leaf group-end { type inet:ip-address; description "Last group address."; } } case singleaddress { leaf group-address { type inet:ip-address; description "Group address"; } } description "Choice for group format."; } description Litkowski, et al. Expires May 8, 2017 [Page 113] Internet-Draft l3vpn-svc-cfg November 2016 "Definition of groups for RP to group mapping."; } grouping vpn-service-multicast { container multicast { if-feature multicast; leaf enabled { type boolean; default false; description "Enable multicast."; } container customer-tree-flavors { leaf-list tree-flavor { type identityref { base multicast-tree-type; } description "Type of tree to be used."; } description "Type of trees used by customer."; } container rp { container rp-group-mappings { list rp-group-mapping { key "id"; leaf id { type uint16; description "Unique identifier for the mapping."; } container provider-managed { leaf enabled { type boolean; default false; description "Set to true, if the RP must be a provider managed node. Set to false, if it is a customer managed node."; } leaf rp-redundancy { when "../enabled = 'true'" { description Litkowski, et al. Expires May 8, 2017 [Page 114] Internet-Draft l3vpn-svc-cfg November 2016 "Relevant when RP is provider managed."; } type boolean; default false; description "If true, redundancy mechanism for RP is required."; } leaf optimal-traffic-delivery { when "../enabled = 'true'" { description "Relevant when RP is provider managed."; } type boolean; default false; description "If true, SP must ensure that traffic uses an optimal path."; } description "Parameters for provider managed RP."; } leaf rp-address { when "../provider-managed/enabled = 'false'" { description "Relevant when RP is provider managed."; } type inet:ip-address; description "Defines the address of the RendezvousPoint. Used if RP is customer managed."; } container groups { list group { key id; leaf id { type uint16; description "Identifier for the group."; } uses multicast-rp-group-cfg; Litkowski, et al. Expires May 8, 2017 [Page 115] Internet-Draft l3vpn-svc-cfg November 2016 description "List of groups."; } description "Multicast groups associated with RP."; } description "List of RP to group mappings."; } description "RP to group mappings."; } container rp-discovery { leaf rp-discovery-type { type identityref { base multicast-rp-discovery-type; } default static-rp; description "Type of RP discovery used."; } container bsr-candidates { when "../rp-discovery-type = 'bsr-rp'" { description "Only applicable if discovery type is BSR-RP"; } leaf-list bsr-candidate-address { type inet:ip-address; description "Address of BSR candidate"; } description "Customer BSR candidates address"; } description "RP discovery parameters"; } description "RendezvousPoint parameters."; } description "Multicast global parameters for the VPN service."; } description "grouping for multicast vpn definition"; Litkowski, et al. Expires May 8, 2017 [Page 116] Internet-Draft l3vpn-svc-cfg November 2016 } grouping vpn-service-mpls { leaf carrierscarrier { if-feature carrierscarrier; type boolean; default false; description "The VPN is using Carrier's Carrier, and so MPLS is required."; } description "grouping for mpls CsC definition"; } grouping customer-location-info { container locations { list location { key location-id; leaf location-id { type svc-id; description "Identifier for a particular location"; } leaf address { type string; description "Address (number and street) of the site."; } leaf postal-code { type string; description "Postal code of the site."; } leaf state { type string; description "State of the site. This leaf can also be used to describe a region for country who does not have states. "; } Litkowski, et al. Expires May 8, 2017 [Page 117] Internet-Draft l3vpn-svc-cfg November 2016 leaf city { type string; description "City of the site."; } leaf country-code { type string { pattern '[A-Z]{2}'; } description "Country of the site. Expressed as ISO ALPHA-2 code."; } description "Location of the site."; } description "List of locations for the site"; } description "This grouping defines customer location parameters"; } grouping site-group { container groups { list group { key group-id; leaf group-id { type string; description "Group-id the site is belonging to"; } description "List of group-id"; } description "Groups the site or site-network-access is belonging to."; } description "Grouping definition to assign group-ids to site or site-network-access"; } grouping site-diversity { Litkowski, et al. Expires May 8, 2017 [Page 118] Internet-Draft l3vpn-svc-cfg November 2016 container site-diversity { if-feature site-diversity; uses site-group; description "Diversity constraint type. Group values defined here will be inherited to all site-network-accesses."; } description "This grouping defines site diversity parameters"; } grouping access-diversity { container access-diversity { if-feature site-diversity; uses site-group; container constraints { list constraint { key constraint-type; leaf constraint-type { type identityref { base placement-diversity; } description "Diversity constraint type."; } container target { choice target-flavor { case id { list group { key group-id; leaf group-id { type string; description "The constraint will apply against this particular group-id"; } description "List of groups"; } } case all-accesses { Litkowski, et al. Expires May 8, 2017 [Page 119] Internet-Draft l3vpn-svc-cfg November 2016 leaf all-other-accesses { type empty; description "The constraint will apply against all other site network access of this site"; } } case all-groups { leaf all-other-groups { type empty; description "The constraint will apply against all other groups the customer is managing"; } } description "Choice for the group definition"; } description "The constraint will apply against this list of groups"; } description "List of constraints"; } description "Constraints for placing this site network access"; } description "Diversity parameters."; } description "This grouping defines access diversity parameters"; } grouping operational-requirements { leaf requested-site-start { type yang:date-and-time; description "Optional leaf indicating requested date and time Litkowski, et al. Expires May 8, 2017 [Page 120] Internet-Draft l3vpn-svc-cfg November 2016 when the service at a particular site is expected to start"; } leaf requested-site-stop { type yang:date-and-time; description "Optional leaf indicating requested date and time when the service at a particular site is expected to stop"; } description "This grouping defines some operational parameters parameters"; } grouping operational-requirements-ops { leaf actual-site-start { type yang:date-and-time; config false; description "Optional leaf indicating actual date and time when the service at a particular site actually started"; } leaf actual-site-stop { type yang:date-and-time; config false; description "Optional leaf indicating actual date and time when the service at a particular site actually stopped"; } description "This grouping defines some operational parameters parameters"; } grouping flow-definition { container match-flow { leaf dscp { type inet:dscp; Litkowski, et al. Expires May 8, 2017 [Page 121] Internet-Draft l3vpn-svc-cfg November 2016 description "DSCP value."; } leaf dot1p { type uint8 { range "0 .. 7"; } description "802.1p matching."; } leaf ipv4-src-prefix { type inet:ipv4-prefix; description "Match on IPv4 src address."; } leaf ipv6-src-prefix { type inet:ipv6-prefix; description "Match on IPv6 src address."; } leaf ipv4-dst-prefix { type inet:ipv4-prefix; description "Match on IPv4 dst address."; } leaf ipv6-dst-prefix { type inet:ipv6-prefix; description "Match on IPv6 dst address."; } leaf l4-src-port { type inet:port-number; description "Match on layer 4 src port."; } leaf-list target-sites { type svc-id; description "Identify a site as traffic destination."; } container l4-src-port-range { leaf lower-port { type inet:port-number; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; Litkowski, et al. Expires May 8, 2017 [Page 122] Internet-Draft l3vpn-svc-cfg November 2016 must ". >= ../lower-port" { description "Upper boundary must be higher than lower boundary"; } description "Upper boundary for port."; } description "Match on layer 4 src port range."; } leaf l4-dst-port { type inet:port-number; description "Match on layer 4 dst port."; } container l4-dst-port-range { leaf lower-port { type inet:port-number; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; must ". >= ../lower-port" { description "Upper boundary must be higher than lower boundary"; } description "Upper boundary for port."; } description "Match on layer 4 dst port range."; } leaf protocol-field { type union { type uint8; type identityref { base protocol-type; } } description "Match on IPv4 protocol or Ipv6 Next Header field."; } Litkowski, et al. Expires May 8, 2017 [Page 123] Internet-Draft l3vpn-svc-cfg November 2016 description "Describe flow matching criterions."; } description "Flow definition based on criteria."; } grouping site-service-basic { leaf svc-input-bandwidth { type uint32; units bps; description "From the PE perspective, the service input bandwidth of the connection."; } leaf svc-output-bandwidth { type uint32; units bps; description "From the PE perspective, the service output bandwidth of the connection."; } leaf svc-mtu { type uint16; units bytes; description "MTU at service level. If the service is IP, it refers to the IP MTU."; } description "Defines basic service parameters for a site."; } grouping site-protection { container traffic-protection { if-feature fast-reroute; leaf enabled { type boolean; default false; description "Enables traffic protection of access link."; } description "Fast reroute service parameters for the site."; } description Litkowski, et al. Expires May 8, 2017 [Page 124] Internet-Draft l3vpn-svc-cfg November 2016 "Defines protection service parameters for a site."; } grouping site-service-mpls { container carrierscarrier { if-feature carrierscarrier; leaf signalling-type { type enumeration { enum "ldp" { description "Use LDP as signalling protocol between PE and CE."; } enum "bgp" { description "Use BGP 3107 as signalling protocol between PE and CE. In this case, bgp must be also configured as routing-protocol. "; } } description "MPLS signalling type."; } description "This container is used when customer provides MPLS based services. This is used in case of Carrier's Carrier."; } description "Defines MPLS service parameters for a site."; } grouping site-service-qos-profile { container qos { if-feature qos; container qos-classification-policy { list rule { key id; ordered-by user; leaf id { type uint16; description "ID of the rule."; } Litkowski, et al. Expires May 8, 2017 [Page 125] Internet-Draft l3vpn-svc-cfg November 2016 choice match-type { case match-flow { uses flow-definition; } case match-application { leaf match-application { type identityref { base customer-application; } description "Defines the application to match."; } } description "Choice for classification"; } leaf target-class-id { type string; description "Identification of the class of service. This identifier is internal to the administration."; } description "List of marking rules."; } description "Need to express marking rules ..."; } container qos-profile { choice qos-profile { description "Choice for QoS profile. Can be standard profile or custom."; case standard { leaf profile { type string; description "QoS profile to be used"; } } case custom { container classes { Litkowski, et al. Expires May 8, 2017 [Page 126] Internet-Draft l3vpn-svc-cfg November 2016 if-feature qos-custom; list class { key class-id; leaf class-id { type string; description "Identification of the class of service. This identifier is internal to the administration."; } leaf rate-limit { type uint8; units percent; description "To be used if class must be rate limited. Expressed as percentage of the svc-bw."; } container latency { choice flavor { case lowest { leaf use-lowest-latency { type empty; description "The traffic class should use the lowest latency path"; } } case boundary { leaf latency-boundary { type uint16; units msec; description "The traffic class should use a path with a defined maximum latency."; } } description "Latency constraint on the traffic class"; } description "Latency constraint on the traffic class"; Litkowski, et al. Expires May 8, 2017 [Page 127] Internet-Draft l3vpn-svc-cfg November 2016 } container jitter { choice flavor { case lowest { leaf use-lowest-jitter { type empty; description "The traffic class should use the lowest jitter path"; } } case boundary { leaf latency-boundary { type uint32; units usec; description "The traffic class should use a path with a defined maximum jitter."; } } description "Jitter constraint on the traffic class"; } description "Jitter constraint on the traffic class"; } container bandwidth { leaf guaranteed-bw-percent { type uint8; units percent; description "To be used to define the guaranteed BW in percent of the svc-bw available."; } leaf end-to-end { type empty; description "Used if the bandwidth reservation must be done on the MPLS network too"; } description "Bandwidth constraint on the traffic class"; Litkowski, et al. Expires May 8, 2017 [Page 128] Internet-Draft l3vpn-svc-cfg November 2016 } description "List of class of services."; } description "Container for list of class of services."; } } } description "Qos profile configuration."; } description "QoS configuration."; } description "This grouping defines QoS parameters for a site"; } grouping site-security-authentication { container authentication { description "Authentication parameters"; } description "This grouping defines authentication parameters for a site"; } grouping site-security-encryption { container encryption { if-feature encryption; leaf enabled { type boolean; default false; description "If true, access encryption is required."; } leaf layer { type enumeration { enum layer2 { description Litkowski, et al. Expires May 8, 2017 [Page 129] Internet-Draft l3vpn-svc-cfg November 2016 "Encryption will occur at layer 2."; } enum layer3 { description "Encryption will occur at layer 3. IPSec may be used as example."; } } mandatory true; description "Layer on which encryption is applied."; } container encryption-profile { choice profile { case provider-profile { leaf profile-name { type string; description "Name of the SP profile to be applied."; } } case customer-profile { leaf algorithm { type string; description "Encryption algorithm to be used."; } choice key-type { case psk { leaf preshared-key { type string; description "Key coming from customer."; } } case pki { } description "Type of keys to be used."; } } description "Choice of profile."; } Litkowski, et al. Expires May 8, 2017 [Page 130] Internet-Draft l3vpn-svc-cfg November 2016 description "Profile of encryption to be applied."; } description "Encryption parameters."; } description "This grouping defines encryption parameters for a site"; } grouping site-attachment-bearer { container bearer { container requested-type { if-feature requested-type; leaf requested-type { type string; description "Type of requested bearer Ethernet, DSL, Wireless ... Operator specific."; } leaf strict { type boolean; default false; description "define if the requested-type is a preference or a strict requirement."; } description "Container for requested type."; } leaf always-on { if-feature always-on; type boolean; default true; description "Request for an always on access type. This means no Dial access type for example."; } leaf bearer-reference { if-feature bearer-reference; type string; description "This is an internal reference for the service provider. Litkowski, et al. Expires May 8, 2017 [Page 131] Internet-Draft l3vpn-svc-cfg November 2016 Used "; } description "Bearer specific parameters. To be augmented."; } description "Defines physical properties of a site attachment."; } grouping site-routing { container routing-protocols { list routing-protocol { key type; leaf type { type identityref { base routing-protocol-type; } description "Type of routing protocol."; } container ospf { when "../type = 'ospf'" { description "Only applies when protocol is OSPF."; } if-feature rtg-ospf; leaf-list address-family { type address-family; description "Address family to be activated."; } leaf area-address { type yang:dotted-quad; description "Area address."; } leaf metric { type uint16; description "Metric of PE-CE link."; } Litkowski, et al. Expires May 8, 2017 [Page 132] Internet-Draft l3vpn-svc-cfg November 2016 container sham-links { if-feature rtg-ospf-sham-link; list sham-link { key target-site; leaf target-site { type svc-id; description "Target site for the sham link connection. The site is referred through it's ID."; } leaf metric { type uint16; description "Metric of the sham link."; } description "Creates a shamlink with another site"; } description "List of Sham links"; } description "OSPF specific configuration."; } container bgp { when "../type = 'bgp'" { description "Only applies when protocol is BGP."; } if-feature rtg-bgp; leaf autonomous-system { type uint32; description "AS number."; } leaf-list address-family { type address-family; description "Address family to be activated."; } description Litkowski, et al. Expires May 8, 2017 [Page 133] Internet-Draft l3vpn-svc-cfg November 2016 "BGP specific configuration."; } container static { when "../type = 'static'" { description "Only applies when protocol is static."; } container cascaded-lan-prefixes { list ipv4-lan-prefixes { if-feature ipv4; key "lan next-hop"; leaf lan { type inet:ipv4-prefix; description "Lan prefixes."; } leaf lan-tag { type string; description "Internal tag to be used in vpn policies."; } leaf next-hop { type inet:ipv4-address; description "Nexthop address to use at customer side."; } description " List of LAN prefixes for the site. "; } list ipv6-lan-prefixes { if-feature ipv6; key "lan next-hop"; leaf lan { type inet:ipv6-prefix; description "Lan prefixes."; } leaf lan-tag { type string; description Litkowski, et al. Expires May 8, 2017 [Page 134] Internet-Draft l3vpn-svc-cfg November 2016 "Internal tag to be used in vpn policies."; } leaf next-hop { type inet:ipv6-address; description "Nexthop address to use at customer side."; } description " List of LAN prefixes for the site. "; } description "LAN prefixes from the customer."; } description "Static routing specific configuration."; } container rip { when "../type = 'rip'" { description "Only applies when protocol is RIP."; } if-feature rtg-rip; leaf-list address-family { type address-family; description "Address family to be activated."; } description "RIP routing specific configuration."; } container vrrp { when "../type = 'vrrp'" { description "Only applies when protocol is VRRP."; Litkowski, et al. Expires May 8, 2017 [Page 135] Internet-Draft l3vpn-svc-cfg November 2016 } if-feature rtg-vrrp; leaf-list address-family { type address-family; description "Address family to be activated."; } description "VRRP routing specific configuration."; } description "List of routing protocols used on the site. Need to be augmented."; } description "Defines routing protocols."; } description "Grouping for routing protocols."; } grouping site-attachment-ip-connection { container ip-connection { container ipv4 { if-feature ipv4; leaf address-allocation-type { type identityref { base address-allocation-type; } default "static-address"; description "Defines how addresses are allocated. "; } leaf number-of-dynamic-address { when "../address-allocation-type = 'provider-dhcp'" { description "Only applies when addresses are dhcp allocated"; } type uint8; Litkowski, et al. Expires May 8, 2017 [Page 136] Internet-Draft l3vpn-svc-cfg November 2016 default 1; description "Describes the number of IP addresses the customer requires"; } container dhcp-relay { when "../address-allocation-type = 'provider-dhcp-relay'" { description "Only applies when provider is required to implementations DHCP relay function"; } container customer-dhcp-servers { leaf-list server-ip-address { type inet:ipv4-address; description "IP address of customer DHCP server"; } description "Container for list of customer DHCP server"; } description "DHCP relay provided by operator."; } container addresses { when "../address-allocation-type = 'static-address'" { description "Only applies when protocol allocation type is static"; } leaf provider-address { type inet:ipv4-address; description "Provider side address."; } leaf customer-address { type inet:ipv4-address; description "Customer side address."; } leaf mask { type uint8 { range "0..31"; } description Litkowski, et al. Expires May 8, 2017 [Page 137] Internet-Draft l3vpn-svc-cfg November 2016 "Subnet mask expressed in bits"; } description "Describes IP addresses used"; } description "IPv4 specific parameters"; } container ipv6 { if-feature ipv6; leaf address-allocation-type { type identityref { base address-allocation-type; } default "static-address"; description "Defines how addresses are allocated. "; } leaf number-of-dynamic-address { when "../address-allocation-type = 'provider-dhcp' "+ "or ../address-allocation-type "+ "= 'provider-dhcp-slaac'" { description "Only applies when addresses are dhcp allocated"; } type uint8; default 1; description "Describes the number of IP addresses the customer requires"; } container dhcp-relay { when "../address-allocation-type = 'provider-dhcp-relay'" { description "Only applies when provider is required to implementations DHCP relay function"; } container customer-dhcp-servers { Litkowski, et al. Expires May 8, 2017 [Page 138] Internet-Draft l3vpn-svc-cfg November 2016 leaf-list server-ip-address { type inet:ipv6-address; description "IP address of customer DHCP server"; } description "Container for list of customer DHCP server"; } description "DHCP relay provided by operator."; } container addresses { when "../address-allocation-type = 'static-address'" { description "Only applies when protocol allocation type is static"; } leaf provider-address { type inet:ipv6-address; description "Provider side address."; } leaf customer-address { type inet:ipv6-address; description "Customer side address."; } leaf mask { type uint8 { range "0..127"; } description "Subnet mask expressed in bits"; } description "Describes IP addresses used"; } description "IPv6 specific parameters"; } container oam { container bfd { if-feature bfd; leaf enabled { Litkowski, et al. Expires May 8, 2017 [Page 139] Internet-Draft l3vpn-svc-cfg November 2016 type boolean; default false; description "BFD activation"; } choice holdtime { case profile { leaf profile-name { type string; description "Service provider well known profile."; } description "Service provider well known profile."; } case fixed { leaf fixed-value { type uint32; units msec; description "Expected holdtime expressed in msec."; } } description "Choice for holdtime flavor."; } description "Container for BFD."; } description "Define the OAM used on the connection."; } description "Defines connection parameters."; } description "This grouping defines IP connection parameters."; } grouping site-service-multicast { container multicast { if-feature multicast; leaf multicast-site-type { Litkowski, et al. Expires May 8, 2017 [Page 140] Internet-Draft l3vpn-svc-cfg November 2016 type enumeration { enum receiver-only { description "The site has only receivers."; } enum source-only { description "The site has only sources."; } enum source-receiver { description "The site has both sources & receivers."; } } default "source-receiver"; description "Type of multicast site."; } container multicast-address-family { leaf ipv4 { if-feature ipv4; type boolean; default true; description "Enables ipv4 multicast"; } leaf ipv6 { if-feature ipv6; type boolean; default false; description "Enables ipv6 multicast"; } description "Defines protocol to carry multicast."; } leaf protocol-type { type enumeration { enum host { description " Hosts are directly connected to the provider network. Host protocols like IGMP, MLD are required. "; } Litkowski, et al. Expires May 8, 2017 [Page 141] Internet-Draft l3vpn-svc-cfg November 2016 enum router { description " Hosts are behind a customer router. PIM will be implemented. "; } enum both { description "Some Hosts are behind a customer router and some others are directly connected to the provider network. Both host and routing protocols must be used. Typically IGMP and PIM will be implemented. "; } } default "both"; description "Multicast protocol type to be used with the customer site."; } description "Multicast parameters for the site."; } description "Multicast parameters for the site."; } grouping site-management { container management { leaf type { type identityref { base management; } description "Management type of the connection."; } description "Management configuration"; } description "Management parameters for the site."; } grouping site-devices { Litkowski, et al. Expires May 8, 2017 [Page 142] Internet-Draft l3vpn-svc-cfg November 2016 container devices { must "/l3vpn-svc/sites/site/management/type = "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type ="+ "'co-managed'" { description "Applicable only for provider-managed or co-managed device"; } list device { key device-id; leaf device-id { type svc-id; description "identifier for the device"; } leaf location { type leafref { path "/l3vpn-svc/sites/site/locations/"+ "location/location-id"; } description "Location of the device"; } container management { must "/l3vpn-svc/sites/site/management/type"+ "= 'co-managed'" { description "Applicable only for co-managed device"; } leaf address-family { type address-family; description "Address family used for management."; } leaf address { type inet:ip-address; description "Management address"; } description "Management configuration. Only for co-managed case."; } description Litkowski, et al. Expires May 8, 2017 [Page 143] Internet-Draft l3vpn-svc-cfg November 2016 "Device configuration"; } description "List of devices requested by customer"; } description "Grouping for device allocation"; } grouping site-vpn-flavor { leaf site-vpn-flavor { type identityref { base site-vpn-flavor; } default site-vpn-flavor-single; description "Defines if the site is a single VPN site, or multiVPN or ..."; } description "Grouping for site-vpn-flavor."; } grouping site-vpn-policy { container vpn-policies { list vpn-policy { key vpn-policy-id; leaf vpn-policy-id { type svc-id; description "Unique identifier for the VPN policy."; } list entries { key id; leaf id { type svc-id; description "Unique identifier for the policy entry."; } container filter { choice lan { case prefixes { leaf-list ipv4-lan-prefix { if-feature ipv4; Litkowski, et al. Expires May 8, 2017 [Page 144] Internet-Draft l3vpn-svc-cfg November 2016 type inet:ipv4-prefix; description "List of IPv4 prefixes to be matched."; } leaf-list ipv6-lan-prefix { if-feature ipv6; type inet:ipv6-prefix; description "List of IPv6 prefixes to be matched."; } } case lan-tag { leaf-list lan-tag { type string; description "List of lan-tags to be matched."; } } description "Choice for LAN matching type"; } description "If used, it permit to split site LANs among multiple VPNs. If no filter used, all the LANs will be part of the same VPNs with the same role."; } container vpn { leaf vpn-id { type leafref { path "/l3vpn-svc/vpn-services/" +"vpn-service/vpn-id"; } mandatory true; description "Reference to an IPVPN."; } leaf site-role { type identityref { base site-role; } default any-to-any-role; description "Role of the site in the IPVPN."; } Litkowski, et al. Expires May 8, 2017 [Page 145] Internet-Draft l3vpn-svc-cfg November 2016 description "List of VPNs the LAN is associated to."; } description "List of entries for export policy."; } description "List of VPN policies."; } description "VPN policy."; } description "VPN policy parameters for the site."; } grouping site-maximum-routes { container maximum-routes { list address-family { key af; leaf af { type address-family; description "Address-family."; } leaf maximum-routes { type uint32; description "Maximum prefixes the VRF can accept for this address-family."; } description "List of address families."; } description "Define maximum-routes for the VRF."; } description "Define maximum-routes for the site."; } grouping site-security { Litkowski, et al. Expires May 8, 2017 [Page 146] Internet-Draft l3vpn-svc-cfg November 2016 container security { uses site-security-authentication; uses site-security-encryption; description "Site specific security parameters."; } description "Grouping for security parameters."; } grouping site-service { container service { uses site-service-qos-profile; uses site-service-mpls; uses site-service-multicast; description "Service parameters on the attachement."; } description "Grouping for service parameters."; } grouping site-network-access-service { container service { uses site-service-basic; uses site-service-qos-profile; uses site-service-mpls; uses site-service-multicast; description "Service parameters on the attachement."; } description "Grouping for service parameters."; } grouping vpn-extranet { container extranet-vpns { if-feature extranet-vpn; list extranet-vpn { key vpn-id; leaf vpn-id { type svc-id; description "Identifies the target VPN"; Litkowski, et al. Expires May 8, 2017 [Page 147] Internet-Draft l3vpn-svc-cfg November 2016 } leaf local-sites-role { type identityref { base site-role; } default any-to-any-role; description "This describes the role of the local sites in the target VPN topology."; } description "List of extranet VPNs the local VPN is attached to."; } description "Container for extranet vpn cfg."; } description "grouping for extranet VPN configuration. Extranet provides a way to interconnect all sites from two VPNs in a easy way."; } grouping site-attachment-availability { container availability { leaf access-priority { type uint32; default 1; description "Defines the priority for the access. The highest the priority value is, the highest the preference of the access is."; } description "Availability parameters (used for multihoming)"; } description "Defines site availability parameters."; } grouping access-vpn-policy { container vpn-attachment { choice attachment-flavor { Litkowski, et al. Expires May 8, 2017 [Page 148] Internet-Draft l3vpn-svc-cfg November 2016 case vpn-policy-id { leaf vpn-policy-id { type leafref { path "/l3vpn-svc/sites/site/"+ "vpn-policies/vpn-policy/"+ "vpn-policy-id"; } description "Reference to a VPN policy."; } } case vpn-id { leaf vpn-id { type leafref { path "/l3vpn-svc/vpn-services"+ "/vpn-service/vpn-id"; } description "Reference to a VPN."; } leaf site-role { type identityref { base site-role; } default any-to-any-role; description "Role of the site in the IPVPN."; } } mandatory true; description "Choice for VPN attachment flavor."; } description "Defines VPN attachment of a site."; } description "Defines the VPN attachment rules for a site logical access."; } grouping vpn-svc-cfg { leaf vpn-id { type svc-id; description "VPN identifier. Local administration meaning."; } leaf customer-name { Litkowski, et al. Expires May 8, 2017 [Page 149] Internet-Draft l3vpn-svc-cfg November 2016 type string; description "Name of the customer."; } leaf vpn-service-topology { type identityref { base vpn-topology; } default "any-to-any"; description "VPN service topology."; } uses vpn-service-cloud-access; uses vpn-service-multicast; uses vpn-service-mpls; uses vpn-extranet; description "grouping for vpn-svc configuration."; } grouping site-top-level-cfg { uses operational-requirements; uses customer-location-info; uses site-devices; uses site-diversity; uses site-management; uses site-vpn-policy; uses site-vpn-flavor; uses site-maximum-routes; uses site-security; uses site-service; uses site-protection; uses site-routing; description "Grouping for site top level cfg."; } grouping site-network-access-top-level-cfg { leaf site-network-access-type { type identityref { base site-network-access-type; } default "point-to-point"; description "Describes the type of connection, e.g. : point-to-point or multipoint"; Litkowski, et al. Expires May 8, 2017 [Page 150] Internet-Draft l3vpn-svc-cfg November 2016 } choice location-flavor { case location { when "/l3vpn-svc/sites/site/management/type = "+ "'customer-managed'" { description "Applicable only for customer-managed"; } leaf location-reference { type leafref { path "/l3vpn-svc/sites/site/locations/"+ "location/location-id"; } description "Location of the site-network-access"; } } case device { when "/l3vpn-svc/sites/site/management/type = "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type = "+ "'co-managed'" { description "Applicable only for provider-managed or co-managed device"; } leaf device-reference { type leafref { path "/l3vpn-svc/sites/site/devices/"+ "device/device-id"; } description "Identifier of CE to use"; } } mandatory true; description "Choice on how to describe the site location"; } uses access-diversity; uses site-attachment-bearer; uses site-attachment-ip-connection; uses site-security; uses site-network-access-service; uses site-routing; uses site-attachment-availability; Litkowski, et al. Expires May 8, 2017 [Page 151] Internet-Draft l3vpn-svc-cfg November 2016 uses access-vpn-policy; description "Grouping for site network access top level cfg."; } /* Main blocks */ container l3vpn-svc { container vpn-services { list vpn-service { key vpn-id; uses vpn-svc-cfg; description " List of VPN services. "; } description "top level container for the VPN services."; } container sites { list site { key site-id; leaf site-id { type svc-id; description "Identifier of the site."; } uses site-top-level-cfg; uses operational-requirements-ops; container site-network-accesses { list site-network-access { key site-network-access-id; leaf site-network-access-id { type svc-id; description "Identifier for the access"; } uses site-network-access-top-level-cfg; Litkowski, et al. Expires May 8, 2017 [Page 152] Internet-Draft l3vpn-svc-cfg November 2016 description "List of accesses for a site."; } description "List of accesses for a site."; } description "List of sites."; } description "Container for sites"; } description "Main container for L3VPN service configuration."; } } 10. Security Considerations The YANG modules defined in this document MAY be accessed via the RESTCONF protocol [I-D.ietf-netconf-restconf] or NETCONF protocol ([RFC6241]. The lowest RESTCONF or NETCONF layer requires that the transport-layer protocol provides both data integrity and confidentiality, see Section 2 in [I-D.ietf-netconf-restconf] and [RFC6241]. The client MUST carefully examine the certificate presented by the server to determine if it meets the client's expectations, and the server MUST authenticate client access to any protected resource. The client identity derived from the authentication mechanism used is subject to the NETCONF Access Control Module (NACM) ([RFC6536]). Other protocols to access this YANG module are also required to support the similar mechanism. The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be carefully created/read/updated/deleted. The entries in the lists below include customer proprietary or confidential information, therefore only authorized clients MUST access the information and the other clients MUST NOT be able to access the information. o /l3vpn-svc/vpn-services/vpn-service o /l3vpn-svc/sites/site Litkowski, et al. Expires May 8, 2017 [Page 153] Internet-Draft l3vpn-svc-cfg November 2016 The data model proposes some security parameters than can be extended by augmentation as part of the customer service request: those parameters are described in Section 6.9. 11. Contribution Authors would like to thank Rob Shakir for his major contribution on the initial modeling and use cases. 12. Acknowledgements Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang, Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe Landry and Andrew Leu for the contributions to the document. 13. IANA Considerations IANA is requested to assign a new URI from the IETF XML registry ([RFC3688]). Authors are suggesting the following URI: ID: yang:ietf-l3vpn-svc URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc Filename: [ TBD-at-registration ] Reference: [ RFC-to-be ] Registrant Contact: L3SM WG XML: N/A, the requested URI is an XML namespace This document also requests a new YANG module name in the YANG Module Names registry ([RFC7950]) with the following suggestion: Name: ietf-l3vpn-svc Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc Prefix: l3vpn-svc Module: Reference: [ RFC-to-be ] 14. Change Log 14.1. Changes between versions -18 and-19 o Country code string pattern enforced to ISO ALPHA-2 code. o zip-code renamed to postal-code. o Added new address-allocation-type: provider-dhcp-slaac. Litkowski, et al. Expires May 8, 2017 [Page 154] Internet-Draft l3vpn-svc-cfg November 2016 o Removed transport-constraints and include transport constraints (jitter,latency, bandwidth) in the qos-profile. o qos-profile simplified with more abstraction. o added target-sites in flow-definition. 14.2. Changes between versions -17 and-18 o Removed TOS from flow matching. 14.3. Changes between versions -16 and-17 o Renamed "vpn-svc" list to "vpn-service". o Renamed "vpn-policy-list" to "vpn-policies". o Renamed "management-transport" to "address-family". o Renamed "multicast-transport" to "address-family". o Modified cloud access policy using a choice. o any-to-any-role as default site-role. o "address-family" is now an enumeration instead of identity. o cloud-access feature moved to container level. o Added "address-translation" container for cloud-access. o Renamed "customer-nat-address" to "customer-address". o New type ip:address for "customer-address". o "tree-flavor" moved to leaf-list. o "bsr-candidate" list moved to "bsr-candidate-address" leaf-list. o layer becomes mandatory in security-encryption. o ip-subnet mask range modified. o multicast transport constraint destination moved to leaf-list. o lan-prefixes in vpn-policy moved to leaf-list ang tag has been renamed "prefixes". Litkowski, et al. Expires May 8, 2017 [Page 155] Internet-Draft l3vpn-svc-cfg November 2016 o Added source and destination port range in QoS classification. o QoS classification uses more existing inet:types. o Grouping defined for site group list. 14.4. Changes between versions -15 and-16 o Rename "topology" leaf to "vpn-service-topology". 14.5. Changes between versions -13 and-14 o Choice between device reference and location reference. 14.6. Changes between versions -12 and-13 o Removed rip-ng identity (rip container has AF information) o renamed pe-dhcp to provider-dhcp o add provider-dhcp-relay identity and container o BW/MTU is now only under site-network-access o Add list of location and location ID o Site-network-access mapped to location Identifier o Add list of devices (provided by operator) requested by customer o Some management parameters moved under device list o Site-network-access mapped to device identifier 14.7. Changes between versions -11 and-12 o Fixing some 'when' statements that prevented compilation. 14.8. Changes between versions -09 and-10 o Removed templates. o Add site-network-access-type. o Add a leaf number-of-dynamic-address in case of pe-dhcp addressing. Litkowski, et al. Expires May 8, 2017 [Page 156] Internet-Draft l3vpn-svc-cfg November 2016 14.9. Changes between versions -08 and-09 o Add site-vpn-flavor NNI. 14.10. Changes between versions -07 and-08 o Traffic protection moved to site level. o Decouple operational-requirements in two containers. 14.11. Changes between versions -06 and-07 o Set config false to actual-site-start and stop. o Add a container before cloud-access list. o Add a container before authorized-sites list. o Add a container before denied-sites list. o Modified access-diversity modeling. o Replacing type placement diversity by an identity. 14.12. Changes between versions -05 and-06 o Added linecard diverse for site diversity o Added a new diversity enum in placement-diversity: none o Added state to site location o remove reference to core routing model: created new address family identities o added features o Modified bearer parameters o Modified union for ipv4/ipv6 addresses to ip-address type o Add BSR parameters for multicast o Add applications matching for QoS classification Litkowski, et al. Expires May 8, 2017 [Page 157] Internet-Draft l3vpn-svc-cfg November 2016 14.13. Changes between versions -04 and-05 o Modify VPN policy and creating a vpn-policy-list o Add VPN policy reference and VPN ID reference under site-network- access 14.14. Changes between versions -02 and-03 o Add extranet-vpn container in vpn-svc o Creating top level containers o Refine groupings o Added site-vpn-flavor o qos-profile moved to choice o vpn leaf moved to vpn-id in vpn-policy o added ordered-by user to qos classification list o moved traffic protection to access availability o creating a choice in matching filter for VPN policy o added dot1p matching field in flow-definition 14.15. Changes between versions -01 and-02 o A site is now a collection of site-accesses. This was introduced to support M to N availability. o Site-availability has been removed, replaced by availability parameters under site-accesses o Added transport-constraints within vpn-svc o Add ToS support in match-flow o nexthop in cascaded lan as mandatory o customer-specific-info deleted and moved to routing protocols o customer-lan-connection modified: need prefix and CE address o add choice in managing PE-CE addressing Litkowski, et al. Expires May 8, 2017 [Page 158] Internet-Draft l3vpn-svc-cfg November 2016 o Simplifying traffic protection o Refine groupings for vpn-svc o Removed name in vpn-svc o id in vpn-svc moved to string o Rename id in vpn-svc to vpn-id o Changed key of vpn-svc list to vpn-id o Add DSCP support in flow definition o Removed ACL from security o Add FW for site and cloud access 14.16. Changes between versions -00 and-01 o Creating multiple reusable groupings o Added mpls leaf in vpn-svc for carrier's carrier case o Modify identity single to single-site o Modify site-type to site-role and also child identities. o Creating OAM container under site and moved BFD in. o Creating flow-definition grouping to be reused in ACL, QoS ... o Simplified VPN policy. o Adding multicast static group to RP mappings. o Removed native-vpn and site-role from global site cfg, now managed within the VPN policy. o Creating a separate list for site templates. 15. References 15.1. Normative References Litkowski, et al. Expires May 8, 2017 [Page 159] Internet-Draft l3vpn-svc-cfg November 2016 [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/ RFC4862, September 2007, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . Litkowski, et al. Expires May 8, 2017 [Page 160] Internet-Draft l3vpn-svc-cfg November 2016 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . 15.2. Informative References [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, DOI 10.17487/RFC4110, July 2005, . Authors' Addresses Stephane Litkowski Orange Business Services Email: stephane.litkowski@orange.com Luis Tomotaki Verizon Email: luis.tomotaki@verizon.com Kenichi Ogaki KDDI Email: ke-oogaki@kddi.com Litkowski, et al. Expires May 8, 2017 [Page 161] ./draft-ietf-6man-default-iids-16.txt0000664000764400076440000004602312773016002016575 0ustar iustyiusty IPv6 maintenance Working Group (6man) F. Gont Internet-Draft SI6 Networks / UTN-FRH Updates: 2464, 2467, 2470, 2491, 2492, A. Cooper 2497, 2590, 3146, 3572, 4291, Cisco 4338, 4391, 5072, 5121 (if D. Thaler approved) Microsoft Intended status: Standards Track W. Liu Expires: March 29, 2017 Huawei Technologies September 28, 2016 Recommendation on Stable IPv6 Interface Identifiers draft-ietf-6man-default-iids-16 Abstract This document changes the recommended default IID generation scheme for cases where SLAAC is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 21, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Gont, et al. Expires March 29, 2017 [Page 1] Internet-Draft Default Interface-IDs September 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 4 4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460], which typically results in hosts configuring one or more "stable" addresses composed of a network prefix advertised by a local router, and an Interface Identifier (IID) [RFC4291] that typically embeds a stable link-layer address (e.g., an IEEE LAN MAC address). In some network technologies and adaptation layers, the use of an IID based on a link-layer address may offer some advantages. For example, the IP-over-IEEE802.15.4 standard in [RFC6775] allows for compression of IPv6 addresses when the IID is based on the underlying link-layer address. The security and privacy implications of embedding a stable link- layer address in an IPv6 IID have been known for some time now, and are discussed in great detail in [RFC7721]. They include: o Network activity correlation o Location tracking o Address scanning o Device-specific vulnerability exploitation Gont, et al. Expires March 29, 2017 [Page 2] Internet-Draft Default Interface-IDs September 2016 More generally, the reuse of identifiers that have their own semantics or properties across different contexts or scopes can be detrimental for security and privacy [I-D.gont-predictable-numeric-ids]. In the case of traditional stable IPv6 IIDs, some of the security and privacy implications are dependent on the properties of the underlying link-layer addresses (e.g., whether the link-layer address is ephemeral or randomly generated), while other implications (e.g., reduction of the entropy of the IID) depend on the algorithm for generating the IID itself. In standardized recommendations for stable IPv6 IID generation meant to achieve particular security and privacy properties, it is therefore necessary to recommend against embedding stable link-layer addresses in IPv6 IIDs. Furthermore, some popular IPv6 implementations have already deviated from the traditional stable IID generation scheme to mitigate the aforementioned security and privacy implications [Microsoft]. As a result of the aforementioned issues, this document changes the recommended default IID generation scheme for generating stable IPv6 addresses with SLAAC to that specified in [RFC7217], and recommends against embedding stable link-layer addresses in IPv6 Interface Identifiers, such that the aforementioned issues are mitigated. That is, this document simply replaces the default algorithm that is recommended to be employed when generating stable IPv6 IIDs. NOTE: [RFC4291] defines the "Modified EUI-64 format" for IIDs. Appendix A of [RFC4291] then describes how to transform an IEEE EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an EUI-64 identifier is derived, into an IID in the Modified EUI-64 format. In a variety of scenarios, addresses that remain stable for the lifetime of a host's connection to a single subnet, are viewed as desirable. For example, stable addresses may be viewed as beneficial for network management, event logging, enforcement of access control, provision of quality of service, or for server or routing interfaces. Similarly, stable addresses (as opposed to temporary addresses [RFC4941]) allow for long-lived TCP connections, and are also usually desirable when performing server-like functions (i.e., receiving incoming connections). The recommendations in this document apply only in cases where implementations otherwise would have configured a stable IPv6 IID containing a link layer address. For example, this document does not change any existing recommendations concerning the use of temporary addresses as specified in [RFC4941], nor do the recommendations apply to cases where SLAAC is employed to generate non-stable IPv6 Gont, et al. Expires March 29, 2017 [Page 3] Internet-Draft Default Interface-IDs September 2016 addresses (e.g. by embedding a link-layer address that is periodically randomized), nor does it introduce any new requirements regarding when stable addresses are to be configured. Thus, the recommendations in this document simply improve the security and privacy properties of stable addresses. 2. Terminology Stable address: An address that does not vary over time within the same network (as defined in [RFC7721]). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Generation of IPv6 Interface Identifiers with SLAAC Nodes SHOULD implement and employ [RFC7217] as the default scheme for generating stable IPv6 addresses with SLAAC. A link layer MAY also define a mechanism for stable IPv6 address generation that is more efficient and does not address the security and privacy considerations discussed in Section 1. The choice of whether to enable the security- and privacy-preserving mechanism or not SHOULD be configurable in such a case. By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID. In particular, this document RECOMMENDS that nodes do not generate stable IIDs with the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], [RFC4391], [RFC5121], and [RFC5072]. 4. Future Work At the time of this writing, the mechanisms specified in the following documents might require updates to be fully compatible with the recommendations in this document: o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" [RFC6282] o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944] o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"[RFC6775] Gont, et al. Expires March 29, 2017 [Page 4] Internet-Draft Default Interface-IDs September 2016 o "Transmission of IPv6 Packets over ITU-T G.9959 Networks" [RFC7428] Future revisions or updates of these documents should take the issues of privacy and security mentioned in Section 1 and explain any design and engineering considerations that lead to the use of stable IIDs based on a node's link-layer address. 5. IANA Considerations There are no IANA registries within this document. The RFC-Editor can remove this section before publication of this document as an RFC. 6. Security Considerations This recommends against the (default) use of predictable Interface Identifiers in IPv6 addresses. It recommends [RFC7217] as the default scheme for generating IPv6 stable addresses with SLAAC, such that the security and privacy issues of IIDs that embed stable link- layer addresses are mitigated. 7. Acknowledgements The authors would like to thank (in alphabetical order) Bob Hinden, Ray Hunter and Erik Nordmark, for providing a detailed review of this document. The authors would like to thank (in alphabetical order) Fred Baker, Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner, Randy Turner, James Woodyatt, and Juan Carlos Zuniga, for providing valuable comments on earlier versions of this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Gont, et al. Expires March 29, 2017 [Page 5] Internet-Draft Default Interface-IDs September 2016 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, . [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, DOI 10.17487/RFC2470, December 1998, . [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, DOI 10.17487/RFC2491, January 1999, . [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, . [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, . [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, DOI 10.17487/RFC2590, May 1999, . [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, October 2001, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, January 2006, . Gont, et al. Expires March 29, 2017 [Page 6] Internet-Draft Default Interface-IDs September 2016 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 2006, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, . [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, DOI 10.17487/RFC5121, February 2008, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . Gont, et al. Expires March 29, 2017 [Page 7] Internet-Draft Default Interface-IDs September 2016 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, . 8.2. Informative References [I-D.gont-predictable-numeric-ids] Gont, F. and I. Arce, "Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols", draft-gont-predictable-numeric-ids-00 (work in progress), February 2016. [Microsoft] Davies, J., "Understanding IPv6, 3rd. ed", page 83, Microsoft Press, 2012, . [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July 2003, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . Authors' Addresses Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com Gont, et al. Expires March 29, 2017 [Page 8] Internet-Draft Default Interface-IDs September 2016 Alissa Cooper Cisco 707 Tasman Drive Milpitas, CA 95035 US Phone: +1-408-902-3950 Email: alcoop@cisco.com URI: https://www.cisco.com/ Dave Thaler Microsoft Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 8835 Email: dthaler@microsoft.com Will Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Gont, et al. Expires March 29, 2017 [Page 9] ./draft-ietf-idr-deprecate-30-31-129-02.txt0000664000764400076440000001311213031317570017034 0ustar iustyiusty IDR J. Snijders Internet-Draft NTT Intended status: Standards Track December 29, 2016 Expires: July 2, 2017 Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 243 draft-ietf-idr-deprecate-30-31-129-02 Abstract This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as "deprecated". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 2, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Snijders Expires July 2, 2017 [Page 1] Internet-Draft Deprecation Of Squatted BGP Path Attributes December 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 3. Security Considerations . . . . . . . . . . . . . . . . . . . 2 4. Informative References . . . . . . . . . . . . . . . . . . . 3 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction It has been discovered that certain BGP Path Attribute values have been used in BGP implementations which have been deployed in the wild while not being assigned by the IANA for such usage. Unregistered usage of BGP Path Attribute values can lead to deployment problems for new technologies. The use of these unregistered values was noticed when BGP Large Communities attribute [I-D.ietf-idr-large-community] was initially assigned value 30 by IANA. It was subsequently discovered that a widely-deployed BGP-4 [RFC4271] implementation had released code which used path attribute 30 and which applied a "Treat-as-withdraw" [RFC7606] strategy to routes containing a valid Large Community attribute, since it was expecting a different data structure. Because these routes were dropped, early adopters of Large Communities were unreachable from parts of the Internet. As a workaround, a new Early IANA Allocation was requested. The squatting of values 30, 31, 129, 241, 242 and 243 has been confirmed by the involved vendors or through source code review. 2. IANA Considerations Per this document, IANA is requested to mark values 30, 31, 129, 241, 242, and 243 as "deprecated" in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group. The marking "deprecated" meaning "use is not recommended" ([I-D.leiba-cotton-iana-5226bis]). 3. Security Considerations There are no meaningful security consequences arising from this registry update. Snijders Expires July 2, 2017 [Page 2] Internet-Draft Deprecation Of Squatted BGP Path Attributes December 2016 4. Informative References [I-D.ietf-idr-large-community] Heitz, J., Snijders, J., Patel, K., Bagdonas, I., and N. Hilliard, "BGP Large Communities", draft-ietf-idr-large- community-11 (work in progress), December 2016. [I-D.leiba-cotton-iana-5226bis] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", draft- leiba-cotton-iana-5226bis-18 (work in progress), September 2016. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . Appendix A. Acknowledgements The author would like to gratefully acknowledge Marlien Vijfhuizen who helped discover the squatting of value 30, and Nick Hilliard for editorial feedback. Author's Address Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ NL Email: job@ntt.net Snijders Expires July 2, 2017 [Page 3] ./draft-ietf-6man-ipv6-mibs-obsolete-02.txt0000664000764400076440000034300113012213023017625 0ustar iustyiusty IPv6 Maintenance B. Fenner Internet-Draft Arista Networks, Inc. Obsoletes: 2452, 2454, 2465, 2466 (if November 14, 2016 approved) Intended status: Informational Expires: May 18, 2017 Republishing the IPV6-specific MIB modules as obsolete draft-ietf-6man-ipv6-mibs-obsolete-02 Abstract In 2005, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB and IPV6-UDP-MIB modules, for the purpose of updating MIB module repositories. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 18, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Fenner Expires May 18, 2017 [Page 1] Internet-Draft ipv6-mibs-obsolete November 2016 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Historic IPV6-TC . . . . . . . . . . . . . . . . . . . . . . 3 3. Historic IPV6-MIB . . . . . . . . . . . . . . . . . . . . . . 5 4. Historic IPV6-ICMP-MIB . . . . . . . . . . . . . . . . . . . 39 5. Historic IPV6-UDP-MIB . . . . . . . . . . . . . . . . . . . . 52 6. Historic IPV6-TCP-MIB . . . . . . . . . . . . . . . . . . . . 56 7. Reclassification . . . . . . . . . . . . . . . . . . . . . . 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 62 10.2. Informative References . . . . . . . . . . . . . . . . . 62 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 63 A.1. Changes since draft-ietf-6man-ipv6-mibs-obsolete-01 . . . 63 A.2. Changes since draft-ietf-6man-ipv6-mibs-obsolete-00 . . . 63 A.3. Changes since draft-fenner-ipv6-mibs-obsolete-00 . . . . 63 A.4. Changes since draft-fenner-ipv6-mibs-obsolete-01 . . . . 64 A.5. Changes since draft-fenner-ipv6-mibs-obsolete-02 . . . . 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 64 1. Motivation In 2005, the IPv6 MIB update group published updated versions of the IP-MIB [RFC4293], UDP-MIB [RFC4113], TCP-MIB [RFC4022] and IP- FORWARD-MIB [RFC4292] modules, which use the InetAddressType/ InetAddress construct to handle IPv4 and IPv6 in the same table. These documents were marked in the RFC Index as obsoleting the corresponding IPV6-MIBs, but the extracted content of these MIBs Fenner Expires May 18, 2017 [Page 2] Internet-Draft ipv6-mibs-obsolete November 2016 never changed in MIB repositories, and the original RFCs (as is normal IETF policy) never changed from being Proposed Standard. Note that the timeline of these MIB modules looks like shown below (and it is the added support for IPv6 in the later revision of the original modules that people often overlook). IPv6-MIB--------X \ IP-MIB-------------------IP-MIB---> This causes an unclear situation when simply looking at MIB repositories, so we are simply republishing these MIB modules with the SMI syntax changed to obsolete. This is an unusual step, and is not the intended path with every obsolete MIB module; the special history of these modules lead to this special step. 2. Historic IPV6-TC IPV6-TC DEFINITIONS ::= BEGIN IMPORTS Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; -- definition of textual conventions Ipv6Address ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:" STATUS obsolete DESCRIPTION "This data type is used to model IPv6 addresses. This is a binary string of 16 octets in network byte-order. This object is obsoleted by INET-ADDRESS-MIB::InetAddress." SYNTAX OCTET STRING (SIZE (16)) Ipv6AddressPrefix ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:" STATUS obsolete DESCRIPTION "This data type is used to model IPv6 address prefixes. This is a binary string of up to 16 octets in network byte-order. This object is obsoleted by INET-ADDRESS-MIB::InetAddress." SYNTAX OCTET STRING (SIZE (0..16)) Fenner Expires May 18, 2017 [Page 3] Internet-Draft ipv6-mibs-obsolete November 2016 Ipv6AddressIfIdentifier ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:" STATUS obsolete DESCRIPTION "This data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. This object is obsoleted by IP-MIB::Ipv6AddressIfIdentifierTC." SYNTAX OCTET STRING (SIZE (0..8)) Ipv6IfIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS obsolete DESCRIPTION "A unique value, greater than zero for each internetwork-layer interface in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each internetwork-layer interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. This object is obsoleted by IF-MIB::InterfaceIndex." SYNTAX Integer32 (1..2147483647) Ipv6IfIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS obsolete DESCRIPTION "This textual convention is an extension of the Ipv6IfIndex convention. The latter defines a greater than zero value used to identify an IPv6 interface in the managed system. This extension permits the additional value of zero. The value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced. This object is obsoleted by IF-MIB::InterfaceIndexOrZero." SYNTAX Integer32 (0..2147483647) END Fenner Expires May 18, 2017 [Page 4] Internet-Draft ipv6-mibs-obsolete November 2016 3. Historic IPV6-MIB IPV6-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Counter32, Unsigned32, Integer32, Gauge32 FROM SNMPv2-SMI DisplayString, PhysAddress, TruthValue, TimeStamp, VariablePointer, RowPointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF Ipv6IfIndex, Ipv6Address, Ipv6AddressPrefix, Ipv6AddressIfIdentifier, Ipv6IfIndexOrZero FROM IPV6-TC; ipv6MIB MODULE-IDENTITY LAST-UPDATED "201505282112Z" ORGANIZATION "IETF IPv6 Working Group" CONTACT-INFO " Dimitry Haskin Postal: Bay Networks, Inc. 660 Techology Park Drive. Billerica, MA 01821 US Tel: +1-978-916-8124 E-mail: dhaskin@baynetworks.com Steve Onishi Postal: Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 US Tel: +1-978-916-3816 E-mail: sonishi@baynetworks.com" DESCRIPTION "The obsolete MIB module for entities implementing the IPv6 protocol. Use the IP-MIB or IP-FORWARD-MIB instead." REVISION "201505282112Z" DESCRIPTION "Obsoleting this MIB module; it has been replaced by the revised IP-MIB (RFC4293) and IP-FORWARD-MIB (RFC4292)." Fenner Expires May 18, 2017 [Page 5] Internet-Draft ipv6-mibs-obsolete November 2016 REVISION "9802052155Z" DESCRIPTION "First revision, published as RFC2465" ::= { mib-2 55 } -- the IPv6 general group ipv6MIBObjects OBJECT IDENTIFIER ::= { ipv6MIB 1 } ipv6Forwarding OBJECT-TYPE SYNTAX INTEGER { forwarding(1), -- acting as a router -- NOT acting as notForwarding(2) -- a router } MAX-ACCESS read-write STATUS obsolete DESCRIPTION "The indication of whether this entity is acting as an IPv6 router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv6 routers forward datagrams. IPv6 hosts do not (except those source-routed via the host). Note that for some managed nodes, this object may take on only a subset of the values possible. Accordingly, it is appropriate for an agent to return a `wrongValue' response if a management station attempts to change this object to an inappropriate value. This object is obsoleted by IP-MIB::ipv6IpForwarding." ::= { ipv6MIBObjects 1 } ipv6DefaultHopLimit OBJECT-TYPE SYNTAX INTEGER(0..255) MAX-ACCESS read-write STATUS obsolete DESCRIPTION "The default value inserted into the Hop Limit field of the IPv6 header of datagrams originated at this entity, whenever a Hop Limit value is not supplied by the transport layer protocol. This object is obsoleted by IP-MIB::ipv6IpDefaultHopLimit." DEFVAL { 64 } Fenner Expires May 18, 2017 [Page 6] Internet-Draft ipv6-mibs-obsolete November 2016 ::= { ipv6MIBObjects 2 } ipv6Interfaces OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of IPv6 interfaces (regardless of their current state) present on this system. This object is obsolete; there is no direct replacement but its value can be derived from the number of rows in the IP-MIB::ipv6InterfaceTable." ::= { ipv6MIBObjects 3 } ipv6IfTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The value of sysUpTime at the time of the last insertion or removal of an entry in the ipv6IfTable. If the number of entries has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value. This object is obsoleted by IP-MIB::ipv6InterfaceTableLastChange." ::= { ipv6MIBObjects 4 } -- the IPv6 Interfaces table ipv6IfTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6IfEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The IPv6 Interfaces table contains information on the entity's internetwork-layer interfaces. An IPv6 interface constitutes a logical network layer attachment to the layer immediately below IPv6 including internet layer 'tunnels', such as tunnels over IPv4 or IPv6 itself. This table is obsoleted by IP-MIB::ipv6InterfaceTable." ::= { ipv6MIBObjects 5 } Fenner Expires May 18, 2017 [Page 7] Internet-Draft ipv6-mibs-obsolete November 2016 ipv6IfEntry OBJECT-TYPE SYNTAX Ipv6IfEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "An interface entry containing objects about a particular IPv6 interface. This object is obsoleted by IP-MIB::ipv6InterfaceEntry." INDEX { ipv6IfIndex } ::= { ipv6IfTable 1 } Ipv6IfEntry ::= SEQUENCE { ipv6IfIndex Ipv6IfIndex, ipv6IfDescr DisplayString, ipv6IfLowerLayer VariablePointer, ipv6IfEffectiveMtu Unsigned32, ipv6IfReasmMaxSize Unsigned32, ipv6IfIdentifier Ipv6AddressIfIdentifier, ipv6IfIdentifierLength INTEGER, ipv6IfPhysicalAddress PhysAddress, ipv6IfAdminStatus INTEGER, ipv6IfOperStatus INTEGER, ipv6IfLastChange TimeStamp } ipv6IfIndex OBJECT-TYPE SYNTAX Ipv6IfIndex MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "A unique non-zero value identifying the particular IPv6 interface. This object is obsoleted. In the IP-MIB, interfaces are simply identified by IfIndex." ::= { ipv6IfEntry 1 } ipv6IfDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS obsolete DESCRIPTION "A textual string containing information about the interface. This string may be set by the network management system. This object is obsoleted by IF-MIB::ifDescr." Fenner Expires May 18, 2017 [Page 8] Internet-Draft ipv6-mibs-obsolete November 2016 ::= { ipv6IfEntry 2 } ipv6IfLowerLayer OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-only STATUS obsolete DESCRIPTION "This object identifies the protocol layer over which this network interface operates. If this network interface operates over the data-link layer, then the value of this object refers to an instance of ifIndex [6]. If this network interface operates over an IPv4 interface, the value of this object refers to an instance of ipAdEntAddr [3]. If this network interface operates over another IPv6 interface, the value of this object refers to an instance of ipv6IfIndex. If this network interface is not currently operating over an active protocol layer, then the value of this object should be set to the OBJECT ID { 0 0 }. This object is obsolete. The IF-STACK-TABLE may be used to express relationships between interfaces." ::= { ipv6IfEntry 3 } ipv6IfEffectiveMtu OBJECT-TYPE SYNTAX Unsigned32 UNITS "octets" MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The size of the largest IPv6 packet which can be sent/received on the interface, specified in octets. This object is obsolete. The value of IF-MIB::ifMtu for the corresponding value of ifIndex represents the MTU of the interface." ::= { ipv6IfEntry 4 } ipv6IfReasmMaxSize OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "octets" MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The size of the largest IPv6 datagram which this Fenner Expires May 18, 2017 [Page 9] Internet-Draft ipv6-mibs-obsolete November 2016 entity can re-assemble from incoming IPv6 fragmented datagrams received on this interface. This object is obsoleted by IP-MIB::ipv6InterfaceReasmMaxSize." ::= { ipv6IfEntry 5 } ipv6IfIdentifier OBJECT-TYPE SYNTAX Ipv6AddressIfIdentifier MAX-ACCESS read-write STATUS obsolete DESCRIPTION "The Interface Identifier for this interface that is (at least) unique on the link this interface is attached to. The Interface Identifier is combined with an address prefix to form an interface address. By default, the Interface Identifier is autoconfigured according to the rules of the link type this interface is attached to. This object is obsoleted by IP-MIB::ipv6InterfaceIdentifier." ::= { ipv6IfEntry 6 } ipv6IfIdentifierLength OBJECT-TYPE SYNTAX INTEGER (0..64) UNITS "bits" MAX-ACCESS read-write STATUS obsolete DESCRIPTION "The length of the Interface Identifier in bits. This object is obsolete. It can be derived from the length of IP-MIB::ipv6InterfaceIdentifier; Interface Identifiers that are not an even number of octets are not supported." ::= { ipv6IfEntry 7 } ipv6IfPhysicalAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The interface's physical address. For example, for an IPv6 interface attached to an 802.x link, this object normally contains a MAC address. Note that in some cases this address may differ from the address of the interface's protocol sub-layer. The interface's media-specific MIB must define the bit and byte ordering and the format of the value of Fenner Expires May 18, 2017 [Page 10] Internet-Draft ipv6-mibs-obsolete November 2016 this object. For interfaces which do not have such an address (e.g., a serial line), this object should contain an octet string of zero length. This object is obsoleted by IF-MIB::ifPhysAddress." ::= { ipv6IfEntry 8 } ipv6IfAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2) } MAX-ACCESS read-write STATUS obsolete DESCRIPTION "The desired state of the interface. When a managed system initializes, all IPv6 interfaces start with ipv6IfAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ipv6IfAdminStatus is then changed to the up(1) state (or remains in the down(2) state). This object is obsolete. IPv6 does not have a separate admin status; the admin status of the interface is represented by IF-MIB::ifAdminStatus." ::= { ipv6IfEntry 9 } ipv6IfOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), noIfIdentifier(3), -- no interface identifier -- status can not be -- determined for some unknown(4), -- reason -- some component is notPresent(5) -- missing } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The current operational state of the interface. The noIfIdentifier(3) state indicates that no valid Interface Identifier is assigned to the interface. Fenner Expires May 18, 2017 [Page 11] Internet-Draft ipv6-mibs-obsolete November 2016 This state usually indicates that the link-local interface address failed Duplicate Address Detection. If ipv6IfAdminStatus is down(2) then ipv6IfOperStatus should be down(2). If ipv6IfAdminStatus is changed to up(1) then ipv6IfOperStatus should change to up(1) if the interface is ready to transmit and receive network traffic; it should remain in the down(2) or noIfIdentifier(3) state if and only if there is a fault that prevents it from going to the up(1) state; it should remain in the notPresent(5) state if the interface has missing (typically, lower layer) components. This object is obsolete. IPv6 does not have a separate operational status; the operational status of the interface is represented by IF-MIB::ifOperStatus." ::= { ipv6IfEntry 10 } ipv6IfLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value. This object is obsolete. The last change of IF-MIB::ifOperStatus is represented by IF-MIB::ifLastChange." ::= { ipv6IfEntry 11 } -- IPv6 Interface Statistics table ipv6IfStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6IfStatsEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "IPv6 interface traffic statistics. This table is obsoleted by the IP-MIB::ipIfStatsTable." ::= { ipv6MIBObjects 6 } ipv6IfStatsEntry OBJECT-TYPE SYNTAX Ipv6IfStatsEntry Fenner Expires May 18, 2017 [Page 12] Internet-Draft ipv6-mibs-obsolete November 2016 MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "An interface statistics entry containing objects at a particular IPv6 interface. This object is obsoleted by the IP-MIB::ipIfStatsEntry." AUGMENTS { ipv6IfEntry } ::= { ipv6IfStatsTable 1 } Ipv6IfStatsEntry ::= SEQUENCE { ipv6IfStatsInReceives Counter32, ipv6IfStatsInHdrErrors Counter32, ipv6IfStatsInTooBigErrors Counter32, ipv6IfStatsInNoRoutes Counter32, ipv6IfStatsInAddrErrors Counter32, ipv6IfStatsInUnknownProtos Counter32, ipv6IfStatsInTruncatedPkts Counter32, ipv6IfStatsInDiscards Counter32, ipv6IfStatsInDelivers Counter32, ipv6IfStatsOutForwDatagrams Counter32, ipv6IfStatsOutRequests Counter32, ipv6IfStatsOutDiscards Counter32, ipv6IfStatsOutFragOKs Counter32, ipv6IfStatsOutFragFails Counter32, ipv6IfStatsOutFragCreates Counter32, ipv6IfStatsReasmReqds Counter32, ipv6IfStatsReasmOKs Counter32, ipv6IfStatsReasmFails Counter32, ipv6IfStatsInMcastPkts Fenner Expires May 18, 2017 [Page 13] Internet-Draft ipv6-mibs-obsolete November 2016 Counter32, ipv6IfStatsOutMcastPkts Counter32 } ipv6IfStatsInReceives OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of input datagrams received by the interface, including those received in error. This object is obsoleted by IP-MIB::ipIfStatsHCInReceives." ::= { ipv6IfStatsEntry 1 } ipv6IfStatsInHdrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of input datagrams discarded due to errors in their IPv6 headers, including version number mismatch, other format errors, hop count exceeded, errors discovered in processing their IPv6 options, etc. This object is obsoleted by IP-MIB::ipIfStatsInHdrErrors." ::= { ipv6IfStatsEntry 2 } ipv6IfStatsInTooBigErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of input datagrams that could not be forwarded because their size exceeded the link MTU of outgoing interface. This object is obsoleted. It was not replicated in the IP-MIB due to feedback that systems did not retain the incoming interface of a packet that failed fragmentation." ::= { ipv6IfStatsEntry 3 } ipv6IfStatsInNoRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete Fenner Expires May 18, 2017 [Page 14] Internet-Draft ipv6-mibs-obsolete November 2016 DESCRIPTION "The number of input datagrams discarded because no route could be found to transmit them to their destination. This object is obsoleted by IP-MIB::ipIfStatsInNoRoutes." ::= { ipv6IfStatsEntry 4 } ipv6IfStatsInAddrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of input datagrams discarded because the IPv6 address in their IPv6 header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., ::0) and unsupported addresses (e.g., addresses with unallocated prefixes). For entities which are not IPv6 routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address. This object is obsoleted by IP-MIB::ipIfStatsInAddrErrors." ::= { ipv6IfStatsEntry 5 } ipv6IfStatsInUnknownProtos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol. This counter is incremented at the interface to which these datagrams were addressed which might not be necessarily the input interface for some of the datagrams. This object is obsoleted by IP-MIB::ipIfStatsInUnknownProtos." ::= { ipv6IfStatsEntry 6 } ipv6IfStatsInTruncatedPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION Fenner Expires May 18, 2017 [Page 15] Internet-Draft ipv6-mibs-obsolete November 2016 "The number of input datagrams discarded because datagram frame didn't carry enough data. This object is obsoleted by IP-MIB::ipIfStatsInTruncatedPkts." ::= { ipv6IfStatsEntry 7 } ipv6IfStatsInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of input IPv6 datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly. This object is obsoleted by IP-MIB::ipIfStatsInDiscards." ::= { ipv6IfStatsEntry 8 } ipv6IfStatsInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of datagrams successfully delivered to IPv6 user-protocols (including ICMP). This counter is incremented at the interface to which these datagrams were addressed which might not be necessarily the input interface for some of the datagrams. This object is obsoleted by IP-MIB::ipIfStatsHCInDelivers." ::= { ipv6IfStatsEntry 9 } ipv6IfStatsOutForwDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of output datagrams which this entity received and forwarded to their final destinations. In entities which do not act as IPv6 routers, this counter will include only those packets which were Source-Routed via this entity, and the Source-Route processing was successful. Note that for Fenner Expires May 18, 2017 [Page 16] Internet-Draft ipv6-mibs-obsolete November 2016 a successfully forwarded datagram the counter of the outgoing interface is incremented. This object is obsoleted by IP-MIB::ipIfStatsHCOutForwDatagrams." ::= { ipv6IfStatsEntry 10 } ipv6IfStatsOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of IPv6 datagrams which local IPv6 user-protocols (including ICMP) supplied to IPv6 in requests for transmission. Note that this counter does not include any datagrams counted in ipv6IfStatsOutForwDatagrams. This object is obsoleted by IP-MIB::ipIfStatsHCOutRequests." ::= { ipv6IfStatsEntry 11 } ipv6IfStatsOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of output IPv6 datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipv6IfStatsOutForwDatagrams if any such packets met this (discretionary) discard criterion. This object is obsoleted by IP-MIB::ipIfStatsOutDiscards." ::= { ipv6IfStatsEntry 12 } ipv6IfStatsOutFragOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of IPv6 datagrams that have been successfully fragmented at this output interface. This object is obsoleted by IP-MIB::ipIfStatsOutFragOKs." ::= { ipv6IfStatsEntry 13 } Fenner Expires May 18, 2017 [Page 17] Internet-Draft ipv6-mibs-obsolete November 2016 ipv6IfStatsOutFragFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of IPv6 datagrams that have been discarded because they needed to be fragmented at this output interface but could not be. This object is obsoleted by IP-MIB::ipIfStatsOutFragFails." ::= { ipv6IfStatsEntry 14 } ipv6IfStatsOutFragCreates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of output datagram fragments that have been generated as a result of fragmentation at this output interface. This object is obsoleted by IP-MIB::ipIfStatsOutFragCreates." ::= { ipv6IfStatsEntry 15 } ipv6IfStatsReasmReqds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of IPv6 fragments received which needed to be reassembled at this interface. Note that this counter is incremented at the interface to which these fragments were addressed which might not be necessarily the input interface for some of the fragments. This object is obsoleted by IP-MIB::ipIfStatsReasmReqds." ::= { ipv6IfStatsEntry 16 } ipv6IfStatsReasmOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of IPv6 datagrams successfully reassembled. Note that this counter is incremented at the interface to which these datagrams were addressed which might not be necessarily the input Fenner Expires May 18, 2017 [Page 18] Internet-Draft ipv6-mibs-obsolete November 2016 interface for some of the fragments. This object is obsoleted by IP-MIB::ipIfStatsReasmOKs." ::= { ipv6IfStatsEntry 17 } ipv6IfStatsReasmFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of failures detected by the IPv6 re- assembly algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count of discarded IPv6 fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received. This counter is incremented at the interface to which these fragments were addressed which might not be necessarily the input interface for some of the fragments. This object is obsoleted by IP-MIB::ipIfStatsReasmFails." ::= { ipv6IfStatsEntry 18 } ipv6IfStatsInMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of multicast packets received by the interface This object is obsoleted by IP-MIB::ipIfStatsHCInMcastPkts." ::= { ipv6IfStatsEntry 19 } ipv6IfStatsOutMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of multicast packets transmitted by the interface This object is obsoleted by IP-MIB::ipIfStatsHCOutMcastPkts." ::= { ipv6IfStatsEntry 20 } -- Address Prefix table Fenner Expires May 18, 2017 [Page 19] Internet-Draft ipv6-mibs-obsolete November 2016 -- The IPv6 Address Prefix table contains information on -- the entity's IPv6 Address Prefixes that are associated -- with IPv6 interfaces. ipv6AddrPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6AddrPrefixEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The list of IPv6 address prefixes of IPv6 interfaces. This table is obsoleted by IP-MIB::ipAddressPrefixTable." ::= { ipv6MIBObjects 7 } ipv6AddrPrefixEntry OBJECT-TYPE SYNTAX Ipv6AddrPrefixEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "An interface entry containing objects of a particular IPv6 address prefix. This entry is obsoleted by IP-MIB::ipAddressPrefixEntry." INDEX { ipv6IfIndex, ipv6AddrPrefix, ipv6AddrPrefixLength } ::= { ipv6AddrPrefixTable 1 } Ipv6AddrPrefixEntry ::= SEQUENCE { ipv6AddrPrefix Ipv6AddressPrefix, ipv6AddrPrefixLength INTEGER, ipv6AddrPrefixOnLinkFlag TruthValue, ipv6AddrPrefixAutonomousFlag TruthValue, ipv6AddrPrefixAdvPreferredLifetime Unsigned32, ipv6AddrPrefixAdvValidLifetime Unsigned32 } ipv6AddrPrefix OBJECT-TYPE SYNTAX Ipv6AddressPrefix MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The prefix associated with the this interface. This object is obsoleted by IP-MIB::ipAddressPrefixPrefix." ::= { ipv6AddrPrefixEntry 1 } Fenner Expires May 18, 2017 [Page 20] Internet-Draft ipv6-mibs-obsolete November 2016 ipv6AddrPrefixLength OBJECT-TYPE SYNTAX INTEGER (0..128) UNITS "bits" MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The length of the prefix (in bits). This object is obsoleted by IP-MIB::ipAddressPrefixLength." ::= { ipv6AddrPrefixEntry 2 } ipv6AddrPrefixOnLinkFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS obsolete DESCRIPTION "This object has the value 'true(1)', if this prefix can be used for on-link determination and the value 'false(2)' otherwise. This object is obsoleted by IP-MIB::ipAddressPrefixOnLinkFlag." ::= { ipv6AddrPrefixEntry 3 } ipv6AddrPrefixAutonomousFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS obsolete DESCRIPTION "Autonomous address configuration flag. When true(1), indicates that this prefix can be used for autonomous address configuration (i.e. can be used to form a local interface address). If false(2), it is not used to autoconfigure a local interface address. This object is obsoleted by IP-MIB::ipAddressPrefixAutonomousFlag." ::= { ipv6AddrPrefixEntry 4 } ipv6AddrPrefixAdvPreferredLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS obsolete DESCRIPTION "It is the length of time in seconds that this prefix will remain preferred, i.e. time until deprecation. A value of 4,294,967,295 represents Fenner Expires May 18, 2017 [Page 21] Internet-Draft ipv6-mibs-obsolete November 2016 infinity. The address generated from a deprecated prefix should no longer be used as a source address in new communications, but packets received on such an interface are processed as expected. This object is obsoleted by IP-MIB::ipAddressPrefixAdvPreferredLifetime." ::= { ipv6AddrPrefixEntry 5 } ipv6AddrPrefixAdvValidLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS obsolete DESCRIPTION "It is the length of time in seconds that this prefix will remain valid, i.e. time until invalidation. A value of 4,294,967,295 represents infinity. The address generated from an invalidated prefix should not appear as the destination or source address of a packet. This object is obsoleted by IP-MIB::ipAddressPrefixAdvValidLifetime." ::= { ipv6AddrPrefixEntry 6 } -- the IPv6 Address table -- The IPv6 address table contains this node's IPv6 -- addressing information. ipv6AddrTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6AddrEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The table of addressing information relevant to this node's interface addresses. This table is obsoleted by IP-MIB::ipAddressTable." ::= { ipv6MIBObjects 8 } ipv6AddrEntry OBJECT-TYPE SYNTAX Ipv6AddrEntry Fenner Expires May 18, 2017 [Page 22] Internet-Draft ipv6-mibs-obsolete November 2016 MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The addressing information for one of this node's interface addresses. This entry is obsoleted by IP-MIB::ipAddressEntry." INDEX { ipv6IfIndex, ipv6AddrAddress } ::= { ipv6AddrTable 1 } Ipv6AddrEntry ::= SEQUENCE { ipv6AddrAddress Ipv6Address, ipv6AddrPfxLength INTEGER, ipv6AddrType INTEGER, ipv6AddrAnycastFlag TruthValue, ipv6AddrStatus INTEGER } ipv6AddrAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The IPv6 address to which this entry's addressing information pertains. This object is obsoleted by IP-MIB::ipAddressAddr." ::= { ipv6AddrEntry 1 } ipv6AddrPfxLength OBJECT-TYPE SYNTAX INTEGER(0..128) UNITS "bits" MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The length of the prefix (in bits) associated with the IPv6 address of this entry. This object is obsoleted by the IP-MIB::ipAddressPrefixLength in the row of the IP-MIB::ipAddressPrefixTable to which the IP-MIB::ipAddressPrefix points." ::= { ipv6AddrEntry 2 } ipv6AddrType OBJECT-TYPE SYNTAX INTEGER { -- address has been formed -- using stateless Fenner Expires May 18, 2017 [Page 23] Internet-Draft ipv6-mibs-obsolete November 2016 stateless(1), -- autoconfiguration -- address has been acquired -- by stateful means -- (e.g. DHCPv6, manual stateful(2), -- configuration) -- type can not be determined unknown(3) -- for some reason. } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The type of address. Note that 'stateless(1)' refers to an address that was statelessly autoconfigured; 'stateful(2)' refers to a address which was acquired by via a stateful protocol (e.g. DHCPv6, manual configuration). This object is obsoleted by IP-MIB::ipAddressOrigin." ::= { ipv6AddrEntry 3 } ipv6AddrAnycastFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS obsolete DESCRIPTION "This object has the value 'true(1)', if this address is an anycast address and the value 'false(2)' otherwise. This object is obsoleted by a value of 'anycast(2)' in IP-MIB::ipAddressType." ::= { ipv6AddrEntry 4 } ipv6AddrStatus OBJECT-TYPE SYNTAX INTEGER { preferred(1), deprecated(2), invalid(3), inaccessible(4), unknown(5) -- status can not be determined -- for some reason. } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "Address status. The preferred(1) state indicates Fenner Expires May 18, 2017 [Page 24] Internet-Draft ipv6-mibs-obsolete November 2016 that this is a valid address that can appear as the destination or source address of a packet. The deprecated(2) state indicates that this is a valid but deprecated address that should no longer be used as a source address in new communications, but packets addressed to such an address are processed as expected. The invalid(3) state indicates that this is not valid address which should not appear as the destination or source address of a packet. The inaccessible(4) state indicates that the address is not accessible because the interface to which this address is assigned is not operational. This object is obsoleted by IP-MIB::ipAddressStatus." ::= { ipv6AddrEntry 5 } -- IPv6 Routing objects ipv6RouteNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of current ipv6RouteTable entries. This is primarily to avoid having to read the table in order to determine this number. This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteNumber." ::= { ipv6MIBObjects 9 } ipv6DiscardedRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries. This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteDiscards." ::= { ipv6MIBObjects 10 } -- IPv6 Routing table ipv6RouteTable OBJECT-TYPE Fenner Expires May 18, 2017 [Page 25] Internet-Draft ipv6-mibs-obsolete November 2016 SYNTAX SEQUENCE OF Ipv6RouteEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "IPv6 Routing table. This table contains an entry for each valid IPv6 unicast route that can be used for packet forwarding determination. This table is obsoleted by IP-FORWARD-MIB::inetCidrRouteTable." ::= { ipv6MIBObjects 11 } ipv6RouteEntry OBJECT-TYPE SYNTAX Ipv6RouteEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "A routing entry. This entry is obsoleted by IP-FORWARD-MIB::inetCidrRouteEntry." INDEX { ipv6RouteDest, ipv6RoutePfxLength, ipv6RouteIndex } ::= { ipv6RouteTable 1 } Ipv6RouteEntry ::= SEQUENCE { ipv6RouteDest Ipv6Address, ipv6RoutePfxLength INTEGER, ipv6RouteIndex Unsigned32, ipv6RouteIfIndex Ipv6IfIndexOrZero, ipv6RouteNextHop Ipv6Address, ipv6RouteType INTEGER, ipv6RouteProtocol INTEGER, ipv6RoutePolicy Integer32, ipv6RouteAge Unsigned32, ipv6RouteNextHopRDI Unsigned32, ipv6RouteMetric Unsigned32, ipv6RouteWeight Unsigned32, ipv6RouteInfo RowPointer, ipv6RouteValid TruthValue } ipv6RouteDest OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION Fenner Expires May 18, 2017 [Page 26] Internet-Draft ipv6-mibs-obsolete November 2016 "The destination IPv6 address of this route. This object may not take a Multicast address value. This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteDest." ::= { ipv6RouteEntry 1 } ipv6RoutePfxLength OBJECT-TYPE SYNTAX INTEGER(0..128) UNITS "bits" MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "Indicates the prefix length of the destination address. This object is obsoleted by IP-FORWARD-MIB::inetCidrRoutePfxLen." ::= { ipv6RouteEntry 2 } ipv6RouteIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The value which uniquely identifies the route among the routes to the same network layer destination. The way this value is chosen is implementation specific but it must be unique for ipv6RouteDest/ipv6RoutePfxLength pair and remain constant for the life of the route. This object is obsoleted by IP-FORWARD-MIB::inetCidrRoutePolicy." ::= { ipv6RouteEntry 3 } ipv6RouteIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of ipv6IfIndex. For routes of the discard type this value can be zero. This object is obsoleted by Fenner Expires May 18, 2017 [Page 27] Internet-Draft ipv6-mibs-obsolete November 2016 IP-FORWARD-MIB::inetCidrRouteIfIndex." ::= { ipv6RouteEntry 4 } ipv6RouteNextHop OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS read-only STATUS obsolete DESCRIPTION "On remote routes, the address of the next system en route; otherwise, ::0 ('00000000000000000000000000000000'H in ASN.1 string representation). This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteNextHop." ::= { ipv6RouteEntry 5 } ipv6RouteType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following -- an route indicating that -- packets to destinations -- matching this route are discard(2), -- to be discarded -- route to directly local(3), -- connected (sub-)network -- route to a remote remote(4) -- destination } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The type of route. Note that 'local(3)' refers to a route for which the next hop is the final destination; 'remote(4)' refers to a route for which the next hop is not the final destination; 'discard(2)' refers to a route indicating that packets to destinations matching this route are to be discarded (sometimes called black-hole route). This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteType." ::= { ipv6RouteEntry 6 } Fenner Expires May 18, 2017 [Page 28] Internet-Draft ipv6-mibs-obsolete November 2016 ipv6RouteProtocol OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following -- non-protocol information, -- e.g., manually configured local(2), -- entries netmgmt(3), -- static route -- obtained via Neighbor -- Discovery protocol, ndisc(4), -- e.g., result of Redirect -- the following are all -- dynamic routing protocols rip(5), -- RIPng ospf(6), -- Open Shortest Path First bgp(7), -- Border Gateway Protocol idrp(8), -- InterDomain Routing Protocol igrp(9) -- InterGateway Routing Protocol } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The routing mechanism via which this route was learned. This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteProto." ::= { ipv6RouteEntry 7 } ipv6RoutePolicy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The general set of conditions that would cause the selection of one multipath route (set of next hops for a given destination) is referred to as 'policy'. Unless the mechanism indicated by ipv6RouteProtocol specified otherwise, the policy specifier is the 8-bit Traffic Class field of the IPv6 packet header that is zero extended at the left to a 32-bit value. Protocols defining 'policy' otherwise must either define a set of values which are valid for this object or must implement an integer- instanced policy table for which this object's Fenner Expires May 18, 2017 [Page 29] Internet-Draft ipv6-mibs-obsolete November 2016 value acts as an index. This object is obsoleted by IP-FORWARD-MIB::inetCidrRoutePolicy." ::= { ipv6RouteEntry 8 } ipv6RouteAge OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned. This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteAge." ::= { ipv6RouteEntry 9 } ipv6RouteNextHopRDI OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The Routing Domain ID of the Next Hop. The semantics of this object are determined by the routing-protocol specified in the route's ipv6RouteProtocol value. When this object is unknown or not relevant its value should be set to zero. This object is obsolete, and has no replacement. The Routing Domain ID concept did not catch on." ::= { ipv6RouteEntry 10 } ipv6RouteMetric OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The routing metric for this route. The semantics of this metric are determined by the routing protocol specified in the route's ipv6RouteProtocol value. When this is unknown or not relevant to the protocol indicated by ipv6RouteProtocol, the object value should be set to its maximum value (4,294,967,295). Fenner Expires May 18, 2017 [Page 30] Internet-Draft ipv6-mibs-obsolete November 2016 This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteMetric1." ::= { ipv6RouteEntry 11 } ipv6RouteWeight OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The system internal weight value for this route. The semantics of this value are determined by the implementation specific rules. Generally, within routes with the same ipv6RoutePolicy value, the lower the weight value the more preferred is the route. This object is obsoleted, and has not been replaced." ::= { ipv6RouteEntry 12 } ipv6RouteInfo OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS obsolete DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route's ipv6RouteProto value. If this information is not present, its value should be set to the OBJECT ID { 0 0 }, which is a syntactically valid object identifier, and any implementation conforming to ASN.1 and the Basic Encoding Rules must be able to generate and recognize this value. This object is obsoleted, and has not been replaced." ::= { ipv6RouteEntry 13 } ipv6RouteValid OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS obsolete DESCRIPTION "Setting this object to the value 'false(2)' has the effect of invalidating the corresponding entry in the ipv6RouteTable object. That is, it effectively disassociates the destination identified with said entry from the route Fenner Expires May 18, 2017 [Page 31] Internet-Draft ipv6-mibs-obsolete November 2016 identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipv6RouteValid object. This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteStatus." DEFVAL { true } ::= { ipv6RouteEntry 14 } -- IPv6 Address Translation table ipv6NetToMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6NetToMediaEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The IPv6 Address Translation table used for mapping from IPv6 addresses to physical addresses. The IPv6 address translation table contain the Ipv6Address to `physical' address equivalencies. Some interfaces do not use translation tables for determining address equivalencies; if all interfaces are of this type, then the Address Translation table is empty, i.e., has zero entries. This table is obsoleted by IP-MIB::ipNetToPhysicalTable." ::= { ipv6MIBObjects 12 } ipv6NetToMediaEntry OBJECT-TYPE SYNTAX Ipv6NetToMediaEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "Each entry contains one IPv6 address to `physical' address equivalence. This entry is obsoleted by IP-MIB::ipNetToPhysicalEntry." INDEX { ipv6IfIndex, ipv6NetToMediaNetAddress } ::= { ipv6NetToMediaTable 1 } Fenner Expires May 18, 2017 [Page 32] Internet-Draft ipv6-mibs-obsolete November 2016 Ipv6NetToMediaEntry ::= SEQUENCE { ipv6NetToMediaNetAddress Ipv6Address, ipv6NetToMediaPhysAddress PhysAddress, ipv6NetToMediaType INTEGER, ipv6IfNetToMediaState INTEGER, ipv6IfNetToMediaLastUpdated TimeStamp, ipv6NetToMediaValid TruthValue } ipv6NetToMediaNetAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The IPv6 Address corresponding to the media-dependent `physical' address. This object is obsoleted by IP-MIB::ipNetToPhysicalNetAddress." ::= { ipv6NetToMediaEntry 1 } ipv6NetToMediaPhysAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The media-dependent `physical' address. This object is obsoleted by IP-MIB::ipNetToPhysicalPhysAddress." ::= { ipv6NetToMediaEntry 2 } ipv6NetToMediaType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following dynamic(2), -- dynamically resolved static(3), -- statically configured local(4) -- local interface } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The type of the mapping. The 'dynamic(2)' type indicates that the IPv6 address to physical Fenner Expires May 18, 2017 [Page 33] Internet-Draft ipv6-mibs-obsolete November 2016 addresses mapping has been dynamically resolved using the IPv6 Neighbor Discovery protocol. The static(3)' types indicates that the mapping has been statically configured. The local(4) indicates that the mapping is provided for an entity's own interface address. This object is obsoleted by IP-MIB::ipNetToPhysicalType." ::= { ipv6NetToMediaEntry 3 } ipv6IfNetToMediaState OBJECT-TYPE SYNTAX INTEGER { reachable(1), -- confirmed reachability stale(2), -- unconfirmed reachability delay(3), -- waiting for reachability -- confirmation before entering -- the probe state probe(4), -- actively probing invalid(5), -- an invalidated mapping unknown(6) -- state can not be determined -- for some reason. } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The Neighbor Unreachability Detection [8] state for the interface when the address mapping in this entry is used. This object is obsoleted by IP-MIB::ipNetToPhysicalState." ::= { ipv6NetToMediaEntry 4 } ipv6IfNetToMediaLastUpdated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The value of sysUpTime at the time this entry was last updated. If this entry was updated prior to the last re-initialization of the local network management subsystem, then this object contains a zero value. Fenner Expires May 18, 2017 [Page 34] Internet-Draft ipv6-mibs-obsolete November 2016 This object is obsoleted by IP-MIB::ipNetToPhysicalLastUpdated." ::= { ipv6NetToMediaEntry 5 } ipv6NetToMediaValid OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS obsolete DESCRIPTION "Setting this object to the value 'false(2)' has the effect of invalidating the corresponding entry in the ipv6NetToMediaTable. That is, it effectively disassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipv6NetToMediaValid object. This object is obsoleted by IP-MIB::ipNetToPhysicalRowStatus." DEFVAL { true } ::= { ipv6NetToMediaEntry 6 } -- definition of IPv6-related notifications. -- Note that we need ipv6NotificationPrefix with the 0 -- sub-identifier to make this MIB to translate to -- an SNMPv1 format in a reversible way. For example -- it is needed for proxies that convert SNMPv1 traps -- to SNMPv2 notifications without MIB knowledge. ipv6Notifications OBJECT IDENTIFIER ::= { ipv6MIB 2 } ipv6NotificationPrefix OBJECT IDENTIFIER ::= { ipv6Notifications 0 } ipv6IfStateChange NOTIFICATION-TYPE OBJECTS { ipv6IfDescr, ipv6IfOperStatus -- the new state of the If. } STATUS obsolete DESCRIPTION "An ipv6IfStateChange notification signifies that there has been a change in the state of an ipv6 interface. This notification should Fenner Expires May 18, 2017 [Page 35] Internet-Draft ipv6-mibs-obsolete November 2016 be generated when the interface's operational status transitions to or from the up(1) state. This object is obsoleted by IF-MIB::linkUp and IF-MIB::linkDown notifications." ::= { ipv6NotificationPrefix 1 } -- conformance information ipv6Conformance OBJECT IDENTIFIER ::= { ipv6MIB 3 } ipv6Compliances OBJECT IDENTIFIER ::= { ipv6Conformance 1 } ipv6Groups OBJECT IDENTIFIER ::= { ipv6Conformance 2 } -- compliance statements ipv6Compliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement for SNMPv2 entities which implement ipv6 MIB. This compliance statement is obsoleted by IP-MIB::ipMIBCompliance2." MODULE -- this module MANDATORY-GROUPS { ipv6GeneralGroup, ipv6NotificationGroup } OBJECT ipv6Forwarding MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6DefaultHopLimit MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfDescr MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfIdentifier MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfIdentifierLength Fenner Expires May 18, 2017 [Page 36] Internet-Draft ipv6-mibs-obsolete November 2016 MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfAdminStatus MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6RouteValid MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6NetToMediaValid MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" ::= { ipv6Compliances 1 } ipv6GeneralGroup OBJECT-GROUP OBJECTS { ipv6Forwarding, ipv6DefaultHopLimit, ipv6Interfaces, ipv6IfTableLastChange, ipv6IfDescr, ipv6IfLowerLayer, ipv6IfEffectiveMtu, ipv6IfReasmMaxSize, ipv6IfIdentifier, ipv6IfIdentifierLength, ipv6IfPhysicalAddress, ipv6IfAdminStatus, ipv6IfOperStatus, ipv6IfLastChange, ipv6IfStatsInReceives, ipv6IfStatsInHdrErrors, ipv6IfStatsInTooBigErrors, ipv6IfStatsInNoRoutes, ipv6IfStatsInAddrErrors, ipv6IfStatsInUnknownProtos, ipv6IfStatsInTruncatedPkts, ipv6IfStatsInDiscards, ipv6IfStatsInDelivers, ipv6IfStatsOutForwDatagrams, ipv6IfStatsOutRequests, Fenner Expires May 18, 2017 [Page 37] Internet-Draft ipv6-mibs-obsolete November 2016 ipv6IfStatsOutDiscards, ipv6IfStatsOutFragOKs, ipv6IfStatsOutFragFails, ipv6IfStatsOutFragCreates, ipv6IfStatsReasmReqds, ipv6IfStatsReasmOKs, ipv6IfStatsReasmFails, ipv6IfStatsInMcastPkts, ipv6IfStatsOutMcastPkts, ipv6AddrPrefixOnLinkFlag, ipv6AddrPrefixAutonomousFlag, ipv6AddrPrefixAdvPreferredLifetime, ipv6AddrPrefixAdvValidLifetime, ipv6AddrPfxLength, ipv6AddrType, ipv6AddrAnycastFlag, ipv6AddrStatus, ipv6RouteNumber, ipv6DiscardedRoutes, ipv6RouteIfIndex, ipv6RouteNextHop, ipv6RouteType, ipv6RouteProtocol, ipv6RoutePolicy, ipv6RouteAge, ipv6RouteNextHopRDI, ipv6RouteMetric, ipv6RouteWeight, ipv6RouteInfo, ipv6RouteValid, ipv6NetToMediaPhysAddress, ipv6NetToMediaType, ipv6IfNetToMediaState, ipv6IfNetToMediaLastUpdated, ipv6NetToMediaValid } STATUS obsolete DESCRIPTION "The IPv6 group of objects providing for basic management of IPv6 entities. This group is obsoleted by various groups in IP-MIB." ::= { ipv6Groups 1 } ipv6NotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { ipv6IfStateChange } STATUS obsolete DESCRIPTION Fenner Expires May 18, 2017 [Page 38] Internet-Draft ipv6-mibs-obsolete November 2016 "The notification that an IPv6 entity is required to implement. This group is obsoleted by IF-MIB::linkUpDownNotificationsGroup." ::= { ipv6Groups 2 } END 4. Historic IPV6-ICMP-MIB IPV6-ICMP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ipv6IfEntry FROM IPV6-MIB; ipv6IcmpMIB MODULE-IDENTITY LAST-UPDATED "201505282112Z" ORGANIZATION "IETF IPv6 Working Group" CONTACT-INFO " Dimitry Haskin Postal: Bay Networks, Inc. 660 Techology Park Drive. Billerica, MA 01821 US Tel: +1-978-916-8124 E-mail: dhaskin@baynetworks.com Steve Onishi Postal: Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 US Tel: +1-978-916-3816 E-mail: sonishi@baynetworks.com" DESCRIPTION "The obsolete MIB module for entities implementing the ICMPv6. Use the IP-MIB instead." REVISION "201505282112Z" DESCRIPTION "Obsoleting this MIB module; it has been replaced by Fenner Expires May 18, 2017 [Page 39] Internet-Draft ipv6-mibs-obsolete November 2016 the revised IP-MIB (RFC4293)." REVISION "9801082155Z" DESCRIPTION "First revision, published as RFC2466" ::= { mib-2 56 } -- the ICMPv6 group ipv6IcmpMIBObjects OBJECT IDENTIFIER ::= { ipv6IcmpMIB 1 } -- Per-interface ICMPv6 statistics table ipv6IfIcmpTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6IfIcmpEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "IPv6 ICMP statistics. This table contains statistics of ICMPv6 messages that are received and sourced by the entity. This table is obsolete, because systems were found not to maintain these statistics per-interface." ::= { ipv6IcmpMIBObjects 1 } ipv6IfIcmpEntry OBJECT-TYPE SYNTAX Ipv6IfIcmpEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "An ICMPv6 statistics entry containing objects at a particular IPv6 interface. Note that a receiving interface is the interface to which a given ICMPv6 message is addressed which may not be necessarily the input interface for the message. Similarly, the sending interface is the interface that sources a given ICMP message which is usually but not necessarily the output interface for the message. This table is obsolete, because systems were found not to maintain these statistics per-interface." AUGMENTS { ipv6IfEntry } ::= { ipv6IfIcmpTable 1 } Fenner Expires May 18, 2017 [Page 40] Internet-Draft ipv6-mibs-obsolete November 2016 Ipv6IfIcmpEntry ::= SEQUENCE { ipv6IfIcmpInMsgs Counter32 , ipv6IfIcmpInErrors Counter32 , ipv6IfIcmpInDestUnreachs Counter32 , ipv6IfIcmpInAdminProhibs Counter32 , ipv6IfIcmpInTimeExcds Counter32 , ipv6IfIcmpInParmProblems Counter32 , ipv6IfIcmpInPktTooBigs Counter32 , ipv6IfIcmpInEchos Counter32 , ipv6IfIcmpInEchoReplies Counter32 , ipv6IfIcmpInRouterSolicits Counter32 , ipv6IfIcmpInRouterAdvertisements Counter32 , ipv6IfIcmpInNeighborSolicits Counter32 , ipv6IfIcmpInNeighborAdvertisements Counter32 , ipv6IfIcmpInRedirects Counter32 , ipv6IfIcmpInGroupMembQueries Counter32 , ipv6IfIcmpInGroupMembResponses Counter32 , ipv6IfIcmpInGroupMembReductions Counter32 , ipv6IfIcmpOutMsgs Counter32 , ipv6IfIcmpOutErrors Counter32 , ipv6IfIcmpOutDestUnreachs Counter32 , ipv6IfIcmpOutAdminProhibs Counter32 , ipv6IfIcmpOutTimeExcds Counter32 , ipv6IfIcmpOutParmProblems Counter32 , ipv6IfIcmpOutPktTooBigs Fenner Expires May 18, 2017 [Page 41] Internet-Draft ipv6-mibs-obsolete November 2016 Counter32 , ipv6IfIcmpOutEchos Counter32 , ipv6IfIcmpOutEchoReplies Counter32 , ipv6IfIcmpOutRouterSolicits Counter32 , ipv6IfIcmpOutRouterAdvertisements Counter32 , ipv6IfIcmpOutNeighborSolicits Counter32 , ipv6IfIcmpOutNeighborAdvertisements Counter32 , ipv6IfIcmpOutRedirects Counter32 , ipv6IfIcmpOutGroupMembQueries Counter32 , ipv6IfIcmpOutGroupMembResponses Counter32 , ipv6IfIcmpOutGroupMembReductions Counter32 } ipv6IfIcmpInMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of ICMP messages received by the interface which includes all those counted by ipv6IfIcmpInErrors. Note that this interface is the interface to which the ICMP messages were addressed which may not be necessarily the input interface for the messages. This object has been obsoleted by IP-MIB::icmpStatsInMsgs." ::= { ipv6IfIcmpEntry 1 } ipv6IfIcmpInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP messages which the interface received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.). This object has been obsoleted by IP-MIB::icmpStatsInErrors." Fenner Expires May 18, 2017 [Page 42] Internet-Draft ipv6-mibs-obsolete November 2016 ::= { ipv6IfIcmpEntry 2 } ipv6IfIcmpInDestUnreachs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Destination Unreachable messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 3 } ipv6IfIcmpInAdminProhibs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP destination unreachable/communication administratively prohibited messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 4 } ipv6IfIcmpInTimeExcds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Time Exceeded messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 5 } ipv6IfIcmpInParmProblems OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Parameter Problem messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts Fenner Expires May 18, 2017 [Page 43] Internet-Draft ipv6-mibs-obsolete November 2016 in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 6 } ipv6IfIcmpInPktTooBigs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Packet Too Big messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 7 } ipv6IfIcmpInEchos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Echo (request) messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 8 } ipv6IfIcmpInEchoReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Echo Reply messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 9 } ipv6IfIcmpInRouterSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Router Solicit messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts Fenner Expires May 18, 2017 [Page 44] Internet-Draft ipv6-mibs-obsolete November 2016 in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 10 } ipv6IfIcmpInRouterAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Router Advertisement messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 11 } ipv6IfIcmpInNeighborSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Neighbor Solicit messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 12 } ipv6IfIcmpInNeighborAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Neighbor Advertisement messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 13 } ipv6IfIcmpInRedirects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of Redirect messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts Fenner Expires May 18, 2017 [Page 45] Internet-Draft ipv6-mibs-obsolete November 2016 in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 14 } ipv6IfIcmpInGroupMembQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMPv6 Group Membership Query messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 15} ipv6IfIcmpInGroupMembResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMPv6 Group Membership Response messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 16} ipv6IfIcmpInGroupMembReductions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMPv6 Group Membership Reduction messages received by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 17} ipv6IfIcmpOutMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of ICMP messages which this interface attempted to send. Note that this counter includes all those counted by icmpOutErrors. Fenner Expires May 18, 2017 [Page 46] Internet-Draft ipv6-mibs-obsolete November 2016 This object has been obsoleted by IP-MIB::icmpStatsOutMsgs." ::= { ipv6IfIcmpEntry 18 } ipv6IfIcmpOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP messages which this interface did not send due to problems discovered within ICMP such as a lack of buffers. This value should not include errors discovered outside the ICMP layer such as the inability of IPv6 to route the resultant datagram. In some implementations there may be no types of error which contribute to this counter's value. This object has been obsoleted by IP-MIB::icmpStatsOutErrors." ::= { ipv6IfIcmpEntry 19 } ipv6IfIcmpOutDestUnreachs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Destination Unreachable messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 20 } ipv6IfIcmpOutAdminProhibs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "Number of ICMP dest unreachable/communication administratively prohibited messages sent. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 21 } ipv6IfIcmpOutTimeExcds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Fenner Expires May 18, 2017 [Page 47] Internet-Draft ipv6-mibs-obsolete November 2016 STATUS obsolete DESCRIPTION "The number of ICMP Time Exceeded messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 22 } ipv6IfIcmpOutParmProblems OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Parameter Problem messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 23 } ipv6IfIcmpOutPktTooBigs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Packet Too Big messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 24 } ipv6IfIcmpOutEchos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Echo (request) messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 25 } ipv6IfIcmpOutEchoReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Fenner Expires May 18, 2017 [Page 48] Internet-Draft ipv6-mibs-obsolete November 2016 STATUS obsolete DESCRIPTION "The number of ICMP Echo Reply messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 26 } ipv6IfIcmpOutRouterSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Router Solicitation messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 27 } ipv6IfIcmpOutRouterAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Router Advertisement messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 28 } ipv6IfIcmpOutNeighborSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMP Neighbor Solicitation messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 29 } ipv6IfIcmpOutNeighborAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Fenner Expires May 18, 2017 [Page 49] Internet-Draft ipv6-mibs-obsolete November 2016 STATUS obsolete DESCRIPTION "The number of ICMP Neighbor Advertisement messages sent by the interface. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 30 } ipv6IfIcmpOutRedirects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 31 } ipv6IfIcmpOutGroupMembQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMPv6 Group Membership Query messages sent. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 32} ipv6IfIcmpOutGroupMembResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMPv6 Group Membership Response messages sent. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 33} ipv6IfIcmpOutGroupMembReductions OBJECT-TYPE SYNTAX Counter32 Fenner Expires May 18, 2017 [Page 50] Internet-Draft ipv6-mibs-obsolete November 2016 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of ICMPv6 Group Membership Reduction messages sent. This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts in the row corresponding to this message type." ::= { ipv6IfIcmpEntry 34} -- conformance information ipv6IcmpConformance OBJECT IDENTIFIER ::= { ipv6IcmpMIB 2 } ipv6IcmpCompliances OBJECT IDENTIFIER ::= { ipv6IcmpConformance 1 } ipv6IcmpGroups OBJECT IDENTIFIER ::= { ipv6IcmpConformance 2 } -- compliance statements ipv6IcmpCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement for SNMPv2 entities which implement ICMPv6. This compliance statement has been obsoleted by IP-MIB::ipMIBCompliance2." MODULE -- this module MANDATORY-GROUPS { ipv6IcmpGroup } ::= { ipv6IcmpCompliances 1 } ipv6IcmpGroup OBJECT-GROUP OBJECTS { ipv6IfIcmpInMsgs, ipv6IfIcmpInErrors, ipv6IfIcmpInDestUnreachs, ipv6IfIcmpInAdminProhibs, ipv6IfIcmpInTimeExcds, ipv6IfIcmpInParmProblems, ipv6IfIcmpInPktTooBigs, ipv6IfIcmpInEchos, ipv6IfIcmpInEchoReplies, ipv6IfIcmpInRouterSolicits, ipv6IfIcmpInRouterAdvertisements, ipv6IfIcmpInNeighborSolicits, ipv6IfIcmpInNeighborAdvertisements, Fenner Expires May 18, 2017 [Page 51] Internet-Draft ipv6-mibs-obsolete November 2016 ipv6IfIcmpInRedirects, ipv6IfIcmpInGroupMembQueries, ipv6IfIcmpInGroupMembResponses, ipv6IfIcmpInGroupMembReductions, ipv6IfIcmpOutMsgs, ipv6IfIcmpOutErrors, ipv6IfIcmpOutDestUnreachs, ipv6IfIcmpOutAdminProhibs, ipv6IfIcmpOutTimeExcds, ipv6IfIcmpOutParmProblems, ipv6IfIcmpOutPktTooBigs, ipv6IfIcmpOutEchos, ipv6IfIcmpOutEchoReplies, ipv6IfIcmpOutRouterSolicits, ipv6IfIcmpOutRouterAdvertisements, ipv6IfIcmpOutNeighborSolicits, ipv6IfIcmpOutNeighborAdvertisements, ipv6IfIcmpOutRedirects, ipv6IfIcmpOutGroupMembQueries, ipv6IfIcmpOutGroupMembResponses, ipv6IfIcmpOutGroupMembReductions } STATUS obsolete DESCRIPTION "The ICMPv6 group of objects providing information specific to ICMPv6. This group has been obsoleted by IP-MIB::icmpStatsGroup." ::= { ipv6IcmpGroups 1 } END 5. Historic IPV6-UDP-MIB IPV6-UDP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, mib-2, experimental FROM SNMPv2-SMI Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; ipv6UdpMIB MODULE-IDENTITY LAST-UPDATED "201505282112Z" ORGANIZATION "IETF IPv6 MIB Working Group" CONTACT-INFO " Mike Daniele Fenner Expires May 18, 2017 [Page 52] Internet-Draft ipv6-mibs-obsolete November 2016 Postal: Compaq Computer Corporation 110 Spitbrook Rd Nashua, NH 03062. US Phone: +1 603 884 1423 Email: daniele@zk3.dec.com" DESCRIPTION "The obsolete MIB module for entities implementing UDP over IPv6. Use the UDP-MIB instead." REVISION "201505282112Z" DESCRIPTION "Obsoleting this MIB module; it has been replaced by the revised UDP-MIB (RFC4113)." REVISION "9801290000Z" DESCRIPTION "First revision, published as RFC2454" ::= { experimental 87 } -- objects specific to UDP for IPv6 udp OBJECT IDENTIFIER ::= { mib-2 7 } -- the UDP over IPv6 Listener table -- This table contains information about this entity's -- UDP/IPv6 endpoints. Only endpoints utilizing IPv6 addresses -- are contained in this table. This entity's UDP/IPv4 endpoints -- are contained in udpTable. ipv6UdpTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6UdpEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "A table containing UDP listener information for UDP/IPv6 endpoints. This table is obsoleted by UDP-MIB::udpEndpointTable." ::= { udp 6 } ipv6UdpEntry OBJECT-TYPE SYNTAX Ipv6UdpEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "Information about a particular current UDP listener. Fenner Expires May 18, 2017 [Page 53] Internet-Draft ipv6-mibs-obsolete November 2016 Note that conceptual rows in this table require an additional index object compared to udpTable, since IPv6 addresses are not guaranteed to be unique on the managed node. This entry is obsoleted by UDP-MIB::udpEndpointTable." INDEX { ipv6UdpLocalAddress, ipv6UdpLocalPort, ipv6UdpIfIndex } ::= { ipv6UdpTable 1 } Ipv6UdpEntry ::= SEQUENCE { ipv6UdpLocalAddress Ipv6Address, ipv6UdpLocalPort INTEGER, ipv6UdpIfIndex Ipv6IfIndexOrZero } ipv6UdpLocalAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The local IPv6 address for this UDP listener. In the case of a UDP listener which is willing to accept datagrams for any IPv6 address associated with the managed node, the value ::0 is used. This object is obsoleted by UDP-MIB::udpEndpointLocalAddress." ::= { ipv6UdpEntry 1 } ipv6UdpLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The local port number for this UDP listener. This object is obsoleted by UDP-MIB::udpEndpointLocalPort." ::= { ipv6UdpEntry 2 } ipv6UdpIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS read-only STATUS obsolete DESCRIPTION "An index object used to disambiguate conceptual rows in the table, since the ipv6UdpLocalAddress/ipv6UdpLocalPort pair may not be unique. Fenner Expires May 18, 2017 [Page 54] Internet-Draft ipv6-mibs-obsolete November 2016 This object identifies the local interface that is associated with ipv6UdpLocalAddress for this UDP listener. If such a local interface cannot be determined, this object should take on the value 0. (A possible example of this would be if the value of ipv6UdpLocalAddress is ::0.) The interface identified by a particular non-0 value of this index is the same interface as identified by the same value of ipv6IfIndex. The value of this object must remain constant during the life of this UDP endpoint. This object is obsoleted by the zone identifier in an InetAddressIPv6z address in UDP-MIB::udpEndpointLocalAddress." ::= { ipv6UdpEntry 3 } -- -- conformance information -- ipv6UdpConformance OBJECT IDENTIFIER ::= { ipv6UdpMIB 2 } ipv6UdpCompliances OBJECT IDENTIFIER ::= { ipv6UdpConformance 1 } ipv6UdpGroups OBJECT IDENTIFIER ::= { ipv6UdpConformance 2 } -- compliance statements ipv6UdpCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement for SNMPv2 entities which implement UDP over IPv6. This object is obsoleted by UDP-MIB::udpMIBCompliance2." MODULE -- this module MANDATORY-GROUPS { ipv6UdpGroup } ::= { ipv6UdpCompliances 1 } ipv6UdpGroup OBJECT-GROUP OBJECTS { -- these are defined in this module -- ipv6UdpLocalAddress (not-accessible) -- ipv6UdpLocalPort (not-accessible) ipv6UdpIfIndex } STATUS obsolete DESCRIPTION "The group of objects providing management of Fenner Expires May 18, 2017 [Page 55] Internet-Draft ipv6-mibs-obsolete November 2016 UDP over IPv6. This group is obsoleted by several groups in UDP-MIB." ::= { ipv6UdpGroups 1 } END 6. Historic IPV6-TCP-MIB IPV6-TCP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, mib-2, experimental FROM SNMPv2-SMI Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; ipv6TcpMIB MODULE-IDENTITY LAST-UPDATED "201505282112Z" ORGANIZATION "IETF IPv6 MIB Working Group" CONTACT-INFO " Mike Daniele Postal: Compaq Computer Corporation 110 Spitbrook Rd Nashua, NH 03062. US Phone: +1 603 884 1423 Email: daniele@zk3.dec.com" DESCRIPTION "The obsolete MIB module for entities implementing TCP over IPv6. Use the TCP-MIB instead." REVISION "201505282112Z" DESCRIPTION "Obsoleting this MIB module; it has been replaced by the revised TCP-MIB (RFC4022)." REVISION "9801290000Z" DESCRIPTION "First revision, published as RFC2452" ::= { experimental 86 } -- objects specific to TCP for IPv6 tcp OBJECT IDENTIFIER ::= { mib-2 6 } -- the TCP over IPv6 Connection table Fenner Expires May 18, 2017 [Page 56] Internet-Draft ipv6-mibs-obsolete November 2016 -- This connection table contains information about this -- entity's existing TCP connections between IPv6 endpoints. -- Only connections between IPv6 addresses are contained in -- this table. This entity's connections between IPv4 -- endpoints are contained in tcpConnTable. ipv6TcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6TcpConnEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "A table containing TCP connection-specific information, for only those connections whose endpoints are IPv6 addresses. This table is obsoleted by TCP-MIB::tcpConnectionTable." ::= { tcp 16 } ipv6TcpConnEntry OBJECT-TYPE SYNTAX Ipv6TcpConnEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "A conceptual row of the ipv6TcpConnTable containing information about a particular current TCP connection. Each row of this table is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state. Note that conceptual rows in this table require an additional index object compared to tcpConnTable, since IPv6 addresses are not guaranteed to be unique on the managed node. This entry is obsoleted by TCP-MIB::tcpConnectionEntry." INDEX { ipv6TcpConnLocalAddress, ipv6TcpConnLocalPort, ipv6TcpConnRemAddress, ipv6TcpConnRemPort, ipv6TcpConnIfIndex } ::= { ipv6TcpConnTable 1 } Ipv6TcpConnEntry ::= SEQUENCE { ipv6TcpConnLocalAddress Ipv6Address, ipv6TcpConnLocalPort INTEGER, ipv6TcpConnRemAddress Ipv6Address, ipv6TcpConnRemPort INTEGER, ipv6TcpConnIfIndex Ipv6IfIndexOrZero, ipv6TcpConnState INTEGER } Fenner Expires May 18, 2017 [Page 57] Internet-Draft ipv6-mibs-obsolete November 2016 ipv6TcpConnLocalAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The local IPv6 address for this TCP connection. In the case of a connection in the listen state which is willing to accept connections for any IPv6 address associated with the managed node, the value ::0 is used. This object is obsoleted by TCP-MIB::tcpConnectionLocalAddressType." ::= { ipv6TcpConnEntry 1 } ipv6TcpConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The local port number for this TCP connection. This object is obsoleted by TCP-MIB::tcpConnectionLocalPort." ::= { ipv6TcpConnEntry 2 } ipv6TcpConnRemAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The remote IPv6 address for this TCP connection. This object is obsoleted by TCP-MIB::tcpConnectionRemAddress." ::= { ipv6TcpConnEntry 3 } ipv6TcpConnRemPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The remote port number for this TCP connection. This object is obsoleted by TCP-MIB::tcpConnectionRemPort." ::= { ipv6TcpConnEntry 4 } ipv6TcpConnIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS not-accessible Fenner Expires May 18, 2017 [Page 58] Internet-Draft ipv6-mibs-obsolete November 2016 STATUS obsolete DESCRIPTION "An index object used to disambiguate conceptual rows in the table, since the connection 4-tuple may not be unique. If the connection's remote address (ipv6TcpConnRemAddress) is a link-local address and the connection's local address (ipv6TcpConnLocalAddress) is not a link-local address, this object identifies a local interface on the same link as the connection's remote link-local address. Otherwise, this object identifies the local interface that is associated with the ipv6TcpConnLocalAddress for this TCP connection. If such a local interface cannot be determined, this object should take on the value 0. (A possible example of this would be if the value of ipv6TcpConnLocalAddress is ::0.) The interface identified by a particular non-0 value of this index is the same interface as identified by the same value of ipv6IfIndex. The value of this object must remain constant during the life of the TCP connection. This object is obsoleted by the zone identifier in an InetAddressIPv6z address in either TCP-MIB::tcpConnectionLocalAddress or TCP-MIB::tcpConnectionRemAddress." ::= { ipv6TcpConnEntry 5 } ipv6TcpConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) } MAX-ACCESS read-write STATUS obsolete DESCRIPTION "The state of this TCP connection. Fenner Expires May 18, 2017 [Page 59] Internet-Draft ipv6-mibs-obsolete November 2016 The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return an error response (`badValue' for SNMPv1, 'wrongValue' for SNMPv2) if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably). This object is obsoleted by TCP-MIB::tcpConnectionState." ::= { ipv6TcpConnEntry 6 } -- -- conformance information -- ipv6TcpConformance OBJECT IDENTIFIER ::= { ipv6TcpMIB 2 } ipv6TcpCompliances OBJECT IDENTIFIER ::= { ipv6TcpConformance 1 } ipv6TcpGroups OBJECT IDENTIFIER ::= { ipv6TcpConformance 2 } -- compliance statements ipv6TcpCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement for SNMPv2 entities which implement TCP over IPv6. This compliance statement is obsoleted by TCP-MIB::tcpMIBCompliance2." MODULE -- this module MANDATORY-GROUPS { ipv6TcpGroup } ::= { ipv6TcpCompliances 1 } ipv6TcpGroup OBJECT-GROUP OBJECTS { -- these are defined in this module -- ipv6TcpConnLocalAddress (not-accessible) -- ipv6TcpConnLocalPort (not-accessible) -- ipv6TcpConnRemAddress (not-accessible) -- ipv6TcpConnRemPort (not-accessible) Fenner Expires May 18, 2017 [Page 60] Internet-Draft ipv6-mibs-obsolete November 2016 -- ipv6TcpConnIfIndex (not-accessible) ipv6TcpConnState } STATUS obsolete DESCRIPTION "The group of objects providing management of TCP over IPv6. This group is obsoleted by several groups in TCP-MIB." ::= { ipv6TcpGroups 1 } END 7. Reclassification This document reclassifies [RFC2452], [RFC2454], [RFC2465], and [RFC2466] to Historic. 8. Security Considerations This document contains only obsolete objects, which [RFC2578] says "should not be implemented and/or can be removed if previously implemented". Since the contents of this document should not be implemented, it has no security implications. If there were any security implications based on these objects in an implementation, removing these objects as [RFC2578] suggests would improve the security of that implementation. 9. IANA Considerations In smi-numbers [1], the entries for RFC2452 and RFC2454, in the "SMI Experimental Codes" section, have an annotation "(Historic)" or "(Historical)". IANA is asked to make the following changes to the "SMI Network Management MGMT Codes Internet-standard MIB" section: o Remove RFC1213 from the references for mib-2.5 "icmp". o Update the reference for mib-2.6 "tcp" to point to RFC4022. o Remove RFC1213 from the references for mib-2.7 "udp". o Remove RFC2012 from the references for mib-2.49 "tcpMIB". o Add the "(Historic)" annotation for the entries for mib-2.55 "ipv6MIB" and for mib-2.56 "ipv6IcmpMIB", and update the reference to point to this document. Fenner Expires May 18, 2017 [Page 61] Internet-Draft ipv6-mibs-obsolete November 2016 IANA is asked to make the following changes to the "SMI Experimental Codes" section: o Add the "(Historic)" annotation for experimental.74 "IPV6 MIB" o Change the "(Historical)" annotation for experimental.87 "ipv6UdpMIB" to "(Historic)" o Update the reference for experimental.86 "ipv6TcpMIB" and experimental.87 "ipv6UdpMIB" to point to this document. 10. References 10.1. Normative References [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/ RFC2578, April 1999, . 10.2. Informative References [RFC2452] Daniele, M., "IP Version 6 Management Information Base for the Transmission Control Protocol", RFC 2452, DOI 10.17487/RFC2452, December 1998, . [RFC2454] Daniele, M., "IP Version 6 Management Information Base for the User Datagram Protocol", RFC 2454, DOI 10.17487/ RFC2454, December 1998, . [RFC2465] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, DOI 10.17487/RFC2465, December 1998, . [RFC2466] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: ICMPv6 Group", RFC 2466, DOI 10.17487/ RFC2466, December 1998, . [RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005, . Fenner Expires May 18, 2017 [Page 62] Internet-Draft ipv6-mibs-obsolete November 2016 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, DOI 10.17487/ RFC4113, June 2005, . [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, DOI 10.17487/RFC4292, April 2006, . [RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, April 2006, . 10.3. URIs [1] http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml Appendix A. Change history A.1. Changes since draft-ietf-6man-ipv6-mibs-obsolete-01 o Thanks to ops-dir comments by Dan Romascanu and Juergen Schoenwaelder, updated the motiviation text to include Juergen's ASCII art history and a specific mention that this is not the intended disposition of all obsolete MIBs. o Thanks to gen-art review by Jouni Korhonen, who pointed out that I had neglected RFC2579's requirement to note the obsoleting object for TEXTUAL-CONVENTIONs too. A.2. Changes since draft-ietf-6man-ipv6-mibs-obsolete-00 Thanks to an excellent review by Mike Heard. o Correct the REVISION clause for the original IPV6-MIB o Remove the illegal sub-typing from SEQUENCE definitions in IPV6-MIB, IPV6-UDP-MIB and IPV6-TCP-MIB. A.3. Changes since draft-fenner-ipv6-mibs-obsolete-00 o Realized that IPV6-ICMP-MIB was [RFC2466], so modified the added REVISION clause and the Reclassification section. o Added Security Considerations o Added IANA Considerations Fenner Expires May 18, 2017 [Page 63] Internet-Draft ipv6-mibs-obsolete November 2016 o Added the 6.c.iii Legend to the copyright statement, since the original RFCs were published before pre-5378. o Used "MIB module" instead of "MIB" when referring to a module, and changed REVISION DESCRIPTION to "Obsoleting", not "Deprecating". o Added "Obsoletes:" header to document o Switched to pre-5378 IPR statement, since the original RFCs were pre-5378. A.4. Changes since draft-fenner-ipv6-mibs-obsolete-01 o Updated the DESCRIPTION of MODULE-IDENTITY to improve the "MIB index" problem. o Updated IANA considerations. A.5. Changes since draft-fenner-ipv6-mibs-obsolete-02 o Fixed "IPV6-MIB" in title o Fixed some extra blank lines in the source MIBs, introduced by the process of extraction from RFCs. Author's Address Bill Fenner Arista Networks, Inc. 5453 Great America Parkway Santa Clara 95054 USA Phone: +1-408-547-5572 Email: fenner@fenron.com Fenner Expires May 18, 2017 [Page 64] ./draft-ietf-ice-dualstack-fairness-07.txt0000664000764400076440000005521213012160114017674 0ustar iustyiusty ICE P. Martinsen Internet-Draft T. Reddy Intended status: Best Current Practice P. Patil Expires: May 18, 2017 Cisco November 14, 2016 ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines draft-ietf-ice-dualstack-fairness-07 Abstract This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 18, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Martinsen, et al. Expires May 18, 2017 [Page 1] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 3. ICE Multihomed Recomendations . . . . . . . . . . . . . . . . 3 4. ICE Dual Stack Recomendations . . . . . . . . . . . . . . . . 4 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 7.1. ICE-Dual Stack Fairness Test code . . . . . . . . . . . . 8 7.2. ICE-Dual Stack Fairness Test code . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In multihomed and IPv4/IPv6 dual-stack environments ICE [I-D.ietf-ice-rfc5245bis] would benefit by a fair distribution of its connectivity checks across available interfaces or IP address types. With a fair distribution of the connectivity checks, excessive delays are avoided if a particular network path is broken or slow. It would arguably be better to put the interfaces or address types known to the application last in the checklist. However, the main motivation by ICE is to make no assumptions regarding network topology, hence a fair distribution of the connectivity checks is more appropriate. If an application operates in a well-known environment is can safely override the recommendation given in this document. Applications should take special care to deprioritize network interfaces known to provide unreliable connectivity when operating in a multihomed environment. For example, certain tunnel services might provide unreliable connectivity. Doing so will ensure a more fair distribution of the connectivity checks across available network interfaces on the device. The simple guidelines presented here describe how to deprioritize interfaces known by the application to provide unreliable connectivity. There is also a need to introduce better handling of connectivity checks for different IP address families in dual-stack IPv4/IPv6 ICE scenarios. Following the recommendations from RFC6724 [RFC6724] will lead to prioritization of IPv6 over IPv4 for the same candidate type. Martinsen, et al. Expires May 18, 2017 [Page 2] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 Due to this, connectivity checks for candidates of the same type (host, reflexive or relay) are sent such that an IP address family is completely depleted before checks from the other address family are started. This results in user noticeable setup delays if the path for the prioritized address family is broken. To avoid user noticeable delays when either IPv6 or IPv4 path is broken or excessively slow, this specification encourages intermingling the different address families when connectivity checks are performed. This will lead to more sustained dual-stack IPv4/IPv6 deployment as users will no longer have an incentive to disable IPv6. The cost is a small penalty to the address type that otherwise would have been prioritized. Further this document recommends to keep track of previous known connectivity problem and assign a lower priority to those addresses. Specific mechanisms and rules for tracking connectivity issues are out of scope for this document. This document describes what parameters an agent can safely alter to fairly order the checklist candidate pairs in multihomed and dual- stack environments, thus affecting the sending order of the connectivity checks. Actual values of those parameters is an implementation detail. Dependant on the nomination method in use, this might have an effect on what candidate pair ends up as the active one. Ultimately it should be up to the agent to decide what candidate pair is best suited for transporting media. The guidelines outlined in this specification are backward compatible with a standard ICE implementation. This specification only alters the values used to create the resulting checklists in such a way that the core mechanisms from ICE [RFC5245] and ICEbis [I-D.ietf-ice-rfc5245bis] are still in effect. 2. Notational Conventions This document uses terminology defined in [I-D.ietf-ice-rfc5245bis]. 3. ICE Multihomed Recomendations A multihomed ICE agent can potentially send and receive connectivity checks on all available interfaces and IP addresses. It is possible for an interface to have several IP addresses associated with it. To avoid unnecessary delay when performing connectivity checks it would be beneficial to prioritize interfaces and IP addresses known by the agent to provide stable connectivity. The application knowledge regarding the reliability of an interface can also be based on simple metrics like previous connection success/ failure rates or a more static model based on interface types like Martinsen, et al. Expires May 18, 2017 [Page 3] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 wired, wireless, cellular, virtual, tunneled in conjunction with other operational metrics. This would require the application to have the right permissions to obtain such operational metrics. Candidates from an interface known to the application to provide unreliable connectivity should get a low candidate priority. When to consider connectivity as unreliable is implementation specific. Usage of ICE is not limited to VoIP applications. What an application sees as unreliability might be determined by a mix of how long lived the connection is, how often setup is required and others, for now unknown, requirements. This is purely an optimization to speed up the ICE connectivity check phase. If the application is unable to get any interface information regarding type or unable to store any relevant metrics, it should treat all interfaces as if they have reliable connectivity. This ensures all interfaces gets their fair chance to perform their connectivity checks. 4. ICE Dual Stack Recomendations Candidates should be prioritized such that a sequence of candidates belonging to the same address family will be intermingled with candidates from an alternate IP family. For example, promoting IPv4 candidates in the presence of many IPv6 candidates such that an IPv4 address candidate is always present after a small sequence of IPv6 candidates, i.e., reordering candidates such that both IPv6 and IPv4 candidates get a fair chance during the connectivity check phase. This makes ICE connectivity checks more responsive to broken path failures of an address family. An ICE agent can choose an algorithm or a technique of its choice to ensure that the resulting check lists have a fair intermingled mix of IPv4 and IPv6 address families. However, modifying the check list directly can lead to uncoordinated local and remote check lists that result in ICE taking longer to complete or in the worst case scenario fail. The best approach is to set the appropriate value for local preference in the formula for calculating the candidate priority value described in ICE [I-D.ietf-ice-rfc5245bis] section "4.1.2.1 Recommended Formula". Implementations should prioritize IPv6 candidates by putting some of them first in the intermingled checklist. This increases the chance of IPv6 connectivity checks to complete first and be ready for nomination or usage. This enables implementations to follow the intent of [RFC6555] "Happy Eyeballs: Success with Dual-Stack Hosts". It is worth noting that the timing recommendations in [RFC6555] will be overruled by how ICE paces out its connectivity checks. Martinsen, et al. Expires May 18, 2017 [Page 4] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 A simple formula to calculate how many IPv6 addresses to put before any IPv4 addresses could look like: Hi = (N_4 + N_6) / N_4 Where Hi = Head start before intermingling starts N_4 = Number of IPv4 addresses N_6 = Number of IPv6 addresses If a host have 2 IPv4 addresses and 6 IPv6 addresses, it will insert an IP4 address after 4 IPv6 addresses by choosing the appropriate local preference values when calculating the pair priorities. 5. Compatibility ICE [I-D.ietf-ice-rfc5245bis] section "4.1.2 Prioritizing Candidates" states that the formula in section "4.1.2.1 Recommended Formula" should be used to calculate the candidate priority. The formula is as follows: priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID) ICE [I-D.ietf-ice-rfc5245bis] section "4.1.2.2 Guidelines for Choosing Type and Local Preferences" has guidelines for how the type preference and local preference value should be chosen. Instead of having a static local preference value for IPv4 and IPv6 addresses, it is possible to choose this value dynamically in such a way that IPv4 and IPv6 address candidate priorities end up intermingled within the same candidate type. It is also possible to assign lower priorities to IP addresses derived from unreliable interfaces using the local preference value. It is worth mentioning that [I-D.ietf-ice-rfc5245bis] section "4.1.2.1 Recommended Formula" says that; "if there are multiple candidates for a particular component for a particular media stream that has the same type, the local preference MUST be unique for each one". The local type preference can be dynamically changed in such a way that IPv4 and IPv6 address candidates end up intermingled regardless of candidate type. This is useful if there are a lot of IPv6 host candidates effectively blocking connectivity checks for IPv4 server reflexive candidates. Martinsen, et al. Expires May 18, 2017 [Page 5] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 Candidates with IP addresses from an unreliable interface should be ordered at the end of the checklist, i.e., not intermingled as the dual-stack candidates. The list below shows a sorted local candidate list where the priority is calculated in such a way that the IPv4 and IPv6 candidates are intermingled (No multihomed candidates). To allow for earlier connectivity checks for the IPv4 server reflexive candidates, some of the IPv6 host candidates are demoted. This is just an example of how a candidate priorities can be calculated to provide better fairness between IPv4 and IPv6 candidates without breaking any of the ICE connectivity checks. Candidate Address Component Type Type ID Priority ------------------------------------------- (1) HOST IPv6 (1) 2129289471 (2) HOST IPv6 (2) 2129289470 (3) HOST IPv4 (1) 2129033471 (4) HOST IPv4 (2) 2129033470 (5) HOST IPv6 (1) 2128777471 (6) HOST IPv6 (2) 2128777470 (7) HOST IPv4 (1) 2128521471 (8) HOST IPv4 (2) 2128521470 (9) HOST IPv6 (1) 2127753471 (10) HOST IPv6 (2) 2127753470 (11) SRFLX IPv6 (1) 1693081855 (12) SRFLX IPv6 (2) 1693081854 (13) SRFLX IPv4 (1) 1692825855 (14) SRFLX IPv4 (2) 1692825854 (15) HOST IPv6 (1) 1692057855 (16) HOST IPv6 (2) 1692057854 (17) RELAY IPv6 (1) 15360255 (18) RELAY IPv6 (2) 15360254 (19) RELAY IPv4 (1) 15104255 (20) RELAY IPv4 (2) 15104254 SRFLX = server reflexive Note that the list does not alter the component ID part of the formula. This keeps the different components (RTP and RTCP) close in the list. What matters is the ordering of the candidates with component ID 1. Once the checklist is formed for a media stream the candidate pair with component ID 1 will be tested first. If ICE connectivity check is successful then other candidate pairs with the Martinsen, et al. Expires May 18, 2017 [Page 6] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 same foundation will be unfrozen ([I-D.ietf-ice-rfc5245bis] section 5.1.3.4. Computing States). The local and remote agent can have different algorithms for choosing the local preference and type preference values without impacting the synchronization between the local and remote check lists. The check list is made up of candidate pairs. A candidate pair is two candidates paired up and given a candidate pair priority as described in [I-D.ietf-ice-rfc5245bis] section 5.1.3.2. Using the pair priority formula: pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) Where G is the candidate priority provided by the controlling agent and D the candidate priority provided by the controlled agent. This ensures that the local and remote check lists are coordinated. Even if the two agents have different algorithms for choosing the candidate priority value to get an intermingled set of IPv4 and IPv6 candidates, the resulting checklist, that is a list sorted by the pair priority value, will be identical on the two agents. The agent that has promoted IPv4 cautiously i.e. lower IPv4 candidate priority values compared to the other agent, will influence the check list the most due to (2^32*MIN(G,D)) in the formula. These recommendations are backward compatible with a standard ICE implementation. The resulting local and remote checklist will still be synchronized. Dependant of the nomination method in use the procedures described in this document might change what candidate pair ends up as the active one. A test implementation of an example algorithm is available at [ICE_dualstack_imp]. 6. IANA Considerations None. 7. Implementation Status [Note to RFC Editor: Please remove this section and reference to [RFC6982] prior to publication.] Martinsen, et al. Expires May 18, 2017 [Page 7] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC6982], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 7.1. ICE-Dual Stack Fairness Test code Organization: Cisco Description: Open-Source ICE, TURN and STUN implementation. Implementation: https://github.com/palerikm/ICE-DualStackFairness Level of maturity: Code is stable. Coverage: Follows the recommendations in this document Licensing: BSD Implementation experience: Straightforward as there are no compatibility issues. Contact: Paal-Erik Martinsen palmarti@cisco.com 7.2. ICE-Dual Stack Fairness Test code Organization: Others Description: Major ICE implementations, browser based and stand- alone ICE, TURN and STUN implementations. Implementation: Product specific. Martinsen, et al. Expires May 18, 2017 [Page 8] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 Level of maturity: Code is stable and available in the wild. Coverage: Implements the recommendations in this document. Licensing: Some open source, some close source Implementation experience: Already implemented in some of the implementations. This document describes what needs to be done to achieve the desired fairness. 8. Security Considerations The security considerations described in [I-D.ietf-ice-rfc5245bis] are still valid. It changes recommended values and describes how an agent could choose those values in a safe way. In section Section 3 the agent can prioritize the network interface based on previous network knowledge. This can potentially be unwanted information leakage towards the remote agent. 9. Acknowledgements Authors would like to thank Dan Wing, Ari Keranen, Bernard Aboba, Martin Thomson, Jonathan Lennox, Balint Menyhart, Ole Troan, Simon Perreault, Ben Cambell and Mirja Kuehlewind for their comments and review. 10. References 10.1. Normative References [I-D.ietf-ice-rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-05 (work in progress), October 2016. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, . Martinsen, et al. Expires May 18, 2017 [Page 9] Internet-Draft ICE Multihomed and DualStack Guidelines November 2016 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, . 10.2. Informative References [ICE_dualstack_imp] Martinsen, P., "ICE DualStack Test Implementation github repo", . Authors' Addresses Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens Vei 22 Lysaker, Akershus 1325 Norway Email: palmarti@cisco.com Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Prashanth Patil Cisco Systems, Inc. Bangalore India Email: praspati@cisco.com Martinsen, et al. Expires May 18, 2017 [Page 10] ./draft-ietf-appsawg-file-scheme-16.txt0000664000764400076440000010763513024633161017215 0ustar iustyiusty Applications Area Working Group M. Kerwin Internet-Draft QUT Updates: 1738 (if approved) December 16, 2016 Intended status: Standards Track Expires: June 19, 2017 The file URI Scheme draft-ietf-appsawg-file-scheme-16 Abstract This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme, replacing the very brief definition in Section 3.10 of RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 19, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Kerwin Expires June 19, 2017 [Page 1] Internet-Draft file-scheme December 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operations Involving file URIs . . . . . . . . . . . . . . . 5 4. File System Name Encoding . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Differences from Previous Specifications . . . . . . 9 Appendix B. Example URIs . . . . . . . . . . . . . . . . . . . . 9 Appendix C. Similar Technologies . . . . . . . . . . . . . . . . 10 Appendix D. System-Specific Operations . . . . . . . . . . . . . 10 D.1. POSIX Systems . . . . . . . . . . . . . . . . . . . . . . 11 D.2. DOS- and Windows-Like Systems . . . . . . . . . . . . . . 11 D.3. Mac OS X Systems . . . . . . . . . . . . . . . . . . . . 11 D.4. OpenVMS Files-11 Systems . . . . . . . . . . . . . . . . 11 Appendix E. Nonstandard Syntax Variations . . . . . . . . . . . 11 E.1. User Information . . . . . . . . . . . . . . . . . . . . 12 E.2. DOS and Windows Drive Letters . . . . . . . . . . . . . . 12 E.2.1. Relative Resolution . . . . . . . . . . . . . . . . . 13 E.2.2. Vertical Line Character . . . . . . . . . . . . . . . 13 E.3. UNC Strings . . . . . . . . . . . . . . . . . . . . . . . 14 E.3.1. file URI with Authority . . . . . . . . . . . . . . . 14 E.3.2. file URI with UNC Path . . . . . . . . . . . . . . . 15 E.4. Backslash as Separator . . . . . . . . . . . . . . . . . 16 Appendix F. Collected Nonstandard Rules . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction A file URI identifies an object (a "file") stored in a structured object naming and accessing environment on a host (a "file system.") The URI can be used in discussions about the file, and if other Kerwin Expires June 19, 2017 [Page 2] Internet-Draft file-scheme December 2016 conditions are met it can be dereferenced to directly access the file. This document specifies a syntax based on the generic syntax of [RFC3986] that is compatible with most existing usages. Where incompatibilities arise they are usually in parts of the scheme that were underspecified in earlier definitions and have been tightened up by more recent specifications. Appendix A lists significant changes to syntax. Extensions to the syntax which might be encountered in practice are listed in Appendix E; these extensions are listed for informational purposes and are not a requirement of implementation. The file URI scheme is not coupled with a specific protocol, nor with a specific media type [RFC6838]. See Section 3 for a discussion of operations that can be performed on the object identified by a file URI. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning. Throughout this document the term "local file" is used to describe files that can be accessed through the local file system API using only the information included in the file path, not relying on other information (such as network addresses.) It is important to note that a local file may not be physically located on the local machine, for example if a networked file system is transparently mounted into the local file system. The term "local file URI" is used to describe file URIs which have no "authority" component, or where the authority is the special string "localhost" or a fully qualified domain name that resolves to the machine from which the URI is being interpreted (Section 2). 2. Syntax The file URI syntax is defined here in Augmented Backus-Naur Form (ABNF) [RFC5234], importing the "host" and "path-absolute" rules from [RFC3986] (as updated by [RFC6874].) The generic syntax in [RFC3986] includes "path" and "authority" components, for each of which only a subset is used in the definition Kerwin Expires June 19, 2017 [Page 3] Internet-Draft file-scheme December 2016 of the file URI scheme. The relevant subset of "path" is "path- absolute", and the subset of "authority" is "file-auth", given below. The syntax definition below is different from those given in [RFC1630] and [RFC1738] as it is derived from the generic syntax of [RFC3986], which post-dates the previous file URI specifications. Appendix A enumerates significant differences. file-URI = file-scheme ":" file-hier-part file-scheme = "file" file-hier-part = ( "//" auth-path ) / local-path auth-path = [ file-auth ] path-absolute local-path = path-absolute file-auth = "localhost" / host The "host" is the fully qualified domain name of the system on which the file is accessible. This allows a client on another system to know that it cannot access the file system, or perhaps that it needs to use some other local mechanism to access the file. As a special case, the "file-auth" rule can match the string "localhost" which is interpreted as "the machine from which the URI is being interpreted," exactly as if no authority were present. Some current usages of the scheme incorrectly interpret all values in the authority of a file URI, including "localhost", as non-local. Yet others interpret any value as local, even if the "host" does not resolve to the local machine. To maximize compatibility with previous specifications, users MAY choose to include an "auth-path" with no "file-auth" when creating a URI. The path component represents the absolute path to the file in the file system. See Appendix D for some discussion of system-specific concerns including absolute file paths and file system roots. Some file systems have case-sensitive file naming and some do not. As such the file URI scheme supports case sensitivity, in order to retain the case as given. Any transport-related handling of the file URI scheme MUST retain the case as given. Any mapping to or from a case-insensitive form is solely the responsibility of the implementation processing the file URI on behalf of the referenced file system. Kerwin Expires June 19, 2017 [Page 4] Internet-Draft file-scheme December 2016 Also see Appendix E that lists some nonstandard syntax variations that can be encountered in practice. 3. Operations Involving file URIs See the POSIX file and directory operations [POSIX] for examples of standardized operations that can be performed on files. A file URI can be dependably dereferenced or translated to a local file path only if it is local. A file URI is considered "local" if it has no "file-auth", or the "file-auth" is the special string "localhost" or a fully qualified domain name that resolves to the machine from which the URI is being interpreted (Section 2). This specification neither defines nor forbids any set of operations that might be performed on a file identified by a non-local file URI. 4. File System Name Encoding File systems use various encoding schemes to store file and directory names. Many modern file systems store file and directory names as arbitrary sequences of octets, in which case the representation as an encoded string often depends on the user's localization settings, or defaults to UTF-8 [STD63]. When a file URI is produced that represents textual data consisting of characters from the Unicode Standard coded character set [UNICODE], the data SHOULD be encoded as octets according to the UTF-8 character encoding scheme [STD63] before percent-encoding is applied; as per [RFC3986], Section 2.5. A decision not to use percent-encoded UTF-8 is outside the scope of this specification. It will typically require the use of heuristics or explicit knowledge about the way the string will be processed. 5. Security Considerations There are many security considerations for URI schemes discussed in [RFC3986]. File access and the granting of privileges for specific operations are complex topics, and the use of file URIs can complicate the security model in effect for file privileges. Historically, user agents have granted content from the file URI scheme a tremendous amount of privilege. However, granting all local files such wide privileges can lead to privilege escalation attacks. Some user agents have had success granting local files directory- Kerwin Expires June 19, 2017 [Page 5] Internet-Draft file-scheme December 2016 based privileges, but this approach has not been widely adopted. Other user agents use globally unique identifiers as the origin for each file URI [RFC6454], which is the most secure option. Treating a non-local file URI as local or otherwise attempting to perform local operations on a non-local URI can result in security problems. File systems typically assign an operational meaning to special characters, such as the "/", "\", ":", "[", and "]" characters, and to special device names like ".", "..", "...", "aux", "lpt", etc. In some cases, merely testing for the existence of such a name will cause the operating system to pause or invoke unrelated system calls, leading to significant security concerns regarding denial of service and unintended data transfer. It would not be possible for this specification to list all such significant characters and device names. Implementers should research the reserved names and characters for the types of storage device that may be attached to their application and restrict the use of data obtained from URI components accordingly. File systems vary in the way they handle case. Care must be taken to avoid issues resulting from possibly unexpected aliasing from case- only differences between file paths or URIs, or from mismatched encodings or Unicode equivalences [UAX15] (see Section 4). 6. IANA Considerations This document defines the following URI scheme, so the "Permanent URI Schemes" registry has been updated accordingly. This registration complies with [BCP35]. Scheme name: file Status: permanent Applications/protocols that use this scheme name: Commonly used in hypertext documents to refer to files without depending on network access. Supported by major browsers. Used in development libraries, such as: * Windows Shell (PathCreateFromUrl, UrlCreateFromPath). * libwww-perl - The World-Wide Web library for Perl. Kerwin Expires June 19, 2017 [Page 6] Internet-Draft file-scheme December 2016 Contact: Applications and Real-Time Area Change Controller: This scheme is registered under the IETF tree. As such, the IETF maintains change control. References: This RFC. 7. Acknowledgements Contributions from many members of the IETF and W3C communities - notably Dave Crocker, Graham Klyne, Tom Petch, and John Klensin - are greatly appreciated. Additional thanks to Dave Risney, author of the informative IE Blog article , and Dave Thaler for their early comments and suggestions; and to Paul Hoffman, whose earlier work served as an inspiration for this undertaking. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . Kerwin Expires June 19, 2017 [Page 7] Internet-Draft file-scheme December 2016 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, February 2013, . [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . 8.2. Informative References [Bash-Tilde] Free Software Foundation, Inc, "Bash Reference Manual: Tilde Expansion", February 2014, . [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [Bug107540] Bugzilla@Mozilla, "Bug 107540", October 2007, . [MS-DTYP] Microsoft Open Specifications, "Windows Data Types, 2.2.57 UNC", October 2015, . [POSIX] IEEE, "IEEE Std 1003.1, 2013 Edition", 2013. [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, DOI 10.17487/RFC1630, June 1994, . [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, December 1994, . [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, DOI 10.17487/RFC2396, August 1998, . Kerwin Expires June 19, 2017 [Page 8] Internet-Draft file-scheme December 2016 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [UAX15] Davis, M., Ed. and K. Whistler, Ed., "Unicode Standard Annex #15: Unicode Normalization Forms", February 2016, . [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 9.0.0", ISBN 978-1-936213-13-9, June 2016, . [WHATWG-URL] WHATWG, "URL Standard", December 2016, . [Win32-Namespaces] Microsoft Developer Network, "Naming Files, Paths, and Namespaces", June 2013, . [Zsh-Tilde] "zsh: 14.7 Filename Expansion", December 2015, . Appendix A. Differences from Previous Specifications The syntax definition in Section 2 inherits incremental differences from the general syntax of [RFC1738] made by [RFC2396] ([RFC2396], Appendix G) and [RFC3986] ([RFC3986], Appendix D). According to the definition in [RFC1738] a file URL always started with the token "file://", followed by an (optionally blank) host name and a "/". The syntax given in Section 2 makes the entire authority component, including the double slashes "//", optional. Appendix B. Example URIs The syntax in Section 2 is intended to support file URIs that take the following forms: Local files: o A traditional file URI for a local file, with an empty authority. This is the most common format in use today. E.g.: Kerwin Expires June 19, 2017 [Page 9] Internet-Draft file-scheme December 2016 * "file:///path/to/file" o The minimal representation of a local file, with no authority field and an absolute path that begins with a slash "/". E.g.: * "file:/path/to/file" Non-local files: o A non-local file, with an explicit authority. E.g.: * "file://host.example.com/path/to/file" Appendix C. Similar Technologies o The WHATWG URL specification [WHATWG-URL] defines browser behavior for a variety of inputs, including file URIs. As a living document, it changes to reflect updates in browser behavior. As a result, its algorithms and syntax definitions may or may not be consistent with this specification. Implementors should be aware of this possible discrepancy if they expect to share file URIs with browsers that follow the WHATWG specification. o The Universal Naming Convention (UNC) [MS-DTYP] defines a string format that can perform a similar role to the file URI scheme in describing the location of files, except that files located by UNC filespace selector strings are typically stored on a remote machine and accessed using a network protocol. Appendix E.3 lists some ways in which UNC filespace selector strings are currently made to interoperate with the file URI scheme. o The Microsoft Windows API defines Win32 Namespaces [Win32-Namespaces] for interacting with files and devices using Windows API functions. These namespaced paths are prefixed by "\\?\" for Win32 File Namespaces and "\\.\" for Win32 Device Namespaces. There is also a special case for UNC file paths in Win32 File Namespaces, referred to as "Long UNC", using the prefix "\\?\UNC\". This specification does not define a mechanism for translating namespaced paths to or from file URIs. Appendix D. System-Specific Operations This appendix is not normative. It highlights some observed behaviours and provides system-specific guidance for interacting with file URIs and paths. This is not an exhaustive list of operating or file systems; rather it is intended to illustrate certain types of interactions that might be encountered. Kerwin Expires June 19, 2017 [Page 10] Internet-Draft file-scheme December 2016 D.1. POSIX Systems In a POSIX file system the root of the file system is represented as a directory with a zero-length name, usually written as "/"; the presence of this root in a file URI can be taken as given by the initial slash in the "path-absolute" rule. Common UNIX shells such as the Bourne-Again SHell (bash) and Z Shell (zsh) provide a function known as "tilde expansion" [Bash-Tilde] or "filename expansion" [Zsh-Tilde], where a path that begins with a tilde character "~" can be expanded out to a special directory name. No such facility exists using the file URI scheme; a tilde in a file URI is always just a tilde. D.2. DOS- and Windows-Like Systems When mapping a DOS- or Windows-like file path to a file URI, the drive letter (e.g. "c:") is typically mapped into the first path segment. Appendix E lists some nonstandard techniques for interacting with DOS- or Windows-like file paths and URIs. D.3. Mac OS X Systems The HFS+ file system uses a nonstandard normalization form, similar to Normalization Form D [UAX15]. Take care when transforming HFS+ file paths to and from URIs (Section 4). D.4. OpenVMS Files-11 Systems When mapping a VMS file path to a file URI, the device name is mapped into the first path segment. Note that the dollars sign "$" is a reserved character per the definition in [RFC3986], Section 2.2, so should be percent-encoded if present in the device name. If the VMS file path includes a node reference, that reference is used as the authority. Where the original node reference includes a user name and password in an access control string, they can be transcribed into the authority using the nonstandard syntax extension in Appendix E.1. Appendix E. Nonstandard Syntax Variations These variations may be encountered by existing usages of the file URI scheme, but are not supported by the normative syntax of Section 2. Kerwin Expires June 19, 2017 [Page 11] Internet-Draft file-scheme December 2016 This appendix is not normative. E.1. User Information It might be necessary to include user information such as a user name in a file URI, for example when mapping a VMS file path with a node reference that includes an access control string. To allow user information to be included in a file URI, the "file- auth" rule in Section 2 can be replaced with the following: file-auth = "localhost" / [ userinfo "@" ] host This uses the "userinfo" rule from [RFC3986]. As discussed in the HP OpenVMS Systems Documentation "access control strings include sufficient information to allow someone to break in to the remote account, [therefore] they create serious security exposure." In a similar vein, the presence of a password in a "user:password" userinfo field is deprecated by [RFC3986]. Take care when dealing with information that can be used to identify a user or grant access to a system. E.2. DOS and Windows Drive Letters On Windows- or DOS-like file systems an absolute file path can begin with a drive letter. To facilitate this, the "local-path" rule in Section 2 can be replaced with the following: local-path = [ drive-letter ] path-absolute drive-letter = ALPHA ":" The "ALPHA" rule is defined in [RFC5234]. This is intended to support the minimal representation of a local file in a DOS- or Windows-like environment, with no authority field and an absolute path that begins with a drive letter. E.g.: o "file:c:/path/to/file" URIs of the form "file:///c:/path/to/file" are already supported by the "path-absolute" rule. Note that comparison of drive letters in DOS or Windows file paths is case-insensitive. In some usages of file URIs drive letters are Kerwin Expires June 19, 2017 [Page 12] Internet-Draft file-scheme December 2016 canonicalized by converting them to uppercase, and other usages treat URIs that differ only in the case of the drive letter as identical. E.2.1. Relative Resolution To mimic the behaviour of DOS- or Windows-like file systems, relative references beginning with a slash "/" can be resolved relative to the drive letter, when present; and resolution of ".." dot segments (per Section 5.2.4 of [RFC3986]) can be modified to not ever overwrite the drive letter. For example: base URI: file:///c:/path/to/file.txt rel. ref.: /some/other/thing.bmp resolved: file:///c:/some/other/thing.bmp base URI: file:///c:/foo.txt rel. ref.: ../bar.txt resolved: file:///c:/bar.txt A relative reference starting with a drive letter would be interpreted by a generic URI parser as a URI with the drive letter as its scheme. Instead such a reference ought to be constructed with a leading slash "/" character (e.g. "/c:/foo.txt"). Relative references with a drive letter followed by a character other than a slash (e.g. "/c:bar/baz.txt" or "/c:../foo.txt") might not be accepted as dereferenceable URIs in DOS- or Windows-like systems. E.2.2. Vertical Line Character Historically some usages of file URIs have included a vertical line character "|" instead of a colon ":" in the drive letter construct. [RFC3986] forbids the use of the vertical line, however it may be necessary to interpret or update old URIs. For interpreting such URIs, the "auth-path" and "local-path" rules in Section 2 and the "drive-letter" rule above can be replaced with the following: Kerwin Expires June 19, 2017 [Page 13] Internet-Draft file-scheme December 2016 auth-path = [ file-auth ] path-absolute / [ file-auth ] file-absolute local-path = [ drive-letter ] path-absolute / file-absolute file-absolute = "/" drive-letter path-absolute drive-letter = ALPHA ":" / ALPHA "|" This is intended to support regular DOS or Windows file URIs with vertical line characters in the drive letter construct. E.g.: o "file:///c|/path/to/file" o "file:/c|/path/to/file" o "file:c|/path/to/file" To update such an old URI, replace the vertical line "|" with a colon ":". E.3. UNC Strings Some usages of the file URI scheme allow UNC filespace selector strings [MS-DTYP] to be translated to and from file URIs, either by mapping the equivalent segments of the two schemes (hostname to authority, sharename+objectnames to path), or by mapping the entire UNC string to the path segment of a URI. E.3.1. file URI with Authority The following is an algorithmic description of the process of translating a UNC filespace selector string to a file URI by mapping the equivalent segments of the two schemes: 1. Initialize the URI with the "file:" scheme identifier. 2. Append the authority: 1. Append the "//" authority sigil to the URI. 2. Append the host-name field of the UNC string to the URI. 3. Append the share-name: Kerwin Expires June 19, 2017 [Page 14] Internet-Draft file-scheme December 2016 1. Transform the share-name to a path segment ([RFC3986], Section 3.3) to conform to the encoding rules of Section 2 of [RFC3986]. 2. Append a delimiting slash character "/" and the transformed segment to the URI. 4. For each object-name: 1. Transform the objectname to a path segment as above. The colon character ":" is allowed as a delimiter before stream-name and stream-type in the file-name, if present. 2. Append a delimiting slash character "/" and the transformed segment to the URI. For example: UNC String: \\host.example.com\Share\path\to\file.txt URI: file://host.example.com/Share/path/to/file.txt The inverse algorithm, for translating a file URI to a UNC filespace selector string, is left as an exercise for the reader. E.3.2. file URI with UNC Path It is common to encounter file URIs that encode entire UNC strings in the path, usually with all backslash "\" characters replaced with slashes "/". To interpret such URIs, the "auth-path" rule in Section 2 can be replaced with the following: auth-path = [ file-auth ] path-absolute / unc-authority path-absolute unc-authority = 2*3"/" file-host file-host = inline-IP / IPv4address / reg-name inline-IP = "%5B" ( IPv6address / IPvFuture ) "%5D" This syntax uses the "IPv4address", "IPv6address", "IPvFuture", and "reg-name" rules from [RFC3986]. Note that the "file-host" rule is the same as "host" but with percent-encoding applied to "[" and "]" characters. Kerwin Expires June 19, 2017 [Page 15] Internet-Draft file-scheme December 2016 This extended syntax is intended to support URIs that take the following forms, in addition to those in Appendix B: Non-local files: o The representation of a non-local file, with an empty authority and a complete (transformed) UNC string in the path. E.g.: * "file:////host.example.com/path/to/file" o As above, with an extra slash between the empty authority and the transformed UNC string, as per the syntax defined in [RFC1738]. E.g.: * "file://///host.example.com/path/to/file" This representation is notably used by the Firefox web browser. See Bugzilla#107540 [Bug107540]. It also further limits the definition of a "local file URI" by excluding any file URI with a path that encodes a UNC string. E.4. Backslash as Separator Historically some usages have copied entire file paths into the path components of file URIs. Where DOS or Windows file paths were thus copied the resulting URI strings contained unencoded backslash "\" characters, which are forbidden by both [RFC1738] and [RFC3986]. It may be possible to translate or update such an invalid file URI by replacing all backslashes "\" with slashes "/", if it can be determined with reasonable certainty that the backslashes are intended as path separators. Appendix F. Collected Nonstandard Rules Here are the collected syntax rules for all optional appendices, presented for convenience. This collected syntax is not normative. Kerwin Expires June 19, 2017 [Page 16] Internet-Draft file-scheme December 2016 file-URI = file-scheme ":" file-hier-part file-scheme = "file" file-hier-part = ( "//" auth-path ) / local-path auth-path = [ file-auth ] path-absolute / [ file-auth ] file-absolute / unc-authority path-absolute local-path = [ drive-letter ] path-absolute / file-absolute file-auth = "localhost" / [ userinfo "@" ] host unc-authority = 2*3"/" file-host file-host = inline-IP / IPv4address / reg-name inline-IP = "%5B" ( IPv6address / IPvFuture ) "%5D" file-absolute = "/" drive-letter path-absolute drive-letter = ALPHA ":" / ALPHA "|" This collected syntax is intended to support file URIs that take the following forms: Local files: o A traditional file URI for a local file, with an empty authority. E.g.: * "file:///path/to/file" o The minimal representation of a local file, with no authority field and an absolute path that begins with a slash "/". E.g.: * "file:/path/to/file" o The minimal representation of a local file in a DOS- or Windows- based environment, with no authority field and an absolute path that begins with a drive letter. E.g.: * "file:c:/path/to/file" Kerwin Expires June 19, 2017 [Page 17] Internet-Draft file-scheme December 2016 o Regular DOS or Windows file URIs, with vertical line characters in the drive letter construct. E.g.: * "file:///c|/path/to/file" * "file:/c|/path/to/file" * "file:c|/path/to/file" Non-local files: o The representation of a non-local file, with an explicit authority. E.g.: * "file://host.example.com/path/to/file" o The "traditional" representation of a non-local file, with an empty authority and a complete (transformed) UNC string in the path. E.g.: * "file:////host.example.com/path/to/file" o As above, with an extra slash between the empty authority and the transformed UNC string. E.g.: * "file://///host.example.com/path/to/file" Author's Address Matthew Kerwin Queensland University of Technology Victoria Park Road Kelvin Grove, QLD 4059 Australia Email: matthew.kerwin@qut.edu.au Kerwin Expires June 19, 2017 [Page 18] ./draft-ietf-idr-large-community-12.txt0000664000764400076440000004245313033447605017262 0ustar iustyiusty IDR J. Heitz, Ed. Internet-Draft Cisco Intended status: Standards Track J. Snijders, Ed. Expires: July 9, 2017 NTT K. Patel Arrcus I. Bagdonas Equinix N. Hilliard INEX January 5, 2017 BGP Large Communities draft-ietf-idr-large-community-12 Abstract This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers including four-octet Autonomous System Numbers. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 9, 2017. Heitz, et al. Expires July 9, 2017 [Page 1] Internet-Draft BGP Large Communities January 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. BGP Large Communities Attribute . . . . . . . . . . . . . . . 3 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Canonical Representation . . . . . . . . . . . . . . . . . . 4 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 7 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction BGP [RFC4271] implementations typically support a routing policy language to control the distribution of routing information. Network operators attach BGP communities to routes to associate particular properties with these routes. These properties may include information such as the route origin location, or specification of a routing policy action to be taken, or one that has been taken, and is applied to all routes contained in a BGP Update Message where the Communities Attribute is included. Because BGP communities are optional transitive BGP attributes, BGP communities may be acted upon or otherwise used by routing policies in other Autonomous Systems (ASes) on the Internet. Heitz, et al. Expires July 9, 2017 [Page 2] Internet-Draft BGP Large Communities January 2017 BGP Communities attributes are a variable length attribute consisting of a set of one or more four-octet values, each of which specify a community [RFC1997]. Common use of the individual values of this attribute type split this single 32-bit value into two 16-bit values. The most significant word is interpreted as an Autonomous System Number (ASN) and the least significant word is a locally defined value whose meaning is assigned by the operator of the Autonomous System in the most significant word. Since the adoption of four-octet ASNs [RFC6793], the BGP Communities attribute can no longer accommodate the above encoding, as a two- octet word cannot fit a four-octet ASN. The BGP Extended Communities attribute [RFC4360] is also unsuitable. The six-octet length of the Extended Community value precludes the common operational practise of encoding four-octet ASNs in both the Global Administrator and the Local Administrator sub-fields. To address these shortcomings, this document defines a BGP Large Communities attribute encoded as an unordered set of one or more twelve-octet values, each consisting of a four-octet Global Administrator field and two four-octet operator-defined fields, each of which can be used to denote properties or actions significant to the operator of the Autonomous System assigning the values. 2. BGP Large Communities Attribute This document defines the BGP Large Communities attribute as an optional transitive path attribute of variable length. All routes with the BGP Large Communities attribute belong to the communities specified in the attribute. Each BGP Large Community value is encoded as a 12-octet quantity, as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Data Part 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Data Part 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Global Administrator: A four-octet namespace identifier. Local Data Part 1: A four-octet operator-defined value. Heitz, et al. Expires July 9, 2017 [Page 3] Internet-Draft BGP Large Communities January 2017 Local Data Part 2: A four-octet operator-defined value. The Global Administrator field is intended to allow different Autonomous Systems to define BGP Large Communities without collision. This field SHOULD be an Autonomous System Number (ASN), in which case the Local Data Parts are to be interpreted as defined by the owner of the ASN. The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT RECOMMENDED. There is no significance to the order in which twelve-octet Large Community Attribute values are encoded in a Large Communities attribute, A BGP speaker can transmit them in any order. Duplicate BGP Large Community values MUST NOT be transmitted. A receiving speaker MUST silently remove redundant BGP Large Community values from a BGP Large Community attribute. 3. Aggregation If a range of routes is aggregated, then the resulting aggregate should have a BGP Large Communities attribute which contains all of the BGP Large Communities attributes from all of the aggregated routes. 4. Canonical Representation The canonical representation of BGP Large Communities is three separate unsigned integers in decimal notation in the following order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain leading zeros; a zero value MUST be represented with a single zero. Each number is separated from the next by a single colon. For example: 64496:4294967295:2, 64496:0:0. BGP Large Communities SHOULD be represented in the canonical representation. 5. Error Handling The error handling of BGP Large Communities is as follows: o A BGP Large Communities attribute SHALL be considered malformed if the length of the BGP Large Communities Attribute value, expressed in octets, is not a non-zero multiple of 12. o A BGP Large Communities attribute SHALL NOT be considered malformed due solely to presence of duplicate community values. Heitz, et al. Expires July 9, 2017 [Page 4] Internet-Draft BGP Large Communities January 2017 o A BGP UPDATE message with a malformed BGP Large Communities attribute SHALL be handled using the approach of "treat-as- withdraw" as described in section 2 [RFC7606]. The BGP Large Communities Global Administrator field may contain any value, and a BGP Large Communities attribute MUST NOT be considered malformed if the Global Administrator field contains an unallocated, unassigned or reserved ASN. 6. Security Considerations This document does not change any underlying security issues associated with any other BGP Communities mechanism. Specifically, an AS relying on the BGP Large Communities attribute carried in BGP must have trust in every other AS in the path, as any intermediate Autonomous System in the path may have added, deleted, or altered the BGP Large Communities attribute. Specifying the mechanism to provide such trust is beyond the scope of this document. BGP Large Communities do not protect the integrity of each community value. Operators should be aware that it is possible for a BGP speaker to alter BGP Large Community Attribute values in a BGP Update Message. Protecting the integrity of the transitive handling of BGP Large Community attributes in a manner consistent with the intent of expressed BGP routing policies falls within the broader scope of securing BGP, and is not specifically addressed here. Network administrators should note the recommendations in Section 11 of BGP Operations and Security [RFC7454]. 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC7942. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. As of today these vendors have produced an implementation of BGP Large Communities: Heitz, et al. Expires July 9, 2017 [Page 5] Internet-Draft BGP Large Communities January 2017 o Cisco IOS XR o ExaBGP o GoBGP o BIRD o OpenBGPD o pmacct o Quagga The latest implementation news is tracked at http://largebgpcommunities.net/ [1]. 8. IANA Considerations IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group and is now asked to make that Permanent. 9. Contributors The following people contributed significantly to the content of the document: John Heasley NTT Communications Email: heas@shrubbery.net Adam Simpson Nokia Email: adam.1.simpson@nokia.com 10. Acknowledgments The authors would like to thank Ruediger Volk, Russ White, Acee Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, Heitz, et al. Expires July 9, 2017 [Page 6] Internet-Draft BGP Large Communities January 2017 Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann, Geoff Huston, Mach Chen, and Alvaro Retana for their support, insightful review and comments. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . 11.2. Informative References [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous System (AS) Numbers", BCP 6, RFC 7300, DOI 10.17487/RFC7300, July 2014, . Heitz, et al. Expires July 9, 2017 [Page 7] Internet-Draft BGP Large Communities January 2017 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, . [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, . 11.3. URIs [1] http://largebgpcommunities.net Authors' Addresses Jakob Heitz (editor) Cisco 170 West Tasman Drive San Jose, CA 95054 USA Email: jheitz@cisco.com Job Snijders (editor) NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ The Netherlands Email: job@ntt.net Keyur Patel Arrcus, Inc Email: keyur@arrcus.com Ignas Bagdonas Equinix 80 Cheapside London EC2V 6EE United Kingdom Email: ibagdona.ietf@gmail.com Heitz, et al. Expires July 9, 2017 [Page 8] Internet-Draft BGP Large Communities January 2017 Nick Hilliard INEX 4027 Kingswood Road Dublin 24 IE Email: nick@inex.ie Heitz, et al. Expires July 9, 2017 [Page 9] ./draft-ietf-appsawg-mdn-3798bis-16.txt0000664000764400076440000023420013020045113016673 0ustar iustyiusty Network Working Group T. Hansen, Ed. Internet-Draft AT&T Laboratories Obsoletes: 3798 (if approved) A. Melnikov, Ed. Updates: 2046, 3461 (if approved) Isode Ltd Intended status: Standards Track December 1, 2016 Expires: June 4, 2017 Message Disposition Notification draft-ietf-appsawg-mdn-3798bis-16.txt Abstract This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. This document obsoletes RFC 3798, moving it to Internet Standard. It also updates RFC 2046 (message/partial Media Type handling) and RFC 3461 (Original-Recipient header field generation requirement). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Hansen & Melnikov Expires June 4, 2017 [Page 1] Internet-Draft MDN December 2016 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requesting Message Disposition Notifications . . . . . . . . 5 2.1. The Disposition-Notification-To Header . . . . . . . . . 5 2.2. The Disposition-Notification-Options Header . . . . . . . 7 2.3. The Original-Recipient Header Field . . . . . . . . . . . 8 2.4. Use with the Message/Partial Media Type . . . . . . . . . 9 3. Format of a Message Disposition Notification . . . . . . . . 10 3.1. The message/disposition-notification Media Type . . . . . 11 3.2. Message/disposition-notification Content Fields . . . . . 14 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 21 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 21 5. Conformance and Usage Requirements . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.1. Disclosure of Product Information . . . . . . . . . . 25 6.2.2. MUA Fingerprinting . . . . . . . . . . . . . . . . . 25 6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 25 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 25 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 26 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 28 Hansen & Melnikov Expires June 4, 2017 [Page 2] Internet-Draft MDN December 2016 8.1. Gatewaying from other mail systems to MDNs . . . . . . . 28 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 29 8.3. Gatewaying of MDN-requests to other mail systems . . . . 29 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10.1. Disposition-Notification-Options header field disposition-notification-parameter names . . . . . . . . 32 10.2. Disposition modifier names . . . . . . . . . . . . . . . 33 10.3. MDN extension field names . . . . . . . . . . . . . . . 33 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This memo defines a media type [RFC2046] for message disposition notifications (MDNs). An MDN can be used to notify the sender of a message of any of several conditions that may occur after successful delivery, such as display of the message contents, printing of the message, deletion (without display) of the message, or the recipient's refusal to provide MDNs. The "message/disposition- notification" content-type defined herein is intended for use within the framework of the "multipart/report" content type defined in RFC- REPORT [RFC6522]. This memo defines the format of the notifications and the RFC-MSGFMT [RFC5322] header fields used to request them. This memo is an update to RFC 3798 and is intended to be published at Internet Standard Level. 1.1. Purposes The MDNs defined in this memo are expected to serve several purposes: a. Inform human beings of the disposition of messages after successful delivery, in a manner that is largely independent of human language; b. Allow mail user agents to keep track of the disposition of messages sent, by associating returned MDNs with earlier message transmissions; Hansen & Melnikov Expires June 4, 2017 [Page 3] Internet-Draft MDN December 2016 c. Convey disposition notification requests and disposition notifications between Internet Mail and "foreign" mail systems via a gateway; d. Allow "foreign" notifications to be tunneled through a MIME- capable message system and back into the original messaging system that issued the original notification, or even to a third messaging system; e. Allow language-independent, yet reasonably precise, indications of the disposition of a message to be delivered. 1.2. Requirements These purposes place the following constraints on the notification protocol: a. It must be readable by humans, and must be machine-parsable. b. It must provide enough information to allow message senders (or their user agents) to unambiguously associate an MDN with the message that was sent and the original recipient address for which the MDN was issued (if such information is available), even if the message was forwarded to another recipient address. c. It must also be able to describe the disposition of a message independent of any particular human language or of the terminology of any particular mail system. d. The specification must be extensible in order to accommodate future requirements. 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-KEYWORDS [RFC2119]. All syntax descriptions use the ABNF specified by RFC-MSGFMT [RFC5322], in which the lexical tokens (used below) are defined: "CRLF", "FWS", "CFWS", "field-name", "mailbox-list", "msg-id", and Hansen & Melnikov Expires June 4, 2017 [Page 4] Internet-Draft MDN December 2016 "text". The following lexical tokens are defined in RFC-SMTP [RFC5321]: "atom". 2. Requesting Message Disposition Notifications Message disposition notifications are requested by including a Disposition-Notification-To header field in the message containing one or more addresses specifying where dispositions should be sent. Further information to be used by the recipient's Mail User Agent (MUA) [RFC5598] in generating the MDN may be provided by also including Original-Recipient and/or Disposition-Notification-Options header fields in the message. 2.1. The Disposition-Notification-To Header A request for the receiving user agent to issue message disposition notifications is made by placing a Disposition-Notification-To header field into the message. The syntax of the header field is mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF A Disposition-Notification-To header field can appear at most once in a message. The presence of a Disposition-Notification-To header field in a message is merely a request for an MDN. The recipients' user agents are always free to silently ignore such a request. An MDN MUST NOT itself have a Disposition-Notification-To header field. An MDN MUST NOT be generated in response to an MDN. A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. That is, once an MDN has been issued on behalf of a recipient, no further MDNs may be issued on behalf of that recipient by the same user agent, even if another disposition is performed on the message. However, if a message is forwarded, an MDN may have been issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated. It is also possible that if the same message is being accessed by multiple user agents (for example using POP3), then multiple dispositions might be generated for the same recipient. User agents SHOULD leverage support in the underlying message access protocol to prevent multiple MDNs from being generated. In particular, when the user agent is accessing the message using RFC-IMAP [RFC3501], it SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503]. Hansen & Melnikov Expires June 4, 2017 [Page 5] Internet-Draft MDN December 2016 While Internet standards normally do not specify the behavior of user interfaces, it is strongly recommended that the user agent obtain the user's consent before sending an MDN. This consent could be obtained for each message through some sort of prompt or dialog box, or globally through the user's setting of a preference. The user might also indicate globally that MDNs are to never be sent. The purpose of obtaining user's consent is to protect user's privacy. The default value should be not to send MDNs. MDNs MUST NOT be sent automatically if the address in the Disposition-Notification-To header field differs from the address in the Return-Path header field (see RFC-MSGFMT [RFC5322]). In this case, confirmation from the user MUST be obtained, if possible. If obtaining consent is not possible (e.g., because the user is not online at the time or the client is not an interactive email client), then an MDN MUST NOT be sent. Confirmation from the user MUST be obtained (or no MDN sent) if there is no Return-Path header field in the message, or if there is more than one distinct address in the Disposition-Notification-To header field. The comparison of the addresses is done using only the addr-spec (local-part "@" domain) portion, excluding any angle brackets, phrase and route. As prescribed by RFC 5322, the comparison is case- sensitive for the local-part and case-insensitive for the domain part. The local-part comparison SHOULD be done after performing local-part canonicalization (i.e. after removing the surrounding double-quote characters, if any, as well as any escaping "\" characters. (See RFC-MSGFMT [RFC5322] for more details.) Implementations MAY treat known domain aliases as equivalent for the purpose of comparison. Note that use of subaddressing (see [RFC5233]) can result in a failure to match two local-parts and thus result in possible suppression of the MDN. This document doesn't recommend special handling for this case, as the receiving MUA can't reliably know whether or not the sender is using subaddressing. If the message contains more than one Return-Path header field, the implementation may pick one to use for the comparison, or treat the situation as a failure of the comparison. The reason for not automatically sending an MDN if the comparison fails or more than one address is specified is to reduce the possibility of mail loops and of MDNs being used for mail bombing. Hansen & Melnikov Expires June 4, 2017 [Page 6] Internet-Draft MDN December 2016 It's especially important that a message that contains a Disposition- Notification-To header field also contain a Message-ID header field, to permit user agents to automatically correlate MDNs with their original messages. If the request for message disposition notifications for some recipients and not others is desired, two copies of the message should be sent, one with a Disposition-Notification-To header field and one without. Many of the other header fields of the message (e.g., To, Cc) will be the same in both copies. The recipients in the respective message envelopes determine from whom message disposition notifications are requested and from whom they are not. If desired, the Message-ID header field may be the same in both copies of the message. Note that there are other situations (e.g., Bcc) in which it is necessary to send multiple copies of a message with slightly different header fields. The combination of such situations and the need to request MDNs for a subset of all recipients may result in more than two copies of a message being sent, some with a Disposition-Notification-To header field and some without. If it is possible to determine that a recipient is a newsgroup, do not include a Disposition-Notification-To header field for that recipient. Similarly, if an existing message is resent or gatewayed to a newsgroup, the agent doing resending/gatewaying SHOULD strip the Disposition-Notification-To header field. See Section 5 for more discussion. Clients that see an otherwise valid Disposition- Notification-To header field in a newsgroup message SHOULD NOT generate an MDN. 2.2. The Disposition-Notification-Options Header Extensions to this specification may require that information be supplied to the recipient's MUA for additional control over how and what MDNs are generated. The Disposition-Notification-Options header field provides an extensible mechanism for such information. The syntax of this header field is as follows: Hansen & Melnikov Expires June 4, 2017 [Page 7] Internet-Draft MDN December 2016 Disposition-Notification-Options = "Disposition-Notification-Options" ":" [FWS] disposition-notification-parameter-list CRLF disposition-notification-parameter-list = disposition-notification-parameter *([FWS] ";" [FWS] disposition-notification-parameter) disposition-notification-parameter = attribute [FWS] "=" [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) importance = "required" / "optional" attribute = atom value = word A Disposition-Notification-Options header field can appear at most once in a message. An importance of "required" indicates that interpretation of the disposition-notification-parameter is necessary for proper generation of an MDN in response to this request. An importance of "optional" indicates that an MUA that does not understand the meaning of this disposition-notification-parameter MAY generate an MDN in response anyway, ignoring the value of the disposition-notification-parameter. No disposition-notification-parameter attribute names are defined in this specification. Attribute names may be defined in the future by later revisions or extensions to this specification. disposition- notification-parameter attribute names MUST be registered with the Internet Assigned Numbers Authority (IANA) using "Specification required" registration policy. The "X-" prefix has historically been used to denote unregistered "experimental" protocol elements, that are assumed not to become common use. Deployment experience of this and other protocols have shown that this assumption is often false. This document allows the use of the "X-" prefix primarily to allow the registration of attributes that are already in common use. The prefix has no meaning for new attributes. Its use in substantially new attributes may cause confusion and is therefore discouraged. (See Section 10 for a registration form.) 2.3. The Original-Recipient Header Field Since electronic mail addresses may be rewritten while the message is in transit, it is useful for the original recipient address to be made available by the delivering Message Transfer Agent (MTA) [RFC5598]. The delivering MTA may be able to obtain this information Hansen & Melnikov Expires June 4, 2017 [Page 8] Internet-Draft MDN December 2016 from the ORCPT parameter of the SMTP RCPT TO command, as defined in RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461]. RFC-DSN-SMTP [RFC3461] is amended as follows: If the ORCPT information is available, the delivering MTA SHOULD insert an Original-Recipient header field at the beginning of the message (along with the Return-Path header field). The delivering MTA MAY delete any other Original-Recipient header fields that occur in the message. The syntax of this header field is as follows: original-recipient-header = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS OWS = [CFWS] ; Optional whitespace. ; MDN generators SHOULD use "*WSP" ; (typically a single space or nothing. ; It SHOULD be nothing at the end of a field), ; unless an RFC 5322 "comment" is required. ; ; MDN parsers MUST parse it as "[CFWS]". The address-type and generic-address token are as specified in the description of the Original-Recipient field in Section 3.2.3. The purpose of carrying the original recipient information and returning it in the MDN is to permit automatic correlation of MDNs with the original message on a per-recipient basis. 2.4. Use with the Message/Partial Media Type The use of the header fields Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient with the MIME message/partial content type (RFC-MIME-MEDIA [RFC2046]]) requires further definition. When a message is segmented into two or more message/partial fragments, the three header fields mentioned in the above paragraph SHOULD be placed in the "inner" or "enclosed" message (using the terms of RFC-MIME-MEDIA [RFC2046]). If these header fields are found in the header fields of any of the fragments, they are ignored. When the multiple message/partial fragments are reassembled, the following applies. If these header fields occur along with the other header fields of a message/partial fragment message, they pertain to an MDN that will be generated for the fragment. If these header fields occur in the header fields of the "inner" or "enclosed" message (using the terms of RFC-MIME-MEDIA [RFC2046]), they pertain Hansen & Melnikov Expires June 4, 2017 [Page 9] Internet-Draft MDN December 2016 to an MDN that will be generated for the reassembled message. Section 5.2.2.1 of RFC-MIME-MEDIA [RFC2046]) is amended to specify that, in addition to the header fields specified there, the three header fields described in this specification are to be appended, in order, to the header fields of the reassembled message. Any occurrences of the three header fields defined here in the header fields of the initial enclosing message MUST NOT be copied to the reassembled message. 3. Format of a Message Disposition Notification A message disposition notification is a MIME message with a top-level content-type of multipart/report (defined in RFC-REPORT [RFC6522]). When multipart/report content is used to transmit an MDN: a. The report-type parameter of the multipart/report content is "disposition-notification". b. The first component of the multipart/report contains a human- readable explanation of the MDN, as described in RFC-REPORT [RFC6522]. c. The second component of the multipart/report is of content-type message/disposition-notification, described in Section 3.1 of this document. d. If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report. The decision of whether or not to return the message or part of the message is up to the MUA generating the MDN. However, in the case of encrypted messages requesting MDNs, if the original message or a portion thereof is returned, it MUST be in its original encrypted form. NOTE: For message disposition notifications gatewayed from foreign systems, the header fields of the original message may not be available. In this case, the third component of the MDN may be omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header fields that contain equivalent information. In particular, it is very desirable to preserve the subject and date fields from the original message. The MDN MUST be addressed (in both the message header field and the transport envelope) to the address(es) from the Disposition- Hansen & Melnikov Expires June 4, 2017 [Page 10] Internet-Draft MDN December 2016 Notification-To header field from the original message for which the MDN is being generated. The From header field of the MDN MUST contain the address of the person for whom the message disposition notification is being issued. The envelope sender address (i.e., SMTP "MAIL FROM") of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages nor other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN. A message disposition notification MUST NOT itself request an MDN. That is, it MUST NOT contain a Disposition-Notification-To header field. The Message-ID header field (if present) for an MDN MUST be different from the Message-ID of the message for which the MDN is being issued. A particular MDN describes the disposition of exactly one message for exactly one recipient. Multiple MDNs may be generated as a result of one message submission, one per recipient. However, due to the circumstances described in Section 2.1, it's possible that some of the recipients for whom MDNs were requested will not generate MDNs. 3.1. The message/disposition-notification Media Type The message/disposition-notification Media Type is defined as follows: Type name: message Subtype name: disposition-notification Required parameters: none Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non- MIME mail readers. Security considerations: discussed in Section 6 of [RFCXXXX]. Hansen & Melnikov Expires June 4, 2017 [Page 11] Internet-Draft MDN December 2016 Interoperability considerations: none Published specification: [RFCXXXX] Applications that use this media type: Mail Transfer Agents and email clients that support multipart/report generation and/or parsing. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): none File extension(s): .disposition-notification Macintosh file type code(s): The 'TEXT' type code is suggested as files of this type are typically used for diagnostic purposes and suitable for analysis in a text editor. A uniform type identifier (UTI) of "public.utf8- email-message-header" is suggested. This type conforms to "public.plain-text". Person & email address to contact for further information: ART Area Mailing List Intended usage: COMMON Restrictions on usage: This media type contains textual data in the US-ASCII charset, which is always 7-bit. Author: See the Authors' Addresses section of [RFCXXXX] Change controller: IETF Provisional registration? no Hansen & Melnikov Expires June 4, 2017 [Page 12] Internet-Draft MDN December 2016 (While the 7bit restriction applies to the message/disposition- notification portion of the multipart/report content, it does not apply to the optional third portion of the multipart/report content.) The message/disposition-notification report type for use in the multipart/report is "disposition-notification". The body of a message/disposition-notification consists of one or more "fields" formatted according to the ABNF of RFC-MSGFMT [RFC5322] header "fields". The syntax of the message/disposition-notification content is as follows: disposition-notification-content = [ reporting-ua-field CRLF ] [ mdn-gateway-field CRLF ] [ original-recipient-field CRLF ] final-recipient-field CRLF [ original-message-id-field CRLF ] disposition-field CRLF *( error-field CRLF ) *( extension-field CRLF ) extension-field = extension-field-name ":" *([FWS] text) extension-field-name = field-name Note that the order of the above fields is recommended, but not fixed. Extension fields can appear anywhere. 3.1.1. General conventions for fields Since these fields are defined according to the rules of RFC-MSGFMT [RFC5322], the same conventions for continuation lines and comments apply. Notification fields may be continued onto multiple lines by beginning each additional line with a SPACE or HTAB. Text that appears in parentheses is considered a comment and not part of the contents of that notification field. Field names are case- insensitive, so the names of notification fields may be spelled in any combination of upper and lower case letters. [RFC5322] comments in notification fields may use the "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047]. 3.1.2. "*-type" subfields Several fields consist of a "-type" subfield, followed by a semi- colon, followed by "*text". For these fields, the keyword used in the address-type or MTA-type subfield indicates the expected format of the address or MTA-name that follows. Hansen & Melnikov Expires June 4, 2017 [Page 13] Internet-Draft MDN December 2016 The "-type" subfields are defined as follows: a. An "address-type" specifies the format of a mailbox address. For example, Internet Mail addresses use the "rfc822" address-type. Other values can appear in this field as specified in the "Address Types" IANA subregistry established by RFC-DSN-FORMAT [RFC3464]. address-type = atom atom = b. An "MTA-name-type" specifies the format of a mail transfer agent name. For example, for an SMTP server on an Internet host, the MTA name is the domain name of that host, and the "dns" MTA-name- type is used. Other values can appear in this field as specified in the "MTA Name Types" IANA subregistry established by RFC-DSN- FORMAT [RFC3464]. mta-name-type = atom Values for address-type and mta-name-type are case-insensitive. Thus, address-type values of "RFC822" and "rfc822" are equivalent. The Internet Assigned Numbers Authority (IANA) maintains a registry of address-type and mta-name-type values, along with descriptions of the meanings of each, or a reference to one or more specifications that provide such descriptions. (The "rfc822" address-type is defined in RFC-DSN-SMTP [RFC3461].) Registration forms for address- type and mta-name-type appear in RFC-DSN-FORMAT [RFC3464]. 3.2. Message/disposition-notification Content Fields 3.2.1. The Reporting-UA field reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] ua-name = *text-no-semi ua-product = *([FWS] text) text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon The Reporting-UA field is defined as follows: Hansen & Melnikov Expires June 4, 2017 [Page 14] Internet-Draft MDN December 2016 An MDN describes the disposition of a message after it has been delivered to a recipient. In all cases, the Reporting-UA is the MUA that performed the disposition described in the MDN. The "Reporting-UA" field contains information about the MUA that generated the MDN, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular MUA limitations, and for analytics regarding MUA or operating system use. A MUA SHOULD send a "Reporting-UA" field unless specifically configured not to do so. If the reporting MUA consists of more than one component (e.g., a base program and plug-ins), this may be indicated by including a list of product names. A reporting MUA SHOULD limit generated product identifiers to what is necessary to identify the product; a sender MUST NOT generate advertising or other nonessential information within the product identifier. A reporting MUA SHOULD NOT generate a "Reporting-UA" field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed "Reporting- UA" field values increase the risk of a user being identified against their wishes ("fingerprinting"). Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a MUA masquerades as a different MUA, recipients can assume that the user intentionally desires to see responses tailored for that identified MUA, even if they might not work as well for the actual MUA being used. Example: Reporting-UA: Foomail 97.1 3.2.2. The MDN-Gateway field The MDN-Gateway field indicates the name of the gateway or MTA that translated a foreign (non-Internet) message disposition notification into this MDN. This field MUST appear in any MDN that was translated by a gateway from a foreign system into MDN format, and MUST NOT appear otherwise. Hansen & Melnikov Expires June 4, 2017 [Page 15] Internet-Draft MDN December 2016 mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name OWS mta-name = *text For gateways into Internet Mail, the MTA-name-type will normally be "dns", and the mta-name will be the Internet domain name of the gateway. 3.2.3. Original-Recipient field The Original-Recipient field indicates the original recipient address as specified by the sender of the message for which the MDN is being issued. For Internet Mail messages, the value of the Original- Recipient field is obtained from the Original-Recipient header field from the message for which the MDN is being generated. If there is an Original-Recipient header field in the message, or if information about the original recipient is reliably available some other way, then the Original-Recipient field MUST be included. Otherwise, the Original-Recipient field MUST NOT be included. If there is more than one Original-Recipient header field in the message, the MUA may choose the one to use, or act as if no Original-Recipient header field is present. original-recipient-field = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS generic-address = *text The address-type field indicates the type of the original recipient address. If the message originated within the Internet, the address- type field will normally be "rfc822", and the address will be according to the syntax specified in RFC-MSGFMT [RFC5322]. The value "unknown" should be used if the Reporting MUA cannot determine the type of the original recipient address from the message envelope. This address is the same as that provided by the sender and can be used to automatically correlate MDN reports with original messages on a per recipient basis. 3.2.4. Final-Recipient field The Final-Recipient field indicates the recipient for which the MDN is being issued. This field MUST be present. The syntax of the field is as follows: final-recipient-field = "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS Hansen & Melnikov Expires June 4, 2017 [Page 16] Internet-Draft MDN December 2016 The generic-address subfield of the Final-Recipient field SHOULD contain the mailbox address of the recipient (which will be the same as the From header field of the MDN) as it was when the MDN was generated by the MUA. One example of when this field might not contain the final recipient address of the message is when an alias (e.g. "customer- support@example.com") forwards mail to a specific personal address (e.g. "bob@example.com"). Bob might want to be able to send MDNs, but not give away his personal email address. In this case the Final-Recipient field can be "customer-support@example.com" instead of "bob@example.com". The Final-Recipient address may differ from the address originally provided by the sender, because it may have been transformed during forwarding and gatewaying into a totally unrecognizable mess. However, in the absence of the optional Original-Recipient field, the Final-Recipient field and any returned content may be the only information available with which to correlate the MDN with a particular message recipient. The address-type subfield indicates the type of address expected by the reporting MTA in that context. Recipient addresses obtained via SMTP will normally be of address-type "rfc822", but can be other values from the "Address Types" subregistry of the "Delivery Status Notification (DSN) Types" IANA registry. Since mailbox addresses (including those used in the Internet) may be case sensitive, the case of alphabetic characters in the address MUST be preserved. 3.2.5. Original-Message-ID field The Original-Message-ID field indicates the message-ID of the message for which the MDN is being issued. It is obtained from the Message- ID header field of the message for which the MDN is issued. This field MUST be present if and only if the original message contained a Message-ID header field. The syntax of the field is as follows: original-message-id-field = "Original-Message-ID" ":" msg-id The msg-id token is as specified in RFC-MSGFMT [RFC5322]. Hansen & Melnikov Expires June 4, 2017 [Page 17] Internet-Draft MDN December 2016 3.2.6. Disposition field The Disposition field indicates the action performed by the Reporting-MUA on behalf of the user. This field MUST be present. The syntax for the Disposition field is: disposition-field = "Disposition" ":" OWS disposition-mode OWS ";" OWS disposition-type [ OWS "/" OWS disposition-modifier *( OWS "," OWS disposition-modifier ) ] OWS disposition-mode = action-mode OWS "/" OWS sending-mode action-mode = "manual-action" / "automatic-action" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" disposition-type = "displayed" / "deleted" / "dispatched" / "processed" disposition-modifier = "error" / disposition-modifier-extension disposition-modifier-extension = atom The disposition-mode, disposition-type, and disposition-modifier values may be spelled in any combination of upper and lower case US- ASCII characters. 3.2.6.1. Disposition modes Disposition mode consists of 2 parts: action mode and sending mode. The following action modes are defined: "manual-action" The disposition described by the disposition type was a result of an explicit instruction by the user rather than some sort of automatically performed action. (This might include the case when the user has manually configured her MUA to automatically respond to valid MDN requests.) Unless prescribed otherwise in a particular mail environment, in order to preserve user's privacy, this MUST be the default for MUAs. Hansen & Melnikov Expires June 4, 2017 [Page 18] Internet-Draft MDN December 2016 "automatic-action" The disposition described by the disposition type was a result of an automatic action, rather than an explicit instruction by the user for this message. This is typically generated by a Mail Delivery Agent (e.g. MDN generations by Sieve reject action [RFC5429], Fax-over-Email [RFC3249], Voice Messaging System (VPIM) [RFC3801] or upon delivery to a mailing list). "Manual-action" and "automatic-action" are mutually exclusive. One or the other MUST be specified. The following sending modes are defined: "MDN-sent-manually" The user explicitly gave permission for this particular MDN to be sent. Unless prescribed otherwise in a particular mail environment, in order to preserve user's privacy, this MUST be the default for MUAs. "MDN-sent-automatically" The MDN was sent because the MUA had previously been configured to do so automatically. "MDN-sent-manually" and "MDN-sent-automatically" are mutually exclusive. One or the other MUST be specified. 3.2.6.2. Disposition types The following disposition-types are defined: "displayed" The message has been displayed by the MUA to someone reading the recipient's mailbox. There is no guarantee that the content has been read or understood. "dispatched" The message has been sent somewhere in some manner (e.g., printed, faxed, forwarded) without necessarily having been previously displayed to the user. The user may or may not see the message later. Hansen & Melnikov Expires June 4, 2017 [Page 19] Internet-Draft MDN December 2016 "processed" The message has been processed in some manner (i.e., by some sort of rules or server) without being displayed to the user. The user may or may not see the message later, or there may not even be a human user associated with the mailbox. "deleted" The message has been deleted. The recipient may or may not have seen the message. The recipient might "undelete" the message at a later time and read the message. 3.2.6.3. Disposition modifiers Only the extension disposition modifiers is defined: disposition-modifier-extension Disposition modifiers may be defined in the future by later revisions or extensions to this specification. MDN disposition value names MUST be registered with the Internet Assigned Numbers Authority (IANA) using "Specification required" registration policy. (See Section 10 for a registration form.) MDNs with disposition modifier names not understood by the receiving MUA MAY be silently ignored or placed in the user's mailbox without special interpretation. They MUST NOT cause any error message to be sent to the sender of the MDN. It is not required that an MUA be able to generate all of the possible values of the Disposition field. A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. That is, once an MDN has been issued on behalf of a recipient, no further MDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. However, if a message is forwarded, a "dispatched" MDN MAY be issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated. 3.2.7. Error Field The Error field is used to supply additional information in the form of text messages when the "error" disposition modifier appear. The syntax is as follows: Hansen & Melnikov Expires June 4, 2017 [Page 20] Internet-Draft MDN December 2016 error-field = "Error" ":" *([FWS] text) Note that syntax of these header fields doesn't include comments, so "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't be used to convey non ASCII text. Application that need to convey non ASCII text in these fields should consider implementing message/ global-disposition-notification media type specified in [RFC6533] instead of this specification. 3.3. Extension-fields Additional MDN fields may be defined in the future by later revisions or extensions to this specification. MDN field names MUST be registered with the Internet Assigned Numbers Authority (IANA) using "Specification required" registration policy. (See Section 10 for a registration form.) MDN Extension-fields may be defined for the following reasons: a. To allow additional information from foreign disposition reports to be tunneled through Internet MDNs. The names of such MDN fields should begin with an indication of the foreign environment name (e.g., X400-Physical-Forwarding-Address). b. To allow transmission of diagnostic information that is specific to a particular mail user agent (MUA). The names of such MDN fields should begin with an indication of the MUA implementation that produced the MDN (e.g., Foomail-information). 4. Timeline of events The following timeline shows when various events in the processing of a message and generation of MDNs take place: -- User composes message -- User tells MUA to send message. -- MUA passes message to Mail Submission Agent (MSA), original recipient information passed along. -- MSA sends message to next MTA. Hansen & Melnikov Expires June 4, 2017 [Page 21] Internet-Draft MDN December 2016 -- Final MTA receives message. -- Final MTA delivers message to recipient's mailbox (possibly generating a Delivery Status Notification (DSN)). -- (Recipient's) MUA discovers a new message in recipient's mailbox and decides whether an MDN should be generated. If the MUA has information that an MDN has already been generated for this message, no further MDN processing described below is performed. If MUA decides that no MDN can be generated, no further MDN processing described below is performed. -- MUA performs automatic processing and might generate corresponding MDNs ("dispatched", "processed" or "deleted" disposition type with "automatic-action" and "MDN-sent-automatically" disposition modes). The MUA remembers that an MDN was generated. -- MUA displays list of messages to user. -- User selects a message and requests that some action be performed on it. -- MUA performs requested action; if an automatic MDN has not already been generated, with user's permission, sends an appropriate MDN ("displayed", "dispatched", "processed", or "deleted" disposition type, with "manual-action" and "MDN-sent-manually" or "MDN-sent- automatically" disposition mode). The MUA remembers that an MDN was generated. -- User possibly performs other actions on message, but no further MDNs are generated. 5. Conformance and Usage Requirements An MUA or gateway conforms to this specification if it generates MDNs according to the protocol defined in this memo. It is not necessary to be able to generate all of the possible values of the Disposition field. MUAs and gateways MUST NOT generate the Original-Recipient field of an MDN unless the mail protocols provide the address originally Hansen & Melnikov Expires June 4, 2017 [Page 22] Internet-Draft MDN December 2016 specified by the sender at the time of submission. Ordinary SMTP does not make that guarantee, but the SMTP extension defined in RFC- DSN-SMTP [RFC3461] permits such information to be carried in the envelope if it is available. The Original-Recipient header field defined in this document provides a way for the MTA to pass the original recipient address to the MUA. Each sender-specified recipient address may result in more than one MDN. If an MDN is requested for a recipient that is forwarded to multiple recipients of an "alias" (as defined in RFC-DSN-SMTP [RFC3461], section 6.2.7.3), each of the recipients may issue an MDN. Successful distribution of a message to a mailing list exploder or gateway to Usenet newsgroup SHOULD be considered the final disposition of the message. A mailing list exploder MAY issue an MDN with a disposition type of "processed" and disposition modes of "automatic-action" and "MDN-sent-automatically" indicating that the message has been forwarded to the list. In this case, the request for MDNs is not propagated to the members of the list. Alternatively (if successful distribution of a message to a mailing list exploder/Usenet newsgroup is not considered the final disposition of the message), the mailing list exploder can issue no MDN and propagate the request for MDNs to all members of the list. The latter behavior is not recommended for any but small, closely knit lists, as it might cause large numbers of MDNs to be generated and may cause confidential subscribers to the list to be revealed. The mailing list exploder can also direct MDNs to itself, correlate them, and produce a report to the original sender of the message. This specification places no restrictions on the processing of MDNs received by user agents or mailing lists. 6. Security Considerations The following security considerations apply when using MDNs: 6.1. Forgery MDNs can be (and are, in practice) forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list exploders) that wish to make automatic use of MDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks. Security threats related to forged MDNs include the sending of: Hansen & Melnikov Expires June 4, 2017 [Page 23] Internet-Draft MDN December 2016 a. A falsified disposition notification when the indicated disposition of the message has not actually occurred, b. Unsolicited MDNs Similarly, a forged spam or phishing email message can contain Disposition-Notification-To header field that can trick the recipient to send an MDN. MDN processing should only be invoked once authenticity of email message is verified. 6.2. Privacy Another dimension of security is privacy. There may be cases in which a message recipient does not wish the disposition of messages addressed to him to be known, or is concerned that the sending of MDNs may reveal other sensitive information (e.g., when the message was read, using which email client, which OS was used). In this situation, it is acceptable for the MUA to silently ignore requests for MDNs. If the Disposition-Notification-To header field is passed on unmodified when a message is distributed to the subscribers of a mailing list, the subscribers to the list may be revealed to the sender of the original message by the generation of MDNs. Headers of the original message returned in part 3 of the multipart/ report, as well as content of the message/disposition-notification part could reveal confidential information about host names and/or network topology inside a firewall. Disposition mode (Section 3.2.6.1) can leak information about recipient's MUA configuration, in particular whether MDNs are acknowledged manually or automatically. If this is a concern, MUAs can return "manual-action/MDN-sent-manually" disposition mode in generated MDNs. In general, any optional MDN field may be omitted if the Reporting MUA site or user determines that inclusion of the field would impose too great a compromise of site confidentiality. The need for such confidentiality must be balanced against the utility of the omitted information in MDNs. In some cases, someone with access to the message stream may use the MDN request mechanism to monitor the mail reading habits of a target. If the target is known to generate MDN reports, they could add a disposition-notification-to field containing the envelope from Hansen & Melnikov Expires June 4, 2017 [Page 24] Internet-Draft MDN December 2016 address. This risk can be minimized by not sending MDN's automatically. 6.2.1. Disclosure of Product Information The "Reporting-UA" field (Section 3.2.1) User-Agent (Section 5.5.3) and header fields often reveal information about the respective sender's software systems. In theory, this can make it easier for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the apparent software versions being used. Also note that the "Reporting-UA" field doesn't provide any new information in comparison to the "User-Agent" and/or (undocumented) "X-Mailer" header fields used by many MUAs. 6.2.2. MUA Fingerprinting The "Reporting-UA" field (Section 3.2.1) might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. Even when the guidance in Section 3.2.1 is followed to avoid fingerprinting, other sources of unique information may still be present, such as the Accept-Language header fields. 6.3. Non-Repudiation MDNs do not provide non-repudiation with proof of delivery. Within the framework of today's Internet Mail, the MDNs defined in this document provide valuable information to the mail user; however, MDNs cannot be relied upon as a guarantee that a message was or was not seen by the recipient. Even if MDNs are not actively forged, they may be lost in transit. The recipient may bypass the MDN issuing mechanism in some manner. One possible solution for this purpose can be found in RFC-SEC- SERVICES [RFC2634]. 6.4. Mail Bombing The MDN request mechanism introduces an additional way of mailbombing a mailbox. The MDN request notification provides an address to which MDN's should be sent. It is possible for an attacking agent to send a potentially large set of messages to otherwise unsuspecting third party recipients with a false "disposition-notification-to:" address. Automatic, or simplistic processing of such requests would result in a flood of MDN notifications to the target of the attack. Additionally, as generated MDN notifications can include full content of messages that caused them and thus they can be bigger than such Hansen & Melnikov Expires June 4, 2017 [Page 25] Internet-Draft MDN December 2016 messages, they can be used for bandwidth amplification attacks. Such an attack could overrun the storage capacity of the targeted mailbox and/or of the mail transport system, and deny service. For that reason, MDN's SHOULD NOT be sent automatically where the "disposition-notification-to:" address is different from the SMTP "MAIL FROM" address (which is carried in the Return-Path header field). See Section 2.1 for further discussion. 7. Collected ABNF Grammar NOTE: The following lexical tokens are defined in RFC-MSGFMT [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, comment, word. The following lexical tokens are defined in RFC-SMTP [RFC5321]: atom. (Note that RFC-MSGFMT [RFC5322] also defines "atom", but the version from RFC-SMTP [RFC5321] is more restrictive and this more restrictive version is used in this document.) "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] is allowed everywhere where RFC-MSGFMT [RFC5322] "comment" is used, for example in CFWS. OWS = [CFWS] ; Optional whitespace. ; MDN generators SHOULD use "*WSP" ; (typically a single space or nothing. ; It SHOULD be nothing at the end of a field), ; unless an RFC 5322 "comment" is required. ; ; MDN parsers MUST parse it as "[CFWS]". Message header fields: mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF Disposition-Notification-Options = "Disposition-Notification-Options" ":" [FWS] disposition-notification-parameter-list CRLF disposition-notification-parameter-list = disposition-notification-parameter *([FWS] ";" [FWS] disposition-notification-parameter) disposition-notification-parameter = attribute [FWS] "=" [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) importance = "required" / "optional" attribute = atom Hansen & Melnikov Expires June 4, 2017 [Page 26] Internet-Draft MDN December 2016 value = word original-recipient-header = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS CRLF Report content: disposition-notification-content = [ reporting-ua-field CRLF ] [ mdn-gateway-field CRLF ] [ original-recipient-field CRLF ] final-recipient-field CRLF [ original-message-id-field CRLF ] disposition-field CRLF *( error-field CRLF ) *( extension-field CRLF ) address-type = atom mta-name-type = atom reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] ua-name = *text-no-semi ua-product = *([FWS] text) text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name mta-name = *text original-recipient-field = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS generic-address = *text final-recipient-field = "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS original-message-id-field = "Original-Message-ID" ":" msg-id disposition-field = "Disposition" ":" OWS disposition-mode OWS ";" OWS disposition-type [ OWS "/" OWS disposition-modifier *( OWS "," OWS disposition-modifier ) ] OWS Hansen & Melnikov Expires June 4, 2017 [Page 27] Internet-Draft MDN December 2016 disposition-mode = action-mode OWS "/" OWS sending-mode action-mode = "manual-action" / "automatic-action" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" disposition-type = "displayed" / "deleted" / "dispatched" / "processed" disposition-modifier = "error" / disposition-modifier-extension disposition-modifier-extension = atom error-field = "Error" ":" *([FWS] text) extension-field = extension-field-name ":" *([FWS] text) extension-field-name = field-name 8. Guidelines for Gatewaying MDNs NOTE: This section provides non-binding recommendations for the construction of mail gateways that wish to provide semi-transparent disposition notifications between the Internet and another electronic mail system. Specific MDN gateway requirements for a particular pair of mail systems may be defined by other documents. 8.1. Gatewaying from other mail systems to MDNs A mail gateway may issue an MDN to convey the contents of a "foreign" disposition notification over Internet Mail. When there are appropriate mappings from the foreign notification elements to MDN fields, the information may be transmitted in those MDN fields. Additional information (such as might be needed to tunnel the foreign notification through the Internet) may be defined in extension MDN fields. (Such fields should be given names that identify the foreign mail protocol, e.g., X400-* for X.400 protocol elements). The gateway must attempt to supply reasonable values for the Reporting-UA, Final-Recipient, and Disposition fields. These will normally be obtained by translating the values from the foreign notification into their Internet-style equivalents. However, some loss of information is to be expected. The sender-specified recipient address and the original message-id, if present in the foreign notification, should be preserved in the Original-Recipient and Original-Message-ID fields. Hansen & Melnikov Expires June 4, 2017 [Page 28] Internet-Draft MDN December 2016 The gateway should also attempt to preserve the "final" recipient address from the foreign system. Whenever possible, foreign protocol elements should be encoded as meaningful printable ASCII strings. For MDNs produced from foreign disposition notifications, the name of the gateway MUST appear in the MDN-Gateway field of the MDN. 8.2. Gatewaying from MDNs to other mail systems It may be possible to gateway MDNs from the Internet into a foreign mail system. The primary purpose of such gatewaying is to convey disposition information in a form that is usable by the destination system. A secondary purpose is to allow "tunneling" of MDNs through foreign mail systems in case the MDN may be gatewayed back into the Internet. In general, the recipient of the MDN (i.e., the sender of the original message) will want to know, for each recipient: the closest available approximation to the original recipient address, and the disposition (displayed, printed, etc.). If possible, the gateway should attempt to preserve the Original- Recipient address and Original-Message-ID (if present) in the resulting foreign disposition report. If it is possible to tunnel an MDN through the destination environment, the gateway specification may define a means of preserving the MDN information in the disposition reports used by that environment. 8.3. Gatewaying of MDN-requests to other mail systems By use of the separate disposition-notification-to request header field, this specification offers a richer functionality than most, if not all, other email systems. In most other email systems, the notification recipient is identical to the message sender as indicated in the "from" address. There are two interesting cases when gatewaying into such systems: 1. If the address in the disposition-notification-to header field is identical to the address in the SMTP "MAIL FROM", the expected behavior will result, even if the disposition-notification-to information is lost. Systems should propagate the MDN request. 2. If the address in the disposition-notification-to header field is different from the address in the SMTP "MAIL FROM", gatewaying Hansen & Melnikov Expires June 4, 2017 [Page 29] Internet-Draft MDN December 2016 into a foreign system without a separate notification address will result in unintended behavior. This is especially important when the message arrives via a mailing list expansion software that may specifically replace the SMTP "MAIL FROM" address with an alternate address. In such cases, the MDN request should not be gatewayed and should be silently dropped. This is consistent with other forms of non-support for MDN. 9. Example NOTE: This example is provided as illustration only, and is not considered part of the MDN protocol specification. If the example conflicts with the protocol definition above, the example is wrong. Likewise, the use of *-type subfield names or extension fields in this example is not to be construed as a definition for those type names or extension fields. This is an MDN issued after a message has been displayed to the user of an Internet Mail user agent. Hansen & Melnikov Expires June 4, 2017 [Page 30] Internet-Draft MDN December 2016 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 From: Joe Recipient Message-Id: <199509200019.12345@example.com> Subject: Disposition notification To: Jane Sender MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615765/example.com" --RAA14128.773615765/example.com The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe Recipient with subject "First draft of report" has been displayed. This is no guarantee that the message has been read or understood. --RAA14128.773615765/example.com content-type: message/disposition-notification Reporting-UA: joes-pc.cs.example.com; Foomail 97.1 Original-Recipient: rfc822;Joe_Recipient@example.com Final-Recipient: rfc822;Joe_Recipient@example.com Original-Message-ID: <199509192301.23456@example.org> Disposition: manual-action/MDN-sent-manually; displayed --RAA14128.773615765/example.com content-type: message/rfc822 [original message optionally goes here] --RAA14128.773615765/example.com-- 10. IANA Considerations There are two actions for IANA: 1. IANA is asked to update the registration template for the message/disposition-notification media type to the one in Section 3.1 of this document, and to update the reference for that media type to point to this document instead of to RFC 3798. 2. The registries specified here already exist, and this section is updating their documentation. IANA is asked to change the reference document for the three Message Disposition Notification Parameters registries to point to this document instead of to RFC 3798. Hansen & Melnikov Expires June 4, 2017 [Page 31] Internet-Draft MDN December 2016 This document specifies three types of parameters that must be registered with the Internet Assigned Numbers Authority (IANA). All of them use [RFC5226] "Specification required" IANA registration policy. The forms below are for use when registering a new disposition- notification-parameter name for the Disposition-Notification-Options header field, a new disposition modifier name, or a new MDN extension field. Each piece of information required by a registration form may be satisfied either by providing the information on the form itself, or by including a reference to a published, publicly available specification that includes the necessary information. IANA MAY reject registrations because of incomplete registration forms or incomplete specifications. To register, complete the following applicable form and send it via electronic mail to . 10.1. Disposition-Notification-Options header field disposition- notification-parameter names A registration for a Disposition-Notification-Options header field disposition-notification-parameter name MUST include the following information: a. The proposed disposition-notification-parameter name. b. The syntax for disposition-notification-parameter values, specified using BNF, ABNF, regular expressions, or other non- ambiguous language. c. If disposition-notification-parameter values are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a Disposition-Notification-Options header field. d. A reference to a permanent and readily available public specification that describes the semantics of the disposition- notification-parameter values. Hansen & Melnikov Expires June 4, 2017 [Page 32] Internet-Draft MDN December 2016 10.2. Disposition modifier names A registration for a disposition-modifier name (used in the Disposition field of a message/disposition-notification) MUST include the following information: a. The proposed disposition-modifier name. b. A reference to a permanent and readily available public specification that describes the semantics of the disposition modifier. 10.3. MDN extension field names A registration for an MDN extension-field name MUST include the following information: a. The proposed extension field name. b. The syntax for extension values, specified using BNF, ABNF, regular expressions, or other non-ambiguous language. c. If extension-field values are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a Disposition-Notification-Options header field. d. A reference to a permanent and readily available public specification that describes the semantics of the extension field. 11. Acknowledgements The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben Campbell, Pete Resnick, Donald Eastlake and Alissa Cooper are gratefully acknowledged for this revision. The contributions of Roger Fajman and Greg Vaudreuil to earlier versions of this document are also gratefully acknowledged. Hansen & Melnikov Expires June 4, 2017 [Page 33] Internet-Draft MDN December 2016 12. References 12.1. Normative References [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, . [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, . [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Hansen & Melnikov Expires June 4, 2017 [Page 34] Internet-Draft MDN December 2016 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)", RFC 3503, DOI 10.17487/RFC3503, March 2003, . 12.2. Informative References [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, . [RFC3249] Cancio, V., Moldovan, M., Tamura, H., and D. Wing, "Implementers Guide for Facsimile Using Internet Mail", RFC 3249, DOI 10.17487/RFC3249, September 2002, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, DOI 10.17487/RFC3801, June 2004, . [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5429] Stone, A., Ed., "Sieve Email Filtering: Reject and Extended Reject Extensions", RFC 5429, DOI 10.17487/RFC5429, March 2009, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, . Hansen & Melnikov Expires June 4, 2017 [Page 35] Internet-Draft MDN December 2016 Appendix A. Changes from RFC 3798 Changed IANA registration for different subregistries to "Specification Required" to match what is already used by IANA. Updated IANA registration template for message/disposition- notification. "X-" fields no longer reserved for experimental use and can now be registered in compliance with RFC 6648. Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns". Strengthen requirements on obtaining user consent in order to protect user privacy. Removed discussion of using source routes with MDNs, as source route is a deprecated Email feature. The values of "dispatched" and "processed" were lost from the ABNF for "disposition-type". (Erratum #691) Because the warning disposition modifier was previously removed, warning-field has also been removed. (Erratum #692) Because the failed disposition type was previously removed, failure- field has also been removed. The ABNF for ua-name and ua-product included semi-colon, which could not be distinguished from *text in the production. The ua-name was restricted to not include semi-colon. Semi-colon can still appear in the ua-product. Removed recommendation to include the MUA DNS host name in the "Reporting-UA" MDN field. The ABNF did not indicate all places that whitespace was allowable, in particular folding whitespace, although all implementations allow whitespace and folding in the header fields just like any other RFC5322 [RFC5322]-formatted header field. There were also a number of places in the ABNF that inconsistently permitted comments and whitespace in one leg of the production and not another. The ABNF now specifies FWS and CFWS in several places that should have already been specified by the grammar. Extension-field was defined in the collected grammar but not in the main text. Hansen & Melnikov Expires June 4, 2017 [Page 36] Internet-Draft MDN December 2016 The comparison of mailboxes in Disposition-Notification-To to the Return-Path addr-spec was clarified. The use of the grammar production "parameter" was confusing with the RFC2045 [RFC2045] production of the same name, as well as other uses of the same term. These have been clarified. A clarification was added on the extent of the 7bit nature of MDNs. Uses of the terms "may" and "might" were clarified. A clarification was added on the order of the fields in the message/ disposition-notification content. Authors' Addresses Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA Email: tony@att.com Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP UK Email: Alexey.Melnikov@isode.com Hansen & Melnikov Expires June 4, 2017 [Page 37] ./draft-ietf-lisp-crypto-10.txt0000664000764400076440000012674013000746276015657 0ustar iustyiusty Internet Engineering Task Force D. Farinacci Internet-Draft lispers.net Intended status: Experimental B. Weis Expires: April 17, 2017 cisco Systems October 14, 2016 LISP Data-Plane Confidentiality draft-ietf-lisp-crypto-10 Abstract This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 17, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Farinacci & Weis Expires April 17, 2017 [Page 1] Internet-Draft LISP Data-Plane Confidentiality October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 4 6. Encoding and Transmitting Key Material . . . . . . . . . . . 5 7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 8 8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 10 9. Procedures for Encryption and Decryption . . . . . . . . . . 11 10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 12 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 13 12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 17 B.1. Changes to draft-ietf-lisp-crypto-10.txt . . . . . . . . 17 B.2. Changes to draft-ietf-lisp-crypto-09.txt . . . . . . . . 18 B.3. Changes to draft-ietf-lisp-crypto-08.txt . . . . . . . . 18 B.4. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 18 B.5. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 18 B.6. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 18 B.7. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 18 B.8. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 18 B.9. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 19 B.10. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 19 B.11. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 19 B.12. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 20 B.13. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The Locator/ID Separation Protocol [RFC6830] defines a set of functions for routers to exchange information used to map from non- routable Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel Farinacci & Weis Expires April 17, 2017 [Page 2] Internet-Draft LISP Data-Plane Confidentiality October 2016 Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs) and Reencapsulating Tunnel Routers (RTRs). Packets that arrive at the ITR or PITR may not be encrypted, which means no protection or privacy of the data is added. When the source host encrypts the data stream, encapsulated packets do not need to be encrypted by LISP. However, when plaintext packets are sent by hosts, this design can encrypt the user payload to maintain privacy on the path between the encapsulator (the ITR or PITR) to a decapsulator (ETR or RTR). The encrypted payload is unidirectional. However, return traffic uses the same procedures but with different key values by the same xTRs or potentially different xTRs when the paths between LISP sites are asymmetric. This document has the following requirements (as well as the general requirements from [RFC6973]) for the solution space: o Do not require a separate Public Key Infrastructure (PKI) that is out of scope of the LISP control-plane architecture. o The budget for key exchange MUST be one round-trip time. That is, only a two packet exchange can occur. o Use symmetric keying so faster cryptography can be performed in the LISP data plane. o Avoid a third-party trust anchor if possible. o Provide for rekeying when secret keys are compromised. o Support Authenticated Encryption with packet integrity checks. o Support multiple cipher suites so new crypto algorithms can be easily introduced. Satisfying the above requirements provides the following benefits: o Avoiding a PKI reduces the operational cost of managing a secure network. Key management is distributed and independent from any other infrastructure. o Packet transport is optimized due to less packet headers. Packet loss is reduced by a more efficient key exchange. o Authentication and privacy are provided with a single mechanism thereby providing less per packet overhead and therefore more resource efficiency. Farinacci & Weis Expires April 17, 2017 [Page 3] Internet-Draft LISP Data-Plane Confidentiality October 2016 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms AEAD: Authenticated Encryption with Additional Data [RFC5116]. ICV: Integrity Check Value. LCAF: LISP Canonical Address Format ([LCAF]). xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs. 4. Overview The approach proposed in this document is to NOT rely on the LISP mapping system (or any other key infrastructure system) to store security keys. This will provide for a simpler and more secure mechanism. Secret shared keys will be negotiated between the ITR and the ETR in Map-Request and Map-Reply messages. Therefore, when an ITR needs to obtain the RLOC of an ETR, it will get security material to compute a shared secret with the ETR. The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating to. When the ITR encrypts a packet before encapsulation, it will identify the key it used for the crypto calculation so the ETR knows which key to use for decrypting the packet after decapsulation. By using key-ids in the LISP header, we can also get fast rekeying functionality. The key management described in this documemnt is unidirectional from the ITR (the encapsulator) to the ETR (the decapsultor). 5. Diffie-Hellman Key Exchange LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and computation for computing a shared secret. The Diffie-Hellman parameters will be passed via Cipher Suite code-points in Map-Request and Map-Reply messages. Here is a brief description how Diff-Hellman works: Farinacci & Weis Expires April 17, 2017 [Page 4] Internet-Draft LISP Data-Plane Confidentiality October 2016 +----------------------------+---------+----------------------------+ | ITR | | ETR | +------+--------+------------+---------+------------+---------------+ |Secret| Public | Calculates | Sends | Calculates | Public |Secret| +------|--------|------------|---------|------------|--------|------+ | i | p,g | | p,g --> | | | e | +------|--------|------------|---------|------------|--------|------+ | i | p,g,I |g^i mod p=I | I --> | | p,g,I | e | +------|--------|------------|---------|------------|--------|------+ | i | p,g,I | | <-- E |g^e mod p=E | p,g | e | +------|--------|------------|---------|------------|--------|------+ | i,s |p,g,I,E |E^i mod p=s | |I^e mod p=s |p,g,I,E | e,s | +------|--------|------------|---------|------------|--------|------+ Public-key exchange for computing a shared private key [DH] Diffie-Hellman parameters 'p' and 'g' must be the same values used by the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' in a Map-Request packet. When the ETR receives the Map-Request, it uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The ETR transmits 'E' in a Map-Reply message. At this point, the ETR has enough information to compute 's', the shared secret, by using 'I' as the base and the ETR's private key 'e' as the exponent. When the ITR receives the Map-Reply, it uses the ETR's public-key 'E' with the ITR's private key 'i' to compute the same 's' shared secret the ETR computed. The value 'p' is used as a modulus to create the width of the shared secret 's' (see Section 6). 6. Encoding and Transmitting Key Material The Diffie-Hellman key material is transmitted in Map-Request and Map-Reply messages. Diffie-Hellman parameters are encoded in the LISP Security Type LCAF [LCAF]. Farinacci & Weis Expires April 17, 2017 [Page 5] Internet-Draft LISP Data-Plane Confidentiality October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Public Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Public Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions The 'Key Count' field encodes the number of {'Key-Length', 'Key- Material'} fields included in the encoded LCAF. The maximum number of keys that can be encoded are 3, each identified by key-id 1, followed by key-id 2, and finally key-id 3. The 'R' bit is not used for this use-case of the Security Type LCAF but is reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be transmitted as 0 and MUST be ignored on receipt. Farinacci & Weis Expires April 17, 2017 [Page 6] Internet-Draft LISP Data-Plane Confidentiality October 2016 Cipher Suite 0: Reserved Cipher Suite 1: Diffie-Hellman Group: 2048-bit MODP [RFC3526] Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 IV length: 16 bytes KDF: HMAC-SHA-256 Cipher Suite 2: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 IV length: 16 bytes KDF: HMAC-SHA-256 Cipher Suite 3: Diffie-Hellman Group: 2048-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes KDF: HMAC-SHA-256 Cipher Suite 4: Diffie-Hellman Group: 3072-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes KDF: HMAC-SHA-256 Cipher Suite 5: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes KDF: HMAC-SHA-256 Cipher Suite 6: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539] Integrity: Integrated with [CHACHA-POLY] AEAD_CHACHA20_POLY1305 IV length: 8 bytes KDF: HMAC-SHA-256 Farinacci & Weis Expires April 17, 2017 [Page 7] Internet-Draft LISP Data-Plane Confidentiality October 2016 The "Public Key Material" field contains the public key generated by one of the Cipher Suites defined above. The length of the key in octets is encoded in the "Key Length" field. When an ITR, PITR, or RTR sends a Map-Request, they will encode their own RLOC in the Security Type LCAF format within the ITR-RLOCs field. When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in Security Type LCAF format within the RLOC-record field of each EID- record supplied. If an ITR, PITR, or RTR sends a Map-Request with the Security Type LCAF included and the ETR or RTR does not want to have encapsulated traffic encrypted, they will return a Map-Reply with no RLOC records encoded with the Security Type LCAF. This signals to the ITR, PITR or RTR not to encrypt traffic (it cannot encrypt traffic anyways since no ETR public-key was returned). Likewise, if an ITR or PITR wish to include multiple key-ids in the Map-Request but the ETR or RTR wish to use some but not all of the key-ids, they return a Map-Reply only for those key-ids they wish to use. 7. Shared Keys used for the Data-Plane When an ITR or PITR receives a Map-Reply accepting the Cipher Suite sent in the Map-Request, it is ready to create data plane keys. The same process is followed by the ETR or RTR returning the Map-Reply. The first step is to create a shared secret, using the peer's shared Diffie-Hellman Public Key Material combined with device's own private keying material as described in Section 5. The Diffie-Hellman parameters used is defined in the cipher suite sent in the Map- Request and copied into the Map-Reply. The resulting shared secret is used to compute an AEAD-key for the algorithms specified in the cipher suite. A Key Derivation Function (KDF) in counter mode as specified by [NIST-SP800-108] is used to generate the data-plane keys. The amount of keying material that is derived depends on the algorithms in the cipher suite. The inputs to the KDF are as follows: o KDF function. This is HMAC-SHA-256 in this document but generally specified in each Cipher Suite definition. o A key for the KDF function. This is the computed Diffie-Hellman shared secret. Farinacci & Weis Expires April 17, 2017 [Page 8] Internet-Draft LISP Data-Plane Confidentiality October 2016 o Context that binds the use of the data-plane keys to this session. The context is made up of the following fields, which are concatenated and provided as the data to be acted upon by the KDF function. Context: o A counter, represented as a two-octet value in network byte order. o The null-terminated string "lisp-crypto". o The ITR's nonce from the Map-Request the cipher suite was included in. o The number of bits of keying material required (L), represented as a two-octet value in network byte order. The counter value in the context is first set to 1. When the amount of keying material exceeds the number of bits returned by the KDF function, then the KDF function is called again with the same inputs except that the counter increments for each call. When enough keying material is returned, it is concatenated and used to create keys. For example, AES with 128-bit keys requires 16 octets (128 bits) of keying material, and HMAC-SHA1-96 requires another 16 octets (128 bits) of keying material in order to maintain a consistent 128-bits of security. Since 32 octets (256 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, only one call is required. The inputs are as follows: key-material = HMAC-SHA-256(dh-shared-secret, context) where: context = 0x0001 || "lisp-crypto" || || 0x0100 In contrast, a cipher suite specifying AES with 256-bit keys requires 32 octets (256 bits) of keying material, and HMAC-SHA256-128 requires another 32 octets (256 bits) of keying material in order to maintain a consistent 256-bits of security. Since 64 octets (512 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, two calls are required. Farinacci & Weis Expires April 17, 2017 [Page 9] Internet-Draft LISP Data-Plane Confidentiality October 2016 key-material-1 = HMAC-SHA-256(dh-shared-secret, context) where: context = 0x0001 || "lisp-crypto" || || 0x0200 key-material-2 = HMAC-SHA-256(dh-shared-secret, context) where: context = 0x0002 || "lisp-crypto" || || 0x0200 key-material = key-material-1 || key-material-2 If the key-material is longer than the required number of bits (L), then only the most significant L bits are used. From the derived key-material, the most significant 256 bits are used for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided into a 128-bit encryption key and a 128-bit integrity check key internal to the cipher used by the ITR. 8. Data-Plane Operation The LISP encapsulation header [RFC6830] requires changes to encode the key-id for the key being used for encryption. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = 4341 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L / |N|L|E|V|I|R|K|K| Nonce/Map-Version |\ \ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A S \ | Instance ID/Locator-Status-Bits | |D P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |/ | Initialization Vector (IV) | I E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C n / | | V c | | | r | Packet Payload with EID Header ... | | y | | | p \ | |/ t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K-bits indicate when packet is encrypted and which key used When the KK bits are 00, the encapsulated packet is not encrypted. When the value of the KK bits are 1, 2, or 3, it encodes the key-id of the secret keys computed during the Diffie-Hellman Map-Request/ Farinacci & Weis Expires April 17, 2017 [Page 10] Internet-Draft LISP Data-Plane Confidentiality October 2016 Map-Reply exchange. When the KK bits are not 0, the payload is prepended with an Initialization Vector (IV). The length of the IV field is based on the cipher suite used. Since all cipher suites defined in this document do Authenticated Encryption (AEAD), an ICV field does not need to be present in the packet since it is included in the ciphertext. The Additional Data (AD) used for the ICV is shown above and includes the LISP header, the IV field and the packet payload. When an ITR or PITR receives a packet to be encapsulated, the device will first decide what key to use, encode the key-id into the LISP header, and use that key to encrypt all packet data that follows the LISP header. Therefore, the outer header, UDP header, and LISP header travel as plaintext. There is an open working group item to discuss if the data encapsulation header needs change for encryption or any new applications. This document proposes changes to the existing header so experimentation can continue without making large changes to the data-plane at this time. This document allocates 2 bits of the previously unused 3 flag bits (note the R-bit above is still a reserved flag bit as documented in [RFC6830]) for the KK bits. 9. Procedures for Encryption and Decryption When an ITR, PITR, or RTR encapsulate a packet and have already computed an AEAD-key (detailed in section Section 7) that is associated with a destination RLOC, the following encryption and encapsulation procedures are performed: 1. The encapsulator creates an IV and prepends the IV value to the packet being encapsulated. For GCM and Chacha cipher suites, the IV is incremented for every packet (beginning with a value of 1 in the first packet) and sent to the destination RLOC. For CBC cipher suites, the IV is a new random number for every packet sent to the destination RLOC. For the Chacha cipher suite, the IV is an 8-byte random value that is appended to a 4-byte counter that is incremented for every packet (beginning with a value of 1 in the first packet). 2. Next encrypt with cipher function AES or Chacha20 using the AEAD- key over the packet payload following the AEAD specification referenced in the cipher suite definition. This does not include the IV. The IV must be transmitted as plaintext so the decrypter can use it as input to the decryption cipher. The payload should be padded to an integral number of bytes a block cipher may require. The result of the AEAD operation may contain an ICV, the size of which is defined by the referenced AEAD Farinacci & Weis Expires April 17, 2017 [Page 11] Internet-Draft LISP Data-Plane Confidentiality October 2016 specification. Note that the AD (i.e. the LISP header exactly as will be prepended in the next step and the IV) must be given to the AEAD encryption function as the "associated data" argument. 3. Prepend the LISP header. The key-id field of the LISP header is set to the key-id value that corresponds to key-pair used for the encryption cipher. 4. Lastly, prepend the UDP header and outer IP header onto the encrypted packet and send packet to destination RLOC. When an ETR, PETR, or RTR receive an encapsulated packet, the following decapsulation and decryption procedures are performed: 1. The outer IP header, UDP header, LISP header, and IV field are stripped from the start of the packet. The LISP header and IV are retained and given to the AEAD decryption operation as the "associated data" argument. 2. The packet is decrypted using the AEAD-key and the IV from the packet. The AEAD-key is obtained from a local-cache associated with the key-id value from the LISP header. The result of the decryption function is a plaintext packet payload if the cipher returned a verified ICV. Otherwise, the packet is invalid and is discarded. If the AEAD specification included an ICV, the AEAD decryption function will locate the ICV in the ciphertext and compare it to a version of the ICV that the AEAD decryption function computes. If the computed ICV is different than the ICV located in the ciphertext, then it will be considered tampered. 3. If the packet was not tampered with, the decrypted packet is forwarded to the destination EID. 10. Dynamic Rekeying Since multiple keys can be encoded in both control and data messages, an ITR can encapsulate and encrypt with a specific key while it is negotiating other keys with the same ETR. As soon as an ETR or RTR returns a Map-Reply, it should be prepared to decapsulate and decrypt using the new keys computed with the new Diffie-Hellman parameters received in the Map-Request and returned in the Map-Reply. RLOC-probing can be used to change keys or cipher suites by the ITR at any time. And when an initial Map-Request is sent to populate the ITR's map-cache, the Map-Request flows across the mapping system where a single ETR from the Map-Reply RLOC-set will respond. If the ITR decides to use the other RLOCs in the RLOC-set, it MUST send a Map-Request directly to negotiate security parameters with the ETR. Farinacci & Weis Expires April 17, 2017 [Page 12] Internet-Draft LISP Data-Plane Confidentiality October 2016 This process may be used to test reachability from an ITR to an ETR initially when a map-cache entry is added for the first time, so an ITR can get both reachability status and keys negotiated with one Map-Request/Map-Reply exchange. A rekeying event is defined to be when an ITR or PITR changes the cipher suite or public-key in the Map-Request. The ETR or RTR compares the cipher suite and public-key it last received from the ITR for the key-id, and if any value has changed, it computes a new public-key and cipher suite requested by the ITR from the Map-Request and returns it in the Map-Reply. Now a new shared secret is computed and can be used for the key-id for encryption by the ITR and decryption by the ETR. When the ITR or PITR starts this process of negotiating a new key, it must not use the corresponding key-id in encapsulated packets until it receives a Map-Reply from the ETR with the same cipher suite value it expects (the values it sent in a Map- Request). Note when RLOC-probing continues to maintain RLOC reachability and rekeying is not desirable, the ITR or RTR can either not include the Security Type LCAF in the Map-Request or supply the same key material as it received from the last Map-Reply from the ETR or RTR. This approach signals to the ETR or RTR that no rekeying event is requested. 11. Future Work For performance considerations, newer Elliptic-Curve Diffie-Hellman (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to reduce CPU cycles required to compute shared secret keys. For better security considerations as well as to be able to build faster software implementations, newer approaches to ciphers and authentication methods will be researched and tested. Some examples are Chacha20 and Poly1305 [CHACHA-POLY] [RFC7539]. 12. Security Considerations 12.1. SAAG Support The LISP working group received security advice and guidance from the Security Area Advisory Group (SAAG). The SAAG has been involved early in the design process and their input and reviews have been included in this document. Comments from the SAAG included: 1. Do not use asymmetric ciphers in the data-plane. Farinacci & Weis Expires April 17, 2017 [Page 13] Internet-Draft LISP Data-Plane Confidentiality October 2016 2. Consider adding ECDH early in the design. 3. Add cipher suites because ciphers are created more frequently than protocols that use them. 4. Consider the newer AEAD technology so authentication comes with doing encryption. 12.2. LISP-Crypto Security Threats Since ITRs and ETRs participate in key exchange over a public non- secure network, a man-in-the-middle (MITM) could circumvent the key exchange and compromise data-plane confidentiality. This can happen when the MITM is acting as a Map-Replier, provides its own public key so the ITR and the MITM generate a shared secret key among each other. If the MITM is in the data path between the ITR and ETR, it can use the shared secret key to decrypt traffic from the ITR. Since LISP can secure Map-Replies by the authentication process specified in [LISP-SEC], the ITR can detect when a MITM has signed a Map-Reply for an EID-prefix it is not authoritative for. When an ITR determines the signature verification fails, it discards and does not reuse the key exchange parameters, avoids using the ETR for encapsulation, and issues a severe log message to the network administrator. Optionally, the ITR can send RLOC-probes to the compromised RLOC to determine if can reach the authoritative ETR. And when the ITR validates the signature of a Map-Reply, it can begin encrypting and encapsulating packets to the RLOC of ETR. 13. IANA Considerations This document describes a mechanism for encrypting LISP encapsulated packets based on Diffie-Hellman key exchange procedures. During the exchange the devices have to agree on a Cipher Suite used (i.e. the cipher and hash functions used to encrypt/decrypt and to sign/verify packets). The 8-bit Cipher Suite field is reserved for such purpose in the security material section of the Map-Request and Map-Reply messages. This document requests IANA to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP Crypto Cipher Suite". Initial values for the registry are provided below. Future assignments are to be made on a First Come First Served Basis. Farinacci & Weis Expires April 17, 2017 [Page 14] Internet-Draft LISP Data-Plane Confidentiality October 2016 +-----+--------------------------------------------+------------+ |Value| Suite | Definition | +-----+--------------------------------------------+------------+ | 0 | Reserved | Section 6 | +-----+--------------------------------------------+------------+ | 1 | LISP_2048MODP_AES128_CBC_SHA256 | Section 6 | +-----+--------------------------------------------+------------+ | 2 | LISP_EC25519_AES128_CBC_SHA256 | Section 6 | +-----+--------------------------------------------+------------+ | 3 | LISP_2048MODP_AES128_GCM | Section 6 | +-----+--------------------------------------------+------------+ | 4 | LISP_3072MODP_AES128_GCM M-3072 | Section 6 | +-----+--------------------------------------------+------------+ | 5 | LISP_256_EC25519_AES128_GCM | Section 6 | +-----+--------------------------------------------+------------+ | 6 | LISP_256_EC25519_CHACHA20_POLY1305 | Section 6 | +-----+--------------------------------------------+------------+ LISP Crypto Cipher Suites 14. References 14.1. Normative References [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-13.txt (work in progress). [NIST-SP800-108] "National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions NIST SP800-108"", NIST SP 800-108, October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, . [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, . Farinacci & Weis Expires April 17, 2017 [Page 15] Internet-Draft LISP Data-Plane Confidentiality October 2016 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, . 14.2. Informative References [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- aes-cbc-hmac-sha2-05.txt (work in progress). [CHACHA-POLY] Langley, A., "ChaCha20 and Poly1305 based Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04 (work in progress). Farinacci & Weis Expires April 17, 2017 [Page 16] Internet-Draft LISP Data-Plane Confidentiality October 2016 [CURVE25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", Publication http://www.iacr.org/cryptodb/archive/2006/ PKC/3351/3351.pdf. [DH] "Diffie-Hellman key exchange", Wikipedia http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange. [LISP-DDT] Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP Delegated Database Tree", draft-fuller-lisp-ddt-04 (work in progress). [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-10 (work in progress). Appendix A. Acknowledgments The authors would like to thank Dan Harkins, Joel Halpern, Fabio Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest, suggestions, and discussions about LISP data-plane security. An individual thank you to LISP WG chair Luigi Iannone for shepherding this document as well as contributing to the IANA Considerations section. The authors would like to give a special thank you to Ilari Liusvaara for his extensive commentary and discussion. He has contributed his security expertise to make lisp-crypto as secure as the state of the art in cryptography. In addition, the support and suggestions from the SAAG working group were helpful and appreciative. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-crypto-10.txt o Posted October 2016 after October 13th telechat. o Addressed comments from Kathleen Moriarty, Stephen Farrel, and Pete Resnick. Farinacci & Weis Expires April 17, 2017 [Page 17] Internet-Draft LISP Data-Plane Confidentiality October 2016 B.2. Changes to draft-ietf-lisp-crypto-09.txt o Posted October 2016. o Addressed comments from OPs Directorate reviewer Susan Hares. B.3. Changes to draft-ietf-lisp-crypto-08.txt o Posted September 2016. o Addressed comments from Security Directorate reviewer Chris Lonvick. B.4. Changes to draft-ietf-lisp-crypto-07.txt o Posted September 2016. o Addressed comments from Routing Directorate reviewer Danny McPherson. B.5. Changes to draft-ietf-lisp-crypto-06.txt o Posted June 2016. o Fixed IDnits errors. B.6. Changes to draft-ietf-lisp-crypto-05.txt o Posted June 2016. o Update document which reflects comments Luigi provided as document shepherd. B.7. Changes to draft-ietf-lisp-crypto-04.txt o Posted May 2016. o Update document timer from expiration. B.8. Changes to draft-ietf-lisp-crypto-03.txt o Posted December 2015. o Changed cipher suite allocations. We now have 2 AES-CBC cipher suites for compatibility, 3 AES-GCM cipher suites that are faster ciphers that include AE and a Chacha20-Poly1305 cipher suite which is the fastest but not totally proven/accepted.. Farinacci & Weis Expires April 17, 2017 [Page 18] Internet-Draft LISP Data-Plane Confidentiality October 2016 o Remove 1024-bit DH keys for key exchange. o Make clear that AES and chacha20 ciphers use AEAD so part of encrytion/decryption does authentication. o Make it more clear that separate key pairs are used in each direction between xTRs. o Indicate that the IV length is different per cipher suite. o Use a counter based IV for every packet for AEAD ciphers. Previously text said to use a random number. But CBC ciphers, use a random number. o Indicate that key material is sent in network byte order (big endian). o Remove A-bit from Security Type LCAF. No need to do authentication only with the introduction of AEAD ciphers. These ciphers can do authentication. So you get ciphertext for free. o Remove language that refers to "encryption-key" and "integrity- key". Used term "AEAD-key" that is used by the AEAD cipher suites that do encryption and authenticaiton internal to the cipher. B.9. Changes to draft-ietf-lisp-crypto-02.txt o Posted September 2015. o Add cipher suite for Elliptic Curve 25519 DH exchange. o Add cipher suite for Chacha20/Poly1305 ciphers. B.10. Changes to draft-ietf-lisp-crypto-01.txt o Posted May 2015. o Create cipher suites and encode them in the Security LCAF. o Add IV to beginning of packet header and ICV to end of packet. o AEAD procedures are now part of encrpytion process. B.11. Changes to draft-ietf-lisp-crypto-00.txt o Posted January 2015. Farinacci & Weis Expires April 17, 2017 [Page 19] Internet-Draft LISP Data-Plane Confidentiality October 2016 o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- 00. This draft has become a working group document o Add text to indicate the working group may work on a new data encapsulation header format for data-plane encryption. B.12. Changes to draft-farinacci-lisp-crypto-01.txt o Posted July 2014. o Add Group-ID to the encoding format of Key Material in a Security Type LCAF and modify the IANA Considerations so this draft can use key exchange parameters from the IANA registry. o Indicate that the R-bit in the Security Type LCAF is not used by lisp-crypto. o Add text to indicate that ETRs/RTRs can negotiate less number of keys from which the ITR/PITR sent in a Map-Request. o Add text explaining how LISP-SEC solves the problem when a man-in- the-middle becomes part of the Map-Request/Map-Reply key exchange process. o Add text indicating that when RLOC-probing is used for RLOC reachability purposes and rekeying is not desired, that the same key exchange parameters should be used so a reallocation of a pubic key does not happen at the ETR. o Add text to indicate that ECDH can be used to reduce CPU requirements for computing shared secret-keys. B.13. Changes to draft-farinacci-lisp-crypto-00.txt o Initial draft posted February 2014. Authors' Addresses Dino Farinacci lispers.net San Jose, California 95120 USA Phone: 408-718-2001 Email: farinacci@gmail.com Farinacci & Weis Expires April 17, 2017 [Page 20] Internet-Draft LISP Data-Plane Confidentiality October 2016 Brian Weis cisco Systems 170 West Tasman Drive San Jose, California 95124-1706 USA Phone: 408-526-4796 Email: bew@cisco.com Farinacci & Weis Expires April 17, 2017 [Page 21] ./draft-ietf-aqm-docsis-pie-02.txt0000664000764400076440000007702312660522460016203 0ustar iustyiusty Active Queue Management and Packet Scheduling (aqm) G. White Internet-Draft CableLabs Intended status: Informational R. Pan Expires: August 15, 2016 Cisco Systems February 12, 2016 A PIE-Based AQM for DOCSIS Cable Modems draft-ietf-aqm-docsis-pie-02 Abstract Cable modems based on the DOCSIS(R) specification provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on Active Queue Management that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 15, 2016. White & Pan Expires August 15, 2016 [Page 1] Internet-Draft docsis-pie February 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview of DOCSIS AQM Requirements . . . . . . . . . . . . . 3 3. The DOCSIS MAC Layer and Service Flows . . . . . . . . . . . 3 4. DOCSIS-PIE vs. PIE . . . . . . . . . . . . . . . . . . . . . 5 4.1. Latency Target . . . . . . . . . . . . . . . . . . . . . 5 4.2. Departure rate estimation . . . . . . . . . . . . . . . . 5 4.3. Enhanced burst protection . . . . . . . . . . . . . . . . 6 4.4. Expanded auto-tuning range . . . . . . . . . . . . . . . 7 4.5. Trigger for exponential decay . . . . . . . . . . . . . . 7 4.6. Drop probability scaling . . . . . . . . . . . . . . . . 7 4.7. Support for explicit congestion notification . . . . . . 8 5. Implementation Guidance . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . 9 Appendix A. DOCSIS-PIE Algorithm definition . . . . . . . . . . 9 A.1. DOCSIS-PIE AQM Constants and Variables . . . . . . . . . 10 A.1.1. Configuration parameters . . . . . . . . . . . . . . 10 A.1.2. Constant values . . . . . . . . . . . . . . . . . . . 10 A.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 10 A.1.4. Public/system functions: . . . . . . . . . . . . . . 11 A.2. DOCSIS-PIE AQM Control Path . . . . . . . . . . . . . . . 11 A.3. DOCSIS-PIE AQM Data Path . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction A recent resurgence of interest in Active Queue Management, arising from a recognition of the inadequacies of drop tail queuing in the presence of loss-based congestion control algorithms, has resulted in the development of new algorithms that appear to provide very good White & Pan Expires August 15, 2016 [Page 2] Internet-Draft docsis-pie February 2016 congestion feedback to current TCP algorithms, while also having operational simplicity and low complexity. One of these algorithms has been selected as a requirement for cable modems built according to the DOCSIS 3.1 specification [DOCSIS_3.1]. The Data Over Cable Service Interface Specifications (DOCSIS) define the broadband technology deployed worldwide for Ethernet and IP service over hybrid fiber-coaxial cable systems. The most recent revision of the DOCSIS technology, version 3.1, was published in October 2013 and provides support for up to 10 Gbps downstream (toward the customer) and 1 Gbps upstream (from the customer) capacity over existing cable networks. Previous versions of the DOCSIS technology did not contain requirements for AQM. This document outlines the high-level AQM requirements for DOCSIS systems, discusses some of the salient features of the DOCSIS MAC layer, and describes the DOCSIS-PIE algorithm - largely by comparing it to its progenitor, the [I-D.ietf-aqm-pie] algorithm. 2. Overview of DOCSIS AQM Requirements CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1] mandates that cable modems implement a specific variant of the Proportional Integral controller Enhanced (PIE) [I-D.ietf-aqm-pie] active queue management algorithm. This specific variant is provided for reference in Appendix A, and simulation results comparing it to drop tail queuing and other AQM options are given in [CommMag] and [DOCSIS-AQM]. In addition, CableLabs' DOCSIS 3.0 specification [DOCSIS_3.0] has been amended to recommend that cable modems implement the same algorithm. Both specifications allow that cable modems can optionally implement additional algorithms, that can then be selected for use by the operator via the modem's configuration file. These requirements on the cable modem apply to upstream transmissions (i.e. from the customer to the Internet). Both specifications also include requirements (mandatory in DOCSIS 3.1 and recommended in DOCSIS 3.0) that the Cable Modem Termination System (CMTS) implement active queue management for downstream traffic, however no specific algorithm is defined for downstream use. 3. The DOCSIS MAC Layer and Service Flows The DOCSIS Media Access Control (sub-)layer provides tools for configuring differentiated Quality of Service for different applications by the use of Packet Classifiers and Service Flows. Each Service Flow has an associated Quality of Service (QoS) parameter set that defines the treatment of the packets that traverse the Service Flow. These parameters include (for example) Minimum White & Pan Expires August 15, 2016 [Page 3] Internet-Draft docsis-pie February 2016 Reserved Traffic Rate, Maximum Sustained Traffic Rate, Peak Traffic Rate, Maximum Traffic Burst, and Traffic Priority. Each upstream Service Flow corresponds to a queue in the cable modem, and each downstream Service Flow corresponds to a queue in the CMTS. The DOCSIS AQM requirements mandate that the CM and CMTS implement the AQM algorithm (and allow it to be disabled if need be) on each Service Flow queue independently. Packet Classifiers can match packets based upon several fields in the packet/frame headers including the Ethernet header, IP header, and TCP/UDP header. Matched packets are then queued in the associated Service Flow queue. Each cable modem can be configured with multiple Packet Classifiers and Service Flows. The maximum number of such entities that a cable modem supports is an implementation decision for the manufacturer, but modems typically support 16 or 32 upstream Service Flows and at least that many Packet Classifiers. Similarly the CMTS supports multiple downstream Service Flows and multiple Packet Classifiers per cable modem. It is typical that upstream and downstream Service Flows used for broadband Internet access are configured with a Maximum Sustained Traffic Rate. This QoS parameter rate-shapes the traffic onto the DOCSIS link, and is the main parameter that defines the service offering. Additionally, it is common that upstream and downstream Service Flows are configured with a Maximum Traffic Burst and a Peak Traffic Rate. These parameters allow the service to burst at a higher (sometimes significantly higher) rate than is defined in the Maximum Sustained Traffic Rate for the amount of bytes configured in Maximum Traffic Burst, as long as the long-term average data rate remains at or below the Maximum Sustained Traffic Rate. Mathematically, what is enforced is that the traffic placed on the DOCSIS link in the time interval (t1,t2) complies with the following rate shaping equations: TxBytes(t1,t2) <= (t2-t1)*R/8 + B TxBytes(t1,t2) <= (t2-t1)*P/8 + 1522 for all values t2>t1, where: R = Maximum Sustained Traffic Rate (bps) P = Peak Traffic Rate (bps) B = Maximum Traffic Burst (bytes) White & Pan Expires August 15, 2016 [Page 4] Internet-Draft docsis-pie February 2016 The result of this configuration is that the link rate available to the Service Flow varies based on the pattern of load. If the load that the Service Flow places on the link is less than the Maximum Sustained Traffic Rate, the Service Flow "earns" credit that it can then use (should the load increase) to burst at the Peak Traffic Rate. This dynamic is important since these rate changes (particularly the decrease in data rate once the traffic burst credit is exhausted) can induce a step increase in buffering latency. 4. DOCSIS-PIE vs. PIE There are a number of differences between the version of the PIE algorithm that is mandated for cable modems in the DOCSIS specifications and the version described in [I-D.ietf-aqm-pie]. These differences are described in the following subsections. 4.1. Latency Target The latency target (aka delay reference) is a key parameter that affects, among other things, the tradeoff in performance between latency-sensitive applications and bulk TCP applications. Via simulation studies, a value of 10ms was identified as providing a good balance of performance. However, it is recognized that there may be service offerings for which this value doesn't provide the best performance balance. As a result, this is provided as a configuration parameter that the operator can set independently on each upstream service flow. If not explicitly set by the operator, the modem will use 10 ms as the default value. 4.2. Departure rate estimation The PIE algorithm utilizes a departure rate estimator to track fluctuations in the egress rate for the queue and to generate a smoothed estimate of this rate for use in the drop probability calculation. This estimator may be well suited to many link technologies, but is not ideal for DOCSIS upstream links for a number of reasons. First, the bursty nature of the upstream transmissions, in which the queue drains at line rate (up to ~100 Mbps for DOCSIS 3.0 and ~1 Gbps for DOCSIS 3.1) and then is blocked until the next transmit opportunity, results in the potential for inaccuracy in measurement, given that the PIE departure rate estimator starts each measurement during a transmission burst and ends each measurement during a (possibly different) transmission burst. For example, in the case where the start and end of measurement occur within a single burst, the PIE estimator will calculate the egress rate to be equal to the line rate, rather than the average rate available to the modem. White & Pan Expires August 15, 2016 [Page 5] Internet-Draft docsis-pie February 2016 Second, the latency introduced by the DOCSIS request-grant mechanism can result in some further inaccuracy. In typical conditions, the request-grant mechanism can add between ~4 ms and ~8 ms of latency to the forwarding of upstream traffic. Within that range, the amount of additional latency that affects any individual data burst is effectively random, being influenced by the arrival time of the burst relative to the next request transmit opportunity, among other factors. Third, in the significant majority of cases, the departure rate, while variable, is controlled by the modem itself via the pair of token bucket rate shaping equations described in Section 3. Together, these two equations enforce a maximum sustained traffic rate, a peak traffic rate, and a maximum traffic burst size for the modem's requested bandwidth. The implication of this is that the modem, in the significant majority of cases, will know precisely what the departure rate will be, and can predict exactly when transitions between peak rate and maximum sustained traffic rate will occur. Compare this to the PIE estimator, which would be simply reacting to (and smoothing its estimate of) those rate transitions after the fact. Finally, since the modem is already implementing the dual token bucket traffic shaper, it contains enough internal state to calculate predicted queuing delay with a minimum of computations. Furthermore, these computations only need to be run every drop probability update interval, as opposed to the PIE estimator, which runs a similar number of computations on each packet dequeue event. For these reasons, the DOCSIS-PIE algorithm utilizes the configuration and state of the dual token bucket traffic shaper to translate queue depth into predicted queuing delay, rather than implementing the departure rate estimator defined in PIE. 4.3. Enhanced burst protection The PIE [I-D.ietf-aqm-pie] algorithm has two states, INACTIVE and ACTIVE. During the INACTIVE state, AQM packet drops are suppressed. The algorithm transitions to the ACTIVE state when the queue exceeds 1/3 of the buffer size. Upon transition to the ACTIVE state, PIE includes a burst protection feature in which the AQM packet drops are suppressed for the first 150ms. Since DOCSIS-PIE is predominantly deployed on consumer broadband connections, a more sophisticated burst protection was developed in order to provide better performance in the presence of a single TCP session. Where the PIE algorithm has two states, DOCSIS-PIE has three. The INACTIVE and ACTIVE states in DOCSIS-PIE are identical to those White & Pan Expires August 15, 2016 [Page 6] Internet-Draft docsis-pie February 2016 states in PIE. The QUIESCENT state is a transitional state between INACTIVE and ACTIVE. The DOCSIS-PIE algorithm transitions from INACTIVE to QUIESCENT when the queue exceeds 1/3 of the buffer size. In the QUIESCENT state, packet drops are immediately enabled, and upon the first packet drop, the algorithm transitions to the ACTIVE state (where drop probability is reset to zero for the 150ms duration of the burst protection as in PIE). From the ACTIVE state, the algorithm transitions to QUIESCENT if the drop_probability has decayed to zero and the queuing latency has been less than half of the LATENCY_TARGET for two update intervals. The algorithm then fully resets to the INACTIVE state if this "quiet" condition exists for the duration of the BURST_RESET_TIMEOUT (1 second). One end result of the addition of the QUIESCENT state is that a single packet drop can occur relatively early on during an initial burst, whereas all drops would be suppressed for at least 150ms of the burst duration in PIE. The other end result is that if traffic stops and then resumes within 1 second, DOCSIS_PIE can directly drop a single packet and then re-enter burst protection, whereas PIE would require that the buffer exceed 1/3 full. 4.4. Expanded auto-tuning range The PIE algorithm scales the PI coefficients based on the current drop probability. The DOCSIS-PIE algorithm extends this scaling to drop probabilities below 1e-4. 4.5. Trigger for exponential decay The PIE algorithm includes a mechanism by which the drop probability is allowed to decay exponentially (rather than linearly) when it is detected that the buffer is empty. In the DOCSIS case, recently arrived packets may reside in buffer due to the request-grant latency even if the link is effectively idle. As a result, the buffer may not be identically empty in the situations for which the exponential decay is intended. To compensate for this, we trigger exponential decay when the buffer occupancy is less than 5ms * Peak Traffic Rate. 4.6. Drop probability scaling The DOCSIS-PIE algorithm scales the calculated drop probability based on the ratio of the packet size to a constant value of 1024 bytes (representing approximate average packet size). While [RFC7567] in general recommends against this type of scaling, we note that DOCSIS- PIE is expected to predominantly be used to manage upstream queues in residential broadband deployments, where we believe the benefits outweigh the disadvantages. As a safeguard to prevent a flood of small packets from starving flows that use larger packets, DOCSIS-PIE limits the scaled probability to a defined maximum value of 0.85. White & Pan Expires August 15, 2016 [Page 7] Internet-Draft docsis-pie February 2016 4.7. Support for explicit congestion notification DOCSIS-PIE does not include support for explicit congestion notification. Cable modems are essentially IEEE 802.1d Ethernet bridges and so are not designed to modify IP header fields. Additionally, the packet processing pipeline in a cable modem is commonly implemented in hardware. As a result, introducing support for ECN would have engendered a more significant redesign of cable modem data paths, and implementations would have been difficult or impossible to modify in the future. At the time of the development of DOCSIS-PIE, which coincided with the development of modem chip designs, the benefits of ECN marking relative to packet drop were considered to be relatively minor, there was considerable discussion about differential treatment of ECN capable packets in the AQM drop/ mark decision, and there were some initial suggestions that a new ECN approach was needed. Due to this uncertainty, we chose not to include support for ECN. 5. Implementation Guidance The AQM space is an evolving one, and it is expected that continued research in this field may in the future result in improved algorithms. As part of defining the DOCSIS-PIE algorithm, we split the pseudocode definition into two components, a "data path" component and a "control path" component. The control path component contains the packet drop probability update functionality, whereas the data path component contains the per-packet operations, including the drop decision logic. It is understood that some aspects of the cable modem implementation may be done in hardware, particularly functions that handle packet- processing. While the DOCSIS specifications don't mandate the internal implementation details of the cable modem, modem implementers are strongly advised against implementing the control path functionality in hardware. The intent of this advice is to retain the possibility that future improvements in AQM algorithms can be accommodated via software updates to deployed devices. 6. IANA Considerations This document has no actions for IANA. White & Pan Expires August 15, 2016 [Page 8] Internet-Draft docsis-pie February 2016 7. Security Considerations This document describes an active queue management algorithm based on [I-D.ietf-aqm-pie] for implementation in DOCSIS cable modem devices. This algorithm introduces no specific security exposures. 8. Informative References [CommMag] White, G., "Active queue management in DOCSIS 3.1 networks", IEEE Communications Magazine vol.53, no.3, pp.126-132, March 2015. [DOCSIS-AQM] White, G., "Active Queue Management in DOCSIS 3.x Cable Modems", May 2014, . [DOCSIS_3.0] CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols Specification", December 2015, . [DOCSIS_3.1] CableLabs, "DOCSIS 3.1 MAC and Upper Layer Protocols Specification", December 2015, . [I-D.ietf-aqm-pie] Pan, R., Natarajan, P., and F. Baker, "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", draft- ietf-aqm-pie-03 (work in progress), November 2015. [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . Appendix A. DOCSIS-PIE Algorithm definition PIE defines two functions organized here into two design blocks: 1. Control path block, a periodically running algorithm that calculates a drop probability based on the estimated queuing latency and queuing latency trend. White & Pan Expires August 15, 2016 [Page 9] Internet-Draft docsis-pie February 2016 2. Data path block, a function that occurs on each packet enqueue: per-packet drop decision based on the drop probability. It is desired to have the ability to update the Control path block based on operational experience with PIE deployments. A.1. DOCSIS-PIE AQM Constants and Variables A.1.1. Configuration parameters o LATENCY_TARGET. AQM Latency Target for this Service Flow o PEAK_RATE. Service Flow configured Peak Traffic Rate, expressed in Bytes/sec. o MSR. Service Flow configured Max. Sustained Traffic Rate, expressed in Bytes/sec. o BUFFER_SIZE. The size (in bytes) of the buffer for this Service Flow. A.1.2. Constant values o A = 0.25, B = 2.5. Weights in the drop probability calculation o INTERVAL = 16 ms. Update interval for drop probability. o BURST_RESET_TIMEOUT = 1 s. o MAX_BURST = 142 ms (150 ms - 8 ms (update error)) o MEAN_PKTSIZE = 1024 bytes o MIN_PKTSIZE = 64 bytes o PROB_LOW = 0.85 o PROB_HIGH = 8.5 o LATENCY_LOW = 5 ms o LATENCY_HIGH = 200 ms. A.1.3. Variables o drop_prob_. The current packet drop probability. o accu_prob_. accumulated drop prob. since last drop White & Pan Expires August 15, 2016 [Page 10] Internet-Draft docsis-pie February 2016 o qdelay_old_. The previous queue delay estimate. o burst_allowance_. Countdown for burst protection, initialize to 0 o burst_reset_. counter to reset burst o aqm_state_. AQM activity state encoding 3 states: INACTIVE - queue staying below 1/3 full, suppress AQM drops QUIESCENT - transition state ACTIVE - normal AQM drops (after burst protection period) o queue_. Holds the pending packets. A.1.4. Public/system functions: o drop(packet). Drops/discards a packet o random(). Returns a uniform r.v. in the range 0 ~ 1 o queue_.is_full(). Returns true if queue_ is full o queue_.byte_length(). Returns current queue_ length in bytes, including all MAC PDU bytes without DOCSIS MAC overhead o queue_.enque(packet). Adds packet to tail of queue_ o msrtokens(). Returns current token credits (in bytes) from the Max Sust. Traffic Rate token bucket o packet.size(). Returns size of packet A.2. DOCSIS-PIE AQM Control Path The DOCSIS-PIE control path performs the following: o Calls control_path_init() at service flow creation o Calls calculate_drop_prob() at a regular INTERVAL (16ms) ================ // Initialization function control_path_init() { drop_prob_ = 0; qdelay_old_ = 0; burst_reset_ = 0; White & Pan Expires August 15, 2016 [Page 11] Internet-Draft docsis-pie February 2016 aqm_state_ = INACTIVE; } // Background update, occurs every INTERVAL calculate_drop_prob() { if (queue_.byte_length() <= msrtokens()) { qdelay = queue_.byte_length() / PEAK_RATE; } else { qdelay = ((queue_.byte_length() - msrtokens()) / MSR \ + msrtokens() / PEAK_RATE); } if (burst_allowance_ > 0) { drop_prob_ = 0; burst_allowance_ = max(0, burst_allowance_ - INTERVAL); } else { p = A * (qdelay - LATENCY_TARGET) + \ B * (qdelay - qdelay_old_); // Since A=0.25 & B=2.5, can be implemented // with shift and add if (drop_prob_ < 0.000001) { p /= 2048; } else if (drop_prob_ < 0.00001) { p /= 512; } else if (drop_prob_ < 0.0001) { p /= 128; } else if (drop_prob_ < 0.001) { p /= 32; } else if (drop_prob_ < 0.01) { p /= 8; } else if (drop_prob_ < 0.1) { p /= 2; } else if (drop_prob_ < 1) { p /= 0.5; } else if (drop_prob_ < 10) { p /= 0.125; } else { p /= 0.03125; } if ((drop_prob_ >= 0.1) && (p > 0.02)) { p = 0.02; } drop_prob_ += p; /* some special cases */ White & Pan Expires August 15, 2016 [Page 12] Internet-Draft docsis-pie February 2016 if (qdelay < LATENCY_LOW && qdelay_old_ < LATENCY_LOW) { drop_prob_ *= 0.98; // exponential decay } else if (qdelay > LATENCY_HIGH) { drop_prob_ += 0.02; // ramp up quickly } drop_prob_ = max(0, drop_prob_); drop_prob_ = min(drop_prob_, \ PROB_LOW * MEAN_PKTSIZE/MIN_PKTSIZE); } // check if all is quiet quiet = (qdelay < 0.5 * LATENCY_TARGET) && (qdelay_old_ < 0.5 * LATENCY_TARGET) && (drop_prob_ == 0) && (burst_allowance_ == 0); // Update AQM state based on quiet or !quiet if ((aqm_state_ == ACTIVE) && quiet) { aqm_state_ = QUIESCENT; burst_reset_ = 0; } else if (aqm_state_ == QUIESCENT) { if (quiet) { burst_reset_ += INTERVAL ; if (burst_reset_ > BURST_RESET_TIMEOUT) { burst_reset_ = 0; aqm_state_ = INACTIVE; } } else { burst_reset_ = 0; } } qdelay_old_ = qdelay; } A.3. DOCSIS-PIE AQM Data Path The DOCSIS-PIE data path performs the following: o Calls enque() in response to an incoming packet from the CMCI ================ enque(packet) { if (queue_.is_full()) { drop(packet); accu_prob_ = 0; White & Pan Expires August 15, 2016 [Page 13] Internet-Draft docsis-pie February 2016 } else if (drop_early(packet, queue_.byte_length())) { drop(packet); } else { queue_.enque(packet); } } //////////////// drop_early(packet, queue_length) { // if still in burst protection, suppress AQM drops if (burst_allowance_ > 0) { return FALSE; } // if drop_prob_ goes to zero, clear accu_prob_ if (drop_prob_ == 0) { accu_prob_ = 0; } if (aqm_state_ == INACTIVE) { if (queue_.byte_length() < BUFFER_SIZE/3) { // if queue is still small, stay in // INACTIVE state and suppress AQM drops return FALSE; } else { // otherwise transition to QUIESCENT state aqm_state_ = QUIESCENT; } } //The CM can quantize packet.size to 64, 128, 256, 512, 768, // 1024, 1280, 1536, 2048 in the calculation below p1 = drop_prob_ * packet.size() / MEAN_PKTSIZE; p1 = min(p1, PROB_LOW); accu_prob_ += p1; // Suppress AQM drops in certain situations if ( (qdelay_old_ < 0.5 * LATENCY_TARGET && drop_prob_ < 0.2) || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { return FALSE; } if (accu_prob_ < PROB_LOW) { // avoid dropping too fast due return FALSE; // to bad luck of coin tosses... } else if (accu_prob_ >= PROB_HIGH) { // ...and avoid droppping drop = TRUE; // too slowly White & Pan Expires August 15, 2016 [Page 14] Internet-Draft docsis-pie February 2016 } else { //Random drop double u = random(); // 0 ~ 1 if (u > p1) return FALSE; else drop = TRUE; } // at this point, drop == TRUE, so packet will be dropped. // reset accu_prob_ accu_prob_ = 0; // If in QUIESCENT state, packet drop triggers // ACTIVE state and start of burst protection if (aqm_state_ == QUIESCENT) { aqm_state_ = ACTIVE; burst_allowance_ = MAX_BURST; } return TRUE; } Authors' Addresses Greg White CableLabs 858 Coal Creek Circle Louisville, CO 80027-9750 USA Email: g.white@cablelabs.com Rong Pan Cisco Systems 510 McCarthy Blvd Milpitas, CA 95134 USA Email: ropan@cisco.com White & Pan Expires August 15, 2016 [Page 15] ./draft-ietf-lisp-introduction-13.txt0000664000764400076440000020266012507232506017054 0ustar iustyiusty Network Working Group A. Cabellos Internet-Draft UPC-BarcelonaTech Intended status: Informational D. Saucez (Ed.) Expires: October 4, 2015 INRIA April 02, 2015 An Architectural Introduction to the Locator/ID Separation Protocol (LISP) draft-ietf-lisp-introduction-13.txt Abstract This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 4, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 1] Internet-Draft LISP Introduction April 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 3.2. Overview of the Architecture . . . . . . . . . . . . . . 5 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. A Brief History of Location/Identity Separation . . 25 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction This document introduces the Locator/ID Separation Protocol (LISP) [RFC6830] architecture, its main operational mechanisms and its design rationale. Fundamentally, LISP is built following a well- known architectural idea: decoupling the IP address overloaded semantics. Indeed and as pointed out by Noel Chiappa [RFC4984], Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 2] Internet-Draft LISP Introduction April 2015 currently IP addresses both identify the topological location of a network attachment point as well as the node's identity. However, nodes and routing have fundamentally different requirements, routing systems require that addresses are aggregatable and have topological meaning, while nodes require to be identified independently of their current location [RFC4984]. LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are syntactically identical to the current IPv4 and IPv6 addresses. EIDs are used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. RLOCs are assigned topologically to network attachment points and are typically routed inter-domain. With LISP, the edge of the Internet (where the nodes are connected) and the core (where inter-domain routing occurs) can be logically separated and interconnected by LISP-capable routers. LISP also introduces a database, called the Mapping System, to store and retrieve mappings between identity and location. LISP-capable routers exchange packets over the Internet core by encapsulating them to the appropriate location. In summary: o RLOCs have meaning only in the underlay network, that is the underlying core routing system. o EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers. o The LISP edge maps EIDs to RLOCs o Within the underlay network, RLOCs have both locator and identifier semantics o An EID within a LISP site carries both identifier and locator semantics to other nodes within that site o An EID within a LISP site carries identifier and limited locator semantics to nodes at other LISP sites (i.e., enough locator information to tell that the EID is external to the site) The relationship described above is not unique to LISP but it is common to other overlay technologies. The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP were to be completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System. In Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 3] Internet-Draft LISP Introduction April 2015 such scenario RLOCs are quasi-static (i.e., low churn), hence making the routing system scalable [Quoitin], while EIDs can roam anywhere with no churn to the underlying routing system. [RFC7215] discusses the impact of LISP on the global routing system during the transition period. However, the separation between location and identity that LISP offers makes it suitable for use in additional scenarios such as Traffic Engineering (TE), multihoming, and mobility among others. This document describes the LISP architecture and its main operational mechanisms as well as its design rationale. It is important to note that this document does not specify or complement the LISP protocol. The interested reader should refer to the main LISP specifications [RFC6830] and the complementary documents [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the protocol specifications along with the LISP deployment guidelines [RFC7215]. 2. Definition of Terms Endpoint IDentifier (EID): EIDs are addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. Routing LOcator (RLOC): RLOCs are addresses assigned topologically to network attachment points and typically routed inter-domain. Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates packets from a LISP site towards the core network. Egress Tunnel Router (ETR): A LISP-capable router that decapsulates packets from the core of the network towards a LISP site. xTR: A router that implements both ITR and ETR functionalities. Map-Request: A LISP signaling message used to request an EID-to-RLOC mapping. Map-Reply: A LISP signaling message sent in response to a Map- Request that contains a resolved EID-to-RLOC mapping. Map-Register: A LISP signaling message used to register an EID-to- RLOC mapping. Map-Notify: A LISP signaling message sent in response of a Map- Register to acknowledge the correct reception of an EID-to-RLOC mapping. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 4] Internet-Draft LISP Introduction April 2015 This document describes the LISP architecture and does not introduce any new term. The reader is referred to [RFC6830], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052], [RFC7215] for the complete definition of terms. 3. LISP Architecture This section presents the LISP architecture, it first details the design principles of LISP and then it proceeds to describe its main aspects: data-plane, control-plane, and internetworking mechanisms. 3.1. Design Principles The LISP architecture is built on top of four basic design principles: o Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale. Devices are assigned with relatively opaque topologically meaningful addresses that are independent of their topological location. o Overlay architecture: Overlays route packets over the current Internet, allowing deployment of new protocols without changing the current infrastructure hence, resulting into a low deployment cost. o Decoupled data and control-plane: Separating the data-plane from the control-plane allows them to scale independently and use different architectural approaches. This is important given that they typically have different requirements and allows for other data-planes to be added. While decoupled, data and control-plane are not completely isolated because the LISP data-plane may trigger control-plane activity. o Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters. 3.2. Overview of the Architecture LISP splits architecturally the core from the edge of the Internet by creating two separate namespaces: Endpoint Identifiers (EIDs) and Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6 addresses that uniquely identify communication end-hosts and are assigned and configured by the same mechanisms that exist at the time Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 5] Internet-Draft LISP Introduction April 2015 of this writing. EIDs do not contain inter-domain topological information and because of this, EIDs are usually routable at the edge (within LISP sites) or in the non-LISP Internet; see Section 3.5 for discussion of LISP site internetworking with non-LISP sites and domains in the Internet. LISP sites (at the edge of the Internet) are connected to the core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the core of the Internet using tunnels between the LISP-capable routers. When packets originated from a LISP site are flowing towards the core network, they ingress into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When packets flow from the core network to a LISP site, they egress from an encapsulated tunnel to an Egress Tunnel Router (ETR). An xTR is a router which can perform both ITR and ETR operations. In this context ITRs encapsulate packets while ETRs decapsulate them, hence LISP operates as an overlay on top of the current Internet core. /-----------------\ --- | Mapping | | . System | | Control -| |`, | Plane ,' \-----------------/ . | / | --- ,.., - _,....,, | ,.., | / ` ,' ,-` `', | / ` | / \ +-----+ ,' `, +-----+ / \ | | EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data | Space |-| |--| Space |--| |-| Space | | Plane \ / +-----+ . / +-----+ \ / | `. .' `. ,' `. .' | `'-` `., ,.' `'-` --- ``'''`` LISP Site (Edge) Core LISP Site (Edge) Figure 1.- A schema of the LISP Architecture With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6 address assigned to an Internet-facing network interface of an ITR or ETR. Typically RLOCs are numbered from topologically aggregatable blocks assigned to a site at each point to which it attaches to the global Internet, the topology is defined by the connectivity of networks. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 6] Internet-Draft LISP Introduction April 2015 A database which is typically distributed, called the Mapping System, stores mappings between EIDs and RLOCs. Such mappings relate the identity of the devices attached to LISP sites (EIDs) to the set of RLOCs configured at the LISP-capable routers servicing the site. Furthermore, the mappings also include traffic engineering policies and can be configured to achieve multihoming and load balancing. The LISP Mapping System is conceptually similar to the DNS where it is organized as a distributed multi-organization network database. With LISP, ETRs register mappings while ITRs retrieve them. Finally, the LISP architecture emphasizes incremental deployment. Given that LISP represents an overlay to the current Internet architecture, endhosts as well as intra and inter-domain routers remain unchanged, and the only required changes to the existing infrastructure are to routers connecting the EID with the RLOC space. Additionally, LISP requires the deployment of an independent Mapping System, such distributed database is a new network entity. The following describes a simplified packet flow sequence between two nodes that are attached to LISP sites. Please note that typical LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants to send a packet to server HostB. /----------------\ | Mapping | | System | .| |- ` \----------------/ `. ,` \ / `. ,' _,..-..,, ', / -` `-, \ .' ,' \ `, ` ' \ ' +-----+ | | RLOC_B1+-----+ HostA | | | RLOC |-------| | HostB EID_A--|ITR_A|----| Space | |ETR_B|--EID_B | | RLOC_A1 |-------| | +-----+ | | RLOC_B2+-----+ , / \ / `', ,-` ``''-''`` Figure 2.- Packet flow sequence in LISP Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 7] Internet-Draft LISP Introduction April 2015 1. HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining an A or AAAA record. Then it generates an IP packet as in the Internet, the packet has source address EID_A and destination address EID_B. 2. The packet is routed towards ITR_A in the LISP site using standard intra-domain mechanisms. 3. ITR_A upon receiving the packet queries the Mapping System to retrieve the locator of ETR_B that is servicing HostB's EID_B. In order to do so it uses a LISP control message called Map- Request, the message contains EID_B as the lookup key. In turn it receives another LISP control message called Map-Reply, the message contains two locators: RLOC_B1 and RLOC_B2 along with traffic engineering policies: priority and weight per locator. Note that a Map-Reply can contain more locators if needed. ITR_A also stores the mapping in a local cache to speed-up forwarding of subsequent packets. 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according to the priorities/weights specified in the mapping). The packet contains two IP headers, the outer header has RLOC_A1 as source and RLOC_B1 as destination, the inner original header has EID_A as source and EID_B as destination. Furthermore ITR_A adds a LISP header, more details about LISP encapsulation can be found in Section 3.3.1. 5. The encapsulated packet is forwarded by the Internet core as a normal IP packet, making the EID invisible from the Internet core. 6. Upon reception of the encapsulated packet by ETR_B, it decapsulates the packet and forwards it to HostB. 3.3. Data-Plane This section provides a high-level description of the LISP data- plane, which is specified in detail in [RFC6830]. The LISP data- plane is responsible for encapsulating and decapsulating data packets and caching the appropriate forwarding state. It includes two main entities, the ITR and the ETR, both are LISP capable routers that connect the EID with the RLOC space (ITR) and vice versa (ETR). 3.3.1. LISP Encapsulation ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 8] Internet-Draft LISP Introduction April 2015 be consistent in case of multi-path solutions such as ECMP [RFC2992]) and ignored on reception. LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936] that is not verified when it is received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum. By omitting the additional outer UDP encapsulation checksum, xTRs can forward packets more efficiently. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums are verified when the UDP packets are received, as part of normal UDP processing. LISP-encapsulated packets also include a LISP header (after the UDP header and before the original IP header). The LISP header is prepended by ITRs and striped by ETRs. It carries reachability information (see more details in Section 4.2) and the Instance ID field. The Instance ID field is used to distinguish traffic to/from different tenant address spaces at the LISP site and that may use overlapped but logically separated EID addressing. Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends ("outer" to "inner"): 1. Outer IP header containing RLOCs as source and destination addresses. This header is originated by ITRs and stripped by ETRs. 2. UDP header (port 4341) with zero checksum. This header is originated by ITRs and stripped by ETRs. 3. LISP header that contains various forwarding-plane features (such as reachability) and an Instance ID field. This header is originated by ITRs and stripped by ETRs. 4. Inner IP header containing EIDs as source and destination addresses. This header is created by the source end-host and is left unchanged by LISP data plane processing on the ITR and ETR. Finally, in some scenarios Re-encapsulating and/or Recursive tunnels are useful to choose a specified path in the underlay network, for instance to avoid congestion or failure. Re-encapsulating tunnels are consecutive LISP tunnels and occur when a decapsulator (an ETR action) removes a LISP header and then acts as an encapsultor (an ITR action) to prepend another one. On the other hand, Recursive tunnels are nested tunnels and are implemented by using multiple LISP encapsulations on a packet. Such functions are implemented by Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of as a router that first acts as an ETR by decapsulating packets and then as Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 9] Internet-Draft LISP Introduction April 2015 an ITR by encapsulating them towards another locator, more information can be found at [RFC6830]. 3.3.2. LISP Forwarding State In the LISP architecture, ITRs keep just enough information to route traffic flowing through them. Meaning that, ITRs retrieve from the LISP Mapping System mappings between EID-prefixes (blocks of EIDs) and RLOCs that are used to encapsulate packets. Such mappings are stored in a local cache called the Map-Cache for subsequent packets addressed to the same EID prefix. Note that, in case of overlapping EID-prefixes, following a single request, the ITR may receive a set of mappings, covering the requested EID-prefix and all more-specifics (cf., Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live) TTL (set by the ETR). More details about the Map-Cache management can be found in Section 4.1. 3.4. Control-Plane The LISP control-plane, specified in [RFC6833], provides a standard interface to register and request mappings. The LISP Mapping System is a database that stores such mappings. The following first describes the mappings, then the standard interface to the Mapping System, and finally its architecture. 3.4.1. LISP Mappings Each mapping includes the bindings between EID prefix(es) and set of RLOCs as well as traffic engineering policies, in the form of priorities and weights for the RLOCs. Priorities allow the ETR to configure active/backup policies while weights are used to load- balance traffic among the RLOCs (on a per-flow basis). Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) [RFC3232]. However LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. With such a general syntax for address encoding in place, LISP aims to provide flexibility to current and future applications. For instance LCAFs could support MAC addresses, geo-coordinates, ASCII names and application specific data. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 10] Internet-Draft LISP Introduction April 2015 3.4.2. Mapping System Interface LISP defines a standard interface between data and control planes. The interface is specified in [RFC6833] and defines two entities: Map-Server: A network infrastructure component that learns mappings from ETRs and publishes them into the LISP Mapping System. Typically Map-Servers are not authoritative to reply to queries and hence, they forward them to the ETR. However they can also operate in proxy-mode, where the ETRs delegate replying to queries to Map-Servers. This setup is useful when the ETR has limited resources (i.e., CPU or power). Map-Resolver: A network infrastructure component that interfaces ITRs with the Mapping System by proxying queries and in some cases responses. The interface defines four LISP control messages which are sent as UDP datagrams (port 4342): Map-Register: This message is used by ETRs to register mappings in the Mapping System and it is authenticated using a shared key between the ETR and the Map-Server. Map-Notify: When requested by the ETR, this message is sent by the Map-Server in response to a Map-Register to acknowledge the correct reception of the mapping and convey the latest Map-Server state on the EID to RLOC mapping. In some cases a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs. Map-Request: This message is used by ITRs or Map-Resolvers to resolve the mapping of a given EID. Map-Reply: This message is sent by Map-Servers or ETRs in response to a Map-Request and contains the resolved mapping. Please note that a Map-Reply may contain a negative reply if, for example, the queried EID is not part of the LISP EID space. In such cases the ITR typically forwards the traffic natively (non encapsulated) to the public Internet, this behavior is defined to support incremental deployment of LISP. 3.4.3. Mapping System LISP architecturally decouples control and data-plane by means of a standard interface. This interface glues the data-plane, routers responsible for forwarding data-packets, with the LISP Mapping System, a database responsible for storing mappings. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 11] Internet-Draft LISP Introduction April 2015 With this separation in place the data and control-plane can use different architectures if needed and scale independently. Typically the data-plane is optimized to route packets according to hierarchical IP addresses. However the control-plane may have different requirements, for instance and by taking advantage of the LCAFs, the Mapping System may be used to store non-hierarchical keys (such as MAC addresses), requiring different architectural approaches for scalability. Another important difference between the LISP control and data-planes is that, and as a result of the local mapping cache available at ITR, the Mapping System does not need to operate at line-rate. Many of the existing mechanisms to create distributed systems have been explored and considered for the Mapping System architecture: graph-based databases in the form of LISP+ALT [RFC6836], hierarchical databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in the form of LISP-NERD [RFC6837], flat databases in the form of LISP-DHT [I-D.cheng-lisp-shdht],[Mathy] and, a multicast- based database [I-D.curran-lisp-emacs]. Furthermore it is worth noting that, in some scenarios such as private deployments, the Mapping System can operate as logically centralized. In such cases it is typically composed of a single Map-Server/Map-Resolver. The following focuses on the two mapping systems that have been implemented and deployed (LISP-ALT and LISP+DDT). 3.4.3.1. LISP+ALT The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first Mapping System proposed, developed and deployed on the LISP pilot network. It is based on a distributed BGP overlay participated by Map-Servers and Map-Resolvers. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-prefixes registered by the serviced ETRs, making the EID routable on the ALT topology. When an ITR needs a mapping it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible for the mapping. Upon reception the Map- Server forwards the request to the ETR that in turn, replies directly to the ITR using the native Internet core. 3.4.3.2. LISP-DDT LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a hierarchical directory whose internal structure mirrors the hierarchical nature of the EID address space. The DDT hierarchy is composed of DDT nodes forming a tree structure, the leafs of the tree Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 12] Internet-Draft LISP Introduction April 2015 are Map-Servers. On top of the structure there is the DDT root node [DDT-ROOT], which is a particular instance of a DDT node and that matches the entire address space. As in the case of DNS, DDT supports multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers are the clients of the DDT hierarchy and can query either the DDT root and/or other DDT nodes. /---------\ | | | DDT Root| | /0 | ,.\---------/-, ,-'` | `'., -'` | `- /-------\ /-------\ /-------\ | DDT | | DDT | | DDT | | Node | | Node | | Note | ... | 0/8 | | 1/8 | | 2/8 | \-------/ \-------/ \-------/ _. _. . -..,,,_ -` -` \ ````''-- +------------+ +------------+ +------------+ +------------+ | Map-Server | | Map-Server | | Map-Server | | Map-Server | | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| +------------+ +------------+ +------------+ +------------+ Figure 3.- A schematic representation of the DDT tree structure, please note that the prefixes and the structure depicted should be only considered as an example. The DDT structure does not actually index EID-prefixes but eXtended EID-prefixes (XEID). An XEID-prefix is just the concatenation of the following fields (from most significant bit to less significant bit): Database-ID, Instance ID, Address Family Identifier and the actual EID-prefix. The Database-ID is provided for possible future requirements of higher levels in the hierarchy and to enable the creation of multiple and separate database trees. In order to resolve a query LISP-DDT operates in a similar way to the DNS but only supports iterative lookups. DDT clients (usually Map- Resolvers) generate Map-Requests to the DDT root node. In response they receive a newly introduced LISP-control message: a Map-Referral. A Map-Referral provides the list of RLOCs of the set of DDT nodes matching a configured XEID delegation. That is, the information contained in the Map-Referral points to the child of the queried DDT node that has more specific information about the queried XEID- prefix. This process is repeated until the DDT client walks the tree Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 13] Internet-Draft LISP Introduction April 2015 structure (downwards) and discovers the Map-Server servicing the queried XEID. At this point the client sends a Map-Request and receives a Map-Reply containing the mappings. It is important to note that DDT clients can also cache the information contained in Map-Referrals, that is, they cache the DDT structure. This is used to reduce the mapping retrieving latency[Jakab]. The DDT Mapping System relies on manual configuration. That is Map- Resolvers are manually configured with the set of available DDT root nodes while DDT nodes are manually configured with the appropriate XEID delegations. Configuration changes in the DDT nodes are only required when the tree structure changes itself, but it doesn't depend on EID dynamics (RLOC allocation or traffic engineering policy changes). 3.5. Internetworking Mechanisms EIDs are typically identical to either IPv4 or IPv6 addresses and they are stored in the LISP Mapping System, however they are usually not announced in the Internet global routing system. As a result LISP requires an internetworking mechanism to allow LISP sites to speak with non-LISP sites and vice versa. LISP internetworking mechanisms are specified in [RFC6832]. LISP defines two entities to provide internetworking: Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from the legacy Internet to LISP sites. PITRs announce in the global routing system blocks of EID prefixes (aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID), the PITR LISP-encapsulates it towards the RLOC(s) of the appropriate LISP site. The impact of PITRs in the routing table size of the Default-Free Zone (DFZ) is, in the worst-case, similar to the case in which LISP is not deployed. EID-prefixes will be aggregated as much as possible both by the PITR and by the global routing system. Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulated packets with a local EID address as a source to the legacy Internet. For instance when Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge routers, or when an intermediate network between a LISP site and a non-LISP site does not support the desired version of IP (IPv4 or IPv6). In both cases the PETR overcomes such limitations by encapsulating packets over the network. There is no specified provision for the distribution of PETR RLOC addresses to the ITRs. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 14] Internet-Draft LISP Introduction April 2015 Additionally, LISP also defines mechanisms to operate with private EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case the xTR replaces a private EID source address with a routable one. At the time of this writing, work is ongoing to define NAT-traversal capabilities, that is xTRs behind a NAT using non-routable RLOCs. PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, by providing significant flexibility in the placement of the boundaries between the LISP and non-LISP portions of the network, and making it easy to change those boundaries over time. 4. LISP Operational Mechanisms This section details the main operational mechanisms defined in LISP. 4.1. Cache Management LISP's decoupled control and data-plane, where mappings are stored in the control-plane and used for forwarding in the data plane, requires a local cache in ITRs to reduce signaling overhead (Map-Request/Map- Reply) and increase forwarding speed. The local cache available at the ITRs, called Map-Cache, is used by the router to LISP-encapsulate packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and contains basically the set of RLOCs with the associated traffic engineering policies (priorities and weights). The Map-Cache, as any other cache, requires cache coherence mechanisms to maintain up-to-date information. LISP defines three main mechanisms for cache coherence: Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR can't use the mapping until it is refreshed by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. Solicit-Map-Request (SMR): SMR is an explicit mechanism to update mapping information. In particular a special type of Map-Request can be sent on demand by ETRs to request refreshing a mapping. Upon reception of a SMR message, the ITR must refresh the bindings by sending a Map-Request to the Mapping System. Further uses of SMRs are documented in [RFC6830]. Map-Versioning: This optional mechanism piggybacks in the LISP header of data-packets the version number of the mappings used by an xTR. This way, when an xTR receives a LISP-encapsulated packet from a remote xTR, it can check whether its own Map-Cache or the one of the remote xTR is outdated. If its Map-Cache is outdated, it sends a Map-Request for the remote EID so to obtain the newest Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 15] Internet-Draft LISP Introduction April 2015 mappings. On the contrary, if it detects that the remote xTR Map- Cache is outdated, it sends a SMR to notify it that a new mapping is available. Finally it is worth noting that in some cases an entry in the map- cache can be proactively refreshed using the mechanisms described in the section below. 4.2. RLOC Reachability In most cases LISP operates with a pull-based Mapping System (e.g., DDT), this results in an edge to edge pull architecture. In such scenario the network state is stored in the control-plane while the data-plane pulls it on demand. This has consequences concerning the propagation of xTRs reachability/liveness information since pull architectures require explicit mechanisms to propagate this information. As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs: Locator Status Bits (LSB): LSB is a passive technique, the LSB field is carried by data-packets in the LISP header and can be set by a ETRs to specify which RLOCs of the ETR site are up/down. This information can be used by the ITRs as a hint about the reachability to perform additional checks. Also note that LSB does not provide path reachability status, only hints on the status of RLOCs. Echo-nonce: This is also a passive technique, that can only operate effectively when data flows bi-directionally between two communicating xTRs. Basically, an ITR piggybacks a random number (called nonce) in LISP data packets, if the path and the probed locator are up, the ETR will piggyback the same random number on the next data-packet, if this is not the case the ITR can set the locator as unreachable. When traffic flow is unidirectional or when the ETR receiving the traffic is not the same as the ITR that transmits it back, additional mechanisms are required. RLOC-probing: This is an active probing algorithm where ITRs send probes to specific locators, this effectively probes both the locator and the path. In particular this is done by sending a Map-Request (with certain flags activated) on the data-plane (RLOC space) and waiting in return a Map-Reply, also sent on the data-plane. The active nature of RLOC-probing provides an effective mechanism to determine reachability and, in case of failure, switching to a different locator. Furthermore the mechanism also provides useful RTT estimates of the delay of the path that can be used by other network algorithms. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 16] Internet-Draft LISP Introduction April 2015 It is worth noting that RLOC probing and Echo-nonce can work together. Specifically if a nonce is not echoed, an ITR could RLOC- probe to determine if the path is up when it cannot tell the difference between a failed bidirectional path or the return path is not used (a unidirectional path). Additionally, LISP also recommends inferring reachability of locators by using information provided by the underlay, in particular: ICMP signaling: The LISP underlay -the current Internet- uses the ICMP protocol to signal unreachability (among other things). LISP can take advantage of this and the reception of a ICMP Network Unreachable or ICMP Host Unreachable message can be seen as a hint that a locator might be unreachable, this should lead to perform additional checks. Underlay routing: Both BGP and IBGP carry reachability information, LISP-capable routers that have access to underlay routing information can use it to determine if a given locator or path are reachable. 4.3. ETR Synchronization All the ETRs that are authoritative to a particular EID-prefix must announce the same mapping to the requesters, this means that ETRs must be aware of the status of the RLOCs of the remaining ETRs. This is known as ETR synchronization. At the time of this writing LISP does not specify a mechanism to achieve ETR synchronization. Although many well-known techniques could be applied to solve this issue it is still under research, as a result operators must rely on coherent manual configuration 4.4. MTU Handling Since LISP encapsulates packets it requires dealing with packets that exceed the MTU of the path between the ITR and the ETR. Specifically LISP defines two mechanisms: Stateless: With this mechanism the effective MTU is assumed from the ITR's perspective. If a payload packet is too big for the effective MTU, and can be fragmented, the payload packet is fragmented on the ITR, such that reassembly is performed at the destination host. Stateful: With this mechanism ITRs keep track of the MTU of the paths towards the destination locators by parsing the ICMP Too Big packets sent by intermediate routers. ITRs will send ICMP Too Big messages to inform the sources about the effective MTU. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 17] Internet-Draft LISP Introduction April 2015 Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or PLPMTUD [RFC4821] to keep track of the MTU towards the locators. In both cases if the packet cannot be fragmented (IPv4 with DF=1 or IPv6) then the ITR drops it and replies with a ICMP Too Big message to the source. 5. Mobility The separation between locators and identifiers in LISP is suitable for traffic engineering purpose where LISP sites can change their attachment points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. In this context, the border routers operate the xTR functionality and endpoints are not aware of the existence of LISP. This functionality is similar to Network Mobility [RFC3963]. However, this mode of operation does not allow seamless mobility of endpoints between different LISP sites as the EID address might not be routable in a visited site. Nevertheless, LISP can be used to enable seamless IP mobility when LISP is directly implemented in the endpoint or when the endpoint roams to an attached xTR. Each endpoint is then an xTR and the EID address is the one presented to the network stack used by applications while the RLOC is the address gathered from the network when it is visited. This functionality is similar to Mobile IP ([RFC5944] and [RFC6275]). Whenever the device changes of RLOC, the xTR updates the RLOC of its local mapping and registers it to its Map-Server, typically with a low TTL value (1min). To avoid the need of a home gateway, the ITR also indicates the RLOC change to all remote devices that have ongoing communications with the device that moved. The combination of both methods ensures the scalability of the system as signaling is strictly limited the Map-Server and to hosts with which communications are ongoing. In the mobility case the EID-prefix can be as small as a full /32 or /128 (IPv4 or IPv6 respectively) depending on the specific use-case (e.g., subnet mobility vs single VM/Mobile node mobility). The decoupled identity and location provided by LISP allows it to operate with other layer 2 and layer 3 mobility solutions. 6. Multicast LISP also supports transporting IP multicast packets sent from the EID space, the operational changes required to the multicast protocols are documented in [RFC6831]. In such scenarios, LISP may create multicast state both at the core and at the sites (both source and receiver). When signaling is used Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 18] Internet-Draft LISP Introduction April 2015 to create multicast state at the sites, LISP routers unicast encapsulate PIM Join/Prune messages from receiver to source sites. At the core, ETRs build a new PIM Join/Prune message addressed to the RLOC of the ITR servicing the source. An simplified sequence is shown below 1. An end-host willing to join a multicast channel sends an IGMP report. Multicast PIM routers at the LISP site propagate PIM Join/Prune messages (S-EID, G) towards the ETR. 2. The join message flows to the ETR, upon reception the ETR builds two join messages, the first one unicast LISP-encapsulates the original join message towards the RLOC of the ITR servicing the source. This message creates (S-EID, G) multicast state at the source site. The second join message contains as destination address the RLOC of the ITR servicing the source (S-RLOC, G) and creates multicast state at the core. 3. Multicast data packets originated by the source (S-EID, G) flow from the source to the ITR. The ITR LISP-encapsulates the multicast packets, the outter header includes its own RLOC as the source (S-RLOC) and the original multicast group address (G) as the destination. Please note that multicast group address are logical and are not resolved by the mapping system. Then the multicast packet is transmitted through the core towards the receiving ETRs that decapsulates the packets and sends them using the receiver's site multicast state. Please note that the inner and outer multicast addresses are in general different, unless in specific cases where the underlay provider implements a tight control on the overlay. LISP specifications already support all PIM modes [RFC6831]. Additionally, LISP can support as well non-PIM mechanisms in order to maintain multicast state. 7. Use Cases 7.1. Traffic Engineering A LISP site can strictly impose via which ETRs the traffic must enter the the LISP site network even though the path followed to reach the ETR is not under the control of the LISP site. This fine control is implemented with the mappings. When a remote site is willing to send traffic to a LISP site, it retrieves the mapping associated to the destination EID via the mapping system. The mapping is sent directly by an authoritative ETR of the EID and is not altered by any intermediate network. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 19] Internet-Draft LISP Introduction April 2015 A mapping associates a list of RLOCs to an EID prefix. Each RLOC corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward packets to EIDs in the prefix. Each RLOC is tagged with a priority and a weight in the mapping. The priority is used to indicates which RLOCs should be preferred to send packets (the least preferred ones being provided for backup purpose). The weight permits to balance the load between the RLOCs with the same priority, proportionally to the weight value. As mappings are directly issued by the authoritative ETR of the EID and are not altered while transmitted to the remote site, it offers highly flexible incoming inter-domain traffic engineering with even the possibility for a site to support a different mapping policy for each remote site. routing policies. 7.2. LISP for IPv6 Co-existence LISP encapsulations allows to transport packets using EIDs from a given address family (e.g., IPv6) with packets from other address families (e.g., IPv4). The absence of correlation between the address family of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6 to be deployed when all of the core network may not have IPv6 enabled. For example, two IPv6-only data centers could be interconnected via the legacy IPv4 Internet. If their border routers are LISP capable, sending packets between the data center is done without any form of translation as the native IPv6 packets (in the EID space) will be LISP encapsulated and transmitted over the IPv4 legacy Internet by the mean of IPv4 RLOCs. 7.3. LISP for Virtual Private Networks It is common to operate several virtual networks over the same physical infrastructure. In such virtual private networks, it is essential to distinguish which virtual network a packet belongs and tags or labels are used for that purpose. When using LISP, the distinction can be made with the Instance ID field. When an ITR encapsulates a packet from a particular virtual network (e.g., known via the VRF or VLAN), it tags the encapsulated packet with the Instance ID corresponding to the virtual network of the packet. When an ETR receives a packet tagged with an Instance ID it uses the Instance ID to determine how to treat the packet. The main usage of LISP for virtual private networks does not introduce additional requirements on the underlying network, as long as it is running IP. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 20] Internet-Draft LISP Introduction April 2015 7.4. LISP for Virtual Machine Mobility in Data Centers A way to enable seamless virtual machine mobility in data center is to conceive the datacenter backbone as the RLOC space and the subnet where servers are hosted as forming the EID space. A LISP router is placed at the border between the backbone and each subnet. When a virtual machine is moved to another subnet, it can keep (temporarily) the address it had before the move so to continue without a transport layer connection reset. When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System. To inform the other LISP routers that the machine moved and where, and then to avoid detours via the initial subnetwork, mechanisms such as the Solicit-Map-Request messages are used. 8. Security Considerations This section describes the security considerations associated to the LISP protocol. While in a push mapping system, the state necessary to forward packets is learned independently of the traffic itself, with a pull architecture, the system becomes reactive and data-plane events (e.g., the arrival of a packet for an unknown destination) may trigger control-plane events. This on-demand learning of mappings provides many advantages as discussed above but may also affect the way security is enforced. Usually, the data-plane is implemented in the fast path of routers to provide high performance forwarding capabilities while the control- plane features are implemented in the slow path to offer high flexibility and a performance gap of several order of magnitude can be observed between the slow and the fast paths. As a consequence, the way data-plane events are notified to the control-plane must be thought carefully so to not overload the slow path and rate limiting should be used as specified in [RFC6830]. Care must also be taken so to not overload the mapping system (i.e., the control plane infrastructure) as the operations to be performed by the mapping system may be more complex than those on the data- plane, for that reason [RFC6830] recommends to rate limit the sending of messages to the mapping system. To improve resiliency and reduce the overall number of messages exchanged, LISP offers the possibility to leak information, such as reachabilty of locators, directly into data plane packets. In Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 21] Internet-Draft LISP Introduction April 2015 environments that are not fully trusted, control information gleaned from data-plane packets should be verified before using them. Mappings are the centrepiece of LISP and all precautions must be taken to avoid them to be manipulated or misused by malicious entities. Using trustable Map-Servers that strictly respect [RFC6833] and the lightweight authentication mechanism proposed by LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the mapping integrity. In more critical environments, secure measures may be needed. The way security is implemented for a given mapping system strongly depends on the architecture of the mapping system itself and the threat model assumed for the deployment. Thus, the mapping system security has to be discussed in the relevant documents proposing the mapping system architecture. As with any other tunneling mechanism, middleboxes on the path between an ITR (or PITR) and an ETR (or PETR) must implement mechanisms to strip the LISP encapsulation to correctly inspect the content of LISP encapsulated packets. Like other map-and-encap mechanisms, LISP enables triangular routing (i.e., packets of a flow cross different border routers depending on their direction). This means that intermediate boxes may have incomplete view on the traffic they inspect or manipulate. Moreover, LISP-encapsulated packets are routed based on the outer IP address (i.e., the RLOC), and can be delivered to an ETR that is not responsible of the destination EID of the packet or even to a network element that is not an ETR. The mitigation consists in applying appropriate filtering techniques on the network elements that can potentially receive un-expected LISP-encapsulated packets More details about security implications of LISP are discussed in [I-D.ietf-lisp-threats]. 9. IANA Considerations This memo includes no request to IANA. 10. Acknowledgements This document was initiated by Noel Chiappa and much of the core philosophy came from him. The authors acknowledge the important contributions he has made to this work and thank him for his past efforts. The authors would also like to thank Dino Farinacci, Fabio Maino, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 22] Internet-Draft LISP Introduction April 2015 Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black as well as every people acknowledged in [RFC6830]. 11. References 11.1. Normative References [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in progress), October 2014. [I-D.ietf-lisp-lcaf] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in progress), December 2014. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 (work in progress), October 2014. [I-D.ietf-lisp-threats] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", draft-ietf-lisp-threats-12 (work in progress), March 2015. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 23] Internet-Draft LISP Introduction April 2015 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, January 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013. [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, January 2013. [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 24] Internet-Draft LISP Introduction April 2015 [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, October 2013. [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, April 2014. 11.2. Informative References [DDT-ROOT] LISP DDT ROOT, , "http://ddt-root.org/", August 2013. [I-D.cheng-lisp-shdht] Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping Overlay", draft-cheng-lisp-shdht-04 (work in progress), July 2013. [I-D.curran-lisp-emacs] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00 (work in progress), November 2007. [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System, IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343", October 2010. [Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: Towards a DHT to map identifiers onto locators. The ACM ReArch, Re-Architecting the Internet. Madrid (Spain)", December 2008. [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, ""Evaluating the Benefits of the Locator/Identifier Separation" in Proceedings of 2Nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture", 2007. Appendix A. A Brief History of Location/Identity Separation The LISP architecture for separation of location and identity resulted from the discussions of this topic at the Amsterdam IAB Routing and Addressing Workshop, which took place in October 2006 [RFC4984]. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 25] Internet-Draft LISP Introduction April 2015 A small group of like-minded personnel spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop and on various mailing lists. The first Internet-Draft on LISP appeared in January, 2007. Trial implementations started at that time, with initial trial deployments underway since June 2007; the results of early experience have been fed back into the design in a continuous, ongoing process over several years. LISP at this point represents a moderately mature system, having undergone a long organic series of changes and updates. LISP transitioned from an IRTF activity to an IETF WG in March 2009, and after numerous revisions, the basic specifications moved to becoming RFCs at the start of 2013 (although work to expand and improve it, and find new uses for it, continues, and undoubtly will for a long time to come). A.1. Old LISP Models LISP, as initially conceived, had a number of potential operating modes, named 'models'. Although they are no used anymore, one occasionally sees mention of them, so they are briefly described here. LISP 1: EIDs all appear in the normal routing and forwarding tables of the network (i.e. they are 'routable');this property is used to 'bootstrap' operation, by using this to load EID->RLOC mappings. Packets were sent with the EID as the destination in the outer wrapper; when an ETR saw such a packet, it would send a Map-Reply to the source ITR, giving the full mapping. LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on a separate network. LISP 2: EIDs are not routable; EID->RLOC mappings are available from the DNS. LISP 3: EIDs are not routable; and have to be looked up in in a new EID->RLOC mapping database (in the initial concept, a system using Distributed Hash Tables). Two variants were possible: a 'push' system, in which all mappings were distributed to all ITRs, and a 'pull' system in which ITRs load the mappings they need, as needed. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 26] Internet-Draft LISP Introduction April 2015 Authors' Addresses Albert Cabellos UPC-BarcelonaTech c/ Jordi Girona 1-3 Barcelona, Catalonia 08034 Spain Email: acabello@ac.upc.edu Damien Saucez (Ed.) INRIA 2004 route des Lucioles BP 93 Sophia Antipolis Cedex 06902 France Email: damien.saucez@inria.fr Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 27] ./draft-ietf-aqm-ecn-benefits-08.txt0000664000764400076440000013770612625014066016520 0ustar iustyiusty Network Working Group G. Fairhurst Internet-Draft University of Aberdeen Intended status: Informational M. Welzl Expires: May 27, 2016 University of Oslo November 24, 2015 The Benefits of using Explicit Congestion Notification (ECN) draft-ietf-aqm-ecn-benefits-08 Abstract The goal of this document is to describe the potential benefits when applications use a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN, nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers or other network devices. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 27, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Fairhurst & Welzl Expires May 27, 2016 [Page 1] Internet-Draft Benefits of ECN November 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Benefit of using ECN to avoid Congestion Loss . . . . . . . . 5 2.1. Improved Throughput . . . . . . . . . . . . . . . . . . . 5 2.2. Reduced Head-of-Line Blocking . . . . . . . . . . . . . . 6 2.3. Reduced Probability of RTO Expiry . . . . . . . . . . . . 6 2.4. Applications that do not Retransmit Lost Packets . . . . 7 2.5. Making Incipient Congestion Visible . . . . . . . . . . . 8 2.6. Opportunities for new Transport Mechanisms . . . . . . . 8 3. Network Support for ECN . . . . . . . . . . . . . . . . . . . 9 3.1. The ECN Field . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Forwarding ECN-Capable IP Packets . . . . . . . . . . . . 10 3.3. Enabling ECN in Network Devices . . . . . . . . . . . . . 10 3.4. Co-existance of ECN and non-ECN flows . . . . . . . . . . 11 3.5. Bleaching and Middlebox Requirements to deploy ECN . . . 11 3.6. Tunneling ECN and the use of ECN by Lower Layer Networks 12 4. Using ECN across the Internet . . . . . . . . . . . . . . . . 12 4.1. Partial Deployment . . . . . . . . . . . . . . . . . . . 13 4.2. Detecting whether a Path Really Supports ECN . . . . . . 13 4.3. Detecting ECN Receiver Feedback Cheating . . . . . . . . 14 5. Summary: Enabling ECN in Network Devices and Hosts . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Revision Information . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Internet Transports (such as TCP and SCTP) are implemented in endpoints (Internet hosts) and are designed to detect and react to network congestion. Congestion may be detected by loss of an IP packet or, if Explicit Congestion Notification (ECN) [RFC3168] is enabled, by the reception of a packet with a Congestion Experienced (CE) marking in the IP header. Both of these are treated by transports as indications of congestion. ECN may also be enabled by Fairhurst & Welzl Expires May 27, 2016 [Page 2] Internet-Draft Benefits of ECN November 2015 other transports: UDP applications that provide congestion control may enable ECN when they are able to correctly process the ECN signals [ID.RFC5405.bis] (e.g., ECN with RTP [RFC6679]). Active Queue Management (AQM) [RFC7567] is a class of techniques that can be used by network devices (a router, middlebox, or other device that forwards packets through the network) to manage the size of queues in network buffers. A network device that does not support AQM typically uses a drop-tail policy to drop excess IP packets when its queue becomes full. The discard of packets is treated by transport protocols as a signal that indicates congestion on the end-to-end network path. End-to-end transports, such as TCP, can cause a low level of loss while seeking to share capacity with other flows. Although losses are not always due to congestion (loss may be due to link corruption, receiver- overrun, etc) end points have to conservatively presume that all loss is potentially due to congestion and reduce their rate. Observed loss therefore results in a congestion control reaction by the transport to reduce the maximum rate permitted by the sending endpoint. ECN makes it possible for the network to signal the presence of incipient congestion without incurring packet loss, it lets the network deliver some packets to an application that would otherwise have been dropped if the application or transport did not support ECN. This packet loss reduction is the most obvious benefit of ECN, but it is often relatively modest. However, enabling ECN can also result in a number of beneficial side-effects, some of which may be much more significant than the immediate packet loss reduction from receiving CE-marking instead of dropping packets. Several benefits reduce latency (e.g., reduced Head-of-Line Blocking). The use of ECN is indicated in the ECN field [RFC3168], carried in the packet header of all IPv4 and IPv6 packets. This field may be set to one of four values shown in Table 1. The not-ECT codepoint '00' indicates a packet that is not using ECN. The ECT(0) codepoint '01' and the ECT(1) codepoint '10' both indicate that the transport protocol using the IP layer supports the use of ECN. The CE codepoint '11' is set by an ECN-capable network device to indicate congestion to the transport endpoint. Fairhurst & Welzl Expires May 27, 2016 [Page 3] Internet-Draft Benefits of ECN November 2015 +-----+-----+---------+ | ECN FIELD | Name | +-----+-----+---------+ | 0 | 0 | Not-ECT | | 0 | 1 | ECT(1) | | 1 | 0 | ECT(0) | | 1 | 1 | CE | +-----+-----+---------+ Table 1: The ECN Field in the IP Packet Header (based on [RFC3168]). When an application uses a transport that enables use of ECN [RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in the IP header of packets that it sends. This indicates to network devices that they may mark, rather than drop the ECN-capable IP packets. An ECN-capable network device can then signal incipient congestion (network queueing) at a point before a transport experiences congestion loss or high queuing delay. The marking is generally performed as the result of various AQM algorithms [RFC7567], where the exact combination of AQM/ECN algorithms does not need to be known by the transport endpoints. The focus of the document is on usage of ECN by transport and application layer flows, not its implementation in endpoint hosts, or in routers and other network devices. 1.1. Terminology The following terms are used: AQM: Active Queue Management. CE: Congestion Experienced, a codepoint value '11' marked in the ECN field of the IP packet header. ECN-capable IP Packet : A packet where the ECN field is set to a non- zero ECN value (i.e., with a ECT(0), ECT(1), or the CE codepoint). ECN-capable network device : An ECN-capable network device may forward, drop, or queue an ECN-capable packet and may choose to CE- mark this packet when there is incipient congestion. ECN-capable transport/application : A transport that sends ECN- capable IP Packets, and monitors reception of the ECN field and generates appropriate feedback to control the rate of the sending endpoint. Fairhurst & Welzl Expires May 27, 2016 [Page 4] Internet-Draft Benefits of ECN November 2015 to provide end-to-end congestion control. ECN field: A 2-bit field specified for use explicit congestion signalling in the IPv4 and IPv6 packet headers. Endpoint: An Internet host that terminates a transport protocol connection across an Internet path. Incipient Congestion: The detection of congestion when it is starting, perhaps by a network device noting that the arrival rate exceeds the forwarding rate. Network device: A router, middlebox, or other device that forwards IP packets through the network. non-ECN-capable: A network device or endpoint that does not interpret the ECN field. Such a device is not permitted to change the ECN codepoint. not-ECN-capable IP Packet: An IP packet with the ECN field set to a value of zero ('00'). A not-ECN-capable packet may be forwarded, dropped or queued by a network device. 2. Benefit of using ECN to avoid Congestion Loss An ECN-capable network device is expected to CE-mark an ECN-capable IP packet when an AQM method detects incipient congestion, rather than to drop the packet [RFC7567]. An application can benefit from this marking in several ways: 2.1. Improved Throughput ECN seeks to avoid the inefficiency of dropping data that has already made it across at least part of the network path. ECN can improve the throughput of an application, although this increase in throughput is often not the most significant gain. When an application uses a light to moderately loaded network path, the number of packets that are dropped due to congestion is small. Using an example from Table 1 of [RFC3649], for a standard TCP sender with a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 bytes and an average throughput of 1 Mbps, the average packet drop ratio would be 0.02 (i.e., 1 in 50 packets). This translates into an approximate 2% throughput gain if ECN is enabled. (Note that in heavy congestion, packet loss may be unavoidable with, or without, ECN.) Fairhurst & Welzl Expires May 27, 2016 [Page 5] Internet-Draft Benefits of ECN November 2015 2.2. Reduced Head-of-Line Blocking Many Internet transports provide in-order delivery of received data segments to the applications they support. For these applications, use of ECN can reduce the delay that can result when these applications experience packet loss. Packet loss may occur for various reasons. One cause arises when an AQM scheme drops a packet as a signal of incipient congestion. Whatever the cause of loss, a missing packet needs to trigger a congestion control response. A reliable transport also triggers retransmission to recover the lost data. For a transport providing in-order delivery, this requires that the transport receiver stalls (or waits) for all data that was sent ahead of a lost segment to be correctly received before it can forward any later data to the application. A loss therefore creates a delay of at least one RTT after a loss event before data can be delivered to an application. We call this Head-of-Line (HOL) blocking. This is the usual requirement for TCP and SCTP. (PR-SCTP [RFC3758], UDP [RFC0768][ID.RFC5405.bis], and DCCP [RFC4340] provide a transport that does not provide re-ordering). By enabling ECN, a transport continues to receive in-order data when there is incipient congestion, and can pass this data to the receiving application. Use of ECN avoids the additional reordering delay in a reliable transport. The sender still needs to make an appropriate congestion-response to reduce the maximum transmission rate for future traffic, which usually will require a reduction in the sending rate [ID.RFC5405.bis].) 2.3. Reduced Probability of RTO Expiry Some patterns of packet loss can result in a Retransmission Time Out (RTO), which causes a sudden and significant change in the allowed rate at which a transport/application can forward packets. Because ECN provides an alternative to drop for network devices to signal incipient congestion, this can reduce the probability of loss and hence reduce the likelihood of RTO expiry. Internet transports/applications generally use a RTO timer as a last resort to detect and recover loss [ID.RFC5405.bis] [RFC5681]). Specifically, a RTO timer detects loss of a packet that is not followed by other packets, such as at the end of a burst of data segments or when an application becomes idle (either because the application has no further data to send or the network prevents sending further data, e.g., flow or congestion control at the transport layer). This loss of the last segment (or last few segments) of a traffic burst is also known as a "tail loss". Fairhurst & Welzl Expires May 27, 2016 [Page 6] Internet-Draft Benefits of ECN November 2015 Standard transport recovery methods, such as Fast Recovery ( [RFC5681], are often unable to recover from a tail loss. This is because the endpoint receiver is unaware that the lost segments were actually sent, and therefore generates no feedback [Fla13]. Retransmission of these segments therefore relies on expiry of a transport retransmission timer. This timer is also used to detect a lack of forwarding along a path. Expiry of the RTO therefore results in the consequent loss of state about the network path being used. This typically includes resetting path estimates such as the RTT, re- initialising the congestion window, and possibly updates to other transport state. This can reduce the performance of the transport until it again adapts to the path. An ECN-capable network device cannot eliminate the possibility of tail loss, because a drop may occur due to a traffic burst exceeding the instantaneous available capacity of a network buffer or as a result of the AQM algorithm (overload protection mechanisms, etc [RFC7567]). However, an ECN-capable network device that observes incipient congestion may be expected to buffer the IP packets of an ECN-capable flow and set a CE-mark in one or more packet(s), rather than triggering packet drop. Setting a CE-mark signals incipient congestion without forcing the transport/application to enter retransmission timeout. This reduces application-level latency and can improve the throughput for applications that send intermittent bursts of data. The benefit of avoiding retransmission loss is expected to be significant when ECN is used on TCP SYN/ACK packets [RFC5562] where the RTO interval may be large because TCP cannot base the timeout period on prior RTT measurements from the same connection. 2.4. Applications that do not Retransmit Lost Packets A transport that enables ECN can receive timely congestion signals without the need to retransmit packets each time it receives a congestion signal. Some latency-critical applications do not retransmit lost packets, yet may be able to adjust their sending rate following detection of incipient congestion. Examples of such applications include UDP- based services that carry Voice over IP (VoIP), interactive video, or real-time data. The performance of many such applications degrades rapidly with increasing packet loss and the transport/application may therefore employ mechanisms (e.g., packet forward error correction, data duplication, or media codec error concealment) to mitigate the immediate effect of congestion loss on the application. Some mechanisms consume additional network capacity, some require additional processing and some contribute additional path latency Fairhurst & Welzl Expires May 27, 2016 [Page 7] Internet-Draft Benefits of ECN November 2015 when congestion is experienced. By decoupling congestion control from loss, ECN can allow transports that support these applications to reduce their rate before the application experiences loss from congestion. This can reduce the negative impact of triggering loss- hiding mechanisms with a direct positive impact on the quality experienced by the users of these applications. 2.5. Making Incipient Congestion Visible A characteristic of using ECN is that it exposes the presence of congestion on a network path to the transport and network layers allowing information to be collected about the presence of incipient congestion. Recording the presence of CE-marked packets can provide information about the current congestion level experienced on a network path. A network flow that only experiences CE-marking and no loss implies that the sending endpoint is experiencing only congestion. A network flow may also experience loss (e.g., due to queue overflow, AQM methods that protect other flows, link corruption or loss in middleboxes). When a mixture of CE-marking and packet loss is experienced, transports and measurements need to assume there is congestion [RFC7567]. An absence of CE-marks therefore does not indicate a path has not experienced congestion. The reception of CE-marked packets can be used to monitor the level of congestion by a transport/application or a network operator. For example, ECN measurements are used by Congestion Exposure (ConEx) [RFC6789]. In contrast, metering packet loss is harder. 2.6. Opportunities for new Transport Mechanisms ECN can enable design and deployment of new algorithms in network devices and Internet transports. Internet transports need to regard both loss and CE-marking as an indication of congestion. However, while the amount of feedback provided by drop ought naturally to be minimized, this is not the case for ECN. In contrast, an ECN-Capable network device could provide richer (more frequent and fine-grained) indication of its congestion state to the transport. For any ECN-capable transport, the receiving endpoint needs to provide feedback to the transport sender to indicate that CE-marks have been received.[RFC3168] provides one method that signals once each round trip time that CE-marked packets have been received. A receiving endpoint may provide more detailed feedback to the congestion controller at the sender (e.g., describing the set of received ECN codepoints, or indicating each received CE-marked Fairhurst & Welzl Expires May 27, 2016 [Page 8] Internet-Draft Benefits of ECN November 2015 packet). Precise feedback about the number of CE-marks encountered is supported by the Real Time Protocol (RTP) when used over UDP [RFC6679] and has been proposed for SCTP [ST14] and TCP [ID.Acc.ECN]. More detailed feedback is expected to enable evolution of transport protocols allowing the congestion control mechanism to make a more appropriate decision on how to react to congestion. Designers of transport protocols need to consider not only how network devices CE- mark packets, but also how the control loop in the application/ transport reacts to reception of these CE-marked packets. Benefit has been noted when packets are CE-marked early using an instantaneous queue, and if the receiving endpoint provides feedback about the number of packet marks encountered, an improved sender behavior has been shown to be possible, e.g, Datacenter TCP (DCTCP) [AL10]. DCTCP is targeted at controlled environments such as a datacenter. This is work-in-progress and it is currently unknown whether or how such behaviour could be safely introduced into the Internet. Any update to an Internet transport protocol requires careful consideration of the robustness of the behaviour when working with endpoints or network devices that were not designed for the new congestion reaction. 3. Network Support for ECN For an application to use ECN requires that the endpoints first enable ECN within the transport being used, but also for all network devices along the path to at least forward IP packets that set a non- zero ECN codepoint. ECN can be deployed both in the general Internet and in controlled environments: o ECN can be incrementally deployed in the general Internet. The IETF has provided guidance on configuration and usage in [RFC7567]. o ECN may be deployed within a controlled environment, for example within a data centre or within a well-managed private network. This use of ECN may be tuned to the specific use-case. An example is DCTCP [AL10] [ID.DCTCP]. Early experience of using ECN across the general Internet encountered a number of operational difficulties when the network path either failed to transfer ECN-capable packets or inappropriately changed the ECN codepoints [BA11]. A recent survey reported a growing support for network paths to pass ECN codepoints [TR15]. Fairhurst & Welzl Expires May 27, 2016 [Page 9] Internet-Draft Benefits of ECN November 2015 The remainder of this section identifies what is needed for network devices to effectively support ECN. 3.1. The ECN Field The current IPv4 and IPv6 specifications assign usage of 2 bits in the IP header to carry the ECN codepoint. This 2-bit field was reserved in [RFC2474] and assigned in [RFC3168]. [RFC4774] discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. Some network devices were configured to use a routing hash that included the set of 8 bits forming the now deprecated Type of Service (ToS) field [RFC1349]. The present use of this field assigns 2 of these bits to carry the ECN field. This is incompatible with use in a routing hash, because it could lead to IP packets that carry a CE- mark being routed over a different path to those packets that carried an ECT mark. The resultant reordering would impact the performance of transport protocols (such as TCP or SCTP) and UDP-based applications that are senstive to reordering. A network device that conforms to this older specification needs to be updated to the current specifications [RFC2474] to support ECN. Configuraton of network devices must note that the ECN field may be updated by any ECN-capable network device along a path. 3.2. Forwarding ECN-Capable IP Packets Not all network devices along a path need to be ECN-capable (i.e., perform CE-marking). However, all network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used. Any network device that does not perform CE-marking of an ECN-capable packet can be expected to drop these packets under congestion. Applications that experience congestion at these network devices do not see any benefit from enabling ECN. However, they may see benefit if the congestion were to occur within a network device that did support ECN. 3.3. Enabling ECN in Network Devices Network devices should use an AQM algorithm that CE-marks ECN-capable traffic when making decisions about the response to congestion [RFC7567]. An ECN method should set a CE-mark on ECN-capable packets in the presence of incipient congestion. A CE-marked packet will be Fairhurst & Welzl Expires May 27, 2016 [Page 10] Internet-Draft Benefits of ECN November 2015 interpreted as an indication of incipient congestion by the transport endpoints. There is opportunity to design an AQM method for an ECN-capable network device that differs from an AQM method designed to drop packets. [RFC7567] states that the network device should allow this behaviour to be configurable. [RFC3168] describes a method in which a network device sets the CE- mark at the time that the network device would otherwise have dropped the packet. While it has often been assumed that network devices should CE-mark packets at the same level of congestion at which they would otherwise have dropped them, [RFC7567] recommends that network devices allow independent configuration of the settings for AQM dropping and ECN marking. Such separate configuration of the drop and mark policies is supported in some network devices. 3.4. Co-existance of ECN and non-ECN flows Network devices need to be able to forward all IP flows and provide appropriate treatment for both ECN and non-ECN traffic. The design considerations for an AQM scheme supporting ECN needs to consider the impact of queueing during incipient congestion. For example, a simple AQM scheme could choose to queue ECN-capable and non-ECN capable flows in the same queue with an ECN scheme that CE- mark packets during incipient congestion. The CE-marked packets that remain in the queue during congestion can continue to contribute to queueing delay. In contrast, non-ECN-capable packets would normally be dropped by an AQM scheme under incipient congestion. This difference in queueing is one motivation for consideration of more advanced AQM schemes, and may provide an incentive for enabling flow isolation using scheduling [RFC7567]. The IETF is defining methods to evaluate the suitability of AQM schemes for deployment in the general Internet [ID.AQM.eval]. 3.5. Bleaching and Middlebox Requirements to deploy ECN Network devices should not be configured to change the ECN codepoint in the packets that they forward, except to set the CE-codepoint to signal incipient congestion. Cases have been noted where an endpoint sends a packet with a non- zero ECN mark, but the packet is received by the remote endpoint with a zero ECN codepoint [TR15]. This could be a result of a policy that erases or "bleaches" the ECN codepoint values at a network edge (resetting the codepoint to zero). Bleaching may occur for various Fairhurst & Welzl Expires May 27, 2016 [Page 11] Internet-Draft Benefits of ECN November 2015 reasons (including normalising packets to hide which equipment supports ECN). This policy prevents use of ECN by applications. When ECN-capable IP packets, marked as ECT(0) or ECT(1), are remarked to non-ECN-capable (i.e., the ECN field is set to zero codepoint), this could result in the packets being dropped by ECN-capable network devices further along the path. This eliminates the advantage of using of ECN. A network device must not change a packet with a CE mark to a zero codepoint, if the network device decides not to forward the packet with the CE-mark, it has to instead drop the packet and not bleach the marking. This is because a CE-marked packet has already received ECN treatment in the network, and remarking it would then hide the congestion signal from the receiving endpoint. This eliminates the benefits of ECN. It can also slow down the response to congestion compared to using AQM, because the transport will only react if it later discovers congestion by some other mechanism. Prior to RFC2474, a previous usage assigned the bits now forming the ECN field as a part of the now deprecated Type of Service (ToS) field [RFC1349]. A network device that conforms to this older specification was allowed to remark or erase the ECN codepoints, and such equipment needs to be updated to the current specifications to support ECN. 3.6. Tunneling ECN and the use of ECN by Lower Layer Networks Some networks may use ECN internally or tunnel ECN (e.g., for traffic engineering or security). These methods need to ensure that the ECN- field of the tunnel packets is handled correctly at the ingress and egress of the tunnel. Guidance on the correct use of ECN is provided in [RFC6040]. Further guidance on the encapsulation and use of ECN by non-IP network devices is provided in [ID.ECN-Encap]. 4. Using ECN across the Internet A receiving endpoint needs to report the loss it experiences when it uses loss-based congestion control. So also, when ECN is enabled, a receiving endpoint must correctly report the presence of CE-marks by providing a mechanism to feed this congestion information back to the sending endpoint , [RFC3168], [ID.RFC5405.bis], enabling the sender to react to experienced congestion. This mechanism needs to be designed to operate robustly across a wide range of Internet path characteristics. This section describes partial deployment, how ECN- enabled endpoints can continue to work effectively over a path that Fairhurst & Welzl Expires May 27, 2016 [Page 12] Internet-Draft Benefits of ECN November 2015 experiences misbehaving network devices or when an endpoint does not correctly provide feedback of ECN congestion information. 4.1. Partial Deployment Use of ECN is negotiated between the endpoints prior to using the mechanism. ECN has been designed to allow incremental partial deployment [RFC3168]. Any network device can choose to use either ECN or some other loss-based policy to manage its traffic. Similarly, transport/ application negotiation allows senders and receiving endpoints to choose whether ECN will be used to manage congestion for a particular network flow. 4.2. Detecting whether a Path Really Supports ECN Internet transport and applications need to be robust to the variety and sometimes varying path characteristics that are encountered in the general Internet. They need to monitor correct forwarding of ECN over the entire path and duration of a session. To be robust, applications and transports need to be designed with the expectation of heterogeneous forwarding (e.g., where some IP packets are CE-marked by one network device, and some by another, possibly using a different AQM algorithm, or when a combination of CE-marking and loss-based congestion indications are used. ([ID.AQM.eval] describes methodologies for evaluating AQM schemes.) A transport/application also needs to be robust to path changes. A change in the set of network devices along a path could impact the ability to effectively signal or use ECN across the path, e.g., when a path changes to use a middlebox that bleaches ECN codepoints (see Section 3.5). A sending endpoint can check that any CE-marks applied to packets received over the path are indeed delivered to the remote receiving endpoint and that appropriate feedback is provided. (This could be done by a sender setting known a CE codepoint for specific packets in a network flow and then checking whether the remote endpoint correctly reports these marks [ID.Fallback], [TR15].) If a sender detects persistent misuse of ECN, it needs to fall back to using loss-based recovery and congestion control. Guidance on a suitable tranport reaction is provided in [ID.Fallback]. Fairhurst & Welzl Expires May 27, 2016 [Page 13] Internet-Draft Benefits of ECN November 2015 4.3. Detecting ECN Receiver Feedback Cheating Appropriate feedback requires that the endpoint receiver does not try to conceal reception of CE-marked packets in the ECN feedback information provided to the sending endpoint [RFC7567]. Designers of applications/transports are therefore encouraged to include mechanisms that can detect this misbehavior. If a sending endpoint detects that a receiver is not correctly providing this feedback, it needs to fall back to using loss-based recovery instead of ECN. 5. Summary: Enabling ECN in Network Devices and Hosts This section summarises the benefits of deploying and using ECN within the Internet. It also provides a list of prerequisites to achieve ECN deployment. Application developers should where possible use transports that enable ECN. Applications that directly use UDP need to provide support to implement the functions required for ECN [ID.RFC5405.bis]. Once enabled, an application that uses a transport that supports ECN will experience the benefits of ECN as network deployment starts to enable ECN. The application does not need to be rewritten to gain these benefits. Table 2 summarises the key benefits. +---------+-----------------------------------------------------+ | Section | Benefit | +---------+-----------------------------------------------------+ | 2.1 | Improved throughput | | 2.2 | Reduced Head-of-Line blocking | | 2.3 | Reduced probability of RTO Expiry | | 2.4 | Applications that do not retransmit lost packets | | 2.5 | Making incipient congestion visible | | 2.6 | Opportunities for new transport mechanisms | +---------+-----------------------------------------------------+ Table 2: Summary of Key Benefits Network operators and people configuring network devices should enable ECN [RFC7567]. Prerequisites for network devices (including IP routers) to enable use of ECN include: o A network device that updates the ECN field in IP packets must use IETF-specified methods (see Section 3.1). Fairhurst & Welzl Expires May 27, 2016 [Page 14] Internet-Draft Benefits of ECN November 2015 o A network device may support alternate ECN semantics (see Section 3.1). o A network device must not choose a different network path solely because a packet carries has a CE-codepoint set in the ECN Field, CE-marked packets need to follow the same path as packets with an ECT(0) or ECT(1) codepoint (see Section 3.1).Network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used (see Section 3.2). o A network device must not change a packet with a CE mark to a not- ECN-capable codepoint ('00'), if the network device decides not to forward the packet with the CE-mark, it has to instead drop the packet and not bleach the marking (see Section 3.5). o An ECN-capable network device should correctly update the ECN codepoint of ECN-capable packets in the presence of incipient congestion (see Section 3.3). o Network devices need to be able to forward both ECN-capable and not-ECN-capable flows (see Section 3.4). Prerequisites for network endpoints to enable use of ECN include: o An application should use an Internet transport that can set and receive ECN marks (see Section 4). o An ECN-capable transport/application must return feedback indicating congestion to the sending endpoint and perform an appropriate congestion response (see Section 4). o An ECN-capable transport/application should detect paths where there is there is persistent misuse of ECN and fall back to not sending ECT(0) or ECT(1) (see Section 4.2). o Designers of applications/transports are encouraged to include mechanisms that can detect and react appropriately to misbehaving receivers that fail to report CE-marked packets (see Section 4.3). 6. Acknowledgements The authors were part-funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the authors. The authors would like to thank the following people for their comments on prior versions of this document: Bob Briscoe, David Fairhurst & Welzl Expires May 27, 2016 [Page 15] Internet-Draft Benefits of ECN November 2015 Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie, and other members of the TSVWG and AQM working groups. 7. IANA Considerations XX RFC Ed - PLEASE REMOVE THIS SECTION XXX This memo includes no request to IANA. 8. Security Considerations This document introduces no new security considerations. Each RFC listed in this document discusses the security considerations of the specification it contains. 9. Revision Information XXX RFC-Ed please remove this section prior to publication. Revision 00 was the first WG draft. Revision 01 includes updates to complete all the sections and a rewrite to improve readability. Added section 2. Author list reversed, since Gorry has become the lead author. Corrections following feedback from Wes Eddy upon review of an interim version of this draft. Note: Wes Eddy raised a question about whether discussion of the ECN Pitfalls could be improved or restructured - this is expected to be addressed in the next revision. Revision 02 updates the title, and also the description of mechanisms that help with partial ECN support. We think this draft is ready for wider review. Comments are welcome to the authors or via the IETF AQM or TSVWG mailing lists. Revision 03 includes updates from the mailing list and WG discussions at the Dallas IETF meeting. The section "Avoiding Capacity Overshoot" was removed, since this refers primarily to an AQM benefit, and the additional benefits of ECN are already stated. Separated normative and informative references Revision 04 (WG Review during WGLC) Fairhurst & Welzl Expires May 27, 2016 [Page 16] Internet-Draft Benefits of ECN November 2015 Updated the abstract. Added a table of contents. Addressed various (some conflicting) comments during WGLC with new text. The section on Network Support for ECN was moved, and some suggestions for rewording sections were implemented. Decided not to remove section headers for 2.1 and 2.2 - to ensure the document clearly calls-out the benefits. Updated references. Updated text to improve consistency of terms and added definitions for key terms. Note: The group suggested this document should not define recommendations for end hosts or routers, but simply state the things needs to enable deployment to be successful. Revision 05 (after WGLC comments) Updated abstract to avoid suggesting that this describes new methods for deployment. Added ECN-field definition, and sorted terms in order. Added an opening para to each "benefit" to say what this is. Sought to remove redundancy between sections. Added new section on Codepoints to avoid saying the same thing twice. Reworked sections 3 and 4 to clarify discussion and to remove unnecessary text. Reformatted Summary to refer to sections describing things, rather than appear as a list of new recommendations. Reordered to match the new document order. Note: This version expects an update to RFC5405.bis that will indicate UDP ECN requirements (normative). Revision 06 Corrections from Miria. Revision 07 Fairhurst & Welzl Expires May 27, 2016 [Page 17] Internet-Draft Benefits of ECN November 2015 Update to include IESG feedback from: Spencer, Dan, Benoit, Joel. Corrected Non-ECN to Not-ECN where appropriate, added table of codepoints, clarified sentences describing "conservative" behaviour, added requirement to not do ToS-based routing (Junos enhanced hash), etc. Ammended Acknowledgments section. Revision 08 Typo and definition correction from Bob Briscoe. 10. References 10.1. Normative References [ID.RFC5405.bis] Eggert, Lars., Fairhurst, Gorry., and Greg. Shepherd, "Unicast UDP Usage Guidelines", 2015. [RFC2474] "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers". [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC7567] Baker, F. and G. Fairhurst, "IETF Recommendations Regarding Active Queue Management", Internet-draft draft- ietf-aqm-recommendation-06, October 2014. 10.2. Informative References [AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data Center TCP (DCTCP)", SIGCOMM 2010, August 2010. [BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, "Measuring the State of ECN Readiness in Servers, Clients, and Routers, ACM IMC", 2011. Fairhurst & Welzl Expires May 27, 2016 [Page 18] Internet-Draft Benefits of ECN November 2015 [Fla13] Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas., Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain, Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh. Govindan, "Reducing web latency: the virtue of gentle aggression.", SIGCOMM 2013, October 2013. [ID.Acc.ECN] Briscoe, Bob., Scheffeneger, Richard., and Mirja. Kuehlewind, "More Accurate ECN Feedback in TCP, Work-in- Progress". [ID.AQM.eval] Kuhn, Nicolas., Natarajan, Preethi., Ros, David., and Naeem. Khademi, "AQM Characterization Guidelines (Work-in- progress, draft-ietf-aqm-eval-guidelines)", 2015. [ID.DCTCP] Bensley, S., Eggert, Lars., and D. Thaler, "Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters (Work-in-progress, draft-bensley-tcpm-dctcp)", 2015. [ID.ECN-Encap] Briscoe, B., Kaippallimalil, J., and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Internet-draft, IETF work- in-progress draft-ietf-tsvwg-ecn-encap-guidelines. [ID.Fallback] Kuehlewind, Mirja. and Brian. Trammell, "A Mechanism for ECN Path Probing and Fallback, draft-kuehlewind-tcpm-ecn- fallback, Work-in-Progress". [RFC0768] Postel, J., "User Datagram Protocol", 1980. [RFC1349] "Type of Service in the Internet Protocol Suite". [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, . [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, . Fairhurst & Welzl Expires May 27, 2016 [Page 19] Internet-Draft Benefits of ECN November 2015 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, . [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. Ramakrishnan, "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, DOI 10.17487/RFC5562, June 2009, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, . [ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Control Transmission Protocol (SCTP)", Internet-draft draft-stewart-tsvwg-sctpecn-05.txt, January 2014. [TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, Learmonth, Iain., and Gorry. Fairhurst, "Enabling internet-wide deployment of Explicit Congestion Notification Tramwell, B., Kuehlewind, M., Boppart, D., Learmonth, I., Fairhurst, G. & Scheffnegger, Passive and Active Measurement Conference (PAM)", March 2015. Authors' Addresses Fairhurst & Welzl Expires May 27, 2016 [Page 20] Internet-Draft Benefits of ECN November 2015 Godred Fairhurst University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE UK Email: gorry@erg.abdn.ac.uk Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Fairhurst & Welzl Expires May 27, 2016 [Page 21] ./draft-ietf-lisp-lcaf-22.txt0000664000764400076440000026060113017103472015233 0ustar iustyiusty Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: June 1, 2017 Brocade J. Snijders NTT November 28, 2016 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-22 Abstract This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 1, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Farinacci, et al. Expires June 1, 2017 [Page 1] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 8 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 8 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 11 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 4.5. Multicast Group Membership Information . . . . . . . . . 15 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 17 4.7. Storing Security Data in the Mapping Database . . . . . . 18 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 20 4.9. Replication List Entries for Multicast Forwarding . . . . 22 4.10. Applications for AFI List Type . . . . . . . . . . . . . 23 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 23 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 24 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 25 4.10.4. Using Recursive LISP Canonical Address Encodings . . 26 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 27 5. Experimental LISP Canonical Address Applications . . . . . . 28 5.1. Convey Application Specific Data . . . . . . . . . . . . 29 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 30 5.3. PETR Admission Control Functionality . . . . . . . . . . 32 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 33 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 34 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. Normative References . . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 40 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 42 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 42 B.1. Changes to draft-ietf-lisp-lcaf-22.txt . . . . . . . . . 42 B.2. Changes to draft-ietf-lisp-lcaf-21.txt . . . . . . . . . 43 B.3. Changes to draft-ietf-lisp-lcaf-20.txt . . . . . . . . . 43 B.4. Changes to draft-ietf-lisp-lcaf-19.txt . . . . . . . . . 43 B.5. Changes to draft-ietf-lisp-lcaf-18.txt . . . . . . . . . 43 Farinacci, et al. Expires June 1, 2017 [Page 2] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 B.6. Changes to draft-ietf-lisp-lcaf-17.txt . . . . . . . . . 43 B.7. Changes to draft-ietf-lisp-lcaf-16.txt . . . . . . . . . 43 B.8. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 44 B.9. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 44 B.10. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 44 B.11. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 44 B.12. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 44 B.13. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 44 B.14. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 45 B.15. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 45 B.16. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 45 B.17. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 45 B.18. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 45 B.19. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 45 B.20. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 46 B.21. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 46 B.22. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 46 B.23. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires June 1, 2017 [Page 3] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 IPv6 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. Specific detail uses for the LCAF types defined in this document can be found in the use-case documents that use them. The same LCAF type may be used by more than one use-case document. As an experimental specification, this work is by definition, incomplete. The LCAF types defined in this document are to support experimentation and intended for cautious use in self-contained environments in support of the corresponding use-case documents. This document provides assignment for an initial set of approved LCAF Types (registered with IANA) and additional unapproved LCAF Types [RFC6830]. The unapproved LCAF encodings are defined to support further study and experimentation. 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. Address families are defined for IPv4 and IPv6. See [AFI] and [RFC3232] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Farinacci, et al. Expires June 1, 2017 [Page 4] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Unspecified Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider-Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). This section defines all types for which an initial allocation in the LISP-LCAF registry is requested. See IANA Considerations section for the complete list of such types. The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. When the LISP protocol uses LCAF definitions from this document, the AFI-based address lengths are specified in this document. When new LCAF definitions are defined in other use case documents, the AFI-based address lengths for any new AFI encoded addresses are specified in those documents. Farinacci, et al. Expires June 1, 2017 [Page 5] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 The first 6 bytes of an LISP Canonical Address are followed by a variable number of fields of variable length: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1/Rsvd2: these 8-bit fields are reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings. Currently allocated (both approved and unapproved) values are: Type 0: Null Body Type Type 1: AFI List Type Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Farinacci, et al. Expires June 1, 2017 [Page 6] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Type 16: Encapsulation Format Type Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. When including the AFI, an LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Rsvd1, Rsvd2, and Length fields. When the AFI is not next to an encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Rsvd1, Rsvd2, and Length fields. [RFC6830] states RLOC records based on an IP address are sorted when encoded in control messages so the locator-set has consistent order across all xTRs for a given EID. The sort order is based on sort-key {afi, RLOC-address}. When an RLOC based on an IP address is LCAF encoded, the sort-key is {afi, LCAF-Type}. Therefore, when a locator- set has a mix of AFI records and LCAF records, they are ordered from smallest to largest AFI value. Farinacci, et al. Expires June 1, 2017 [Page 7] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4. LISP Canonical Address Applications The following sections define the LCAF for the currently approved initial set of Type values. 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI-based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | IID mask-len | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. The low-order bits of the Instance ID field must be 0. Length: length in bytes starting and including the byte after this Length field. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The reason for the length difference is so that the maximum number of instances supported per mapping system is 2^32 while conserving space in the LISP data header. This comes at the expense of limiting the maximum number of instances per xTR to 2^24. If an xTR is configured with multiple instance-IDs where the value in Farinacci, et al. Expires June 1, 2017 [Page 8] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 the high-order 8 bits are the same, then the low-order 24 bits MUST be unique. AFI = x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Usage: When used as a lookup key, the EID is regarded as an extended- EID in the mapping system. This encoding is used in EID records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. Farinacci, et al. Expires June 1, 2017 [Page 9] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 AS Number LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. AS Number: the 32-bit AS number of the autonomous system that has been assigned to either the EID or RLOC that follows. AFI = x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires June 1, 2017 [Page 10] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.3. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Valid values are from 0 to 180 degrees right or left of the Prime Meridian. Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Farinacci, et al. Expires June 1, 2017 [Page 11] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Altitude: Height relative to sea level in meters. This is a two's complement signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI = x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. The use of the Geo-Coordinates LCAF encoding raises privacy issues as location information is privacy sensitive, and possibly unexpectedly privacy sensitive information may be conveyed, e.g. if the location information corresponds to a router located in a person's home. Therefore, this encoding should not be used unless needed for operation of a LISP deployment. Before electing to utilize this encoding, care should be taken to ensure the appropriate policies are being used by the EID for controlling the conveyed information. Farinacci, et al. Expires June 1, 2017 [Page 12] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.4. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details. NAT-Traversal Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI = x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires June 1, 2017 [Page 13] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Reencapsulating Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of RTRs encoded is determined by parsing each field. When there are no RTRs supplied, the RTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero RTRs encoded. Usage: This encoding can be used in Info-Request and Info-Reply messages. The mapping system does not store this information. The information is used by an xTR and Map-Server to convey private and public address information when traversing NAT and firewall devices. Care should be taken to protect privacy against the adverse use of a Global or Private ETR RLOC Address by ensuring policy controls are used during EID registrations that use this LCAF Type in RLOC- records. Refer to the use case documents for additional information. Farinacci, et al. Expires June 1, 2017 [Page 14] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.5. Multicast Group Membership Information Multicast group information can be published in the mapping database. So a lookup on a group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI-encoded locator address. When an RTR list is being registered (with multiple levels according to [I-D.coras-lisp-re]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when an EID is away from its home subnet location. Multicast Info Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Reserved: must be set to zero and ignored on receipt. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Farinacci, et al. Expires June 1, 2017 [Page 15] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Source MaskLen: the mask length of the source prefix that follows. The length is the number of high-order mask bits set. Group MaskLen: the mask length of the group prefix that follows. The length is the number of high-order mask bits set. AFI = x: x can be any AFI value from [AFI]. When a specific address family has a multicast address semantic, this field must be either a group address or a broadcast address. Source/Subnet Address: is the source address or prefix for encoding a (S,G) multicast entry. Group Address: is the group address or group prefix for encoding (S,G) or (*,G) multicast entries. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires June 1, 2017 [Page 16] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.6. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF can be returned to provide a list of locators in an explicit re- encapsulation path. See [I-D.farinacci-lisp-te] for details. Explicit Locator Path (ELP) Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI = x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI = x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can be reachable. Strict bit (S): this is the strict bit which means the associated Reencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires June 1, 2017 [Page 17] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 AFI = x: x can be any AFI value from [AFI]. When a specific AFI has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. This encoding does not need to be understood by the mapping system for mapping database lookups since this LCAF type is not a lookup key. 4.7. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF will be used to encode key material. See [I-D.ietf-lisp-ddt] for details. Farinacci, et al. Expires June 1, 2017 [Page 18] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Security Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. A key section is made up of "Key Length" and "Key Material" fields. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. Refer to the [I-D.ietf-lisp-ddt] and [I-D.ietf-lisp-crypto] use cases for definitions of this field. Rsvd4: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI = x: x can be any AFI value from [AFI]. This is the locator address that owns the encoded security key. Farinacci, et al. Expires June 1, 2017 [Page 19] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 4.8. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow need consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Farinacci, et al. Expires June 1, 2017 [Page 20] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Source/Dest Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = y | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. The length is the number of high-order mask bits set. Dest-ML: the mask length of the destination prefix that follows. The length is the number of high-order mask bits set. AFI = x: x can be any AFI value from [AFI]. AFI = y: y can be any AFI value from [AFI]. When a specific address family has a multicast address semantic, this field must be either a group address or a broadcast address. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Refer to [I-D.farinacci-lisp-te] for usage details of this LCAF type. Farinacci, et al. Expires June 1, 2017 [Page 21] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.9. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [I-D.coras-lisp-re]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 13 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Rsvd3/Rsvd4: must be set to zero and ignore on receipt. Level Value: this value is associated with the level within the overlay distribution tree hierarchy where the RTR resides. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI = x: x can be any AFI value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. For efficiency reasons, all RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Farinacci, et al. Expires June 1, 2017 [Page 22] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. 4.10. Applications for AFI List Type 4.10.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry a variable number of AFIs in one LCAF AFI. Address Binding LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. See subsections in this section for specific use cases. Farinacci, et al. Expires June 1, 2017 [Page 23] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.10.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. See [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when doing EID mobility. Care should be taken to protect privacy against the adverse use of a Layer-2 MAC Address by ensuring policy controls are used during EID registrations that use AFI=6 encodings in RLOC-records. Refer to the use case documents for additional information. Farinacci, et al. Expires June 1, 2017 [Page 24] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.10.3. ASCII Names in the Mapping Database If DNS names [RFC1035] or URIs [RFC3986] are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string. ASCII LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. An example for using DNS names is when an ETR registers a mapping with an EID-record encoded as (AFI=1, 10.0.0.0/8) with a RLOC-record (AFI=17, "router.abc.com"). Farinacci, et al. Expires June 1, 2017 [Page 25] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.10.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCAF AFI another LCAF AFI (for example, Application Specific Data see Section 5.1. Recursive LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Rsvd2 | Length2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Length2: length in bytes starting and including the byte after this Length2 field. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires June 1, 2017 [Page 26] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 4.10.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Rsvd2 | Length2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 0 | AFI = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Length2: length in bytes starting and including the byte after this Length2 field. If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate Farinacci, et al. Expires June 1, 2017 [Page 27] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. 5. Experimental LISP Canonical Address Applications The following sections describe experimental LCAF encodings. These LCAF Types are not approved (registered with IANA). The inclusion of these encodings in this document are in support of further study and experimentation to determine whether these encodings are functional, if there is a demand for these use cases, and better understand deployment considerations. As noted previously, these LCAF Types are restricted to cautious use in self-contained environments in support of the corresponding use-case documents. Farinacci, et al. Expires June 1, 2017 [Page 28] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 5.1. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI = x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. This LCAF type is used as a Farinacci, et al. Expires June 1, 2017 [Page 29] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 lookup key to the mapping system that can return a longest-match or exact-match entry. 5.2. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Key Field Num: the value of this field is the number of "Key" sub- fields minus 1, the "Key" field can be broken up into. So if this Farinacci, et al. Expires June 1, 2017 [Page 30] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 field has a value of 0, there is 1 sub-field in the "Key". The width of the sub-fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes each in length. Allowing for a reasonable number of 16 sub-field separators, valid values range from 0 to 15. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, the low-order field in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (as shown above). Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires June 1, 2017 [Page 31] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 5.3. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. This nonce value is inserted in the nonce field in the LISP header encapsulation. AFI = x: x can be any AFI value from [AFI]. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires June 1, 2017 [Page 32] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 5.4. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 14 | Rsvd2 |B| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON length | JSON binary/text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC7159]. JSON length: length in octets of the following 'JSON binary/text encoding' field. JSON binary/text encoding field: a variable length field that contains either binary or text encodings. AFI = x: x can be any AFI value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Usage: This is an experimental type where the usage has not been defined yet. An example mapping is an EID-record encoded as a distinguished-name "cpe-rotuer" and a RLOC-record encoded as a JSON string "{ "router-address" : "1.1.1.1", "router-mask" : "8" }". Farinacci, et al. Expires June 1, 2017 [Page 33] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 5.5. Encoding Key/Value Address Pairs The Key/Value pair is, for example, useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as the key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 15 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Address as Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = y | Address as Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. AFI = x: x is the "Address as Key" AFI that can have any value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Address as Key: this AFI-encoded address will be attached with the attributes encoded in "Address as Value" which follows this field. AFI = y: y is the "Address of Value" AFI that can have any value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Value: this AFI-encoded address will be the attribute address that goes along with "Address as Key" which precedes this field. Farinacci, et al. Expires June 1, 2017 [Page 34] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Usage: This is an experimental type where the usage has not been defined yet. 5.6. Multiple Data-Planes Overlays are becoming popular in many parts of the network which have created an explosion of data-plane encapsulation headers. Since the LISP mapping system can hold many types of address formats, it can represent the encapsulation format supported by an RLOC as well. When an encapsulator receives a Map-Reply with an Encapsulation Format LCAF Type encoded in an RLOC-record, it can select an encapsulation format, that it can support, from any of the encapsulation protocols which have the bit set to 1 in this LCAF type. Farinacci, et al. Expires June 1, 2017 [Page 35] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Encapsulation Format Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 16 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes starting and including the byte after this Length field. Reserved-for-Future-Encapsulations: must be set to zero and ignored on receipt. This field will get bits allocated to future encapsulations, as they are created. L: The RLOCs listed in the AFI-encoded addresses in the next longword can accept layer 3 LISP encapsulation using destination UDP port 4341 [RFC6830]. l: The RLOCs listed in the AFI-encoded addresses in the next longword can accept layer 2 LISP encapsulation using destination UDP port 8472 [I-D.smith-lisp-layer2]. V: The RLOCs listed in the AFI-encoded addresses in the next longword can accept VXLAN encapsulation using destination UDP port 4789 [RFC7348]. v: The RLOCs listed in the AFI-encoded addresses in the next longword can accept VXLAN-GPE encapsulation using destination UDP port 4790 [I-D.quinn-vxlan-gpe]. N: The RLOCs listed in the AFI-encoded addresses in the next longword can accept NV-GRE encapsulation using IPv4/ IPv6 protocol number 47 [RFC7637]. G: The RLOCs listed in the AFI-encoded addresses in the next longword can accept GENEVE encapsulation using destination UDP port 6081 [I-D.gross-geneve]. U: The RLOCs listed in the AFI-encoded addresses in the next longword can accept GUE encapsulation using destination UDP port TBD [I-D.herbert-gue]. Farinacci, et al. Expires June 1, 2017 [Page 36] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. 6. Security Considerations This document is classified as Experimental. The LCAF encodings defined in this document are intended to be used with their corresponding use cases and in self-contained environments. Users Farinacci, et al. Expires June 1, 2017 [Page 37] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 should carefully consider how the [I-D.ietf-lisp-sec] threat model applies to their particular use case. The use of the Geo-Coordinates LCAF Type may raise physical privacy issues. Care should be taken when configuring the mapping system to use specific policy parameters so geo-location information is not returned gratuitously. It is recommended that any documents that specify the use of the Geo-Coordinates LCAF Type should consider the applicability of the BCP160 [RFC6280] for location-based privacy protection. Additional privacy concerns have arisen since publication of BCP160, and future work on LISP should examine potential threats beyond BCP160 and address improving privacy and security for LISP deployments. 7. IANA Considerations This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Such address format is based on a fixed AFI (16387) and a LISP LCAF Type field. The LISP LCAF Type field is an 8-bit field specific to the LISP Canonical Address formatted encodings, for which IANA is to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP LCAF Type". Initial values for the LISP LCAF Type registry are given below. Future assignments are to be made based on specification required. Assignments consist of a LISP LCAF Type name and its associated value: +-------+------------------------------+------------+ | Value | LISP LCAF Type Name | Definition | +-------+------------------------------+------------+ | 0 | Null Body Type | Section 3 | | 1 | AFI List Type | Section 3 | | 2 | Instance ID Type | Section 3 | | 3 | AS Number Type | Section 3 | | 5 | Geo Coordinates Type | Section 3 | | 7 | NAT-Traversal Type | Section 3 | | 9 | Multicast Info Type | Section 3 | | 10 | Explicit Locator Path Type | Section 3 | | 11 | Security Key Type | Section 3 | | 12 | Source/Dest Key Type | Section 3 | | 13 | Replication List Entry Type | Section 3 | +-------+------------------------------+------------+ Table 1: LISP LCAF Type Initial Values Farinacci, et al. Expires June 1, 2017 [Page 38] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 8. References 8.1. Normative References [BCP160] "An Architecture for Location and Location Privacy in Internet Applications", Best Current Practices https://www.rfc-editor.org/bcp/bcp160.txt, July 2011. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . Farinacci, et al. Expires June 1, 2017 [Page 39] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . 8.2. Informative References [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/assignments/address-family- numbers/address-family-numbers.xhtml?, Febuary 2007. [I-D.coras-lisp-re] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-08 (work in progress), November 2015. [I-D.ermagan-lisp-nat-traversal] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan- lisp-nat-traversal-11 (work in progress), August 2016. [I-D.farinacci-lisp-te] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-11 (work in progress), September 2016. [I-D.gross-geneve] Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Generic Network Virtualization Encapsulation", draft- gross-geneve-02 (work in progress), October 2014. Farinacci, et al. Expires June 1, 2017 [Page 40] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 [I-D.herbert-gue] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", draft-herbert-gue-03 (work in progress), March 2015. [I-D.ietf-lisp-crypto] Farinacci, D. and B. Weis, "LISP Data-Plane Confidentiality", draft-ietf-lisp-crypto-10 (work in progress), October 2016. [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- ddt-08 (work in progress), September 2016. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 (work in progress), November 2016. [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- mobility-01 (work in progress), October 2016. [I-D.quinn-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-04 (work in progress), February 2015. [I-D.smith-lisp-layer2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 (L2) LISP Encapsulation Format", draft-smith-lisp- layer2-03 (work in progress), September 2013. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Farinacci, et al. Expires June 1, 2017 [Page 41] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. And finally, the authors thank Stephen Farrell (Security Area Director) and Deborah Brungard (Routing Area Director) for their suggested text to get the document through IESG review. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-lcaf-22.txt o Submitted November 2016. o Take into account RTG area director Deborah Brungard's comments suggestions. o The changes put in shoudl clear Stephen's DISCUSS comments on RLOC-record ordering and privacy concerns with the Geo-Coordinate LCAF type. Farinacci, et al. Expires June 1, 2017 [Page 42] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 B.2. Changes to draft-ietf-lisp-lcaf-21.txt o Submitted November 2016. o Reflect Alexey's DISCUSS comments. o Add text to intro section that says the details for any LCAF type can be found in other use-case documents. o Provide general examples for JSON and DNS LCAF types. B.3. Changes to draft-ietf-lisp-lcaf-20.txt o Submitted October 2016. o Put in references to DNS names and URIs per Alexey's comment. B.4. Changes to draft-ietf-lisp-lcaf-19.txt o Submitted October 2016. o Make it more clear that any use-case documents that use the Geo- Coordinates LCAF type should discuss RFC6280 compliance. B.5. Changes to draft-ietf-lisp-lcaf-18.txt o Submitted October 2016 after October 13th telechat. o Addressed comments from Ben Campbell, Jari Arrko, Stephen Farrel, Peter Yee, Dale Worley, Mirja Kuehlewind, and Suresh Krishnan. B.6. Changes to draft-ietf-lisp-lcaf-17.txt o Submitted October 2016. o Addressed comments from Gen-ART reviewer Peter Yee. o Addressed IESG last-call comments from Suresh Krishnan. B.7. Changes to draft-ietf-lisp-lcaf-16.txt o Submitted October 2016. o Addressed comments from Security Directorate reviewer David Mandelberg. Farinacci, et al. Expires June 1, 2017 [Page 43] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 B.8. Changes to draft-ietf-lisp-lcaf-15.txt o Submitted September 2016. o Addressed comments from Routing Directorate reviewer Stig Venass. B.9. Changes to draft-ietf-lisp-lcaf-14.txt o Submitted July 2016. o Fix IDnits errors and comments from Luigi Iannone, document shepherd. B.10. Changes to draft-ietf-lisp-lcaf-13.txt o Submitted May 2016. o Explain the Instance-ID LCAF Type is 32-bits in length and the Instance-ID field in the LISP encapsulation header is 24-bits. B.11. Changes to draft-ietf-lisp-lcaf-12.txt o Submitted March 2016. o Updated references and document timer. o Removed the R, J, and L bits from the Multicast Info Type LCAF since working group decided to not go forward with draft- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- signal-free-00.txt. B.12. Changes to draft-ietf-lisp-lcaf-11.txt o Submitted September 2015. o Reflecting comments from Prague LISP working group. o Readying document for a LISP LCAF registry, RFC publication, and for new use cases that will be defined in the new charter. B.13. Changes to draft-ietf-lisp-lcaf-10.txt o Submitted June 2015. o Fix coauthor Job's contact information. Farinacci, et al. Expires June 1, 2017 [Page 44] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 B.14. Changes to draft-ietf-lisp-lcaf-09.txt o Submitted June 2015. o Fix IANA Considerations section to request a registry to allocate and track LCAF Type values. B.15. Changes to draft-ietf-lisp-lcaf-08.txt o Submitted April 2015. o Comment from Florin. The Application Data Type length field has a typo. The field should be labeled "12 + n" and not "8 + n". o Fix length fields in the sections titled "Using Recursive LISP Canonical Address Encodings", "Generic Database Mapping Lookups", and "Data Model Encoding". B.16. Changes to draft-ietf-lisp-lcaf-07.txt o Submitted December 2014. o Add a new LCAF Type called "Encapsulation Format" so decapsulating xTRs can inform encapsulating xTRs what data-plane encapsulations they support. B.17. Changes to draft-ietf-lisp-lcaf-06.txt o Submitted October 2014. o Make it clear how sorted RLOC records are done when LCAFs are used as the RLOC record. B.18. Changes to draft-ietf-lisp-lcaf-05.txt o Submitted May 2014. o Add a length field of the JSON payload that can be used for either binary or text encoding of JSON data. B.19. Changes to draft-ietf-lisp-lcaf-04.txt o Submitted January 2014. o Agreement among ELP implementors to have the AFI 16-bit field adjacent to the address. This will make the encoding consistent with all other LCAF type address encodings. Farinacci, et al. Expires June 1, 2017 [Page 45] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 B.20. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.21. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use cases. o Changed references to new LISP RFCs. B.22. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.23. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Farinacci, et al. Expires June 1, 2017 [Page 46] Internet-Draft LISP Canonical Address Format (LCAF) November 2016 Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ The Netherlands Email: job@ntt.net Farinacci, et al. Expires June 1, 2017 [Page 47] ./draft-ietf-aqm-fq-codel-06.txt0000664000764400076440000015605212672752375015657 0ustar iustyiusty AQM working group T. Hoeiland-Joergensen Internet-Draft Karlstad University Intended status: Experimental P. McKenney Expires: September 19, 2016 IBM Linux Technology Center D. Taht Teklibre J. Gettys E. Dumazet Google, Inc. March 18, 2016 The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm draft-ietf-aqm-fq-codel-06 Abstract This memo presents the FQ-CoDel hybrid packet scheduler/Active Queue Management algorithm, a powerful tool for fighting bufferbloat and reducing latency. FQ-CoDel mixes packets from multiple flows and reduces the impact of head of line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short; and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 19, 2016. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 1] Internet-Draft fq-codel March 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 4 1.2. Terminology and concepts . . . . . . . . . . . . . . . . 4 1.3. Informal summary of FQ-CoDel . . . . . . . . . . . . . . 5 2. CoDel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Flow Queueing . . . . . . . . . . . . . . . . . . . . . . . . 6 4. The FQ-CoDel scheduler . . . . . . . . . . . . . . . . . . . 7 4.1. Enqueue . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Alternative classification schemes . . . . . . . . . 8 4.2. Dequeue . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Implementation considerations . . . . . . . . . . . . . . . . 10 5.1. Data structures . . . . . . . . . . . . . . . . . . . . . 10 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Interval . . . . . . . . . . . . . . . . . . . . . . 11 5.2.2. Target . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.3. Packet limit . . . . . . . . . . . . . . . . . . . . 11 5.2.4. Quantum . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.5. Flows . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.6. Explicit Congestion Notification (ECN) . . . . . . . 12 5.2.7. CE threshold . . . . . . . . . . . . . . . . . . . . 13 5.3. Probability of hash collisions . . . . . . . . . . . . . 13 5.4. Memory Overhead . . . . . . . . . . . . . . . . . . . . . 13 5.5. Per-Packet Timestamping . . . . . . . . . . . . . . . . . 14 5.6. Limiting queueing in lower layers . . . . . . . . . . . . 15 5.7. Other forms of "Fair Queueing" . . . . . . . . . . . . . 15 5.8. Differences between CoDel and FQ-CoDel behaviour . . . . 15 6. Limitations of flow queueing . . . . . . . . . . . . . . . . 16 6.1. Fairness between things other than flows . . . . . . . . 16 6.2. Flow bunching by opaque encapsulation . . . . . . . . . . 17 6.3. Low-priority congestion control algorithms . . . . . . . 17 7. Deployment status and future work . . . . . . . . . . . . . . 18 Hoeiland-Joergensen, etExpires September 19, 2016 [Page 2] Internet-Draft fq-codel March 2016 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The FlowQueue-CoDel (FQ-CoDel) algorithm is a combined packet scheduler and Active Queue Management (AQM) [RFC3168] algorithm developed as part of the bufferbloat-fighting community effort [BLOATWEB]. It is based on a modified Deficit Round Robin (DRR) queue scheduler [DRR][DRRPP], with the CoDel AQM [I-D.ietf-aqm-codel] algorithm operating on each queue. This document describes the combined algorithm; reference implementations are available for the ns2 [NS2] and ns3 [NS3] network simulators, and it is included in the mainline Linux kernel as the fq_codel queueing discipline [LINUXSRC]. FQ-CoDel is a general, efficient, nearly parameterless queue management approach combining flow queueing with CoDel. It is a powerful tool for solving bufferbloat [BLOAT], and we believe it to be safe to turn on by default, as has already happened in a number of Linux distributions. In this document we document the Linux implementation in sufficient detail for an independent implementation, to enable deployment outside of the Linux ecosystem. Since the FQ-CoDel algorithm was originally developed in the Linux kernel, that implementation is still considered canonical. This document strives to describe the algorithm in the abstract in the first sections and separate out most implementation details in subsequent sections, but does use the Linux implementation as reference for default behaviour in the algorithm description itself. The rest of this document is structured as follows: This section gives some concepts and terminology used in the rest of the document, and gives a short informal summary of the FQ-CoDel algorithm. Section 2 gives an overview of the CoDel algorithm. Section 3 covers the flow hashing and DRR portion. Section 4 then describes the working of the algorithm in detail, while Section 5 describes implementation details and considerations. Section 6 lists some of the limitations of using flow queueing. Finally, Section 7 outlines the current status of FQ-CoDel deployment and lists some possible future areas of inquiry, and Section 8 reiterates some important security points that must be observed in the implementation. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 3] Internet-Draft fq-codel March 2016 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. 1.2. Terminology and concepts Flow: A flow is typically identified by a 5-tuple of source IP, destination IP, source port, destination port, and protocol number. It can also be identified by a superset or subset of those parameters, or by media access control (MAC) address, or other means. FQ-CoDel hashes flows into a configurable number of buckets to assign packets to internal Queues. Queue: A queue of packets represented internally in FQ-CoDel. In most instances each flow gets its own queue; however because of the possibility of hash collisions, this is not always the case. In an attempt to avoid confusion, the word 'queue' is used to refer to the internal data structure, and 'flow' to refer to the actual stream of packets being delivered to the FQ-CoDel algorithm. Scheduler: A mechanism to select which queue a packet is dequeued from. CoDel AQM: The Active Queue Management algorithm employed by FQ-CoDel [I-D.ietf-aqm-codel]. DRR: Deficit round-robin scheduling [DRR]. Quantum: The maximum amount of bytes to be dequeued from a queue at once. Interval: Characteristic time period used by the control loop of CoDel to detect when a persistent Queue is developing (see Section 4.3 of [I-D.ietf-aqm-codel]). Target: Setpoint value of the minimum sojourn time of packets in a Queue used as the target of the control loop in CoDel (see Section 4.4 of [I-D.ietf-aqm-codel]). Hoeiland-Joergensen, etExpires September 19, 2016 [Page 4] Internet-Draft fq-codel March 2016 1.3. Informal summary of FQ-CoDel FQ-CoDel is a _hybrid_ of DRR [DRR] and CoDel [I-D.ietf-aqm-codel], with an optimisation for sparse flows similar to Shortest Queue First (SQF) [SQF] and DRR++ [DRRPP]. We call this "Flow Queueing" rather than "Fair Queueing" as flows that build a queue are treated differently from flows that do not. By default, FQ-CoDel stochastically classifies incoming packets into different queues by hashing the 5-tuple of IP protocol number and source and destination IP and port numbers, perturbed with a random number selected at initiation time (although other flow classification schemes can optionally be configured instead; see Section 4.1.1). Each queue is managed by the CoDel AQM algorithm [CODEL]. Packet ordering within a queue is preserved, since queues have FIFO ordering. The FQ-CoDel algorithm consists of two logical parts: the scheduler which selects which queue to dequeue a packet from, and the CoDel AQM which works on each of the queues. The subtleties of FQ-CoDel are mostly in the scheduling part, whereas the interaction between the scheduler and the CoDel algorithm are fairly straight forward: At initialisation, each queue is set up to have a separate set of CoDel state variables. By default, 1024 queues are created. The Linux implementation at the time of writing supports anywhere from one to 64K separate queues, and each queue maintains the state variables throughout its lifetime, and so acts the same as the non-FQ CoDel variant would. This means that with only one queue, FQ-CoDel behaves essentially the same as CoDel by itself. On dequeue, FQ-CoDel selects a queue from which to dequeue by a two- tier round-robin scheme, in which each queue is allowed to dequeue up to a configurable quantum of bytes for each iteration. Deviations from this quantum is maintained as byte credits for the queue, which serves to make the fairness scheme byte-based rather than packet- based. The two-tier round-robin mechanism distinguishes between "new" queues (which don't build up a standing queue) and "old" queues, that have queued enough data to be around for more than one iteration of the round-robin scheduler. This new/old queue distinction has a particular consequence for queues that don't build up more than a quantum of bytes before being visited by the scheduler: Such queues are removed from the list, and then re-added as a new queue each time a packet arrives for it, and so will get priority over queues that do not empty out each round (except for a minor modification to protect against starvation, detailed below). Exactly how little data a flow has to send to keep Hoeiland-Joergensen, etExpires September 19, 2016 [Page 5] Internet-Draft fq-codel March 2016 its queue in this state is somewhat difficult to reason about, because it depends on both the egress link speed and the number of concurrent flows. However, in practice many things that are beneficial to have prioritised for typical internet use (ACKs, DNS lookups, interactive SSH, HTTP requests, VoIP) _tend_ to fall in this category, which is why FQ-CoDel performs so well for many practical applications. However, the implicitness of the prioritisation means that for applications that require guaranteed priority (for instance multiplexing the network control plane over the network itself), explicit classification is still needed. This scheduling scheme has some subtlety to it, which is explained in detail in the remainder of this document. 2. CoDel CoDel is described in the ACM Queue paper [CODEL], and the IETF document [I-D.ietf-aqm-codel]. The basic idea is to control queue length, maintaining sufficient queueing to keep the outgoing link busy, but avoiding building up the queue beyond that point. This is done by preferentially dropping packets that remain in the queue for "too long". Packets are dropped by head drop, which lowers the time for the drop signal to propagate back to the sender by the length of the queue, and helps trigger TCP fast retransmit sooner. The CoDel algorithm itself will not be described here; instead we refer the reader to the CoDel draft [I-D.ietf-aqm-codel]. 3. Flow Queueing The intention of FQ-CoDel's scheduler is to give each _flow_ its own queue, hence the term _Flow Queueing_. Rather than a perfect realisation of this, a hashing-based scheme is used, where flows are hashed into a number of buckets which each has its own queue. The number of buckets is configurable, and presently defaults to 1024 in the Linux implementation. This is enough to avoid hash collisions on a moderate number of flows as seen for instance in a home gateway. Depending on the characteristics of the link, this can be tuned to trade off memory for a lower probability of hash collisions. See Section 6 for a more in-depth discussion of this. By default, the flow hashing is performed on the 5-tuple of source and destination IP addresses and port numbers and IP protocol number. While the hashing can be customised to match on arbitrary packet bytes, care should be taken when doing so: Much of the benefit of the FQ-CoDel scheduler comes from this per-flow distinction. However, the default hashing does have some limitations, as discussed in Section 6. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 6] Internet-Draft fq-codel March 2016 FQ-CoDel's DRR scheduler is byte-based, employing a deficit round- robin mechanism between queues. This works by keeping track of the current number _byte credits_ of each queue. This number is initialised to the configurable quantum; each time a queue gets a dequeue opportunity, it gets to dequeue packets, decreasing the number of credits by the packet size for each packet. This continues until the value of _byte credits_ becomes zero or less, at which point it is increased by one quantum, and the dequeue opportunity ends. This means that if one queue contains packets of, for instance, size quantum/3, and another contains quantum-sized packets, the first queue will dequeue three packets each time it gets a turn, whereas the second only dequeues one. This means that flows that send small packets are not penalised by the difference in packet sizes; rather, the DRR scheme approximates a (single-)byte-based fairness queueing scheme. The size of the quantum determines the scheduling granularity, with the tradeoff from too small a quantum being scheduling overhead. For small bandwidths, lowering the quantum from the default MTU size can be advantageous. Unlike plain DRR there are two sets of flows - a "new" list for flows that have not built a queue recently, and an "old" list for queues that build a backlog. This distinction is an integral part of the FQ-CoDel scheduler and is described in more detail in Section 4. 4. The FQ-CoDel scheduler To make its scheduling decisions, FQ-CoDel maintains two ordered lists of active queues, called "new" and "old" queues. When a packet is added to a queue that is not currently active, that queue becomes active by being added to the list of new queues. Later on, it is moved to the list of old queues, from which it is removed when it is no longer active. This behaviour is the source of some subtlety in the packet scheduling at dequeue time, explained below. 4.1. Enqueue The packet enqueue mechanism consists of three stages: classification into a queue, timestamping and bookkeeping, and optionally dropping a packet when the total number of enqueued packets goes over the maximum. When a packet is enqueued, it is first classified into the appropriate queue. By default, this is done by hashing (using a Jenkins hash function [JENKINS]) on the 5-tuple of IP protocol, and source and destination IP addresses and port numbers (if they exist), and taking the hash value modulo the number of queues. The hash is Hoeiland-Joergensen, etExpires September 19, 2016 [Page 7] Internet-Draft fq-codel March 2016 salted by modulo addition of a random value selected at initialisation time, to prevent possible DoS attacks if the hash is predictable ahead of time (see Section 8). The Linux kernel implements the Jenkins hash function by mixing three 32-bit values into a single 32-bit output value. Inputs larger than 96 bits are reduced by additional mixing steps, 96 bits at a time. Once the packet has been successfully classified into a queue, it is handed over to the CoDel algorithm for timestamping. It is then added to the tail of the selected queue, and the queue's byte count is updated by the packet size. Then, if the queue is not currently active (i.e., if it is not in either the list of new or the list of old queues), it is added to the end of the list of new queues, and its number of credits is initiated to the configured quantum. Otherwise, the queue is left in its current queue list. Finally, the total number of enqueued packets is compared with the configured limit, and if it is _above_ this value (which can happen since a packet was just enqueued), a packet is dropped from the head of the queue with the largest current byte count. Note that this in most cases means that the packet that gets dropped is different from the one that was just enqueued, and may even be from a different queue. 4.1.1. Alternative classification schemes As mentioned previously, it is possible to modify the classification scheme to provide a different notion of a 'flow'. The Linux implementation provides this option in the form of the "tc filter" command. While this can add capabilities (for instance, matching on other possible parameters such as MAC address, diffserv code point values, firewall rules, flow specific markings, IPv6 flow label, etc.), care should be taken to preserve the notion of 'flow' as much of the benefit of the FQ-CoDel scheduler comes from keeping flows in separate queues. For protocols that do not contain a port number (such as ICMP), the Linux implementation simply sets the port numbers to zero and performs the hashing as usual. In practice, this results in such protocols to each get their own queue (except in the case of hash collisions). An implementation can perform other classifications for protocols that have their own notion of a flow, but SHOULD fall back to simply hashing on source and destination IP address and IP protocol number in the absence of other information. The default classification scheme can additionally be improved by performing decapsulation of tunnelled packets prior to hashing on the 5-tuple in the encapsulated payload. The Linux implementation does Hoeiland-Joergensen, etExpires September 19, 2016 [Page 8] Internet-Draft fq-codel March 2016 this for common encapsulations known to the kernel, such as 6in4 [RFC4213], IP-in-IP [RFC2003] and GRE (Generic Routing Encapsulation) [RFC2890]. This helps to distinguish between flows that share the same (outer) 5-tuple, but of course is limited to unencrypted tunnels (see Section 6.2). 4.2. Dequeue Most of FQ-CoDel's work is done at packet dequeue time. It consists of three parts: selecting a queue from which to dequeue a packet, actually dequeuing it (employing the CoDel algorithm in the process), and some final bookkeeping. For the first part, the scheduler first looks at the list of new queues; for the queue at the head of that list, if that queue has a negative number of credits (i.e., it has already dequeued at least a quantum of bytes), it is given an additional quantum of credits, the queue is put onto _the end of_ the list of old queues, and the routine selects the next queue and starts again. Otherwise, that queue is selected for dequeue. If the list of new queues is empty, the scheduler proceeds down the list of old queues in the same fashion (checking the credits, and either selecting the queue for dequeuing, or adding credits and putting the queue back at the end of the list). After having selected a queue from which to dequeue a packet, the CoDel algorithm is invoked on that queue. This applies the CoDel control law, which is the mechanism CoDel uses to determine when to drop packets (see [I-D.ietf-aqm-codel]). As a result of this, one or more packets may be discarded from the head of the selected queue, before the packet that should be dequeued is returned (or nothing is returned if the queue is or becomes empty while being handled by the CoDel algorithm). Finally, if the CoDel algorithm does not return a packet, then the queue must be empty, and the scheduler does one of two things: if the queue selected for dequeue came from the list of new queues, it is moved to _the end of_ the list of old queues. If instead it came from the list of old queues, that queue is removed from the list, to be added back (as a new queue) the next time a packet arrives that hashes to that queue. Then (since no packet was available for dequeue), the whole dequeue process is restarted from the beginning. If, instead, the scheduler _did_ get a packet back from the CoDel algorithm, it subtracts the size of the packet from the byte credits for the selected queue and returns the packet as the result of the dequeue operation. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 9] Internet-Draft fq-codel March 2016 The step that moves an empty queue from the list of new queues to _the end of_ the list of old queues before it is removed is crucial to prevent starvation. Otherwise the queue could reappear (the next time a packet arrives for it) before the list of old queues is visited; this can go on indefinitely even with a small number of active flows, if the flow providing packets to the queue in question transmits at just the right rate. This is prevented by first moving the queue to _the end of_ the list of old queues, forcing a pass through that, and thus preventing starvation. Moving it to the end of the list, rather than the front, is crucial for this to work. The resulting migration of queues between the different states is summarised in the following state diagram: +-----------------+ +------------------+ | | Empty | | | Empty |<---------------+ Old +----+ | | | | | +-------+---------+ +------------------+ | | ^ ^ |Credits |Arrival | | |Exhausted v | | | +-----------------+ | | | | | Empty or | | | | New +-------------------+ +-------+ | | Credits exhausted +-----------------+ Figure 1: Partial state diagram for queues between different states. Both the new and old queue states can additionally have arrival and dequeue events that do not change the state; these are omitted here. 5. Implementation considerations This section contains implementation details for the FQ-CoDel algorithm. This includes the data structures and parameters used in the Linux implementation, as well as discussion of some required features of the target platform and other considerations. 5.1. Data structures The main data structure of FQ-CoDel is the array of queues, which is instantiated with the number of queues specified by the _flows_ parameter at instantiation time. Each queue consists simply of an ordered list of packets with FIFO semantics, two state variables tracking the queue credits and total number of bytes enqueued, and the set of CoDel state variables. Other state variables to track Hoeiland-Joergensen, etExpires September 19, 2016 [Page 10] Internet-Draft fq-codel March 2016 queue statistics can also be included: for instance, the Linux implementation keeps a count of dropped packets. In addition to the queue structures themselves, FQ-CoDel maintains two ordered lists containing references to the subset of queues that are currently active. These are the list of 'new' queues and the list of 'old' queues, as explained in Section 4 above. In the Linux implementation, queue space is shared: there's a global limit on the number of packets the queues can hold, but not one per queue. 5.2. Parameters The following are the user configuration parameters exposed by the Linux implementation of FQ-CoDel. 5.2.1. Interval The _interval_ parameter has the same semantics as CoDel and is used to ensure that the minimum sojourn time of packets in a queue used as an estimator by the CoDel control algorithm is a relatively up-to- date value. That is, CoDel only reacts to delay experienced in the last epoch of length interval. It SHOULD be set to be on the order of the worst-case RTT through the bottleneck to give end-points sufficient time to react. The default interval value is 100 ms. 5.2.2. Target The _target_ parameter has the same semantics as CoDel. It is the acceptable minimum standing/persistent queue delay for each FQ-CoDel Queue. This minimum delay is identified by tracking the local minimum queue delay that packets experience. The default target value is 5 ms, but this value should be tuned to be at least the transmission time of a single MTU-sized packet at the prevalent egress link speed (which for, e.g., 1Mbps and MTU 1500 is ~15ms), to prevent CoDel from being too aggressive at low bandwidths. It should otherwise be set to on the order of 5-10% of the configured interval. 5.2.3. Packet limit Routers do not have infinite memory, so some packet limit MUST be enforced. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 11] Internet-Draft fq-codel March 2016 The _limit_ parameter is the hard limit on the real queue size, measured in number of packets. This limit is a global limit on the number of packets in all queues; each individual queue does not have an upper limit. When the limit is reached and a new packet arrives for enqueue, a packet is dropped from the head of the largest queue (measured in bytes) to make room for the new packet. In Linux, the default packet limit is 10240 packets, which is suitable for up to 10 Gigabit Ethernet speeds. In practice, the hard limit is rarely, if ever, hit, as drops are performed by the CoDel algorithm long before the limit is hit. For platforms that are severely memory constrained, a lower limit can be used. 5.2.4. Quantum The _quantum_ parameter is the number of bytes each queue gets to dequeue on each round of the scheduling algorithm. The default is set to 1514 bytes which corresponds to the Ethernet MTU plus the hardware header length of 14 bytes. In systems employing TCP Segmentation Offload (TSO), where a "packet" consists of an offloaded packet train, it can presently be as large as 64K bytes. In systems using Generic Receive Offload (GRO), they can be up to 17 times the TCP max segment size (or 25K bytes). These mega-packets severely impact FQ-CoDel's ability to schedule traffic, and hurt latency needlessly. There is ongoing work in Linux to make smarter use of offload engines. 5.2.5. Flows The _flows_ parameter sets the number of queues into which the incoming packets are classified. Due to the stochastic nature of hashing, multiple flows may end up being hashed into the same slot. This parameter can be set only at initialisation time in the current implementation, since memory has to be allocated for the hash table. The default value is 1024 in the current Linux implementation. 5.2.6. Explicit Congestion Notification (ECN) ECN is _enabled_ by default. Rather than do anything special with misbehaved ECN flows, FQ-CoDel relies on the packet scheduling system to minimise their impact, thus the number of unresponsive packets in a flow being marked with ECN can grow to the overall packet limit, but will not otherwise affect the performance of the system. It can be disabled by specifying the _noecn_ parameter. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 12] Internet-Draft fq-codel March 2016 5.2.7. CE threshold This parameter enables Date Centre TCP (DCTCP)-like processing resulting in CE (Congestion Encountered) marking on ECN-Capable Transport (ECT) packets [RFC3168] starting at a lower sojourn delay setpoint than the default CoDel Target. Details of DCTCP can be found in [I-D.ietf-tcpm-dctcp]. The parameter, _ce_threshold_, is disabled by default and can be set to a number of microseconds to enable. 5.3. Probability of hash collisions Since the Linux FQ-CoDel implementation by default uses 1024 hash buckets, the probability that (say) 100 flows will all hash to the same bucket is something like ten to the power of minus 300. Thus, at least one of the flows will almost certainly hash to some other queue. Expanding on this, based on analytical equations for hash collision probabilities, for 100 flows, the probability of no collision is 90.78%; the probability that no more than two of the 100 flows will be involved in any given collision = 99.57%; and the probability that no more than three of the 100 flows will be involved in any given collision = 99.99%. These probabilities assume a hypothetical perfect hashing function, so in practice they may be a bit lower. We have not found this difference to matter in practice. These probabilities can be improved upon by using set-associative hashing, a technique used in the Cake algorithm currently being developed as a further development upon the FQ-CoDel principles. For a 4-way associative hash with the same number of total queues, the probability of no collisions for 100 flows is 99.93%, while for an 8-way associative hash it is ~100%. 5.4. Memory Overhead FQ-CoDel can be implemented with a low memory footprint (less than 64 bytes per queue on 64 bit systems). These are the data structures used in the Linux implementation: Hoeiland-Joergensen, etExpires September 19, 2016 [Page 13] Internet-Draft fq-codel March 2016 struct codel_vars { u32 count; /* number of dropped packets */ u32 lastcount; /* count entry to dropping state */ bool dropping; /* currently dropping? */ u16 rec_inv_sqrt; /* reciprocal sqrt computation */ codel_time_t first_above_time; /* when delay above target */ codel_time_t drop_next; /* next time to drop */ codel_time_t ldelay; /* sojourn time of last dequeued packet */ }; struct fq_codel_flow { struct sk_buff *head; struct sk_buff *tail; struct list_head flowchain; int credits; /* current number of queue credits */ u32 dropped; /* # of drops (or ECN marks) on flow */ struct codel_vars cvars; }; The master table managing all queues looks like this: struct fq_codel_sched_data { struct tcf_proto *filter_list; /* optional external classifier */ struct fq_codel_flow *flows; /* Flows table [flows_cnt] */ u32 *backlogs; /* backlog table [flows_cnt] */ u32 flows_cnt; /* number of flows */ u32 perturbation; /* hash perturbation */ u32 quantum; /* psched_mtu(qdisc_dev(sch)); */ struct codel_params cparams; struct codel_stats cstats; u32 drop_overlimit; u32 new_flow_count; struct list_head new_flows; /* list of new flows */ struct list_head old_flows; /* list of old flows */ }; 5.5. Per-Packet Timestamping The CoDel portion of the algorithm requires per-packet timestamps be stored along with the packet. While this approach works well for software-based routers, it may be impossible to retrofit devices that Hoeiland-Joergensen, etExpires September 19, 2016 [Page 14] Internet-Draft fq-codel March 2016 do most of their processing in silicon and lack space or mechanism for timestamping. Also, while perfect resolution is not needed, timestamp resolution finer than the CoDel target setting is necessary. Furthermore, timestamping functions in the core OS need to be efficient as they are called at least once on each packet enqueue and dequeue. 5.6. Limiting queueing in lower layers When deploying a queue management algorithm such as FQ-CoDel, it is important to ensure that the algorithm actually runs in the right place to control the queue. In particular lower layers of the operating system networking stack can have queues of their own, as can device drivers and hardware. Thus, it is desirable that the queue management algorithm runs as close to the hardware as possible. However, scheduling such complexity at interrupt time is difficult, so a small standing queue between the algorithm and the wire is often needed at higher transmit rates. In Linux, the mechanism to ensure these different needs are balanced is called "Byte Queue Limits" [BQL], which controls the device driver ring buffer (for physical line rates). For cases where this functionality is not available, the queue can be controlled by means of a software rate limiter such as Hierarchical Token Bucket [HTB] or Hierarchical Fair-Service Curve [HFSC]. The Cake algorithm [CAKE] integrates a software rate limiter for this purpose. Other issues with queues at lower layers are described in [CODEL]. 5.7. Other forms of "Fair Queueing" Much of the scheduling portion of FQ-CoDel is derived from DRR and is substantially similar to DRR++. Versions based on Stochastic Fair Queueing [SFQ] have also been produced and tested in ns2. Other forms of Fair Queueing, such as Weighted Fair Queueing [WFQ] or Quick Fair Queueing [QFQ], have not been thoroughly explored, but there's no a priori reason why the round-robin scheduling of FQ-CoDel couldn't be replaced with something else. For a comprehensive discussion of fairness queueing algorithms and their combination with AQM, see [I-D.ietf-aqm-fq-implementation]. 5.8. Differences between CoDel and FQ-CoDel behaviour CoDel can be applied to a single queue system as a straight AQM, where it converges towards an "ideal" drop rate (i.e., one that Hoeiland-Joergensen, etExpires September 19, 2016 [Page 15] Internet-Draft fq-codel March 2016 minimises delay while keeping a high link utilisation), and then optimises around that control point. The scheduling of FQ-CoDel mixes packets of competing flows, which acts to pace bursty flows to better fill the pipe. Additionally, a new flow gets substantial leeway over other flows until CoDel finds an ideal drop rate for it. However, for a new flow that exceeds the configured quantum, more time passes before all of its data is delivered (as packets from it, too, are mixed across the other existing queue-building flows). Thus, FQ-CoDel takes longer (as measured in time) to converge towards an ideal drop rate for a given new flow, but does so within fewer delivered _packets_ from that flow. Finally, the flow isolation FQ-CoDel provides means that the CoDel drop mechanism operates on the flows actually building queues, which results in packets being dropped more accurately from the largest flows than CoDel alone manages. Additionally, flow isolation radically improves the transient behaviour of the network when traffic or link characteristics change (e.g., when new flows start up or the link bandwidth changes); while CoDel itself can take a while to respond, FQ-CoDel reacts almost immediately. 6. Limitations of flow queueing While FQ-CoDel has been shown in many scenarios to offer significant performance gains compared to alternative queue management strategies, there are some scenarios where the scheduling algorithm in particular is not a good fit. This section documents some of the known cases which either may require tweaking the default behaviour, or where alternatives to flow queueing should be considered. 6.1. Fairness between things other than flows In some parts of the network, enforcing flow-level fairness may not be desirable, or some other form of fairness may be more important. An example of this can be an Internet Service Provider that may be more interested in ensuring fairness between customers than between flows. Or a hosting or transit provider that wishes to ensure fairness between connecting Autonomous Systems or networks. Another issue can be that the number of simultaneous flows experienced at a particular link can be too high for flow-based fairness queueing to be effective. Whatever the reason, in a scenario where fairness between flows is not desirable, reconfiguring FQ-CoDel to match on a different characteristic can be a way forward. The implementation in Linux can leverage the packet matching mechanism of the _tc_ subsystem to use Hoeiland-Joergensen, etExpires September 19, 2016 [Page 16] Internet-Draft fq-codel March 2016 any available packet field to partition packets into virtual queues, to for instance match on address or subnet source/destination pairs, application layer characteristics, etc. Furthermore, as commonly deployed today, FQ-CoDel is used with three or more tiers of service classification: priority, best effort and background, based on diffserv markings. Some products do more detailed classification, including deep packet inspection and destination-specific filters to achieve their desired result. 6.2. Flow bunching by opaque encapsulation Where possible, FQ-CoDel will attempt to decapsulate packets before matching on the header fields for the flow hashing. However, for some encapsulation techniques, most notably encrypted VPNs, this is not possible. If several flows are bunched into one such encapsulated tunnel, they will be seen as one flow by the FQ-CoDel algorithm. This means that they will share a queue, and drop behaviour, and so flows inside the encapsulation will not benefit from the implicit prioritisation of FQ-CoDel, but will continue to benefit from the reduced overall queue length from the CoDel algorithm operating on the queue. In addition, when such an encapsulated bunch competes against other flows, it will count as one flow, and not assigned a share of the bandwidth based on how many flows are inside the encapsulation. Depending on the application, this may or may not be desirable behaviour. In cases where it is not, changing FQ-CoDel's matching to not be flow-based (as detailed in the previous subsection above) can be a mitigation. Going forward, having some mechanism for opaque encapsulations to express to the outer layer which flow a packet belongs to, could be a way to mitigate this. Naturally, care needs to be taken when designing such a mechanism to ensure no new privacy and security issues are raised by exposing information from inside the encapsulation to the outside world. Keeping the extra information out-of-band and dropping it before it hits the network could be one way to achieve this. 6.3. Low-priority congestion control algorithms In the presence of queue management schemes that limit latency under load, low-priority congestion control algorithms such as LEDBAT [RFC6817] (or, in general, algorithms that try to voluntarily use up less than their fair share of bandwidth) experiences little added latency when the link is congested. Thus, they lack the signal to back off that added latency previously afforded them. This effect is seen with FQ-CoDel as well as with any effective AQM [GONG2014]. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 17] Internet-Draft fq-codel March 2016 As such, these delay-based algorithms tend to revert to loss-based congestion control, and will consume the fair share of bandwidth afforded to them by the FQ-CoDel scheduler. However, low-priority congestion control mechanisms may be able to take steps to continue to be low priority, for instance by taking into account the vastly reduced level of delay afforded by an AQM, or by using a coupled approach to observing the behaviour of multiple flows. 7. Deployment status and future work The FQ-CoDel algorithm as described in this document has been shipped as part of the Linux kernel since version 3.5, released on the 21st of July, 2012, with the ce_threshold being added in version 4.2. The algorithm has seen widespread testing in a variety of contexts and is configured as the default queueing discipline in a number of mainline Linux distributions (as of this writing at least OpenWRT, Arch Linux and Fedora). We believe it to be a safe default and encourage people running Linux to turn it on: It is a massive improvement over the previous default FIFO queue. Of course there is always room for improvement, and this document has listed some of the known limitations of the algorithm. As such, we encourage further research into algorithm refinements and addressing of limitations. One such effort is undertaken by the bufferbloat community in the form of the Cake queue management scheme [CAKE]. In addition to this we believe the following (non-exhaustive) list of issues to be worthy of further enquiry: o Variations on the flow classification mechanism to fit different notions of flows. For instance, an ISP might want to deploy per- subscriber scheduling, while in other cases several flows can share a 5-tuple, as exemplified by the RTCWEB QoS recommendations [I-D.ietf-tsvwg-rtcweb-qos]. o Interactions between flow queueing and delay-based congestion control algorithms and scavenger protocols. o Other scheduling mechanisms to replace the DRR portion of the algorithm, e.g., QFQ or WFQ. o Sensitivity of parameters, most notably the number of queues and the CoDel parameters. 8. Security Considerations There are no specific security exposures associated with FQ-CoDel that are not also present in current FIFO systems. On the contrary, some vulnerabilities of FIFO systems are reduced with FQ-CoDel (e.g., Hoeiland-Joergensen, etExpires September 19, 2016 [Page 18] Internet-Draft fq-codel March 2016 simple minded packet floods). However, some care is needed in the implementation to ensure this is the case. These are included in the description above, however we reiterate them here: o To prevent packets in the new queues from starving old queues, it is important that when a queue on the list of new queues empties, it is moved to _the end of_ the list of old queues. This is described at the end of Section 4.2. o To prevent an attacker targeting a specific flow for a denial of service attack, the hash that maps packets to queues should not be predictable. To achieve this, FQ-CoDel salts the hash, as described in the beginning of Section 4.1. The size of the salt and the strength of the hash function is obviously a tradeoff between performance and security. The Linux implementation uses a 32 bit random value as the salt and a Jenkins hash function. This makes it possible to achieve high throughput, and we consider it sufficient to ward off the most obvious attacks. o Packet fragments without a layer 4 header can be hashed into different bins than the first fragment with the header intact. This can cause reordering and/or adversely affect the performance of the flow. Keeping state to match the fragments to the beginning of the packet, or simply putting all packet fragments (including the first fragment of each fragmented packet) into the same queue, are two ways to alleviate this. 9. IANA Considerations This document has no actions for IANA. 10. Acknowledgements Our deepest thanks to Kathie Nichols, Van Jacobson, and all the members of the bufferbloat.net effort for all the help on developing and testing the algorithm. In addition, our thanks to Anil Agarwal for his help with getting the hash collision probabilities in this document right. 11. References 11.1. Normative References [I-D.ietf-aqm-codel] Nichols, K., Jacobson, V., McGregor, A., and J. Iyengar, "Controlled Delay Active Queue Management", draft-ietf- aqm-codel-03 (work in progress), March 2016. Hoeiland-Joergensen, etExpires September 19, 2016 [Page 19] Internet-Draft fq-codel March 2016 [I-D.ietf-aqm-fq-implementation] Baker, F. and R. Pan, "On Queuing, Marking, and Dropping", draft-ietf-aqm-fq-implementation-05 (work in progress), November 2015. [I-D.ietf-tcpm-dctcp] Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", draft-ietf-tcpm-dctcp-01 (work in progress), November 2015. [I-D.ietf-tsvwg-rtcweb-qos] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP and other packet markings for WebRTC QoS", draft-ietf- tsvwg-rtcweb-qos-14 (work in progress), March 2016. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, . Hoeiland-Joergensen, etExpires September 19, 2016 [Page 20] Internet-Draft fq-codel March 2016 11.2. Informative References [BLOAT] Gettys, J., "Bufferbloat: Dark buffers in the Internet.", in IEEE Internet Comput. 15, 3, DOI http://dx.doi.org/10.1109/MIC.2011.56, 2011, . [BLOATWEB] "Bufferbloat web site", . [BQL] Herbert, T., "Network Byte Queue Limits", August 2011, . [CAKE] "Cake comprehensive queue management system", . [CODEL] Nichols, K. and V. Jacobson, "Controlling Queue Delay", July 2012, . [DRR] Shreedhar, M. and G. Varghese, "Efficient Fair Queueing Using Deficit Round Robin", in IEEE/ACM Trans. Netw. 4, 3, June 1996, . [DRRPP] MacGregor, M. and W. Shi, "Deficits for Bursty Latency- critical Flows: DRR++", in Proceedings IEEE International Conference on Networks 2000 (ICON 2000), 2000, . [GONG2014] Gong, Y., Rossi, D., Testa, C., Valenti, S., and D. Taht, "Fighting the bufferbloat: on the coexistence of AQM and low priority congestion control", in 2013 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), July 2014, . [HFSC] Stoica, I., Zhang, H., and T. Eugene, "Hierarchical fair- service curve", in Sigcomm 1997 proceedings, 1997, . [HTB] "Hierarchical Token Bucket", . Hoeiland-Joergensen, etExpires September 19, 2016 [Page 21] Internet-Draft fq-codel March 2016 [JENKINS] Jenkins, B., "A Hash Function for Hash Table Lookup", 1996, . [LINUXSRC] "Current FQ-CoDel Linux source code", . [NS2] "NS2 web site", . [NS3] "NS3 web site", . [QFQ] Checconi, F., Rizzo, L., and P. Valente, "QFQ: Efficient packet scheduling with tight guarantees", in IEEE/ACM Transactions on Networking (TON), 2013, . [SFQ] McKenney, P., "Stochastic fairness queueing", published as technical report, 2002, . [SQF] Bonald, T., Muscariello, L., and N. Ostallo, "On the impact of TCP and per-flow scheduling on Internet Performance", in IEEE/ACM transactions on Networking, April 2012, . [WFQ] Demers, A., Keshav, S., and S. Shenker, "Analysis and simulation of a fair queueing algorithm", in SIGCOMM Comput. Commun. Rev., September 1989, . Authors' Addresses Toke Hoeiland-Joergensen Karlstad University Dept. of Computer Science Karlstad 65188 Sweden Email: toke.hoiland-jorgensen@kau.se Hoeiland-Joergensen, etExpires September 19, 2016 [Page 22] Internet-Draft fq-codel March 2016 Paul McKenney IBM Linux Technology Center 1385 NW Amberglen Parkway Hillsboro, OR 97006 USA Email: paulmck@linux.vnet.ibm.com URI: http://www2.rdrop.com/~paulmck/ Dave Taht Teklibre 2104 W First street Apt 2002 FT Myers, FL 33901 USA Email: dave.taht@gmail.com URI: http://www.teklibre.com/ Jim Gettys 21 Oak Knoll Road Carlisle, MA 993 USA Email: jg@freedesktop.org URI: https://en.wikipedia.org/wiki/Jim_Gettys Eric Dumazet Google, Inc. 1600 Amphitheater Pkwy Mountain View, CA 94043 USA Email: edumazet@gmail.com Hoeiland-Joergensen, etExpires September 19, 2016 [Page 23] ./draft-ietf-nfsv4-scsi-layout-10.txt0000664000764400076440000021431613021475266016702 0ustar iustyiusty NFSv4 C. Hellwig Internet-Draft Intended status: Standards Track December 05, 2016 Expires: June 8, 2017 Parallel NFS (pNFS) SCSI Layout draft-ietf-nfsv4-scsi-layout-10.txt Abstract The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The SCSI Layout Type is defined in this document as an extension to pNFS to allow the use SCSI based block storage devices. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 8, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hellwig Expires June 8, 2017 [Page 1] Internet-Draft pNFS SCSI Layout December 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.2. General Definitions . . . . . . . . . . . . . . . . . . . 4 1.3. Code Components Licensing Notice . . . . . . . . . . . . 4 1.4. XDR Description . . . . . . . . . . . . . . . . . . . . . 5 2. SCSI Layout Description . . . . . . . . . . . . . . . . . . . 6 2.1. Background and Architecture . . . . . . . . . . . . . . . 6 2.2. layouttype4 . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. GETDEVICEINFO . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Volume Identification . . . . . . . . . . . . . . . . 8 2.3.2. Volume Topology . . . . . . . . . . . . . . . . . . . 9 2.4. Data Structures: Extents and Extent Lists . . . . . . . . 12 2.4.1. Layout Requests and Extent Lists . . . . . . . . . . 14 2.4.2. Layout Commits . . . . . . . . . . . . . . . . . . . 15 2.4.3. Layout Returns . . . . . . . . . . . . . . . . . . . 16 2.4.4. Layout Revocation . . . . . . . . . . . . . . . . . . 16 2.4.5. Client Copy-on-Write Processing . . . . . . . . . . . 17 2.4.6. Extents are Permissions . . . . . . . . . . . . . . . 18 2.4.7. Partial-Block Updates . . . . . . . . . . . . . . . . 19 2.4.8. End-of-file Processing . . . . . . . . . . . . . . . 19 2.4.9. Layout Hints . . . . . . . . . . . . . . . . . . . . 20 2.4.10. Client Fencing . . . . . . . . . . . . . . . . . . . 20 2.5. Crash Recovery Issues . . . . . . . . . . . . . . . . . . 22 2.6. Recalling Resources: CB_RECALL_ANY . . . . . . . . . . . 22 2.7. Transient and Permanent Errors . . . . . . . . . . . . . 23 2.8. Volatile write caches . . . . . . . . . . . . . . . . . . 23 3. Enforcing NFSv4 Semantics . . . . . . . . . . . . . . . . . . 24 3.1. Use of Open Stateids . . . . . . . . . . . . . . . . . . 24 3.2. Enforcing Security Restrictions . . . . . . . . . . . . . 25 3.3. Enforcing Locking Restrictions . . . . . . . . . . . . . 25 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Normative References . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Figure 1 shows the overall architecture of a Parallel NFS (pNFS) system: Hellwig Expires June 8, 2017 [Page 2] Internet-Draft pNFS SCSI Layout December 2016 +-----------+ |+-----------+ +-----------+ ||+-----------+ | | ||| | NFSv4.1 + pNFS | | +|| Clients |<------------------------------>| Server | +| | | | +-----------+ | | ||| +-----------+ ||| | ||| | ||| Storage +-----------+ | ||| Protocol |+-----------+ | ||+----------------||+-----------+ Control | |+-----------------||| | Protocol| +------------------+|| Storage |------------+ +| Systems | +-----------+ Figure 1 The overall approach is that pNFS-enhanced clients obtain sufficient information from the server to enable them to access the underlying storage (on the storage systems) directly. See the Section 12 of [RFC5661] for more details. This document is concerned with access from pNFS clients to storage devices over block storage protocols based on the the SCSI Architecture Model ([SAM-5]), e.g., Fibre Channel Protocol (FCP) for Fibre Channel, Internet SCSI (iSCSI) or Serial Attached SCSI (SAS). pNFS SCSI layout requires block based SCSI command sets, for example SCSI Block Commands ([SBC3]). While SCSI command set for non-block based access exist these are not supported by the SCSI layout type, and all future references to SCSI storage devices will imply a block based SCSI command set. The Server to Storage System protocol, called the "Control Protocol", is not of concern for interoperability, although it will typically be the same SCSI based storage protocol. This document is based on [RFC5663] and makes changes to the block layout type to provide a better pNFS layout protocol for SCSI based storage devices. Despite these changes, [RFC5663] remains the defining document for the existing block layout type. pNFS Block Disk Protection [RFC6688] is unnecessary in the context of the SCSI layout type because the new layout type provides mandatory disk access protection as part of the layout type definition. In contrast to [RFC5663], this document uses SCSI protocol features to provide reliable fencing by using SCSI Persistent Reservations, and it can provide reliable and efficient device discovery by using SCSI device identifiers instead of having to rely on probing all devices Hellwig Expires June 8, 2017 [Page 3] Internet-Draft pNFS SCSI Layout December 2016 potentially attached to a client. This new layout type also optimizes the I/O path by reducing the size of the LAYOUTCOMMIT payload. The above two paragraphs summarize the major functional differences from [RFC5663]. There are other minor differences, e.g., the "base" volume type in this specification is used instead of the "simple" volume type in [RFC5663], but there are no significant differences in the data structures that describe the volume topology above this level Section 2.3.2 or in the data structures that describe extents Section 2.4. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. General Definitions The following definitions are provided for the purpose of providing an appropriate context for the reader. Byte This document defines a byte as an octet, i.e., a datum exactly 8 bits in length. Client The "client" is the entity that accesses the NFS server's resources. The client may be an application that contains the logic to access the NFS server directly. The client may also be the traditional operating system client that provides remote file system services for a set of applications. Server The "server" is the entity responsible for coordinating client access to a set of file systems and is identified by a server owner. metadata server (MDS) The metadata server is a pNFS server which provides metadata information for a file system object. It also is responsible for generating layouts for file system objects. Note that the MDS is also responsible for directory-based operations. 1.3. Code Components Licensing Notice The external data representation (XDR) description and scripts for extracting the XDR description are Code Components as described in Section 4 of "Legal Provisions Relating to IETF Documents" [LEGAL]. Hellwig Expires June 8, 2017 [Page 4] Internet-Draft pNFS SCSI Layout December 2016 These Code Components are licensed according to the terms of Section 4 of "Legal Provisions Relating to IETF Documents". 1.4. XDR Description This document contains the XDR [RFC4506] description of the NFSv4.1 SCSI layout protocol. The XDR description is embedded in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The reader can feed this document into the following shell script to produce the machine readable XDR description of the NFSv4.1 SCSI layout: #!/bin/sh grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??' That is, if the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do: sh extract.sh < spec.txt > scsi_prot.x The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///". The embedded XDR file header follows. Subsequent XDR descriptions, with the sentinel sequence are embedded throughout the document. Note that the XDR code contained in this document depends on types from the NFSv4.1 nfs4_prot.x file [RFC5662]. This includes both nfs types that end with a 4, such as offset4, length4, etc., as well as more generic types such as uint32_t and uint64_t. /// /* /// * This code was derived from RFCTBD10 /// * Please reproduce this note if possible. /// */ /// /* /// * Copyright (c) 2010,2015 IETF Trust and the persons /// * identified as the document authors. All rights reserved. /// * /// * Redistribution and use in source and binary forms, with /// * or without modification, are permitted provided that the /// * following conditions are met: /// * /// * - Redistributions of source code must retain the above /// * copyright notice, this list of conditions and the /// * following disclaimer. /// * Hellwig Expires June 8, 2017 [Page 5] Internet-Draft pNFS SCSI Layout December 2016 /// * - Redistributions in binary form must reproduce the above /// * copyright notice, this list of conditions and the /// * following disclaimer in the documentation and/or other /// * materials provided with the distribution. /// * /// * - Neither the name of Internet Society, IETF or IETF /// * Trust, nor the names of specific contributors, may be /// * used to endorse or promote products derived from this /// * software without specific prior written permission. /// * /// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS /// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED /// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE /// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS /// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO /// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE /// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, /// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT /// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR /// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS /// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF /// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, /// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING /// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF /// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. /// */ /// /// /* /// * nfs4_scsi_layout_prot.x /// */ /// /// %#include "nfsv41.h" /// 2. SCSI Layout Description 2.1. Background and Architecture The fundamental storage model supported by SCSI storage devices is a Logical Unit (LU) consisting of a sequential series of fixed-size blocks. Logical units used as devices for NFS SCSI layouts, and the SCSI initiators used for the pNFS Metadata Server and clients MUST support SCSI persistent reservations as defined in [SPC4]. A pNFS layout for this SCSI class of storage is responsible for mapping from an NFS file (or portion of a file) to the blocks of storage volumes that contain the file. The blocks are expressed as extents with 64-bit offsets and lengths using the existing NFSv4 Hellwig Expires June 8, 2017 [Page 6] Internet-Draft pNFS SCSI Layout December 2016 offset4 and length4 types. Clients MUST be able to perform I/O to the block extents without affecting additional areas of storage (especially important for writes); therefore, extents MUST be aligned to logical block size boundaries of the underlying logical units (typically 512 or 4096 bytes). For complex volume topologies the serves MUST ensure extents are aligned to the logical block size boundaries of the larges logical block size in the volume topology. The pNFS operation for requesting a layout (LAYOUTGET) includes the "layoutiomode4 loga_iomode" argument, which indicates whether the requested layout is for read-only use or read-write use. A read-only layout may contain holes that are read as zero, whereas a read-write layout will contain allocated, but un-initialized storage in those holes (read as zero, can be written by client). This document also supports client participation in copy-on-write (e.g., for file systems with snapshots) by providing both read-only and un- initialized storage for the same range in a layout. Reads are initially performed on the read-only storage, with writes going to the un-initialized storage. After the first write that initializes the un-initialized storage, all reads are performed to that now- initialized writable storage, and the corresponding read-only storage is no longer used. The SCSI layout solution expands the security responsibilities of the pNFS clients, and there are a number of environments where the mandatory to implement security properties for NFS cannot be satisfied. The additional security responsibilities of the client follow, and a full discussion is present in Section 4, "Security Considerations". o Typically, SCSI storage devices provide access control mechanisms (e.g., Logical Unit Number (LUN) mapping and/or masking), which operate at the granularity of individual hosts, not individual blocks. For this reason, block-based protection must be provided by the client software. o Similarly, SCSI storage devices typically are not able to validate NFS locks that apply to file regions. For instance, if a file is covered by a mandatory read-only lock, the server can ensure that only readable layouts for the file are granted to pNFS clients. However, it is up to each pNFS client to ensure that the readable layout is used only to service read requests, and not to allow writes to the existing parts of the file. Since SCSI storage devices are generally not capable of enforcing such file-based security, in environments where pNFS clients cannot be trusted to enforce such policies, pNFS SCSI layouts MUST NOT be used. Hellwig Expires June 8, 2017 [Page 7] Internet-Draft pNFS SCSI Layout December 2016 2.2. layouttype4 The layout4 type defined in [RFC5662] is extended with a new value as follows: enum layouttype4 { LAYOUT4_NFSV4_1_FILES = 1, LAYOUT4_OSD2_OBJECTS = 2, LAYOUT4_BLOCK_VOLUME = 3, LAYOUT4_SCSI = 0x80000005 [[RFC Editor: please modify the LAYOUT4_SCSI to be the layouttype assigned by IANA]] }; This document defines structure associated with the layouttype4 value LAYOUT4_SCSI. [RFC5661] specifies the loc_body structure as an XDR type "opaque". The opaque layout is uninterpreted by the generic pNFS client layers, but obviously must be interpreted by the Layout Type implementation. 2.3. GETDEVICEINFO 2.3.1. Volume Identification SCSI targets implementing [SPC4] export unique LU names for each LU through the Device Identification VPD page (page code 0x83), which can be obtained using the INQUIRY command with the EVPD bit set to one. This document uses a subset of this information to identify LUs backing pNFS SCSI layouts. Device Identification VPD page descriptors used to identify LUs for use with pNFS SCSI layouts must adhere to the following restrictions: 1. The "ASSOCIATION" MUST be set to 0 (The DESIGNATOR field is associated with the addressed logical unit). 2. The "DESIGNATOR TYPE" MUST be set to one of four values that are required for the mandatory logical unit name in section 7.7.3 of [SPC4], as explicitly listed in the "pnfs_scsi_designator_type" enumeration: PS_DESIGNATOR_T10 T10 vendor ID based PS_DESIGNATOR_EUI64 EUI-64-based PS_DESIGNATOR_NAA NAA PS_DESIGNATOR_NAME SCSI name string Hellwig Expires June 8, 2017 [Page 8] Internet-Draft pNFS SCSI Layout December 2016 Any other association or designator type MUST NOT be used. Use of T10 vendor IDs is discouraged when one of the other types can be used. The "CODE SET" VPD page field is stored in the "sbv_code_set" field of the "pnfs_scsi_base_volume_info4" structure, the "DESIGNATOR TYPE" is stored in "sbv_designator_type", and the DESIGNATOR is stored in "sbv_designator". Due to the use of a XDR array the "DESIGNATOR LENGTH" field does not need to be set separately. Only certain combinations of "sbv_code_set" and "sbv_designator_type" are valid, please refer to [SPC4] for details, and note that ASCII MAY be used as the code set for UTF-8 text that contains only printable ASCII characters. Note that a Device Identification VPD page MAY contain multiple descriptors with the same association, code set and designator type. NFS clients thus MUST check all the descriptors for a possible match to "sbv_code_set", "sbv_designator_type" and "sbv_designator". Storage devices such as storage arrays can have multiple physical network interfaces that need not be connected to a common network, resulting in a pNFS client having simultaneous multipath access to the same storage volumes via different ports on different networks. Selection of one or multiple ports to access the storage device is left up to the client. Additionally the server returns a Persistent Reservation key in the "sbv_pr_key" field. See Section 2.4.10 for more details on the use of Persistent Reservations. 2.3.2. Volume Topology The pNFS SCSI layout volume topology is expressed in terms of the volume types described below. The individual components of the topology are contained in an array and components MAY refer to other components by using array indices. /// enum pnfs_scsi_volume_type4 { /// PNFS_SCSI_VOLUME_SLICE = 1, /* volume is a slice of /// another volume */ /// PNFS_SCSI_VOLUME_CONCAT = 2, /* volume is a /// concatenation of /// multiple volumes */ /// PNFS_SCSI_VOLUME_STRIPE = 3 /* volume is striped across /// multiple volumes */ /// PNFS_SCSI_VOLUME_BASE = 4, /* volume maps to a single /// LU */ /// }; /// Hellwig Expires June 8, 2017 [Page 9] Internet-Draft pNFS SCSI Layout December 2016 /// /* /// * Code sets from SPC-4. /// */ /// enum pnfs_scsi_code_set { /// PS_CODE_SET_BINARY = 1, /// PS_CODE_SET_ASCII = 2, /// PS_CODE_SET_UTF8 = 3 /// }; /// /// /* /// * Designator types from taken from SPC-4. /// * /// * Other values are allocated in SPC-4, but not mandatory to /// * implement or aren't Logical Unit names. /// */ /// enum pnfs_scsi_designator_type { /// PS_DESIGNATOR_T10 = 1, /// PS_DESIGNATOR_EUI64 = 2, /// PS_DESIGNATOR_NAA = 3, /// PS_DESIGNATOR_NAME = 8 /// }; /// /// /* /// * Logical Unit name + reservation key. /// */ /// struct pnfs_scsi_base_volume_info4 { /// pnfs_scsi_code_set sbv_code_set; /// pnfs_scsi_designator_type sbv_designator_type; /// opaque sbv_designator<>; /// uint64_t sbv_pr_key; /// }; /// /// struct pnfs_scsi_slice_volume_info4 { /// offset4 ssv_start; /* offset of the start of /// the slice in bytes */ /// length4 ssv_length; /* length of slice in /// bytes */ /// uint32_t ssv_volume; /* array index of sliced /// volume */ /// }; /// /// /// struct pnfs_scsi_concat_volume_info4 { /// uint32_t scv_volumes<>; /* array indices of volumes /// which are concatenated */ /// }; Hellwig Expires June 8, 2017 [Page 10] Internet-Draft pNFS SCSI Layout December 2016 /// /// struct pnfs_scsi_stripe_volume_info4 { /// length4 ssv_stripe_unit; /* size of stripe in bytes */ /// uint32_t ssv_volumes<>; /* array indices of /// volumes which are striped /// across -- MUST be same /// size */ /// }; /// /// union pnfs_scsi_volume4 switch (pnfs_scsi_volume_type4 type) { /// case PNFS_SCSI_VOLUME_BASE: /// pnfs_scsi_base_volume_info4 sv_simple_info; /// case PNFS_SCSI_VOLUME_SLICE: /// pnfs_scsi_slice_volume_info4 sv_slice_info; /// case PNFS_SCSI_VOLUME_CONCAT: /// pnfs_scsi_concat_volume_info4 sv_concat_info; /// case PNFS_SCSI_VOLUME_STRIPE: /// pnfs_scsi_stripe_volume_info4 sv_stripe_info; /// }; /// /// /* SCSI layout-specific type for da_addr_body */ /// struct pnfs_scsi_deviceaddr4 { /// pnfs_scsi_volume4 sda_volumes<>; /* array of volumes */ /// }; /// The "pnfs_scsi_deviceaddr4" data structure is a structure that allows arbitrarily complex nested volume structures to be encoded. The types of aggregations that are allowed are stripes, concatenations, and slices. Note that the volume topology expressed in the pnfs_scsi_deviceaddr4 data structure will always resolve to a set of pnfs_scsi_volume_type4 PNFS_SCSI_VOLUME_BASE. The array of volumes is ordered such that the root of the volume hierarchy is the last element of the array. Concat, slice, and stripe volumes MUST refer to volumes defined by lower indexed elements of the array. The "pnfs_scsi_device_addr4" data structure is returned by the server as the storage-protocol-specific opaque field da_addr_body in the "device_addr4" structure by a successful GETDEVICEINFO operation [RFC5661]. As noted above, all device_addr4 structures eventually resolve to a set of volumes of type PNFS_SCSI_VOLUME_BASE. Complicated volume hierarchies may be composed of dozens of volumes each with several components; thus, the device address may require several kilobytes. The client SHOULD be prepared to allocate a large buffer to contain Hellwig Expires June 8, 2017 [Page 11] Internet-Draft pNFS SCSI Layout December 2016 the result. In the case of the server returning NFS4ERR_TOOSMALL, the client SHOULD allocate a buffer of at least gdir_mincount_bytes to contain the expected result and retry the GETDEVICEINFO request. 2.4. Data Structures: Extents and Extent Lists A pNFS SCSI layout is a list of extents within a flat array of data blocks in a volume. The details of the volume topology can be determined by using the GETDEVICEINFO operation. The SCSI layout describes the individual block extents on the volume that make up the file. The offsets and length contained in an extent are specified in units of bytes. /// enum pnfs_scsi_extent_state4 { /// PNFS_SCSI_READ_WRITE_DATA = 0, /* the data located by /// this extent is valid /// for reading and /// writing. */ /// PNFS_SCSI_READ_DATA = 1, /* the data located by this /// extent is valid for /// reading only; it may not /// be written. */ /// PNFS_SCSI_INVALID_DATA = 2, /* the location is valid; the /// data is invalid. It is a /// newly (pre-) allocated /// extent. The client MUST /// not read from this /// space */ /// PNFS_SCSI_NONE_DATA = 3 /* the location is invalid. /// It is a hole in the file. /// The client MUST NOT read /// from or write to this /// space */ /// }; Hellwig Expires June 8, 2017 [Page 12] Internet-Draft pNFS SCSI Layout December 2016 /// /// struct pnfs_scsi_extent4 { /// deviceid4 se_vol_id; /* id of the volume on /// which extent of file is /// stored. */ /// offset4 se_file_offset; /* starting byte offset /// in the file */ /// length4 se_length; /* size in bytes of the /// extent */ /// offset4 se_storage_offset; /* starting byte offset /// in the volume */ /// pnfs_scsi_extent_state4 se_state; /// /* state of this extent */ /// }; /// /// /* SCSI layout-specific type for loc_body */ /// struct pnfs_scsi_layout4 { /// pnfs_scsi_extent4 sl_extents<>; /// /* extents which make up this /// layout. */ /// }; /// The SCSI layout consists of a list of extents that map the regions of the file to locations on a volume. The "se_storage_offset" field within each extent identifies a location on the volume specified by the "se_vol_id" field in the extent. The se_vol_id itself is shorthand for the whole topology of the volume on which the file is stored. The client is responsible for translating this volume- relative offset into an offset on the appropriate underlying SCSI LU. Each extent maps a region of the file onto a portion of the specified LU. The se_file_offset, se_length, and se_state fields for an extent returned from the server are valid for all extents. In contrast, the interpretation of the se_storage_offset field depends on the value of se_state as follows (in increasing order): PNFS_SCSI_READ_WRITE_DATA means that se_storage_offset is valid, and points to valid/initialized data that can be read and written. PNFS_SCSI_READ_DATA means that se_storage_offset is valid and points to valid/initialized data that can only be read. Write operations are prohibited. PNFS_SCSI_INVALID_DATA means that se_storage_offset is valid, but points to invalid un-initialized data. This data MUST not be read from the disk until it has been initialized. A read request for a Hellwig Expires June 8, 2017 [Page 13] Internet-Draft pNFS SCSI Layout December 2016 PNFS_SCSI_INVALID_DATA extent MUST fill the user buffer with zeros, unless the extent is covered by a PNFS_SCSI_READ_DATA extent of a copy-on-write file system. Write requests MUST write whole server-sized blocks to the disk; bytes not initialized by the user MUST be set to zero. Any write to storage in a PNFS_SCSI_INVALID_DATA extent changes the written portion of the extent to PNFS_SCSI_READ_WRITE_DATA; the pNFS client is responsible for reporting this change via LAYOUTCOMMIT. PNFS_SCSI_NONE_DATA means that se_storage_offset is not valid, and this extent MAY not be used to satisfy write requests. Read requests MAY be satisfied by zero-filling as for PNFS_SCSI_INVALID_DATA. PNFS_SCSI_NONE_DATA extents MAY be returned by requests for readable extents; they are never returned if the request was for a writable extent. An extent list contains all relevant extents in increasing order of the se_file_offset of each extent; any ties are broken by increasing order of the extent state (se_state). 2.4.1. Layout Requests and Extent Lists Each request for a layout specifies at least three parameters: file offset, desired size, and minimum size. If the status of a request indicates success, the extent list returned MUST meet the following criteria: o A request for a readable (but not writable) layout MUST return either PNFS_SCSI_READ_DATA or PNFS_SCSI_NONE_DATA extents. It SHALL NOT return PNFS_SCSI_INVALID_DATA or PNFS_SCSI_READ_WRITE_DATA extents. o A request for a writable layout MUST return PNFS_SCSI_READ_WRITE_DATA or PNFS_SCSI_INVALID_DATA extents, and it MAY return addition PNFS_SCSI_READ_DATA extents for ranges covered by PNFS_SCSI_INVALID_DATA extents to allow client side copy-on-write operations. A request for a writable layout SHALL NOT return PNFS_SCSI_NONE_DATA extents. o The first extent in the list MUST contain the requested starting offset. o The total size of extents within the requested range MUST cover at least the minimum size. One exception is allowed: the total size MAY be smaller if only readable extents were requested and EOF is encountered. Hellwig Expires June 8, 2017 [Page 14] Internet-Draft pNFS SCSI Layout December 2016 o Extents in the extent list MUST be logically contiguous for a read-only layout. For a read-write layout, the set of writable extents (i.e., excluding PNFS_SCSI_READ_DATA extents) MUST be logically contiguous. Every PNFS_SCSI_READ_DATA extent in a read- write layout MUST be covered by one or more PNFS_SCSI_INVALID_DATA extents. This overlap of PNFS_SCSI_READ_DATA and PNFS_SCSI_INVALID_DATA extents is the only permitted extent overlap. o Extents MUST be ordered in the list by starting offset, with PNFS_SCSI_READ_DATA extents preceding PNFS_SCSI_INVALID_DATA extents in the case of equal se_file_offsets. According to [RFC5661], if the minimum requested size, loga_minlength, is zero, this is an indication to the metadata server that the client desires any layout at offset loga_offset or less that the metadata server has "readily available". Given the lack of a clear definition of this phrase, in the context of the SCSI layout type, when loga_minlength is zero, the metadata server SHOULD: o when processing requests for readable layouts, return all such, even if some extents are in the PNFS_SCSI_NONE_DATA state. o when processing requests for writable layouts, return extents which can be returned in the PNFS_SCSI_READ_WRITE_DATA state. 2.4.2. Layout Commits /// /// /* SCSI layout-specific type for lou_body */ /// /// struct pnfs_scsi_range4 { /// offset4 sr_file_offset; /* starting byte offset /// in the file */ /// length4 sr_length; /* size in bytes */ /// }; /// /// struct pnfs_scsi_layoutupdate4 { /// pnfs_scsi_range4 slu_commit_list<>; /// /* list of extents which /// * now contain valid data. /// */ /// }; The "pnfs_scsi_layoutupdate4" structure is used by the client as the SCSI layout-specific argument in a LAYOUTCOMMIT operation. The "slu_commit_list" field is a list covering regions of the file layout that were previously in the PNFS_SCSI_INVALID_DATA state, but have Hellwig Expires June 8, 2017 [Page 15] Internet-Draft pNFS SCSI Layout December 2016 been written by the client and SHOULD now be considered in the PNFS_SCSI_READ_WRITE_DATA state. The extents in the commit list MUST be disjoint and MUST be sorted by sr_file_offset. Implementors should be aware that a server MAY be unable to commit regions at a granularity smaller than a file-system block (typically 4 KB or 8 KB). As noted above, the block-size that the server uses is available as an NFSv4 attribute, and any extents included in the "slu_commit_list" MUST be aligned to this granularity and have a size that is a multiple of this granularity. Since the block in question is in state PNFS_SCSI_INVALID_DATA, byte ranges not written SHOULD be filled with zeros. This applies even if it appears that the area being written is beyond what the client believes to be the end of file. 2.4.3. Layout Returns A LAYOUTRETURN operation represents an explicit release of resources by the client. This MAY be done in response to a CB_LAYOUTRECALL or before any recall, in order to avoid a future CB_LAYOUTRECALL. When the LAYOUTRETURN operation specifies a LAYOUTRETURN4_FILE return type, then the layoutreturn_file4 data structure specifies the region of the file layout that is no longer needed by the client. The LAYOUTRETURN operation is done without any SCSI layout specific data. The opaque "lrf_body" field of the "layoutreturn_file4" data structure MUST have length zero. 2.4.4. Layout Revocation Layouts MAY be unilaterally revoked by the server, due to the client's lease time expiring, or the client failing to return a layout which has been recalled in a timely manner. For the SCSI layout type this is accomplished by fencing off the client from access to storage as described in Section 2.4.10. When this is done, it is necessary that all I/Os issued by the fenced-off client be rejected by the storage This includes any in-flight I/Os that the client issued before the layout was revoked. Note, that the granularity of this operation can only be at the host/ LU level. Thus, if one of a client's layouts is unilaterally revoked by the server, it will effectively render useless *all* of the client's layouts for files located on the storage units comprising the volume. This may render useless the client's layouts for files in other file systems. See Section 2.4.10.5 for a discussion of recovery from from fencing. Hellwig Expires June 8, 2017 [Page 16] Internet-Draft pNFS SCSI Layout December 2016 2.4.5. Client Copy-on-Write Processing Copy-on-write is a mechanism used to support file and/or file system snapshots. When writing to unaligned regions, or to regions smaller than a file system block, the writer MUST copy the portions of the original file data to a new location on disk. This behavior can either be implemented on the client or the server. The paragraphs below describe how a pNFS SCSI layout client implements access to a file that requires copy-on-write semantics. Distinguishing the PNFS_SCSI_READ_WRITE_DATA and PNFS_SCSI_READ_DATA extent types in combination with the allowed overlap of PNFS_SCSI_READ_DATA extents with PNFS_SCSI_INVALID_DATA extents allows copy-on-write processing to be done by pNFS clients. In classic NFS, this operation would be done by the server. Since pNFS enables clients to do direct block access, it is useful for clients to participate in copy-on-write operations. All SCSI pNFS clients MUST support this copy-on-write processing. When a client wishes to write data covered by a PNFS_SCSI_READ_DATA extent, it MUST have requested a writable layout from the server; that layout will contain PNFS_SCSI_INVALID_DATA extents to cover all the data ranges of that layout's PNFS_SCSI_READ_DATA extents. More precisely, for any se_file_offset range covered by one or more PNFS_SCSI_READ_DATA extents in a writable layout, the server MUST include one or more PNFS_SCSI_INVALID_DATA extents in the layout that cover the same se_file_offset range. When performing a write to such an area of a layout, the client MUST effectively copy the data from the PNFS_SCSI_READ_DATA extent for any partial blocks of se_file_offset and range, merge in the changes to be written, and write the result to the PNFS_SCSI_INVALID_DATA extent for the blocks for that se_file_offset and range. That is, if entire blocks of data are to be overwritten by an operation, the corresponding PNFS_SCSI_READ_DATA blocks need not be fetched, but any partial- block writes MUST be merged with data fetched via PNFS_SCSI_READ_DATA extents before storing the result via PNFS_SCSI_INVALID_DATA extents. For the purposes of this discussion, "entire blocks" and "partial blocks" refer to the server's file-system block size. Storing of data in a PNFS_SCSI_INVALID_DATA extent converts the written portion of the PNFS_SCSI_INVALID_DATA extent to a PNFS_SCSI_READ_WRITE_DATA extent; all subsequent reads MUST be performed from this extent; the corresponding portion of the PNFS_SCSI_READ_DATA extent MUST NOT be used after storing data in a PNFS_SCSI_INVALID_DATA extent. If a client writes only a portion of an extent, the extent MAY be split at block aligned boundaries. When a client wishes to write data to a PNFS_SCSI_INVALID_DATA extent that is not covered by a PNFS_SCSI_READ_DATA extent, it MUST treat Hellwig Expires June 8, 2017 [Page 17] Internet-Draft pNFS SCSI Layout December 2016 this write identically to a write to a file not involved with copy- on-write semantics. Thus, data MUST be written in at least block- sized increments, aligned to multiples of block-sized offsets, and unwritten portions of blocks MUST be zero filled. 2.4.6. Extents are Permissions Layout extents returned to pNFS clients grant permission to read or write; PNFS_SCSI_READ_DATA and PNFS_SCSI_NONE_DATA are read-only (PNFS_SCSI_NONE_DATA reads as zeroes), PNFS_SCSI_READ_WRITE_DATA and PNFS_SCSI_INVALID_DATA are read/write, (PNFS_SCSI_INVALID_DATA reads as zeros, any write converts it to PNFS_SCSI_READ_WRITE_DATA). This is the only means a client has of obtaining permission to perform direct I/O to storage devices; a pNFS client MUST NOT perform direct I/O operations that are not permitted by an extent held by the client. Client adherence to this rule places the pNFS server in control of potentially conflicting storage device operations, enabling the server to determine what does conflict and how to avoid conflicts by granting and recalling extents to/from clients. If a client makes a layout request that conflicts with an existing layout delegation, the request will be rejected with the error NFS4ERR_LAYOUTTRYLATER. This client is then expected to retry the request after a short interval. During this interval, the server SHOULD recall the conflicting portion of the layout delegation from the client that currently holds it. This reject-and-retry approach does not prevent client starvation when there is contention for the layout of a particular file. For this reason, a pNFS server SHOULD implement a mechanism to prevent starvation. One possibility is that the server can maintain a queue of rejected layout requests. Each new layout request can be checked to see if it conflicts with a previous rejected request, and if so, the newer request can be rejected. Once the original requesting client retries its request, its entry in the rejected request queue can be cleared, or the entry in the rejected request queue can be removed when it reaches a certain age. NFSv4 supports mandatory locks and share reservations. These are mechanisms that clients can use to restrict the set of I/O operations that are permissible to other clients. Since all I/O operations ultimately arrive at the NFSv4 server for processing, the server is in a position to enforce these restrictions. However, with pNFS layouts, I/Os will be issued from the clients that hold the layouts directly to the storage devices that host the data. These devices have no knowledge of files, mandatory locks, or share reservations, and are not in a position to enforce such restrictions. For this reason the NFSv4 server MUST NOT grant layouts that conflict with mandatory locks or share reservations. Further, if a conflicting Hellwig Expires June 8, 2017 [Page 18] Internet-Draft pNFS SCSI Layout December 2016 mandatory lock request or a conflicting open request arrives at the server, the server MUST recall the part of the layout in conflict with the request before granting the request. 2.4.7. Partial-Block Updates SCSI storage devices do not provide byte granularity access and can only perform read and write operations atomically on a block granularity. WRITES to SCSI storage devices thus require read- modify-write cycles to write data smaller than the block size or which is otherwise not block-aligned. Write operations from multiple clients to the same block can thus lead to data corruption even if the byte range written by the applications does not overlap. When there are multiple clients who wish to access the same block, a pNFS server MUST avoid these conflicts by implementing a concurrency control policy of single writer XOR multiple readers for a given data block. 2.4.8. End-of-file Processing The end-of-file location can be changed in two ways: implicitly as the result of a WRITE or LAYOUTCOMMIT beyond the current end-of-file, or explicitly as the result of a SETATTR request. Typically, when a file is truncated by an NFSv4 client via the SETATTR call, the server frees any disk blocks belonging to the file that are beyond the new end-of-file byte, and MUST write zeros to the portion of the new end- of-file block beyond the new end-of-file byte. These actions render any pNFS layouts that refer to the blocks that are freed or written semantically invalid. Therefore, the server MUST recall from clients the portions of any pNFS layouts that refer to blocks that will be freed or written by the server before effecting the file truncation. These recalls may take time to complete; as explained in [RFC5661], if the server cannot respond to the client SETATTR request in a reasonable amount of time, it SHOULD reply to the client with the error NFS4ERR_DELAY. Blocks in the PNFS_SCSI_INVALID_DATA state that lie beyond the new end-of-file block present a special case. The server has reserved these blocks for use by a pNFS client with a writable layout for the file, but the client has yet to commit the blocks, and they are not yet a part of the file mapping on disk. The server MAY free these blocks while processing the SETATTR request. If so, the server MUST recall any layouts from pNFS clients that refer to the blocks before processing the truncate. If the server does not free the PNFS_SCSI_INVALID_DATA blocks while processing the SETATTR request, it need not recall layouts that refer only to the PNFS_SCSI_INVALID_DATA blocks. Hellwig Expires June 8, 2017 [Page 19] Internet-Draft pNFS SCSI Layout December 2016 When a file is extended implicitly by a WRITE or LAYOUTCOMMIT beyond the current end-of-file, or extended explicitly by a SETATTR request, the server need not recall any portions of any pNFS layouts. 2.4.9. Layout Hints The layout hint attribute specified in [RFC5661] is not supported by the SCSI layout, and the pNFS server MUST reject setting a layout hint attribute with a loh_type value of LAYOUT4_SCSI_VOLUME during OPEN or SETATTR operations. On a file system only supporting the SCSI layout a server MUST NOT report the layout_hint attribute in the supported_attrs attribute. 2.4.10. Client Fencing The pNFS SCSI protocol must handle situations in which a system failure, typically a network connectivity issue, requires the server to unilaterally revoke extents from a client after the client fails to respond to a CB_LAYOUTRECALL request. This is implemented by fencing off a non-responding client from access to the storage device. The pNFS SCSI protocol implements fencing using Persistent Reservations (PRs), similar to the fencing method used by existing shared disk file systems. By placing a PR of type "Exclusive Access - Registrants Only" on each SCSI LU exported to pNFS clients the MDS prevents access from any client that does not have an outstanding device ID that gives the client a reservation key to access the LU, and allows the MDS to revoke access to the logic unit at any time. 2.4.10.1. PRs - Key Generation To allow fencing individual systems, each system MUST use a unique Persistent Reservation key. [SPC4] does not specify a way to generate keys. This document assigns the burden to generate unique keys to the MDS, which MUST generate a key for itself before exporting a volume, and a key for each client that accesses SCSI layout volumes. Individuals keys for each volume that a client can access are permitted but not required. 2.4.10.2. PRs - MDS Registration and Reservation Before returning a PNFS_SCSI_VOLUME_BASE volume to the client, the MDS needs to prepare the volume for fencing using PRs. This is done by registering the reservation generated for the MDS with the device using the "PERSISTENT RESERVE OUT" command with a service action of "REGISTER", followed by a "PERSISTENT RESERVE OUT" command, with a service action of "RESERVE" and the type field set to 8h (Exclusive Hellwig Expires June 8, 2017 [Page 20] Internet-Draft pNFS SCSI Layout December 2016 Access - Registrants Only). To make sure all I_T nexuses (see section 3.1.45 of [SAM-5]) are registered, the MDS SHOULD set the "All Target Ports" (ALL_TG_PT) bit when registering the key, or otherwise ensure the registration is performed for each target port, and MUST perform registration for each initiator port. 2.4.10.3. PRs - Client Registration Before performing the first I/O to a device returned from a GETDEVICEINFO operation the client will register the registration key returned in sbv_pr_key with the storage device by issuing a "PERSISTENT RESERVE OUT" command with a service action of REGISTER with the "SERVICE ACTION RESERVATION KEY" set to the reservation key returned in sbv_pr_key. To make sure all I_T nexuses are registered, the client SHOULD set the "All Target Ports" (ALL_TG_PT) bit when registering the key, or otherwise ensure the registration is performed for each target port, and MUST perform registration for each initiator port. When a client stops using a device earlier returned by GETDEVICEINFO it MUST unregister the earlier registered key by issuing a "PERSISTENT RESERVE OUT" command with a service action of "REGISTER" with the "RESERVATION KEY" set to the earlier registered reservation key. 2.4.10.4. PRs - Fencing Action In case of a non-responding client the MDS fences the client by issuing a "PERSISTENT RESERVE OUT" command with the service action set to "PREEMPT" or "PREEMPT AND ABORT", the reservation key field set to the server's reservation key, the service action reservation key field set to the reservation key associated with the non- responding client, and the type field set to 8h (Exclusive Access - Registrants Only). After the MDS preempts a client, all client I/O to the LU fails. The client SHOULD at this point return any layout that refers to the device ID that points to the LU. Note that the client can distinguish I/O errors due to fencing from other errors based on the "RESERVATION CONFLICT" SCSI status. Refer to [SPC4] for details. 2.4.10.5. Client Recovery After a Fence Action A client that detects a "RESERVATION CONFLICT" SCSI status (I/O error) on the storage devices MUST commit all layouts that use the storage device through the MDS, return all outstanding layouts for the device, forget the device ID and unregister the reservation key. Future GETDEVICEINFO calls MAY refer to the storage device again, in Hellwig Expires June 8, 2017 [Page 21] Internet-Draft pNFS SCSI Layout December 2016 which case the client will perform a new registration based on the key provided (via sbv_pr_key) at that time. 2.5. Crash Recovery Issues A critical requirement in crash recovery is that both the client and the server know when the other has failed. Additionally, it is required that a client sees a consistent view of data across server restarts. These requirements and a full discussion of crash recovery issues are covered in the "Crash Recovery" section of the NFSv41 specification [RFC5661]. This document contains additional crash recovery material specific only to the SCSI layout. When the server crashes while the client holds a writable layout, and the client has written data to blocks covered by the layout, and the blocks are still in the PNFS_SCSI_INVALID_DATA state, the client has two options for recovery. If the data that has been written to these blocks is still cached by the client, the client can simply re-write the data via NFSv4, once the server has come back online. However, if the data is no longer in the client's cache, the client MUST NOT attempt to source the data from the data servers. Instead, it SHOULD attempt to commit the blocks in question to the server during the server's recovery grace period, by sending a LAYOUTCOMMIT with the "loca_reclaim" flag set to true. This process is described in detail in Section 18.42.4 of [RFC5661]. 2.6. Recalling Resources: CB_RECALL_ANY The server MAY decide that it cannot hold all of the state for layouts without running out of resources. In such a case, it is free to recall individual layouts using CB_LAYOUTRECALL to reduce the load, or it MAY choose to request that the client return any layout. The NFSv4.1 spec [RFC5661] defines the following types: const RCA4_TYPE_MASK_BLK_LAYOUT = 4; struct CB_RECALL_ANY4args { uint32_t craa_objects_to_keep; bitmap4 craa_type_mask; }; When the server sends a CB_RECALL_ANY request to a client specifying the RCA4_TYPE_MASK_BLK_LAYOUT bit in craa_type_mask, the client SHOULD immediately respond with NFS4_OK, and then asynchronously return complete file layouts until the number of files with layouts cached on the client is less than craa_object_to_keep. Hellwig Expires June 8, 2017 [Page 22] Internet-Draft pNFS SCSI Layout December 2016 2.7. Transient and Permanent Errors The server may respond to LAYOUTGET with a variety of error statuses. These errors can convey transient conditions or more permanent conditions that are unlikely to be resolved soon. The error NFS4ERR_RECALLCONFLICT indicates that the server has recently issued a CB_LAYOUTRECALL to the requesting client, making it necessary for the client to respond to the recall before processing the layout request. A client can wait for that recall to be receive and processe or it can retry as for NFS4ERR_TRYLATER, as described below. The error NFS4ERR_TRYLATER is used to indicate that the server cannot immediately grant the layout to the client. This may be due to constraints on writable sharing of blocks by multiple clients or to a conflict with a recallable lock (e.g. a delegation). In either case, a reasonable approach for the client is to wait several milliseconds and retry the request. The client SHOULD track the number of retries, and if forward progress is not made, the client SHOULD abandon the attempt to get a layout and perform READ and WRITE operations by sending them to the server The error NFS4ERR_LAYOUTUNAVAILABLE MAY be returned by the server if layouts are not supported for the requested file or its containing file system. The server MAY also return this error code if the server is the progress of migrating the file from secondary storage, there is a conflicting lock that would prevent the layout from being granted, or for any other reason that causes the server to be unable to supply the layout. As a result of receiving NFS4ERR_LAYOUTUNAVAILABLE, the client SHOULD abandon the attempt to get a layout and perform READ and WRITE operations by sending them to the MDS. It is expected that a client will not cache the file's layoutunavailable state forever. In particular, when the file is closed or opened by the client, issuing a new LAYOUTGET is appropriate. 2.8. Volatile write caches Many storage devices implement volatile write caches that require an explicit flush to persist the data from write operations to stable storage. Storage devices implementing [SBC3] should indicate a volatile write cache by setting the WCE bit to 1 in the Caching mode page. When a volatile write cache is used, the pNFS server MUST ensure the volatile write cache has been committed to stable storage before the LAYOUTCOMMIT operation returns by using one of the SYNCHRONIZE CACHE commands. Hellwig Expires June 8, 2017 [Page 23] Internet-Draft pNFS SCSI Layout December 2016 3. Enforcing NFSv4 Semantics The functionality provided by SCSI Persistent Reservations makes it possible for the MDS to control access by individual client machines to specific LUs. Individual client machines may be allowed to or prevented from reading or writing to certain block devices. Finer- grained access control methods are not generally available. For this reason, certain responsibilities for enforcing NFSv4 semantics, including security and locking, are delegated to pNFS clients when SCSI layouts are being used. The metadata server's role is to only grant layouts appropriately and the pNFS clients have to be trusted to only perform accesses allowed by the layout extents they currently hold (e.g., and not access storage for files on which a layout extent is not held). In general, the server will not be able to prevent a client that holds a layout for a file from accessing parts of the physical disk not covered by the layout. Similarly, the server will not be able to prevent a client from accessing blocks covered by a layout that it has already returned. The pNFS client must respect the layout model for this mapping type to appropriately respect NFSv4 semantics. Furthermore, there is no way for the storage to determine the specific NFSv4 entity (principal, openowner, lockowner) on whose behalf the I/O operation is being done. This fact may limit the functionality to be supported and require the pNFS client to implement server policies other than those describable by layouts. In cases in which layouts previously granted become invalid, the server has the option of recalling them. In situations in which communication difficulties prevent this from happening, layouts may be revoked by the server. This revocation is accompanied by changes in persistent reservation which have the effect of preventing SCSI access to the LUs in question by the client. 3.1. Use of Open Stateids The effective implementation of these NFSv4 semantic constraints is complicated by the different granularities of the actors for the different types of the functionality to be enforced: o To enforce security constraints for particular principals. o To enforce locking constraints for particular owners (openowners and lockowners) Fundamental to enforcing both of these sorts of constraints is the principle that a pNFS client must not issue a SCSI I/O operation unless it possesses both: Hellwig Expires June 8, 2017 [Page 24] Internet-Draft pNFS SCSI Layout December 2016 o A valid open stateid for the file in question, performing the I/O that allows I/O of the type in question, which is associated with the openowner and principal on whose behalf the I/O is to be done. o A valid layout stateid for the file in question that covers the byte range on which the I/O is to be done and that allows I/O of that type to be done. As a result, if the equivalent of I/O with an anonymous or write- bypass stateid is to be done, it MUST NOT by done using the pNFS SCSI layout type. The client MAY attempt such I/O using READs and WRITEs that do not use pNFS and are directed to the MDS. When open stateids are revoked, due to lease expiration or any form of administrative revocation, the server MUST recall all layouts that allow I/O to be done on any of the files for which open revocation happens. When there is a failure to successfully return those layouts, the client MUST be fenced. 3.2. Enforcing Security Restrictions The restriction noted above provides adequate enforcement of appropriate security restriction when the principal issuing the I/O is the same as that opening the file. The server is responsible for checking that the I/O mode requested by the open is allowed for the principal doing the OPEN. If the correct sort of I/O is done on behalf of the same principal, then the security restriction is thereby enforced. If I/O is done by a principal different from the one that opened the file, the client SHOULD send the I/O to be performed by the metadata server rather than doing it directly to the storage device. 3.3. Enforcing Locking Restrictions Mandatory enforcement of whole-file locking by means of share reservations is provided when the pNFS client obeys the requirement set forth in Section 3.1 above. Since performing I/O requires a valid open stateid an I/O that violates an existing share reservation would only be possible when the server allows conflicting open stateids to exist. The nature of the SCSI layout type is such implementation/enforcement of mandatory byte-range locks is very difficult. Given that layouts are granted to clients rather than owners, the pNFS client is in no position to successfully arbitrate among multiple lockowners on the same client. Suppose lockowner A is doing a write and, while the I/O is pending, lockowner B requests a mandatory byte-range for a byte Hellwig Expires June 8, 2017 [Page 25] Internet-Draft pNFS SCSI Layout December 2016 range potentially overlapping the pending I/O. In such a situation, the lock request cannot be granted while the I/O is pending. In a non-pNFS environment, the server would have to wait for pending I/O before granting the mandatory byte-range lock. In the pNFS environment the server does not issue the I/O and is thus in no position to wait for its completion. The server may recall such layouts but in doing so, it has no way of distinguishing those being used by lockowners A and B, making it difficult to allow B to perform I/O while forbidding A from doing so. Given this fact, the MDS need to successfully recall all layouts that overlap the range being locked before returning a successful response to the LOCK request. While the lock is in effect, the server SHOULD respond to requests for layouts which overlap a currently locked area with NFS4ERR_LAYOUTUNAVAILABLE. To simplify the required logic a server MAY do this for all layout requests on the file in question as long as there are any byte-range locks in effect. Given these difficulties it may be difficult for servers supporting mandatory byte-range locks to also support SCSI layouts. Servers can support advisory byte-range locks instead. The NFSv4 protocol currently has no way of determining whether byte-range lock support on a particular file system will be mandatory or advisory, except by trying operation which would conflict if mandatory locking is in effect. Therefore, to avoid confusion, servers SHOULD NOT switch between mandatory and advisory byte-range locking based on whether any SCSI layouts have been obtained or whether a client that has obtained a SCSI layout has requested a byte-range lock. 4. Security Considerations Access to SCSI storage devices is logically at a lower layer of the I/O stack than NFSv4, and hence NFSv4 security is not directly applicable to protocols that access such storage directly. Depending on the protocol, some of the security mechanisms provided by NFSv4 (e.g., encryption, cryptographic integrity) may not be available or may be provided via different means. At one extreme, pNFS with SCSI layouts can be used with storage access protocols (e.g., serial attached SCSI ([SAS3]) that provide essentially no security functionality. At the other extreme, pNFS may be used with storage protocols such as iSCSI ([RFC7143]) that can provide significant security functionality. It is the responsibility of those administering and deploying pNFS with a SCSI storage access protocol to ensure that appropriate protection is provided to that protocol (physical security is a common means for protocols not based on IP). In environments where the security requirements for the storage protocol cannot be met, pNFS SCSI layouts SHOULD NOT be used. Hellwig Expires June 8, 2017 [Page 26] Internet-Draft pNFS SCSI Layout December 2016 When using IP-based storage protocols such as iSCSI, IPSEC should be used as outlined in [RFC3723] and updated in [RFC7146]. When security is available for a storage protocol, it is generally at a different granularity and with a different notion of identity than NFSv4 (e.g., NFSv4 controls user access to files, iSCSI controls initiator access to volumes). The responsibility for enforcing appropriate correspondences between these security layers is placed upon the pNFS client. As with the issues in the first paragraph of this section, in environments where the security requirements are such that client-side protection from access to storage outside of the layout is not sufficient, pNFS SCSI layouts SHOULD NOT be used. 5. IANA Considerations IANA is requested to assign a new pNFS layout type in the pNFS Layout Types Registry as follows (the value 5 is suggested): Layout Type Name: LAYOUT4_SCSI Value: 0x00000005 RFC: RFCTBD10 How: L (new layout type) Minor Versions: 1 6. Normative References [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", November 2008, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, Apr 2004. [RFC4506] Eisler, M., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006. [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010. [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", RFC 5662, January 2010. [RFC5663] Black, D., Ed., Fridella, S., Ed., and J. Glasgow, Ed., "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, January 2010. Hellwig Expires June 8, 2017 [Page 27] Internet-Draft pNFS SCSI Layout December 2016 [RFC6688] Black, D., Ed., Glasgow, J., and S. Faibish, "Parallel NFS (pNFS) Block Disk Protection", RFC 6688, July 2012. [RFC7143] Chadalapaka, M., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC RFC7143, April 2014. [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC RFC7146, April 2014. [SAM-5] INCITS Technical Committee T10, "SCSI Architecture Model - 5 (SAM-5)", ANSI INCITS 515-2016, 2016. [SAS3] INCITS Technical Committee T10, "Serial Attached Scsi-3", ANSI INCITS ANSI INCITS 519-2014, ISO/IEC 14776-154, 2014. [SBC3] INCITS Technical Committee T10, "SCSI Block Commands-3", ANSI INCITS INCITS 514-2014, ISO/IEC 14776-323, 2014. [SPC4] INCITS Technical Committee T10, "SCSI Primary Commands-4", ANSI INCITS 513-2015, 2015. Appendix A. Acknowledgments Large parts of this document were copied verbatim, and others were inspired by [RFC5663]. Thank to David Black, Stephen Fridella and Jason Glasgow for their work on the pNFS block/volume layout protocol. David Black, Robert Elliott and Tom Haynes provided a throughout review of drafts of this document, and their input led to the current form of the document. David Noveck provided ample feedback to various drafts of this document, wrote the section on enforcing NFSv4 semantics and rewrote various sections to better catch the intent. Appendix B. RFC Editor Notes [RFC Editor: please remove this section prior to publishing this document as an RFC] [RFC Editor: prior to publishing this document as an RFC, please replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the RFC number of this document] Hellwig Expires June 8, 2017 [Page 28] Internet-Draft pNFS SCSI Layout December 2016 [RFC Editor: This draft has a normative dependence on SAM-5, whose publication as a standard is in progress. Publication of this draft as an RFC has to wait for publication of SAM-5 including availability of a reference to the published standard. The author will be able to advise the RFC Editor when SAM-5 is published and supply the necessary reference.] Author's Address Christoph Hellwig Email: hch@lst.de Hellwig Expires June 8, 2017 [Page 29] ./draft-ietf-aqm-pie-10.txt0000664000764400076440000015402712772272502014723 0ustar iustyiusty Internet Draft R. Pan Active Queue Management P. Natarajan Working Group F. Baker Intended Status: Experimental Track Cisco Systems G. White CableLabs Expires: March 30, 2017 September 26, 2016 PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem draft-ietf-aqm-pie-10 Abstract Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users. This document presents a lightweight active queue management design, called PIE (Proportional Integral controller Enhanced), that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Pan et al. Expires March 30, 2017 [Page 1] INTERNET DRAFT PIE August 24, 2016 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The Basic PIE Scheme . . . . . . . . . . . . . . . . . . . . . 6 4.1 Random Dropping . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Drop Probability Calculation . . . . . . . . . . . . . . . . 8 4.3 Latency Calculation . . . . . . . . . . . . . . . . . . . . 10 4.4 Burst Tolerance . . . . . . . . . . . . . . . . . . . . . . 10 5. Optional Design Elements of PIE . . . . . . . . . . . . . . . . 11 5.1 ECN Support . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Dequeue Rate Estimation . . . . . . . . . . . . . . . . . . 11 5.3 Setting PIE active and inactive . . . . . . . . . . . . . . 13 5.4 De-randomization . . . . . . . . . . . . . . . . . . . . . . 14 5.5 Cap Drop Adjustment . . . . . . . . . . . . . . . . . . . . 15 6. Implementation Cost . . . . . . . . . . . . . . . . . . . . . . 15 7. Scope of Experimentation . . . . . . . . . . . . . . . . . . . 16 8. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 Pan et al. Expires March 30, 2017 [Page 2] INTERNET DRAFT PIE August 24, 2016 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1 Normative References . . . . . . . . . . . . . . . . . . . 18 11.2 Informative References . . . . . . . . . . . . . . . . . . 18 11.3 Other References . . . . . . . . . . . . . . . . . . . . . 19 12. The Basic PIE pseudo Code . . . . . . . . . . . . . . . . . . 20 13. Pseudo code for PIE with optional enhancement . . . . . . . . 23 Pan et al. Expires March 30, 2017 [Page 3] INTERNET DRAFT PIE August 24, 2016 1. Introduction The explosion of smart phones, tablets and video traffic in the Internet brings about a unique set of challenges for congestion control. To avoid packet drops, many service providers or data center operators require vendors to put in as much buffer as possible. Because of the rapid decrease in memory chip prices, these requests are easily accommodated to keep customers happy. While this solution succeeds in assuring low packet loss and high TCP throughput, it suffers from a major downside. The TCP protocol continuously increases its sending rate and causes network buffers to fill up. TCP cuts its rate only when it receives a packet drop or mark that is interpreted as a congestion signal. However, drops and marks usually occur when network buffers are full or almost full. As a result, excess buffers, initially designed to avoid packet drops, would lead to highly elevated queueing latency and latency variation. Designing a queue management scheme is a delicate balancing act: it not only should allow short-term burst to smoothly pass, but also should control the average latency in the presence of long-running greedy flows. AQM schemes could potentially solve the aforementioned problem. Active queue management (AQM) schemes, such as Random Early Detection (RED [RED] as suggested in RFC 2309[RFC2309], now obsoleted by RFC 7567 [RFC7567]), have been around for well over a decade. RED is implemented in a wide variety of network devices, both in hardware and software. Unfortunately, due to the fact that RED needs careful tuning of its parameters for various network conditions, most network operators don't turn RED on. In addition, RED is designed to control the queue length which would affect latency implicitly. It does not control latency directly. Hence, the Internet today still lacks an effective design that can control buffer latency to improve the quality of experience to latency-sensitive applications. The more recent RFC 7567 calls for new methods of controlling network latency. New algorithms are beginning to emerge to control queueing latency directly to address the bufferbloat problem [CoDel]. Along these lines, PIE also aims to keep the benefits of RED: including easy implementation and scalability to high speeds. Similar to RED, PIE randomly drops an incoming packet at the onset of the congestion. The congestion detection, however, is based on the queueing latency instead of the queue length like RED. Furthermore, PIE also uses the derivative (rate of change) of the queueing latency to help determine congestion levels and an appropriate response. The design parameters of PIE are chosen via control theory stability analysis. While these parameters can be fixed to work in various traffic conditions, they could be made self-tuning to optimize system performance. Pan et al. Expires March 30, 2017 [Page 4] INTERNET DRAFT PIE August 24, 2016 Separately, it is assumed that any latency-based AQM scheme would be applied over a Fair Queueing (FQ) structure or one of its approximate designs, Flow Queueing or Class Based Queueing (CBQ). FQ is one of the most studied scheduling algorithms since it was first proposed in 1985 [RFC970]. CBQ has been a standard feature in most network devices today[CBQ]. Any AQM scheme that is built on top of FQ or CBQ could benefit from these advantages. Furthermore, these advantages such as per flow/class fairness are orthogonal to the AQM design whose primary goal is to control latency for a given queue. For flows that are classified into the same class and put into the same queue, one needs to ensure their latency is better controlled and their fairness is not worse than those under the standard DropTail or RED design. More details about the relationship between FQ and AQM can be found in IETF draft [FQ-Implement]. In October 2013, CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1] mandated that cable modems implement a specific variant of the PIE design as the active queue management algorithm. In addition to cable specific improvements, the PIE design in DOCSIS 3.1 [DOCSIS-PIE] has improved the original design in several areas, including de- randomization of coin tosses and enhanced burst protection. This draft describes the design of PIE and separates it into basic elements and optional components that may be implemented to enhance the performance of PIE. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Design Goals A queue management framework is designed to improve the performance of interactive and latency-sensitive applications. It should follow the general guidelines set by the AQM working group document " Recommendations Regarding Active Queue Management" [RFC7567]. More specifically PIE design has the following basic criteria. * First, queueing latency, instead of queue length, is controlled. Queue sizes change with queue draining rates and various flows' round trip times. Latency bloat is the real issue that needs to be addressed as it impairs real time applications. Pan et al. Expires March 30, 2017 [Page 5] INTERNET DRAFT PIE August 24, 2016 If latency can be controlled, bufferbloat is not an issue. In fact, once latency is under control it frees up buffers for sporadic bursts. * Secondly, PIE aims to attain high link utilization. The goal of low latency shall be achieved without suffering link under- utilization or losing network efficiency. An early congestion signal could cause TCP to back off and avoid queue building up. On the other hand, however, TCP's rate reduction could result in link under-utilization. There is a delicate balance between achieving high link utilization and low latency. * Furthermore, the scheme should be simple to implement and easily scalable in both hardware and software. PIE strives to maintain similar design simplicity to RED, which has been implemented in a wide variety of network devices. * Finally, the scheme should ensure system stability for various network topologies and scale well across an arbitrary number of streams. Design parameters shall be set automatically. Users only need to set performance-related parameters such as target queue latency, not design parameters. In the following, the design of PIE and its operation are described in detail. 4. The Basic PIE Scheme As illustrated in Fig. 1, PIE is comprised of three simple basic components: a) random dropping at enqueueing; b) periodic drop probability update; c) latency calculation. When a packet arrives, a random decision is made regarding whether to drop the packet. The drop probability is updated periodically based on how far the current latency is away from the target and whether the queueing latency is currently trending up or down. The queueing latency can be obtained using direct measurements or using estimations calculated from the queue length and the dequeue rate. The detailed definition of parameters can be found in the pseudo code section of this document (Section 11). Any state variables that PIE maintains are noted using "PIE->". For full description of the algorithm, one can refer to the full paper [HPSR-PIE]. Pan et al. Expires March 30, 2017 [Page 6] INTERNET DRAFT PIE August 24, 2016 Random Drop / -------------- -------/ --------------> | | | | | --------------> /|\ | | | | | | -------------- | Queue Buffer \ | | \ | |queue \ | |length \ | | \ | \|/ \/ | ----------------- ------------------- | | Drop | | | -----<-----| Probability |<---| Latency | | Calculation | | Calculation | ----------------- ------------------- Figure 1. The PIE Structure 4.1 Random Dropping PIE randomly drops a packet upon its arrival to a queue according to a drop probability, PIE->drop_prob_, that is obtained from the drop- probability-calculation component. The random drop is triggered by a packet arrival before enqueueing into a queue. * Upon a packet enqueue: randomly drop the packet with a probability PIE->drop_prob_. To ensure that PIE is work conserving, we bypass the random drop if the latency sample, PIE->qdelay_old_, is smaller than half of the target latency value (QDELAY_REF) when the drop probability is not too high, PIE->drop_prob_ < 0.2; or if the queue has less than a couple of packets. * Upon a packet enqueue, PIE: //Safeguard PIE to be work conserving if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { return ENQUE; else randomly drop the packet with a probability PIE->drop_prob_. Pan et al. Expires March 30, 2017 [Page 7] INTERNET DRAFT PIE August 24, 2016 PIE optionally supports ECN and see Section 5.1. 4.2 Drop Probability Calculation The PIE algorithm periodically updates the drop probability based on the latency samples: not only the current latency sample but also the trend where the latency is going, up or down. This is the classical Proportional Integral (PI) controller method which is known for eliminating steady state errors. This type of controller has been studied before for controlling the queue length [PI, QCN]. PIE adopts the Proportional Integral controller for controlling latency. The algorithm also auto-adjusts the control parameters based on how heavy the congestion is, which is reflected in the current drop probability. Note that the current drop probability is a direct measure of current congestion level, no need to measure the arrival rate and dequeue rate mismatches. When a congestion period goes away, we might be left with a high drop probability with light packet arrivals. Hence, the PIE algorithm includes a mechanism by which the drop probability decay exponentially (rather than linearly) when the system is not congested. This would help the drop probability converge to 0 faster while the PI controller ensures that it would eventually reaches zero. The decay parameter of 2% gives us a time constant around 50*T_UPDATE. Specifically, the PIE algorithm periodically adjust the drop probability every T_UPDATE interval: * calculate drop probability PIE->drop_prob_ and auto-tune it as: p = alpha*(current_qdelay-QDELAY_REF) + beta*(current_qdelay-PIE->qdelay_old_); if (PIE->drop_prob_ < 0.000001) { p /= 2048; } else if (PIE->drop_prob_ < 0.00001) { p /= 512; } else if (PIE->drop_prob_ < 0.0001) { p /= 128; } else if (PIE->drop_prob_ < 0.001) { p /= 32; } else if (PIE->drop_prob_ < 0.01) { p /= 8; } else if (PIE->drop_prob_ < 0.1) { p /= 2; Pan et al. Expires March 30, 2017 [Page 8] INTERNET DRAFT PIE August 24, 2016 } else { p = p; } PIE->drop_prob_ += p; * decay the drop probability exponentially: if (current_qdelay == 0 && PIE->qdelay_old_ == 0) { PIE->drop_prob_ = PIE->drop_prob_*0.98; //1- 1/64 //is sufficient } * bound the drop probability if (PIE->drop_prob_ < 0) PIE->drop_prob_ = 0.0 if (PIE->drop_prob_ > 1) PIE->drop_prob_ = 1.0 * store current latency value: PIE->qdelay_old_ = current_qdelay. The update interval, T_UPDATE, is defaulted to be 15ms. It MAY be reduced on high speed links in order to provide smoother response. The target latency value, QDELAY_REF, SHOULD be set to 15ms. Variables, current_qdelay and PIE->qdelay_old_ represent the current and previous samples of the queueing latency, which are calculated by the "Latency Calculation" component (see Section 4.3). The variable current_qdelay is actually a temporary variable while PIE->qdelay_old_ is a state variable that PIE keeps. The drop probability is a value between 0 and 1. However, implementations can certainly use integers. The controller parameters, alpha and beta(in the unit of hz) are designed using feedback loop analysis where TCP's behaviors are modeled using the results from well-studied prior art[TCP-Models]. Note that the above adjustment of 'p' effectively scales the alpha and beta parameters based on current congestion level indicated by the drop probability. The theoretical analysis of PIE can be found in [HPSR-PIE]. As a rule of thumb, to keep the same feedback loop dynamics, if we cut T_UPDATE in half, we should also cut alpha by half and increase beta by alpha/4. If the target latency is reduced, e.g. for data center use, the values of alpha and beta should be increased by the same order of magnitude that the target latency is reduced. For example, if QDELAY_REF is reduced Pan et al. Expires March 30, 2017 [Page 9] INTERNET DRAFT PIE August 24, 2016 changed from 15ms to 150us, a reduction of two orders of magnitude, then alpha and beta values should be increased to alpha*100 and beta*100. 4.3 Latency Calculation The PIE algorithm uses latency to calculate drop probability. * It estimates current queueing latency using Little's law: current_qdelay = queue_.byte_length()/dequeue_rate; Details can be found in Section 5.2. * or it may use other techniques for calculating queueing latency, ex: timestamp packets at enqueue and use the same to calculate latency during dequeue. 4.4 Burst Tolerance PIE does not penalize short-term packet bursts as suggested in RFC7567 [RFC7567]. PIE allows bursts of traffic that create finite-duration events in which current queueing latency exceeds the QDELAY_REF, without triggering packet drops. A parameter, MAX_BURST, is introduced that defines the burst duration that will be protected. By default, the parameter SHOULD be set to be 150ms. For simplicity, the PIE algorithm MAY effectively round MAX_BURST up to an integer multiple of T_UPDATE. To implement the burst tolerance function, two basic components of PIE are involved: "random dropping" and "drop probability calculation". The PIE algorithm does the following: * In "Random Dropping" block and upon a packet arrival , PIE checks: Upon a packet enqueue: if PIE->burst_allowance_ > 0 enqueue packet; else randomly drop a packet with a probability PIE->drop_prob_. if (PIE->drop_prob_ == 0 and current_qdelay < QDELAY_REF/2 and PIE->qdelay_old_ < QDELAY_REF/2) PIE->burst_allowance_ = MAX_BURST; * In "Drop Probability Calculation" block, PIE additionally calculates: PIE->burst_allowance_ = max(0,PIE->burst_allowance_ - Pan et al. Expires March 30, 2017 [Page 10] INTERNET DRAFT PIE August 24, 2016 T_UPDATE); The burst allowance, noted by PIE->burst_allowance_, is initialized to MAX_BURST. As long as PIE->burst_allowance_ is above zero, an incoming packet will be enqueued bypassing the random drop process. During each update instance, the value of PIE->burst_allowance_ is decremented by the update period, T_UPDATE and is bottomed at 0. When the congestion goes away, defined here as PIE->drop_prob_ equals 0 and both the current and previous samples of estimated latency are less than half of QDELAY_REF, PIE->burst_allowance_ is reset to MAX_BURST. 5. Optional Design Elements of PIE The above forms the basic elements of the PIE algorithm. There are several enhancements that are added to further augment the performance of the basic algorithm. For clarity purposes, they are included in this section. 5.1 ECN Support PIE MAY support ECN by marking (rather than dropping) ECN capable packets [IETF-ECN]. As a safeguard, an additional threshold, mark_ecnth, is introduced. If the calculated drop probability exceeds mark_ecnth, PIE reverts to packet drop for ECN capable packets. The variable mark_ecnth SHOULD be set at 0.1(10%). * To support ECN, the "random drop with a probability PIE->drop_prob_" function in "Random Dropping" block are changed to the following: * Upon a packet enqueue: if rand() < PIE->drop_prob_: if PIE->drop_prob_ < mark_ecnth && ecn_capable_packet == TRUE: mark packet; else: drop packet; 5.2 Dequeue Rate Estimation Pan et al. Expires March 30, 2017 [Page 11] INTERNET DRAFT PIE August 24, 2016 Using the timestamps, a latency sample can only be obtained when a packet reaches at the head of a queue. When a quick response time is desired or a direct latency sample is not available, one may obtain latency through measuring the dequeue rate. The draining rate of a queue in the network often varies either because other queues are sharing the same link, or the link capacity fluctuates. Rate fluctuation is particularly common in wireless networks. One may measure directly at the dequeue operation. Short, non-persistent bursts of packets result in empty queues from time to time, this would make the measurement less accurate. PIE measures when a sufficient data in the buffer, i.e., when the queue length is over a certain threshold (DQ_THRESHOLD). PIE measures how long it takes to drain DQ_THRESHOLD of packets. More specifically, the rate estimation can be implemented as follows: current_qdelay = queue_.byte_length() * PIE->avg_dq_time_/DQ_THRESHOLD; * Upon a packet deque: if PIE->in_measurement_ == FALSE and queue.byte_length() >= DQ_THRESHOLD: PIE->in_measurement_ = TRUE; PIE->measurement_start_ = now; PIE->dq_count_ = 0; if PIE->in_measurement_ == TRUE: PIE->dq_count_ = PIE->dq_count_ + deque_pkt_size; if PIE->dq_count_ >= DQ_THRESHOLD then weight = DQ_THRESHOLD/2^16 PIE->avg_dq_time_ = (now-PIE->measurement_start_)*weight + PIE->avg_dq_time_*(1-weight); PIE->dq_count_=0; PIE->measurement_start_ = now else PIE->in_measurement_ = FALSE; The parameter, PIE->dq_count_, represents the number of bytes departed since the last measurement. Once PIE->dq_count_ is over DQ_THRESHOLD, a measurement sample is obtained. The threshold is recommended to be set to 16KB assuming a typical packet size of around 1KB or 1.5KB. This threshold would allow sufficient data to obtain an average draining rate but also fast enough (< 64KB) to reflect sudden changes in the draining rate. IF DQ_THRESHOLD is smaller than 64KB, a small weight is used to smooth out the dequeue time and obtain PIE->avg_dq_time_. The dequeue rate is simply DQ_THRESHOLD divided by PIE->avg_dq_time_. This threshold is not crucial for the system's stability. Please note that the update interval for calculating the drop probability is different from the rate measurement cycle. The drop probability calculation is done periodically Pan et al. Expires March 30, 2017 [Page 12] INTERNET DRAFT PIE August 24, 2016 per section 4.2 and it is done even when the algorithm is not in a measurement cycle; in this case the previously latched value of PIE- >avg_dq_time_ is used. Random Drop / -------------- -------/ --------------------> | | | | | --------------> /|\ | | | | | | | | -------------- | | Queue Buffer | | | | | |queue | | |length | | | | \|/ \|/ | ------------------------------ | | Dequeue Rate | -----<-----| & Drop Probability | | Calculation | ------------------------------ Figure 2. The Enqueue-based PIE Structure In some platforms, enqueueing and dequeueing functions belong to different modules that are independent of each other. In such situations, a pure enqueue-based design can be designed. As shown in Figure 2, an enqueue-based design is depicted. The dequeue rate is deduced from the number of packets enqueued and the queue length. The design is based on the following key observation: over a certain time interval, the number of dequeued packets = the number of enqueued packets - the number of remaining packets in queue. In this design, everything can be triggered by a packet arrival including the background update process. The design complexity here is similar to the original design. 5.3 Setting PIE active and inactive Traffic naturally fluctuates in a network. It would be preferable not to unnecessarily drop packets due to a spurious uptick in queueing latency. PIE has an optional feature of automatically becoming active/inactive. To implement this feature, PIE may choose to only become active (from inactive) when the buffer occupancy is over a certain threshold, which Pan et al. Expires March 30, 2017 [Page 13] INTERNET DRAFT PIE August 24, 2016 may be set to 1/3 of the tail drop threshold. PIE becomes inactive when congestion is over, i.e. when the drop probability reaches 0, current and previous latency samples are all below half of QDELAY_REF. Ideally, PIE should become active/inactive based on the latency. However, calculating latency when PIE is inactive would introduce unnecessary packet processing overhead. Weighing the trade-offs, it is decided to compare against tail drop threshold to keep things simple. When PIE is optionally becomes active/inactive, the burst protection logic in Section 4.4 are modified as follows: * "Random Dropping" block, PIE adds: Upon packet arrival: if PIE->active_ == FALSE && queue_length >= TAIL_DROP/3: PIE->active_ = TRUE; PIE->burst_allowance_ = MAX_BURST; if PIE->burst_allowance_ > 0 enqueue packet; else randomly drop a packet with a probability PIE->drop_prob_. if (PIE->drop_prob_ == 0 and current_qdelay < QDELAY_REF/2 and PIE->qdelay_old_ < QDELAY_REF/2) PIE->active_ = FALSE; PIE->burst_allowance_ = MAX_BURST; * "Drop Probability Calculation" block, PIE does the following: if PIE->active_ == TRUE: PIE->burst_allowance_ = max(0,PIE->burst_allowance_ - T_UPDATE); 5.4 De-randomization Although PIE adopts random dropping to achieve latency control, independent coin tosses could introduce outlier situations where packets are dropped too close to each other or too far from each other. This would cause real drop percentage to temporarily deviate from the intended value PIE->drop_prob_. In certain scenarios, such as small number of simultaneous TCP flows, these deviations can cause significant deviations in link utilization and queueing latency. PIE may use a de- randomization mechanism to avoid such situations. A parameter, called PIE->accu_prob_, is reset to 0 after a drop. Upon a packet arrival, PIE- >accu_prob_ is incremented by the amount of drop probability, PIE- >drop_prob_. If PIE->accu_prob_ is less than a low threshold, e.g. 0.85, the arriving packet is enqueued; on the other hand, if PIE->accu_prob_ is more than a high threshold, e.g. 8.5, and the queue is congested, the Pan et al. Expires March 30, 2017 [Page 14] INTERNET DRAFT PIE August 24, 2016 arrival packet is forced to be dropped. A packet is only randomly dropped if PIE->accu_prob_ falls in between the two thresholds. Since PIE->accu_prob_ is reset to 0 after a drop, another drop will not happen until 0.85/PIE->drop_prob_ packets later. This avoids packets being dropped too close to each other. In the other extreme case where 8.5/PIE->drop_prob_ packets have been enqueued without incurring a drop, PIE would force a drop in order to prevent the drops from being spaced too far apart. Further analysis can be found in [DOCSIS-PIE]. 5.5 Cap Drop Adjustment In the case of one single TCP flow during slow start phase in the system, queue could quickly increase during slow start and demands high drop probability. In some environments such as Cable Modem Speed Test, one could not afford triggering timeout and lose throughput as throughput is shown to customers who are testing his/her connection speed. PIE could cap the maximum drop probability increase in each step. * "Drop Probability Calculation" block, PIE adds: if (PIE->drop_prob_ >= 0.1 && p > 0.02) { p = 0.02; } 6. Implementation Cost PIE can be applied to existing hardware or software solutions. There are three steps involved in PIE as discussed in Section 4. Their complexities are examined below. Upon packet arrival, the algorithm simply drops a packet randomly based on the drop probability. This step is straightforward and requires no packet header examination and manipulation. If the implementation doesn't rely on packet timestamps for calculating latency, PIE does not require extra memory. Furthermore, the input side of a queue is typically under software control while the output side of a queue is hardware based. Hence, a drop at enqueueing can be readily retrofitted into existing or software implementations. The drop probability calculation is done in the background and it occurs every T_UPDATE interval. Given modern high speed links, this period translates into once every tens, hundreds or even thousands of packets. Hence the calculation occurs at a much slower time scale than packet processing time, at least an order of magnitude slower. The calculation of drop probability involves multiplications using alpha and beta. Since PIE's control law is robust to minor changes in alpha and beta values, Pan et al. Expires March 30, 2017 [Page 15] INTERNET DRAFT PIE August 24, 2016 an implementation MAY choose these values to the closest multiples of 2 or 1/2 (ex: alpha=1/8, beta=1 + 1/4) such that the multiplications can be done using simple adds and shifts. As no complicated functions are required, PIE can be easily implemented in both hardware and software. The state requirement is only one variables per queue: PIE->qdelay_old_. Hence the memory overhead is small. If one chooses to implement the departure rate estimation, PIE uses a counter to keep track of the number of bytes departed for the current interval. This counter is incremented per packet departure. Every T_UPDATE, PIE calculates latency using the departure rate, which can be implemented using a multiplication. Note that many network devices keep track of an interface's departure rate. In this case, PIE might be able to reuse this information, simply skip the third step of the algorithm and hence incurs no extra cost. If a platform already leverages packet timestamps for other purposes, PIE can make use of these packet timestamps for latency calculation instead of estimating departure rate. Flow queuing can also be combined with PIE to provide isolation between flows. In this case, it is preferable to have an independent value of drop probability per queue. This allows each flow to receive the most appropriate level of congestion signal, and ensures that sparse flows are protected from experiencing packet drops. However, running the entire PIE algorithm independently on each queue in order to calculate the drop probability may be overkill. Furthermore, in the case that departure rate estimation is used to predict queuing latency, it is not possible to calculate an accurate per-queue departure rate upon which to implement the PIE drop probability calculation. Instead, it has been proposed ([DOCSIS_AQM]) that a single implementation of the PIE drop probability calculation based on the overall latency estimate be used, followed by a per-queue scaling of drop-probability based on the ratio of queue-depth between the queue in question and the current largest queue. This scaling is reasonably simple, and has a couple of nice properties. One, if a packet is arriving to an empty queue, it is given immunity from packet drops altogether, regardless of the state of the other queues. Two, in the situation where only a single queue is in use, the algorithm behaves exactly like the single-queue PIE algorithm. In summary, PIE is simple enough to be implemented in both software and hardware. 7. Scope of Experimentation The design of the PIE algorithm is presented in this document. It Pan et al. Expires March 30, 2017 [Page 16] INTERNET DRAFT PIE August 24, 2016 effectively controls the average queueing latency to a target value. The following areas can be further studied and experimented: * Autotuning of target latency without losing utilization; * Autotuning for average RTT of traffic; * The proper threshold to transition smoothly between ECN marking and dropping; * The enhancements in Section 5 can be experimented to see if they would bring more value in the real world. If so, they will be incorporated into the basic PIE algorithm; * The PIE design is separated into data path and control path, and the control path can be implemented in software. Field tests of other control laws can be experimented to further improve PIE's performance. Although all network nodes cannot be changed altogether to adopt latency-based AQM schemes such as PIE, a gradual adoption would eventually lead to end-to-end low latency service for all applications. 8. Incremental Deployment From testbed experiments and large scale simulations of PIE so far, PIE has been shown to be effective across diverse range of network scenarios. There is no indication that PIE would be harmful to deploy. The PIE scheme can be independently deployed and managed without a need for interoperability between different network devices. In addition, any individual buffer queue can be incrementally upgraded to PIE as it can co-exist with existing AQM schemes such as WRED. PIE is intended to be self-configuring. Users should not need to configure any design parameters. Upon installation, the two user- configurable parameters: QDELAY_REF and MAX_BURST, will be defaulted to 15ms and 150ms for non datacenter network devices and to 15us and 150us for datacenter switches, respectively. Since the data path of the algorithm needs only a simple coin toss and the control path calculation happens in a much slower time scale, We don't forsee any scaling issues associated with the algorithm as the link speed scales up. Pan et al. Expires March 30, 2017 [Page 17] INTERNET DRAFT PIE August 24, 2016 9. Security Considerations This document describes an active queue management algorithm based on implementations in different products. This algorithm introduces no specific security exposures. 10. IANA Considerations There are no actions for IANA. 11. References 11.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2 Informative References [RFC970] Nagle, J., "On Packet Switches With Infinite Storage",RFC970, December 1985. [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Patridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and Zhang, L., "Recommendations on Queue Management and Congestion Avoidance in the Internet", April, 1998. [RFC7567] Baker, F. and Fairhurst, G., "Recommendations Regarding Active Queue Management", July, 2015. [CBQ] Cisco White Paper, "http://www.cisco.com/en/US/docs/12_0t/12_0tfeature/guide/cbwfq.html". [CoDel] Nichols, K., Jacobson, V., "Controlling Queue Delay", ACM Queue. ACM Publishing. doi:10.1145/2209249.22W.09264. [DOCSIS_3.1] http://www.cablelabs.com/wp-content/uploads/specdocs /CM-SP-MULPIv3.1-I01-131029.pdf. [DOCSIS-PIE] White, G. and Pan, R., "A PIE-Based AQM for DOCSIS Cable Modems", IETF draft-white-aqm-docsis-pie-02. Pan et al. Expires March 30, 2017 [Page 18] INTERNET DRAFT PIE August 24, 2016 [FQ-Implement] Baker, F. and Pan, R. "On Queueing, Marking and Dropping", IETF draft-ietf-aqm-fq-implementation. [HPSR-PIE] Pan, R., Natarajan, P. Piglione, C., Prabhu, M.S., Subramanian, V., Baker, F. Steeg and B. V., "PIE: A Lightweight Control Scheme to Address the Bufferbloat Problem", IEEE HPSR 2013. https://www.researchgate.net/publication/261134127_PIE_A_lightweight _control_scheme_to_address_the_bufferbloat_problem?origin=mail. [IETF-ECN] Briscoe, B. Kaippallimalil, J and Phaler, P., "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines. 11.3 Other References [PI] Hollot, C.V., Misra, V., Towsley, D. and Gong, W., "On Designing Improved Controller for AQM Routers Supporting TCP Flows", Infocom 2001. [QCN] "Data Center Bridging - Congestion Notification", http://www.ieee802.org/1/pages/802.1au.html. [RED] Floyd, S. and Jacobson V., "Random Early Detection (RED) Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, August, 1993. [TCP-Models] Misra, V., Gong, W., and Towsley, D., "Fluid-base Analysis of a Network of AQM Routers Supporting TCP Flows with an Application to RED", SIGCOMM 2000. Authors' Addresses Rong Pan Cisco Systems 3625 Cisco Way, San Jose, CA 95134, USA Email: ropan@cisco.com Preethi Natarajan, Cisco Systems 725 Alder Drive, Milpitas, CA 95035, USA Email: prenatar@cisco.com Fred Baker Cisco Systems 725 Alder Drive, Pan et al. Expires March 30, 2017 [Page 19] INTERNET DRAFT PIE August 24, 2016 Milpitas, CA 95035, USA Email: fred@cisco.com Greg White CableLabs 858 Coal Creek Circle Louisville, CO 80027, USA Email: g.white@cablelabs.com Other Contributor's Addresses Bill Ver Steeg Comcast Cable Email: William_VerSteeg@comcast.com Mythili Prabhu* Akamai Technologies 3355 Scott Blvd Santa Clara, CA - 95054 Email: mythili@akamai.com Chiara Piglione* Broadcom Corporation 3151 Zanker Road San Jose, CA 95134 Email: chiara@broadcom.com Vijay Subramanian* PLUMgrid, Inc. 350 Oakmead Parkway, Suite 250 Sunnyvale, CA 94085 Email: vns@plumgrid.com * Formerly at Cisco Systems 12. The Basic PIE pseudo Code Configurable Parameters: - QDELAY_REF. AQM Latency Target (default: 15ms) - MAX_BURST. AQM Max Burst Allowance (default: 150ms) Internal Parameters: - Weights in the drop probability calculation (1/s): alpha (default: 1/8), beta(default: 1 + 1/4) - T_UPDATE: a period to calculate drop probability (default:15ms) Pan et al. Expires March 30, 2017 [Page 20] INTERNET DRAFT PIE August 24, 2016 Table which stores status variables (ending with "_"): - burst_allowance_: current burst allowance - drop_prob_: The current packet drop probability. reset to 0 - qdelay_old_: The previous queue delay. reset to 0 Public/system functions: - queue_. Holds the pending packets. - drop(packet). Drops/discards a packet - now(). Returns the current time - random(). Returns a uniform r.v. in the range 0 ~ 1 - queue_.byte_length(). Returns current queue_ length in bytes - queue_.enque(packet). Adds packet to tail of queue_ - queue_.deque(). Returns the packet from the head of queue_ - packet.size(). Returns size of packet - packet.timestamp_delay(). Returns timestamped packet latency ============================ //called on each packet arrival enque(Packet packet) { if (PIE->drop_prob_ == 0 && current_qdelay < QDELAY_REF/2 && PIE->qdelay_old_ < QDELAY_REF/2) { PIE->burst_allowance_ = MAX_BURST; } if (PIE->burst_allowance_ == 0 && drop_early() == DROP) { drop(packet); } else { queue_.enque(packet); } } =========================== drop_early() { //Safeguard PIE to be work conserving if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { return ENQUE; } double u = random(); if (u < PIE->drop_prob_) { return DROP; } else { Pan et al. Expires March 30, 2017 [Page 21] INTERNET DRAFT PIE August 24, 2016 return ENQUE; } } =========================== //we choose the timestamp option of obtaining latency for clarity //rate estimation method can be found in the extended PIE pseudo code deque(Packet packet) { current_qdelay = packet.timestamp_delay(); } ============================ //update periodically, T_UPDATE = 15ms calculate_drop_prob() { //can be implemented using integer multiply, p = alpha*(current_qdelay - QDELAY_REF) + \ beta*(current_qdelay-PIE->qdelay_old_); if (PIE->drop_prob_ < 0.000001) { p /= 2048; } else if (PIE->drop_prob_ < 0.00001) { p /= 512; } else if (PIE->drop_prob_ < 0.0001) { p /= 128; } else if (PIE->drop_prob_ < 0.001) { p /= 32; } else if (PIE->drop_prob_ < 0.01) { p /= 8; } else if (PIE->drop_prob_ < 0.1) { p /= 2; } else { p = p; } PIE->drop_prob_ += p; //Exponentially decay drop prob when congestion goes away if (current_qdelay == 0 && PIE->qdelay_old_ == 0) { PIE->drop_prob_ *= 0.98; //1- 1/64 is sufficient } Pan et al. Expires March 30, 2017 [Page 22] INTERNET DRAFT PIE August 24, 2016 //bound drop probability if (PIE->drop_prob_ < 0) PIE->drop_prob_ = 0.0 if (PIE->drop_prob_ > 1) PIE->drop_prob_ = 1.0 PIE->qdelay_old_ = current_qdelay; PIE->burst_allowance_ = max(0,PIE->burst_allowance_ - T_UPDATE); } } 13. Pseudo code for PIE with optional enhancement Configurable Parameters: - QDELAY_REF. AQM Latency Target (default: 15ms) - MAX_BURST. AQM Max Burst Allowance (default: 150ms) - MAX_ECNTH. AQM Max ECN Marking Threshold (default: 10%) Internal Parameters: - Weights in the drop probability calculation (1/s): alpha (default: 1/8), beta(default: 1+1/4) - DQ_THRESHOLD: (in bytes, default: 2^14 (in a power of 2) ) - T_UPDATE: a period to calculate drop probability (default:15ms) - TAIL_DROP: each queue has a tail drop threshold, pass it to PIE Table which stores status variables (ending with "_"): - active_: INACTIVE/ACTIVE - burst_allowance_: current burst allowance - drop_prob_: The current packet drop probability. reset to 0 - accu_prob_: Accumulated drop probability. reset to 0 - qdelay_old_: The previous queue delay estimate. reset to 0 - last_timestamp_: Timestamp of previous status update - dq_count_, measurement_start_, in_measurement_, avg_dq_time_. variables for measuring average dequeue rate. Public/system functions: - queue_. Holds the pending packets. - drop(packet). Drops/discards a packet - mark(packet). Marks ECN for a packet - now(). Returns the current time Pan et al. Expires March 30, 2017 [Page 23] INTERNET DRAFT PIE August 24, 2016 - random(). Returns a uniform r.v. in the range 0 ~ 1 - queue_.byte_length(). Returns current queue_ length in bytes - queue_.enque(packet). Adds packet to tail of queue_ - queue_.deque(). Returns the packet from the head of queue_ - packet.size(). Returns size of packet - packet.ecn(). Returns whether packet is ECN capable or not ============================ //called on each packet arrival enque(Packet packet) { if (queue_.byte_length()+packet.size() > TAIL_DROP) { drop(packet); PIE->accu_prob_ = 0; } else if (PIE->active_ == TRUE && drop_early() == DROP && PIE->burst_allowance_ == 0) { if (PIE->drop_prob_ < MAX_ECNTH && packet.ecn() == TRUE) mark(packet); else drop(packet); PIE->accu_prob_ = 0; } else { queue_.enque(packet); } //If the queue is over a certain threshold, turn on PIE if (PIE->active_ == INACTIVE && queue_.byte_length() >= TAIL_DROP/3) { PIE->active_ = ACTIVE; PIE->qdelay_old_ = 0; PIE->drop_prob_ = 0; PIE->in_measurement_ = TRUE; PIE->dq_count_ = 0; PIE->avg_dq_time_ = 0; PIE->last_timestamp_ = now; PIE->burst_allowance_ = MAX_BURST; PIE->accu_prob_ = 0; PIE->measurement_start_ = now; } //If the queue has been idle for a while, turn off PIE //reset counters when accessing the queue after some idle //period if PIE was active before if ( PIE->drop_prob_ == 0 && PIE->qdelay_old_ == 0 && current_qdelay == 0) { PIE->active_ = INACTIVE; PIE->in_measurement_ = FALSE; } Pan et al. Expires March 30, 2017 [Page 24] INTERNET DRAFT PIE August 24, 2016 } =========================== drop_early() { //PIE is active but the queue is not congested, return ENQUE if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { return ENQUE; } if (PIE->drop_prob_ == 0) { PIE->accu_prob_ = 0; } //For practical reasons, drop probability can be further scaled //according to packet size. but need to set a bound to //avoid unnecessary bias //Random drop PIE->accu_prob_ += PIE->drop_prob_; if (PIE->accu_prob_ < 0.85) return ENQUE; if (PIE->accu_prob_ >= 8.5) return DROP; double u = random(); if (u < PIE->drop_prob_) { PIE->accu_prob_ = 0; return DROP; } else { return ENQUE; } } ============================ //update periodically, T_UPDATE = 15ms calculate_drop_prob() { if ( (now - PIE->last_timestamp_) >= T_UPDATE && PIE->active_ == ACTIVE) { Pan et al. Expires March 30, 2017 [Page 25] INTERNET DRAFT PIE August 24, 2016 //can be implemented using integer multiply, //DQ_THRESHOLD is power of 2 value current_qdelay = queue_.byte_length() * PIE- >avg_dq_time_/DQ_THRESHOLD; p = alpha*(current_qdelay - QDELAY_REF) + \ beta*(current_qdelay-PIE->qdelay_old_); if (PIE->drop_prob_ < 0.000001) { p /= 2048; } else if (PIE->drop_prob_ < 0.00001) { p /= 512; } else if (PIE->drop_prob_ < 0.0001) { p /= 128; } else if (PIE->drop_prob_ < 0.001) { p /= 32; } else if (PIE->drop_prob_ < 0.01) { p /= 8; } else if (PIE->drop_prob_ < 0.1) { p /= 2; } else { p = p; } if (PIE->drop_prob_ >= 0.1 && p > 0.02) { p = 0.02; } PIE->drop_prob_ += p; //Exponentially decay drop prob when congestion goes away if (current_qdelay < QDELAY_REF/2 && PIE->qdelay_old_ < QDELAY_REF/2) { PIE->drop_prob_ *= 0.98; //1- 1/64 is sufficient } //bound drop probability if (PIE->drop_prob_ < 0) PIE->drop_prob_ = 0 if (PIE->drop_prob_ > 1) PIE->drop_prob_ = 1 PIE->qdelay_old_ = current_qdelay; PIE->last_timestamp_ = now; PIE->burst_allowance_ = max(0,PIE->burst_allowance_ - T_UPDATE); } } Pan et al. Expires March 30, 2017 [Page 26] INTERNET DRAFT PIE August 24, 2016 ========================== //called on each packet departure deque(Packet packet) { //deque rate estimation if (PIE->in_measurement_ == TRUE) { PIE->dq_count_ = packet.size() + PIE->dq_count_; //start a new measurement cycle if we have enough packets if ( PIE->dq_count_ >= DQ_THRESHOLD) { dq_time = now - PIE->measurement_start_; if(PIE->avg_dq_time_ == 0) { PIE->avg_dq_time_ = dq_time; } else { weight = DQ_THRESHOLD/2^16 PIE->avg_dq_time_ = dq_time*weight + PIE->avg_dq_time_*(1- weight); } PIE->in_measurement_ = FALSE; } } //start a measurement if we have enough data in the queue: if (queue_.byte_length() >= DQ_THRESHOLD && PIE->in_measurement_ == FALSE) { PIE->in_measurement_ = TRUE; PIE->measurement_start_ = now; PIE->dq_count_ = 0; } } Pan et al. Expires March 30, 2017 [Page 27] ./draft-ietf-dnsop-maintain-ds-06.txt0000664000764400076440000005154013035272467016723 0ustar iustyiusty dnsop O. Gudmundsson Internet-Draft CloudFlare Intended status: Standards Track P. Wouters Expires: July 14, 2017 Red Hat January 10, 2017 Managing DS records from parent via CDS/CDNSKEY draft-ietf-dnsop-maintain-ds-06 Abstract RFC7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC7344 from informational to standards track and adds a standard track method for initial trust setup and removal of secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records) It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key ("KSK") plus Zone Signing Key ("ZSK") rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Gudmundsson & Wouters Expires July 14, 2017 [Page 1] Internet-Draft DS-maintain-ds January 2017 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Introducing a DS record . . . . . . . . . . . . . . . . . 3 1.2. Removing a DS Record . . . . . . . . . . . . . . . . . . 3 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 4 2.1. The meaning of the CDS RRset . . . . . . . . . . . . . . 5 3. Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . . 5 3.1. Accept policy via authenticated channel . . . . . . . . . 6 3.2. Accept with extra checks . . . . . . . . . . . . . . . . 6 3.3. Accept after delay . . . . . . . . . . . . . . . . . . . 6 3.4. Accept with challenge . . . . . . . . . . . . . . . . . . 6 3.5. Accept from inception . . . . . . . . . . . . . . . . . . 7 4. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 7 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. Promoting RFC7344 to standards track . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Gudmundsson & Wouters Expires July 14, 2017 [Page 2] Internet-Draft DS-maintain-ds January 2017 1. Introduction CDS/CDNSKEY [RFC7344] records are used to signal changes in secure entry points. This is one method to maintain delegations that can be used when the DNS operator has no other way to inform the parent that changes are needed. This document elevates [RFC7344] from informational to standards track RFC. In addition, [RFC7344] is lacking two different options for full automated operation to be possible. It did not define a method for the Initial Trust establishment, leaving it open to each parent to come up with an acceptance policy. Additionally, [RFC7344] did not provide a "delete" signal for the child to inform the parent that the DNSSEC security for its domain must be removed. 1.1. Introducing a DS record Automated insertion of DS records has been limited for many zones by the requirement that all changes pass through a "registry" of the child zone's parent. This has significantly hindered deployment of DNSSEC at large scale for DNS hosters, as the child zone owner is often not aware or able to update DNS records such as the DS record. This document describes a few possible methods for the parent to accept a request by the child to add a DS record to its zone. These methods have different security properties that addresses different deployment scenarios, all resulting in an automated method of trust introduction. 1.2. Removing a DS Record This document introduces the delete option for both CDS and CDNSKEY, allowing a child to signal to the parent to turn off DNSSEC. When a domain is moved from one DNS operator to another, sometimes it is necessary to turn off DNSSEC to facilitate the change of DNS operator. Common scenarios include: 1 Alternative to doing a proper DNSSEC algorithm rollover due to operational limitations such as software limitations. 2 Moving from a DNSSEC operator to a non-DNSSEC capable operator. 3 Moving to an operator that cannot/does-not-want to do a proper DNSSEC rollover. 4 When moving between two DNS operators that use disjoint sets of algorithms to sign the zone, thus an algorithm rollover can not be performed. Gudmundsson & Wouters Expires July 14, 2017 [Page 3] Internet-Draft DS-maintain-ds January 2017 5 The domain holder no longer wants DNSSEC enabled. The lack of a "remove my DNSSEC" option is cited as a reason why some operators cannot deploy DNSSEC, as this is seen as an operational risk. Turning off DNSSEC reduces the security of the domain and thus should only be done carefully, and that decision should be fully under the child domain's control. 1.3. Notation Signaling can happen via CDS or CDNSKEY records. The only differences between the two records is how information is represented, and who calculates the DS digest. For clarity, this document uses the term "CDS" throughout the document to mean "either CDS or CDNSKEY". When the document uses the word "parent" it implies an entity that is authorized to insert DS records into the parent zone on behalf of the child domain. Which entity this exactly is does not matter. It could be the Registrar or Reseller that the child domain was purchased from. It could be the Registry that the domain is registered in when allowed. Or it could be some other entity. 1.4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The Three Uses of CDS In general there are three operations that a domain wants to instruct their parent to perform: 1 Enable DNSSEC validation, i.e. place an initial DS RRset in the parent. 2 Roll over the Key Signing Key ("KSK"), this means updating the DS records in the parent to reflect the new set of KSK's at the child. This could be an ADD operation, a DELETE operation on one or more records while keeping at least one DS RR, or a full REPLACE operation. 3 Turn off DNSSEC validation, i.e. delete all the DS records. Gudmundsson & Wouters Expires July 14, 2017 [Page 4] Internet-Draft DS-maintain-ds January 2017 Rolling the KSK is covered in [RFC7344]. It is considered the safest use case of a CDS/CDNSKEY record as it makes no change to the trust relationship between parent and child. Introduction and removal of DS records are defined in this document. As these CDS/CDNSKEY use cases create or end the trust relationship between the parent and child, these use cases should be carefully implemented and monitored. 2.1. The meaning of the CDS RRset The semantic meaning of publishing a CDS RRset is interpreted to mean: "Publishing a CDS or CDNSKEY record signals to the parent that the child desires that the corresponding DS records be synchronized. Every parent or parental agent should have an acceptance policy of these records for the three different use cases involved: Initial DS publication, Key rollover, and Returning to Insecure." In short, the CDS RRset is an instruction to the parent to modify the DS RRset if the CDS and DS Reset's differ. The acceptance policy for CDS in the rollover case is "seeing" according to [RFC7344]. The acceptance policy in the Delete case is seeing a (validly signed) CDS RRset with the delete operation specified in this document. 3. Enabling DNSSEC via CDS/CDNSKEY There are number of different models for managing initial trust, but in the general case, the child wants to enable global validation. As long as the child is insecure, DNS answers can be forged. The goal is to promote the child from insecure to secure as soon as reasonably possible by the parent. This means that the period from the child's publication of CDS/CDNSKEY RRset to the parent publishing the synchronized DS RRset should be as short as possible. One important use case is how a third party DNS operator can upload its DNSSEC information to the parent, so the parent can publish a DS record for the child. In this case there is a possibility of setting up some kind of authentication mechanism and submission mechanism that is outside the scope of this document. Below are some policies that parents can use. These policies assume that the notifications can be verified or authenticated. Gudmundsson & Wouters Expires July 14, 2017 [Page 5] Internet-Draft DS-maintain-ds January 2017 3.1. Accept policy via authenticated channel In this case the parent is notified via authenticated channel UI/API that a CDS/CDNSKEY RRset exists. In the case of a CDS RRset the parent retrieves the CDS RRset and inserts the corresponding DS RRset as requested. In the case of CDNSKEY the parent retrieves the CDNSKEY RRset and calculates the DS record(s). Parents may limit the DS record type based on local policy. Parents SHOULD NOT refuse CDS/ CDNSKEY updates that do not (yet) have a matching DNSKEY in the child zone. This will allow the child to prepublish a spare (and potentially offline) DNSKEY. 3.2. Accept with extra checks In this case the parent checks that the source of the notification is allowed to request the DS insertion. The checks could include whether this is a trusted entity, whether the nameservers correspond to the requester, whether there have been any changes in registration in the last few days, etc. The parent can also send a notification requesting a confirmation, for example by sending email to the registrant requesting a confirmation. The end result is that the CDS RRset is accepted at the end of the checks or when the out-of-band confirmation is received. Any extra checks should have proper rate limiting in place to prevent abuse. 3.3. Accept after delay In this case, if the parent deems the request valid, it starts monitoring the CDS RRset at the child nameservers over period of time to make sure nothing changes. After some time or after a number of checks, preferably from different vantage points in the network, the parent accepts the CDS RRset as a valid signal to update its DS RRset for this child. 3.4. Accept with challenge In this case the parent instructs the requester to insert some record into the child domain to prove it has the ability to do so (i.e., it is the operator of the zone). This method imposes a new task on the parent to monitor the child zone to see if the challenge has been added to the zone. The parent should verify the challenge is published by all the child's nameservers and should test for this challenge from various diverse network locations to increase the security of this method as much as possible. Gudmundsson & Wouters Expires July 14, 2017 [Page 6] Internet-Draft DS-maintain-ds January 2017 3.5. Accept from inception If a parent is adding a new child domain that is not currently delegated at all, it could use the child CDS/CDNSKEY RRset to immediately publish a DS RRset along with the new NS RRset. This would ensure that the new child domain is never active in an insecure state. 4. DNSSEC Delete Algorithm This document defines the previously reserved DNS Security Algorithm Number of value 0 in the context of CDS and CDNSKEY records to mean that the entire DS RRset at the parent must be removed. The value 0 remains reserved for the DS and DNSKEY records. No DNSSEC validator can treat algorithm 0 as a valid signature algorithm. If a validator sees a DNSKEY or DS record with this algorithm value, it must treat it as unknown. Accordingly, the zone is treated as unsigned unless there are other algorithms present. In general the value 0 should never be used in the context of DNSKEY and DS records. The CERT record [RFC4398] defines the value 0 similarly to mean the algorithm in the CERT record is not defined in DNSSEC. The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exactly the fields as shown below. 1 CDS 0 0 0 0 2 CDNSKEY 0 3 0 0 The keying material payload is represented by a single 0. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. This is a change in format from strict interpretation of [RFC7344] and may cause problems with some deployed software. Strictly speaking the CDS record could be "CDS X 0 X 0" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity the "0 0 0 0" notation is mandated - this is not a definition of DS Digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 0", the value 3 in second field is mandated by [RFC4034] section 2.1.2. Once the parent has verified the CDS/CDNSKEY RRset and it has passed other acceptance tests, the parent MUST remove the DS RRset. After waiting a sufficient amount of time - depending on the parental TTL's - the child can start the process of turning off DNSSEC. Gudmundsson & Wouters Expires July 14, 2017 [Page 7] Internet-Draft DS-maintain-ds January 2017 5. Security considerations Turning off DNSSEC reduces the security of the domain and thus should only be done as a last resort in preventing DNSSEC validation errors due to mismatched DS and DNSKEY records. Users should keep in mind that re-establishing trust in delegation can be hard and takes time. Before deciding to complete the rollover via an unsigned state, all other options should be considered first. A parent SHOULD ensure that when it is allowing a child to become securely delegated, that it has a reasonable assurance that the CDS/ CDNSKEY RRset that is used to bootstrap the security is visible from a geographically and topologically diverse view. It SHOULD also ensure that the zone validates correctly if the parent publishes the DS record. A parent zone might also consider sending an email to its contact addresses to give the child zone a warning that security will be enabled after a certain amount of wait time - thus allowing a child administrator to cancel the request. This document describes a few possible acceptance criteria for the Initial Trust establishment. Due to a large variety of legal frameworks surrounding parent domains (TLDs in particular) this document cannot give a definitive list of valid acceptance criteria. Parental zones should look at the listed methods and pick the most secure method possible within their legal and technical scenario, possibly further securing the acceptance criteria, as long as the deployed method still enables a fully automated method for non-direct parties such as third party DNS hosters. 6. IANA considerations This document updates entry number 0 of the "DNS Security Algorithm Numbers" IANA Registry as follows: +------+---------+-------+-------+-------+--------------------------+ | Numb | Descrip | Mnemo | Zone | Trans | Reference | | er | tion | nic | Signi | . | | | | | | ng | Sec. | | +------+---------+-------+-------+-------+--------------------------+ | 0 | Delete | DELET | N | N | [RFC4034][RFC4398]RFC- | | | DS | E | | | THIS-DOCUMENT] | +------+---------+-------+-------+-------+--------------------------+ Gudmundsson & Wouters Expires July 14, 2017 [Page 8] Internet-Draft DS-maintain-ds January 2017 6.1. Promoting RFC7344 to standards track Experience has shown that CDS/CDNSKEY are useful in the deployment of DNSSEC. [RFC7344] was published as Informational, this document elevates RFC7344 to standards track. 7. References 7.1. Normative References [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . 7.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, . Appendix A. Acknowledgments This document is generated using the mmark tool that Miek Gieben has developed. We thank number of people that have provided feedback and useful comments including Bob Harold, John Levine, Matthijs Mekking(!), Dan York, Shane Kerr, Jacques Latour. Authors' Addresses Olafur Gudmundsson CloudFlare Email: olafur+ietf@cloudflare.com Gudmundsson & Wouters Expires July 14, 2017 [Page 9] Internet-Draft DS-maintain-ds January 2017 Paul Wouters Red Hat Email: pwouters@redhat.com Gudmundsson & Wouters Expires July 14, 2017 [Page 10] ./draft-ietf-avtcore-multi-media-rtp-session-13.txt0000664000764400076440000011400712635025637021526 0ustar iustyiusty AVTCORE WG M. Westerlund Internet-Draft Ericsson Updates: 3550, 3551 (if approved) C. Perkins Intended status: Standards Track University of Glasgow Expires: June 20, 2016 J. Lennox Vidyo December 18, 2015 Sending Multiple Types of Media in a Single RTP Session draft-ietf-avtcore-multi-media-rtp-session-13 Abstract This document specifies how an RTP session can contain RTP Streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 20, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Westerlund, et al. Expires June 20, 2016 [Page 1] Internet-Draft Multiple Media Types in an RTP Session December 2015 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background and Motivation . . . . . . . . . . . . . . . . . . 3 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Using Multiple Media Types in a Single RTP Session . . . . . 6 5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6 5.2. Demultiplexing media types within an RTP session . . . . 7 5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8 5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 6. Extension Considerations . . . . . . . . . . . . . . . . . . 9 6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9 6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10 6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11 7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Real-time Transport Protocol [RFC3550] was designed to use separate RTP sessions to transport different types of media. This implies that different transport layer flows are used for different RTP streams. For example, a video conferencing application might send audio and video traffic RTP flows on separate UDP ports. With increased use of network address/port translation, firewalls, and other middleboxes it is, however, becoming difficult to establish multiple transport layer flows between endpoints. Hence, there is pressure to reduce the number of concurrent transport flows used by RTP applications. This memo updates [RFC3550] and [RFC3551] to allow multiple media types to be sent in a single RTP session in certain cases, thereby reducing the number of transport layer flows that are needed. It makes no changes to RTP behaviour when using multiple RTP streams containing media of the same type (e.g., multiple audio streams or multiple video streams) in a single RTP session. However Westerlund, et al. Expires June 20, 2016 [Page 2] Internet-Draft Multiple Media Types in an RTP Session December 2015 [I-D.ietf-avtcore-rtp-multi-stream] provides important clarifications to RTP behaviour in that case. This memo is structured as follows. Section 2 defines terminology. Section 3 further describes the background to, and motivation for, this memo and Section 4 describes the scenarios where this memo is applicable. Section 5 discusses issues arising from the base RTP and RTCP specification when using multiple types of media in a single RTP session, while Section 6 considers the impact of RTP extensions. We discuss signalling in Section 7. Finally, security considerations are discussed in Section 8. 2. Terminology The terms Encoded Stream, Endpoint, Media Source, RTP Session, and RTP Stream are used as defined in [RFC7656]. We also define the following terms: Media Type: The general type of media data used by a real-time application. The media type corresponds to the value used in the field of an SDP m= line. The media types defined at the time of this writing are "audio", "video", "text", "image", "application", and "message". [RFC4566] [RFC6466] Quality of Service (QoS): Network mechanisms that are intended to ensure that the packets within a flow or with a specific marking are transported with certain properties. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Background and Motivation RTP was designed to support multimedia sessions, containing multiple types of media sent simultaneously, by using multiple transport layer flows. The existence of network address translators, firewalls, and other middleboxes complicates this, however, since a mechanism is needed to ensure that all the transport layer flows needed by the application can be established. This has three consequences: 1. increased delay to establish a complete session, since each of the transport layer flows needs to be negotiated and established; 2. increased state and resource consumption in the middleboxes that can lead to unexpected behaviour when middlebox resource limits are reached; and Westerlund, et al. Expires June 20, 2016 [Page 3] Internet-Draft Multiple Media Types in an RTP Session December 2015 3. increased risk that a subset of the transport layer flows will fail to be established, thus preventing the application from communicating. Using fewer transport layer flows can hence be seen to reduce the risk of communication failure, and can lead to improved reliability and performance. One of the benefits of using multiple transport layer flows is that it makes it easy to use network layer quality of service (QoS) mechanisms to give differentiated performance for different flows. However, we note that many RTP-using application don't use network QoS features, and don't expect or desire any separation in network treatment of their media packets, independent of whether they are audio, video or text. When an application has no such desire, it doesn't need to provide a transport flow structure that simplifies flow based QoS. Given the above issues, it might seem appropriate for RTP-based applications to send all their RTP streams bundled into one RTP session, running over a single transport layer flow. However, this is prohibited by the RTP specification, because the design of RTP makes certain assumptions that can be incompatible with sending multiple media types in a single RTP session. Specifically, the RTP control protocol (RTCP) timing rules assume that all RTP media flows in a single RTP session have broadly similar RTCP reporting and feedback requirements, which can be problematic when different types of media are multiplexed together. Various RTP extensions also make assumptions about SSRC use and RTCP reporting that are incompatible with sending different media types in a single RTP session. This memo updates [RFC3550] and [RFC3551] to allow RTP sessions to contain more than one media type in certain circumstances, and gives guidance on when it is safe to send multiple media types in a single RTP session. 4. Applicability This specification has limited applicability, and anyone intending to use it needs to ensure that their application and use case meets the following criteria: Equal treatment of media: The use of a single RTP session normally results in similar network treatment for all types of media used within the session. Applications that require significantly different network quality of service (QoS) or RTCP configuration for different RTP streams are better suited by sending those RTP streams in separate RTP session, using separate transport layer Westerlund, et al. Expires June 20, 2016 [Page 4] Internet-Draft Multiple Media Types in an RTP Session December 2015 flows for each, since that gives greater flexibility. Further guidance on how to provide differential treatment for some media is given in [I-D.ietf-avtcore-multiplex-guidelines] and [RFC7657]. Compatible RTCP Behaviour: The RTCP timing rules enforce a single RTCP reporting interval for all participants in an RTP session. Flows with very different media sending rate or RTCP feedback requirements cannot be multiplexed together, since this leads to either excessive or insufficient RTCP for some flows, depending on how the RTCP session bandwidth, and hence reporting interval, is configured. For example, it is likely infeasible to find a single RTCP configuration that simultaneously suits both a low-rate audio flow with no feedback, and a high-quality video flow with sophisticated RTCP-based feedback. Thus, combining these into a single RTP session is difficult and/or inadvisable. Signalled Support: The extensions defined in this memo are not compatible with unmodified [RFC3550]-compatible endpoints. Their use requires signalling and mutual agreement by all participants within an RTP session. This requirement can be a problem for signalling solutions that can't negotiate with all participants. For declarative signalling solutions, mandating that the session is using multiple media types in one RTP session can be a way of attempting to ensure that all participants in the RTP session follow the requirement. However, for signalling solutions that lack methods for enforcing that a receiver supports a specific feature, this can still cause issues. Consistent support for multiparty RTP sessions: If it is desired to send multiple types of media in a multiparty RTP session, then all participants in that session need to support sending multiple type of media in a single RTP session. It is not possible, in the general case, to implement a gateway that can interconnect an endpoint using multiple types of media sent using separate RTP sessions, with one or more endpoints that send multiple types of media in a single RTP session. One reason for this is that the same SSRC value can safely be used for different streams in multiple RTP sessions, but when collapsed to a single RTP session there is an SSRC collision. This would not be an issue, since SSRC collision detection will resolve the conflict, except that some RTP payload formats and extensions use matching SSRCs to identify related flows, and break when a single RTP session is used. A middlebox that remaps SSRC values when combining multiple RTP sessions into one also needs to be aware of all possible RTCP packet types that might be used, so that it can remap the SSRC Westerlund, et al. Expires June 20, 2016 [Page 5] Internet-Draft Multiple Media Types in an RTP Session December 2015 values in those packets. This is impossible to do without restricting the set of RTCP packet types that can be used to those that are known by the middlebox. Such a middlebox might also have difficulty due to differences in configured RTCP bandwidth and other parameters between the RTP sessions. Finally, the use of a middlebox that translates SSRC values can negatively impact the possibility for loop detection, as SSRC/CSRC can't be used to detect the loops; instead some other RTP stream or media source identity name space that is common across all interconnect parts is needed. Ability to operate with limited payload type space: An RTP session has only a single 7-bit payload type space for all its payload type numbers. Some applications might find this space limiting when using different media types and RTP payload formats within a single RTP session. Avoids incompatible Extensions: Some RTP and RTCP extensions rely on the existence of multiple RTP sessions and relate RTP streams between sessions. Others report on particular media types, and cannot be used with other media types. Applications that send multiple types of media into a single RTP session need to avoid such extensions. 5. Using Multiple Media Types in a Single RTP Session This section defines what needs to be done or avoided to make an RTP session with multiple media types function without issues. 5.1. Allowing Multiple Media Types in an RTP Session Section 5.2 of "RTP: A Transport Protocol for Real-Time Applications" [RFC3550] states: For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address. Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. This specification changes both of these sentences. The first sentence is changed to: For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate Westerlund, et al. Expires June 20, 2016 [Page 6] Internet-Draft Multiple Media Types in an RTP Session December 2015 RTP session with its own destination transport address, unless specification [RFCXXXX] is followed and the application meets the applicability constraints. The second sentence is changed to: Separate audio and video media sources SHOULD NOT be carried in a single RTP session, unless the guidelines specified in [RFCXXXX] are followed. Second paragraph of Section 6 in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] says: The payload types currently defined in this profile are assigned to exactly one of three categories or media types: audio only, video only and those combining audio and video. The media types are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. Payload types of different media types SHALL NOT be interleaved or multiplexed within a single RTP session, but multiple RTP sessions MAY be used in parallel to send multiple media types. An RTP source MAY change payload types within the same media type during a session. See the section "Multiplexing RTP Sessions" of RFC 3550 for additional explanation. This specification's purpose is to override that existing SHALL NOT under certain conditions. Thus this sentence also has to be changed to allow for multiple media type's payload types in the same session. The sentence containing "SHALL NOT" in the above paragraph is changed to: Payload types of different media types SHALL NOT be interleaved or multiplexed within a single RTP session unless [RFCXXXX] is used, and the application conforms to the applicability constraints. Multiple RTP sessions MAY be used in parallel to send multiple media types. RFC-Editor Note: Please replace RFCXXXX with the RFC number of this specification when assigned. 5.2. Demultiplexing media types within an RTP session When receiving packets from a transport layer flow, an endpoint will first separate the RTP and RTCP packets from the non-RTP packets, and pass them to the RTP/RTCP protocol handler. The RTP and RTCP packets are then demultiplexed based on their SSRC into the different RTP streams. For each RTP stream, incoming RTCP packets are processed, and the RTP payload type is used to select the appropriate media Westerlund, et al. Expires June 20, 2016 [Page 7] Internet-Draft Multiple Media Types in an RTP Session December 2015 decoder. This process remains the same irrespective of whether multiple media types are sent in a single RTP session or not. As explained below, it is important to note that the RTP payload type is never used to distinguish RTP streams. The RTP packets are demultiplexed into RTP streams based on their SSRC, then the RTP payload type is used to select the correct media decoding pathway for each RTP stream. 5.3. Per-SSRC Media Type Restrictions An SSRC in an RTP session can change between media formats of the same type, subject to certain restrictions [RFC7160], but MUST NOT change media type during its lifetime. For example, an SSRC can change between different audio formats, but cannot start sending audio then change to sending video. The lifetime of an SSRC ends when an RTCP BYE packet for that SSRC is sent, or when it ceases transmission for long enough that it times out for the other participants in the session. The main motivation is that a given SSRC has its own RTP timestamp and sequence number spaces. The same way that you can't send two encoded streams of audio with the same SSRC, you can't send one encoded audio and one encoded video stream with the same SSRC. Each encoded stream when made into an RTP stream needs to have the sole control over the sequence number and timestamp space. If not, one would not be able to detect packet loss for that particular encoded stream. Nor can one easily determine which clock rate a particular SSRCs timestamp will increase with. For additional arguments why RTP payload type based multiplexing of multiple media sources doesn't work, see [I-D.ietf-avtcore-multiplex-guidelines]. Within an RTP session where multiple media types have been configured for use, an SSRC can only send one type of media during its lifetime (i.e., it can switch between different audio codecs, since those are both the same type of media, but cannot switch between audio and video). Different SSRCs MUST be used for the different media sources, the same way multiple media sources of the same media type already have to do. The payload type will inform a receiver which media type the SSRC is being used for. Thus the payload type MUST be unique across all of the payload configurations independent of media type that is used in the RTP session. 5.4. RTCP Considerations When sending multiple types of media that have different rates in a single RTP session, endpoints MUST follow the guidelines for handling RTCP described in Section 7 of [I-D.ietf-avtcore-rtp-multi-stream]. Westerlund, et al. Expires June 20, 2016 [Page 8] Internet-Draft Multiple Media Types in an RTP Session December 2015 6. Extension Considerations This section outlines known issues and incompatibilities with RTP and RTCP extensions when multiple media types are used in a single RTP sessions. Future extensions to RTP and RTCP need to consider, and document, any potential incompatibility. 6.1. RTP Retransmission Payload Format The RTP Retransmission Payload Format [RFC4588] can operate in either SSRC-multiplexed mode or session-multiplex mode. In SSRC-multiplexed mode, retransmitted RTP packets are sent in the same RTP session as the original packets, but use a different SSRC with the same RTCP SDES CNAME. If each endpoint sends only a single original RTP stream and a single retransmission RTP stream in the session, this is sufficient. If an endpoint sends multiple original and retransmission RTP streams, as would occur when sending multiple media types in a single RTP session, then each original RTP stream and the retransmission RTP stream have to be associated using heuristics. By having retransmission requests outstanding for only one SSRC not yet mapped, a receiver can determine the binding between original and retransmission RTP stream. Another alternative is the use of different RTP payload types, allowing the signalled "apt" (associated payload type) parameter of the RTP retransmission payload format to be used to associate retransmitted and original packets. Session-multiplexed mode sends the retransmission RTP stream in a separate RTP session to the original RTP stream, but using the same SSRC for each, with association being done by matching SSRCs between the two sessions. This is unaffected by the use of multiple media types in a single RTP session, since each media type will be sent using a different SSRC in the original RTP session, and the same SSRCs can be used in the retransmission session, allowing the streams to be associated. This can be signalled using SDP with the BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and FID grouping [RFC5888] extensions. These SDP extensions require each "m=" line to only be included in a single FID group, but the RTP retransmission payload format uses FID groups to indicate the m= lines that form an original and retransmission pair. Accordingly, when using the BUNDLE extension to allow multiple media types to be sent in a single RTP session, each original media source (m= line) that is retransmitted needs a corresponding m= line in the retransmission RTP session. In case there are multiple media lines for retransmission, these media lines will form an independent BUNDLE group from the BUNDLE group with the source streams. Westerlund, et al. Expires June 20, 2016 [Page 9] Internet-Draft Multiple Media Types in an RTP Session December 2015 An example SDP fragment showing the grouping structures is provided in Figure 1. This example is not legal SDP and only the most important attributes have been left in place. Note that this SDP is not an initial BUNDLE offer. As can be seen there are two bundle groups, one for the source RTP session and one for the retransmissions. Then each of the media sources are grouped with its retransmission flow using FID, resulting in three more groupings. a=group:BUNDLE foo bar fiz a=group:BUNDLE zoo kelp glo a=group:FID foo zoo a=group:FID bar kelp a=group:FID fiz glo m=audio 10000 RTP/AVP 0 a=mid:foo a=rtpmap:0 PCMU/8000 m=video 10000 RTP/AVP 31 a=mid:bar a=rtpmap:31 H261/90000 m=video 10000 RTP/AVP 31 a=mid:fiz a=rtpmap:31 H261/90000 m=audio 40000 RTP/AVPF 99 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=0;rtx-time=3000 a=mid:zoo m=video 40000 RTP/AVPF 100 a=rtpmap:100 rtx/90000 a=fmtp:199 apt=31;rtx-time=3000 a=mid:kelp m=video 40000 RTP/AVPF 100 a=rtpmap:100 rtx/90000 a=fmtp:199 apt=31;rtx-time=3000 a=mid:glo Figure 1: SDP example of Session Multiplexed RTP Retransmission 6.2. RTP Payload Format for Generic FEC The RTP Payload Format for Generic Forward Error Correction (FEC) [RFC5109] (and its predecessor [RFC2733]) can either send the FEC stream as a separate RTP stream, or it can send the FEC combined with the original RTP stream as a redundant encoding [RFC2198]. When sending FEC as a separate stream, the RTP Payload Format for generic FEC requires that FEC stream to be sent in a separate RTP session to the original stream, using the same SSRC, with the FEC stream being associated by matching the SSRC between sessions. The Westerlund, et al. Expires June 20, 2016 [Page 10] Internet-Draft Multiple Media Types in an RTP Session December 2015 RTP session used for the original streams can include multiple RTP streams, and those RTP streams can use multiple media types. The repair session only needs one RTP Payload type to indicate FEC data, irrespective of the number of FEC streams sent, since the SSRC is used to associate the FEC streams with the original streams. Hence, it is RECOMMENDED that the FEC stream use the "application/ulpfec" media type for [RFC5109], and the "application/parityfec" media type for [RFC2733]. It is legal, but NOT RECOMMENDED, to send FEC streams using media specific payload format names (e.g., using both the "audio/ulpfec" and "video/ulpfec" payload formats for a single RTP session containing both audio and video flows), since this unnecessarily uses up RTP payload type values, and adds no value for demultiplexing since there might be multiple streams of the same media type). The combination of an original RTP session using multiple media types with an associated generic FEC session can be signalled using SDP with the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation]. In this case, the RTP session carrying the FEC streams will be its own BUNDLE group. The m= line for each original stream and the m= line for the corresponding FEC stream are grouped using the SDP grouping framework using either the FEC-FR [RFC5956] grouping or, for backwards compatibility, the FEC [RFC4756] grouping. This is similar to the situation that arises for RTP retransmission with session multiplexing discussed in Section 6.1. The Source-Specific Media Attributes [RFC5576] specification defines an SDP extension (the "FEC" semantic of the "ssrc-group" attribute) to signal FEC relationships between multiple RTP streams within a single RTP session. This cannot be used with generic FEC, since the FEC repair packets need to have the same SSRC value as the source packets being protected. There was work on an Unequal Layer Protection (ULP) extension to allow it be use FEC RTP streams within the same RTP Session as the source stream [I-D.lennox-payload-ulp-ssrc-mux]. When the FEC is sent as a redundant encoding, the considerations in Section 6.3 apply. 6.3. RTP Payload Format for Redundant Audio The RTP Payload Format for Redundant Audio [RFC2198] can be used to protect audio streams. It can also be used along with the generic FEC payload format to send original and repair data in the same RTP packets. Both are compatible with RTP sessions containing multiple media types. Westerlund, et al. Expires June 20, 2016 [Page 11] Internet-Draft Multiple Media Types in an RTP Session December 2015 This payload format requires each different redundant encoding use a different RTP payload type number. When used with generic FEC in sessions that contain multiple media types, this requires each media type to use a different payload type for the FEC stream. For example, if audio and text are sent in a single RTP session with generic ULP FEC sent as a redundant encoding for each, then payload types need to be assigned for FEC using the audio/ulpfec and text/ ulpfec payload formats. If multiple original payload types are used in the session, different redundant payload types need to be allocated for each one. This has potential to rapidly exhaust the available RTP payload type numbers. 7. Signalling Establishing a single RTP session using multiple media types requires signalling. This signalling has to: 1. ensure that any participant in the RTP session is aware that this is an RTP session with multiple media types; 2. ensure that the payload types in use in the RTP session are using unique values, with no overlap between the media types; 3. ensure RTP session level parameters, for example the RTCP RR and RS bandwidth modifiers, the RTP/AVPF trr-int parameter, transport protocol, RTCP extensions in use, and any security parameters, are consistent across the session; and 4. ensure that RTP and RTCP functions that can be bound to a particular media type are reused where possible, rather than configuring multiple code-points for the same thing. When using SDP signalling, the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to signal RTP sessions containing multiple media types. 8. Security Considerations RTP provides a range of strong security mechanisms that can be used to secure sessions [RFC7201], [RFC7202]. The majority of these are independent of the type of media sent in the RTP session; however it is important to check that the security mechanism chosen is compatible with all types of media sent within the session. Sending multiple media types in a single RTP session will generally require that all use the same security mechanism, whereas media sent using different RTP sessions can be secured in different ways. When different media types have different security requirements, it might Westerlund, et al. Expires June 20, 2016 [Page 12] Internet-Draft Multiple Media Types in an RTP Session December 2015 be necessary to send them using separate RTP sessions to meet those different requirements. This can have significant costs in terms of resource usage, session set-up time, etc. 9. IANA Considerations This memo makes no request of IANA. 10. Acknowledgements The authors would like to thank Christer Holmberg, Gunnar Hellstroem, Charles Eckel, Tolga Asveren, Warren Kumari, and Meral Shirazipour for their feedback on the document. 11. References 11.1. Normative References [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-23 (work in progress), July 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . Westerlund, et al. Expires June 20, 2016 [Page 13] Internet-Draft Multiple Media Types in an RTP Session December 2015 11.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft-ietf-avtcore- multiplex-guidelines-03 (work in progress), October 2014. [I-D.lennox-payload-ulp-ssrc-mux] Lennox, J., "Supporting Source-Multiplexing of the Real- Time Transport Protocol (RTP) Payload for Generic Forward Error Correction", draft-lennox-payload-ulp-ssrc-mux-00 (work in progress), February 2013. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, DOI 10.17487/RFC2733, December 1999, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, DOI 10.17487/RFC4756, November 2006, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . Westerlund, et al. Expires June 20, 2016 [Page 14] Internet-Draft Multiple Media Types in an RTP Session December 2015 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, . [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)", RFC 6466, DOI 10.17487/RFC6466, December 2011, . [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . Authors' Addresses Westerlund, et al. Expires June 20, 2016 [Page 15] Internet-Draft Multiple Media Types in an RTP Session December 2015 Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Westerlund, et al. Expires June 20, 2016 [Page 16] ./draft-ietf-dprive-dnsodtls-15.txt0000664000764400076440000007507213025113205016504 0ustar iustyiusty DPRIVE T. Reddy Internet-Draft Cisco Intended status: Experimental D. Wing Expires: June 19, 2017 P. Patil Cisco December 16, 2016 Specification for DNS over Datagram Transport Layer Security (DTLS) draft-ietf-dprive-dnsodtls-15 Abstract DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over port 853. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 19, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Reddy, et al. Expires June 19, 2017 [Page 1] Internet-Draft DNS over DTLS December 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3 1.2. Document Status . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Establishing and Managing DNS-over-DTLS Sessions . . . . . . 4 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 3.2. DTLS Handshake and Authentication . . . . . . . . . . . . 5 3.3. Established Sessions . . . . . . . . . . . . . . . . . . 5 4. Performance Considerations . . . . . . . . . . . . . . . . . 6 5. PMTU issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS queries and responses are normally exchanged unencrypted and are thus vulnerable to eavesdropping. Such eavesdropping can result in an undesired entity learning domains that a host wishes to access, thus resulting in privacy leakage. The DNS privacy problem is further discussed in [RFC7626]. This document defines DNS over DTLS (DNS-over-DTLS) which provides confidential DNS communication between stub resolvers and recursive resolvers, stub resolvers and forwarders, forwarders and recursive resolvers. DNS-over-DTLS puts an additional computational load on servers. The largest gain for privacy is to protect the communication between the DNS client (the end user's machine) and its caching resolver. DNS-over-DTLS might work equally between recursive Reddy, et al. Expires June 19, 2017 [Page 2] Internet-Draft DNS over DTLS December 2016 clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter. This document does not change the format of DNS messages. The motivations for proposing DNS-over-DTLS are that o TCP suffers from network head-of-line blocking, where the loss of a packet causes all other TCP segments to not be delivered to the application until the lost packet is re-transmitted. DNS-over- DTLS, because it uses UDP, does not suffer from network head-of- line blocking. o DTLS session resumption consumes 1 round trip whereas TLS session resumption can start only after TCP handshake is complete. However, with TCP Fast Open [RFC7413], the implementation can achieve the same RTT efficiency as DTLS. Note: DNS-over-DTLS is an experimental update to DNS, and the experiment will be concluded when the specification is evaluated through implementations and interoperability testing. 1.1. Relationship to TCP Queries and to DNSSEC DNS queries can be sent over UDP or TCP. The scope of this document, however, is only UDP. DNS over TCP can be protected with TLS, as described in [RFC7858]. DNS-over-DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DTLS record size is larger than the path MTU. In such situations the DNS server will respond with a truncated response (see Section 5). Therefore DNS clients and servers that implement DNS-over-DTLS MUST also implement DNS-over-TLS in order to provide privacy for clients that desire Strict Privacy as described in [I-D.ietf-dprive-dtls-and-tls-profiles]. DNS Security Extensions (DNSSEC [RFC4033]) provides object integrity of DNS resource records, allowing end-users (or their resolver) to verify legitimacy of responses. However, DNSSEC does not provide privacy for DNS requests or responses. DNS-over-DTLS works in conjunction with DNSSEC, but DNS-over-DTLS does not replace the need or value of DNSSEC. 1.2. Document Status This document is an Experimental RFC. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large- scale, real-life deployments. Reddy, et al. Expires June 19, 2017 [Page 3] Internet-Draft DNS over DTLS December 2016 This DTLS solution was considered by the DPRIVE working group as an option to use in case the TLS based approach specified in [RFC7858] turns out to have some issues when deployed. At the time of writing, it is expected that [RFC7858] is what will be deployed, and so this specification is mainly intended as a backup. The following guidelines should be considered when performance benchmarking DNS over DTLS: 1. DNS over DTLS can recover from packet loss and reordering, and does not suffer from network head-of-line blocking. DNS over DTLS performance in comparison with DNS over TLS may be better in lossy networks. 2. The number of round trips to send the first DNS query over DNS over DTLS is less than the number of round trips to send the first DNS query over TLS. Even if TCP Fast Open is used, it only works for subsequent TCP connections between the DNS client and server (Section 3 in [RFC7413]). 3. If DTLS 1.3 protocol [I-D.rescorla-tls-dtls13] is used for DNS over DTLS, it provides critical latency improvements for connection establishment over DTLS 1.2. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 3. Establishing and Managing DNS-over-DTLS Sessions 3.1. Session Initiation By default, DNS-over-DTLS MUST run over standard UDP port 853 as defined in Section 8, unless the DNS server has mutual agreement with its clients to use a port other than 853 for DNS-over-DTLS. In order to use a port other than 853, both clients and servers would need a configuration option in their software. The DNS client should determine if the DNS server supports DNS-over- DTLS by sending a DTLS ClientHello message to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS-over-DTLS. Such another port MUST NOT be port 53 but MAY be from the "first-come, first-served" port range (User Ports [RFC6335], range 1024- 49151) . This recommendation against use Reddy, et al. Expires June 19, 2017 [Page 4] Internet-Draft DNS over DTLS December 2016 of port 53 for DNS-over-DTLS is to avoid complication in selecting use or non-use of DTLS and to reduce risk of downgrade attacks. A DNS server that does not support DNS-over-DTLS will not respond to ClientHello messages sent by the client. If no response is received from that server, and the client has no better round-trip estimate, the client SHOULD retransmit the DTLS ClientHello according to Section 4.2.4.1 of [RFC6347]. After 15 seconds, it SHOULD cease attempts to re-transmit its ClientHello. The client MAY repeat that procedure to discover if DNS-over-DTLS service becomes available from the DNS server, but such probing SHOULD NOT be done more frequently than every 24 hours and MUST NOT be done more frequently than every 15 minutes. This mechanism requires no additional signaling between the client and server. DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT respond to cleartext DNS messages on any port used for DNS-over-DTLS (including, for example, after a failed DTLS handshake). There are significant security issues in mixing protected and unprotected data, therefore UDP connections on a port designated by a given server for DNS-over-DTLS are reserved purely for encrypted communications. 3.2. DTLS Handshake and Authentication DNS client initiates DTLS handshake as described in [RFC6347], following the best practices specified in [RFC7525]. After DTLS negotiation completes, if the DTLS handshake succeeds according to [RFC6347] the connection will be encrypted and is now protected from eavesdropping. DNS privacy requires encrypting the query (and response) from passive attacks. Such encryption typically provides integrity protection as a side-effect, which means on-path attackers cannot simply inject bogus DNS responses. However, to provide stronger protection from active attackers pretending to be the server, the server itself needs to be authenticated. To authenticate the server providing DNS privacy, DNS client MUST use the authenication mechanisms discussed in [I-D.ietf-dprive-dtls-and-tls-profiles]. This document does not propose new ideas for authentication. 3.3. Established Sessions In DTLS, all data is protected using the same record encoding and mechanisms. When the mechanism described in this document is in effect, DNS messages are encrypted using the standard DTLS record encoding. When a user of DTLS wishes to send a DNS message, the data is delivered to the DTLS implementation as an ordinary application Reddy, et al. Expires June 19, 2017 [Page 5] Internet-Draft DNS over DTLS December 2016 data write (e.g., SSL_write()). A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses. To mitigate the risk of unintentional server overload, DNS-over-DTLS clients MUST take care to minimize the number of concurrent DTLS sessions made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one DTLS session. Similarly, servers MAY impose limits on the number of concurrent DTLS sessions being handled for any particular client IP address or subnet. These limits SHOULD be much looser than the client guidelines above, because the server does not know, for example, if a client IP address belongs to a single client, is multiple resolvers on a single machine, or is multiple clients behind a device performing Network Address Translation (NAT). In between normal DNS traffic while the communication to the DNS server is quiescent, the DNS client MAY want to probe the server using DTLS heartbeat [RFC6520] to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time. A DTLS session is terminated by the receipt of an authenticated message that closes the connection (e.g., a DTLS fatal alert). If the server has lost state, a DTLS handshake needs to be initiated with the server. For the server, to mitigate the risk of unintentional server overload, it is RECOMMENDED that the default DNS-over-DTLS server application-level idle time be set to several seconds and not set to less than a second, but no particular value is specified. When no DNS queries have been received from the client after idle time out, the server MUST send a DTLS fatal alert and then destroy its DTLS state. The DTLS fatal alert packet indicates the server has destroyed its state, signaling to the client if it wants to send a new DTLS message it will need to re-establish cryptographic context with the server (via full DTLS handshake or DTLS session resumption). In practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit. 4. Performance Considerations DTLS protocol profile for DNS-over-DTLS is discussed in Section 11 of [I-D.ietf-dprive-dtls-and-tls-profiles]. To reduce the number of octets of the DTLS handshake, especially the size of the certificate in the ServerHello (which can be several kilobytes), DNS clients and servers can use raw public keys [RFC7250] or Cached Information Extension [RFC7924]. Cached Information Extension avoids Reddy, et al. Expires June 19, 2017 [Page 6] Internet-Draft DNS over DTLS December 2016 transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake. TLS False Start [RFC7918] can reduce round-trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query. It is highly advantageous to avoid server-side DTLS state and reduce the number of new DTLS sessions on the server which can be done with TLS Session Resumption without server state [RFC5077]. This also eliminates a round-trip for subsequent DNS-over-DTLS queries, because with [RFC5077] the DTLS session does not need to be re-established. Since responses within a DTLS session can arrive out of order, clients MUST match responses to outstanding queries on the same DTLS connection using the DNS Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability ( [RFC7766], Section 7). 5. PMTU issues Compared to normal DNS, DTLS adds at least 13 octets of header, plus cipher and authentication overhead to every query and every response. This reduces the size of the DNS payload that can be carried. DNS client and server MUST support the EDNS0 option defined in [RFC6891] so that the DNS client can indicate to the DNS server the maximum DNS response size it can reassemble and deliver in the DNS client's network stack. If the DNS client does set the EDNS0 option defined in [RFC6891] then the maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. If the Path MTU is not known, an IP MTU of 1280 bytes SHOULD be assumed. The client sets its EDNS0 value as if DTLS is not being used. The DNS server MUST ensure that the DNS response size does not exceed the Path MTU i.e. each DTLS record MUST fit within a single datagram, as required by [RFC6347]. The DNS server must consider the amount of record expansion expected by the DTLS processing when calculating the size of DNS response that fits within the path MTU. Path MTU MUST be greater than or equal to [DNS response size + DTLS overhead of 13 octets + padding size ([RFC7830]) + authentication overhead of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 of [RFC6347]]. If the DNS server's response were to exceed that calculated value, the server MUST send a response that does fit within that value and sets the TC (truncated) bit. Upon receiving a response with the TC bit set and wanting to receive the entire response, the client behaviour is governed by the current Usage profile [I-D.ietf-dprive-dtls-and-tls-profiles]. For Strict Privacy the client MUST only send a new DNS request for the same resource Reddy, et al. Expires June 19, 2017 [Page 7] Internet-Draft DNS over DTLS December 2016 record over an encrypted transport (e.g. DNS-over-TLS [RFC7858]). Clients using Opportunistic Privacy SHOULD try for the best case (an encrypted and authenticated transport) but MAY fallback to intermediate cases and eventually the worst case scenario (clear text) in order to obtain a response. 6. Anycast DNS servers are often configured with anycast addresses. While the network is stable, packets transmitted from a particular source to an anycast address will reach the same server that has the cryptographic context from the DNS-over-DTLS handshake. But when the network configuration or routing changes, a DNS-over-DTLS packet can be received by a server that does not have the necessary cryptographic context. Clients using DNS-over-DTLS need to always be prepared to re-initiate DTLS handshake and in the worst case this could even happen immediately after re-initiating a new handshake. To encourage the client to initiate a new DTLS handshake, DNS servers SHOULD generate a DTLS fatal alert message in response to receiving a DTLS packet for which the server does not have any cryptographic context. Upon receipt of an un-authenicated DTLS fatal alert, the DTLS client validates the fatal alert is within the replay window (Section 4.1.2.6 of [RFC6347]). It is difficult for the DTLS client to validate that the DTLS fatal alert was generated by the DTLS server in response to a request or was generated by an on- or off- path attacker. Thus, upon receipt of an in-window DTLS fatal alert, the client SHOULD continue re-transmitting the DTLS packet (in the event the fatal alert was spoofed), and at the same time it SHOULD initiate DTLS session resumption. When the DTLS client receives an authenticated DNS response from one of those DTLS sessions, the other DTLS session should be terminated. 7. Usage Two Usage Profiles, Strict and Opportunistic are explained in [I-D.ietf-dprive-dtls-and-tls-profiles]. Using encrypted DNS messages with an authenticated server is most preferred, encrypted DNS messages with an unauthenticated server is next preferred, and plain text DNS messages is least preferred. 8. IANA Considerations This specification uses port 853 already allocated in the IANA port number registry as defined in Section 6 of [RFC7858]. Reddy, et al. Expires June 19, 2017 [Page 8] Internet-Draft DNS over DTLS December 2016 9. Security Considerations The interaction between a DNS client and DNS server requires Datagram Transport Layer Security (DTLS) with a ciphersuite offering confidentiality protection. The guidance given in [RFC7525] MUST be followed to avoid attacks on DTLS. The DNS client SHOULD use the TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling" to check the revocation status of public key certificate of the DNS server. OCSP stapling, unlike OCSP [RFC6960], does not suffer from scale and privacy issues. DNS clients keeping track of servers known to support DTLS enables clients to detect downgrade attacks. To interfere with DNS-over- DTLS, an on- or off-path attacker might send an ICMP message towards the DTLS client or DTLS server. As these ICMP messages cannot be authenticated, all ICMP errors should be treated as soft errors [RFC1122]. If the DNS query was sent over DTLS then the corresponding DNS response MUST only be accepted if it is received over the same DTLS connection. This behavior mitigates all possible attacks described in Measures for Making DNS More Resilient against Forged Answers [RFC5452]. Security considerations in [RFC6347] and [I-D.ietf-dprive-dtls-and-tls-profiles] are to be taken into account. A malicious client might attempt to perform a high number of DTLS handshakes with a server. As the clients are not uniquely identified by the protocol and can be obfuscated with IPv4 address sharing and with IPv6 temporary addresses, a server needs to mitigate the impact of such an attack. Such mitigation might involve rate limiting handshakes from a certain subnet or more advanced DoS/DDoS techniques beyond the scope of this paper. 10. Acknowledgements Thanks to Phil Hedrick for his review comments on TCP and to Josh Littlefield for pointing out DNS-over-DTLS load on busy servers (most notably root servers). The authors would like to thank Simon Josefsson, Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Dickinson, Christian Huitema, Stephane Bortzmeyer, Alexander Mayrhofer, Allison Mankin, Jouni Korhonen, Stephen Farrell, Mirja Kuehlewind, Benoit Claise and Geoff Huston for discussions and comments on the design of DNS-over-DTLS. The authors would like to give special thanks to Sara Dickinson for her help. 11. References Reddy, et al. Expires June 19, 2017 [Page 9] Internet-Draft DNS over DTLS December 2016 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, . [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . Reddy, et al. Expires June 19, 2017 [Page 10] Internet-Draft DNS over DTLS December 2016 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, . 11.2. Informative References [I-D.ietf-dprive-dtls-and-tls-profiles] Dickinson, S., Gillmor, D., and T. Reddy, "Authentication and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf- dprive-dtls-and-tls-profiles-07 (work in progress), October 2016. [I-D.rescorla-tls-dtls13] Rescorla, E. and H. Tschofenig, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft- rescorla-tls-dtls13-00 (work in progress), October 2016. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . Reddy, et al. Expires June 19, 2017 [Page 11] Internet-Draft DNS over DTLS December 2016 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, . [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, . Authors' Addresses Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Reddy, et al. Expires June 19, 2017 [Page 12] Internet-Draft DNS over DTLS December 2016 Dan Wing Email: dwing-ietf@fuggles.com Prashanth Patil Cisco Systems, Inc. Bangalore India Email: praspati@cisco.com Reddy, et al. Expires June 19, 2017 [Page 13] ./draft-ietf-avtcore-rtp-circuit-breakers-18.txt0000664000764400076440000020361612755367056021115 0ustar iustyiusty AVTCORE Working Group C. Perkins Internet-Draft University of Glasgow Updates: 3550 (if approved) V. Singh Intended status: Standards Track callstats.io Expires: February 19, 2017 August 18, 2016 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions draft-ietf-avtcore-rtp-circuit-breakers-18 Abstract The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss, and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure, stopping RTP flows from using excessive resources, and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data, to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any standards-track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Perkins & Singh Expires February 19, 2017 [Page 1] Internet-Draft RTP Circuit Breakers August 2016 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 19, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 7 4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout . . . . . . . . 10 4.2. RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . . 11 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 12 4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 16 4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 17 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 17 6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 19 7. Impact of Explicit Congestion Notification (ECN) . . . . . . 19 8. Impact of Bundled Media and Layered Coding . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] is widely used in voice-over-IP, video teleconferencing, and telepresence systems. Many of these systems run over best-effort UDP/IP networks, and can Perkins & Singh Expires February 19, 2017 [Page 2] Internet-Draft RTP Circuit Breakers August 2016 suffer from packet loss and increased latency if network congestion occurs. Designing effective RTP congestion control algorithms, to adapt the transmission of RTP-based media to match the available network capacity, while also maintaining the user experience, is a difficult but important problem. Many such congestion control and media adaptation algorithms have been proposed, but to date there is no consensus on the correct approach, or even that a single standard algorithm is desirable. This memo does not attempt to propose a new RTP congestion control algorithm. Instead, we propose a small set of RTP circuit breakers: mechanisms that terminate RTP flows in conditions under which there is general agreement that serious network congestion is occurring. The RTP circuit breakers proposed in this memo are a specific instance of the general class of network transport circuit breakers [I-D.ietf-tsvwg-circuit-breaker], designed to act as a protection mechanism of last resort to avoid persistent excessive congestion. To avoid triggering the RTP circuit breaker, any standards-track congestion control algorithms defined for RTP will need to operate within the envelope set by the RTP circuit breaker algorithms defined by this memo. 2. Background We consider congestion control for unicast RTP traffic flows. This is the problem of adapting the transmission of an audio/visual data flow, encapsulated within an RTP transport session, from one sender to one receiver, so that it does not use more capacity than is available along the network path. Such adaptation needs to be done in a way that limits the disruption to the user experience caused by both packet loss and excessive rate changes. Congestion control for multicast flows is outside the scope of this memo. Multicast traffic needs different solutions, since the available capacity estimator for a group of receivers will differ from that for a single receiver, and because multicast congestion control has to consider issues of fairness across groups of receivers that do not apply to unicast flows. Congestion control for unicast RTP traffic can be implemented in one of two places in the protocol stack. One approach is to run the RTP traffic over a congestion controlled transport protocol, for example over TCP, and to adapt the media encoding to match the dictates of the transport-layer congestion control algorithm. This is safe for the network, but can be suboptimal for the media quality unless the transport protocol is designed to support real-time media flows. We do not consider this class of applications further in this memo, as their network safety is guaranteed by the underlying transport. Perkins & Singh Expires February 19, 2017 [Page 3] Internet-Draft RTP Circuit Breakers August 2016 Alternatively, RTP flows can be run over a non-congestion controlled transport protocol, for example UDP, performing rate adaptation at the application layer based on RTP Control Protocol (RTCP) feedback. With a well-designed, network-aware, application, this allows highly effective media quality adaptation, but there is potential to cause persistent congestion in the network if the application does not adapt its sending rate in a timely and effective manner. We consider this class of applications in this memo. Congestion control relies on monitoring the delivery of a media flow, and responding to adapt the transmission of that flow when there are signs that the network path is congested. Network congestion can be detected in one of three ways: 1) a receiver can infer the onset of congestion by observing an increase in one-way delay caused by queue build-up within the network; 2) if Explicit Congestion Notification (ECN) [RFC3168] is supported, the network can signal the presence of congestion by marking packets using ECN Congestion Experienced (CE) marks (this could potentially be augmented by mechanisms such as ConEX [RFC7713], or other future protocol extensions for network signalling of congestion); or 3) in the extreme case, congestion will cause packet loss that can be detected by observing a gap in the received RTP sequence numbers. Once the onset of congestion is observed, the receiver has to send feedback to the sender to indicate that the transmission rate needs to be reduced. How the sender reduces the transmission rate is highly dependent on the media codec being used, and is outside the scope of this memo. There are several ways in which a receiver can send feedback to a media sender within the RTP framework: o The base RTP specification [RFC3550] defines RTCP Reception Report (RR) packets to convey reception quality feedback information, and Sender Report (SR) packets to convey information about the media transmission. RTCP SR packets contain data that can be used to reconstruct media timing at a receiver, along with a count of the total number of octets and packets sent. RTCP RR packets report on the fraction of packets lost in the last reporting interval, the cumulative number of packets lost, the highest sequence number received, and the inter-arrival jitter. The RTCP RR packets also contain timing information that allows the sender to estimate the network round trip time (RTT) to the receivers. RTCP reports are sent periodically, with the reporting interval being determined by the number of SSRCs used in the session and a configured session bandwidth estimate (the number of synchronisation sources (SSRCs) used is usually two in a unicast session, one for each participant, but can be greater if the participants send multiple Perkins & Singh Expires February 19, 2017 [Page 4] Internet-Draft RTP Circuit Breakers August 2016 media streams). The interval between reports sent from each receiver tends to be on the order of a few seconds on average, although it varies with the session bandwidth, and sub-second reporting intervals are possible in high bandwidth sessions, and it is randomised to avoid synchronisation of reports from multiple receivers. RTCP RR packets allow a receiver to report ongoing network congestion to the sender. However, if a receiver detects the onset of congestion part way through a reporting interval, the base RTP specification contains no provision for sending the RTCP RR packet early, and the receiver has to wait until the next scheduled reporting interval. o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more complex and sophisticated reception quality metrics, but do not change the RTCP timing rules. RTCP extended reports of potential interest for congestion control purposes are the extended packet loss, discard, and burst metrics [RFC3611], [RFC7002], [RFC7097], [RFC7003], [RFC6958]; and the extended delay metrics [RFC6843], [RFC6798]. Other RTCP Extended Reports that could be helpful for congestion control purposes might be developed in future. o Rapid feedback about the occurrence of congestion events can be achieved using the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] (or its secure variant, RTP/SAVPF [RFC5124]) in place of the RTP/AVP profile [RFC3551]. This modifies the RTCP timing rules to allow RTCP reports to be sent early, in some cases immediately, provided the RTCP transmission rate keeps within its bandwidth allocation. It also defines transport-layer feedback messages, including negative acknowledgements (NACKs), that can be used to report on specific congestion events. RTP Codec Control Messages [RFC5104] extend the RTP/AVPF profile with additional feedback messages that can be used to influence that way in which rate adaptation occurs, but do not further change the dynamics of how rapidly feedback can be sent. Use of the RTP/AVPF profile is dependent on signalling. o Finally, Explicit Congestion Notification (ECN) for RTP over UDP [RFC6679] can be used to provide feedback on the number of packets that received an ECN Congestion Experienced (CE) mark. This RTCP extension builds on the RTP/AVPF profile to allow rapid congestion feedback when ECN is supported. In addition to these mechanisms for providing feedback, the sender can include an RTP header extension in each packet to record packet transmission times [RFC5450]. Accurate transmission timestamps can be helpful for estimating queuing delays, to get an early indication of the onset of congestion. Perkins & Singh Expires February 19, 2017 [Page 5] Internet-Draft RTP Circuit Breakers August 2016 Taken together, these various mechanisms allow receivers to provide feedback on the senders when congestion events occur, with varying degrees of timeliness and accuracy. The key distinction is between systems that use only the basic RTCP mechanisms, without RTP/AVPF rapid feedback, and those that use the RTP/AVPF extensions to respond to congestion more rapidly. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This interpretation of these key words applies only when written in ALL CAPS. Mixed- or lower-case uses of these key words are not to be interpreted as carrying special significance in this memo. The definition of the RTP circuit breaker is specified in terms of the following variables: o Td is the deterministic RTCP reporting interval, as defined in Section 6.3.1 of [RFC3550]. o Tdr is the sender's estimate of the deterministic RTCP reporting interval, Td, calculated by a receiver of the data it is sending. Tdr is not known at the sender, but can be estimated by executing the algorithm in Section 6.2 of [RFC3550] using the average RTCP packet size seen at the sender, the number of members reported in the receiver's SR/RR report blocks, and whether the receiver is sending SR or RR packets. Tdr is recalculated when each new RTCP SR/RR report is received, but the media timeout circuit breaker (see Section 4.2) is only reconsidered when Tdr increases. o Tr is the network round-trip time, calculated by the sender using the algorithm in Section 6.4.1 of [RFC3550] and smoothed using an exponentially weighted moving average as Tr = (0.8 * Tr) + (0.2 * Tr_new) where Tr_new is the latest RTT estimate obtained from an RTCP report. The weight is chosen so old estimates decay over k intervals. o k is the non-reporting threshold (see Section 4.2). o Tf is the media framing interval at the sender. For applications sending at a constant frame rate, Tf is the inter-frame interval. For applications that switch between a small set of possible frame rates, for example when sending speech with comfort noise, where comfort noise frames are sent less often than speech frames, Tf is set to the longest of the inter-frame intervals of the different frame rates. For applications that send periodic frames but Perkins & Singh Expires February 19, 2017 [Page 6] Internet-Draft RTP Circuit Breakers August 2016 dynamically vary their frame rate, Tf is set to the largest inter- frame interval used in the last 10 seconds. For applications that send less than one frame every 10 seconds, or that have no concept of periodic frames (e.g., text conversation [RFC4103], or pointer events [RFC2862]), Tf is set to the time interval since the previous frame when each frame is sent. o G is the frame group size. That is, the number of frames that are coded together based on a particular sending rate setting. If the codec used by the sender can change its rate on each frame, G = 1; otherwise G is set to the number of frames before the codec can adjust to the new rate. For codecs that have the concept of a group-of-pictures (GoP), G is likely the GoP length. o T_rr_interval is the minimal interval between RTCP reports, as defined in Section 3.4 of [RFC4585]; it is only meaningful for implementations of RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124]. o X is the estimated throughput a TCP connection would achieve over a path, in bytes per second. o s is the size of RTP packets being sent, in bytes. If the RTP packets being sent vary in size, then the average size over the packet comprising the last 4 * G frames MUST be used (this is intended to be comparable to the four loss intervals used in [RFC5348]). o p is the loss event rate, between 0.0 and 1.0, that would be seen by a TCP connection over a particular path. When used in the RTP congestion circuit breaker, this is approximated as described in Section 4.3. o t_RTO is the retransmission timeout value that would be used by a TCP connection over a particular path, in seconds. This MUST be approximated using t_RTO = 4 * Tr when used as part of the RTP congestion circuit breaker. o b is the number of packets that are acknowledged by a single TCP acknowledgement. Following [RFC5348], it is RECOMMENDED that the value b = 1 is used as part of the RTP congestion circuit breaker. 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile The feedback mechanisms defined in [RFC3550] and available under the RTP/AVP profile [RFC3551] are the minimum that can be assumed for a baseline circuit breaker mechanism that is suitable for all unicast applications of RTP. Accordingly, for an RTP circuit breaker to be Perkins & Singh Expires February 19, 2017 [Page 7] Internet-Draft RTP Circuit Breakers August 2016 useful, it needs to be able to detect that an RTP flow is causing excessive congestion using only basic RTCP features, without needing RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports. RTCP is a fundamental part of the RTP protocol, and the mechanisms described here rely on the implementation of RTCP. Implementations that claim to support RTP, but that do not implement RTCP, will be unable to use the circuit breaker mechanisms described in this memo. Such implementations SHOULD NOT be used on networks that might be subject to congestion unless equivalent mechanisms are defined using some non-RTCP feedback channel to report congestion and signal circuit breaker conditions. The RTCP timeout circuit breaker (Section 4.1) will trigger if an implementation of this memo attempts to interwork with an endpoint that does not support RTCP. Implementations that sometimes need to interwork with endpoints that do not support RTCP need to disable the RTP circuit breakers if they don't receive some confirmation via signalling that the remote endpoint implements RTCP (the presence of an SDP "a=rtcp:" attribute in an answer might be such an indication). The RTP Circuit Breaker SHOULD NOT be disabled on networks that might be subject to congestion, unless equivalent mechanisms are defined using some non-RTCP feedback channel to report congestion and signal circuit breaker conditions [I-D.ietf-tsvwg-circuit-breaker]. Three potential congestion signals are available from the basic RTCP SR/RR packets and are reported for each SSRC in the RTP session: 1. The sender can estimate the network round-trip time once per RTCP reporting interval, based on the contents and timing of RTCP SR and RR packets. 2. Receivers report a jitter estimate (the statistical variance of the RTP data packet inter-arrival time) calculated over the RTCP reporting interval. Due to the nature of the jitter calculation ([RFC3550], section 6.4.4), the jitter is only meaningful for RTP flows that send a single data packet for each RTP timestamp value (i.e., audio flows, or video flows where each packet comprises one video frame). 3. Receivers report the fraction of RTP data packets lost during the RTCP reporting interval, and the cumulative number of RTP packets lost over the entire RTP session. These congestion signals limit the possible circuit breakers, since they give only limited visibility into the behaviour of the network. Perkins & Singh Expires February 19, 2017 [Page 8] Internet-Draft RTP Circuit Breakers August 2016 RTT estimates are widely used in congestion control algorithms, as a proxy for queuing delay measures in delay-based congestion control or to determine connection timeouts. RTT estimates derived from RTCP SR and RR packets sent according to the RTP/AVP timing rules are too infrequent to be useful for congestion control, and don't give enough information to distinguish a delay change due to routing updates from queuing delay caused by congestion. Accordingly, we cannot use the RTT estimate alone as an RTP circuit breaker. Increased jitter can be a signal of transient network congestion, but in the highly aggregated form reported in RTCP RR packets, it offers insufficient information to estimate the extent or persistence of congestion. Jitter reports are a useful early warning of potential network congestion, but provide an insufficiently strong signal to be used as a circuit breaker. The remaining congestion signals are the packet loss fraction and the cumulative number of packets lost. If considered carefully, and over an appropriate time frame to distinguish transient problems from long term issues [I-D.ietf-tsvwg-circuit-breaker], these can be effective indicators that persistent excessive congestion is occurring in networks where packet loss is primarily due to queue overflows, although loss caused by non-congestive packet corruption can distort the result in some networks. TCP congestion control [RFC5681] intentionally tries to fill the router queues, and uses the resulting packet loss as congestion feedback. An RTP flow competing with TCP traffic will therefore expect to see a non-zero packet loss fraction, and some variation in queuing latency, in normal operation when sharing a path with other flows, that needs to be accounted for when determining the circuit breaker threshold [I-D.ietf-tsvwg-circuit-breaker]. This behaviour of TCP is reflected in the congestion circuit breaker below, and will affect the design of any RTP congestion control protocol. Two packet loss regimes can be observed: 1) RTCP RR packets show a non-zero packet loss fraction, while the extended highest sequence number received continues to increment; and 2) RR packets show a loss fraction of zero, but the extended highest sequence number received does not increment even though the sender has been transmitting RTP data packets. The former corresponds to the TCP congestion avoidance state, and indicates a congested path that is still delivering data; the latter corresponds to a TCP timeout, and is most likely due to a path failure. A third condition is that data is being sent but no RTCP feedback is received at all, corresponding to a failure of the reverse path. We derive circuit breaker conditions for these loss regimes in the following. Perkins & Singh Expires February 19, 2017 [Page 9] Internet-Draft RTP Circuit Breakers August 2016 4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout An RTCP timeout can occur when RTP data packets are being sent, but there are no RTCP reports returned from the receiver. This is either due to a failure of the receiver to send RTCP reports, or a failure of the return path that is preventing those RTCP reporting from being delivered. In either case, it is not safe to continue transmission, since the sender has no way of knowing if it is causing congestion. An RTP sender that has not received any RTCP SR or RTCP RR packets reporting on the SSRC it is using, for a time period of at least three times its deterministic RTCP reporting interval, Td, without the randomization factor, and using the fixed minimum interval of Tmin=5 seconds, SHOULD cease transmission (see Section 4.5). The rationale for this choice of timeout is as described in Section 6.2 of [RFC3550] ("so that implementations which do not use the reduced value for transmitting RTCP packets are not timed out by other participants prematurely"), as updated by Section 6.1.4 of [I-D.ietf-avtcore-rtp-multi-stream] to account for the use of the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124]. To reduce the risk of premature timeout, implementations SHOULD NOT configure the RTCP bandwidth such that Td is larger than 5 seconds. Similarly, implementations that use the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to values larger than 4 seconds (the reduced limit for T_rr_interval follows Section 6.1.3 of [I-D.ietf-avtcore-rtp-multi-stream]). The choice of three RTCP reporting intervals as the timeout is made following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that participants in an RTP session will timeout and remove an RTP sender from the list of active RTP senders if no RTP data packets have been received from that RTP sender within the last two RTCP reporting intervals. Using a timeout of three RTCP reporting intervals is therefore large enough that the other participants will have timed out the sender if a network problem stops the data packets it is sending from reaching the receivers, even allowing for loss of some RTCP packets. If a sender is transmitting a large number of RTP media streams, such that the corresponding RTCP SR or RR packets are too large to fit into the network MTU, the receiver will generate RTCP SR or RR packets in a round-robin manner. In this case, the sender SHOULD treat receipt of an RTCP SR or RR packet corresponding to any SSRC it sent on the same 5-tuple of source and destination IP address, port, and protocol, as an indication that the receiver and return path are working, preventing the RTCP timeout circuit breaker from triggering. Perkins & Singh Expires February 19, 2017 [Page 10] Internet-Draft RTP Circuit Breakers August 2016 4.2. RTP/AVP Circuit Breaker #2: Media Timeout If RTP data packets are being sent, but the RTCP SR or RR packets reporting on that SSRC indicate a non-increasing extended highest sequence number received, this is an indication that those RTP data packets are not reaching the receiver. This could be a short-term issue affecting only a few RTP packets, perhaps caused by a slow to open firewall or a transient connectivity problem, but if the issue persists, it is a sign of a more ongoing and significant problem (a "media timeout"). The time needed to declare a media timeout depends on the parameters Tdr, Tr, Tf, and on the non-reporting threshold k. The value of k is chosen so that when Tdr is large compared to Tr and Tf, receipt of at least k RTCP reports with non-increasing extended highest sequence number received gives reasonable assurance that the forward path has failed, and that the RTP data packets have not been lost by chance. The RECOMMENDED value for k is 5 reports. When Tdr < Tf, then RTP data packets are being sent at a rate less than one per RTCP reporting interval of the receiver, so the extended highest sequence number received can be expected to be non-increasing for some receiver RTCP reporting intervals. Similarly, when Tdr < Tr, some receiver RTCP reporting intervals might pass before the RTP data packets arrive at the receiver, also leading to reports where the extended highest sequence number received is non-increasing. Both issues require the media timeout interval to be scaled relative to the threshold, k. The media timeout RTP circuit breaker is therefore as follows. When starting sending, calculate MEDIA_TIMEOUT using: MEDIA_TIMEOUT = ceil(k * max(Tf, Tr, Tdr) / Tdr) When a sender receives an RTCP packet that indicates reception of the media it has been sending, then it cancels the media timeout circuit breaker. If it is still sending, then it MUST calculate a new value for MEDIA_TIMEOUT, and set a new media timeout circuit breaker. If a sender receives an RTCP packet indicating that its media was not received, it MUST calculate a new value for MEDIA_TIMEOUT. If the new value is larger than the previous, it replaces MEDIA_TIMEOUT with the new value, extending the media timeout circuit breaker; otherwise it keeps the original value of MEDIA_TIMEOUT. This process is known as reconsidering the media timeout circuit breaker. If MEDIA_TIMEOUT consecutive RTCP packets are received indicating that the media being sent was not received, and the media timeout Perkins & Singh Expires February 19, 2017 [Page 11] Internet-Draft RTP Circuit Breakers August 2016 circuit breaker has not been cancelled, then the media timeout circuit breaker triggers. When the media timeout circuit breaker triggers, the sender SHOULD cease transmission (see Section 4.5). When stopping sending an RTP stream, a sender MUST cancel the corresponding media timeout circuit breaker. 4.3. RTP/AVP Circuit Breaker #3: Congestion If RTP data packets are being sent, and the corresponding RTCP SR or RR packets show non-zero packet loss fraction and increasing extended highest sequence number received, then those RTP data packets are arriving at the receiver, but some degree of congestion is occurring. The RTP/AVP profile [RFC3551] states that: If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable time scale, that is not less than the throughput the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in time scale and throughput. The time scale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. The phase "order of magnitude" in the above means within a factor of ten, approximately. In order to implement this, it is necessary to estimate the throughput a bulk TCP connection would achieve over the path. For a long-lived TCP Reno connection, it has been shown that the TCP throughput, X, in bytes per second, can be estimated using [Padhye]: s X = ------------------------------------------------------------- Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p))) Perkins & Singh Expires February 19, 2017 [Page 12] Internet-Draft RTP Circuit Breakers August 2016 This is the same approach to estimated TCP throughput that is used in [RFC5348]. Under conditions of low packet loss the second term on the denominator is small, so this formula can be approximated with reasonable accuracy as follows [Mathis]: s X = ---------------- Tr*sqrt(2*b*p/3) It is RECOMMENDED that this simplified throughput equation be used, since the reduction in accuracy is small, and it is much simpler to calculate than the full equation. Measurements have shown that the simplified TCP throughput equation is effective as an RTP circuit breaker for multimedia flows sent to hosts on residential networks using ADSL and cable modem links [Singh]. The data shows that the full TCP throughput equation tends to be more sensitive to packet loss and triggers the RTP circuit breaker earlier than the simplified equation. Implementations that desire this extra sensitivity MAY use the full TCP throughput equation in the RTP circuit breaker. Initial measurements in LTE networks have shown that the extra sensitivity is helpful in that environment, with the full TCP throughput equation giving a more balanced circuit breaker response than the simplified TCP equation [Sarker]; other networks might see similar behaviour. No matter what TCP throughput equation is chosen, two parameters need to be estimated and reported to the sender in order to calculate the throughput: the round trip time, Tr, and the loss event rate, p (the packet size, s, is known to the sender). The round trip time can be estimated from RTCP SR and RR packets. This is done too infrequently for accurate statistics, but is the best that can be done with the standard RTCP mechanisms. Report blocks in RTCP SR or RR packets contain the packet loss fraction, rather than the loss event rate, so p cannot be reported (TCP typically treats the loss of multiple packets within a single RTT as one loss event, but RTCP RR packets report the overall fraction of packets lost, and does not report when the packet losses occurred). Using the loss fraction in place of the loss event rate can overestimate the loss. We believe that this overestimate will not be significant, given that we are only interested in order of magnitude comparison ([Floyd] section 3.2.1 shows that the difference is small for steady-state conditions and random loss, but using the loss fraction is more conservative in the case of bursty loss). The congestion circuit breaker is therefore: when a sender that is transmitting at least one RTP packet every max(Tdr, Tr) seconds receives an RTCP SR or RR packet that contains a report block for an SSRC it is using, the sender MUST record the value of the fraction Perkins & Singh Expires February 19, 2017 [Page 13] Internet-Draft RTP Circuit Breakers August 2016 lost field from the report block, and the time since the last report block was received, for that SSRC. If more than CB_INTERVAL (see below) report blocks have been received for that SSRC, the sender MUST calculate the average fraction lost over the last CB_INTERVAL reporting intervals, and then estimate the TCP throughput that would be achieved over the path using the chosen TCP throughput equation and the measured values of the round-trip time, Tr, the loss event rate, p (approximated by the average fraction lost, as is described below), and the packet size, s. The estimate of the TCP throughput, X, is then compared with the actual sending rate of the RTP stream. If the actual sending rate of the RTP stream is more than 10 * X, then the congestion circuit breaker is triggered. The average fraction lost is calculated based on the sum, over the last CB_INTERVAL reporting intervals, of the fraction lost in each reporting interval multiplied by the duration of the corresponding reporting interval, divided by the total duration of the last CB_INTERVAL reporting intervals. The CB_INTERVAL parameter is set to: CB_INTERVAL = ceil(3*min(max(10*G*Tf, 10*Tr, 3*Tdr), max(15, 3*Td))/(3*Tdr)) The parameters that feed into CB_INTERVAL are chosen to give the congestion control algorithm time to react to congestion. They give at least three RTCP reports, ten round trip times, and ten groups of frames to adjust the rate to reduce the congestion to a reasonable level. It is expected that a responsive congestion control algorithm will begin to respond with the next group of frames after it receives indication of congestion, so CB_INTERVAL ought to be a much longer interval than the congestion response. If the RTP/AVPF profile [RFC4585] or the RTP/SAVPF [RFC5124] is used, and the T_rr_interval parameter is used to reduce the frequency of regular RTCP reports, then the value Tdr in the above expression for the CB_INTERVAL parameter MUST be replaced by max(T_rr_interval, Tdr). The CB_INTERVAL parameter is calculated on joining the session, and recalculated on receipt of each RTCP packet, after checking whether the media timeout circuit breaker or the congestion circuit breaker has been triggered. To ensure a timely response to persistent congestion, implementations SHOULD NOT configure the RTCP bandwidth such that Tdr is larger than 5 seconds. Similarly, implementations that use the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to values larger than 4 seconds (the reduced limit for Perkins & Singh Expires February 19, 2017 [Page 14] Internet-Draft RTP Circuit Breakers August 2016 T_rr_interval follows Section 6.1.3 of [I-D.ietf-avtcore-rtp-multi-stream]). The rationale for enforcing a minimum sending rate below which the congestion circuit breaker will not trigger is to avoid spurious circuit breaker triggers when the number of packets sent per RTCP reporting interval is small, and hence the fraction lost samples are subject to measurement artefacts. The bound of at least one packet every max(Tdr, Tr) seconds is derived from the one packet per RTT minimum sending rate of TCP [RFC5405], adapted for use with RTP where the RTCP reporting interval is decoupled from the network RTT. When the congestion circuit breaker is triggered, the sender SHOULD cease transmission (see Section 4.5). However, if the sender is able to reduce its sending rate by a factor of (approximately) ten, then it MAY first reduce its sending rate by this factor (or some larger amount) to see if that resolves the congestion. If the sending rate is reduced in this way and the congestion circuit breaker triggers again after the next CB_INTERVAL RTCP reporting intervals, the sender MUST then cease transmission. An example of such a rate reduction might be a video conferencing system that backs off to sending audio only, before completely dropping the call. If such a reduction in sending rate resolves the congestion problem, the sender MAY gradually increase the rate at which it sends data after a reasonable amount of time has passed, provided it takes care not to cause the problem to recur ("reasonable" is intentionally not defined here, since it depends on the application, media codec, and congestion control algorithm). The RTCP reporting interval of the media sender does not affect how quickly congestion circuit breaker can trigger. The timing is based on the RTCP reporting interval of the receiver that generates the SR/ RR packets from which the loss rate and RTT estimate are derived (note that RTCP requires all participants in a session to have similar reporting intervals, else the participant timeout rules in [RFC3550] will not work, so this interval is likely similar to that of the sender). If the incoming RTCP SR or RR packets are using a reduced minimum RTCP reporting interval (as specified in Section 6.2 of RFC 3550 [RFC3550] or the RTP/AVPF profile [RFC4585]), then that reduced RTCP reporting interval is used when determining if the circuit breaker is triggered. If there are more media streams that can be reported in a single RTCP SR or RR packet, or if the size of a complete RTCP SR or RR packet exceeds the network MTU, then the receiver will report on a subset of sources in each reporting interval, with the subsets selected round- robin across multiple intervals so that all sources are eventually reported [RFC3550]. When generating such round-robin RTCP reports, Perkins & Singh Expires February 19, 2017 [Page 15] Internet-Draft RTP Circuit Breakers August 2016 priority SHOULD be given to reports on sources that have high packet loss rates, to ensure that senders are aware of network congestion they are causing (this is an update to [RFC3550]). 4.4. RTP/AVP Circuit Breaker #4: Media Usability Applications that use RTP are generally tolerant to some amount of packet loss. How much packet loss can be tolerated will depend on the application, media codec, and the amount of error correction and packet loss concealment that is applied. There is an upper bound on the amount of loss that can be corrected, however, beyond which the media becomes unusable. Similarly, many applications have some upper bound on the media capture to play-out latency that can be tolerated before the application becomes unusable. The latency bound will depend on the application, but typical values can range from the order of a few hundred milliseconds for voice telephony and interactive conferencing applications, up to several seconds for some video-on-demand systems. As a final circuit breaker, RTP senders SHOULD monitor the reported packet loss and delay to estimate whether the media is likely to be suitable for the intended purpose. If the packet loss rate and/or latency is such that the media has become unusable, and has remained unusable for a significant time period, then the application SHOULD cease transmission. Similarly, receivers SHOULD monitor the quality of the media they receive, and if the quality is unusable for a significant time period, they SHOULD terminate the session. This memo intentionally does not define a bound on the packet loss rate or latency that will result in unusable media, as these are highly application dependent. Similarly, the time period that is considered significant is application dependent, but is likely on the order of seconds, or tens of seconds. Sending media that suffers from such high packet loss or latency that it is unusable at the receiver is both wasteful of resources, and of no benefit to the user of the application. It also is highly likely to be congesting the network, and disrupting other applications. As such, the congestion circuit breaker will almost certainly trigger to stop flows where the media would be unusable due to high packet loss or latency. However, in pathological scenarios where the congestion circuit breaker does not stop the flow, it is desirable to prevent the application sending unnecessary traffic that might disrupt other uses of the network. The role of the media usability circuit breaker is to protect the network in such cases. Perkins & Singh Expires February 19, 2017 [Page 16] Internet-Draft RTP Circuit Breakers August 2016 4.5. Ceasing Transmission What it means to cease transmission depends on the application. This could mean stopping a single RTP flow, or it could mean that multiple bundled RTP flows are stopped. The intention is that the application will stop sending RTP data packets on a particular 5-tuple (transport protocol, source and destination ports, source and destination IP addresses), until whatever network problem that triggered the RTP circuit breaker has dissipated. RTP flows halted by the circuit breaker SHOULD NOT be restarted automatically unless the sender has received information that the congestion has dissipated, or can reasonably be expected to have dissipated. What could trigger this expectation is necessarily application dependent, but could be, for example, an indication that a competing flow has finished and freed up some capacity, or for an application running on a mobile device, that the device moved to a new location so the flow would traverse a different path if it were restarted. Ideally, a human user will be involved in the decision to try to restart the flow, since that user will eventually give up if the flows repeatedly trigger the circuit breaker. This will help avoid problems with automatic redial systems from congesting the network. It is recognised that the RTP implementation in some systems might not be able to determine if a flow set-up request was initiated by a human user, or automatically by some scripted higher-level component of the system. These implementations MUST rate limit attempts to restart a flow on the same 5-tuple as used by a flow that triggered the circuit breaker, so that the reaction to a triggered circuit breaker lasts for at least the triggering interval [I-D.ietf-tsvwg-circuit-breaker]. The RTP circuit breaker will only trigger, and cease transmission, for media flows subject to long-term persistent congestion. Such flows are likely to have poor quality and usability for some time before the circuit breaker triggers. Implementations can monitor RTCP Reception Report blocks being returned for their media flows, and might find it beneficial to use this information to provide a user interface cue that problems are occurring, in advance of the circuit breaker triggering. 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) [RFC4585] allows receivers to send early RTCP reports in some cases, to inform the sender about particular events in the media stream. There are several use cases for such early RTCP reports, including providing rapid feedback to a sender about the onset of congestion. The RTP/SAVPF Profile [RFC5124] is a secure variant of the RTP/AVPF Perkins & Singh Expires February 19, 2017 [Page 17] Internet-Draft RTP Circuit Breakers August 2016 profile, that is treated the same in the context of the RTP circuit breaker. These feedback profiles are often used with non-compound RTCP reports [RFC5506] to reduce the reporting overhead. Receiving rapid feedback about congestion events potentially allows congestion control algorithms to be more responsive, and to better adapt the media transmission to the limitations of the network. It is expected that many RTP congestion control algorithms will adopt the RTP/AVPF profile or the RTP/SAVPF profile for this reason, defining new transport layer feedback reports that suit their requirements. Since these reports are not yet defined, and likely very specific to the details of the congestion control algorithm chosen, they cannot be used as part of the generic RTP circuit breaker. Reduced-size RTCP reports sent under the RTP/AVPF early feedback rules that do not contain an RTCP SR or RR packet MUST be ignored by the congestion circuit breaker (they do not contain the information needed by the congestion circuit breaker algorithm), but MUST be counted as received packets for the RTCP timeout circuit breaker. Reduced-size RTCP reports sent under the RTP/AVPF early feedback rules that contain RTCP SR or RR packets MUST be processed by the congestion circuit breaker as if they were sent as regular RTCP reports, and counted towards the circuit breaker conditions specified in Section 4 of this memo. This will potentially make the RTP circuit breaker trigger earlier than it would if the RTP/AVPF profile was not used. When using ECN with RTP (see Section 7), early RTCP feedback packets can contain ECN feedback reports. The count of ECN-CE marked packets contained in those ECN feedback reports is counted towards the number of lost packets reported if the ECN Feedback Report is sent in a compound RTCP packet along with an RTCP SR/RR report packet. Reports of ECN-CE packets sent as reduced-size RTCP ECN feedback packets without an RTCP SR/RR packet MUST be ignored. These rules are intended to allow the use of low-overhead RTP/AVPF feedback for generic NACK messages without triggering the RTP circuit breaker. This is expected to make such feedback suitable for RTP congestion control algorithms that need to quickly report loss events in between regular RTCP reports. The reaction to reduced-size RTCP SR/RR packets is to allow such algorithms to send feedback that can trigger the circuit breaker, when desired. The RTP/AVPF and RTP/SAVPF profiles include the T_rr_interval parameter that can be used to adjust the regular RTCP reporting interval. The use of the T_rr_interval parameter changes the behaviour of the RTP circuit breaker, as described in Section 4. Perkins & Singh Expires February 19, 2017 [Page 18] Internet-Draft RTP Circuit Breakers August 2016 6. Impact of RTCP Extended Reports (XR) RTCP Extended Report (XR) blocks provide additional reception quality metrics, but do not change the RTCP timing rules. Some of the RTCP XR blocks provide information that might be useful for congestion control purposes, others provide non-congestion-related metrics. With the exception of RTCP XR ECN Summary Reports (see Section 7), the presence of RTCP XR blocks in a compound RTCP packet does not affect the RTP circuit breaker algorithm. For consistency and ease of implementation, only the reception report blocks contained in RTCP SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets, are used by the RTP circuit breaker algorithm. 7. Impact of Explicit Congestion Notification (ECN) The use of ECN for RTP flows does not affect the RTCP timeout circuit breaker (Section 4.1) or the media timeout circuit breaker (Section 4.2), since these are both connectivity checks that simply determinate if any packets are being received. At the time of this writing, there's no consensus on how the receipt of ECN feedback will impact the congestion circuit breaker (Section 4.3) or indeed whether the congestion circuit breaker ought to take ECN feedback into account. A future version of this memo is expected to provide guidance for implementers. For the media usability circuit breaker (Section 4.4), ECN-CE marked packets arrive at the receiver, and if they arrive in time, they will be decoded and rendered as normal. Accordingly, receipt of such packets ought not affect the usability of the media, and the arrival of RTCP feedback indicating their receipt is not expected to impact the operation of the media usability circuit breaker. 8. Impact of Bundled Media and Layered Coding The RTP circuit breaker operates on a per-RTP session basis. An RTP sender that participates in several RTP sessions MUST treat each RTP session independently with regards to the RTP circuit breaker. An RTP sender can generate several media streams within a single RTP session, with each stream using a different SSRC. This can happen if bundled media are in use, when using simulcast, or when using layered media coding. By default, each SSRC will be treated independently by the RTP circuit breaker. However, the sender MAY choose to treat the flows (or a subset thereof) as a group, such that a circuit breaker trigger for one flow applies to the group of flows as a whole, and either causes the entire group to cease transmission, or the sending rate of the group to reduce by a factor of ten, depending on the RTP Perkins & Singh Expires February 19, 2017 [Page 19] Internet-Draft RTP Circuit Breakers August 2016 circuit breaker triggered. Grouping flows in this way is expected to be especially useful for layered flows sent using multiple SSRCs, as it allows the layered flow to react as a whole, ceasing transmission on the enhancement layers first to reduce sending rate if necessary, rather than treating each layer independently. Care needs to be taken if the different media streams sent on a single transport layer flow use different DSCP values [RFC7657], [I-D.ietf-tsvwg-rtcweb-qos], since congestion could be experienced differently depending on the DSCP marking. Accordingly, RTP media streams with different DSCP values SHOULD NOT be considered as a group when evaluating the RTP Circuit Breaker conditions. 9. Security Considerations The security considerations of [RFC3550] apply. If the RTP/AVPF profile is used to provide rapid RTCP feedback, the security considerations of [RFC4585] apply. If ECN feedback for RTP over UDP/IP is used, the security considerations of [RFC6679] apply. If non-authenticated RTCP reports are used, an on-path attacker can trivially generate fake RTCP packets that indicate high packet loss rates, causing the circuit breaker to trigger and disrupt an RTP session. This is somewhat more difficult for an off-path attacker, due to the need to guess the randomly chosen RTP SSRC value and the RTP sequence number. This attack can be avoided if RTCP packets are authenticated; authentication options are discussed in [RFC7201]. Timely operation of the RTP circuit breaker depends on the choice of RTCP reporting interval. If the receiver has a reporting interval that is overly long, then the responsiveness of the circuit breaker decreases. In the limit, the RTP circuit breaker can be disabled for all practical purposes by configuring an RTCP reporting interval that is many minutes duration. This issue is not specific to the circuit breaker: long RTCP reporting intervals also prevent reception quality reports, feedback messages, codec control messages, etc., from being used. Implementations are expected to impose an upper limit on the RTCP reporting interval they are willing to negotiate (based on the session bandwidth and RTCP bandwidth fraction) when using the RTP circuit breaker, as discussed in Section 4.3. 10. IANA Considerations There are no actions for IANA. Perkins & Singh Expires February 19, 2017 [Page 20] Internet-Draft RTP Circuit Breakers August 2016 11. Acknowledgements The authors would like to thank Bernard Aboba, Harald Alvestrand, Ben Campbell, Alissa Cooper, Spencer Dawkins, Gorry Fairhurst, Stephen Farrell, Nazila Fough, Kevin Gross, Cullen Jennings, Randell Jesup, Mirja Kuehlewind, Jonathan Lennox, Matt Mathis, Stephen McQuistin, Simon Perreault, Eric Rescorla, Abheek Saha, Meral Shirazipour, Fabio Verdicchio, and Magnus Westerlund for their valuable feedback. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . Perkins & Singh Expires February 19, 2017 [Page 21] Internet-Draft RTP Circuit Breakers August 2016 12.2. Informative References [Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", Proceedings of the ACM SIGCOMM conference, 2000, DOI 10.1145/347059.347397, August 2000. [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, Q., and D. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-tsvwg-circuit-breaker] Fairhurst, G., "Network Transport Circuit Breakers", draft-ietf-tsvwg-circuit-breaker-15 (work in progress), April 2016. [I-D.ietf-tsvwg-rtcweb-qos] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- qos-17 (work in progress), May 2016. [Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The macroscopic behavior of the TCP congestion avoidance algorithm", ACM SIGCOMM Computer Communication Review 27(3), DOI 10.1145/263932.264023, July 1997. [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proceedings of the ACM SIGCOMM conference, 1998, DOI 10.1145/285237.285291, August 1998. [RFC2862] Civanlar, M. and G. Cash, "RTP Payload Format for Real- Time Pointers", RFC 2862, DOI 10.17487/RFC2862, June 2000, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, . Perkins & Singh Expires February 19, 2017 [Page 22] Internet-Draft RTP Circuit Breakers August 2016 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, . [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012, . [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, . [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", RFC 6958, DOI 10.17487/RFC6958, May 2013, . [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting", RFC 7002, DOI 10.17487/RFC7002, September 2013, . Perkins & Singh Expires February 19, 2017 [Page 23] Internet-Draft RTP Circuit Breakers August 2016 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, September 2013, . [RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015, . [Sarker] Sarker, Z., Singh, V., and C. Perkins, "An Evaluation of RTP Circuit Breaker Performance on LTE Networks", Proceedings of the IEEE Infocom workshop on Communication and Networking Techniques for Contemporary Video, 2014, April 2014. [Singh] Singh, V., McQuistin, S., Ellis, M., and C. Perkins, "Circuit Breakers for Multimedia Congestion Control", Proceedings of the International Packet Video Workshop, 2013, DOI 10.1109/PV.2013.6691439, December 2013. Authors' Addresses Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Perkins & Singh Expires February 19, 2017 [Page 24] Internet-Draft RTP Circuit Breakers August 2016 Varun Singh Nemu Dialogue Systems Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland Email: varun.singh@iki.fi URI: http://www.callstats.io/ Perkins & Singh Expires February 19, 2017 [Page 25] ./draft-ietf-ipfix-mib-variable-export-10.txt0000664000764400076440000055340612623741351020362 0ustar iustyiusty Internet Engineering Task Force (IETF) P. Aitken, Ed. Internet-Draft Brocade Communications Systems, Inc. Intended status: Standards Track B. Claise Expires: May 24, 2016 S. B S Cisco Systems, Inc. C. McDowall Brocade Communications Systems, Inc. J. Schoenwaelder Jacobs University Bremen November 21, 2015 Exporting MIB Variables using the IPFIX Protocol draft-ietf-ipfix-mib-variable-export-10 Abstract This document specifies a way to complement IPFIX Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 24, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Aitken, et al. Expires May 24, 2016 [Page 1] Internet-Draft Exporting MIB Variables with IPFIX November 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. High Level Solution Overview . . . . . . . . . . . . . . . . 7 5. MIB Object Value Information Elements and the MIB Field Options Template . . . . . . . . . . . . . . . . . . . . . . 8 5.1. MIB Field Options Architecture . . . . . . . . . . . . . 9 5.2. IPFIX and MIB Data Model . . . . . . . . . . . . . . . . 12 5.3. MIB Field Options - Specifications and Required Fields . 13 5.3.1. MIB Field Options Template . . . . . . . . . . . . . 14 5.3.2. MIB Type Options Template . . . . . . . . . . . . . . 14 5.4. MIB Field Options Template Formats . . . . . . . . . . . 15 5.4.1. Data Template containing a mibObject Field . . . . . 15 5.4.2. MIB Field Options Template . . . . . . . . . . . . . 16 5.4.3. MIB Field Options Data Records . . . . . . . . . . . 18 5.4.4. Options Template containing a mibObject Field . . . . 19 5.4.5. MIB Field Options Template with Semantics Fields . . 20 5.4.6. MIB Field Options Template with extra MIB Object Details . . . . . . . . . . . . . . . . . . . . . . . 21 5.5. Use of field order in the MIB Field Option template . . . 24 5.6. Identifying the SNMP Context . . . . . . . . . . . . . . 24 5.7. Template Management . . . . . . . . . . . . . . . . . . . 25 5.7.1. Large Messages . . . . . . . . . . . . . . . . . . . 25 5.7.2. Template Withdrawal and Reuse . . . . . . . . . . . . 26 5.8. Exporting Conceptual Rows and Tables . . . . . . . . . . 26 5.8.1. Exporting Conceptual Rows - indexing . . . . . . . . 26 5.8.2. Exporting Conceptual Rows - mibObjectValueRow . . . . 27 5.8.3. Exporting Conceptual Rows - Augments . . . . . . . . 33 5.8.4. Exporting Conceptual Tables - mibObjectValueTable . . 34 5.8.5. Exporting Columnar Objects - using mibIndexIndicator 35 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Non Columnar MIB Object: Established TCP Connections . . 37 6.2. Enterprise Specific MIB Object: Detailing CPU Load History . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.3. Exporting a Conceptual Row: The OSPF Neighbor Row . . . . 43 6.4. Exporting Augmented Conceptual Row: The IF-MIB id to name Aitken, et al. Expires May 24, 2016 [Page 2] Internet-Draft Exporting MIB Variables with IPFIX November 2015 mapping . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.5. Exporting a Columnar Object: The ipIfStatsInForwDatagrams 51 6.6. Exporting a Columnar Object indexed by IEs: ifOutQLen . . 55 6.7. Exporting With Multiple Contexts: The OSPF Neighbor Row Revisited . . . . . . . . . . . . . . . . . . . . . . . . 59 7. Configuration Considerations . . . . . . . . . . . . . . . . 62 8. The Collecting Process's Side . . . . . . . . . . . . . . . . 62 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 11.1. New IPFIX Semantics . . . . . . . . . . . . . . . . . . 64 11.1.1. snmpCounter . . . . . . . . . . . . . . . . . . . . 64 11.1.2. snmpGauge . . . . . . . . . . . . . . . . . . . . . 64 11.2. New IPFIX Information Elements . . . . . . . . . . . . . 65 11.2.1. New MIB Value Information Elements . . . . . . . . . 65 11.2.2. New MIB Field Options Information Elements . . . . . 71 11.2.3. New MIB Type Information Elements . . . . . . . . . 75 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 76 13.2. Informative References . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 1. Introduction There is growing interest in using IPFIX as a push mechanism for exporting management information. Using a push protocol such as IPFIX instead of a polling protocol like SNMP is especially interesting in situations where large chunks of repetitive data need to be exported periodically. While initially targeted at different problems, there is a large parallel between the information transported via IPFIX and SNMP. Furthermore, certain Management Information Base (MIB) objects are highly relevant to flows as they are understood today. For example, in the IPFIX information model [IANA-IPFIX], Information Elements coming from the SNMP world have already been specified, e.g., ingressInterface and egressInterface both refer to the ifIndex defined in [RFC2863]. In particular the Management Information Base was designed as a separate system of definitions which opens up the possibility of exporting Objects defined via the MIB over other protocols. Rather than mapping existing MIB objects to IPFIX Information Elements on a case by case basis, it would be advantageous to enable the export of any existing or future MIB objects as part of an IPFIX Data Record. This way, the duplication of data models [RFC3444], Aitken, et al. Expires May 24, 2016 [Page 3] Internet-Draft Exporting MIB Variables with IPFIX November 2015 both as SMIv2 MIB objects and IPFIX Information Elements, out of the same information model [RFC3444] would be avoided. Therefore the primary goals of this document are: o to specify a way to complement IPFIX Data Records with Management Information Base (MIB) objects; o to avoid the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified; o to allow the correlation of SNMP and IPFIX sourced data by exporting them together; o to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX based collection infrastructures. 2. Motivation The intended scope of this work is the addition of MIB variable(s) to IPFIX Information Elements in Data Records, in order to complement the Records with useful and already standardized information. Special consideration is given to the case of an existing Template Record which needs to be augmented with some MIB variables whose index is already present in the Template Record as an IPFIX Information Element. For example a 7-tuple Record containing the ingressInterface Information Element, which needs to be augmented by interface counters [RFC2863] which are indexed by the respective ingressInterface values which are already contained in the Data Records. See Section 3 for terminology definitions. Many Data Records contain the ingressInterface and/or the egressInterface Information Elements. These Information Elements carry an ifIndex value, a MIB object defined in [RFC2863]. In order to retrieve additional information about the identified interface, a Collector could simply poll relevant objects from the device running the Exporter via SNMP. However, that approach has several problems: o It requires implementing a mediation function between two data models, i.e., MIB objects and IPFIX Information Elements. o Confirming the validity of simple mappings (e.g., ifIndex to ifName) requires either checking on a regular basis that the Exporter's network management system did not reload, or imposing ifIndex persistence across an Exporter's reload. Aitken, et al. Expires May 24, 2016 [Page 4] Internet-Draft Exporting MIB Variables with IPFIX November 2015 o Synchronization problems occur since counters carried in Data Records and counters carried in SNMP messages are retrieved from the Exporter at different points in time and thus cannot be correlated. In the best case, assuming very tight integration of an IPFIX Collector with an SNMP polling engine, SNMP data is retrieved shortly after Data Records have been received, which implies a delay of the sum of the active or inactive timeouts (if not null) plus the time to export the Data Record to the Collector. If, however, the SNMP data is retrieved by a generic Network Management Station (NMS) polling interface statistics, then the time lag between IPFIX counters and SNMP counters can be significantly higher. See [RFC5470] section 5.1.1. "Flow Expiration" for details of active and inactive timeouts. This document does not specify how to carry SNMP notifications in IPFIX, even if the specifications in this document could potentially allow this. Since IPFIX is a push mechanism, initiated from the Exporter with no acknowledgment method, this specification does not provide the ability to execute configuration changes. The Distributed Management Expression MIB [RFC2982], which is a mechanism to create new MIB variables based on the content of existing ones, could also be advantageous in the context of this specification. Indeed, newly created MIB objects (for example, the link utilization MIB variable), created with the Distributed Management Expression MIB [RFC2982] could nicely complement Data Records. Another advantage of exporting MIB objects via IPFIX is that IPFIX would benefit from an extended series of types to be exported. The simple and application-wide data types specified in SMIv2 [RFC2578], along with new Textual Conventions, can be exported within IPFIX and then decoded in the Collector. However, since a Textual Convention can contain almost any name, this document does not extend the existing informationElementDataType registry [IANA-IPFIX]. The overall architectural model is depicted in Figure 1. The IPFIX Exporter accesses the device's instrumentation, which follows the specifications contained in MIB modules. Other management interfaces such as NETCONF or the device's Command Line Interface (CLI) may provide access to the same instrumentation. Aitken, et al. Expires May 24, 2016 [Page 5] Internet-Draft Exporting MIB Variables with IPFIX November 2015 +------+ +-------+ +.........+ +.....+ | SNMP | | IPFIX | : NETCONF : : CLI : +------+ +-------+ +.........+ +.....+ | | | | +--------------------------------------------+ | Instrumentation (specified in MIB modules) | +--------------------------------------------+ Figure 1: Architectural Model 3. Terminology IPFIX-specific terminology (Information Element, Template, Template Record, Options Template Record, Template Set, Collector, Exporter, Data Record, etc.) used in this document is defined in Section 2 of [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized. This document prefers the more generic term "Data Record" (as opposed to "Flow Record") in relation to the export of MIB objects. Object Identifier (MIB OID) An Object Identifier value is an ordered list of non-negative numbers. For the SMIv2, each number in the list is referred to as a sub-identifier. There are at most 128 sub-identifiers in a value, and each sub-identifier has a maximum value of 2^32 - 1 (4294967295 decimal). See [RFC2578] Section 3.5. MIB Object Identifier Information Element An IPFIX Information Element ("mibObjectIdentifier") which denotes that a MIB Object Identifier (MIB OID) is exported in the (Options) Data Record. See Section 11.2.2.1. SMIv2 Terminology The key words "MIB Module", "MIB Object", "INDEX", "AUGMENTS", "textual convention", "columnar object", "conceptual row", and "conceptual table" in this document are to be interpreted as described in SMIv2 [RFC2578] SMIv2 SYNTAX The SYNTAX key words "INTEGER", "Integer32", "OCTET STRING", "OBJECT IDENTIFIER", "BITS construct", "IpAddress", "Counter32", "Gauge32", "TimeTicks", "Opaque", "Counter64", "Unsigned32", Aitken, et al. Expires May 24, 2016 [Page 6] Internet-Draft Exporting MIB Variables with IPFIX November 2015 "SEQUENCE", and "SEQUENCE OF" in this document are to be interpreted as described in SMIv2 [RFC2578]. SNMP Context Terminology The key words "snmpEngineID", "contextEngineID", and "contextName" in this document are to be interpreted as described in [RFC3411] mibObjectValue Information Elements Refers to any and all of the mibObjectValue Information Elements generically. Any restriction or requirement in this document that refers to mibObjectValue applies to the following Information Elements defined in Section 11.2.1: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueIPAddress, mibObjectValueBITS, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned, mibObjectValueTable, and mibObjectValueRow. IE Used as a shorthand for "Information Element" [RFC7011] in the figures. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. High Level Solution Overview This document specifies a method for creating IPFIX Options Templates that are used to export the extra data required to describe MIB variables (see Section 5.1). This allows IPFIX Templates to contain any combination of fields defined by traditional IPFIX Information Element(s) and/or MIB Object Identifier(s). The MIB Object Identifiers can reference either non- columnar or columnar MIB object(s). Enterprise-specific MIB Object Identifiers are also supported. This document also defines two standard IPFIX Options Templates (see Section 5.3) that are used as part of the mechanism to export MIB object meta data: o MIB Field Options Template (Section 5.3.1) Aitken, et al. Expires May 24, 2016 [Page 7] Internet-Draft Exporting MIB Variables with IPFIX November 2015 o MIB Type Options Template (Section 5.3.2) This document defines three classes of new IPFIX Information Elements. These are used to export values from the MIB, export required Object Identifier information, and optionally export type data from a MIB Module: o MIB Object Value Information Elements (Section 11.2.1) o MIB Field Options Information Elements (Section 11.2.2) o MIB Type Information Information Elements (Section 11.2.3) Additionally, this document defines two new IPFIX semantics which are required for the new Information Elements: o snmpCounter (Section 11.1.1) o snmpGauge (Section 11.1.2) Two common types defined in the SMIv2 are conceptual rows and conceptual tables. It is desirable that exporting a complete or partial conceptual row is simple and efficient. This is accomplished by using IPFIX Structured Data [RFC6313] to reduce repetition of Object Identifier and indexing data. To allow the use of individual columnar objects that make up a conceptual row, a method is also specified to detail that a MIB object is indexed by other fields in the same Data Flow. For an individually indexed mibObjectValue the INDEX fields are sent as any of the other fields in the same Record, and may be mibObjectValue Information Element(s) or other existing Information Element(s). Also, in some cases Exporters may not want (or be able) to export the full information on how the MIB objects being exported are indexed. This may be because the MIB object is being used purely as type information or the Exporting Process may not have knowledge of the indexing required. Therefore providing index information for Columnar Objects is optional. 5. MIB Object Value Information Elements and the MIB Field Options Template This document defines new mibObjectValue Information Elements (in Section 11.2.1). These are used to export MIB objects as part of standard IPFIX Templates. The mibObjectValue Information Elements contain the actual data values. Aitken, et al. Expires May 24, 2016 [Page 8] Internet-Draft Exporting MIB Variables with IPFIX November 2015 The Metering or Exporting Process may extract the data values for mibObjectValue Information Elements from a Process that resides on the same device or may capture or create the data required to match the definition of the MIB object. In particular exporting a value of a MIB object defined in a certain MIB module does not imply that the SNMP process on the device supports that MIB module. The main issue that arises from exporting values of MIB objects in IPFIX is that MIB Object Identifiers do not fit into the standard IPFIX Template format [RFC7011], as this only provides a 16-bit Information Element identifier. The values of a MIB object could be exported using a MIB specific Information Element without providing any Object Identifiers. However, without exporting the actual MIB OID the full type of the data would be unknown and every Field containing MIB object data would appear identical. Without knowing which OID the contents of a field map to, the data would be incomprehensible to a Collector. For the values in the mibObjectValue Information Elements to be understandable, more meta information about the mibObjectValue Information Elements must be sent as part of the IPFIX export. The required minimum to understand each field is the OID as defined in Section 5.3.1. One approach to this problem would be to extend the IPFIX standard to allow extended field specifiers so metadata about fields can be included in Data Templates. This would however require a new version of the IPFIX standard which may not be backwards compatible. However, future versions of IPFIX may export the required MIB metadata as part of newly defined IPFIX Set versions. This document defines a MIB Field Options Template to export the extra meta information required for mibObjectValue Information Elements. This is a standard IPFIX Options Template Set which includes a minimum set of required fields (see Section 5.3.1) and may include extra fields to provide more meta information about one of the mibObjectValue Information Elements. The MIB Field Options export is used to tell the Collecting process: for the following (template, field) the MIB Object type definition has this OID. 5.1. MIB Field Options Architecture Four IPFIX Sets are used together to export a Flow which contains mibObjectValue Information Elements. These are: Aitken, et al. Expires May 24, 2016 [Page 9] Internet-Draft Exporting MIB Variables with IPFIX November 2015 1. A Template Set which includes the mibObjectValue Information Element. The Template Set informs the Collector that a MIB object value of length N will be exported. This Set may also be an Options Template Set. 2. A MIB Field Options Template Set The MIB Field Options Template describes which metadata will be sent for each mibObjectValue Information Element being exported. 3. A MIB Field Options Data Set The MIB Field Options Data Set includes the metadata for each MIB object (i.e., the mibObjectIdentifier or mibSubIdentifier). The metadata about the mibObjectValue Information Elements only needs to be resent as per normal Template refreshes or resends. 4. A Data Set. The Data Set contains only the actual data extracted from the MIB or described by the MIB module. Figure 2 shows the IPFIX Message structure for a MIB Field in a Template Set. +-------------------------------------------------------+ | IPFIX Message Header | +-------------------------------------------------------+ | Template Set (A) | +-------------------------------------------------------+ | Options Template Set (B) (MIB Field Options Template) | +-------------------------------------------------------+ | Data Set (B) (MIB Field Options Data) | +-------------------------------------------------------+ | Data Set (A) | +-------------------------------------------------------+ Figure 2: IPFIX Message structure for a MIB Field in a Template Set The MIB Field Options Template defines MIB Field Options Data Records. The MIB Field Options Data Records annotate the Data Template with mibObjectValue metadata. Together the Data Template and MIB Field Options Data Records define the Data Records that will be exported. Aitken, et al. Expires May 24, 2016 [Page 10] Internet-Draft Exporting MIB Variables with IPFIX November 2015 The Data Records (A) have a dependency on the two Templates and the MIB Field Options Data Records. More Data Sets that use the same mibObjectValue Information Element can then be send in subsequent packets. Figure 3 shows the relationships between the Sets discussed above. +------------------------------+ |MIB Field Options Template (B)| +------------------------------+ |(templateId, elementIndex) | +------------------------------+ | mibOID | +------------------------------+ | | Defines V +------------------------+ +--------------------------+ | Data Template (A) | |MIB Field Options Data (B)| +------------------------+ +--------------------------+ |Field 0 - regular IE | | | +------------------------+ +--------------------------+ |Field 1-mibObjectValue | <----------- | (X,1) = OID | +------------------------+ Annotates +--------------------------+ |Field 2-mibObjectValue | <----------- | (X,2) = OID | +------------------------+ +--------------------------+ | | |------------------------------------/ | | Defines | V +------------------------+ | Data Records (A) | |------------------------| | Field 0 data | +------------------------+ | Field 1 data | +------------------------+ | Field 2 data | +------------------------+ Figure 3: Relationships between Sets Aitken, et al. Expires May 24, 2016 [Page 11] Internet-Draft Exporting MIB Variables with IPFIX November 2015 5.2. IPFIX and MIB Data Model [RFC2578] specifies that the SYNTAX clause for a MIB object defines the abstract data structure of an Object and what it must contain: "The data structure must be one of the following: a base type, the BITS construct, or a textual convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see section 7.1.12)." (From [RFC2578] section 7.1). For each of the SYNTAX clause options this document specifies exactly which mibObjectValue Information Element to use. If a MIB object to be exported is a Textual Convention, the definition of the Textual Convention must be consulted and the SYNTAX clause used to determine the correct base type. This may recurse if the Textual Convention is defined in terms of another Textual Convention but this should end at a base type. If the SYNTAX clause contains a Textual Convention or Subtyping the mibObjectSyntax Information Element SHOULD be used to export this detail to the Collecting Process. The Options for the SYNTAX are then mapped as follows: +-----------------+---------------------+---------------------------+ | RFC2578 Section | SYNTAX | mibObjectValue IE | +-----------------+---------------------+---------------------------+ | 7.1.1 | INTEGER/Integer32 | mibObjectValueInteger | | 7.1.2 | OCTET STRING | mibObjectValueOctetString | | 7.1.3 | OBJECT IDENTIFIER | mibObjectValueOID | | 7.1.4 | The BITS construct | mibObjectValueBits | | 7.1.5 | IpAddress | mibObjectValueIPAddress | | 7.1.6 | Counter32 | mibObjectValueCounter | | 7.1.7 | Gauge32 | mibObjectValueGauge | | 7.1.8 | TimeTicks | mibObjectValueTimeTicks | | 7.1.9 | Opaque | mibObjectValueOctetString | | 7.1.10 | Counter64 | mibObjectValueCounter | | 7.1.11 | Unsigned32 | mibObjectValueUnsigned | | 7.1.12 | SEQUENCE | mibObjectValueRow or | | | | mibObjectValueTable | +-----------------+---------------------+---------------------------+ Table 1: SMIv2 SYNTAX to mibObjectValue types Values are encoded as per the standard IPFIX encoding of Abstract Data Types. The only new encoding reference in this document is that Aitken, et al. Expires May 24, 2016 [Page 12] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Object Identifiers (OID) will be encoded as per ASN.1/BER [BER] in an octetArray. The mibObjectValue and mibObjectIdentifier Information Elements are standard IPFIX fields. Therefore the E bit of the mibObjectValue or mibObjectIdentifier Information Elements is set to "0". The MIB object being exported may be defined in an enterprise- specific MIB module but the Information Elements defined in this standard are still exported with the E bit set to "0". The OID exported encodes that the MIB object was defined in a enterprise- specific MIB Module. 5.3. MIB Field Options - Specifications and Required Fields For each mibObjectValue Information Element that is defined in an IPFIX Template, a MIB Field Options Data Record will be exported that provides the required minimum information to define the MIB object that is being exported (see Section 5.3.1). The MIB Field Options Data Records are defined in a template referred to in this document as a MIB Field Options Template with the format specified in Section 5.4. The MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message as any Template that is using a mibObjectValue Information Element. Note that this places an implicit size constraint on the export. This whole set of Templates and MIB Field Options Data Records MUST all be exported prior to the corresponding Data Records which depend upon them. i.e., the export order MUST be: 1. Data Template for mibObjectValue Information Elements (Set ID 2) 2. MIB Field Options Template (Set ID 3) 3. MIB Field Options Data Records (Set ID >= 256) 4. MIB Object Value Data Records (Set ID >= 256) Note that the ID of an identical MIB Field Options Template which has already been exported MAY be reused without exporting the Template again. IPFIX Set IDs are defined in section 3.3.2 of [RFC7011]. A value of 2 indicates a Template Set, a value of 3 indicates an Options Template Set, and values 256 and above indicate Data Sets. Aitken, et al. Expires May 24, 2016 [Page 13] Internet-Draft Exporting MIB Variables with IPFIX November 2015 5.3.1. MIB Field Options Template Three fields are REQUIRED to unambiguously export a standalone mibObjectValue Information Element with a MIB Field Options Template: o (scope) templateId [IANA-IPFIX] o (scope) informationElementIndex [IANA-IPFIX] o mibObjectIdentifier (Section 11.2.2.1) or mibSubIdentifier (Section 11.2.2.2) These are the minimum fields required in a MIB Field Options Template (see Section 5.4.2). The mibObjectIdentifier is used to provide the OID for all mibObjectValue Information Elements exported except for when Structured Data is being used to export a conceptual row (see Section 5.8.2). While the following are optional, they are nevertheless RECOMMENDED in certain circumstances as described in the referenced sections: o mibCaptureTimeSemantics (discussed in Section 5.4.5; IE defined in Section 11.2.2.4) o mibIndexIndicator (discussed in Section 5.8.5; IE defined in Section 11.2.2.3) o mibContextEngineID (discussed in Section 5.6; IE defined in Section 11.2.2.5) o mibContextName (discussed in Section 5.6; IE defined in Section 11.2.2.6) 5.3.2. MIB Type Options Template There are also fields that provide type information from a MIB object definition that MAY be exported to a Collecting Process. Type information is statically defined in a MIB module; it is not expected to change. However, the additional information about the MIB object may help a Collecting Process that does not have access to the MIB module. To export a MIB Type Options Template, the mibObjectIdentifier is RECOMMENDED as a Scope Field so that it matches the MIB Field Options Aitken, et al. Expires May 24, 2016 [Page 14] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Template. Any combination of the other MIB Type fields may be included. o (scope) mibObjectIdentifier (see Section 11.2.2.1) o mibObjectName (see Section 11.2.3.1) o mibObjectDescription (see Section 11.2.3.2) o mibObjectSyntax (see Section 11.2.3.3) o mibModuleName (see Section 11.2.3.4) 5.4. MIB Field Options Template Formats 5.4.1. Data Template containing a mibObject Field The Template Record format of a Template that uses a mibObjectValue Information Element is identical to the standard IPFIX format as defined in [RFC7011], so a field using a mibObjectValue Information Element is specified using standard IPFIX Field Specifiers as in [RFC7011]. The only extra requirement on a Template Record using mibObjectValue Information Element is that it MUST export the required metadata specified for EACH mibObjectValue Information Element (see Section 5.3.1). If Multiple MIB Field Options Data Records that refer to a mibObjectValue are received the latest MUST be used. This matches the expected behavior of IPFIX Templates. There is a one to one mapping between each mibObjectValue Information Element and a MIB Field Options Data Record. A MIB Field Options Template and corresponding Data Record MUST be exported to provide the minimum required metadata. Figure 4 shows an IPFIX Template Set using a mibObjectValue Information Element. Aitken, et al. Expires May 24, 2016 [Page 15] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = Existing IPFIX Field | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = | Field Length (MIB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IPFIX Template Set using mibObjectValue Information Element Where: One of the mibObjectValue IPFIX Information Elements that denotes that a MIB object data (i.e., the value of a MIB object) will be exported in the (Options) Template Record. This could be any one of the mibObjectValue Information Elements defined in Section 11.2.1: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueIPAddress, mibObjectValueBITS, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned, mibObjectValueTable, and mibObjectValueRow. When a mibObjectValue Information Element is used, the MIB Object Identifier ("mibObjectIdentifier") MUST be exported via a MIB Field Options or by other means. See Section 5.3.1. Field Length (MIB) The length of the encoded MIB object data in the corresponding Data Records, in octets. The definition is as [RFC7011]. Note that the Field Length can be expressed using reduced size encoding per [RFC7011]. Note that the Field Length may be encoded using variable-length encoding per [RFC7011]. 5.4.2. MIB Field Options Template The MIB Field Options Template is a Standard Options Template which defines the Fields that will be exported to provide enough metadata about a mibObjectValue Information Element so that the Collector can Aitken, et al. Expires May 24, 2016 [Page 16] Internet-Draft Exporting MIB Variables with IPFIX November 2015 tie the data values in the mibObjectValue Information Element back to the definition of the MIB object. All MIB Field Options Templates contain the fields as specified in Section 5.3.1. Figure 5 shows the required fields to export a mibObjectIdentifier for the MIB Field Options Template format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: MIB Field Options Template Format - Required Fields Where: templateId The first Scope Field is an IPFIX Information Element which denotes that a Template Identifier will be exported as part of the MIB Field Options Data Record. This Template Identifier paired with an index into that template, the "informationElementIndex" field, uniquely references one mibObjectValue Information Element being exported. informationElementIndex The second Scope Field is an IPFIX Information Element which denotes a zero based index into the fields defined by a Template. When paired with a "templateId" the Record uniquely references one mibObjectValue Information Element being exported. mibObjectIdentifier Aitken, et al. Expires May 24, 2016 [Page 17] Internet-Draft Exporting MIB Variables with IPFIX November 2015 An IPFIX Information Element which denotes the a MIB Object Identifier for the mibObjectValue Information Element exported in the (Options) Template Record. When a MIB Object Value Information Element is used, the MIB Object Identifier MUST be specified in the MIB Field Options Template Record or specified by other means. The Object Identifier is encoded in the IPFIX data record in ASN.1/BER [BER] format. Variable-length encoding SHOULD be used with the mibObjectIdentifier so that multiple different length MIB OIDs can be exported efficiently. This will also allow reuse of the MIB Field Options Template. Variable-length encoding is indicated by the Field Length value of 65535 per sections 3.2 and 7 of [RFC7011]. The RECOMMENDED use of variable length encoding for mibObjectIdentifier fields is indicated in subsequent figures by placing 65535 in the relevant length fields. 5.4.3. MIB Field Options Data Records The MIB Field Options Data Records conform to the Template Specification in the MIB Field Options Template. There may be multiple MIB Field Options Data Records exported. The Collecting Process MUST store all received MIB Field Options Data information for the duration of each Transport Session, because the Collecting Process will need to refer to the extra meta information to fully decode each mibObjectValue Information Element. Figure 6 shows the format of the exported MIB Field Options Data Record detailing the metadata that will be exported to match the Template in Figure 5. Aitken, et al. Expires May 24, 2016 [Page 18] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID | Length = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifier continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifier continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of MIB Field Options Data Record 5.4.4. Options Template containing a mibObject Field The Options Template Record format of a Template that uses a mibObjectValue Information Element is identical to the standard format as defined in [RFC7011]. The mibObjectValue Information Element is specified using standard Field Specifiers as in [RFC7011]. A mibObjectValue Information Element can be either a Scope Field or a non-Scope Field in an Options Template Record. The only extra requirement on a Options Template Record using mibObjectValue Information Element is that it MUST export the required metadata specified in Section 5.3.1 for EACH mibObjectValue Information Element. An IPFIX Options Template Record MUST export a MIB Field Options Template and Data Record to provide the minimum required metadata for each mibObjectValue Information Element. Figure 7 shows an IPFIX Options Template Set using an existing IPFIX Field as a Scope Field and with a mibObjectValueInteger IE as a non- Scope Field, while Figure 8 shows an IPFIX Options Template Set using a mibObjectValueInteger IE as a Scope Field with an existing IPFIX Field as a non-Scope Field. Aitken, et al. Expires May 24, 2016 [Page 19] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = Existing IPFIX Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: IPFIX Options Template Set using a Non Scope mibObjectValueInteger Field 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = Existing IPFIX Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: IPFIX Options Template Set using a Scope mibObjectValueInteger Field 5.4.5. MIB Field Options Template with Semantics Fields A MIB Field Options Template MAY specify that extra Information Elements will be exported to record how the mibObjectValue was collected. Alternatively, one of the existing IPFIX observationTime* elements [IANA-IPFIX] may be exported to specify exactly when the value was collected. Figure 9 shows the MIB Field Options Template for a non-columnar Field with Semantic Data. Aitken, et al. Expires May 24, 2016 [Page 20] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibCaptureTimeSemantics| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: MIB Field Options Template for a non-indexed Field with Semantic Data Where: mibObjectIdentifier Note the use of variable length encoding for this field. mibCaptureTimeSemantics The MIB Capture Time Semantics IPFIX Information Element, as defined in Section 11.2.2.4. It is RECOMMENDED to include this field when exporting a mibObjectValue Information Element that specifies counters or statistics, in particular for situations with long lived Flows. 5.4.6. MIB Field Options Template with extra MIB Object Details The OID exported within the mibObjectIdentifier IPFIX Information Element provides a OID reference to a MIB object type definition that will fully describe the MIB object data being Exported. However an Exported Process MAY decide to include some extra fields to more fully describe the MIB Object that is being exported with a mibObjectValue Information Element. This can be helpful if the Collecting Process may not have access to the MIB module. Aitken, et al. Expires May 24, 2016 [Page 21] Internet-Draft Exporting MIB Variables with IPFIX November 2015 The Exporting Process can either include the extra object details fields as part of the MIB Field Options Template, or export a separate Options Template and Data that maps MIB OIDs in mibObjectIdentifier Fields to the object details. If only a few fields are being exported then including extra type data in the MIB Field Options export will be more efficient. The MIB Field Options Template for a non-indexed Field with extra MIB object details is shown in Figure 10. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 38 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectSyntax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectDescription | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibModuleName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: MIB Field Options Template for a non-indexed Field with extra MIB object details Where: mibObjectSyntax The MIB object syntax string as defined in Section 11.2.3.3. Note that a separate mibObjectSyntax Information Element is required (rather than extend the existing informationElementDataType registry [IANA-IPFIX]) because the SYNTAX clause could contain almost any name. Aitken, et al. Expires May 24, 2016 [Page 22] Internet-Draft Exporting MIB Variables with IPFIX November 2015 mibObjectName The textual name a mibObjectIdentifier Object. mibObjectDescription The textual description for a mibObjectIdentifier. mibModuleName The textual name of the MIB module that defines a MIB Object. Note the use of variable length encoding for the mibObjectIdentifier, mibObjectSyntax, mibObjectName, mibObjectDescription, and mibModuleName, since these are all string fields. The MIB details can be exported as an standard IPFIX Option export [RFC7011] as shown in Figure 11. This may be more efficient as the bulk of this data is text based and SHOULD be exported only once to the Collecting Process if there are many MIB objects being exported. This prevents this large textual data being included for every use of a mibObjectValue Information Element. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectSyntax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectDescription | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibModuleName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Alternative mibObjectIdentifier Option Export with object details Aitken, et al. Expires May 24, 2016 [Page 23] Internet-Draft Exporting MIB Variables with IPFIX November 2015 5.5. Use of field order in the MIB Field Option template The MIB Field Options Template export makes use of the informationElementIndex [IANA-IPFIX] to specify which field in the template that the metadata relates to, which avoids any ordering constraints on the data template. The mibObjectValue Information Elements in a IPFIX export can be in any order in the export packet. However, fields used as an INDEX MUST be in the same order as specified in the INDEX clause of the conceptual row MIB object. The informationElementIndex specifies which Field in the Template extra information is being provided for. This is analogous to standard IPFIX Template Sets which also specify the order of the fields and provide their type and size. If the template changes such that the order is different then the MIB Field Options data MUST be resent to reflect the new ordering. A new Template ID MUST be used to reflect that the ordering has changed. Older MIB Field Options Data may refer to the incorrect field. A templateId [IANA-IPFIX] is only locally unique within a combination of a Observation Domain and Transport session. As such each MIB Field Options Data Record can only refer to templateIds within the same Observation Domain and session. 5.6. Identifying the SNMP Context Each MIB OID is looked up in a specific context, usually the default context. If exporting a MIB OID value that isn't in the default context then the context MUST be identified by including the mibContextEngineID (see Section 11.2.2.5) and mibContextName (see Section 11.2.2.6) fields in the MIB Field Options Template and associated MIB Field Options Data Records, or be included in the same template as the mibFieldValue Field. This context data MUST be included for each field that is not in the default context. The context information MAY be exported as part of the Template that includes the mibObjectValue Information Element or the context information MAY be exported in the MIB Field Options Data Record that refers to the field. Context fields exported in the same Template MUST take precedence over those that refer to the template. Context fields MUST apply to all mibObjectValue Information Elements in the same template and there MUST NOT be duplicates of mibContextName or mibContextEngineID in a Template. Aitken, et al. Expires May 24, 2016 [Page 24] Internet-Draft Exporting MIB Variables with IPFIX November 2015 So a MIB Field Options Template MAY specify no Context information, just the Context Engine ID or both the context engine and context name. This allows the exporter to export the bulk of data in the default context and only tag those required. Since the MIB Field Options Template applies for all the records of a Template using Context Fields in the MIB Field Options Data Template requires that each mibContextEngineID / mibContextName pair have its own Template. 5.7. Template Management Templates are managed as per section 8 of [RFC7011] with the additional constraint that the MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message as any (Option) Template Record that uses a mibObjectValue Information Element. When exporting over an SCTP transport [RFC4960], the MIB Field Options Data Records MUST be exported reliably and in the same SCTP stream as their associated Templates per [RFC6526]. If a Template using a mibObjectValue Information Element is resent for any reason the Records it depends on MUST be sent as well. If a Template is replaced with a new (Option) Template then a new MIB Field Options Data Record MUST be sent with the replacement referencing the new Template ID. An Exporting Process SHOULD reuse MIB Field Options Template IDs when the Templates are identical. Each (Option) Template Record MUST still be accompanied by a copy of the MIB Field Options Template. 5.7.1. Large Messages The requirement to export the MIB Field Options Template and MIB Field Options Data Records in the same IPFIX Message as any (Option) Template Record that uses a mibObjectValue Information Element may result in very large IPFIX Messages. In environments with restricted Message sizes, and only when a reliable SCTP transport is being used, the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records, MAY be exported in separate Messages in the same SCTP stream, provided that their order is maintained. Aitken, et al. Expires May 24, 2016 [Page 25] Internet-Draft Exporting MIB Variables with IPFIX November 2015 5.7.2. Template Withdrawal and Reuse Data Records containing mibObjectValue Information Elements MUST NOT be exported if their corresponding Data Template or MIB Field Options Template has been withdrawn, since the MIB Field Options Template MUST be exported in the same IPFIX Message as the Data Template which it annotates, except as allowed by the caveat of Section 5.7.1. MIB Field Options Template IDs MUST NOT be reused while they are required by any existing Data Templates. 5.8. Exporting Conceptual Rows and Tables There are three approaches for an IPFIX Exporting Process to export the values of columnar objects: 1. Ignoring the indexing of Columnar Objects 2. Exporting conceptual rows/table objects using structured data 3. Exporting individual indexed Columnar Objects Firstly, a subordinate columnar object may be used purely as a data type. In this case there is no index information or relation to a conceptual row object provided by the Exporting Process. Secondly, mibObjectValueRow or mibObjectValueTable can be used to export partial or complete conceptual rows using [RFC6313] structured data. Thirdly, in a mixed option/data IPFIX/MIB template, the mibObjectValue Information Element can have the values of the INDEX clause of the conceptual row provided by other fields in the record. In this case each mibObjectValue Information Element must specify which other field(s) in the template is providing the index information. 5.8.1. Exporting Conceptual Rows - indexing This document defines two forms of indexing that can be used for conceptual row MIB objects. Structured Data based indexing is used solely by the mibObjectValueRow Information Element. Each conceptual row of the MIB object corresponds to a single Data Record exported. The index fields defined in the INDEX clause of the MIB object MUST all be present in the same order as the Scope Fields. This allows a simple Aitken, et al. Expires May 24, 2016 [Page 26] Internet-Draft Exporting MIB Variables with IPFIX November 2015 table export of a conceptual row MIB object without any extra fields required to indicate which fields make up the conceptual row INDEX. Field based indexing is used by giving each mibObjectValue Information Element a mibIndexIndicator to flag the required index fields. This allows complex indexing or mixing of existing IPFIX Information Element with MIB Fields with minimum overhead. It also allows multiple Columnar MIB objects from different conceptual rows to be exported with complete indexing in one IPFIX Template. 5.8.2. Exporting Conceptual Rows - mibObjectValueRow The simplest approach to exporting a complete or partial conceptual row object is done with the mibObjectValueRow Information Element. This is a Structured Data subTemplateList Information Element as detailed in [RFC6313]. The template specified MUST be an Options Template. It also MUST have the fields specified in the INDEX clause of the conceptual row object as the Scope Fields for the Option Export. An overview of this architecture is given in Figure 12. This shows that the full MIB object type definition OID is exported for the mibObjectValueRow conceptual row field but that the individual columnar objects only require the subIdentifier to be exported. To make the diagram clearer the Templates for the MIB Field Options Templates are not shown. Aitken, et al. Expires May 24, 2016 [Page 27] Internet-Draft Exporting MIB Variables with IPFIX November 2015 +---------------------------+ +------------------------+ | Data Template | | MIB Field Options Data | | | | | | mibObjectValueRow |<---| OID | +---------------------------+ +------------------------+ | | +-----------------------+ +------------------------+ | | Options Template | | MIB Field Options Data | | | | | | | | Scope mibObjectValue* |<---| subIdentifiers | | | mibObjectValue* |<---| subIdentifiers | | +-----------------------+ +------------------------+ | | V V +---------------------------+ | Data Flows | | | | subTemplateList (1 entry) | +---------------------------+ Figure 12: Architecture for Exporting Conceptual Rows with mibObjectValueRow The mibIndexIndicator is not required for each individual mibObjectValue Information Element as mibObjectValueRow provides a structure that includes the index details. When Structured Data based indexing is used all Scope Fields MUST be the INDEX Objects in the same order as defined in the INDEX clause of the conceptual row being exported. Each conceptual table MIB object has 2 related OIDs. There is an OID that refers to the Table with syntax of SEQUENCE OF and an OID that refers to each entry or conceptual row with the syntax of SEQUENCE. The OID for the SEQUENCE of a conceptual row MUST be exported. For example in the IF-MIB ([RFC2863]) the OID for ifEntry should be exported rather than the OID for ifTable. The OID for the table (in this case ifTable) can be derived by removing one subidentifier from the ifEntry OID. The Full OID for the conceptual row MIB object type definition being exported with the mibObjectValueRow Information Element MUST be exported. However the fields that are members of the conceptual row need not have the full OID of their MIB object type definition exported. Instead the mibSubIdentifier Information Element can be used to document which entry in the conceptual row the Field is. Aitken, et al. Expires May 24, 2016 [Page 28] Internet-Draft Exporting MIB Variables with IPFIX November 2015 In this case the export flow will contain a single complete or partial row from a table inside a single field of the record. There may be MIB objects that are specified in the INDEX of the conceptual row but not columnar objects of the same conceptual row, for these the Exporter MUST provide the full OID in a mibObjectIdentifier field. So for a conceptual row object with the OID "1.2.3.4.5.6" the OID of the type definitions for columnar objects "1.2.3.4.5.6.1" "1.2.3.4.5.6.2" can be exported with just a subIdentifier of "1" and "2" respectively. The mibObjectValue Information Elements exported using the mibObjectValueRow export MUST all either be Objects defined in the INDEX clause, Columnar Objects of the same conceptual row object or Columnar Objects that AUGMENT the same conceptual row. The [RFC6313] Structured Data subTemplateList format requires a Structured Data Type Semantic to be specified. Unless there is a more appropriate option in the IPFIX Structured Data Types Semantics registry ([IANA-IPFIX-SDTS]) the "undefined" Structured Data Type Semantic can be used. Figure 13 shows an IPFIX Template for a Structured Data export of a conceptual row, while Figure 14 shows an IPFIX Options Template for a complete conceptual row with five columns and two INDEX fields. Figure 15 shows the MIB Field Options Template for a conceptual row field. Figure 16 shows the MIB Field Options Template for the columns inside the conceptual row. Figure 17 shows the OID data for the conceptual row would be exported. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 300 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: IPFIX Template for a Conceptual Row Aitken, et al. Expires May 24, 2016 [Page 29] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 301 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = mibObjectValue INDEX1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue INDEX2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue COLUM3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue COLUM4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue COLUM5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: IPFIX Options Template for a mibObjectValueRow with 5 columns and 2 INDEX fields 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 302 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: MIB Field Options Template for a Conceptual Row Object Where: templateId The templateId for the MIB Option that will be exported. mibObjectIdentifier Aitken, et al. Expires May 24, 2016 [Page 30] Internet-Draft Exporting MIB Variables with IPFIX November 2015 The MIB OID for the Conceptual Row that is being exported. Note the use of variable length encoding for this field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 303 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: MIB Field Options Template for Columnar Objects of a Conceptual Table Where: templateId The templateId used will be for the Template referred to in the subTemplateList of the mibObjectValueRow that will be exported. mibSubIdentifier The sub identifier that specifies the columnar object's ID within the conceptual row. Aitken, et al. Expires May 24, 2016 [Page 31] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 302 | Length = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 300 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifier continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 303 | Length = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 301 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier | templateId = 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex | mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 301 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier | templateId = 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex | mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 301 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: mibOption Data Record for the conceptual row Where: mibObjectIdentifier Will contain the OID for the conceptual row as a whole. mibSubIdentifier The mibSubIdentifier fields will contain the extra Sub Identifier that when added to the OID for the conceptual row give the full OID for the Object. Aitken, et al. Expires May 24, 2016 [Page 32] Internet-Draft Exporting MIB Variables with IPFIX November 2015 5.8.3. Exporting Conceptual Rows - Augments SMIv2 defines conceptual rows as either having an INDEX clause or an AUGMENTS clause. Conceptual row definitions with an AUGMENTS clause extend an existing base conceptual row with an INDEX clause. It is not possible in SMIv2 to AUGMENT a conceptual row that itself has an AUGMENTS clause. The base table and the augmentation have an identical INDEX. Since augmentations allow adding extra columns to existing tables it is beneficial to be able to support them easily in IPFIX exports of conceptual rows. The mibObjectValueRow OID MAY refer either to the base table with the INDEX clause, or to a conceptual row with an AUGMENTS clause. The subIdentifiers in any MIB Field Options Data Record MUST always refer to the OID exported for the mibObjectValueRow IE. If the mibObjectValueRow OID refers to a base table then any extra columns from conceptual rows with an AUGMENTS clause MUST have their full OID exported. If the mibObjectValueRow OID refers to a conceptual row that augments another conceptual row using the AUGMENTS clause then any MIB fields from the original table's INDEX or Columnar Objects MUST NOT use the mibSubIdentifier and MUST instead export the full OID in a mibObjectIdentifier. If the mibObjectValueRow refers to an AUGMENTS conceptual row the Scope Fields of the Template using in the subTemplateList MUST have the INDEX fields from the base table, in the same order as its scope. This is identical to the Scope Field requirements for conceptual rows with an INDEX clause. This flexibility is provided so that the conceptual rows with the most columns can be exported using the more efficient mibSubIdentifier. For example exporting a complete set of augmentation columns would only require the full OIDs for the MIB objects in the INDEX. It is possible to export MIB object columns from multiple AUGMENTS conceptual rows. If this is done then the base table SHOULD be used as the main OID for the mibObjectValueRow. Aitken, et al. Expires May 24, 2016 [Page 33] Internet-Draft Exporting MIB Variables with IPFIX November 2015 5.8.4. Exporting Conceptual Tables - mibObjectValueTable Multiple rows of a conceptual table can be exported in the mibObjectValueTable Information Element (Section 11.2.1.10). This allows a set of conceptual rows corresponding to a conceptual table to be exported as a single field. Therefore a complete set of rows can be exported as a single field with other information elements in a Template. In this fashion several complete conceptual tables could be exported in one packet. Identically with mibObjectValueRow, as in section Section 5.8.2 above, the more specific OID of the SEQUENCE entity MUST be exported. The format of mibObjectValueTable is identical to mibObjectValueRow except that the length of the subTemplateList may be 0 or more entries. All the other, non length, requirements for mibObjectValueRow in Section 5.8.2 apply to mibObjectValueTable. An overview of this architecture is given in Figure 18. This shows the similarity to Figure 12 Aitken, et al. Expires May 24, 2016 [Page 34] Internet-Draft Exporting MIB Variables with IPFIX November 2015 +---------------------------+ +------------------------+ | Data Template | | MIB Field Options Data | | | | | | mibObjectValueTable |<---| OID | +---------------------------+ +------------------------+ | | +-----------------------+ +------------------------+ | | Options Template | | MIB Field Options Data | | | | | | | | Scope mibObjectValue* |<---| subIdentifiers | | | mibObjectValue* |<---| subIdentifiers | | +-----------------------+ +------------------------+ | | V V +-----------------------------+ | Data Flows | | | | subTemplateList (n entries) | | row 1 | | ... | | row n | +-----------------------------+ Figure 18: Architecture for Exporting Conceptual Tables with mibObjectValueTable 5.8.5. Exporting Columnar Objects - using mibIndexIndicator The other option for indexing a Columnar Object that is part of a conceptual table is explicit indexing. In this case there may be non index fields in the scope of the option export or there may be columnar MIB objects from multiple conceptual rows being exported. In this case each mibObjectValue Information Element requires the mibIndexIndicator with the bits set for the fields that are used to index that individual columnar object. The index fields MUST be in the 'correct' order as defined in the conceptual row that each columnar object is a member of. If a mibObjectValue Information Element that is being indexed using mibIndexIndicator is being used as an Options Template Scope Field, then all fields used to index that field MUST also be Scope Fields. Figure 19 shows the MIB Field Options Template for an indexed MIB Columnar Object. Aitken, et al. Expires May 24, 2016 [Page 35] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibIndexIndicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: MIB Field Options Template for an indexed MIB Columnar Object Where: mibIndexIndicator The MIB Index Indicator IPFIX Information Element which marks which fields in the record will act as INDEX values for the exported MIB object. The index data for a mibObjectValue will be other fields contained in the same Data Record. The mibIndexIndicator marks the Fields whose value(s) should be added to the OID for the MIB object type definition exported in mibObjectIdentifier to get the OID for the instance of the MIB object. Elements used to index MIB objects MUST be exported in the same order as they are specified in the INDEX field of the conceptual table they belong to. mibObjectIdentifier Note the use of variable length encoding for this field. 6. Example Use Cases Aitken, et al. Expires May 24, 2016 [Page 36] Internet-Draft Exporting MIB Variables with IPFIX November 2015 6.1. Non Columnar MIB Object: Established TCP Connections The number of established TCP connections of a remote network device could be monitored by configuring it to periodically export the number of established TCP connections to a centralized Collector. In this example, the Exporter would export an IPFIX Message every 30 minutes that contained Data Records detailing the number of established TCP connections. The table of data that is to be exported looks like: +-------------------------+-----------------------+ | TIMESTAMP | ESTABLISHED TCP CONN. | +-------------------------+-----------------------+ | StartTime + 0 seconds | 10 | | StartTime + 60 seconds | 14 | | StartTime + 120 seconds | 19 | | StartTime + 180 seconds | 16 | | StartTime + 240 seconds | 23 | | StartTime + 300 seconds | 29 | +-------------------------+-----------------------+ Table 2: Established TCP Connections The Template Record for such a Data Record will detail two Information Elements: 1. flowStartSeconds from [IANA-IPFIX], Information Element 150: The absolute timestamp of the first packet of this Flow. 2. tcpCurrEstab from [RFC4022], Object ID "1.3.6.1.2.1.6.9": The number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT. Figure 20 shows the exported Template Set detailing the Template Record for exporting the number of established TCP connections. Aitken, et al. Expires May 24, 2016 [Page 37] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 400 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = flowStartSeconds | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueGauge | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: Example of tcpCurrEstab Template Set Figure 21 shows the exported MIB Field Options Template Set detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 400 in Template Record. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 401 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: Example of tcpCurrEstab MIB Field Options Template Set Figure 22 shows the exported MIB Field Options Data Set detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 400 in Template Record. The OID for the MIB object tcpCurrEstab from [RFC4022], Object ID "1.3.6.1.2.1.6.9", will be encoded in ASN.1/BER [BER] as '06072b060102010609' in the data record, which takes nine octets. Aitken, et al. Expires May 24, 2016 [Page 38] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 401 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 400 | informationElementIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=9 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifier = "1.3.6.1.2.1.6.9" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 06072b060102010609 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: Example of tcpCurrEstab MIB Field Options Data Set Figure 23 shows the start of the Data Set for exporting the number of established TCP connections (see Section 6.1). Aitken, et al. Expires May 24, 2016 [Page 39] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 400 | Length = 52 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 0 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 60 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 120 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 180 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 240 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 300 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: Example of tcpCurrEstab Data Set 6.2. Enterprise Specific MIB Object: Detailing CPU Load History For the sake of demonstrating a enterprise-specific MIB object from the CISCO-PROCESS-MIB ([CISCO-PROCESS-MIB]) is chosen. This example would be valid with any enterprise-specific MIB module. The CPU Usage of a remote network device with 1 CPU could be monitored by configuring it to periodically export CPU usage information, i.e., the cpmCPUTotal1minRev from the proprietary CISCO- PROCESS-MIB, Object ID "1.3.6.1.4.1.9.9.109.1.1.1.1.7", to a centralized Collector. Although the cpmCPUTotal1minRev MIB object is a columnar object in a conceptual row, while there is only 1 CPU no extra information is conveyed by providing the INDEX field. So in this case it is acceptable to not export the cpmCPUTotalIndex MIB object. If there Aitken, et al. Expires May 24, 2016 [Page 40] Internet-Draft Exporting MIB Variables with IPFIX November 2015 were multiple CPUs it would be appropriate to include this the cpmCPUTotalIndex field and specify the relationship. In this example, the Exporter would export an IPFIX Message every 30 minutes that contained Data Records detailing the CPU 1 minute busy average at 1 minute intervals. The table of data that is to be exported looks like: +-------------------------+---------------------+ | TIMESTAMP | CPU BUSY PERCENTAGE | +-------------------------+---------------------+ | StartTime + 0 seconds | 10% | | StartTime + 60 seconds | 14% | | StartTime + 120 seconds | 19% | | StartTime + 180 seconds | 16% | | StartTime + 240 seconds | 23% | | StartTime + 300 seconds | 29% | +-------------------------+---------------------+ Table 3: CPU Usage Data The Template Record for such a Data Record will detail two Information Elements: 1. flowStartSeconds from [IANA-IPFIX], Information Element 150: The absolute timestamp of the first packet of this Flow. 2. a mibObjectValueGauge for cpmCPUTotal1minRev, the overall CPU busy percentage in the last one-minute period. Figure 24 shows the exported Template Set detailing the Template Record for exporting CPU Load (see Section 6.2). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 402 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = flowStartSeconds | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueGauge | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 24: Example of CPU Load Template Set Aitken, et al. Expires May 24, 2016 [Page 41] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Figure 25 shows the exported Template Set detailing the MIB Field Options Template for exporting CPU Load (see Section 6.2). Note this is identical to the MIB Field Options Template given in Figure 21 so the same template could have been reused. 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 403 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: Example of CPU Load MIB Field Options Template Set Figure 26 shows the exported MIB Field Options Data Set detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 402 in Template Record (see Section 6.2). The OID for the cpmCPUTotal1minRev has been encoded using ASN.1/BER to '060d2b0601040109096d0101010107' at 15 octets long. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 403 | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 402 | informationElementIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=15 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.4.1.9.9.109.1.1.1.1.7" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060d2b0601040109096d0101010107 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: Example of CPULoad MIB Field Options Data Set Aitken, et al. Expires May 24, 2016 [Page 42] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Note that although cpmCPUTotal1minRev is 32 bits long, reduced size encoding [RFC7011] has been used to encode it within a single octet. The encoding size was specified by setting the length for the mibObjectValueGauge Field to 1 octet in the main Data Template - Figure 24. This example stresses that, even though the OID cpmCPUTotal1minRev is enterprise-specific, the E bit for the mibObjectValueGauge and mibObjectIdentifier is set to "0" since the "mibObjectValueGauge" and "mibObjectIdentifier" Information Element is not enterprise-specific. That this data is from an Enterprise MIB is included in the OID that includes an Enterprise ID. The corresponding Data Set does not add any value for this example, and is therefore not displayed. 6.3. Exporting a Conceptual Row: The OSPF Neighbor Row Many conceptual tables are already defined in standard and proprietary MIBs. These can be exported with a minimum of overhead by using the mibObjectValueRow. This allows the Exporting Process to unambiguously define the INDEX for the entire conceptual row as the Scope Fields of an Option Export. The use of a MIB Field Options Template with mibSubIdentifier being used means that each individual columnar object does not need to have its OID exported to the collector The ospfNbrTable defined in the OSPF MIB [RFC4750] consists of ospfNbrEntry, which has the OID "1.3.6.1.2.1.14.10.1". Each mibObjectValueRow data record will therefore correspond to an ospfNbrEntry. The following fields will be exported: +------------------+----------------+-------------------------+-----+ | Object | ID | mibObjectValue | Len | +------------------+----------------+-------------------------+-----+ | ospfNbrIpAddr | ospfNbrEntry 1 | mibObjectValueIPAddress | 4 | | ospfNbrAddress- | ospfNbrEntry 2 | mibObjectValueInteger | 4 | | -LessIndex | | | | | ospfNbrRtrId | ospfNbrEntry 3 | mibObjectValueIPAddress | 4 | | ospfNbrState | ospfNbrEntry 6 | mibObjectValueInteger | 1 | +------------------+----------------+-------------------------+-----+ Table 4: OSPF Neighbor Entry Objects The OIDs that will be used to export this table are shown in Table 5. Aitken, et al. Expires May 24, 2016 [Page 43] Internet-Draft Exporting MIB Variables with IPFIX November 2015 +------------------+-----------------------+---------------------+ | Entity | Full OID | Exported as | +------------------+-----------------------+---------------------+ | ospfNbrEntry | 1.3.6.1.2.1.14.10.1 | 1.3.6.1.2.1.14.10.1 | | ospfNbrIpAddr | 1.3.6.1.2.1.14.10.1.1 | 1 | | ospfNbrAddress- | 1.3.6.1.2.1.14.10.1.2 | 2 | | -LessIndex | | | | ospfNbrRtrId | 1.3.6.1.2.1.14.10.1.3 | 3 | | ospfNbrState | 1.3.6.1.2.1.14.10.1.6 | 6 | +------------------+-----------------------+---------------------+ Table 5: OSPF OIDs Figure 27 shows the Templates Exported to Support the mibObjectValueRow. Figure 28 shows the example OID Data for the conceptual row exported in mibObjectValueRow Figure 29 shows the example data export for a few neighbors in the table. This shows a Data Record in formatted as per IPFIX Structured Data [RFC6313] and using the the 'undefined' (= 0xFF) semantic [IANA-IPFIX-SDTS]. Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to '06082B060102010E0A01' at 10 octets long. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 500 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 501 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aitken, et al. Expires May 24, 2016 [Page 44] Internet-Draft Exporting MIB Variables with IPFIX November 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 22 | Template ID = 502 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Count = 3 | Scope Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = templateId | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = informationElementIndex| Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectIdentifier | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 503 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: Example of ospfNbrEntry Template and Options Template Sets Aitken, et al. Expires May 24, 2016 [Page 45] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 502 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 500 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06082B060102010E0A01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 503 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 501 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 1 | templateId = 501 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 | mibSubIdentifier = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 501 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 3 | templateId = 501 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 3 | mibSubIdentifier = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 28: Example of ospfNbrEntry OID Data export Aitken, et al. Expires May 24, 2016 [Page 46] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 500 | Length = 52 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 501 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 501 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.2 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 501 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 3.3.3.3 |ospfNbrState=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: Example of Data Export for ospfNbrEntry 6.4. Exporting Augmented Conceptual Row: The IF-MIB id to name mapping The ifTable defined in the [RFC2863] is augmented by the ifXTable (defined in the same MIB module). The OID of the ifEntry is 1.3.6.1.2.1.2.2.1 which is encoded using ASN.1/BER to '06082B06010201020201' at 10 octets long, while the OID of the augmenting ifXEntry is 1.3.6.1.2.1.31.1.1.1 which is encoded using ASN.1/BER to '060a2b060102011f01010101' at 12 octets long. This example demonstrates how columnar objects from the base conceptual row and the augmenting row can be exported in a single mibObjectValueRow Information Element. Table 6 shows the fields which will be exported. Aitken, et al. Expires May 24, 2016 [Page 47] Internet-Draft Exporting MIB Variables with IPFIX November 2015 +---------+------------------+-------+-------------------+ | ifIndex | ifType | ifMtu | ifName | +---------+------------------+-------+-------------------+ | 1 | ethernetCsmacd:6 | 1500 | Ethernet 10 | | 2 | ethernetCsmacd:6 | 1500 | Ethernet 20 | | 3 | ethernetCsmacd:6 | 1500 | FastEthernet 30 | +---------+------------------+-------+-------------------+ Table 6: IF-MIB Data The OIDs that will be used to export this table are shown in Table 7. +---------+------------------------+--------------------------------+ | Entity | Full OID | Exported as | +---------+------------------------+--------------------------------+ | ifEntry | 1.3.6.1.2.1.2.2.1 | OID = 1.3.6.1.2.1.2.2.1 | | ifIndex | 1.3.6.1.2.1.2.2.1.1 | subID = 1 | | ifType | 1.3.6.1.2.1.2.2.1.3 | subID = 3 | | ifMtu | 1.3.6.1.2.1.2.2.1.4 | subID = 4 | | ifName | 1.3.6.1.2.1.31.1.1.1.1 | OID = 1.3.6.1.2.1.31.1.1.1.1 | +---------+------------------------+--------------------------------+ Table 7: IF-MIB OIDs Figure 30 shows the Templates Exported to Support the mibObjectValueRow Information Element. Figure 31 shows the example OID Data for the conceptual row exported in mibObjectValueRow to match Table 7. Figure 32 shows the example data export as per Table 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 600 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 601 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| IE = mibObjectValueInteger | Aitken, et al. Expires May 24, 2016 [Page 48] Internet-Draft Exporting MIB Variables with IPFIX November 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|IE =mibObjectValueOctetString| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 22 | Template ID = 602 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Count = 3 | Scope Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = templateId | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = informationElementIndex| Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectIdentifier | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 603 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30: Example of Augmented ifEntry Template and Options Template Sets Aitken, et al. Expires May 24, 2016 [Page 49] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 602 | Length = 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 600 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=10 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifEntry = 1.3.6.1.2.1.2.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06082B06010201020201 | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 601 | informationElementIndex = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=12 | mibObjectIdentifier ifName ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifName = 1.3.6.1.2.1.31.1.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060a2b060102011f01010101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 603 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 601 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 1 | templateId = 601 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 | mibSubIdentifier = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 601 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 31: Example of Augmented ifEntry OID Data export Aitken, et al. Expires May 24, 2016 [Page 50] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 600 | Length = 68 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length = 11 | ifName = Ethernet 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length = 11 | ifName = Ethernet 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length = 15 | ifName = FastEthernet 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 32: Example of Data Export for Augmented ifEntry 6.5. Exporting a Columnar Object: The ipIfStatsInForwDatagrams It may be that the full set of columnar objects that are supported by a conceptual row are not required to be exported. Rather than use the Structured Data method the mibIndexIndicator method can be used to provide the relation between fields. Aitken, et al. Expires May 24, 2016 [Page 51] Internet-Draft Exporting MIB Variables with IPFIX November 2015 This example shows the MIB Objects that are part of the INDEX of the conceptual row being exported in the correct order and then being referred to by using mibIndexIndicator. This example shows the export of ipIfStatsInForwDatagrams from the IP-MIB [RFC4293]. ipIfStatsInForwDatagrams is a columnar object that is part of the conceptual table ipIfStatsTable. This is comprised of ipIfStatsEntry conceptual rows. The ipIfStatsTable conceptual table is indexed by the ipIfStatsIPVersion and ipIfStatsIfIndex. The Options Template Record for the example Data Record contains the following Information Elements: 1. ipIfStatsIPVersion (1.3.6.1.2.1.4.31.3.1.1) (Scope Field) (encoded using ASN.1/BER to '060A2B06010201041F030101' at 12 octets long) 2. ipIfStatsIfIndex (1.3.6.1.2.1.4.31.3.1.2) (Scope Field) (encoded using ASN.1/BER to '060A2B06010201041F030102' at 12 octets long) 3. ipIfStatsInForwDatagrams (1.3.6.1.2.1.4.31.3.1.12) (non-Scope Field) (encoded using ASN.1/BER to '060A2B06010201041F03010c' at 12 octets long) Note ipIfStatsIfIndex has been reduce length encoded to 2 octets in the following example. An exporting device with more interfaces would use the full length. Figure 33 shows the exported Options Template Set. Aitken, et al. Expires May 24, 2016 [Page 52] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 701 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0|Scope 1=mibObjectValueInteger| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field 1 Length = 1 |0|Scope 2=mibObjectValueInteger| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field 1 Length = 2 |0| IE = mibObjectValueCounter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 33: Example of an Options Template for an Indexed MIB Object with two indices. Figure 34 shows the exported MIB Field Options Template used to export the required mibObjectValue Information Element metadata. This example of the MIB Field Options Template includes the mibIndexIndicator to indicate that some of the other fields in the data records are indexes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 702 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibIndexIndicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 34: Example of an MIB Field Options Template for an Indexed MIB Object with two indices. Figure 35 shows the exported MIB Field Options Data used to export the required mibObjectValue Information Element metadata. Note that Aitken, et al. Expires May 24, 2016 [Page 53] Internet-Draft Exporting MIB Variables with IPFIX November 2015 the first two Data Records have all their mibIndexIndicator bits set to 0. The third mibIndexIndicator has the value '11000000' to show that the first two fields in the record are the INDEX's for this columnar object. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 702 | Length = 58 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 701 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Index 00000000 | VLEN = 12 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.2.1.4.31.3.1.1" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060A2B06010201041F030101 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | templateId = 701 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 |Index 00000000 | VLEN = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibObjectIdentifier = "1.3.6.1.2.1.4.31.3.1.2" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060A2B06010201041F030102 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 701 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index 11000000 | VLEN = 12 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.2.1.4.31.3.1.12" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060A2B06010201041F03010c ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 35: Example of an MIB Field Options Data Set for an Indexed MIB Object with two indices. Figure 36 shows the Data Records that export the values of the 3 mibObjectValue Information Elements. Aitken, et al. Expires May 24, 2016 [Page 54] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 701 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipVer = 1 | ifIndex = 10 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | InForwDatagrams = 10000 | ipVer = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifIndex = 10 | InForwDatagrams = 20000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 36: Example of an MIB Data Set for an Indexed MIB Object with two indices. 6.6. Exporting a Columnar Object indexed by IEs: ifOutQLen If a PSAMP Packet Report [RFC5476] was generated on any dropped packets on an interface then it may be desirable to know if the send queue on the output interface was full. This could be done by exporting the size of the send queue (ifOutQLen) in the same Data Record as the PSAMP Packet Report. The exported data looks like: +-----------+-----------+--------+--------------+-------------------+ | SRC ADDR | DST ADDR | PAK | OUTPUT | OUTPUT Q. LEN | | | | LEN | INTERFACE | (ifOutQLen) | +-----------+-----------+--------+--------------+-------------------+ | 192.0.2.1 | 192.0.2.3 | 150 | Eth 1/0 (15) | 45 | | 192.0.2.4 | 192.0.2.9 | 350 | Eth 1/0 (15) | 45 | | 192.0.2.3 | 192.0.2.9 | 650 | Eth 1/0 (15) | 23 | | 192.0.2.4 | 192.0.2.6 | 350 | Eth 1/1 (16) | 0 | +-----------+-----------+--------+--------------+-------------------+ Table 8: Packet Report with Interface Output Queue Length (ifOutQLen) Data The ifOutQLen MIB object defined in the IF-MIB [RFC2863] provides the length of the output packet queue. This columnar object is part of the ifEntry conceptual row and indexed by the interface index (ifIndex). This relationship between the ifOutQLen field and the index field is exported using mibIndexIndicator in the MIB Field Options Template. The value of "00010000" flags the index fields concisely. Aitken, et al. Expires May 24, 2016 [Page 55] Internet-Draft Exporting MIB Variables with IPFIX November 2015 The Template Record for the example Data Record contains the following Information Elements: 1. sourceIPv4Address 2. destinationIPv4Address 3. totalLengthIPv4 4. egressInterface 5. ifOutQLen indexed by: egressInterface Figure 37 shows the exported Template Set detailing the Template for exporting a PSAMP Report with Interface Output Queue Length (ifOutQLen). Figure 38 and Figure 39 show the MIB Field Options Template and Data Record. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 703 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = sourceIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = destinationIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = totalLengthIPv4 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = egressInterface | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueGauge | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 37: Example of Template for a PSAMP Report with ifOutQLen indexed by egressInterface Aitken, et al. Expires May 24, 2016 [Page 56] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 704 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibIndexIndicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 38: Example of MIB Field Options Template for a PSAMP Report with ifOutQLen indexed by egressInterface 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 704 | Length = 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 703 | informationElementIndex = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Index 00010000 | VLEN = 11 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.2.1.2.2.1.21" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06092B0601020102020115 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Figure 39: Example of MIB Field Options Data Record for a PSAMP Report with ifOutQLen indexed by egressInterface The corresponding IPFIX Data Record is shown in Figure 40. For the sake of the example, the interface index of "Eth 1/0" is 15 and the interface index of "Eth 1/1" is 16. Aitken, et al. Expires May 24, 2016 [Page 57] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 703 | Length = 84 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 150 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 (Eth 1/0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 45 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 350 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 (Eth 1/0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 45 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 650 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 (Eth 1/0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 350 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 (Eth 1/1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 40: Example of PSAMP Packet Report with ifOutQLen indexed by egressInterface Aitken, et al. Expires May 24, 2016 [Page 58] Internet-Draft Exporting MIB Variables with IPFIX November 2015 6.7. Exporting With Multiple Contexts: The OSPF Neighbor Row Revisited If the Context used to export the MIB objects is the default one no extra context fields are required. This example demonstrates how to handle the case when the Context needs to be specified. It is based on the previous example Section 6.3. The OSPF details exported of the conceptual row in Section 6.3 would be suitable if there were only one OSPF process running at the Observation Point. If multiple OSPF processes are present then they can be differentiated by also exporting the mibContextEngineID and mibContextName. The following fields will be exported: +------------------+----------------+-------------------------+-----+ | Object | ID | mibObjectValue | Len | +------------------+----------------+-------------------------+-----+ | ospfNbrIpAddr | ospfNbrEntry 1 | mibObjectValueIPAddress | 4 | | ospfNbrAddress- | ospfNbrEntry 2 | mibObjectValueInteger | 4 | | -LessIndex | | | | | ospfNbrRtrId | ospfNbrEntry 3 | mibObjectValueIPAddress | 4 | | ospfNbrState | ospfNbrEntry 6 | mibObjectValueInteger | 1 | +------------------+----------------+-------------------------+-----+ Table 9: OSPF Neighbor Entry Objects The example contextEngineID matches the example from [RFC3411] for Acme Networks: "'800002b804616263'H (enterprise 696, string 'abc')" Figure 41 shows the Templates Exported to support a mibObjectValueRow that is defined within a context. Figure 42 shows the example OID Data for the conceptual row exported in mibObjectValueRow. These are unchanged from the previous example. Figure 43 shows the example data for 2 OSPF neighbors. Although these have identical INDEX/scope values the context information indicates they come from different OSPF processes. Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to '06082B060102010E0A01' at 10 octets long. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 800 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibContextEngineID | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aitken, et al. Expires May 24, 2016 [Page 59] Internet-Draft Exporting MIB Variables with IPFIX November 2015 |0| IE = mibContextName | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 801 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 22 | Template ID = 802 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Count = 3 | Scope Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = templateId | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = informationElementIndex| Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectIdentifier | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 803 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aitken, et al. Expires May 24, 2016 [Page 60] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Figure 41: Example of ospfNbrEntry Template and Options Template Sets with Context 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 802 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 800 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06082B060102010E0A01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 803 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 801 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 1 | templateId = 801 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 | mibSubIdentifier = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 801 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 3 | templateId = 801 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 3 | mibSubIdentifier = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 42: Example of ospfNbrEntry OID Data export with Context Aitken, et al. Expires May 24, 2016 [Page 61] Internet-Draft Exporting MIB Variables with IPFIX November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 800 | Length = 60 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextEngineID = 800002b804616263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibContextEngineID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextName = con1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 801 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextEngineID = 800002b804616263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibContextEngineID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextName = con2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 801 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 43: Example of Data Export for ospfNbrEntry with Context 7. Configuration Considerations When configuring a MIB OID for export, consideration should be given to whether the SNMP Context String should also be configurable. If a non-default Context String is used then it should be associated with the fields as per Section 5.6. 8. The Collecting Process's Side The specifications in section 9 of [RFC7011] also apply to Collectors that implement this specification. In addition, the following specifications should be noted. Aitken, et al. Expires May 24, 2016 [Page 62] Internet-Draft Exporting MIB Variables with IPFIX November 2015 A Collecting Process that implements this specification MUST store the data records containing the OID Object Type Definitions with the same retention policy as templates. A Collecting Process that implements this specification SHOULD have access to MIB modules in order to look up the received MIB Object Identifiers and find the full type definition and name of MIB OID fields used in received templates. It should be noted that since reduced size encoding MAY be used by the Exporting Process, the Collecting Process cannot assume a received size for a field is the maximum size it should expect for that field. If a Collecting Process receives a MIB Object Identifier that it cannot decode, it MAY log a warning. A Collecting Process MUST support the 3 options for handling columnar objects detailed in Section 5.8. 9. Applicability Making available the many and varied items from MIB modules opens up a wide range of possible applications for the IPFIX protocol, some quite different from the usual flow information. Some monitoring applications periodically export an interface ID to interface name mapping using IPFIX Options Templates. This could be expanded to include the MIB object "ifInUcastPkts" of the IF-MIB [RFC2863] indexed using the ingressInterface Information Element. This would give the input statistics for each interface which can be compared to the flow information to ensure the sampling rate is expected. Or, if there is no sampling, to ensure that all the expected packets are being monitored. 10. Security Considerations For this extension to the IPFIX protocol, the same security considerations as for the IPFIX protocol apply [RFC7011]. If the exporter is generating or capturing the field values itself, e.g., using the MIB objects only as an encoding or type mechanism, there are no extra security considerations beyond standard IPFIX. However, if the exporter is implemented as an SNMP manager accessing an SNMP agent, it MUST authenticate itself to the SNMP agent [RFC3414], [RFC5591], [RFC5592], [RFC6353], and the SNMP agent MUST Aitken, et al. Expires May 24, 2016 [Page 63] Internet-Draft Exporting MIB Variables with IPFIX November 2015 enforce SNMP access control rules [RFC3415] as required by the SNMP architecture [RFC3411]. The access to particular MIB objects is controlled by the configuration of the IPFIX exporter. This is consistent with the way IPFIX controls access to other Information Elements in general. The configuration of an IPFIX Exporter determines which MIB objects are included in IPFIX Data Records sent to certain collectors. Network operators should take care that the only MIB objects which are included in IPFIX Data Records are ones which the receiving flow collector is allowed to receive. Note that multiple users may have access to the data from the flow collector. When exporting MIB objects that may be considered sensitive or vulnerable in some network environments (as mentioned in the Security Considerations section of the RFC containing the MIB module), the Exporter should consider using "IP Flow Anonymization Support" [RFC6235] if the information is anonymizable. Consumers of exported data should therefore be able to handle the kinds of modifications to data described in [RFC6235]. 11. IANA Considerations 11.1. New IPFIX Semantics New IPFIX semantics must be allocated in IANA's IPFIX registry [IANA-IPFIX] per section 6 of [RFC7012], as defined in the sub- sections below. 11.1.1. snmpCounter An integral value reporting the value of a counter, identical to the Counter32 and Counter64 semantics in [RFC2578], as determined by the field length. This is similar to IPFIX's totalCounter semantic, except that total counters have an initial value of 0, while SNMP counters do not. 11.1.2. snmpGauge An integral value identical to the Gauge32 semantic in [RFC2578], and the Gauge64 semantic in [RFC2856], as determined by the field length. Aitken, et al. Expires May 24, 2016 [Page 64] Internet-Draft Exporting MIB Variables with IPFIX November 2015 11.2. New IPFIX Information Elements The new Information Elements in Table 10 must be allocated in IANA's IPFIX registry [IANA-IPFIX], as defined in the sub-sections below. In each case the "Units" and "Range" are to be left blank, since these are not applicable. +-----------+---------------------------+ | ElementId | Name | +-----------+---------------------------+ | TBD1 | mibObjectValueInteger | | TBD2 | mibObjectValueOctetString | | TBD3 | mibObjectValueOID | | TBD4 | mibObjectValueBits | | TBD5 | mibObjectValueIPAddress | | TBD6 | mibObjectValueCounter | | TBD7 | mibObjectValueGauge | | TBD8 | mibObjectValueTimeTicks | | TBD9 | mibObjectValueUnsigned | | TBD10 | mibObjectValueTable | | TBD11 | mibObjectValueRow | | TBD12 | mibObjectIdentifier | | TBD13 | mibSubIdentifier | | TBD14 | mibIndexIndicator | | TBD15 | mibCaptureTimeSemantics | | TBD16 | mibContextEngineID | | TBD17 | mibContextName | | TBD18 | mibObjectName | | TBD19 | mibObjectDescription | | TBD20 | mibObjectSyntax | | TBD21 | mibModuleName | +-----------+---------------------------+ Table 10: New Information Elements 11.2.1. New MIB Value Information Elements 11.2.1.1. mibObjectValueInteger A new Information Element "mibObjectValueInteger" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that the integer value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of Integer32 Aitken, et al. Expires May 24, 2016 [Page 65] Internet-Draft Exporting MIB Variables with IPFIX November 2015 and INTEGER with IPFIX Reduced Size Encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type of signed64. Abstract Data Type: signed64 Data Type Semantics: identifier ElementId: TBD1 Status: current Reference: [this document]. 11.2.1.2. mibObjectValueOctetString A new Information Element "mibObjectValueOctetString" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that an Octet String or Opaque value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of OCTET STRING and Opaque. The value is encoded as per the standard IPFIX Abstract Data Type of octetArray. Abstract Data Type: octetArray Data Type Semantics: default ElementId: TBD2 Status: current Reference: [this document]. 11.2.1.3. mibObjectValueOID A new Information Element "mibObjectValueOID" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that an Object Identifier or OID value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax Aitken, et al. Expires May 24, 2016 [Page 66] Internet-Draft Exporting MIB Variables with IPFIX November 2015 of OBJECT IDENTIFIER. Note - In this case the "mibObjectIdentifier" will define which MIB object is being exported while the value contained in this Information Element will be an OID as a value. The mibObjectValueOID Information Element is encoded as ASN.1/BER [BER] in an octetArray. Abstract Data Type: octetArray Data Type Semantics: default ElementId: TBD3 Status: current Reference: [this document]. 11.2.1.4. mibObjectValueBits A new Information Element "mibObjectValueBits" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that a set of Enumerated flags or bits from a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of BITS. The flags or bits are encoded as per the standard IPFIX Abstract Data Type of octetArray, with sufficient length to accommodate the required number of bits. If the number of bits is not an integer multiple of octets then the most significant bits at end of the octetArray MUST be set to zero. Abstract Data Type: octetArray Data Type Semantics: flags ElementId: TBD4 Status: current Reference: [this document]. 11.2.1.5. mibObjectValueIPAddress A new Information Element "mibObjectValueIPAddress" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Aitken, et al. Expires May 24, 2016 [Page 67] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Description: An IPFIX Information Element which denotes that the IPv4 Address of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of IPaddress. The value is encoded as per the standard IPFIX Abstract Data Type of ipv4Address. Abstract Data Type: ipv4Address Data Type Semantics: default ElementId: TBD5 Status: current Reference: [this document]. 11.2.1.6. mibObjectValueCounter A new Information Element "mibObjectValueCounter" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that the counter value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of Counter32 or Counter64 with IPFIX Reduced Size Encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64. Abstract Data Type: unsigned64 Data Type Semantics: snmpCounter ElementId: TBD6 Status: current Reference: [this document]. 11.2.1.7. mibObjectValueGauge A new Information Element "mibObjectValueGauge" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Aitken, et al. Expires May 24, 2016 [Page 68] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Description: An IPFIX Information Element which denotes that the Gauge value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of Gauge32. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64. This value will represent a non-negative integer, which may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum value. Abstract Data Type: unsigned32 Data Type Semantics: snmpGauge ElementId: TBD7 Status: current Reference: [this document]. 11.2.1.8. mibObjectValueTimeTicks A new Information Element "mibObjectValueTimeTicks" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that the TimeTicks value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of TimeTicks. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned32. Abstract Data Type: unsigned32 Data Type Semantics: default ElementId: TBD8 Status: current Reference: [this document]. 11.2.1.9. mibObjectValueUnsigned A new Information Element "mibObjectValueUnsigned" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Aitken, et al. Expires May 24, 2016 [Page 69] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Description: An IPFIX Information Element which denotes that an unsigned integer value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of unsigned64 with IPFIX Reduced Size Encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64. Abstract Data Type: unsigned64 Data Type Semantics: identifier ElementId: TBD9 Status: current Reference: [this document]. 11.2.1.10. mibObjectValueTable A new Information Element "mibObjectValueTable" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that a complete or partial conceptual table will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with a SYNTAX of SEQUENCE. This is encoded as a subTemplateList of mibObjectValue Information Elements. The template specified in the subTemplateList MUST be an Options Template and MUST include all the Objects listed in the INDEX clause as Scope Fields. Abstract Data Type: subTemplateList Data Type Semantics: list ElementId: TBD10 Status: current Reference: [this document]. Aitken, et al. Expires May 24, 2016 [Page 70] Internet-Draft Exporting MIB Variables with IPFIX November 2015 11.2.1.11. mibObjectValueRow A new Information Element "mibObjectValueRow" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that a single row of a conceptual table will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with a SYNTAX of SEQUENCE. This is encoded as a subTemplateList of mibObjectValue Information Elements. The subTemplateList exported MUST contain exactly one row (i.e., one instance of the subtemplate). The template specified in the subTemplateList MUST be an Options Template and MUST include all the Objects listed in the INDEX clause as Scope Fields. Abstract Data Type: subTemplateList Data Type Semantics: list ElementId: TBD11 Status: current Reference: [this document]. 11.2.2. New MIB Field Options Information Elements 11.2.2.1. mibObjectIdentifier A new Information Element "mibObjectIdentifier" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Element which denotes that a MIB Object Identifier (MIB OID) is exported in the (Options) Template Record. The mibObjectIdentifier Information Element contains the OID assigned to the MIB Object Type Definition encoded as ASN.1/ BER [BER] Abstract Data Type: octetArray Data Type Semantics: default ElementId: TBD12 Status: current Aitken, et al. Expires May 24, 2016 [Page 71] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Reference: [this document]. 11.2.2.2. mibSubIdentifier A new Information Element "mibSubIdentifier" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: A non-negative sub-identifier of an Object Identifier (OID). Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: TBD13 Status: current Reference: [this document]. 11.2.2.3. mibIndexIndicator A new Information Element "mibIndexIndicator" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: This set of bit fields is used for marking the Information Elements of a Data Record that serve as INDEX MIB objects for an indexed Columnar MIB object. Each bit represents an Information Element in the Data Record with the n-th bit representing the n-th Information Element. A bit set to value 1 indicates that the corresponding Information Element is an index of the Columnar Object represented by the mibFieldValue. A bit set to value 0 indicates that this is not the case. If the Data Record contains more than 64 Information Elements, the corresponding Template SHOULD be designed such that all INDEX Fields are among the first 64 Information Elements, because the mibIndexIndicator only contains 64 bits. If the Data Record contains less than 64 Information Elements, then the extra bits in the mibIndexIndicator for which no corresponding Information Element exists MUST have the value 0, and must be disregarded by the Collector. This Information Element may be exported with IPFIX Reduced Size Encoding. Abstract Data Type: unsigned64 Data Type Semantics: flags Aitken, et al. Expires May 24, 2016 [Page 72] Internet-Draft Exporting MIB Variables with IPFIX November 2015 ElementId: TBD14 Status: current Reference: [this document]. 11.2.2.4. mibCaptureTimeSemantics A new Information Element "mibCaptureTimeSemantics" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: Indicates when in the lifetime of the flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to flow creation or flow export time and will refer to the Timestamp fields included in the same record. This field SHOULD be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) and it's important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using structured data. Similarly, if different mibCaptureTimeSemantics apply to different mibObject elements within the Data Record, then individual mibCaptureTimeSemantics should be paired with each OID using structured data. Values: 0. undefined 1. begin - The value for the MIB object is captured from the MIB when the Flow is first observed 2. end - The value for the MIB object is captured from the MIB when the Flow ends 3. export - The value for the MIB object is captured from the MIB at export time 4. average - The value for the MIB object is an average of multiple captures from the MIB over the observed life of the Flow Abstract Data Type: unsigned8 Data Type Semantics: identifier Aitken, et al. Expires May 24, 2016 [Page 73] Internet-Draft Exporting MIB Variables with IPFIX November 2015 ElementId: TBD15 Status: current Reference: [this document]. 11.2.2.5. mibContextEngineID A new Information Element "mibContextEngineID" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: A mibContextEngineID that specifies the SNMP engine ID for a MIB field being exported over IPFIX. Definition as per [RFC3411] section 3.3 Abstract Data Type: octetArray Data Type Semantics: default ElementId: TBD16 Status: current Reference: [this document]. 11.2.2.6. mibContextName A new Information Element "mibContextName" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: This Information Element denotes that a MIB Context Name is specified for a MIB field being exported over IPFIX. Reference [RFC3411] section 3.3 Abstract Data Type: string Data Type Semantics: default ElementId: TBD17 Status: current Reference: [this document]. Aitken, et al. Expires May 24, 2016 [Page 74] Internet-Draft Exporting MIB Variables with IPFIX November 2015 11.2.3. New MIB Type Information Elements 11.2.3.1. mibObjectName A new Information Element "mibObjectName" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The name (called a descriptor in [RFC2578]) of an object type definition. Abstract Data Type: string Data Type Semantics: default ElementId: TBD18 Status: current Reference: [this document]. 11.2.3.2. mibObjectDescription A new Information Element "mibObjectDescription" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The value of the DESCRIPTION clause of an MIB object type definition. Abstract Data Type: string Data Type Semantics: default ElementId: TBD19 Status: current Reference: [this document]. 11.2.3.3. mibObjectSyntax A new Information Element "mibObjectSyntax" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The value of the SYNTAX clause of an MIB object type definition, which may include a Textual Convention or Subtyping. See [RFC2578]. Abstract Data Type: string Aitken, et al. Expires May 24, 2016 [Page 75] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Data Type Semantics: default ElementId: TBD20 Status: current Reference: [this document]. 11.2.3.4. mibModuleName A new Information Element "mibModuleName" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The textual name of the MIB module that defines a MIB Object. Abstract Data Type: string Data Type Semantics: default ElementId: TBD21 Status: current Reference: [this document]. 12. Acknowledgements The authors would like to thank Andrew Johnson for his collaboration on the first version of the draft, and to thank Andrew Feren and Brian Trammell for their detailed reviews. Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme. 13. References 13.1. Normative References [BER] International Organization for Standardization, "Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),International Organization for Standardization. International Standard 8825, December 1987", . Aitken, et al. Expires May 24, 2016 [Page 76] Internet-Draft Exporting MIB Variables with IPFIX November 2015 [IANA-IPFIX] IANA, "IPFIX Information Elements registry", . [IANA-IPFIX-SDTS] IANA, "IPFIX Structured Data Types Semantics registry", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, . [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000, . [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, . [RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream", RFC 6526, DOI 10.17487/RFC6526, March 2012, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . Aitken, et al. Expires May 24, 2016 [Page 77] Internet-Draft Exporting MIB Variables with IPFIX November 2015 13.2. Informative References [CISCO-PROCESS-MIB] Cisco Systems Inc., "CISCO-PROCESS-MIB.my: MIB for CPU and process statistics", . [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, . [RFC2982] Kavasseri, R., Ed., "Distributed Management Expression MIB", RFC 2982, DOI 10.17487/RFC2982, October 2000, . [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, DOI 10.17487/RFC3414, December 2002, . [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, DOI 10.17487/RFC3415, December 2002, . [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, . [RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005, . [RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, April 2006, . [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, DOI 10.17487/RFC4750, December 2006, . Aitken, et al. Expires May 24, 2016 [Page 78] Internet-Draft Exporting MIB Variables with IPFIX November 2015 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, DOI 10.17487/RFC5470, March 2009, . [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, March 2009, . [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, . [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June 2009, . [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, . [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, . [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, . Authors' Addresses Paul Aitken (editor) Brocade Communications Systems, Inc. 19a Canning Street, Level 3 Edinburgh, Scotland EH3 8EG United Kingdom Phone: +44 203 005 0731 Email: paitken@brocade.com Aitken, et al. Expires May 24, 2016 [Page 79] Internet-Draft Exporting MIB Variables with IPFIX November 2015 Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Srikar B S Cisco Systems, Inc. Mail Stop BGL13/3/, SEZ Unit, Cessna Business Park, Kadubeesanahalli Village Varthur Hobli, Sarjapur Marathalli Outer Ring Road Bangalore KARNATAKA 560 103 IN Phone: +91 80 4426 3264 Email: srikar@cisco.com Colin McDowall Brocade Communications Systems, Inc. 19a Canning Street, Level 3 Edinburgh, Scotland EH3 8EG United Kingdom Phone: +44 203 005 0687 Email: cmcdowal@brocade.com Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 Bremen 28725 Germany Phone: +49 421 200-3587 Email: j.schoenwaelder@jacobs-university.de Aitken, et al. Expires May 24, 2016 [Page 80] ./draft-ietf-avtcore-rtp-multi-stream-11.txt0000664000764400076440000022130612632511404020245 0ustar iustyiusty AVTCORE J. Lennox Internet-Draft Vidyo Updates: 3550, 4585 (if approved) M. Westerlund Intended status: Standards Track Ericsson Expires: June 13, 2016 Q. Wu Huawei C. Perkins University of Glasgow December 11, 2015 Sending Multiple RTP Streams in a Single RTP Session draft-ietf-avtcore-rtp-multi-stream-11 Abstract This memo expands and clarifies the behaviour of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regards to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTCP behaviour. It also updates RFC 4585 to update and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 13, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Lennox, et al. Expires June 13, 2016 [Page 1] Internet-Draft Multiple Media Streams in an RTP Session December 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases For Multi-Stream Endpoints . . . . . . . . . . . . 3 3.1. Endpoints with Multiple Capture Devices . . . . . . . . . 3 3.2. Multiple Media Types in a Single RTP Session . . . . . . 4 3.3. Multiple Stream Mixers . . . . . . . . . . . . . . . . . 4 3.4. Multiple SSRCs for a Single Media Source . . . . . . . . 4 4. Use of RTP by endpoints that send multiple media streams . . 5 5. Use of RTCP by Endpoints that send multiple media streams . . 5 5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5 5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 6 5.3. Aggregation of Reports into Compound RTCP Packets . . . . 7 5.3.1. Maintaining AVG_RTCP_SIZE . . . . . . . . . . . . . . 7 5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs . . . 9 5.4. Use of RTP/AVPF or RTP/SAVPF Feedback . . . . . . . . . . 11 5.4.1. Choice of SSRC for Feedback Packets . . . . . . . . . 11 5.4.2. Scheduling an RTCP Feedback Packet . . . . . . . . . 12 6. Adding and Removing SSRCs . . . . . . . . . . . . . . . . . . 14 6.1. Adding RTP Streams . . . . . . . . . . . . . . . . . . . 14 6.2. Removing RTP Streams . . . . . . . . . . . . . . . . . . 15 7. RTCP Considerations for Streams with Disparate Rates . . . . 16 7.1. Timing out SSRCs . . . . . . . . . . . . . . . . . . . . 17 7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter . 18 7.1.2. Avoiding Premature Timeout . . . . . . . . . . . . . 19 7.1.3. Interoperability Between RTP/AVP and RTP/AVPF . . . . 19 7.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 20 7.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 20 7.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 21 7.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Lennox, et al. Expires June 13, 2016 [Page 2] Internet-Draft Multiple Media Streams in an RTP Session December 2015 1. Introduction At the time the Real-Time Transport Protocol (RTP) [RFC3550] was originally designed, and for quite some time after, endpoints in RTP sessions typically only transmitted a single media source, and thus used a single RTP stream and thus synchronization source (SSRC) per RTP session, where separate RTP sessions were typically used for each distinct media type. Recently, however, a number of scenarios have emerged in which endpoints wish to send multiple RTP streams, distinguished by distinct RTP synchronization source (SSRC) identifiers, in a single RTP session. These are outlined in Section 3. Although the initial design of RTP did consider such scenarios, the specification was not consistently written with such use cases in mind. The specification is thus somewhat unclear in places. This memo updates [RFC3550] to clarify behaviour in use cases where endpoints use multiple SSRCs. It also updates [RFC4585] to resolve problems with regards to timeout of inactive SSRCs, and to clarify behaviour around inclusion of feedback messages. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. Use Cases For Multi-Stream Endpoints This section discusses several use cases that have motivated the development of endpoints that sends RTP data using multiple SSRCs in a single RTP session. 3.1. Endpoints with Multiple Capture Devices The most straightforward motivation for an endpoint to send multiple simultaneous RTP streams in a single RTP session is when an endpoint has multiple capture devices, and hence can generate multiple media sources, of the same media type and characteristics. For example, telepresence systems of the type described by the CLUE Telepresence Framework [I-D.ietf-clue-framework] often have multiple cameras or microphones covering various areas of a room, and hence send several RTP streams of each type within a single RTP session. Lennox, et al. Expires June 13, 2016 [Page 3] Internet-Draft Multiple Media Streams in an RTP Session December 2015 3.2. Multiple Media Types in a Single RTP Session Recent work has updated RTP [I-D.ietf-avtcore-multi-media-rtp-session] and SDP [I-D.ietf-mmusic-sdp-bundle-negotiation] to remove the historical assumption in RTP that media sources of different media types would always be sent on different RTP sessions. In this work, a single endpoint's audio and video RTP streams (for example) are instead sent in a single RTP session to reduce the number of transport layer flows used. 3.3. Multiple Stream Mixers There are several RTP topologies which can involve a central device that itself generates multiple RTP streams in a session. An example is a mixer providing centralized compositing for a multi-capture scenario like that described in Section 3.1. In this case, the centralized node is behaving much like a multi-capturer endpoint, generating several similar and related sources. A more complex example is the selective forwarding middlebox, described in Section 3.7 of [RFC7667]. This is a middlebox that receives RTP streams from several endpoints, and then selectively forwards modified versions of some RTP streams toward the other endpoints to which it is connected. For each connected endpoint, a separate media source appears in the session for every other source connected to the middlebox, "projected" from the original streams, but at any given time many of them can appear to be inactive (and thus are receivers, not senders, in RTP). This sort of device is closer to being an RTP mixer than an RTP translator, in that it terminates RTCP reporting about the mixed streams, and it can re- write SSRCs, timestamps, and sequence numbers, as well as the contents of the RTP payloads, and can turn sources on and off at will without appearing to generate packet loss. Each projected stream will typically preserve its original RTCP source description (SDES) information. 3.4. Multiple SSRCs for a Single Media Source There are also several cases where multiple SSRCs can be used to send data from a single media source within a single RTP session. These include, but are not limited to, transport robustness tools, such as the RTP retransmission payload format [RFC4588], that require one SSRC to be used for the media data and another SSRC for the repair data. Similarly, some layered media encoding schemes, for example H.264 SVC [RFC6190], can be used in a configuration where each layer is sent using a different SSRC within a single RTP session. Lennox, et al. Expires June 13, 2016 [Page 4] Internet-Draft Multiple Media Streams in an RTP Session December 2015 4. Use of RTP by endpoints that send multiple media streams RTP is inherently a group communication protocol. Each endpoint in an RTP session will use one or more SSRCs, as will some types of RTP level middlebox. Accordingly, unless restrictions on the number of SSRCs have been signalled, RTP endpoints can expect to receive RTP data packets sent using a number of different SSRCs, within a single RTP session. This can occur irrespective of whether the RTP session is running over a point-to-point connection or a multicast group, since middleboxes can be used to connect multiple transport connections together into a single RTP session (the RTP session is defined by the shared SSRC space, not by the transport connections). Furthermore, if RTP mixers are used, some SSRCs might only be visible in the contributing source (CSRC) list of an RTP packet and in RTCP, and might not appear directly as the SSRC of an RTP data packet. Every RTP endpoint will have an allocated share of the available session bandwidth, as determined by signalling and congestion control. The endpoint needs to keep its total media sending rate within this share. However, endpoints that send multiple RTP streams do not necessarily need to subdivide their share of the available bandwidth independently or uniformly to each RTP stream and its SSRCs. In particular, an endpoint can vary the bandwidth allocation to different streams depending on their needs, and can dynamically change the bandwidth allocated to different SSRCs (for example, by using a variable rate codec), provided the total sending rate does not exceed its allocated share. This includes enabling or disabling RTP streams, or their redundancy streams, as more or less bandwidth becomes available. 5. Use of RTCP by Endpoints that send multiple media streams The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550]. The description of the protocol is phrased in terms of the behaviour of "participants" in an RTP session, under the assumption that each endpoint is a participant with a single SSRC. However, for correct operation in cases where endpoints have multiple SSRC values, implementations MUST treat each SSRC as a separate participant in the RTP session, so that an endpoint that has multiple SSRCs counts as multiple participants. 5.1. RTCP Reporting Requirement An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a separate participant in the RTP session. Each SSRC will maintain its own RTCP-related state information, and hence will have its own RTCP reporting interval that determines when it sends RTCP reports. If the mechanism in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] is Lennox, et al. Expires June 13, 2016 [Page 5] Internet-Draft Multiple Media Streams in an RTP Session December 2015 not used, then each SSRC will send RTCP reports for all other SSRCs, including those co-located at the same endpoint. If the endpoint has some SSRCs that are sending data and some that are only receivers, then they will receive different shares of the RTCP bandwidth and calculate different base RTCP reporting intervals. Otherwise, all SSRCs at an endpoint will calculate the same base RTCP reporting interval. The actual reporting intervals for each SSRC are randomised in the usual way, but reports can be aggregated as described in Section 5.3. 5.2. Initial Reporting Interval When a participant joins a unicast session, the following text from Section 6.2 of [RFC3550] is relevant: "For unicast sessions... the delay before sending the initial compound RTCP packet MAY be zero." The basic assumption is that this also ought to apply in the case of multiple SSRCs. Caution has to be exercised, however, when an endpoint (or middlebox) with a large number of SSRCs joins a unicast session, since immediate transmission of many RTCP reports can create a significant burst of traffic, leading to transient congestion and packet loss due to queue overflows. To ensure that the initial burst of traffic generated by an RTP endpoint is no larger than would be generated by a TCP connection, an RTP endpoint MUST NOT send more than four compound RTCP packets with zero initial delay when it joins an RTP session, independently of the number of SSRCs used by the endpoint. Each of those initial compound RTCP packets MAY include aggregated reports from multiple SSRCs, provided the total compound RTCP packet size does not exceed the MTU, and the avg_rtcp_size is maintained as in Section 5.3.1. Aggregating reports from several SSRCs in the initial compound RTCP packets allows a substantial number of SSRCs to report immediately. Endpoints SHOULD prioritize reports on SSRCs that are likely to be most immediately useful, e.g., for SSRCs that are initially senders. An endpoint that needs to report on more SSRCs than will fit into the four compound RTCP reports that can be sent immediately MUST send the other reports later, following the usual RTCP timing rules including timer reconsideration. Those reports MAY be aggregated as described in Section 5.3. Note: The above is chosen to match the TCP maximum initial window of 4 packets [RFC3390], not the larger TCP initial windows for which there is an ongoing experiment [RFC6928]. The reason for this is a desire to be conservative, since an RTP endpoint will also in many cases start sending RTP data packets at the same time as these initial RTCP packets are sent. Lennox, et al. Expires June 13, 2016 [Page 6] Internet-Draft Multiple Media Streams in an RTP Session December 2015 5.3. Aggregation of Reports into Compound RTCP Packets As outlined in Section 5.1, an endpoint with multiple SSRCs has to treat each SSRC as a separate participant when it comes to sending RTCP reports. This will lead to each SSRC sending a compound RTCP packet in each reporting interval. Since these packets are coming from the same endpoint, it might reasonably be expected that they can be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] allows RTP translators and mixers to aggregate packets in similar circumstances: "It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet." This allows RTP translators and mixers to generate compound RTCP packets that contain multiple SR or RR packets from different SSRCs, as well as any of the other packet types. There are no restrictions on the order in which the RTCP packets can occur within the compound packet, except the regular rule that the compound RTCP packet starts with an SR or RR packet. Due to this rule, correctly implemented RTP endpoints will be able to handle compound RTCP packets that contain RTCP packets relating to multiple SSRCs. Accordingly, endpoints that use multiple SSRCs can aggregate the RTCP packets sent by their different SSRCs into compound RTCP packets, provided 1) the resulting compound RTCP packets begin with an SR or RR packet; 2) they maintain the average RTCP packet size as described in Section 5.3.1; and 3) they schedule packet transmission and manage aggregation as described in Section 5.3.2. 5.3.1. Maintaining AVG_RTCP_SIZE The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis. Each SSRC sends a single compound RTCP packet in each RTCP reporting interval. When an endpoint uses multiple SSRCs, it is desirable to aggregate the compound RTCP packets sent by its SSRCs, reducing the overhead by forming a larger compound RTCP packet. This aggregation Lennox, et al. Expires June 13, 2016 [Page 7] Internet-Draft Multiple Media Streams in an RTP Session December 2015 can be done as described in Section 5.3.2, provided the average RTCP packet size calculation is updated as follows. Participants in an RTP session update their estimate of the average RTCP packet size (avg_rtcp_size) each time they send or receive an RTCP packet (see Section 6.3.3 of [RFC3550]). When a compound RTCP packet that contains RTCP packets from several SSRCs is sent or received, the avg_rtcp_size estimate for each SSRC that is reported upon is updated using div_packet_size rather than the actual packet size: avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size where div_packet_size is packet_size divided by the number of SSRCs reporting in that compound packet. The number of SSRCs reporting in a compound packet is determined by counting the number of different SSRCs that are the source of Sender Report (SR) or Receiver Report (RR) RTCP packets within the compound RTCP packet. Non-compound RTCP packets (i.e., RTCP packets that do not contain an SR or RR packet [RFC5506]) are considered to report on a single SSRC. An SSRC that doesn't follow the above rule, and instead uses the full RTCP compound packet size to calculate avg_rtcp_size, will derive an RTCP reporting interval that is overly large by a factor that is proportional to the number of SSRCs aggregated into compound RTCP packets and the size of set of SSRCs being aggregated relative to the total number of participants. This increased RTCP reporting interval can cause premature timeouts if it is more than five times the interval chosen by the SSRCs that understand compound RTCP that aggregate reports from many SSRCs. A 1500 octet MTU can fit five typical size reports into a compound RTCP packet, so this is a real concern if endpoints aggregate RTCP reports from multiple SSRCs. The issue raised in the previous paragraph is mitigated by the modification in timeout behaviour specified in Section 7.1.2 of this memo. This mitigation is in place in those cases where the RTCP bandwidth is sufficiently high that an endpoint, using avg_rtcp_size calculated without taking into account the number of reporting SSRCs, can transmit more frequently than approximately every 5 seconds. Note, however, that the non-updated endpoint's RTCP reporting is still negatively impacted even if the premature timeout of its SSRCs are avoided. If compatibility with non-updated endpoints is a concern, the number of reports from different SSRCs aggregated into a single compound RTCP packet SHOULD either be limited to two reports, or aggregation ought not used at all. This will limit the non- updated endpoint's RTCP reporting interval to be no larger than twice the RTCP reporting interval that would be chosen by an endpoint following this specification. Lennox, et al. Expires June 13, 2016 [Page 8] Internet-Draft Multiple Media Streams in an RTP Session December 2015 5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs This section revises and extends the behaviour defined in Section 6.3 of [RFC3550], and in Section 3.5.3 of [RFC4585] if the RTP/AVPF profile or the RTP/SAVPF profile is used, regarding actions to take when scheduling and sending RTCP packets where multiple reporting SSRCs are aggregating their RTCP packets into the same compound RTCP packet. These changes to the RTCP scheduling rules are needed to maintain important RTCP timing properties, including the inter-packet distribution, and the behaviour during flash joins and other changes in session membership. The variables tn, tp, tc, T, and Td used in the following are defined in Section 6.3 of [RFC3550]. The variables T_rr_interval and T_rr_last are defined in [RFC4585]. Each endpoint MUST schedule RTCP transmission independently for each of its SSRCs using the regular calculation of tn for the RTP profile being used. Each time the timer tn expires for an SSRC, the endpoint MUST perform RTCP timer reconsideration and, if applicable, T_rr_interval based suppression. If the result indicates that a compound RTCP packet is to be sent by that SSRC, and the transmission is not an early RTCP packet [RFC4585], then the endpoint SHOULD try to aggregate RTCP packets of additional SSRCs that are scheduled in the future into the compound RTCP packet before it is sent. The reason to limit or not aggregate at due to backwards compatibility reasons was discussed earlier in Section 5.3.1. Aggregation proceeds as follows. The endpoint selects the SSRC that has the smallest tn value after the current time, tc, and prepares the RTCP packets that SSRC would send if its timer tn expired at tc. If those RTCP packets will fit into the compound RTCP packet that is being generated, taking into account the path MTU and the previously added RTCP packets, then they are added to the compound RTCP packet; otherwise they are discarded. This process is repeated for each SSRC, in order of increasing tn, until the compound RTCP packet is full, or all SSRCs have been aggregated. At that point, the compound RTCP packet is sent. When the compound RTCP packet is sent, the endpoint MUST update tp, tn, and T_rr_last (if applicable) for each SSRC that was included. These variables are updated as follows: a. For the first SSRC that reported in the compound RTCP packet, set the effective transmission time, tt, of that SSRC to tc. b. For each additional SSRC that reported in the compound RTCP packet, calculate the transmission time that SSRC would have had Lennox, et al. Expires June 13, 2016 [Page 9] Internet-Draft Multiple Media Streams in an RTP Session December 2015 if it had not been aggregated into the compound RTCP packet. This is derived by taking tn for that SSRC, then performing reconsideration and updating tn until tp + T <= tn. Once this is done, set the effective transmission time, tt, for that SSRC to the calculated value of tn. If the RTP/AVPF profile or the RTP/ SAVPF profile is being used, then T_rr_interval based suppression MUST NOT be used in this calculation. c. Calculate average effective transmission time, tt_avg, for the compound RTCP packet based on the tt values for all SSRCs sent in the compound RTCP packet. Set tp for each of the SSRCs sent in the compound RTCP packet to tt_avg. If the RTP/AVPF profile or the RTP/SAVPF profile is being used, set T_tt_last for each SSRC sent in the compound RTCP packet to tt_avg. d. For each of the SSRCs sent in the compound RTCP packet, calculate new tn values based on the updated parameters and the usual RTCP timing rules, and reschedule the timers. When using the RTP/AVPF profile or the RTP/SAVPF profile, the above mechanism only attempts to aggregate RTCP packets when the compound RTCP packet to be sent is not an early RTCP packet, and hence the algorithm in Section 3.5.3 of [RFC4585] will control RTCP scheduling. If T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or 2b of the algorithm are chosen, then the above mechanism updates the necessary variables. However, if the transmission is suppressed per option 2c of the algorithm, then tp is updated to tc as aggregation has not taken place. Reverse reconsideration MUST be performed following Section 6.3.4 of [RFC3550]. In some cases, this can lead to the value of tp after reverse reconsideration being larger than tc. This is not a problem, and has the desired effect of proportionally pulling the tp value towards tc (as well as tn) as the reporting interval shrinks in direct proportion the reduced group size. The above algorithm has been shown in simulations [Sim88][Sim92] to maintain the inter-RTCP packet transmission time distribution for each SSRC, and to consume the same amount of bandwidth as non- aggregated RTCP packets. With this algorithm the actual transmission interval for an SSRC triggering an RTCP compound packet transmission is following the regular transmission rules. The value tp is set to somewhere in the interval [0,1.5/1.21828*Td] ahead of tc. The actual value is average of one instance of tc and the randomized transmission times of the additional SSRCs, thus the lower range of the interval is more probable. This compensates for the bias that is otherwise introduced by picking the shortest tn value out of the N SSRCs included in aggregate. Lennox, et al. Expires June 13, 2016 [Page 10] Internet-Draft Multiple Media Streams in an RTP Session December 2015 The algorithm also handles the cases where the number of SSRCs that can be included in an aggregated packet varies. An SSRC that previously was aggregated and fails to fit in a packet still has its own transmission scheduled according to normal rules. Thus, it will trigger a transmission in due time, or the SSRC will be included in another aggregate. The algorithm's behaviour under SSRC group size changes is as follows: RTP sessions where the number of SSRC are growing: When the group size is growing, Td grows in proportion to the number of new SSRCs in the group. When reconsideration is performed due to expiry of the tn timer, that SSRC will reconsider the transmission and with a certain probability reschedule the tn timer. This part of the reconsideration algorithm is only impacted by the above algorithm by having tp values that were in the future instead of set to the time of the actual last transmission at the time of updating tp. RTP sessions where the number of SSRC are shrinking: When the group shrinks, reverse reconsideration moves the tp and tn values towards tc proportionally to the number of SSRCs that leave the session compared to the total number of participants when they left. The setting of the tp value forward in time related to the tc could be believed to have negative effect. However, the reason for this setting is to compensate for bias caused by picking the shortest tn out of the N aggregated. This bias remains over a reduction in the number of SSRCs. The reverse reconsideration compensates the reduction independently of aggregation being used or not. The negative effect that can occur on removing an SSRC is that the most favourable tn belonged to the removed SSRC. The impact of this is limited to delaying the transmission, in the worst case, one reporting interval. In conclusion the investigations performed have found no significant negative impact on the scheduling algorithm. 5.4. Use of RTP/AVPF or RTP/SAVPF Feedback This section discusses the transmission of RTP/AVPF feedback packets when the transmitting endpoint has multiple SSRCs. The guidelines in this section also apply to endpoints using the RTP/SAVPF profile. 5.4.1. Choice of SSRC for Feedback Packets When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC to use as the source for the RTCP feedback packets it sends. Several factors can affect that choice: Lennox, et al. Expires June 13, 2016 [Page 11] Internet-Draft Multiple Media Streams in an RTP Session December 2015 o RTCP feedback packets relating to a particular media type SHOULD be sent by an SSRC that receives that media type. For example, when audio and video are multiplexed onto a single RTP session, endpoints will use their audio SSRC to send feedback on the audio received from other participants. o RTCP feedback packets and RTCP codec control messages that are notifications or indications regarding RTP data processed by an endpoint MUST be sent from the SSRC used for that RTP data. This includes notifications that relate to a previously received request or command [RFC4585][RFC5104]. o If separate SSRCs are used to send and receive media, then the corresponding SSRC SHOULD be used for feedback, since they have differing RTCP bandwidth fractions. This can also affect the consideration if the SSRC can be used in immediate mode or not. o Some RTCP feedback packet types require consistency in the SSRC used. For example, if a TMMBR limitation [RFC5104] is set by an SSRC, the same SSRC needs to be used to remove the limitation. o If several SSRCs are suitable for sending feedback, it might be desirable to use an SSRC that allows the sending of feedback as an early RTCP packet. When an RTCP feedback packet is sent as part of a compound RTCP packet that aggregates reports from multiple SSRCs, there is no requirement that the compound packet contains an SR or RR packet generated by the sender of the RTCP feedback packet. For reduced- size RTCP packets, aggregation of RTCP feedback packets from multiple sources is not limited further than Section 4.2.2 of [RFC5506]. 5.4.2. Scheduling an RTCP Feedback Packet When an SSRC has a need to transmit a feedback packet in early mode it MUST schedule that packet following the algorithm in Section 3.5 of [RFC4585] modified as follows: o To determine whether an RTP session is considered to be a point- to-point session or a multiparty session, an endpoint MUST count the number of distinct RTCP SDES CNAME values used by the SSRCs listed in the SSRC field of RTP data packets it receives and in the "SSRC of sender" field of RTCP SR, RR, RTPFB, or PSFB packets it receives. An RTP session is considered to be a multiparty session if more than one CNAME is used by those SSRCs, unless signalling indicates that the session is to be handled as point to point, or RTCP reporting groups [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are used. If Lennox, et al. Expires June 13, 2016 [Page 12] Internet-Draft Multiple Media Streams in an RTP Session December 2015 RTCP reporting groups are used, an RTP session is considered to be a point-to-point session if the endpoint receives only a single reporting group, and considered to be a multiparty session if multiple reporting groups are received, or if a combination of reporting groups and SSRCs that are not part of a reporting group are received. Endpoints MUST NOT determine whether an RTP session is multiparty or point-to-point based on the type of connection (unicast or multicast) used, or on the number of SSRCs received. o When checking if there is already a scheduled compound RTCP packet containing feedback messages (Step 2 in Section 3.5.2 of [RFC4585]), that check MUST be done considering all local SSRCs. o If an SSRC is not allowed to send an early RTCP packet, then the feedback message MAY be queued for transmission as part of any early or regular scheduled transmission that can occur within the maximum useful lifetime of the feedback message (T_max_fb_delay). This modifies the behaviour in bullet 4a) in Section 3.5.2 of [RFC4585]. The first bullet point above specifies a rule to determine if an RTP session is to be considered a point-to-point session or a multiparty session. This rule is straightforward to implement, but is known to incorrectly classify some sessions as multiparty sessions. The known problems are as follows: Endpoint with multiple synchronization contexts: An endpoint that is part of a point-to-point session can have multiple synchronization contexts, for example due to forwarding an external media source into a interactive real-time conversation. In this case the classification will consider the peer as two endpoints, while the actual RTP/RTCP transmission will be under the control of one endpoint. Selective Forwarding Middlebox: The SFM as defined in Section 3.7 of [RFC7667] has control over the transmission and configurations between itself and each peer endpoint individually. It also fully controls the RTCP packets being forwarded between the individual legs. Thus, this type of middlebox can be compared to the RTP mixer, which uses its own SSRCs to mix or select the media it forwards, that will be classified as a point-to-point RTP session by the above rule. In the above cases it is very reasonable to use RTCP reporting groups [I-D.ietf-avtcore-rtp-multi-stream-optimisation]. If that extension is used, an endpoint can indicate that the multitude of CNAMEs are in fact under a single endpoint or middlebox control by using only a single reporting group. Lennox, et al. Expires June 13, 2016 [Page 13] Internet-Draft Multiple Media Streams in an RTP Session December 2015 The above rules will also classify some sessions where the endpoint is connected to an RTP mixer as being point to point. For example the mixer could act as gateway to an Any Source Multicast based RTP session for the discussed endpoint. However, this will in most cases be okay, as the RTP mixer provides separation between the two parts of the session. The responsibility falls on the mixer to act accordingly in each domain. Finally, we note that signalling mechanisms could be defined to override the rules when it would result in the wrong classification. 6. Adding and Removing SSRCs The set of SSRCs present in a single RTP session can vary over time due to changes in the number of endpoints in the session, or due to changes in the number or type of RTP streams being sent. Every endpoint in an RTP session will have at least one SSRC that it uses for RTCP reporting, and for sending media if desired. It can also have additional SSRCs, for sending extra media sources or for additional RTCP reporting. If the set of media sources being sent changes, then the set of SSRCs being sent will change. Changes in the media format or clock rate might also require changes in the set of SSRCs used. An endpoint can also have more SSRCs than it has active RTP streams, and send RTCP relating to SSRCs that are not currently sending RTP data packets so that its peers are aware of the SSRCs, and have the associated context (e.g., clock synchronisation and an SDES CNAME) in place to be able to play out media as soon as they becomes active. In the following, we describe some considerations around adding and removing RTP streams and their associated SSRCs. 6.1. Adding RTP Streams When an endpoint joins an RTP session it can have zero, one, or more RTP streams it will send, or that it is prepared to send. If it has no RTP stream it plans to send, it still needs an SSRC that will be used to send RTCP feedback. If it will send one or more RTP streams, it will need the corresponding number of SSRC values. The SSRCs used by an endpoint are made known to other endpoints in the RTP session by sending RTP and RTCP packets. SSRCs can also be signalled using non-RTP means (e.g., [RFC5576]). Unless restricted by signalling, an endpoint can, at any time, send an additional RTP stream, identified by a new SSRC (this might be associated with a signalling event, but that is outside the scope of this memo). This makes the new SSRC visible to the other endpoints in the session, since they share the single SSRC space inherent in the definition of an RTP session. Lennox, et al. Expires June 13, 2016 [Page 14] Internet-Draft Multiple Media Streams in an RTP Session December 2015 An endpoint that has never sent an RTP stream will have an SSRC that it uses for RTCP reporting. If that endpoint wants to start sending an RTP stream, it is RECOMMENDED that it use its existing SSRC for that stream, since otherwise the participant count in the RTP session will be unnecessary increased, leading to a longer RTCP reporting interval and larger RTCP reports due to cross reporting. If the endpoint wants to start sending more than one RTP stream, it will need to generate a new SSRC for the second and any subsequent RTP streams. An endpoint that has previously stopped sending an RTP stream, and that wants to start sending a new RTP stream, cannot generally re-use the existing SSRC, and often needs to generate a new SSRC, because an SSRC cannot change media type (e.g., audio to video) or RTP timestamp clock rate [RFC7160], and because the SSRC might be associated with a particular semantic by the application (note: an RTP stream can pause and restart using the same SSRC, provided RTCP is sent for that SSRC during the pause; these rules only apply to new RTP streams reusing an existing SSRC). 6.2. Removing RTP Streams An SSRC is removed from an RTP session in one of two ways. When an endpoint stops sending RTP and RTCP packets using an SSRC, then that SSRC will eventually time out as described in Section 6.3.5 of [RFC3550]. Alternatively, an SSRC can be explicitly removed from use by sending an RTCP BYE packet as described in Section 6.3.7 of [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by sending an RTCP BYE packet. Note that [RFC3550] requires that the RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session for an SSRC. If an endpoint needs to restart an RTP stream after sending an RTCP BYE for its SSRC, it needs to generate a new SSRC value for that stream. The finality of sending RTCP BYE, means that endpoints needs to consider if the ceasing of transmission of an RTP stream is temporary or permanent. Temporary suspension of media transmission using a particular RTP stream (SSRC) needs to maintain that SSRC as an active participant, by continuing RTCP transmission for it. That way the media sending can be resume immediately, knowing that the context is in place. Permanent transmission halting needs to send RTCP BYE to allow the other participants to use the RTCP bandwidth resources and clean up their state databases. An endpoint that ceases transmission of all its RTP streams but remains in the RTP session MUST maintain at least one SSRC that is to be used for RTCP reporting and feedback (i.e., it cannot send a BYE for all SSRCs, but needs to retain at least one active SSRC). As Lennox, et al. Expires June 13, 2016 [Page 15] Internet-Draft Multiple Media Streams in an RTP Session December 2015 some Feedback packets can be bound to media type there might be need to maintain one SSRC per media type within an RTP session. An alternative can be to create a new SSRC to use for RTCP reporting and feedback. However, to avoid the perception that an endpoint drops completely out of an RTP session such a new SSRC ought to be first established before terminating all the existing SSRCs. 7. RTCP Considerations for Streams with Disparate Rates An RTP session has a single set of parameters that configure the session bandwidth. These are the RTCP sender and receiver fractions (e.g., the SDP "b=RR:" and "b=RS:" lines [RFC3556]), and the parameters of the RTP/AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its secure extension, RTP/SAVPF [RFC5124]) is used. As a consequence, the base RTCP reporting interval, before randomisation, will be the same for every sending SSRC in an RTP session. Similarly, every receiving SSRC in an RTP session will have the same base reporting interval, although this can differ from the reporting interval chosen by sending SSRCs. This uniform RTCP reporting interval for all SSRCs can result in RTCP reports being sent more often, or too seldom, than is considered desirable for a RTP stream. For example, consider a scenario when an audio flow sending at tens of kilobits per second is multiplexed into an RTP session with a multi-megabit high quality video flow. If the session bandwidth is configured based on the video sending rate, and the default RTCP bandwidth fraction of 5% of the session bandwidth is used, it is likely that the RTCP bandwidth will exceed the audio sending rate. If the reduced minimum RTCP interval described in Section 6.2 of [RFC3550] is then used in the session, as appropriate for video where rapid feedback on damaged I-frames is wanted, the uniform reporting interval for all senders could mean that audio sources are expected to send RTCP packets more often than they send audio data packets. This bandwidth mismatch can be reduced by careful tuning of the RTCP parameters, especially trr_int when the RTP/AVPF profile is used, but cannot be avoided entirely as it is inherent in the design of the RTCP timing rules, and affects all RTP sessions that contain flows with greatly mismatched bandwidth. Different media rates or desired RTCP behaviours can also occur with SSRCs carrying the same media type. A common case in multiparty conferencing is when a small number of video streams are shown in high resolution, while the others are shown as low resolution thumbnails, with the choice of which is shown in high resolution being voice activity controlled. Here the differences are both in actual media rate and in choices for what feedback messages might be needed. Other examples of differences that can exist are due to the intended usage of a media source. A media source carrying the video Lennox, et al. Expires June 13, 2016 [Page 16] Internet-Draft Multiple Media Streams in an RTP Session December 2015 of the speaker in a conference is different from a document camera. Basic parameters that can differ in this case are frame-rate, acceptable end-to-end delay, and the SNR fidelity of the image. These differences affect not only the needed bit-rates, but also possible transmission behaviours, usable repair mechanisms, what feedback messages the control and repair requires, the transmission requirements on those feedback messages, and monitoring of the RTP stream delivery. Other similar scenarios can also exist. Sending multiple media types in a single RTP session causes that session to contain more SSRCs than if each media type was sent in a separate RTP session. For example, if two participants each send an audio and a video RTP stream in a single RTP session, that session will comprise four SSRCs, but if separate RTP sessions had been used for audio and video, each of those two RTP sessions would comprise only two SSRCs. Sending multiple RTP streams in an RTP session hence increases the amount of cross reporting between the SSRCs, as each SSRC reports on all other SSRCs in the session. This increases the size of the RTCP reports, causing them to be sent less often than would be the case if separate RTP sessions where used for a given RTCP bandwidth. Finally, when an RTP session contains multiple media types, it is important to note that the RTCP reception quality reports, feedback messages, and extended report blocks used might not be applicable to all media types. Endpoints will need to consider the media type of each SSRC only send or process reports and feedback that apply to that particular SSRC and its media type. Signalling solutions might have shortcomings when it comes to indicating that a particular set of RTCP reports or feedback messages only apply to a particular media type within an RTP session. From an RTCP perspective, therefore, it can be seen that there are advantages to using separate RTP sessions for each media source, rather than sending multiple media sources in a single RTP session. However, these are frequently offset by the need to reduce port use, to ease NAT/firewall traversal, achieved by combining media sources into a single RTP session. The following sections consider some of the issues with using RTCP in sessions with multiple media sources in more detail. 7.1. Timing out SSRCs Various issues have been identified with timing out SSRC values when sending multiple RTP streams in an RTP session. Lennox, et al. Expires June 13, 2016 [Page 17] Internet-Draft Multiple Media Streams in an RTP Session December 2015 7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter The RTP/AVPF profile includes a method to prevent regular RTCP reports from being sent too often. This mechanism is described in Section 3.5.3 of [RFC4585], and is controlled by the T_rr_interval parameter. It works as follows. When a regular RTCP report is sent, a new random value, T_rr_current_interval, is generated, drawn evenly in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP packet is to be sent earlier then T_rr_current_interval seconds after the previous regular RTCP packet, and there are no feedback messages to be sent, then that regular RTCP packet is suppressed, and the next regular RTCP packet is scheduled. The T_rr_current_interval is recalculated each time a regular RTCP packet is sent. The benefit of suppression is that it avoids wasting bandwidth when there is nothing requiring frequent RTCP transmissions, but still allows utilization of the configured bandwidth when feedback is needed. Unfortunately this suppression mechanism skews the distribution of the RTCP sending intervals compared to the regular RTCP reporting intervals. The standard RTCP timing rules, including reconsideration and the compensation factor, result in the intervals between sending RTCP packets having a distribution that is skewed towards the upper end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the deterministic calculated RTCP reporting interval. With Td = 5s this distribution covers the range [2.052s, 6.156s]. In comparison, the RTP/AVPF suppression rules act in an interval that is 0.5 to 1.5 times T_rr_interval; for T_rr_interval = 5s this is [2.5s, 7.5s]. The effect of this is that the time between consecutive RTCP packets when using T_rr_interval suppression can become large. The maximum time interval between sending one regular RTCP packet and the next, when T_rr_interval is being used, occurs when T_rr_current_interval takes its maximum value and a regular RTCP packet is suppressed at the end of the suppression period, then the next regular RTCP packet is scheduled after its largest possible reporting interval. Taking the worst case of the two intervals gives a maximum time between two RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td. This behaviour can be surprising when Td and T_rr_interval have the same value. That is, when T_rr_interval is configured to match the regular RTCP reporting interval. In this case, one might expect that regular RTCP packets are sent according to their usual schedule, but feedback packets can be sent early. However, the above-mentioned issue results in the RTCP packets actually being sent in the range [0.5*Td, 2.731*Td] with a highly non-uniform distribution, rather than the range [0.41*Td, 1.23*Td]. This is perhaps unexpected, but is not a problem in itself. However, when coupled with packet loss, it raises the issue of premature timeout. Lennox, et al. Expires June 13, 2016 [Page 18] Internet-Draft Multiple Media Streams in an RTP Session December 2015 7.1.2. Avoiding Premature Timeout In RTP/AVP [RFC3550] the timeout behaviour is simple, and is 5 times Td, where Td is calculated with a Tmin value of 5 seconds. In other words, if the configured RTCP bandwidth allows for an average RTCP reporting interval shorter than 5 seconds, the timeout is 25 seconds of no activity from the SSRC (RTP or RTCP), otherwise the timeout is 5 average reporting intervals. RTP/AVPF [RFC4585] introduces different timeout behaviours depending on the value of T_rr_interval. When T_rr_interval is 0, it uses the same timeout calculation as RTP/AVP. However, when T_rr_interval is non-zero, it replaces Tmin in the timeout calculation, most likely to speed up detection of timed out SSRCs. However, using a non-zero T_rr_interval has two consequences for RTP behaviour. First, due to suppression, the number of RTP and RTCP packets sent by an SSRC that is not an active RTP sender can become very low, because of the issue discussed in Section 7.1.1. As the RTCP packet interval can be as long as 2.73*Td, then during a 5*Td time period an endpoint might in fact transmit only a single RTCP packet. The long intervals result in fewer RTCP packets, to a point where a single RTCP packet loss can sometimes result in timing out an SSRC. Second, the RTP/AVPF changes to the timeout rules reduce robustness to misconfiguration. It is common to use RTP/AVPF configured such that RTCP packets can be sent frequently, to allow rapid feedback, however this makes timeouts very sensitive to T_rr_interval. For example, if two SSRCs are configured one with T_rr_interval = 0.1s and the other with T_rr_interval = 0.6s, then this small difference will result in the SSRC with the shorter T_rr_interval timing out the other if it stops sending RTP packets, since the other RTCP reporting interval is more than five times its own. When RTP/AVP is used, or RTP/AVPF with T_rr_interval = 0, this is a non-issue, as the timeout period will be 25s, and differences between configured RTCP bandwidth can only cause premature timeouts when the reporting intervals are greater than 5s and differ by a factor of five. To limit the scope for such problematic misconfiguration, we propose an update to the RTP/AVPF timeout rules in Section 7.1.4. 7.1.3. Interoperability Between RTP/AVP and RTP/AVPF If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their secure variants) are combined within a single RTP session, and the RTP/AVPF endpoints use a non-zero T_rr_interval that is significantly below 5 seconds, there is a risk that the RTP/AVPF endpoints will prematurely timeout the SSRCs of the RTP/AVP endpoints, due to their different RTCP timeout rules. Conversely, if the RTP/AVPF endpoints Lennox, et al. Expires June 13, 2016 [Page 19] Internet-Draft Multiple Media Streams in an RTP Session December 2015 use a T_rr_interval that is significant larger than 5 seconds, there is a risk that the RTP/AVP endpoints will timeout the SSRCs of the RTP/AVPF endpoints. Mixing endpoints using two different RTP profiles within a single RTP session is NOT RECOMMENDED. However, if mixed RTP profiles are used, and the RTP/AVPF endpoints are not updated to follow Section 7.1.4 of this memo, then the RTP/AVPF session SHOULD be configured to use T_rr_interval = 4 seconds to avoid premature timeouts. The choice of T_rr_interval = 4 seconds for interoperability might appear strange. Intuitively, this value ought to be 5 seconds, to make both the RTP/AVP and RTP/AVPF use the same timeout period. However, the behaviour outlined in Section 7.1.1 shows that actual RTP/AVPF reporting intervals can be longer than expected. Setting T_rr_interval = 4 seconds gives actual RTCP intervals near to those expected by RTP/AVP, ensuring interoperability. 7.1.4. Updated SSRC Timeout Rules To ensure interoperability and avoid premature timeouts, all SSRCs in an RTP session MUST use the same timeout behaviour. However, previous specification are inconsistent in this regard. To avoid interoperability issues, this memo updates the timeout rules as follows: o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the timeout interval SHALL be calculated using a multiplier of five times the deterministic RTCP reporting interval. That is, the timeout interval SHALL be 5*Td. o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, calculation of Td, for the purpose of calculating the participant timeout only, SHALL be done using a Tmin value of 5 seconds and not the reduced minimal interval, even if the reduced minimum interval is used to calculate RTCP packet transmission intervals. This changes the behaviour for the RTP/AVPF or RTP/SAVPF profiles when T_rr_interval != 0. Specifically, the first paragraph of Section 3.5.4 of [RFC4585] is updated to use Tmin instead of T_rr_interval in the timeout calculation for RTP/AVPF entities. 7.2. Tuning RTCP transmissions This sub-section discusses what tuning can be done to reduce the downsides of the shared RTCP packet intervals. First, it is considered what possibilities exist for the RTP/AVP [RFC3551] Lennox, et al. Expires June 13, 2016 [Page 20] Internet-Draft Multiple Media Streams in an RTP Session December 2015 profile, then what additional tools are provided by RTP/AVPF [RFC4585]. 7.2.1. RTP/AVP and RTP/SAVP When using the RTP/AVP or RTP/SAVP profiles, the options for tuning the RTCP reporting intervals are limited to the RTCP sender and receiver bandwidth, and whether the minimum RTCP interval is scaled according to the bandwidth. As the scheduling algorithm includes both randomisation and reconsideration, one cannot simply calculate the expected average transmission interval using the formula for Td given in Section 6.3.1 of [RFC3550]. However, by considering the inputs to that expression, and the randomisation and reconsideration rules, we can begin to understand the behaviour of the RTCP transmission interval. Let's start with some basic observations: a. Unless the scaled minimum RTCP interval is used, then Td prior to randomization and reconsideration can never be less than Tmin. The default value of Tmin is 5 seconds. b. If the scaled minimum RTCP interval is used, Td can become as low as 360 divided by RTP Session bandwidth in kilobits per second. In SDP the RTP session bandwidth is signalled using a "b=AS" line. An RTP Session bandwidth of 72kbps results in Tmin being 5 seconds. An RTP session bandwidth of 360kbps of course gives a Tmin of 1 second, and to achieve a Tmin equal to once every frame for a 25 frame-per-second video stream requires an RTP session bandwidth of 9Mbps. Use of the RTP/AVPF or RTP/SAVPF profile allows more frequent RTCP reports for the same bandwidth, as discussed below. c. The value of Td scales with the number of SSRCs and the average size of the RTCP reports, to keep the overall RTCP bandwidth constant. d. The actual transmission interval for a Td value is in the range [0.5*Td/1.21828,1.5*Td/1.21828], and the distribution is skewed, due to reconsideration, with the majority of the probability mass being above Td. This means, for example, that for Td = 5s, the actual transmission interval will be distributed in the range [2.052s, 6.156s], and tending towards the upper half of the interval. Note that Tmin parameter limits the value of Td before randomisation and reconsideration are applied, so the actual transmission interval will cover a range extending below Tmin. Lennox, et al. Expires June 13, 2016 [Page 21] Internet-Draft Multiple Media Streams in an RTP Session December 2015 Given the above, we can calculate the number of SSRCs, n, that an RTP session with 5% of the session bandwidth assigned to RTCP can support while maintaining Td equal to Tmin. This will tell us how many RTP streams we can report on, keeping the RTCP overhead within acceptable bounds. We make two assumptions that simplify the calculation: that all SSRCs are senders, and that they all send compound RTCP packets comprising an SR packet with n-1 report blocks, followed by an SDES packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets will vary in size between 54 and 798 octets depending on n, up to the maximum of 31 report blocks that can be included in an SR packet). If we put this packet size, and a 5% RTCP bandwidth fraction into the RTCP interval calculation in Section 6.3.1 of [RFC3550], and calculate the value of n needed to give Td = Tmin for the scaled minimum interval, we find n=9 SSRCs can be supported (irrespective of the interval, due to the way the reporting interval scales with the session bandwidth). We see that to support more SSRCs without changing the scaled minimum interval, we need to increase the RTCP bandwidth fraction from 5%; changing the session bandwidth to a higher value would reduce the Tmin. However, if using the default 5% allocation of RTCP bandwidth, an increase will result in more SSRCs being supported given a fixed Td target. Based on the above, when using the RTP/AVP profile or the RTP/SAVP profile, the key limitation for rapid RTCP reporting in small unicast sessions is going to be the Tmin value. The RTP session bandwidth configured in RTCP has to be sufficiently high to reach the reporting goals the application has following the rules for the scaled minimal RTCP interval. 7.2.2. RTP/AVPF and RTP/SAVPF When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool for tuning RTCP transmissions: the T_rr_interval parameter. Use of this parameter allows short RTCP reporting intervals; alternatively it gives the ability to sent frequent RTCP feedback without sending frequent regular RTCP reports. The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set to a value greater than zero but smaller than Tmin allows more frequent RTCP feedback than the RTP/AVP or RTP/SAVP profiles, for a given RTCP bandwidth. This happens because Tmin is set to zero after the transmission of the initial RTCP report, causing the reporting interval for later packet to be determined by the usual RTCP bandwidth-based calculation, with Tmin=0, and the T_rr_interval. This has the effect that we are no longer restricted by the minimal interval (whether the default 5 second minimum, or the reduced minimum interval). Rather, the RTCP bandwidth and the T_rr_interval are the governing factors, allowing faster feedback. Applications Lennox, et al. Expires June 13, 2016 [Page 22] Internet-Draft Multiple Media Streams in an RTP Session December 2015 that care about rapid regular RTCP feedback ought to consider using the RTP/AVPF or RTP/SAVPF profile, even if they don't use the feedback features of that profile. The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback packets to be sent frequently, without also requiring regular RTCP reports to be sent frequently, since T_rr_interval limits the rate at which regular RTCP packets can be sent, while still permitting RTCP feedback packets to be sent. Applications that can use feedback packets for some RTP streams, e.g., video streams, but don't want frequent regular reporting for other RTP streams, can configure the T_rr_interval to a value so that the regular reporting for both audio and video is at a level that is considered acceptable for the audio. They could then use feedback packets, which will include RTCP SR/RR packets unless reduced size RTCP feedback packets [RFC5506] are used, for the video reporting. This allows the available RTCP bandwidth to be devoted on the feedback that provides the most utility for the application. Using T_rr_interval still requires one to determine suitable values for the RTCP bandwidth value. Indeed, it might make this choice even more important, as this is more likely to affect the RTCP behaviour and performance than when using the RTP/AVP or RTP/SAVP profile, as there are fewer limitations affecting the RTCP transmission. When T_rr_interval is non-zero, there are configurations that need to be avoided. If the RTCP bandwidth chosen is such that the Td value is smaller than, but close to, T_rr_interval, then the actual regular RTCP packet transmission interval can become very large, as discussed in Section 7.1.1. Therefore, for configuration where one intends to have Td smaller than T_rr_interval, then Td is RECOMMENDED to be targeted at values less than 1/4th of T_rr_interval which results in that the range becomes [0.5*T_rr_interval, 1.81*T_rr_interval]. With the RTP/AVPF or RTP/SAVPF profiles, using T_rr_interval = 0 has utility, and results in a behaviour where the RTCP transmission is only limited by the bandwidth, i.e., no Tmin limitations at all. This allows more frequent regular RTCP reporting than can be achieved using the RTP/AVP profile. Many configurations of RTCP will not consume all the bandwidth that they have been configured to use, but this configuration will consume what it has been given. Note that the same behaviour will be achieved as long as T_rr_interval is smaller than 1/3 of Td as that prevents T_rr_interval from affecting the transmission. There exists no method for using different regular RTCP reporting intervals depending on the media type or individual RTP stream, other than using a separate RTP session for each type or stream. Lennox, et al. Expires June 13, 2016 [Page 23] Internet-Draft Multiple Media Streams in an RTP Session December 2015 8. Security Considerations When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the cryptographic context of a compound secure RTCP packet is the SSRC of the sender of the first RTCP (sub-)packet. This could matter in some cases, especially for keying mechanisms such as Mikey [RFC3830] which allow use of per-SSRC keying. Otherwise, the standard security considerations of RTP apply; sending multiple RTP streams from a single endpoint in a single RTP session does not appear to have different security consequences than sending the same number of RTP streams spread across different RTP sessions. 9. IANA Considerations No IANA actions are needed. 10. Acknowledgments The authors like to thank Harald Alvestrand and everyone else who has been involved in the development of this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . Lennox, et al. Expires June 13, 2016 [Page 24] Internet-Draft Multiple Media Streams in an RTP Session December 2015 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . 11.2. Informative References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", draft- ietf-avtcore-multi-media-rtp-session-12 (work in progress), December 2015. [I-D.ietf-avtcore-rtp-multi-stream-optimisation] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", draft-ietf-avtcore-rtp-multi-stream-optimisation-09 (work in progress), November 2015. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue- framework-24 (work in progress), November 2015. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-23 (work in progress), July 2015. [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, DOI 10.17487/RFC3390, October 2002, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . Lennox, et al. Expires June 13, 2016 [Page 25] Internet-Draft Multiple Media Streams in an RTP Session December 2015 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, . [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Lennox, et al. Expires June 13, 2016 [Page 26] Internet-Draft Multiple Media Streams in an RTP Session December 2015 [Sim88] Westerlund, M., "SIMULATION RESULTS FOR MULTI-STREAM", IETF Proceedings https://www.ietf.org/proceedings/92/slides/slides-92- avtcore-0.pdf, November 2013. [Sim92] Westerlund, M., "Changes in RTP Multi-stream", IETF Proceedings https://www.ietf.org/proceedings/92/slides/slides-92- avtcore-0.pdf, March 2015. Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 USA Email: jonathan@vidyo.com Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Lennox, et al. Expires June 13, 2016 [Page 27] ./draft-ietf-cose-msg-24.txt0000664000764400076440000100212713015135140015071 0ustar iustyiusty COSE Working Group J. Schaad Internet-Draft August Cellars Intended status: Standards Track November 22, 2016 Expires: May 26, 2017 CBOR Object Signing and Encryption (COSE) draft-ietf-cose-msg-24 Abstract Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. Contributing to this document The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at . Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 26, 2017. Schaad Expires May 26, 2017 [Page 1] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Design changes from JOSE . . . . . . . . . . . . . . . . 5 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 6 1.3. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 6 1.4. CBOR Related Terminology . . . . . . . . . . . . . . . . 7 1.5. Document Terminology . . . . . . . . . . . . . . . . . . 8 2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 8 3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Common COSE Headers Parameters . . . . . . . . . . . . . 12 4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Signing with One or More Signers . . . . . . . . . . . . 16 4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 18 4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 19 4.4. Signing and Verification Process . . . . . . . . . . . . 20 4.5. Computing Counter Signatures . . . . . . . . . . . . . . 22 5. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 22 5.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 22 5.1.1. Content Key Distribution Methods . . . . . . . . . . 24 5.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 25 5.3. How to encrypt and decrypt for AEAD Algorithms . . . . . 25 5.4. How to encrypt and decrypt for AE Algorithms . . . . . . 28 6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. MACed Message with Recipients . . . . . . . . . . . . . . 30 6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 31 6.3. How to compute and verify a MAC . . . . . . . . . . . . . 31 7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 33 8. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 36 8.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1.1. Security Considerations . . . . . . . . . . . . . . . 39 8.2. Edwards-curve Digital Signature Algorithms (EdDSA) . . . 40 Schaad Expires May 26, 2017 [Page 2] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 8.2.1. Security Considerations . . . . . . . . . . . . . . . 41 9. Message Authentication (MAC) Algorithms . . . . . . . . . . . 41 9.1. Hash-based Message Authentication Codes (HMAC) . . . . . 41 9.1.1. Security Considerations . . . . . . . . . . . . . . . 43 9.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 43 9.2.1. Security Considerations . . . . . . . . . . . . . . . 44 10. Content Encryption Algorithms . . . . . . . . . . . . . . . . 45 10.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . 45 10.1.1. Security Considerations . . . . . . . . . . . . . . 46 10.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . 47 10.2.1. Security Considerations . . . . . . . . . . . . . . 50 10.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . 50 10.3.1. Security Considerations . . . . . . . . . . . . . . 51 11. Key Derivation Functions (KDF) . . . . . . . . . . . . . . . 51 11.1. HMAC-based Extract-and-Expand Key Derivation Function (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 52 11.2. Context Information Structure . . . . . . . . . . . . . 54 12. Content Key Distribution Methods . . . . . . . . . . . . . . 59 12.1. Direct Encryption . . . . . . . . . . . . . . . . . . . 59 12.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 60 12.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . 60 12.2. Key Wrapping . . . . . . . . . . . . . . . . . . . . . . 62 12.2.1. AES Key Wrapping . . . . . . . . . . . . . . . . . . 63 12.3. Key Transport . . . . . . . . . . . . . . . . . . . . . 64 12.4. Direct Key Agreement . . . . . . . . . . . . . . . . . . 64 12.4.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 65 12.4.2. Security Considerations . . . . . . . . . . . . . . 69 12.5. Key Agreement with Key Wrap . . . . . . . . . . . . . . 69 12.5.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 69 13. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 71 13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 72 13.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 72 13.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 73 13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 74 14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 75 15. Application Profiling Considerations . . . . . . . . . . . . 75 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 16.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 77 16.2. COSE Header Parameters Registry . . . . . . . . . . . . 77 16.3. COSE Header Algorithm Parameters Registry . . . . . . . 78 16.4. COSE Algorithms Registry . . . . . . . . . . . . . . . . 78 16.5. COSE Key Common Parameters Registry . . . . . . . . . . 79 16.6. COSE Key Type Parameters Registry . . . . . . . . . . . 80 16.7. COSE Key Type Registry . . . . . . . . . . . . . . . . . 81 16.8. COSE Elliptic Curve Parameters Registry . . . . . . . . 81 16.9. Media Type Registrations . . . . . . . . . . . . . . . . 82 16.9.1. COSE Security Message . . . . . . . . . . . . . . . 82 16.9.2. COSE Key media type . . . . . . . . . . . . . . . . 83 Schaad Expires May 26, 2017 [Page 3] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 16.10. CoAP Content-Format Registrations . . . . . . . . . . . 85 16.11. Expert Review Instructions . . . . . . . . . . . . . . . 86 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 87 17.1. Author's Versions . . . . . . . . . . . . . . . . . . . 88 17.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 88 18. Security Considerations . . . . . . . . . . . . . . . . . . . 89 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 19.1. Normative References . . . . . . . . . . . . . . . . . . 91 19.2. Informative References . . . . . . . . . . . . . . . . . 92 Appendix A. Guidelines for External Data Authentication of Algorithms . . . . . . . . . . . . . . . . . . . . . 95 A.1. Algorithm Identification . . . . . . . . . . . . . . . . 95 A.2. Counter Signature Without Headers . . . . . . . . . . . . 98 Appendix B. Two Layers of Recipient Information . . . . . . . . 99 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 101 C.1. Examples of Signed Message . . . . . . . . . . . . . . . 102 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 102 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 103 C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 104 C.1.4. Signature w/ Criticality . . . . . . . . . . . . . . 105 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 106 C.2.1. Single ECDSA signature . . . . . . . . . . . . . . . 106 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 107 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 107 C.3.2. Direct plus Key Derivation . . . . . . . . . . . . . 108 C.3.3. Counter Signature on Encrypted Content . . . . . . . 109 C.3.4. Encrypted Content with External Data . . . . . . . . 111 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 111 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 111 C.4.2. Encrypted Message w/ a Partial IV . . . . . . . . . . 112 C.5. Examples of MACed messages . . . . . . . . . . . . . . . 112 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 112 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 113 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 114 C.5.4. Multi-recipient MACed message . . . . . . . . . . . . 115 C.6. Examples of MAC0 messages . . . . . . . . . . . . . . . . 116 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 116 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 117 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 117 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 118 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121 1. Introduction There has been an increased focus on small, constrained devices that make up the Internet of Things (IoT). One of the standards that has come out of this process is the Concise Binary Object Representation Schaad Expires May 26, 2017 [Page 4] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 (CBOR) [RFC7049]. CBOR extended the data model of the JavaScript Object Notation (JSON) [RFC7159] by allowing for binary data, among other changes. CBOR is being adopted by several of the IETF working groups dealing with the IoT world as their encoding of data structures. CBOR was designed specifically to be both small in terms of messages transport and implementation size, as well having a schema free decoder. A need exists to provide message security services for IoT, and using CBOR as the message encoding format makes sense. The JOSE working group produced a set of documents [RFC7515][RFC7516][RFC7517][RFC7518] using JSON that specified how to process encryption, signatures and Message Authentication Code (MAC) operations, and how to encode keys using JSON. This document defines the CBOR Object Encryption and Signing (COSE) standard which does the same thing for the CBOR encoding format. While there is a strong attempt to keep the flavor of the original JOSE documents, two considerations are taken into account: o CBOR has capabilities that are not present in JSON and are appropriate to use. One example of this is the fact that CBOR has a method of encoding binary directly without first converting it into a base64 encoded string. o COSE is not a direct copy of the JOSE specification. In the process of creating COSE, decisions that were made for JOSE were re-examined. In many cases different results were decided on as the criteria was not always the same. 1.1. Design changes from JOSE o Define a single top message structure so that encrypted, signed and MACed messages can easily be identified and still have a consistent view. o Signed messages distinguish between the protected and unprotected parameters that relate to the content from those that relate to the signature. o MACed messages are separated from signed messages. o MACed messages have the ability to use the same set of recipient algorithms as enveloped messages for obtaining the MAC authentication key. o Use binary encodings for binary data rather than base64url encodings. Schaad Expires May 26, 2017 [Page 5] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Combine the authentication tag for encryption algorithms with the cipher text. o The set of cryptographic algorithms has been expanded in some directions, and trimmed in others. 1.2. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When the words appear in lower case, their natural language meaning is used. 1.3. CBOR Grammar There is currently no standard CBOR grammar available for use by specifications. The CBOR structures are therefore described in prose. The document was developed by first working on the grammar and then developing the prose to go with it. An artifact of this is that the prose was written using the primitive type strings defined by CBOR Data Definition Language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. In this specification, the following primitive types are used: any - non-specific value that permits all CBOR values to be placed here. bool - a boolean value (true: major type 7, value 21; false: major type 7, value 20). bstr - byte string (major type 2). int - an unsigned integer or a negative integer. nil - a null value (major type 7, value 22). nint - a negative integer (major type 1). tstr - a UTF-8 text string (major type 3). uint - an unsigned integer (major type 0). Two syntaxes from CDDL appear in this document as shorthand. These are: Schaad Expires May 26, 2017 [Page 6] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 FOO / BAR - indicates that either FOO or BAR can appear here [+ FOO] - indicates that the type FOO appears one or more times in an array As well as the prose description, a version of a CBOR grammar is presented in CDDL. Since CDDL has not been published as an RFC, this grammar may not work with the final version of CDDL. The CDDL grammar is informational, the prose description is normative. The collected CDDL can be extracted from the XML version of this document via the following XPath expression below. (Depending on the XPath evaluator one is using, it may be necessary to deal with > as an entity.) //artwork[@type='CDDL']/text() CDDL expects the initial non-terminal symbol to be the first symbol in the file. For this reason the first fragment of CDDL is presented here. start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types ; This is defined to make the tool quieter: Internal_Types = Sig_structure / Enc_structure / MAC_structure / COSE_KDF_Context The non-terminal Internal_Types is defined for dealing with the automated validation tools used during the writing of this document. It references those non-terminals that are used for security computations, but are not emitted for transport. 1.4. CBOR Related Terminology In JSON, maps are called objects and only have one kind of map key: a string. In COSE, we use strings, negative integers and unsigned integers as map keys. The integers are used for compactness of encoding and easy comparison. The inclusion of strings allows for an additional range of short encoded values to be used as well. Since the word "key" is mainly used in its other meaning, as a cryptographic key, we use the term "label" for this usage as a map key. The presence of a label in a COSE map which is not a string or an integer is an error. Applications can either fail processing or process messages with incorrect labels, however they MUST NOT create messages with incorrect labels. Schaad Expires May 26, 2017 [Page 7] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 A CDDL grammar fragment is defined that defines the non-terminals 'label', as in the previous paragraph and 'values', which permits any value to be used. label = int / tstr values = any 1.5. Document Terminology In this document, we use the following terminology: Byte is a synonym for octet. Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use in constrained systems. It is defined in [RFC7252]. Authenticated Encryption (AE) [RFC5116] algorithms are those encryption algorithms which provide an authentication check of the contents algorithm with the encryption service. Authenticated Encryption with Authenticated Data (AEAD) [RFC5116] algorithms provide the same content authentication service as AE algorithms, but additionally provide for authentication of non- encrypted data as well. 2. Basic COSE Structure The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different types of security messages. All of the message structures are built on the CBOR array type. The first three elements of the array always contain the same information: 1. The set of protected header parameters wrapped in a bstr. 2. The set of unprotected header parameters as a map. 3. The content of the message. The content is either the plain text or the cipher text as appropriate. The content may be detached, but the location is still used. The content is wrapped in a bstr when present and is a nil value when detached. Elements after this point are dependent on the specific message type. COSE messages are also built using the concept of layers to separate different types of cryptographic concepts. As an example of how this works, consider the COSE_Encrypt message (Section 5.1). This message type is broken into two layers: the content layer and the recipient Schaad Expires May 26, 2017 [Page 8] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 layer. In the content layer, the plain text is encrypted and information about the encrypted message are placed. In the recipient layer, the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient is placed. A single layer version of the encryption message COSE_Encrypt0 (Section 5.2) is provided for cases where the CEK is pre-shared. Identification of which type of message has been presented is done by the following methods: 1. The specific message type is known from the context. This may be defined by a marker in the containing structure or by restrictions specified by the application protocol. 2. The message type is identified by a CBOR tag. Messages with a CBOR tag are known in this specification as tagged messages, while those without the CBOR tag are known as untagged messages. This document defines a CBOR tag for each of the message structures. These tags can be found in Table 1. 3. When a COSE object is carried in a media type of application/ cose, the optional parameter 'cose-type' can be used to identify the embedded object. The parameter is OPTIONAL if the tagged version of the structure is used. The parameter is REQUIRED if the untagged version of the structure is used. The value to use with the parameter for each of the structures can be found in Table 1. 4. When a COSE object is carried as a CoAP payload, the CoAP Content-Format Option can be used to identify the message content. The CoAP Content-Format values can be found in Table 26. The CBOR tag for the message structure is not required as each security message is uniquely identified. Schaad Expires May 26, 2017 [Page 9] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +-------+---------------+---------------+---------------------------+ | CBOR | cose-type | Data Item | Semantics | | Tag | | | | +-------+---------------+---------------+---------------------------+ | 98 | cose-sign | COSE_Sign | COSE Signed Data Object | | | | | | | 18 | cose-sign1 | COSE_Sign1 | COSE Single Signer Data | | | | | Object | | | | | | | 96 | cose-encrypt | COSE_Encrypt | COSE Encrypted Data | | | | | Object | | | | | | | 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Single Recipient | | | | | Encrypted Data Object | | | | | | | 97 | cose-mac | COSE_Mac | COSE Mac-ed Data Object | | | | | | | 17 | cose-mac0 | COSE_Mac0 | COSE Mac w/o Recipients | | | | | Object | +-------+---------------+---------------+---------------------------+ Table 1: COSE Message Identification The following CDDL fragment identifies all of the top messages defined in this document. Separate non-terminals are defined for the tagged and the untagged versions of the messages. COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message COSE_Untagged_Message = COSE_Sign / COSE_Sign1 / COSE_Encrypt / COSE_Encrypt0 / COSE_Mac / COSE_Mac0 COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged / COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged / COSE_Mac_Tagged / COSE_Mac0_Tagged 3. Header Parameters The structure of COSE has been designed to have two buckets of information that are not considered to be part of the payload itself, but are used for holding information about content, algorithms, keys, or evaluation hints for the processing of the layer. These two buckets are available for use in all of the structures except for keys. While these buckets are present, they may not all be usable in all instances. For example, while the protected bucket is defined as part of the recipient structure, some of the algorithms used for Schaad Expires May 26, 2017 [Page 10] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 recipient structures do not provide for authenticated data. If this is the case, the protected bucket is left empty. Both buckets are implemented as CBOR maps. The map key is a 'label' (Section 1.4). The value portion is dependent on the definition for the label. Both maps use the same set of label/value pairs. The integer and string values for labels have been divided into several sections with a standard range, a private range, and a range that is dependent on the algorithm selected. The defined labels can be found in the "COSE Header Parameters" IANA registry (Section 16.2). Two buckets are provided for each layer: protected: Contains parameters about the current layer that are to be cryptographically protected. This bucket MUST be empty if it is not going to be included in a cryptographic computation. This bucket is encoded in the message as a binary object. This value is obtained by CBOR encoding the protected map and wrapping it in a bstr object. Senders SHOULD encode a zero length map as a zero length string rather than as a zero length map (encoded as h'a0'). The zero length binary encoding is preferred because it is both shorter and the version used in the serialization structures for cryptographic computation. After encoding the map, the value is wrapped in the binary object. Recipients MUST accept both a zero length binary value and a zero length map encoded in the binary value. The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit. (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding. unprotected: Contains parameters about the current layer that are not cryptographically protected. Only parameters that deal with the current layer are to be placed at that layer. As an example of this, the parameter 'content type' describes the content of the message being carried in the message. As such, this parameter is placed only in the content layer and is not placed in the recipient or signature layers. In principle, one should be able to process any given layer without reference to any other layer. With the exception of the COSE_Sign structure, the only data that needs to cross layers is the cryptographic key. The buckets are present in all of the security objects defined in this document. The fields in order are the 'protected' bucket (as a CBOR 'bstr' type) and then the 'unprotected' bucket (as a CBOR 'map' Schaad Expires May 26, 2017 [Page 11] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 type). The presence of both buckets is required. The parameters that go into the buckets come from the IANA "COSE Header Parameters" registry (Section 16.2). Some common parameters are defined in the next section, but a number of parameters are defined throughout this document. Labels in each of the maps MUST be unique. When processing messages, if a label appears multiple times, the message MUST be rejected as malformed. Applications SHOULD verify that the same label does not occur in both the protected and unprotected headers. If the message is not rejected as malformed, attributes MUST be obtained from the protected bucket before they are obtained from the unprotected bucket. The following CDDL fragment represents the two header buckets. A group Headers is defined in CDDL that represents the two buckets in which attributes are placed. This group is used to provide these two fields consistently in all locations. A type is also defined which represents the map of common headers. Headers = ( protected : empty_or_serialized_map, unprotected : header_map ) header_map = { Generic_Headers, * label => values } empty_or_serialized_map = bstr .cbor header_map / bstr .size 0 3.1. Common COSE Headers Parameters This section defines a set of common header parameters. A summary of these parameters can be found in Table 2. This table should be consulted to determine the value of label, and the type of the value. The set of header parameters defined in this section are: alg: This parameter is used to indicate the algorithm used for the security processing. This parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (COSE_Sign, COSE_Sign0, COSE_Mac and COSE_Mac0). This authentication can be done either by placing the header in the protected header bucket or as part of the externally Schaad Expires May 26, 2017 [Page 12] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 supplied data. The value is taken from the "COSE Algorithms" Registry (see Section 16.4). crit: The parameter is used to indicate which protected header labels an application that is processing a message is required to understand. Parameters defined in this document do not need to be included as they should be understood by all implementations. When present, this parameter MUST be placed in the protected header bucket. The array MUST have at least one value in it. Not all labels need to be included in the 'crit' parameter. The rules for deciding which header labels are placed in the array are: * Integer labels in the range of 0 to 8 SHOULD be omitted. * Integer labels in the range -1 to -128 can be omitted as they are algorithm dependent. If an application can correctly process an algorithm, it can be assumed that it will correctly process all of the common parameters associated with that algorithm. Integer labels in the range -129 to -65536 SHOULD be included as these would be less common parameters that might not be generally supported. * Labels for parameters required for an application MAY be omitted. Applications should have a statement if the label can be omitted. The header parameter values indicated by 'crit' can be processed by either the security library code or by an application using a security library; the only requirement is that the parameter is processed. If the 'crit' value list includes a value for which the parameter is not in the protected bucket, this is a fatal error in processing the message. content type: This parameter is used to indicate the content type of the data in the payload or cipher text fields. Integers are from the "CoAP Content-Formats" IANA registry table [COAP.Formats]. Text values following the syntax of "/" where and are defined in Section 4.2 of [RFC6838]. Leading and trailing whitespace is also omitted. Textual content values along with parameters and subparameters can be located using the IANA "Media Types" registry. Applications SHOULD provide this parameter if the content structure is potentially ambiguous. kid: This parameter identifies one piece of data that can be used as input to find the needed cryptographic key. The value of this parameter can be matched against the 'kid' member in a COSE_Key Schaad Expires May 26, 2017 [Page 13] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 structure. Other methods of key distribution can define an equivalent field to be matched. Applications MUST NOT assume that 'kid' values are unique. There may be more than one key with the same 'kid' value, so all of the keys associated with this 'kid' may need to be checked. The internal structure of 'kid' values is not defined and cannot be relied on by applications. Key identifier values are hints about which key to use. This is not a security critical field. For this reason, it can be placed in the unprotected headers bucket. IV: This parameter holds the Initialization Vector (IV) value. For some symmetric encryption algorithms this may be referred to as a nonce. The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled. Partial IV This parameter holds a part of the IV value. When using the COSE_Encrypt0 structure, a portion of the IV can be part of the context associated with the key. This field is used to carry a value that causes the IV to be changed for each message. The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled. The 'Initialization Vector' and 'Partial Initialization Vector' parameters MUST NOT both be present in the same security layer. The message IV is generated by the following steps: 1. Left pad the partial IV with zeros to the length of IV. 2. XOR the padded partial IV with the context IV. counter signature: This parameter holds one or more counter signature values. Counter signatures provide a method of having a second party sign some data. The counter signature parameter can occur as an unprotected attribute in any of the following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac and COSE_Mac0. These structures all have the same beginning elements so that a consistent calculation of the counter signature can be computed. Details on computing counter signatures are found in Section 4.5. Schaad Expires May 26, 2017 [Page 14] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +-----------+-------+----------------+-------------+----------------+ | name | label | value type | value | description | | | | | registry | | +-----------+-------+----------------+-------------+----------------+ | alg | 1 | int / tstr | COSE | Cryptographic | | | | | Algorithms | algorithm to | | | | | registry | use | | | | | | | | crit | 2 | [+ label] | COSE Header | Critical | | | | | Labels | headers to be | | | | | registry | understood | | | | | | | | content | 3 | tstr / uint | CoAP | Content type | | type | | | Content- | of the payload | | | | | Formats or | | | | | | Media Types | | | | | | registry | | | | | | | | | kid | 4 | bstr | | Key identifier | | | | | | | | IV | 5 | bstr | | Full | | | | | | Initialization | | | | | | Vector | | | | | | | | Partial | 6 | bstr | | Partial | | IV | | | | Initialization | | | | | | Vector | | | | | | | | counter | 7 | COSE_Signature | | CBOR encoded | | signature | | / [+ | | signature | | | | COSE_Signature | | structure | | | | ] | | | +-----------+-------+----------------+-------------+----------------+ Table 2: Common Header Parameters The CDDL fragment that represents the set of headers defined in this section is given below. Each of the headers is tagged as optional because they do not need to be in every map; headers required in specific maps are discussed above. Schaad Expires May 26, 2017 [Page 15] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Generic_Headers = ( ? 1 => int / tstr, ; algorithm identifier ? 2 => [+label], ; criticality ? 3 => tstr / int, ; content type ? 4 => bstr, ; key identifier ? 5 => bstr, ; IV ? 6 => bstr, ; Partial IV ? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature ) 4. Signing Objects COSE supports two different signature structures. COSE_Sign allows for one or more signatures to be applied to the same content. COSE_Sign1 is restricted to a single signer. The structures cannot be converted between each other; as the signature computation includes a parameter identifying which structure is being used, the converted structure will fail signature validation. 4.1. Signing with One or More Signers The COSE_Sign structure allows for one or more signatures to be applied to a message payload. Parameters relating to the content and parameters relating to the signature are carried along with the signature itself. These parameters may be authenticated by the signature, or just present. An example of a parameter about the content is the content type. Examples of parameters about the signature would be the algorithm and key used to create the signature and counter signatures. When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a successful signature by that signer. However, there are some application environments where other rules are needed. An application that employs a rule other than one valid signature for each signer must specify those rules. Also, where simple matching of the signer identifier is not sufficient to determine whether the signatures were generated by the same signer, the application specification must describe how to determine which signatures were generated by the same signer. Support for different communities of recipients is the primary reason that signers choose to include more than one signature. For example, the COSE_Sign structure might include signatures generated with the Edwards Digital Signature Algorithm (EdDSA) [I-D.irtf-cfrg-eddsa] signature algorithm and with the Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] signature algorithm. This allows recipients to verify the signature associated with one algorithm or the other. (The original source of Schaad Expires May 26, 2017 [Page 16] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 this text is [RFC5652].) More detailed information on multiple signature evaluation can be found in [RFC5752]. The signature structure can be encoded either as tagged or untagged depending on the context it will be used in. A tagged COSE_Sign structure is identified by the CBOR tag TBD1. The CDDL fragment that represents this is: COSE_Sign_Tagged = #6.98(COSE_Sign) A COSE Signed Message is defined in two parts. The CBOR object that carries the body and information about the body is called the COSE_Sign structure. The CBOR object that carries the signature and information about the signature is called the COSE_Signature structure. Examples of COSE Signed Messages can be found in Appendix C.1. The COSE_Sign structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. payload contains the serialized content to be signed. If the payload is not present in the message, the application is required to supply the payload separately. The payload is wrapped in a bstr to ensure that it is transported without changes. If the payload is transported separately ("detached content"), then a nil CBOR object is placed in this location and it is the responsibility of the application to ensure that it will be transported without changes. Note: When a signature with message recovery algorithm is used (Section 8), the maximum number of bytes that can be recovered is the length of the payload. The size of the payload is reduced by the number of bytes that will be recovered. If all of the bytes of the payload are consumed, then the payload is encoded as a zero length binary string rather than as being absent. signatures is an array of signatures. Each signature is represented as a COSE_Signature structure. The CDDL fragment that represents the above text for COSE_Sign follows. Schaad Expires May 26, 2017 [Page 17] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 COSE_Sign = [ Headers, payload : bstr / nil, signatures : [+ COSE_Signature] ] The COSE_Signature structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. signature contains the computed signature value. The type of the field is a bstr. Algorithms MUST specify padding if the signature value is not a multiple of 8 bits. The CDDL fragment that represents the above text for COSE_Signature follows. COSE_Signature = [ Headers, signature : bstr ] ! 4.2. Signing with One Signer The COSE_Sign1 signature structure is used when only one signature is going to be placed on a message. The parameters dealing with the content and the signature are placed in the same pair of buckets rather than having the separation of COSE_Sign. The structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Sign1 structure is identified by the CBOR tag TBD7. The CDDL fragment that represents this is: COSE_Sign1_Tagged = #6.18(COSE_Sign1) The CBOR object that carries the body, the signature, and the information about the body and signature is called the COSE_Sign1 structure. Examples of COSE_Sign1 messages can be found in Appendix C.2. The COSE_Sign1 structure is a CBOR array. The fields of the array in order are: Schaad Expires May 26, 2017 [Page 18] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 protected as described in Section 3. unprotected as described in Section 3. payload as described in Section 4.1. signature contains the computed signature value. The type of the field is a bstr. The CDDL fragment that represents the above text for COSE_Sign1 follows. COSE_Sign1 = [ Headers, payload : bstr / nil, signature : bstr ] 4.3. Externally Supplied Data One of the features offered in the COSE document is the ability for applications to provide additional data to be authenticated, but that is not carried as part of the COSE object. The primary reason for supporting this can be seen by looking at the CoAP message structure [RFC7252], where the facility exists for options to be carried before the payload. Examples of data that can be placed in this location would be the CoAP code or CoAP options. If the data is in the header section, then it is available for proxies to help in performing its operations. For example, the Accept Option can be used by a proxy to determine if an appropriate value is in the Proxy's cache. But the sender can prevent a proxy from changing the set of values that it will accept by including that value in the resulting authentication tag. However, it may also be desired to protect these values so that if they are modified in transit, it can be detected. This document describes the process for using a byte array of externally supplied authenticated data; however, the method of constructing the byte array is a function of the application. Applications that use this feature need to define how the externally supplied authenticated data is to be constructed. Such a construction needs to take into account the following issues: o If multiple items are included, applications need to ensure that the same byte string is not produced if there are different inputs. This could occur by appending the strings 'AB' and 'CDE' or by appending the strings 'ABC' and 'DE'. This is usually addressed by making fields a fixed width and/or encoding the length of the field as part of the output. Using options from Schaad Expires May 26, 2017 [Page 19] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 CoAP [RFC7252] as an example, these fields use a TLV structure so they can be concatenated without any problems. o If multiple items are included, an order for the items needs to be defined. Using options from CoAP as an example, an application could state that the fields are to be ordered by the option number. o Applications need to ensure that the byte stream is going to be the same on both sides. Using options from CoAP might give a problem if the same relative numbering is kept. An intermediate node could insert or remove an option, changing how the relative number is done. An application would need to specify that the relative number must be re-encoded to be relative only to the options that are in the external data. 4.4. Signing and Verification Process In order to create a signature, a well-defined byte stream is needed. The Sig_struture is used to create the canonical form. This signing and verification process takes in the body information (COSE_Sign or COSE_Sign1), the signer information (COSE_Signature), and the application data (external source). A Sig_structure is a CBOR array. The fields of the Sig_struture in order are: 1. A text string identifying the context of the signature. The context string is: "Signature" for signatures using the COSE_Signature structure. "Signature1" for signatures using the COSE_Sign1 structure. "CounterSignature" for signatures used as counter signature attributes. 2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. 3. The protected attributes from the signer structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. This field is omitted for the COSE_Sign1 signature structure. 4. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero length binary string. (See Section 4.3 for application guidance on constructing this field.) Schaad Expires May 26, 2017 [Page 20] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 5. The payload to be signed encoded in a bstr type. The payload is placed here independent of how it is transported. The CDDL fragment that describes the above text is. Sig_structure = [ context : "Signature" / "Signature1" / "CounterSignature", body_protected : empty_or_serialized_map, ? sign_protected : empty_or_serialized_map, external_aad : bstr, payload : bstr ] How to compute a signature: 1. Create a Sig_structure and populate it with the appropriate fields. 2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14. 3. Call the signature creation algorithm passing in K (the key to sign with), alg (the algorithm to sign with), and ToBeSigned (the value to sign). 4. Place the resulting signature value in the 'signature' field of the array. The steps for verifying a signature are: 1. Create a Sig_structure object and populate it with the appropriate fields. 2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14. 3. Call the signature verification algorithm passing in K (the key to verify with), alg (the algorithm used sign with), ToBeSigned (the value to sign), and sig (the signature to be verified). In addition to performing the signature verification, the application may also perform the appropriate checks to ensure that the key is correctly paired with the signing identity and that the signing identity is authorized before performing actions. Schaad Expires May 26, 2017 [Page 21] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 4.5. Computing Counter Signatures Counter signatures provide a method of associating different signature generated by different signers with some piece of content. This is normally used to provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a Timestamp). In this document, we allow for counter signatures to exist in a greater number of environments. As an example, it is possible to place a counter signature in the unprotected attributes of a COSE_Encrypt object. This would allow for an intermediary to either verify that the encrypted byte stream has not been modified, without being able to decrypt it, or for the intermediary to assert that an encrypted byte stream either existed at a given time or passed through it in terms of routing (i.e., a proxy signature). An example of a counter signature on a signature can be found in Appendix C.1.3. An example of a counter signature in an encryption object can be found in Appendix C.3.3. The creation and validation of counter signatures over the different items relies on the fact that the structure of the objects have the same structure. The elements are a set of protected attributes, a set of unprotected attributes, and a body, in that order. This means that the Sig_structure can be used in a uniform manner to get the byte stream for processing a signature. If the counter signature is going to be computed over a COSE_Encrypt structure, the body_protected and payload items can be mapped into the Sig_structure in the same manner as from the COSE_Sign structure. It should be noted that only a signature algorithm with appendix (see Section 8) can be used for counter signatures. This is because the body should be able to be processed without having to evaluate the counter signature, and this is not possible for signature schemes with message recovery. 5. Encryption Objects COSE supports two different encryption structures. COSE_Encrypt0 is used when a recipient structure is not needed because the key to be used is known implicitly. COSE_Encrypt is used the rest of the time. This includes cases where there are multiple recipients or a recipient algorithm other than direct is used. 5.1. Enveloped COSE Structure The enveloped structure allows for one or more recipients of a message. There are provisions for parameters about the content and parameters about the recipient information to be carried in the Schaad Expires May 26, 2017 [Page 22] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 message. The protected parameters associated with the content are authenticated by the content encryption algorithm. The protected parameters associated with the recipient are authenticated by the recipient algorithm (when the algorithm supports it). Examples of parameters about the content are the type of the content and the content encryption algorithm. Examples of parameters about the recipient are the recipient's key identifier and the recipient's encryption algorithm. The same techniques and structures are used for encrypting both the plain text and the keys. This is different from the approach used by both CMS [RFC5652] and JSON Web Encryption (JWE) [RFC7516] where different structures are used for the content layer and for the recipient layer. Two structures are defined: COSE_Encrypt to hold the encrypted content and COSE_recipient to hold the encrypted keys for recipients. Examples of encrypted messages can be found in Appendix C.3. The COSE_Encrypt structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Encrypt structure is identified by the CBOR tag TBD2. The CDDL fragment that represents this is: COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) The COSE_Encrypt structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. ' ciphertext contains the cipher text encoded as a bstr. If the cipher text is to be transported independently of the control information about the encryption process (i.e., detached content) then the field is encoded as a nil value. recipients contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient. The CDDL fragment that corresponds to the above text is: COSE_Encrypt = [ Headers, ciphertext : bstr / nil, recipients : [+COSE_recipient] ] Schaad Expires May 26, 2017 [Page 23] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 The COSE_recipient structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. ciphertext contains the encrypted key encoded as a bstr. All encoded keys are symetric keys, the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value. recipients contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient. (An example of this can be found in Appendix B.) If there are no recipient information structures, this element is absent. The CDDL fragment that corresponds to the above text for COSE_recipient is: COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ] 5.1.1. Content Key Distribution Methods An encrypted message consists of an encrypted content and an encrypted CEK for one or more recipients. The CEK is encrypted for each recipient, using a key specific to that recipient. The details of this encryption depend on which class the recipient algorithm falls into. Specific details on each of the classes can be found in Section 12. A short summary of the five content key distribution methods is: direct: The CEK is the same as the identified previously distributed symmetric key or derived from a previously distributed secret. No CEK is transported in the message. symmetric key-encryption keys: The CEK is encrypted using a previously distributed symmetric KEK. key agreement: The recipient's public key and a sender's private key are used to generate a pairwise secret, a KDF is applied to derive a key, and then the CEK is either the derived key or encrypted by the derived key. Schaad Expires May 26, 2017 [Page 24] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 key transport: The CEK is encrypted with the recipient's public key. No key transport algorithms are defined in this document. passwords: The CEK is encrypted in a KEK that is derived from a password. No password algorithms are defined in this document. 5.2. Single Recipient Encrypted The COSE_Encrypt0 encrypted structure does not have the ability to specify recipients of the message. The structure assumes that the recipient of the object will already know the identity of the key to be used in order to decrypt the message. If a key needs to be identified to the recipient, the enveloped structure ought to be used. Examples of encrypted messages can be found in Appendix C.3. The COSE_Encrypt0 structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Encrypt0 structure is identified by the CBOR tag TBD3. The CDDL fragment that represents this is: COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0) The COSE_Encrypt0 structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. ciphertext as described in Section 5.1. The CDDL fragment for COSE_Encrypt0 that corresponds to the above text is: COSE_Encrypt0 = [ Headers, ciphertext : bstr / nil, ] 5.3. How to encrypt and decrypt for AEAD Algorithms The encryption algorithm for AEAD algorithms is fairly simple. The first step is to create a consistent byte stream for the authenticated data structure. For this purpose, we use an Enc_structure. The Enc_structure is a CBOR array. The fields of the Enc_structure in order are: Schaad Expires May 26, 2017 [Page 25] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 1. A text string identifying the context of the authenticated data structure. The context string is: "Encrypt0" for the content encryption of a COSE_Encrypt0 data structure. "Encrypt" for the first layer of a COSE_Encrypt data structure (i.e., for content encryption). "Enc_Recipient" for a recipient encoding to be placed in an COSE_Encrypt data structure. "Mac_Recipient" for a recipient encoding to be placed in a MACed message structure. "Rec_Recipient" for a recipient encoding to be placed in a recipient structure. 2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. 3. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero length bstr. (See Section 4.3 for application guidance on constructing this field.) The CDDL fragment that describes the above text is: Enc_structure = [ context : "Encrypt" / "Encrypt0" / "Enc_Recipient" / "Mac_Recipient" / "Rec_Recipient", protected : empty_or_serialized_map, external_aad : bstr ] How to encrypt a message: 1. Create an Enc_structure and populate it with the appropriate fields. 2. Encode the Enc_structure to a byte stream (AAD), using the encoding described in Section 14. 3. Determine the encryption key (K). This step is dependent on the class of recipient algorithm being used. For: Schaad Expires May 26, 2017 [Page 26] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Other: The key is randomly or pseudo-randomly generated. 4. Call the encryption algorithm with K (the encryption key), P (the plain text) and AAD. Place the returned cipher text into the 'ciphertext' field of the structure. 5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plain text. How to decrypt a message: 1. Create a Enc_structure and populate it with the appropriate fields. 2. Encode the Enc_structure to a byte stream (AAD), using the encoding described in Section 14. 3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For: No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Schaad Expires May 26, 2017 [Page 27] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Other: The key is determined by decoding and decrypting one of the recipient structures. 4. Call the decryption algorithm with K (the decryption key to use), C (the cipher text) and AAD. 5.4. How to encrypt and decrypt for AE Algorithms How to encrypt a message: 1. Verify that the 'protected' field is empty. 2. Verify that there was no external additional authenticated data supplied for this operation. 3. Determine the encryption key. This step is dependent on the class of recipient algorithm being used. For: No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Other: The key is randomly generated. 4. Call the encryption algorithm with K (the encryption key to use) and the P (the plain text). Place the returned cipher text into the 'ciphertext' field of the structure. 5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plain text. How to decrypt a message: 1. Verify that the 'protected' field is empty. 2. Verify that there was no external additional authenticated data supplied for this operation. Schaad Expires May 26, 2017 [Page 28] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For: No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Other: The key is determined by decoding and decrypting one of the recipient structures. 4. Call the decryption algorithm with K (the decryption key to use), and C (the cipher text). 6. MAC Objects COSE supports two different MAC structures. COSE_MAC0 is used when a recipient structure is not needed because the key to be used is implicitly known. COSE_MAC is used for all other cases. These include a requirement for multiple recipients, the key being unknown, and a recipient algorithm of other than direct. In this section, we describe the structure and methods to be used when doing MAC authentication in COSE. This document allows for the use of all of the same classes of recipient algorithms as are allowed for encryption. When using MAC operations, there are two modes in which they can be used. The first is just a check that the content has not been changed since the MAC was computed. Any class of recipient algorithm can be used for this purpose. The second mode is to both check that the content has not been changed since the MAC was computed, and to use the recipient algorithm to verify who sent it. The classes of recipient algorithms that support this are those that use a pre- shared secret or do static-static key agreement (without the key wrap step). In both of these cases, the entity that created and sent the message MAC can be validated. (This knowledge of sender assumes that there are only two parties involved and you did not send the message to yourself.) The origination property can be obtained with both of the MAC message structures. Schaad Expires May 26, 2017 [Page 29] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 6.1. MACed Message with Recipients The multiple recipient MACed message uses two structures, the COSE_Mac structure defined in this section for carrying the body and the COSE_recipient structure (Section 5.1) to hold the key used for the MAC computation. Examples of MACed messages can be found in Appendix C.5. The MAC structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac structure is identified by the CBOR tag TBD4. The CDDL fragment that represents this is: COSE_Mac_Tagged = #6.97(COSE_Mac) The COSE_Mac structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. payload contains the serialized content to be MACed. If the payload is not present in the message, the application is required to supply the payload separately. The payload is wrapped in a bstr to ensure that it is transported without changes. If the payload is transported separately (i.e., detached content), then a nil CBOR value is placed in this location and it is the responsibility of the application to ensure that it will be transported without changes. tag contains the MAC value. recipients as described in Section 5.1. The CDDL fragment that represents the above text for COSE_Mac follows. COSE_Mac = [ Headers, payload : bstr / nil, tag : bstr, recipients :[+COSE_recipient] ] Schaad Expires May 26, 2017 [Page 30] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 6.2. MACed Messages with Implicit Key In this section, we describe the structure and methods to be used when doing MAC authentication for those cases where the recipient is implicitly known. The MACed message uses the COSE_Mac0 structure defined in this section for carrying the body. Examples of MACed messages with an implicit key can be found in Appendix C.6. The MAC structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac0 structure is identified by the CBOR tag TBD6. The CDDL fragment that represents this is: COSE_Mac0_Tagged = #6.17(COSE_Mac0) The COSE_Mac0 structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. payload as described in Section 6.1. tag contains the MAC value. The CDDL fragment that corresponds to the above text is: COSE_Mac0 = [ Headers, payload : bstr / nil, tag : bstr, ] 6.3. How to compute and verify a MAC In order to get a consistent encoding of the data to be authenticated, the MAC_structure is used to have a canonical form. The MAC_structure is a CBOR array. The fields of the MAC_structure in order are: 1. A text string that identifies the structure that is being encoded. This string is "MAC" for the COSE_Mac structure. This string is "MAC0" for the COSE_Mac0 structure. Schaad Expires May 26, 2017 [Page 31] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 2. The protected attributes from the COSE_MAC structure. If there are no protected attributes, a zero length bstr is used. 3. The protected attributes from the application encoded as a bstr type. If this field is not supplied, it defaults to a zero length binary string. (See Section 4.3 for application guidance on constructing this field.) 4. The payload to be MAC-ed encoded in a bstr type. The payload is placed here independent of how it is transported. The CDDL fragment that corresponds to the above text is: MAC_structure = [ context : "MAC" / "MAC0", protected : empty_or_serialized_map, external_aad : bstr, payload : bstr ] The steps to compute a MAC are: 1. Create a MAC_structure and populate it with the appropriate fields. 2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14. 3. Call the MAC creation algorithm passing in K (the key to use), alg (the algorithm to MAC with) and ToBeMaced (the value to compute the MAC on). 4. Place the resulting MAC in the 'tag' field of the COSE_Mac or COSE_Mac0 structure. 5. Encrypt and encode the MAC key for each recipient of the message. The steps to verify a MAC are: 1. Create a MAC_structure object and populate it with the appropriate fields. 2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14. 3. Obtain the cryptographic key from one of the recipients of the message. Schaad Expires May 26, 2017 [Page 32] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 4. Call the MAC creation algorithm passing in K (the key to use), alg (the algorithm to MAC with) and ToBeMaced (the value to compute the MAC on). 5. Compare the MAC value to the 'tag' field of the COSE_Mac or COSE_Mac0 structure. 7. Key Objects A COSE Key structure is built on a CBOR map object. The set of common parameters that can appear in a COSE Key can be found in the IANA "COSE Key Common Parameters" registry (Section 16.5). Additional parameters defined for specific key types can be found in the IANA "COSE Key Type Parameters" registry (Section 16.6). A COSE Key Set uses a CBOR array object as its underlying type. The values of the array elements are COSE Keys. A Key Set MUST have at least one element in the array. Examples of Key Sets can be found in Appendix C.7. Each element in a key set MUST be processed independently. If one element in a key set is either malformed or uses a key that is not understood by an application, that key is ignored and the other keys are processed normally. The element "kty" is a required element in a COSE_Key map. The CDDL grammar describing COSE_Key and COSE_KeySet is: COSE_Key = { 1 => tstr / int, ; kty ? 2 => bstr, ; kid ? 3 => tstr / int, ; alg ? 4 => [+ (tstr / int) ], ; key_ops ? 5 => bstr, ; Base IV * label => values } COSE_KeySet = [+COSE_Key] 7.1. COSE Key Common Parameters This document defines a set of common parameters for a COSE Key object. Table 3 provides a summary of the parameters defined in this section. There are also parameters that are defined for specific key types. Key type specific parameters can be found in Section 13. Schaad Expires May 26, 2017 [Page 33] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +---------+-------+----------------+------------+-------------------+ | name | label | CBOR type | registry | description | +---------+-------+----------------+------------+-------------------+ | kty | 1 | tstr / int | COSE Key | Identification of | | | | | Common | the key type | | | | | Parameters | | | | | | | | | alg | 3 | tstr / int | COSE | Key usage | | | | | Algorithm | restriction to | | | | | Values | this algorithm | | | | | | | | kid | 2 | bstr | | Key | | | | | | Identification | | | | | | value - match to | | | | | | kid in message | | | | | | | | key_ops | 4 | [+ (tstr/int)] | | Restrict set of | | | | | | permissible | | | | | | operations | | | | | | | | Base IV | 5 | bstr | | Base IV to be | | | | | | xor-ed with | | | | | | Partial IVs | +---------+-------+----------------+------------+-------------------+ Table 3: Key Map Labels kty: This parameter is used to identify the family of keys for this structure, and thus the set of key type specific parameters to be found. The set of values defined in this document can be found in Table 21. This parameter MUST be present in a key object. Implementations MUST verify that the key type is appropriate for the algorithm being processed. The key type MUST be included as part of the trust decision process. alg: This parameter is used to restrict the algorithm that is used with the key. If this parameter is present in the key structure, the application MUST verify that this algorithm matches the algorithm for which the key is being used. If the algorithms do not match, then this key object MUST NOT be used to perform the cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified, however this is considered to be a poor security practice. kid: This parameter is used to give an identifier for a key. The identifier is not structured and can be anything from a user provided string to a value computed on the public portion of the Schaad Expires May 26, 2017 [Page 34] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 key. This field is intended for matching against a 'kid' parameter in a message in order to filter down the set of keys that need to be checked. key_ops: This parameter is defined to restrict the set of operations that a key is to be used for. The value of the field is an array of values from Table 4. Algorithms define the values of key ops that are permitted to appear and are required for specific operations. The set of values matches that in [RFC7517] and [W3C.WebCrypto]. Base IV: This parameter is defined to carry the base portion of an IV. It is designed to be used with the partial IV header parameter defined in Section 3.1. This field provides the ability to associate a partial IV with a key that is then modified on a per message basis with the partial IV. Extreme care needs to be taken when using a Base IV in an application. Many encryption algorithms lose security if the same IV is used twice. If different keys are derived for each sender, using the same base IV with partial IVs starting at zero is likely to ensure that the IV would not be used twice for a single key. If different keys are derived for each sender, starting at the same base IV is likely to satisfy this condition. If the same key is used for multiple senders, then the application needs to provide for a method of dividing the IV space up between the senders. This could be done by providing a different base point to start from or a different partial IV to start with and restricting the number of messages to be sent before re-keying. Schaad Expires May 26, 2017 [Page 35] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +---------+-------+-------------------------------------------------+ | name | value | description | +---------+-------+-------------------------------------------------+ | sign | 1 | The key is used to create signatures. Requires | | | | private key fields. | | | | | | verify | 2 | The key is used for verification of signatures. | | | | | | encrypt | 3 | The key is used for key transport encryption. | | | | | | decrypt | 4 | The key is used for key transport decryption. | | | | Requires private key fields. | | | | | | wrap | 5 | The key is used for key wrapping. | | key | | | | | | | | unwrap | 6 | The key is used for key unwrapping. Requires | | key | | private key fields. | | | | | | derive | 7 | The key is used for deriving keys. Requires | | key | | private key fields. | | | | | | derive | 8 | The key is used for deriving bits not to be | | bits | | used as a key. Requires private key fields. | | | | | | MAC | 9 | The key is used for creating MACs. | | create | | | | | | | | MAC | 10 | The key is used for validating MACs. | | verify | | | +---------+-------+-------------------------------------------------+ Table 4: Key Operation Values 8. Signature Algorithms There are two signature algorithm schemes. The first is signature with appendix. In this scheme, the message content is processed and a signature is produced, the signature is called the appendix. This is the scheme used by algorithms such as ECDSA and RSASSA-PSS. (In fact the SSA in RSASSA-PSS stands for Signature Scheme with Appendix.) The signature functions for this scheme are: signature = Sign(message content, key) valid = Verification(message content, key, signature) Schaad Expires May 26, 2017 [Page 36] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 The second scheme is signature with message recovery. (An example of such an algorithm is [PVSig].) In this scheme, the message content is processed, but part of it is included in the signature. Moving bytes of the message content into the signature allows for smaller signatures, the signature size is still potentially large, but the message content has shrunk. This has implications for systems implementing these algorithms and for applications that use them. The first is that the message content is not fully available until after a signature has been validated. Until that point the part of the message contained inside of the signature is unrecoverable. The second is that the security analysis of the strength of the signature is very much based on the structure of the message content. Messages that are highly predictable require additional randomness to be supplied as part of the signature process. In the worst case, it becomes the same as doing a signature with appendix. Finally, in the event that multiple signatures are applied to a message, all of the signature algorithms are going to be required to consume the same number of bytes of message content. This means that mixing of the different schemes in a single message is not supported, and if a recovery signature scheme is used, then the same amount of content needs to be consumed by all of the signatures. The signature functions for this scheme are: signature, message sent = Sign(message content, key) valid, message content = Verification(message sent, key, signature) Signature algorithms are used with the COSE_Signature and COSE_Sign1 structures. At this time, only signatures with appendixes are defined for use with COSE, however considerable interest has been expressed in using a signature with message recovery algorithm due to the effective size reduction that is possible. Implementations will need to keep this in mind for later possible integration. 8.1. ECDSA ECDSA [DSS] defines a signature algorithm using ECC. Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithms allows for systems to avoid relying on random number generators in order to avoid generating the same value of 'k' (the per-message random value). Biased generation of the value be attacked and collisions will lead to leaked keys. It additionally allows for doing deterministic tests for the signature algorithm. The use of deterministic ECDSA does not lessen the need to to have good random number generation when creating the private key. Schaad Expires May 26, 2017 [Page 37] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 The ECDSA signature algorithm is parameterized with a hash function (h). In the event that the length of the hash function output is greater than the group of the key, the left-most bytes of the hash output are used. The algorithms defined in this document can be found in Table 5. +-------+-------+---------+------------------+ | name | value | hash | description | +-------+-------+---------+------------------+ | ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 | | | | | | | ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 | | | | | | | ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 | +-------+-------+---------+------------------+ Table 5: ECDSA Algorithm Values This document defines ECDSA to work only with the curves P-256, P-384 and P-521. This document requires that the curves be encoded using the 'EC2' (2 coordinate Elliptic Curve) key type. Implementations need to check that the key type and curve are correct when creating and verifying a signature. Other documents can define it to work with other curves and points in the future. In order to promote interoperability, it is suggested that SHA-256 be used only with curve P-256, SHA-384 be used only with curve P-384 and SHA-512 be used with curve P-521. This is aligned with the recommendation in Section 4 of [RFC5480]. The signature algorithm results in a pair of integers (R, S). These integers will the same length as length of the key used for the signature process. The signature is encoded by converting the integers into byte strings of the same length as the key size. The length is rounded up to the nearest byte and is left padded with zero bits to get to the correct length. The two integers are then concatenated together to form a byte string that is the resulting signature. Using the function defined in [I-D.moriarty-pkcs1] the signature is: Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8) When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'EC2'. Schaad Expires May 26, 2017 [Page 38] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o If the 'alg' field is present, it MUST match the ECDSA signature algorithm being used. o If the 'key_ops' field is present, it MUST include 'sign' when creating an ECDSA signature. o If the 'key_ops' field is present, it MUST include 'verify' when verifying an ECDSA signature. 8.1.1. Security Considerations The security strength of the signature is no greater than the minimum of the security strength associated with the bit length of the key and the security strength of the hash function. Note: Use of this technique is a good idea even when good random number generation exists. Doing so both reduces the possibility of having the same value of 'k' in two signature operations and allows for reproducible signature values, which helps testing. There are two substitution attacks that can theoretically be mounted against the ECDSA signature algorithm. o Changing the curve used to validate the signature: If one changes the curve used to validate the signature, then potentially one could have a two messages with the same signature each computed under a different curve. The only requirement on the new curve is that its order be the same as the old one and it be acceptable to the client. An example would be to change from using the curve secp256r1 (aka P-256) to using secp256k1. (Both are 256 bit curves.) We current do not have any way to deal with this version of the attack except to restrict the overall set of curves that can be used. o Change the hash function used to validate the signature: If one has either two different hash functions of the same length, or one can truncate a hash function down, then one could potentially find collisions between the hash functions rather than within a single hash function. (For example, truncating SHA-512 to 256 bits might collide with a SHA-256 bit hash value.) As the hash algorithm is part of the signature algorithm identifier, this attack is mitigated by including signature algorithm identifier in the protected header. Schaad Expires May 26, 2017 [Page 39] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 8.2. Edwards-curve Digital Signature Algorithms (EdDSA) [I-D.irtf-cfrg-eddsa] describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing and, HashEdDSA where a hash function is applied to the content before signing and the result of that hash function is signed. For the EdDSA, the content to be signed (either the message or the pre-hash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. This means that there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE object (with the hash value) and the content as separate items. The algorithms defined in this document can be found in Table 6. A single signature algorithm is defined, which can be used for multiple curves. +-------+-------+-------------+ | name | value | description | +-------+-------+-------------+ | EdDSA | -8 | EdDSA | +-------+-------+-------------+ Table 6: EdDSA Algorithm Values [I-D.irtf-cfrg-eddsa] describes the method of encoding the signature value. When using a COSE key for this algorithm the following checks are made: o The 'kty' field MUST be present and it MUST be 'OKP' (Octet Key Pair). o The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm. o If the 'alg' field is present, it MUST match 'EdDSA'. Schaad Expires May 26, 2017 [Page 40] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature. o If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature. 8.2.1. Security Considerations How public values are computed is not the same when looking at EdDSA and ECDH, for this reason they should not be used with the other algorithm. If batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED. Signing and non- batch signature verification are deterministic operations and do not need random numbers of any kind. 9. Message Authentication (MAC) Algorithms Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, be used to prove the identity of the sender to a third party. MACs use the same scheme as signature with appendix algorithms. The message content is processed and an authentication code is produced. The authentication code is frequently called a tag. The MAC functions are: tag = MAC_Create(message content, key) valid = MAC_Verify(message content, key, tag) MAC algorithms can be based on either a block cipher algorithm (i.e., AES-MAC) or a hash algorithm (i.e., HMAC). This document defines a MAC algorithm using each of these constructions. MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures. 9.1. Hash-based Message Authentication Codes (HMAC) The Hash-based Message Authentication Code algorithm (HMAC) [RFC2104][RFC4231] was designed to deal with length extension attacks. The algorithm was also designed to allow for new hash algorithms to be directly plugged in without changes to the hash function. The HMAC design process has been shown as solid since, while the security of hash algorithms such as MD5 has decreased over Schaad Expires May 26, 2017 [Page 41] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 time, the security of HMAC combined with MD5 has not yet been shown to be compromised [RFC6151]. The HMAC algorithm is parameterized by an inner and outer padding, a hash function (h), and an authentication tag value length. For this specification, the inner and outer padding are fixed to the values set in [RFC2104]. The length of the authentication tag corresponds to the difficulty of producing a forgery. For use in constrained environments, we define a set of HMAC algorithms that are truncated. There are currently no known issues with truncation, however the security strength of the message tag is correspondingly reduced in strength. When truncating, the left-most tag length bits are kept and transmitted. The algorithms defined in this document can be found in Table 7. +-----------+-------+---------+----------+--------------------------+ | name | value | Hash | Tag | description | | | | | Length | | +-----------+-------+---------+----------+--------------------------+ | HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 | | 256/64 | | | | truncated to 64 bits | | | | | | | | HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 | | 256/256 | | | | | | | | | | | | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 | | 384/384 | | | | | | | | | | | | HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 | | 512/512 | | | | | +-----------+-------+---------+----------+--------------------------+ Table 7: HMAC Algorithm Values Some recipient algorithms carry the key while others derive a key from secret data. For those algorithms that carry the key (such as AES-KeyWrap), the size of the HMAC key SHOULD be the same size as the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. Schaad Expires May 26, 2017 [Page 42] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o If the 'alg' field is present, it MUST match the HMAC algorithm being used. o If the 'key_ops' field is present, it MUST include 'MAC create' when creating an HMAC authentication tag. o If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an HMAC authentication tag. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. 9.1.1. Security Considerations HMAC has proved to be resistant to attack even when used with weakened hash algorithms. The current best known attack appears is to brute force the key. This means that key size is going to be directly related to the security of an HMAC operation. 9.2. AES Message Authentication Code (AES-CBC-MAC) AES-CBC-MAC is defined in [MAC]. (Note this is not the same algorithm as AES-CMAC [RFC4493]). AES-CBC-MAC is parameterized by the key length, the authentication tag length and the IV used. For all of these algorithms, the IV is fixed to all zeros. We provide an array of algorithms for various key lengths and tag lengths. The algorithms defined in this document are found in Table 8. Schaad Expires May 26, 2017 [Page 43] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +-------------+-------+----------+----------+-----------------------+ | name | value | key | tag | description | | | | length | length | | +-------------+-------+----------+----------+-----------------------+ | AES-MAC | 14 | 128 | 64 | AES-MAC 128 bit key, | | 128/64 | | | | 64-bit tag | | | | | | | | AES-MAC | 15 | 256 | 64 | AES-MAC 256 bit key, | | 256/64 | | | | 64-bit tag | | | | | | | | AES-MAC | 25 | 128 | 128 | AES-MAC 128 bit key, | | 128/128 | | | | 128-bit tag | | | | | | | | AES-MAC | 26 | 256 | 128 | AES-MAC 256 bit key, | | 256/128 | | | | 128-bit tag | +-------------+-------+----------+----------+-----------------------+ Table 8: AES-MAC Algorithm Values Keys may be obtained either from a key structure or from a recipient structure. Implementations creating and validating MAC values MUST validate that the key type, key length and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. o If the 'alg' field is present, it MUST match the AES-MAC algorithm being used. o If the 'key_ops' field is present, it MUST include 'MAC create' when creating an AES-MAC authentication tag. o If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an AES-MAC authentication tag. 9.2.1. Security Considerations A number of attacks exist against CBC-MAC that need to be considered. - o A single key must only be used for messages of a fixed and known length. If this is not the case, an attacker will be able to generate a message with a valid tag given two message and tag pairs. This can be addressed by using different keys for different length messages. The current structure mitigates this Schaad Expires May 26, 2017 [Page 44] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 problem, as a specific encoding structure that includes lengths is built and signed. (CMAC also addresses this issue.) o When using CBC mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code. o If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros. 10. Content Encryption Algorithms Content Encryption Algorithms provide data confidentiality for potentially large blocks of data using a symmetric key. They provide integrity on the data that was encrypted, however they provide either no or very limited data origination. (One cannot, for example, be used to prove the identity of the sender to a third party.) The ability to provide data origination is linked to how the CEK is obtained. COSE restricts the set of legal content encryption algorithms to those that support authentication both of the content and additional data. The encryption process will generate some type of authentication value, but that value may be either explicit or implicit in terms of the algorithm definition. For simplicity sake, the authentication code will normally be defined as being appended to the cipher text stream. The encryption functions are: ciphertext = Encrypt(message content, key, additional data) valid, message content = Decrypt(cipher text, key, additional data) Most AEAD algorithms are logically defined as returning the message content only if the decryption is valid. Many but not all implementations will follow this convention. The message content MUST NOT be used if the decryption does not validate. These algorithms are used in COSE_Encrypt and COSE_Encrypt0. 10.1. AES GCM The GCM mode is a generic authenticated encryption block cipher mode defined in [AES-GCM]. The GCM mode is combined with the AES block encryption algorithm to define an AEAD cipher. The GCM mode is parameterized by the size of the authentication tag and the size of the nonce. This document fixes the size of the nonce at 96 bits. The size of the authentication tag is limited to a small Schaad Expires May 26, 2017 [Page 45] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 set of values. For this document however, the size of the authentication tag is fixed at 128 bits. The set of algorithms defined in this document are in Table 9. +---------+-------+------------------------------------------+ | name | value | description | +---------+-------+------------------------------------------+ | A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag | | | | | | A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag | | | | | | A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag | +---------+-------+------------------------------------------+ Table 9: Algorithm Value for AES-GCM Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. o If the 'alg' field is present, it MUST match the AES-GCM algorithm being used. o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. 10.1.1. Security Considerations When using AES-GCM, the following restrictions MUST be enforced: o The key and nonce pair MUST be unique for every message encrypted. o The total amount of data encrypted for a single key MUST NOT exceed 2^39 - 256 bits. An explicit check is required only in environments where it is expected that it might be exceeded. Consideration was given to supporting smaller tag values; the constrained community would desire tag sizes in the 64-bit range. Schaad Expires May 26, 2017 [Page 46] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Doing so drastically changes both the maximum messages size (generally not an issue) and the number of times that a key can be used. Given that CCM is the usual mode for constrained environments, restricted modes are not supported. 10.2. AES CCM Counter with CBC-MAC (CCM) is a generic authentication encryption block cipher mode defined in [RFC3610]. The CCM mode is combined with the AES block encryption algorithm to define a commonly used content encryption algorithm used in constrained devices. The CCM mode has two parameter choices. The first choice is M, the size of the authentication field. The choice of the value for M involves a trade-off between message growth (from the tag) and the probably that an attacker can undetectably modify a message. The second choice is L, the size of the length field. This value requires a trade-off between the maximum message size and the size of the Nonce. It is unfortunate that the specification for CCM specified L and M as a count of bytes rather than a count of bits. This leads to possible misunderstandings where AES-CCM-8 is frequently used to refer to a version of CCM mode where the size of the authentication is 64 bits and not 8 bits. These values have traditionally been specified as bit counts rather than byte counts. This document will follow the convention of using bit counts so that it is easier to compare the different algorithms presented in this document. We define a matrix of algorithms in this document over the values of L and M. Constrained devices are usually operating in situations where they use short messages and want to avoid doing recipient specific cryptographic operations. This favors smaller values of both L and M. Less constrained devices will want to be able to use larger messages and are more willing to generate new keys for every operation. This favors larger values of L and M. The following values are used for L: 16 bits (2) limits messages to 2^16 bytes (64 KiB) in length. This is sufficiently long for messages in the constrained world. The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. 64 bits (8) limits messages to 2^64 bytes in length. The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without repeating. Schaad Expires May 26, 2017 [Page 47] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 The following values are used for M: 64 bits (8) produces a 64-bit authentication tag. This implies that there is a 1 in 2^64 chance that a modified message will authenticate. 128 bits (16) produces a 128-bit authentication tag. This implies that there is a 1 in 2^128 chance that a modified message will authenticate. Schaad Expires May 26, 2017 [Page 48] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +--------------------+-------+----+-----+-----+---------------------+ | name | value | L | M | k | description | +--------------------+-------+----+-----+-----+---------------------+ | AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode | | | | | | | 128-bit key, 64-bit | | | | | | | tag, 13-byte nonce | | | | | | | | | AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode | | | | | | | 256-bit key, 64-bit | | | | | | | tag, 13-byte nonce | | | | | | | | | AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode | | | | | | | 128-bit key, 64-bit | | | | | | | tag, 7-byte nonce | | | | | | | | | AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode | | | | | | | 256-bit key, 64-bit | | | | | | | tag, 7-byte nonce | | | | | | | | | AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode | | | | | | | 128-bit key, | | | | | | | 128-bit tag, | | | | | | | 13-byte nonce | | | | | | | | | AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode | | | | | | | 256-bit key, | | | | | | | 128-bit tag, | | | | | | | 13-byte nonce | | | | | | | | | AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode | | | | | | | 128-bit key, | | | | | | | 128-bit tag, 7-byte | | | | | | | nonce | | | | | | | | | AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode | | | | | | | 256-bit key, | | | | | | | 128-bit tag, 7-byte | | | | | | | nonce | +--------------------+-------+----+-----+-----+---------------------+ Table 10: Algorithm Values for AES-CCM Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length and algorithm are correct and appropriate for the entities involved. Schaad Expires May 26, 2017 [Page 49] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. o If the 'alg' field is present, it MUST match the AES-CCM algorithm being used. o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. 10.2.1. Security Considerations When using AES-CCM, the following restrictions MUST be enforced: o The key and nonce pair MUST be unique for every message encrypted. Note that the value of L influences the number of unique nonces. o The total number of times the AES block cipher is used MUST NOT exceed 2^61 operations. This limitation is the sum of times the block cipher is used in computing the MAC value and in performing stream encryption operations. An explicit check is required only in environments where it is expected that it might be exceeded. [RFC3610] additionally calls out one other consideration of note. It is possible to do a pre-computation attack against the algorithm in cases where portions of the plaintext are highly predictable. This reduces the security of the key size by half. Ways to deal with this attack include adding a random portion to the nonce value and/or increasing the key size used. Using a portion of the nonce for a random value will decrease the number of messages that a single key can be used for. Increasing the key size may require more resources in the constrained device. See sections 5 and 10 of [RFC3610] for more information. 10.3. ChaCha20 and Poly1305 ChaCha20 and Poly1305 combined together is an AEAD mode that is defined in [RFC7539]. This is an algorithm defined to be a cipher that is not AES and thus would not suffer from any future weaknesses found in AES. These cryptographic functions are designed to be fast in software-only implementations. The ChaCha20/Poly1305 AEAD construction defined in [RFC7539] has no parameterization. It takes a 256-bit key and a 96-bit nonce, as well Schaad Expires May 26, 2017 [Page 50] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 as the plain text and additional data as inputs and produces the cipher text as an option. We define one algorithm identifier for this algorithm in Table 11. +-------------------+-------+---------------------------------------+ | name | value | description | +-------------------+-------+---------------------------------------+ | ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ 256-bit key, | | | | 128-bit tag | +-------------------+-------+---------------------------------------+ Table 11: Algorithm Value for AES-GCM Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. o If the 'alg' field is present, it MUST match the ChaCha20/Poly1305 algorithm being used. o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. 10.3.1. Security Considerations The pair of key, nonce MUST be unique for every invocation of the algorithm. Nonce counters are considered to be an acceptable way of ensuring that they are unique. 11. Key Derivation Functions (KDF) Key Derivation Functions (KDFs) are used to take some secret value and generate a different one. The secret value comes in three flavors: o Secrets that are uniformly random: This is the type of secret that is created by a good random number generator. Schaad Expires May 26, 2017 [Page 51] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Secrets that are not uniformly random: This is type of secret that is created by operations like key agreement. o Secrets that are not random: This is the type of secret that people generate for things like passwords. General KDF functions work well with the first type of secret, can do reasonably well with the second type of secret, and generally do poorly with the last type of secret. None of the KDF functions in this section are designed to deal with the type of secrets that are used for passwords. Functions like PBES2 [I-D.moriarty-pkcs5-v2dot1] need to be used for that type of secret. The same KDF function can be setup to deal with the first two types of secrets in a different way. The KDF function defined in Section 11.1 is such a function. This is reflected in the set of algorithms defined for HKDF. When using KDF functions, one component that is included is context information. Context information is used to allow for different keying information to be derived from the same secret. The use of context based keying material is considered to be a good security practice. This document defines a single context structure and a single KDF function. These elements are used for all of the recipient algorithms defined in this document that require a KDF process. These algorithms are defined in Section 12.1.2, Section 12.4.1, and Section 12.5.1. 11.1. HMAC-based Extract-and-Expand Key Derivation Function (HKDF) The HKDF key derivation algorithm is defined in [RFC5869]. The HKDF algorithm takes these inputs: secret - a shared value that is secret. Secrets may be either previously shared or derived from operations like a DH key agreement. salt - an optional value that is used to change the generation process. The salt value can be either public or private. If the salt is public and carried in the message, then the 'salt' algorithm header parameter defined in Table 13 is used. While [RFC5869] suggests that the length of the salt be the same as the length of the underlying hash value, any amount of salt will improve the security as different key values will be generated. This parameter is protected by being included in the key Schaad Expires May 26, 2017 [Page 52] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 computation and does not need to be separately authenticated. The salt value does not need to be unique for every message sent. length - the number of bytes of output that need to be generated. context information - Information that describes the context in which the resulting value will be used. Making this information specific to the context in which the material is going to be used ensures that the resulting material will always be tied to that usage. The context structure defined in Section 11.2 is used by the KDF functions in this document. PRF - The underlying pseudo-random function to be used in the HKDF algorithm. The PRF is encoded into the HKDF algorithm selection. HKDF is defined to use HMAC as the underlying PRF. However, it is possible to use other functions in the same construct to provide a different KDF function that is more appropriate in the constrained world. Specifically, one can use AES-CBC-MAC as the PRF for the expand step, but not for the extract step. When using a good random shared secret of the correct length, the extract step can be skipped. For the AES algorithm versions, the extract step is always skipped. The extract step cannot be skipped if the secret is not uniformly random, for example, if it is the result of an ECDH key agreement step. (This implies that the AES HKDF version cannot be used with ECDH.) If the extract step is skipped, the 'salt' value is not used as part of the HKDF functionality. The algorithms defined in this document are found in Table 12. +---------------+-----------------+---------------------------------+ | name | PRF | description | +---------------+-----------------+---------------------------------+ | HKDF SHA-256 | HMAC with | HKDF using HMAC SHA-256 as the | | | SHA-256 | PRF | | | | | | HKDF SHA-512 | HMAC with | HKDF using HMAC SHA-512 as the | | | SHA-512 | PRF | | | | | | HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as the PRF | | MAC-128 | | w/ 128-bit key | | | | | | HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as the PRF | | MAC-256 | | w/ 256-bit key | +---------------+-----------------+---------------------------------+ Table 12: HKDF algorithms Schaad Expires May 26, 2017 [Page 53] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +------+-------+------+-------------------------------+-------------+ | name | label | type | algorithm | description | +------+-------+------+-------------------------------+-------------+ | salt | -20 | bstr | direct+HKDF-SHA-256, direct | Random salt | | | | | +HKDF-SHA-512, direct+HKDF- | | | | | | AES-128, direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ES+HKDF-512, ECDH- | | | | | | SS+HKDF-256, ECDH- | | | | | | SS+HKDF-512, ECDH-ES+A128KW, | | | | | | ECDH-ES+A192KW, ECDH- | | | | | | ES+A256KW, ECDH-SS+A128KW, | | | | | | ECDH-SS+A192KW, ECDH- | | | | | | SS+A256KW | | +------+-------+------+-------------------------------+-------------+ Table 13: HKDF Algorithm Parameters 11.2. Context Information Structure The context information structure is used to ensure that the derived keying material is "bound" to the context of the transaction. The context information structure used here is based on that defined in [SP800-56A]. By using CBOR for the encoding of the context information structure, we automatically get the same type and length separation of fields that is obtained by the use of ASN.1. This means that there is no need to encode the lengths for the base elements as it is done by the encoding used in JOSE (Section 4.6.2 of [RFC7518]). The context information structure refers to PartyU and PartyV as the two parties that are doing the key derivation. Unless the application protocol defines differently, we assign PartyU to the entity that is creating the message and PartyV to the entity that is receiving the message. By doing this association, different keys will be derived for each direction as the context information is different in each direction. The context structure is built from information that is known to both entities. This information can be obtained from a variety of sources: o Fields can be defined by the application. This is commonly used to assign fixed names to parties, but can be used for other items such as nonces. o Fields can be defined by usage of the output. Examples of this are the algorithm and key size that are being generated. Schaad Expires May 26, 2017 [Page 54] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Fields can be defined by parameters from the message. We define a set of parameters in Table 14 that can be used to carry the values associated with the context structure. Examples of this are identities and nonce values. These parameters are designed to be placed in the unprotected bucket of the recipient structure. (They do not need to be in the protected bucket since they already are included in the cryptographic computation by virtue of being included in the context structure.) +----------+-------+------+---------------------------+-------------+ | name | label | type | algorithm | description | +----------+-------+------+---------------------------+-------------+ | PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U | | identity | | | direct+HKDF-SHA-512, | identity | | | | | direct+HKDF-AES-128, | Information | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ES+HKDF-512, ECDH- | | | | | | SS+HKDF-256, ECDH- | | | | | | SS+HKDF-512, ECDH- | | | | | | ES+A128KW, ECDH- | | | | | | ES+A192KW, ECDH- | | | | | | ES+A256KW, ECDH- | | | | | | SS+A128KW, ECDH- | | | | | | SS+A192KW, ECDH-SS+A256KW | | | | | | | | | PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U | | nonce | | / | direct+HKDF-SHA-512, | provided | | | | int | direct+HKDF-AES-128, | nonce | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ES+HKDF-512, ECDH- | | | | | | SS+HKDF-256, ECDH- | | | | | | SS+HKDF-512, ECDH- | | | | | | ES+A128KW, ECDH- | | | | | | ES+A192KW, ECDH- | | | | | | ES+A256KW, ECDH- | | | | | | SS+A128KW, ECDH- | | | | | | SS+A192KW, ECDH-SS+A256KW | | | | | | | | | PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U | | other | | | direct+HKDF-SHA-512, | other | | | | | direct+HKDF-AES-128, | provided | | | | | direct+HKDF-AES-256, | information | | | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ES+HKDF-512, ECDH- | | | | | | SS+HKDF-256, ECDH- | | | | | | SS+HKDF-512, ECDH- | | Schaad Expires May 26, 2017 [Page 55] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 | | | | ES+A128KW, ECDH- | | | | | | ES+A192KW, ECDH- | | | | | | ES+A256KW, ECDH- | | | | | | SS+A128KW, ECDH- | | | | | | SS+A192KW, ECDH-SS+A256KW | | | | | | | | | PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V | | identity | | | direct+HKDF-SHA-512, | identity | | | | | direct+HKDF-AES-128, | Information | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ES+HKDF-512, ECDH- | | | | | | SS+HKDF-256, ECDH- | | | | | | SS+HKDF-512, ECDH- | | | | | | ES+A128KW, ECDH- | | | | | | ES+A192KW, ECDH- | | | | | | ES+A256KW, ECDH- | | | | | | SS+A128KW, ECDH- | | | | | | SS+A192KW, ECDH-SS+A256KW | | | | | | | | | PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V | | nonce | | / | direct+HKDF-SHA-512, | provided | | | | int | direct+HKDF-AES-128, | nonce | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ES+HKDF-512, ECDH- | | | | | | SS+HKDF-256, ECDH- | | | | | | SS+HKDF-512, ECDH- | | | | | | ES+A128KW, ECDH- | | | | | | ES+A192KW, ECDH- | | | | | | ES+A256KW, ECDH- | | | | | | SS+A128KW, ECDH- | | | | | | SS+A192KW, ECDH-SS+A256KW | | | | | | | | | PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V | | other | | | direct+HKDF-SHA-512, | other | | | | | direct+HKDF-AES-128, | provided | | | | | direct+HKDF-AES-256, | information | | | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ES+HKDF-512, ECDH- | | | | | | SS+HKDF-256, ECDH- | | | | | | SS+HKDF-512, ECDH- | | | | | | ES+A128KW, ECDH- | | | | | | ES+A192KW, ECDH- | | | | | | ES+A256KW, ECDH- | | | | | | SS+A128KW, ECDH- | | | | | | SS+A192KW, ECDH-SS+A256KW | | +----------+-------+------+---------------------------+-------------+ Schaad Expires May 26, 2017 [Page 56] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Table 14: Context Algorithm Parameters We define a CBOR object to hold the context information. This object is referred to as COSE_KDF_Context. The object is based on a CBOR array type. The fields in the array are: AlgorithmID This field indicates the algorithm for which the key material will be used. This normally is either a Key Wrap algorithm identifier or a Content Encryption algorithm identifier. The values are from the "COSE Algorithm Value" registry. This field is required to be present. The field exists in the context information so that if the same environment is used for different algorithms, then completely different keys will be generated for each of those algorithms. (This practice means if algorithm A is broken and thus is easier to find, the key derived for algorithm B will not be the same as the key derived for algorithm A.) PartyUInfo This field holds information about party U. The PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo are encoded in the order presented, however if the element does not exist no element is placed in the array. The elements of the PartyUInfo array are: identity This contains the identity information for party U. The identities can be assigned in one of two manners. Firstly, a protocol can assign identities based on roles. For example, the roles of "client" and "server" may be assigned to different entities in the protocol. Each entity would then use the correct label for the data they send or receive. The second way for a protocol to assign identities is to use a name based on a naming system (i.e., DNS, X.509 names). We define an algorithm parameter 'PartyU identity' that can be used to carry identity information in the message. However, identity information is often known as part of the protocol and can thus be inferred rather than made explicit. If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information. The identity information does not need to be specified and is set to nil in that case. nonce This contains a nonce value. The nonce can either be implicit from the protocol or carried as a value in the unprotected headers. We define an algorithm parameter 'PartyU nonce' that can be used to carry this value in the message However, the nonce value could be determined by the application and the value determined from elsewhere. Schaad Expires May 26, 2017 [Page 57] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 This option does not need to be specified and is set to nil in that case other This contains other information that is defined by the protocol. This option does not need to be specified and is set to nil in that case PartyVInfo This field holds information about party V. The content of the structure are the same as for the PartyUInfo but for party V. SuppPubInfo This field contains public information that is mutually known to both parties. keyDataLength This is set to the number of bits of the desired output value. (This practice means if algorithm A can use two different key lengths, the key derived for longer key size will not contain the key for shorter key size as a prefix.) protected This field contains the protected parameter field. If there are no elements in the protected field, then use a zero length bstr. other This field is for free form data defined by the application. An example is that an application could define two different strings to be placed here to generate different keys for a data stream vs a control stream. This field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included. SuppPrivInfo This field contains private information that is mutually known private information. An example of this information would be a pre-existing shared secret. (This could, for example, be used in combination with an ECDH key agreement to provide a secondary proof of identity.) The field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included. The following CDDL fragment corresponds to the text above. Schaad Expires May 26, 2017 [Page 58] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 PartyInfo = ( identity : bstr / nil, nonce : bstr / int / nil, other : bstr / nil, ) COSE_KDF_Context = [ AlgorithmID : int / tstr, PartyUInfo : [ PartyInfo ], PartyVInfo : [ PartyInfo ], SuppPubInfo : [ keyDataLength : uint, protected : empty_or_serialized_map, ? other : bstr ], ? SuppPrivInfo : bstr ] 12. Content Key Distribution Methods Content key distribution methods (recipient algorithms) can be defined into a number of different classes. COSE has the ability to support many classes of recipient algorithms. In this section, a number of classes are listed and then a set of algorithms are specified for each of the classes. The names of the recipient algorithm classes used here are the same as are defined in [RFC7516]. Other specifications use different terms for the recipient algorithm classes or do not support some of the recipient algorithm classes. 12.1. Direct Encryption The direct encryption class algorithms share a secret between the sender and the recipient that is used either directly or after manipulation as the CEK. When direct encryption mode is used, it MUST be the only mode used on the message. The COSE_Encrypt structure for the recipient is organized as follows: o The 'protected' field MUST be a zero length item unless it is used in the computation of the content key. o The 'alg' parameter MUST be present. o A parameter identifying the shared secret SHOULD be present. o The 'ciphertext' field MUST be a zero length item. o The 'recipients' field MUST be absent. Schaad Expires May 26, 2017 [Page 59] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 12.1.1. Direct Key This recipient algorithm is the simplest; the identified key is directly used as the key for the next layer down in the message. There are no algorithm parameters defined for this algorithm. The algorithm identifier value is assigned in Table 15. When this algorithm is used, the protected field MUST be zero length. The key type MUST be 'Symmetric'. +--------+-------+-------------------+ | name | value | description | +--------+-------+-------------------+ | direct | -6 | Direct use of CEK | +--------+-------+-------------------+ Table 15: Direct Key 12.1.1.1. Security Considerations This recipient algorithm has several potential problems that need to be considered: o These keys need to have some method to be regularly updated over time. All of the content encryption algorithms specified in this document have limits on how many times a key can be used without significant loss of security. o These keys need to be dedicated to a single algorithm. There have been a number of attacks developed over time when a single key is used for multiple different algorithms. One example of this is the use of a single key both for CBC encryption mode and CBC-MAC authentication mode. o Breaking one message means all messages are broken. If an adversary succeeds in determining the key for a single message, then the key for all messages is also determined. 12.1.2. Direct Key with KDF These recipient algorithms take a common shared secret between the two parties and applies the HKDF function (Section 11.1), using the context structure defined in Section 11.2 to transform the shared secret into the CEK. The 'protected' field can be of non-zero length. Either the 'salt' parameter of HKDF or the partyU 'nonce' parameter of the context structure MUST be present. The salt/nonce parameter can be generated either randomly or deterministically. The Schaad Expires May 26, 2017 [Page 60] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 requirement is that it be a unique value for the shared secret in question. If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the hash function underlying HKDF. While there is no way to guarantee that it will be unique, there is a high probability that it will be unique. If the salt/nonce value is generated deterministically, it can be guaranteed to be unique and thus there is no length requirement. A new IV must be used for each message if the same key is used. The IV can be modified in a predictable manner, a random manner or an unpredictable manner (i.e., encrypting a counter). The IV used for a key can also be generated from the same HKDF functionality as the key is generated. If HKDF is used for generating the IV, the algorithm identifier is set to "IV- GENERATION". When these algorithms are used, the key type MUST be 'symmetric'. The set of algorithms defined in this document can be found in Table 16. +---------------------+-------+-------------+-----------------------+ | name | value | KDF | description | +---------------------+-------+-------------+-----------------------+ | direct+HKDF-SHA-256 | -10 | HKDF | Shared secret w/ HKDF | | | | SHA-256 | and SHA-256 | | | | | | | direct+HKDF-SHA-512 | -11 | HKDF | Shared secret w/ HKDF | | | | SHA-512 | and SHA-512 | | | | | | | direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ AES- | | | | MAC-128 | MAC 128-bit key | | | | | | | direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ AES- | | | | MAC-256 | MAC 256-bit key | +---------------------+-------+-------------+-----------------------+ Table 16: Direct Key with KDF When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. Schaad Expires May 26, 2017 [Page 61] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o If the 'alg' field is present, it MUST match the algorithm being used. o If the 'key_ops' field is present, it MUST include 'deriveKey' or 'deriveBits'. 12.1.2.1. Security Considerations The shared secret needs to have some method to be regularly updated over time. The shared secret forms the basis of trust. Although not used directly, it should still be subject to scheduled rotation. While these methods do not provide for perfect forward secrecy, as the same shared secret is used for all of the keys generated, if the key for any single message is discovered only the message (or series of messages) using that derived key are compromised. A new key derivation step will generate a new key which requires the same amount of work to get the key. 12.2. Key Wrapping In key wrapping mode, the CEK is randomly generated and that key is then encrypted by a shared secret between the sender and the recipient. All of the currently defined key wrapping algorithms for COSE are AE algorithms. Key wrapping mode is considered to be superior to direct encryption if the system has any capability for doing random key generation. This is because the shared key is used to wrap random data rather than data that has some degree of organization and may in fact be repeating the same content. The use of Key Wrapping loses the weak data origination that is provided by the direct encryption algorithms. The COSE_Encrypt structure for the recipient is organized as follows: o The 'protected' field MUST be absent if the key wrap algorithm is an AE algorithm. o The 'recipients' field is normally absent, but can be used. Applications MUST deal with a recipient field being present, not being able to decrypt that recipient is an acceptable way of dealing with it. Failing to process the message is not an acceptable way of dealing with it. o The plain text to be encrypted is the key from next layer down (usually the content layer). Schaad Expires May 26, 2017 [Page 62] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the shared secret. 12.2.1. AES Key Wrapping The AES Key Wrapping algorithm is defined in [RFC3394]. This algorithm uses an AES key to wrap a value that is a multiple of 64 bits. As such, it can be used to wrap a key for any of the content encryption algorithms defined in this document. The algorithm requires a single fixed parameter, the initial value. This is fixed to the value specified in Section 2.2.3.1 of [RFC3394]. There are no public parameters that vary on a per invocation basis. The protected header field MUST be empty. Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. o If the 'alg' field is present, it MUST match the AES Key Wrap algorithm being used. o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. +--------+-------+----------+-----------------------------+ | name | value | key size | description | +--------+-------+----------+-----------------------------+ | A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key | | | | | | | A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key | | | | | | | A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key | +--------+-------+----------+-----------------------------+ Table 17: AES Key Wrap Algorithm Values Schaad Expires May 26, 2017 [Page 63] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 12.2.1.1. Security Considerations for AES-KW The shared secret needs to have some method to be regularly updated over time. The shared secret is the basis of trust. 12.3. Key Transport Key transport mode is also called key encryption mode in some standards. Key transport mode differs from key wrap mode in that it uses an asymmetric encryption algorithm rather than a symmetric encryption algorithm to protect the key. This document does not define any key transport mode algorithms. When using a key transport algorithm, the COSE_Encrypt structure for the recipient is organized as follows: o The 'protected' field MUST be absent. o The plain text to be encrypted is the key from next layer down (usually the content layer). o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the asymmetric key. 12.4. Direct Key Agreement The 'direct key agreement' class of recipient algorithms uses a key agreement method to create a shared secret. A KDF is then applied to the shared secret to derive a key to be used in protecting the data. This key is normally used as a CEK or MAC key, but could be used for other purposes if more than two layers are in use (see Appendix B). The most commonly used key agreement algorithm is Diffie-Hellman, but other variants exist. Since COSE is designed for a store and forward environment rather than an on-line environment, many of the DH variants cannot be used as the receiver of the message cannot provide any dynamic key material. One side-effect of this is that perfect forward secrecy (see [RFC4949]) is not achievable. A static key will always be used for the receiver of the COSE object. Two variants of DH that are supported are: Ephemeral-Static DH: where the sender of the message creates a one-time DH key and uses a static key for the recipient. The use of the ephemeral sender key means that no additional random input is needed as this is randomly generated for each message. Schaad Expires May 26, 2017 [Page 64] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Static-Static DH: where a static key is used for both the sender and the recipient. The use of static keys allows for recipient to get a weak version of data origination for the message. When static-static key agreement is used, then some piece of unique data for the KDF is required to ensure that a different key is created for each message. When direct key agreement mode is used, there MUST be only one recipient in the message. This method creates the key directly and that makes it difficult to mix with additional recipients. If multiple recipients are needed, then the version with key wrap needs to be used. The COSE_Encrypt structure for the recipient is organized as follows: o At a minimum, headers MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the recipient's asymmetric key. o The headers SHOULD identify the sender's key for the static-static versions and MUST contain the sender's ephemeral key for the ephemeral-static versions. 12.4.1. ECDH The mathematics for Elliptic Curve Diffie-Hellman can be found in [RFC6090]. In this document, the algorithm is extended to be used with the two curves defined in [RFC7748]. ECDH is parameterized by the following: o Curve Type/Curve: The curve selected controls not only the size of the shared secret, but the mathematics for computing the shared secret. The curve selected also controls how a point in the curve is represented and what happens for the identity points on the curve. In this specification, we allow for a number of different curves to be used. A set of curves are defined in Table 22. The math used to obtain the computed secret is based on the curve selected and not on the ECDH algorithm. For this reason, a new algorithm does not need to be defined for each of the curves. o Computed Secret to Shared Secret: Once the computed secret is known, the resulting value needs to be converted to a byte string to run the KDF function. The X coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly as it is a byte string of a known length. For the P-256, P-384 and P-521 curves, the X coordinate is run through the I2OSP function defined in [I-D.moriarty-pkcs1], using the same computation for n as is defined in Section 8.1. Schaad Expires May 26, 2017 [Page 65] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Ephemeral-static or static-static: The key agreement process may be done using either a static or an ephemeral key for the sender's side. When using ephemeral keys, the sender MUST generate a new ephemeral key for every key agreement operation. The ephemeral key is placed in the 'ephemeral key' parameter and MUST be present for all algorithm identifiers that use ephemeral keys. When using static keys, the sender MUST either generate a new random value or otherwise create a unique value. For the KDF functions used, this means either in the 'salt' parameter for HKDF (Table 13) or in the 'PartyU nonce' parameter for the context structure (Table 14) MUST be present. (Both may be present if desired.) The value in the parameter MUST be unique for the pair of keys being used. It is acceptable to use a global counter that is incremented for every static-static operation and use the resulting value. When using static keys, the static key should be identified to the recipient. The static key can be identified either by providing the key ('static key') or by providing a key identifier for the static key ('static key id'). Both of these parameters are defined in Table 19. o Key derivation algorithm: The result of an ECDH key agreement process does not provide a uniformly random secret. As such, it needs to be run through a KDF in order to produce a usable key. Processing the secret through a KDF also allows for the introduction of context material: how the key is going to be used, and one-time material for static-static key agreement. All of the algorithms defined in this document use one of the HKDF algorithms defined in Section 11.1 with the context structure defined in Section 11.2. o Key Wrap algorithm: No key wrap algorithm is used. This is represented in Table 18 as 'none'. The key size for the context structure is the content layer encryption algorithm size. The set of direct ECDH algorithms defined in this document are found in Table 18. Schaad Expires May 26, 2017 [Page 66] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +-----------+-------+---------+------------+--------+---------------+ | name | value | KDF | Ephemeral- | Key | description | | | | | Static | Wrap | | +-----------+-------+---------+------------+--------+---------------+ | ECDH-ES + | -25 | HKDF - | yes | none | ECDH ES w/ | | HKDF-256 | | SHA-256 | | | HKDF - | | | | | | | generate key | | | | | | | directly | | | | | | | | | ECDH-ES + | -26 | HKDF - | yes | none | ECDH ES w/ | | HKDF-512 | | SHA-512 | | | HKDF - | | | | | | | generate key | | | | | | | directly | | | | | | | | | ECDH-SS + | -27 | HKDF - | no | none | ECDH SS w/ | | HKDF-256 | | SHA-256 | | | HKDF - | | | | | | | generate key | | | | | | | directly | | | | | | | | | ECDH-SS + | -28 | HKDF - | no | none | ECDH SS w/ | | HKDF-512 | | SHA-512 | | | HKDF - | | | | | | | generate key | | | | | | | directly | +-----------+-------+---------+------------+--------+---------------+ Table 18: ECDH Algorithm Values Schaad Expires May 26, 2017 [Page 67] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +-----------+-------+----------+---------------------+--------------+ | name | label | type | algorithm | description | +-----------+-------+----------+---------------------+--------------+ | ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral | | key | | | ECDH-ES+HKDF-512, | Public key | | | | | ECDH-ES+A128KW, | for the | | | | | ECDH-ES+A192KW, | sender | | | | | ECDH-ES+A256KW | | | | | | | | | static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static | | key | | | ECDH-SS+HKDF-512, | Public key | | | | | ECDH-SS+A128KW, | for the | | | | | ECDH-SS+A192KW, | sender | | | | | ECDH-SS+A256KW | | | | | | | | | static | -3 | bstr | ECDH-SS+HKDF-256, | Static | | key id | | | ECDH-SS+HKDF-512, | Public key | | | | | ECDH-SS+A128KW, | identifier | | | | | ECDH-SS+A192KW, | for the | | | | | ECDH-SS+A256KW | sender | +-----------+-------+----------+---------------------+--------------+ Table 19: ECDH Algorithm Parameters This document defines these algorithms to be used with the curves P-256, P-384, P-521, X25519, and X448. Implementations MUST verify that the key type and curve are correct. Different curves are restricted to different key types. Implementations MUST verify that the curve and algorithm are appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'. o If the 'alg' field is present, it MUST match the Key Agreement algorithm being used. o If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key. o If the 'key_ops' field is present, it MUST be empty for the public key. Schaad Expires May 26, 2017 [Page 68] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 12.4.2. Security Considerations Some method of checking that points provided from external entities are valid. For the 'EC2' key format, this can be done by checking that the x and y values form a point on the curve. For the 'OKP' format, there is no simple way to do point validation. Consideration was given to requiring that the public keys of both entities be provided as part of the key derivation process. (As recommended in section 6.1 of [RFC7748].) This was not done as COSE is used in a store and forward format rather than in on line key exchange. In order for this to be a problem, either the receiver public key has to be chosen maliciously or the sender has to be malicious. In either case, all security evaporates anyway. A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted. (Either by the end user or by the entity that is responsible for making trust statements on keys.) 12.5. Key Agreement with Key Wrap Key Agreement with Key Wrapping uses a randomly generated CEK. The CEK is then encrypted using a Key Wrapping algorithm and a key derived from the shared secret computed by the key agreement algorithm. The function for this would be: encryptedKey = KeyWrap(KDF(DH-Shared, context), CEK) The COSE_Encrypt structure for the recipient is organized as follows: o The 'protected' field is fed into the KDF context structure. o The plain text to be encrypted is the key from next layer down (usually the content layer). o The 'alg' parameter MUST be present in the layer. o A parameter identifying the recipient's key SHOULD be present. A parameter identifying the sender's key SHOULD be present. 12.5.1. ECDH These algorithms are defined in Table 20. ECDH with Key Agreement is parameterized by the same parameters as for ECDH Section 12.4.1 with the following modifications: Schaad Expires May 26, 2017 [Page 69] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Key Wrap Algorithm: Any of the key wrap algorithms defined in Section 12.2.1 are supported. The size of the key used for the key wrap algorithm is fed into the KDF function. The set of identifiers are found in Table 20. +-----------+-------+---------+------------+--------+---------------+ | name | value | KDF | Ephemeral- | Key | description | | | | | Static | Wrap | | +-----------+-------+---------+------------+--------+---------------+ | ECDH-ES + | -29 | HKDF - | yes | A128KW | ECDH ES w/ | | A128KW | | SHA-256 | | | Concat KDF | | | | | | | and AES Key | | | | | | | wrap w/ 128 | | | | | | | bit key | | | | | | | | | ECDH-ES + | -30 | HKDF - | yes | A192KW | ECDH ES w/ | | A192KW | | SHA-256 | | | Concat KDF | | | | | | | and AES Key | | | | | | | wrap w/ 192 | | | | | | | bit key | | | | | | | | | ECDH-ES + | -31 | HKDF - | yes | A256KW | ECDH ES w/ | | A256KW | | SHA-256 | | | Concat KDF | | | | | | | and AES Key | | | | | | | wrap w/ 256 | | | | | | | bit key | | | | | | | | | ECDH-SS + | -32 | HKDF - | no | A128KW | ECDH SS w/ | | A128KW | | SHA-256 | | | Concat KDF | | | | | | | and AES Key | | | | | | | wrap w/ 128 | | | | | | | bit key | | | | | | | | | ECDH-SS + | -33 | HKDF - | no | A192KW | ECDH SS w/ | | A192KW | | SHA-256 | | | Concat KDF | | | | | | | and AES Key | | | | | | | wrap w/ 192 | | | | | | | bit key | | | | | | | | | ECDH-SS + | -34 | HKDF - | no | A256KW | ECDH SS w/ | | A256KW | | SHA-256 | | | Concat KDF | | | | | | | and AES Key | | | | | | | wrap w/ 256 | | | | | | | bit key | +-----------+-------+---------+------------+--------+---------------+ Table 20: ECDH Algorithm Values with Key Wrap Schaad Expires May 26, 2017 [Page 70] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'. o If the 'alg' field is present, it MUST match the Key Agreement algorithm being used. o If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key. o If the 'key_ops' field is present, it MUST be empty for the public key. 13. Key Object Parameters The COSE_Key object defines a way to hold a single key object. It is still required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key types. For each of the key types, we define both public and private members. The public members are what is transmitted to others for their usage. Private members allow for the archival of keys by individuals. However, there are some circumstances in which private keys may be distributed to entities in a protocol. Examples include: entities that have poor random number generation, centralized key creation for multi-cast type operations, and protocols in which a shared secret is used as a bearer token for authorization purposes. Key types are identified by the 'kty' member of the COSE_Key object. In this document, we define four values for the member: +-----------+-------+--------------------------------------------+ | name | value | description | +-----------+-------+--------------------------------------------+ | OKP | 1 | Octet Key Pair | | | | | | EC2 | 2 | Elliptic Curve Keys w/ X,Y Coordinate pair | | | | | | Symmetric | 4 | Symmetric Keys | | | | | | Reserved | 0 | This value is reserved | +-----------+-------+--------------------------------------------+ Table 21: Key Type Values Schaad Expires May 26, 2017 [Page 71] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 13.1. Elliptic Curve Keys Two different key structures could be defined for Elliptic Curve keys. One version uses both an x and a y coordinate, potentially with point compression ('EC2'). This is the traditional EC point representation that is used in [RFC5480]. The other version uses only the x coordinate as the y coordinate is either to be recomputed or not needed for the key agreement operation ('OKP'). Applications MUST check that the curve and the key type are consistent and reject a key if they are not. +---------+----------+-------+------------------------------------+ | name | key type | value | description | +---------+----------+-------+------------------------------------+ | P-256 | EC2 | 1 | NIST P-256 also known as secp256r1 | | | | | | | P-384 | EC2 | 2 | NIST P-384 also known as secp384r1 | | | | | | | P-521 | EC2 | 3 | NIST P-521 also known as secp521r1 | | | | | | | X25519 | OKP | 4 | X25519 for use w/ ECDH only | | | | | | | X448 | OKP | 5 | X448 for use w/ ECDH only | | | | | | | Ed25519 | OKP | 6 | Ed25519 for use w/ EdDSA only | | | | | | | Ed448 | OKP | 7 | Ed448 for use w/ EdDSA only | +---------+----------+-------+------------------------------------+ Table 22: EC Curves 13.1.1. Double Coordinate Curves The traditional way of sending EC curves has been to send either both the x and y coordinates, or the x coordinate and a sign bit for the y coordinate. The latter encoding has not been recommended in the IETF due to potential IPR issues. However, for operations in constrained environments, the ability to shrink a message by not sending the y coordinate is potentially useful. For EC keys with both coordinates, the 'kty' member is set to 2 (EC2). The key parameters defined in this section are summarized in Table 23. The members that are defined for this key type are: crv contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found Schaad Expires May 26, 2017 [Page 72] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 in Table 22. Other curves may be registered in the future and private curves can be used as well. x contains the x coordinate for the EC point. The integer is converted to an octet string as defined in [SEC1]. Leading zero octets MUST be preserved. y contains either the sign bit or the value of y coordinate for the EC point. When encoding the value y, the integer is converted to an octet string (as defined in [SEC1]) and encoded as a CBOR bstr. Leading zero octets MUST be preserved. The compressed point encoding is also supported. Compute the sign bit as laid out in the Elliptic-Curve-Point-to-Octet-String Conversion function of [SEC1]. If the sign bit is zero, then encode y as a CBOR false value, otherwise encode y as a CBOR true value. The encoding of the infinity point is not supported. d contains the private key. For public keys, it is REQUIRED that 'crv', 'x' and 'y' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' and 'y' also be present, but they can be recomputed from the required elements and omitting them saves on space. +------+-------+-------+---------+----------------------------------+ | name | key | label | type | description | | | type | | | | +------+-------+-------+---------+----------------------------------+ | crv | 2 | -1 | int / | EC Curve identifier - Taken from | | | | | tstr | the COSE Curves registry | | | | | | | | x | 2 | -2 | bstr | X Coordinate | | | | | | | | y | 2 | -3 | bstr / | Y Coordinate | | | | | bool | | | | | | | | | d | 2 | -4 | bstr | Private key | +------+-------+-------+---------+----------------------------------+ Table 23: EC Key Parameters 13.2. Octet Key Pair A new key type is defined for Octet Key Pairs (OKP). Do not assume that keys using this type are elliptic curves. This key type could be used for other curve types (for example, mathematics based on hyper-elliptic surfaces). Schaad Expires May 26, 2017 [Page 73] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 The key parameters defined in this section are summarized in Table 24. The members that are defined for this key type are: crv contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in Table 22. Other curves may be registered in the future and private curves can be used as well. x contains the x coordinate for the EC point. The octet string represents a little-endian encoding of x. d contains the private key. For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space. +------+------+-------+-------+-------------------------------------+ | name | key | label | type | description | | | type | | | | +------+------+-------+-------+-------------------------------------+ | crv | 1 | -1 | int / | EC Curve identifier - Taken from | | | | | tstr | the COSE Key Common Parameters | | | | | | registry | | | | | | | | x | 1 | -2 | bstr | X Coordinate | | | | | | | | d | 1 | -4 | bstr | Private key | +------+------+-------+-------+-------------------------------------+ Table 24: Octet Key Pair Parameters 13.3. Symmetric Keys Occasionally it is required that a symmetric key be transported between entities. This key structure allows for that to happen. For symmetric keys, the 'kty' member is set to 3 (Symmetric). The member that is defined for this key type is: k contains the value of the key. This key structure does not have a form that contains only public members. As it is expected that this key structure is going to be transmitted, care must be taking that it is never transmitted Schaad Expires May 26, 2017 [Page 74] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 accidentally or insecurely. For symmetric keys, it is REQUIRED that 'k' be present in the structure. +------+----------+-------+------+-------------+ | name | key type | label | type | description | +------+----------+-------+------+-------------+ | k | 4 | -1 | bstr | Key Value | +------+----------+-------+------+-------------+ Table 25: Symmetric Key Parameters 14. CBOR Encoder Restrictions There has been an attempt to limit the number of places where the document needs to impose restrictions on how the CBOR Encoder needs to work. We have managed to narrow it down to the following restrictions: o The restriction applies to the encoding the Sig_structure, the Enc_structure, and the MAC_structure. o The rules for Canonical CBOR (Section 3.9 of RFC 7049) MUST be used in these locations. The main rule that needs to be enforced is that all lengths in these structures MUST be encoded such that they are encoded using definite lengths and the minimum length encoding is used. o Applications MUST NOT generate messages with the same label used twice as a key in a single map. Applications MUST NOT parse and process messages with the same label used twice as a key in a single map. Applications can enforce the parse and process requirement by using parsers that will fail the parse step or by using parsers that will pass all keys to the application and the application can perform the check for duplicate keys. 15. Application Profiling Considerations This document is designed to provide a set of security services, but not to provide implementation requirements for specific usage. The interoperability requirements are provided for how each of the individual services are used and how the algorithms are to be used for interoperability. The requirements about which algorithms and which services are needed are deferred to each application. An example of a profile can be found in [I-D.selander-ace-object-security] where two profiles are being developed. One is for carrying content by itself, and the other is for carrying content in combination with CoAP headers. Schaad Expires May 26, 2017 [Page 75] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 It is intended that a profile of this document be created that defines the interoperability requirements for that specific application. This section provides a set of guidelines and topics that need to be considered when profiling this document. o Applications need to determine the set of messages defined in this document that they will be using. The set of messages corresponds fairly directly to the set of security services that are needed and to the security levels needed. o Applications may define new header parameters for a specific purpose. Applications will often times select specific header parameters to use or not to use. For example, an application would normally state a preference for using either the IV or the partial IV parameter. If the partial IV parameter is specified, then the application would also need to define how the fixed portion of the IV would be determined. o When applications use externally defined authenticated data, they need to define how that data is encoded. This document assumes that the data will be provided as a byte stream. More information can be found in Section 4.3. o Applications need to determine the set of security algorithms that are to be used. When selecting the algorithms to be used as the mandatory to implement set, consideration should be given to choosing different types of algorithms when two are chosen for a specific purpose. An example of this would be choosing HMAC- SHA512 and AES-CMAC as different MAC algorithms; the construction is vastly different between these two algorithms. This means that a weakening of one algorithm would be unlikely to lead to a weakening of the other algorithms. Of course, these algorithms do not provide the same level of security and thus may not be comparable for the desired security functionality. o Applications may need to provide some type of negotiation or discovery method if multiple algorithms or message structures are permitted. The method can be as simple as requiring preconfiguration of the set of algorithms to providing a discovery method built into the protocol. S/MIME provided a number of different ways to approach the problem that applications could follow: * Advertising in the message (S/MIME capabilities) [RFC5751]. * Advertising in the certificate (capabilities extension) [RFC4262]. Schaad Expires May 26, 2017 [Page 76] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 * Minimum requirements for the S/MIME, which have been updated over time [RFC2633][RFC5751]. 16. IANA Considerations 16.1. CBOR Tag assignment It is requested that IANA assign the following tags from the "CBOR Tags" registry. It is requested that the tags for COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 be assigned in the 1 to 23 value range (one byte long when encoded). It is requested that the tags for COSE_Sign, COSE_Encrypt and COSE_MAC be assigned in the 24 to 255 value range (two bytes long when encoded). The tags to be assigned are in Table 1. 16.2. COSE Header Parameters Registry It is requested that IANA create a new registry entitled "COSE Header Parameters". The registry should be created as Expert Review Required. Guidelines for the experts is provided Section 16.11. It should be noted that in additional to the expert review, some portions of the registry require a specification, potentially on standards track, be supplied as well. The columns of the registry are: name The name is present to make it easier to refer to and discuss the registration entry. The value is not used in the protocol. Names are to be unique in the table. label This is the value used for the label. The label can be either an integer or a string. Registration in the table is based on the value of the label requested. Integer values between 1 and 255 and strings of length 1 are designated as Standards Track Document required. Integer values from 256 to 65535 and strings of length 2 are designated as Specification Required. Integer values of greater than 65535 and strings of length greater than 2 are designated as expert review. Integer values in the range -1 to -65536 are delegated to the "COSE Header Algorithm Parameters" registry. Integer values less than -65536 are marked as private use. value This contains the CBOR type for the value portion of the label. value registry This contains a pointer to the registry used to contain values where the set is limited. Schaad Expires May 26, 2017 [Page 77] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 description This contains a brief description of the header field. specification This contains a pointer to the specification defining the header field (where public). The initial contents of the registry can be found in Table 2 and Table 27. The specification column for all rows in that table should be this document. Additionally, the label of 0 is to be marked as 'Reserved'. 16.3. COSE Header Algorithm Parameters Registry It is requested that IANA create a new registry entitled "COSE Header Algorithm Parameters". The registry is to be created as Expert Review Required. Expert review guidelines are provided in Section 16.11. The columns of the registry are: name The name is present to make it easier to refer to and discuss the registration entry. The value is not used in the protocol. algorithm The algorithm(s) that this registry entry is used for. This value is taken from the "COSE Algorithm Values" registry. Multiple algorithms can be specified in this entry. For the table, the algorithm, label pair MUST be unique. label This is the value used for the label. The label is an integer in the range of -1 to -65536. value This contains the CBOR type for the value portion of the label. description This contains a brief description of the header field. specification This contains a pointer to the specification defining the header field (where public). The initial contents of the registry can be found in Table 13, Table 14, and Table 19. The specification column for all rows in that table should be this document. 16.4. COSE Algorithms Registry It is requested that IANA create a new registry entitled "COSE Algorithms Registry". The registry is to be created as Expert Review Required. Guidelines for the experts is provided Section 16.11. It Schaad Expires May 26, 2017 [Page 78] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 should be noted that in additional to the expert review, some portions of the registry require a specification, potentially on standards track, be supplied as well. The columns of the registry are: value: The value to be used to identify this algorithm. Algorithm values MUST be unique. The value can be a positive integer, a negative integer or a string. Integer values between -256 and 255 and strings of length 1 are designated as Standards Track Document required. Integer values from -65536 to 65535 and strings of length 2 are designated as Specification Required. Integer values of greater than 65535 and strings of length greater than 2 are designated as expert review. Integer values less than -65536 are marked as private use. description: A short description of the algorithm. specification: A document where the algorithm is defined (if publicly available). recommended: Does the IETF have a concensus recommendation to use the algorithm. The legal values are 'yes', 'no' and 'deprecated'. The initial contents of the registry can be found in Table 10, Table 9, Table 11, Table 5, Table 7, Table 8, Table 15, Table 16, Table 17, Table 6, Table 20 and Table 18. The specification column for all rows in the table should be this document. The recommneded column for all rows in the table are set to 'yes'. Additionally, the label of 0 is to be marked as 'Reserved'. NOTE: The assignment of algorithm identifiers in this document was done so that positive numbers were used for the first layer objects (COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and COSE_Mac0). Negative numbers were used for second layer objects (COSE_Signature and COSE_recipient). Expert reviewers should consider this practice, but are not expected to be restricted by this precedent. 16.5. COSE Key Common Parameters Registry It is requested that IANA create a new registry entitled "COSE Key Common Parameters" registry. The registry is to be created as Expert Review Required. Guidelines for the experts is provided Section 16.11. It should be noted that in additional to the expert review, some portions of the registry require a specification, potentially on standards track, be supplied as well. Schaad Expires May 26, 2017 [Page 79] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 The columns of the registry are: name This is a descriptive name that enables easier reference to the item. It is not used in the encoding. label The value to be used to identify this algorithm. Key map labels MUST be unique. The label can be a positive integer, a negative integer or a string. Integer values between 0 and 255 and strings of length 1 are designated as Standards Track Document required. Integer values from 256 to 65535 and strings of length 2 are designated as Specification Required. Integer values of greater than 65535 and strings of length greater than 2 are designated as expert review. Integer values in the range -1 to -65536 are used for key parameters specific to a single algorithm delegated to the "COSE Key Type Parameter Labels" registry. Integer values less than -65536 are marked as private use. CBOR Type This field contains the CBOR type for the field. registry This field denotes the registry that values come from, if one exists. description This field contains a brief description for the field. specification This contains a pointer to the public specification for the field if one exists This registry will be initially populated by the values in Table 3. The specification column for all of these entries will be this document. 16.6. COSE Key Type Parameters Registry It is requested that IANA create a new registry "COSE Key Type Parameters". The registry is to be created as Expert Review Required. Expert review guidelines are provided in Section 16.11. The columns of the table are: key type This field contains a descriptive string of a key type. This should be a value that is in the COSE Key Common Parameters table and is placed in the 'kty' field of a COSE Key structure. name This is a descriptive name that enables easier reference to the item. It is not used in the encoding. Schaad Expires May 26, 2017 [Page 80] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 label The label is to be unique for every value of key type. The range of values is from -256 to -1. Labels are expected to be reused for different keys. CBOR type This field contains the CBOR type for the field. description This field contains a brief description for the field. specification This contains a pointer to the public specification for the field if one exists. This registry will be initially populated by the values in Table 23, Table 24, and Table 25. The specification column for all of these entries will be this document. 16.7. COSE Key Type Registry It is requested that IANA create a new registry "COSE Key Type Registry". The registry is to be created as Expert Review Required. Expert review guidelines are provided in Section 16.11. The columns of this table are: name This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. value This is the value used to identify the curve. These values MUST be unique. The value can be a positive integer, a negative integer or a string. description This field contains a brief description of the curve. specification This contains a pointer to the public specification for the curve if one exists. This registry will be initially populated by the values in Table 21. The specification column for all of these entries will be this document. 16.8. COSE Elliptic Curve Parameters Registry It is requested that IANA create a new registry "COSE Elliptic Curve Parameters". The registry is to be created as Expert Review Required. Guidelines for the experts is provided Section 16.11. It should be noted that in additional to the expert review, some portions of the registry require a specification, potentially on standards track, be supplied as well. Schaad Expires May 26, 2017 [Page 81] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 The columns of the table are: name This is a descriptive name that enables easier reference to the item. It is not used in the encoding. value This is the value used to identify the curve. These values MUST be unique. The integer values from -256 to 255 are designated as Standards Track Document Required. The integer values from 256 to 65535 and -65536 to -257 are designated as Specification Required. Integer values over 65535 are designated as expert review. Integer values less than -65536 are marked as private use. key type This designates the key type(s) that can be used with this curve. description This field contains a brief description of the curve. specification This contains a pointer to the public specification for the curve if one exists. recommended: Does the IETF have a concensus recommendation to use the algorithm. The legal values are 'yes', 'no' and 'deprecated'. This registry will be initially populated by the values in Table 22. The specification column for all of these entries will be this document. The recommended column for all of the inital entries will be 'yes'. 16.9. Media Type Registrations 16.9.1. COSE Security Message This section registers the "application/cose" media type in the "Media Types" registry. These media types are used to indicate that the content is a COSE message. Type name: application Subtype name: cose Required parameters: N/A Optional parameters: cose-type Encoding considerations: binary Schaad Expires May 26, 2017 [Page 82] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Security considerations: See the Security Considerations section of RFC TBD. Interoperability considerations: N/A Published specification: RFC TBD Applications that use this media type: IoT applications sending security content over HTTP(S) transports. Fragment identifier considerations: N/A Additional information: * Magic number(s): N/A * File extension(s): cbor * Macintosh file type code(s): N/A Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: Jim Schaad, ietf@augustcellars.com Change Controller: IESG Provisional registration? No 16.9.2. COSE Key media type This section registers the "application/cose-key" and "application/ cose-key-set" media types in the "Media Types" registry. These media types are used to indicate, respectively, that content is a COSE_Key or COSE_KeySet object. The template for registering "application/cose-key" is: Type name: application Subtype name: cose-key Required parameters: N/A Schaad Expires May 26, 2017 [Page 83] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Optional parameters: N/A Encoding considerations: binary Security considerations: See the Security Considerations section of RFC TBD. Interoperability considerations: N/A Published specification: RFC TBD Applications that use this media type: Distribution of COSE based keys for IoT applications. Fragment identifier considerations: N/A Additional information: * Magic number(s): N/A * File extension(s): cbor * Macintosh file type code(s): N/A Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: Jim Schaad, ietf@augustcellars.com Change Controller: IESG Provisional registration? No The template for registering "application/cose-key-set" is: Type name: application Subtype name: cose-key-set Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Schaad Expires May 26, 2017 [Page 84] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Security considerations: See the Security Considerations section of RFC TBD. Interoperability considerations: N/A Published specification: RFC TBD Applications that use this media type: Distribution of COSE based keys for IoT applications. Fragment identifier considerations: N/A Additional information: * Magic number(s): N/A * File extension(s): cbor * Macintosh file type code(s): N/A Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: Jim Schaad, ietf@augustcellars.com Change Controller: IESG Provisional registration? No 16.10. CoAP Content-Format Registrations IANA is requested to add the following entries to the "CoAP Content- Format" registry. ID assignment in the 24-255 range is requested. Schaad Expires May 26, 2017 [Page 85] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 +---------------------------------+----------+-------+--------------+ | Media Type | Encoding | ID | Reference | +---------------------------------+----------+-------+--------------+ | application/cose; cose-type | | TBD10 | [This | | ="cose-sign" | | | Document] | | | | | | | application/cose; cose-type | | TBD11 | [This | | ="cose-sign1" | | | Document] | | | | | | | application/cose; cose-type | | TBD12 | [This | | ="cose-encrypt" | | | Document] | | | | | | | application/cose; cose-type | | TBD13 | [This | | ="cose-encrypt0" | | | Document] | | | | | | | application/cose; cose-type | | TBD14 | [This | | ="cose-mac" | | | Document] | | | | | | | application/cose; cose-type | | TBD15 | [This | | ="cose-mac0" | | | Document] | | | | | | | application/cose-key | | TBD16 | [This | | | | | Document] | | | | | | | application/cose-key-set | | TBD17 | [This | | | | | Document | +---------------------------------+----------+-------+--------------+ Table 26 16.11. Expert Review Instructions All of the IANA registries established in this document are defined as expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points: o Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing. Schaad Expires May 26, 2017 [Page 86] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. o Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. o When algorithms are registered, vanity registrations should be discouraged. One way to do this is to require registrations to provide additional documentation on security analysis of the algorithm. Another thing that should be considered is to request for an opinion on the algorithm from the Crypto Forum Research Group (CFRG). Algorithms that do not meet the security requirements of the community and the messages structures should not be registered. 17. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. Schaad Expires May 26, 2017 [Page 87] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 It is up to the individual working groups to use this information as they see fit". 17.1. Author's Versions There are three different implementations that have been created by the author of the document both to create the examples that are included in the document and to validate the structures and methodology used in the design of COSE. Implementation Location: https://github.com/cose-wg Primary Maintainer: Jim Schaad Languages: There are three different languages that are currently supported: Java, C# and C. Cryptography: The Java and C# libraries use Bouncy Castle to provide the required cryptography. The C version uses OPENSSL Version 1.0 for the cryptography. Coverage: The libraries currently do not have full support for counter signatures of either variety. They do have support to allow for implicit algorithm support as they allow for the application to set attributes that are not to be sent in the message. Testing: All of the examples in the example library are generated by the C# library and then validated using the Java and C libraries. All three libraries have tests to allow for the creating of the same messages that are in the example library followed by validating them. These are not compared against the example library. The Java and C# libraries have unit testing included. Not all of the MUST statements in the document have been implemented as part of the libraries. One such statement is the requirement that unique labels be present. Licensing: Revised BSD License 17.2. COSE Testing Library Implementation Location: https://github.com/cose-wg/Examples Primary Maintainer: Jim Schaad Description: A set of tests for the COSE library is provided as part of the implementation effort. Both success and fail tests Schaad Expires May 26, 2017 [Page 88] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 have been provided. All of the examples in this document are part of this example set. Coverage: An attempt has been made to have test cases for every message type and algorithm in the document. Currently examples dealing with counter signatures, EdDSA, and ECDH with Curve24459 and Goldilocks are missing. Licensing: Public Domain 18. Security Considerations There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some considerations have been highlighted here, additional considerations may be found in the documents listed in the references. Implementations need to protect the private key material for any individuals. There are some cases in this document that need to be highlighted on this issue. o Using the same key for two different algorithms can leak information about the key. It is therefore recommended that keys be restricted to a single algorithm. o Use of 'direct' as a recipient algorithm combined with a second recipient algorithm, exposes the direct key to the second recipient. o Several of the algorithms in this document have limits on the number of times that a key can be used without leaking information about the key. The use of ECDH and direct plus KDF (with no key wrap) will not directly lead to the private key being leaked; the one way function of the KDF will prevent that. There is however, a different issue that needs to be addressed. Having two recipients requires that the CEK be shared between two recipients. The second recipient therefore has a CEK that was derived from material that can be used for the weak proof of origin. The second recipient could create a message using the same CEK and send it to the first recipient, the first recipient would, for either static-static ECDH or direct plus KDF, make an assumption that the CEK could be used for proof of origin even though it is from the wrong entity. If the key wrap step is added, then no proof of origin is implied and this is not an issue. Schaad Expires May 26, 2017 [Page 89] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Although it has been mentioned before, the use of a single key for multiple algorithms has been demonstrated in some cases to leak information about a key, provide for attackers to forge integrity tags, or gain information about encrypted content. Binding a key to a single algorithm prevents these problems. Key creators and key consumers are strongly encouraged not only to create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure. In addition to checking that algorithms are correct, the key form needs to be checked as well. Do not use an 'EC2' key where an 'OKP' key is expected. Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made. Is the data or action something that the entity associated with the key has a right to see or a right to request? A number of factors are associated with this trust decision. Some of the ones that are highlighted here are: o What are the permissions associated with the key owner? o Is the cryptographic algorithm acceptable in the current context? o Have the restrictions associated with the key, such as algorithm or freshness, been checked and are correct? o Is the request something that is reasonable, given the current state of the application? o Have any security considerations that are part of the message been enforced (as specified by the application or 'crit' parameter)? There are a large number of algorithms presented in this document that use nonce values. For all of the nonces defined in this document, there is some type of restriction on the nonce being a unique value either for a key or for some other conditions. In all of these cases, there is no known requirement on the nonce being both unique and unpredictable, under these circumstances it reasonable to use a counter for creation of the nonce. In cases where one wants the pattern of the nonce to be unpredictable as well as unique, one can use a key created for that purpose and encrypt the counter to produce the nonce value. One area that has been starting to get exposure is doing traffic analysis of encrypted messages based on the length of the message. This specification does not provide for a uniform method of providing padding as part of the message structure. An observer can Schaad Expires May 26, 2017 [Page 90] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 distinguish between two different strings (for example, 'YES' and 'NO') based on length for all of the content encryption algorithms that are defined in this document. This means that it is up to applications to document how content padding is to be done in order to prevent or discourage such analysis. (For example, the strings could be defined as 'YES' and 'NO '.) 19. References 19.1. Normative References [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.", Nov 2007. [COAP.Formats] IANA, , "CoAP Content-Formats". [DSS] U.S. National Institute of Standards and Technology, "Digital Signature Standard (DSS)", July 2013. [I-D.irtf-cfrg-eddsa] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 (work in progress), August 2016. [MAC] NiST, N., "FIPS PUB 113: Computer Data Authentication", May 1985. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, . [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, . Schaad Expires May 26, 2017 [Page 91] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", May 2009. 19.2. Informative References [I-D.greevenbosch-appsawg-cbor-cddl] Vigano, C. and H. Birkholz, "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work in progress), September 2016. [I-D.moriarty-pkcs1] Moriarty, K., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1 Version 2.2: RSA Cryptography Specifications", draft-moriarty-pkcs1-03 (work in progress), September 2016. Schaad Expires May 26, 2017 [Page 92] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 [I-D.moriarty-pkcs5-v2dot1] Moriarty, K., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", draft-moriarty-pkcs5-v2dot1-04 (work in progress), September 2016. [I-D.selander-ace-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)", draft-selander-ace- object-security-06 (work in progress), October 2016. [PVSig] Brown, D. and D. Johnson, "Formal Security Proofs for a Signature Scheme with Partial Message Recover", February 2000. [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, . [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . [RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 2005, . [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . Schaad Expires May 26, 2017 [Page 93] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in Cryptographic Message Syntax (CMS)", RFC 5752, DOI 10.17487/RFC5752, January 2010, . [RFC5990] Randall, J., Kaliski, B., Brainard, J., and S. Turner, "Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 5990, DOI 10.17487/RFC5990, September 2010, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . Schaad Expires May 26, 2017 [Page 94] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [SP800-56A] Barker, E., Chen, L., Roginsky, A., and M. Smid, "NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", May 2013. [W3C.WebCrypto] Watson, M., "Web Cryptography API", July 2016. Appendix A. Guidelines for External Data Authentication of Algorithms There has been a portion of the working group who have expressed a strong desire to relax the rule that the algorithm identifier be required to appear in each level of a COSE object. There are two basic reasons that have been advanced to support this position. First, the resulting message will be smaller if the algorithm identifier is omitted from the most common messages in a CoAP environment. Second, there is a potential bug that will arise if full checking is not done correctly between the different places that an algorithm identifier could be placed (the message itself, an application statement, the key structure that the sender possesses and the key structure the recipient possesses). This appendix lays out how such a change can be made and the details that an application needs to specify in order to use this option. Two different sets of details are specified: Those needed to omit an algorithm identifier and those needed to use a variant on the counter signature attribute that contains no attributes about itself. A.1. Algorithm Identification In this section are laid out three sets of recommendations. The first set of recommendations apply to having an implicit algorithm identified for a single layer of a COSE object. The second set of recommendations apply to having multiple implicit algorithms Schaad Expires May 26, 2017 [Page 95] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 identified for multiple layers of a COSE object. The third set of recommendations apply to having implicit algorithms for multiple COSE object constructs. RFC 2119 language is deliberately not used here. This specification can provide recommendations, but it cannot enforce them. This set of recommendations applies to the case where an application is distributing a fixed algorithm along with the key information for use in a single COSE object. This normally applies to the smallest of the COSE objects, specifically COSE_Sign1, COSE_Mac0, and COSE_Encrypt0, but could apply to the other structures as well. The following items should be taken into account: o Applications need to list the set of COSE structures that implicit algorithms are to be used in. Applications need to require that the receipt of an explicit algorithm identifier in one of these structures will lead to the message being rejected. This requirement is stated so that there will never be a case where there is any ambiguity about the question of which algorithm should be used, the implicit or the explicit one. This applies even if the transported algorithm identifier is a protected attribute. This applies even if the transported algorithm is the same as the implicit algorithm. o Applications need to define the set of information that is to be considered to be part of a context when omitting algorithm identifiers. At a minimum, this would be the key identifier (if needed), the key, the algorithm, and the COSE structure it is used with. Applications should restrict the use of a single key to a single algorithm. As noted for some of the algorithms in this document, the use of the same key in different related algorithms can lead to leakage of information about the key, leakage about the data or the ability to perform forgeries. o In many cases, applications that make the algorithm identifier implicit will also want to make the context identifier implicit for the same reason. That is, omitting the context identifier will decrease the message size (potentially significantly depending on the length of the identifier). Applications that do this will need to describe the circumstances where the context identifier is to be omitted and how the context identifier is to be inferred in these cases. (Exhaustive search over all of the keys would normally not be considered to be acceptable.) An example of how this can be done is to tie the context to a transaction identifier. Both would be sent on the original message, but only the transaction identifier would need to be sent Schaad Expires May 26, 2017 [Page 96] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 after that point as the context is tied into the transaction identifier. Another way would be to associate a context with a network address. All messages coming from a single network address can be assumed to be associated with a specific context. (In this case the address would normally be distributed as part of the context.) o Applications cannot rely on key identifiers being unique unless they take significant efforts to ensure that they are computed in such a way as to create this guarantee. Even when an application does this, the uniqueness might be violated if the application is run in different contexts (i.e., with a different context provider) or if the system combines the security contexts from different applications together into a single store. o Applications should continue the practice of protecting the algorithm identifier. Since this is not done by placing it in the protected attributes field, applications should define an application specific external data structure that includes this value. This external data field can be used as such for content encryption, MAC, and signature algorithms. It can be used in the SuppPrivInfo field for those algorithms which use a KDF function to derive a key value. Applications may also want to protect other information that is part of the context structure as well. It should be noted that those fields, such as the key or a base IV, are protected by virtue of being used in the cryptographic computation and do not need to be included in the external data field. The second case is having multiple implicit algorithm identifiers specified for a multiple layer COSE object. An example of how this would work is the encryption context that an application specifies contains a content encryption algorithm, a key wrap algorithm, a key identifier, and a shared secret. The sender omits sending the algorithm identifier for both the content layer and the recipient layer leaving only the key identifier. The receiver then uses the key identifier to get the implicit algorithm identifiers. The following additional items need to be taken into consideration: o Applications that want to support this will need to define a structure that allows for, and clearly identifies, both the COSE structure to be used with a given key and the structure and algorithm to be used for the secondary layer. The key for the secondary layer is computed per normal from the recipient layer. The third case is having multiple implicit algorithm identifiers, but targeted at potentially unrelated layers or different COSE objects. Schaad Expires May 26, 2017 [Page 97] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 There are a number of different scenarios where this might be applicable. Some of these scenarios are: o Two contexts are distributed as a pair. Each of the contexts is for use with a COSE_Encrypt message. Each context will consist of distinct secret keys and IVs and potentially even different algorithms. One context is for sending messages from party A to party B, the second context is for sending messages from party B to party A. This means that there is no chance for a reflection attack to occur as each party uses different secret keys to send its messages, a message that is reflected back to it would fail to decrypt. o Two contexts are distributed as a pair. The first context is used for encryption of the message; the second context is used to place a counter signature on the message. The intention is that the second context can be distributed to other entities independently of the first context. This allows these entities to validate that the message came from an individual without being able to decrypt the message and see the content. o Two contexts are distributed as a pair. The first context contains a key for dealing with MACed messages, the second context contains a key for dealing with encrypted messages. This allows for a unified distribution of keys to participants for different types of messages that have different keys, but where the keys may be used in coordinated manner. For these cases, the following additional items need to be considered: o Applications need to ensure that the multiple contexts stay associated. If one of the contexts is invalidated for any reason, all of the contexts associated with it should also be invalidated. A.2. Counter Signature Without Headers There is a group of people who want to have a counter signature parameter that is directly tied to the value being signed and thus the authenticated and unauthenticated buckets can be removed from the message being sent. The focus on this is an even smaller size, as all of the information on the process of creating the counter signature is implicit rather than being explicitly carried in the message. This includes not only the algorithm identifier as presented above, but also items such as the key identification is always external to the signature structure. This means that the entities that are doing the validation of the counter signature are required to infer which key is to be used from context rather than Schaad Expires May 26, 2017 [Page 98] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 being explicit. One way of doing this would be to presume that all data coming from a specific port (or to a specific URL) is to be validated by a specific key. (Note that this does not require that the key identifier be part of the value signed as it does not serve a cryptographic purpose. If the key validates the counter signature, then it should be presumed that the entity associated with that key produced the signature.) When computing the signature for the bare counter signature header, the same Sig_structure defined in Section 4.4 is used. The sign_protected field is omitted, as there is no protected header field in in this counter signature header. The value of "CounterSignature0" is placed in the context field of the Sig_stucture. +-------------------+-------+-------+-------+-----------------------+ | name | label | value | value | description | | | | type | | | +-------------------+-------+-------+-------+-----------------------+ | CounterSignature0 | 9 | bstr | | Counter signature | | | | | | with implied signer | | | | | | and headers | +-------------------+-------+-------+-------+-----------------------+ Table 27 Appendix B. Two Layers of Recipient Information All of the currently defined recipient algorithms classes only use two layers of the COSE_Encrypt structure. The first layer is the message content and the second layer is the content key encryption. However, if one uses a recipient algorithm such as RSA-KEM (see Appendix A of RSA-KEM [RFC5990]), then it makes sense to have three layers of the COSE_Encrypt structure. These layers would be: o Layer 0: The content encryption layer. This layer contains the payload of the message. o Layer 1: The encryption of the CEK by a KEK. o Layer 2: The encryption of a long random secret using an RSA key and a key derivation function to convert that secret into the KEK. This is an example of what a triple layer message would look like. The message has the following layers: Schaad Expires May 26, 2017 [Page 99] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Layer 0: Has a content encrypted with AES-GCM using a 128-bit key. o Layer 1: Uses the AES Key wrap algorithm with a 128-bit key. o Layer 2: Uses ECDH Ephemeral-Static direct to generate the layer 1 key. In effect, this example is a decomposed version of using the ECDH- ES+A128KW algorithm. Size of binary file is 183 bytes Schaad Expires May 26, 2017 [Page 100] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 96( [ / protected / h'a10101' / { \ alg \ 1:1 \ AES-GCM 128 \ } / , / unprotected / { / iv / 5:h'02d1f7e6f26c43d4868d87ce' }, / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e2852948658f0 811139868826e89218a75715b', / recipients / [ [ / protected / h'', / unprotected / { / alg / 1:-3 / A128KW / }, / ciphertext / h'dbd43c4e9d719c27c6275c67d628d493f090593db82 18f11', / recipients / [ [ / protected / h'a1013818' / { \ alg \ 1:-25 \ ECDH-ES + HKDF-256 \ } / , / unprotected / { / ephemeral / -1:{ / kty / 1:2, / crv / -1:1, / x / -2:h'b2add44368ea6d641f9ca9af308b4079aeb519f11 e9b8a55a600b21233e86e68', / y / -3:false }, / kid / 4:'meriadoc.brandybuck@buckland.example' }, / ciphertext / h'' ] ] ] ] ] ) Appendix C. Examples This appendix includes a set of examples that show the different features and message types that have been defined in this document. To make the examples easier to read, they are presented using the extended CBOR diagnostic notation (defined in [I-D.greevenbosch-appsawg-cbor-cddl]) rather than as a binary dump. Schaad Expires May 26, 2017 [Page 101] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 A GitHub project has been created at https://github.com/cose-wg/ Examples that contains not only the examples presented in this document, but a more complete set of testing examples as well. Each example is found in a JSON file that contains the inputs used to create the example, some of the intermediate values that can be used in debugging the example and the output of the example presented in both a hex and a CBOR diagnostic notation format. Some of the examples at the site are designed failure testing cases; these are clearly marked as such in the JSON file. If errors in the examples in this document are found, the examples on github will be updated and a note to that effect will be placed in the JSON file. As noted, the examples are presented using the CBOR's diagnostic notation. A Ruby based tool exists that can convert between the diagnostic notation and binary. This tool can be installed with the command line: gem install cbor-diag The diagnostic notation can be converted into binary files using the following command line: diag2cbor.rb < inputfile > outputfile The examples can be extracted from the XML version of this document via an XPath expression as all of the artwork is tagged with the attribute type='CBORdiag'. (Depending on the XPath evaluator one is using, it may be necessary to deal with > as an entity.) //artwork[@type='CDDL']/text() C.1. Examples of Signed Message C.1.1. Single Signature This example uses the following: o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 Size of binary file is 103 bytes Schaad Expires May 26, 2017 [Page 102] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 98( [ / protected / h'', / unprotected / {}, / payload / 'This is the content.', / signatures / [ [ / protected / h'a10126' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb 5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b 98f53afd2fa0f30a' ] ] ] ) C.1.2. Multiple Signers This example uses the following: o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 o Signature Algorithm: ECDSA w/ SHA-512, Curve P-521 Size of binary file is 277 bytes Schaad Expires May 26, 2017 [Page 103] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 98( [ / protected / h'', / unprotected / {}, / payload / 'This is the content.', / signatures / [ [ / protected / h'a10126' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb 5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b 98f53afd2fa0f30a' ], [ / protected / h'a1013823' / { \ alg \ 1:-36 } / , / unprotected / { / kid / 4:'bilbo.baggins@hobbiton.example' }, / signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1 de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024 7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030 c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f 83ab87bb4f7a0297' ] ] ] ) C.1.3. Counter Signature This example uses the following: o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 o The same parameters are used for both the signature and the counter signature. Size of binary file is 180 bytes Schaad Expires May 26, 2017 [Page 104] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 98( [ / protected / h'', / unprotected / { / countersign / 7:[ / protected / h'a10126' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4 9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e 8802bb6650cceb2c' ] }, / payload / 'This is the content.', / signatures / [ [ / protected / h'a10126' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb 5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b 98f53afd2fa0f30a' ] ] ] ) C.1.4. Signature w/ Criticality This example uses the following: o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 o There is a criticality marker on the "reserved" header parameter Size of binary file is 125 bytes Schaad Expires May 26, 2017 [Page 105] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 98( [ / protected / h'a2687265736572766564f40281687265736572766564' / { "reserved":false, \ crit \ 2:[ "reserved" ] } / , / unprotected / {}, / payload / 'This is the content.', / signatures / [ [ / protected / h'a10126' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / signature / h'3fc54702aa56e1b2cb20284294c9106a63f91bac658d 69351210a031d8fc7c5ff3e4be39445b1a3e83e1510d1aca2f2e8a7c081c7645042b 18aba9d1fad1bd9c' ] ] ] ) C.2. Single Signer Examples C.2.1. Single ECDSA signature This example uses the following: o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 Size of binary file is 98 bytes Schaad Expires May 26, 2017 [Page 106] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 18( [ / protected / h'a10126' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / payload / 'This is the content.', / signature / h'eae868ecc176883766c5dc5ba5b8dca25dab3c2e56a551ce 5705b793914348e19f43d6c6ba654472da301b645b293c9ba939295b97c4bdb84778 2bff384c5794' ] ) C.3. Examples of Enveloped Messages C.3.1. Direct ECDH This example uses the following: o CEK: AES-GCM w/ 128-bit key o Recipient class: ECDH Ephemeral-Static, Curve P-256 Size of binary file is 151 bytes Schaad Expires May 26, 2017 [Page 107] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 96( [ / protected / h'a10101' / { \ alg \ 1:1 \ AES-GCM 128 \ } / , / unprotected / { / iv / 5:h'c9cf4df2fe6c632bf7886413' }, / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0 c52a357da7a644b8070a151b0', / recipients / [ [ / protected / h'a1013818' / { \ alg \ 1:-25 \ ECDH-ES + HKDF-256 \ } / , / unprotected / { / ephemeral / -1:{ / kty / 1:2, / crv / -1:1, / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf bf054e1c7b4d91d6280', / y / -3:true }, / kid / 4:'meriadoc.brandybuck@buckland.example' }, / ciphertext / h'' ] ] ] ) C.3.2. Direct plus Key Derivation This example uses the following: o CEK: AES-CCM w/128-bit key, truncate the tag to 64 bits o Recipient class: Use HKDF on a shared secret with the following implicit fields as part of the context. * salt: "aabbccddeeffgghh" * APU identity: "lighting-client" * APV identity: "lighting-server" * Supplementary Public Other: "Encryption Example 02" Schaad Expires May 26, 2017 [Page 108] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Size of binary file is 91 bytes 96( [ / protected / h'a1010a' / { \ alg \ 1:10 \ AES-CCM-16-64-128 \ } / , / unprotected / { / iv / 5:h'89f52f65a1c580933b5261a76c' }, / ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93 1b687b847', / recipients / [ [ / protected / h'a10129' / { \ alg \ 1:-10 } / , / unprotected / { / salt / -20:'aabbccddeeffgghh', / kid / 4:'our-secret' }, / ciphertext / h'' ] ] ] ) C.3.3. Counter Signature on Encrypted Content This example uses the following: o CEK: AES-GCM w/ 128-bit key o Recipient class: ECDH Ephemeral-Static, Curve P-256 Size of binary file is 326 bytes Schaad Expires May 26, 2017 [Page 109] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 96( [ / protected / h'a10101' / { \ alg \ 1:1 \ AES-GCM 128 \ } / , / unprotected / { / iv / 5:h'c9cf4df2fe6c632bf7886413', / countersign / 7:[ / protected / h'a1013823' / { \ alg \ 1:-36 } / , / unprotected / { / kid / 4:'bilbo.baggins@hobbiton.example' }, / signature / h'00929663c8789bb28177ae28467e66377da12302d7f9 594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00 3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c c3430c9d65e7ddff' ] }, / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0 c52a357da7a644b8070a151b0', / recipients / [ [ / protected / h'a1013818' / { \ alg \ 1:-25 \ ECDH-ES + HKDF-256 \ } / , / unprotected / { / ephemeral / -1:{ / kty / 1:2, / crv / -1:1, / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf bf054e1c7b4d91d6280', / y / -3:true }, / kid / 4:'meriadoc.brandybuck@buckland.example' }, / ciphertext / h'' ] ] ] ) Schaad Expires May 26, 2017 [Page 110] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 C.3.4. Encrypted Content with External Data This example uses the following: o CEK: AES-GCM w/ 128-bit key o Recipient class: ECDH static-Static, Curve P-256 with AES Key Wrap o Externally Supplied AAD: h'0011bbcc22dd44ee55ff660077' Size of binary file is 173 bytes 96( [ / protected / h'a10101' / { \ alg \ 1:1 \ AES-GCM 128 \ } / , / unprotected / { / iv / 5:h'02d1f7e6f26c43d4868d87ce' }, / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e28529d8f5335 e5f0165eee976b4a5f6c6f09d', / recipients / [ [ / protected / h'a101381f' / { \ alg \ 1:-32 \ ECHD-SS+A128KW \ } / , / unprotected / { / static kid / -3:'peregrin.took@tuckborough.example', / kid / 4:'meriadoc.brandybuck@buckland.example', / U nonce / -22:h'0101' }, / ciphertext / h'41e0d76f579dbd0d936a662d54d8582037de2e366fd e1c62' ] ] ] ) C.4. Examples of Encrypted Messages C.4.1. Simple Encrypted Message This example uses the following: o CEK: AES-CCM w/ 128-bit key and a 64-bit tag Size of binary file is 52 bytes Schaad Expires May 26, 2017 [Page 111] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 16( [ / protected / h'a1010a' / { \ alg \ 1:10 \ AES-CCM-16-64-128 \ } / , / unprotected / { / iv / 5:h'89f52f65a1c580933b5261a78c' }, / ciphertext / h'5974e1b99a3a4cc09a659aa2e9e7fff161d38ce7edd5617 388e77baf' ] ) C.4.2. Encrypted Message w/ a Partial IV This example uses the following: o CEK: AES-CCM w/ 128-bit key and a 64-bit tag o Prefix for IV is 89F52F65A1C580933B52 Size of binary file is 41 bytes 16( [ / protected / h'a1010a' / { \ alg \ 1:10 \ AES-CCM-16-64-128 \ } / , / unprotected / { / partial iv / 6:h'61a7' }, / ciphertext / h'252a8911d465c125b6764739700f0141ed09192da5c69e5 33abf852b' ] ) C.5. Examples of MACed messages C.5.1. Shared Secret Direct MAC This example uses the following: o MAC: AES-CMAC, 256-bit key, truncated to 64 bits o Recipient class: direct shared secret Size of binary file is 57 bytes Schaad Expires May 26, 2017 [Page 112] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 97( [ / protected / h'a1010f' / { \ alg \ 1:15 \ AES-CBC-MAC-256//64 \ } / , / unprotected / {}, / payload / 'This is the content.', / tag / h'9e1226ba1f81b848', / recipients / [ [ / protected / h'', / unprotected / { / alg / 1:-6 / direct /, / kid / 4:'our-secret' }, / ciphertext / h'' ] ] ] ) C.5.2. ECDH Direct MAC This example uses the following: o MAC: HMAC w/SHA-256, 256-bit key o Recipient class: ECDH key agreement, two static keys, HKDF w/ context structure Size of binary file is 214 bytes Schaad Expires May 26, 2017 [Page 113] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 97( [ / protected / h'a10105' / { \ alg \ 1:5 \ HMAC 256//256 \ } / , / unprotected / {}, / payload / 'This is the content.', / tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99 4bc3f16a41', / recipients / [ [ / protected / h'a101381a' / { \ alg \ 1:-27 \ ECDH-SS + HKDF-256 \ } / , / unprotected / { / static kid / -3:'peregrin.took@tuckborough.example', / kid / 4:'meriadoc.brandybuck@buckland.example', / U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d 19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583 68b017e7f2a9e5ce4db5' }, / ciphertext / h'' ] ] ] ) C.5.3. Wrapped MAC This example uses the following: o MAC: AES-MAC, 128-bit key, truncated to 64 bits o Recipient class: AES keywrap w/ a pre-shared 256-bit key Size of binary file is 109 bytes Schaad Expires May 26, 2017 [Page 114] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 97( [ / protected / h'a1010e' / { \ alg \ 1:14 \ AES-CBC-MAC-128//64 \ } / , / unprotected / {}, / payload / 'This is the content.', / tag / h'36f5afaf0bab5d43', / recipients / [ [ / protected / h'', / unprotected / { / alg / 1:-5 / A256KW /, / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037' }, / ciphertext / h'711ab0dc2fc4585dce27effa6781c8093eba906f227 b6eb0' ] ] ] ) C.5.4. Multi-recipient MACed message This example uses the following: o MAC: HMAC w/ SHA-256, 128-bit key o Recipient class: Uses three different methods 1. ECDH Ephemeral-Static, Curve P-521, AES-Key Wrap w/ 128-bit key 2. AES-Key Wrap w/ 256-bit key Size of binary file is 309 bytes Schaad Expires May 26, 2017 [Page 115] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 97( [ / protected / h'a10105' / { \ alg \ 1:5 \ HMAC 256//256 \ } / , / unprotected / {}, / payload / 'This is the content.', / tag / h'bf48235e809b5c42e995f2b7d5fa13620e7ed834e337f6aa43df16 1e49e9323e', / recipients / [ [ / protected / h'a101381c' / { \ alg \ 1:-29 \ ECHD-ES+A128KW \ } / , / unprotected / { / ephemeral / -1:{ / kty / 1:2, / crv / -1:3, / x / -2:h'0043b12669acac3fd27898ffba0bcd2e6c366d53bc4db 71f909a759304acfb5e18cdc7ba0b13ff8c7636271a6924b1ac63c02688075b55ef2 d613574e7dc242f79c3', / y / -3:true }, / kid / 4:'bilbo.baggins@hobbiton.example' }, / ciphertext / h'339bc4f79984cdc6b3e6ce5f315a4c7d2b0ac466fce a69e8c07dfbca5bb1f661bc5f8e0df9e3eff5' ], [ / protected / h'', / unprotected / { / alg / 1:-5 / A256KW /, / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037' }, / ciphertext / h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a 518e7736549e998370695e6d6a83b4ae507bb' ] ] ] ) C.6. Examples of MAC0 messages C.6.1. Shared Secret Direct MAC This example uses the following: o MAC: AES-CMAC, 256-bit key, truncated to 64 bits Schaad Expires May 26, 2017 [Page 116] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o Recipient class: direct shared secret Size of binary file is 37 bytes 17( [ / protected / h'a1010f' / { \ alg \ 1:15 \ AES-CBC-MAC-256//64 \ } / , / unprotected / {}, / payload / 'This is the content.', / tag / h'726043745027214f' ] ) Note that this example uses the same inputs as Appendix C.5.1. C.7. COSE Keys C.7.1. Public Keys This is an example of a COSE Key set. This example includes the public keys for all of the previous examples. In order the keys are: o An EC key with a kid of "meriadoc.brandybuck@buckland.example" o An EC key with a kid of "peregrin.took@tuckborough.example" o An EC key with a kid of "bilbo.baggins@hobbiton.example" o An EC key with a kid of "11" Size of binary file is 481 bytes Schaad Expires May 26, 2017 [Page 117] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 [ { -1:1, -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0 8551d', -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008 4d19c', 1:2, 2:'meriadoc.brandybuck@buckland.example' }, { -1:1, -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a 09eff', -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf c117e', 1:2, 2:'11' }, { -1:3, -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de 7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8 f42ad', -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e 60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1 d9475', 1:2, 2:'bilbo.baggins@hobbiton.example' }, { -1:1, -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91 d6280', -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf 822bb', 1:2, 2:'peregrin.took@tuckborough.example' } ] C.7.2. Private Keys This is an example of a COSE Key set. This example includes the private keys for all of the previous examples. In order the keys are: Schaad Expires May 26, 2017 [Page 118] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 o An EC key with a kid of "meriadoc.brandybuck@buckland.example" o A shared-secret key with a kid of "our-secret" o An EC key with a kid of "peregrin.took@tuckborough.example" o A shared-secret key with a kid of "018c0ae5-4d9b-471b- bfd6-eef314bc7037" o An EC key with a kid of "bilbo.baggins@hobbiton.example" o An EC key with a kid of "11" Size of binary file is 816 bytes [ { 1:2, 2:'meriadoc.brandybuck@buckland.example', -1:1, -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0 8551d', -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008 4d19c', -4:h'aff907c99f9ad3aae6c4cdf21122bce2bd68b5283e6907154ad911840fa 208cf' }, { 1:2, 2:'11', -1:1, -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a 09eff', -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf c117e', -4:h'57c92077664146e876760c9520d054aa93c3afb04e306705db609030850 7b4d3' }, { 1:2, 2:'bilbo.baggins@hobbiton.example', -1:3, -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de 7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8 f42ad', -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e 60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1 d9475', Schaad Expires May 26, 2017 [Page 119] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 -4:h'00085138ddabf5ca975f5860f91a08e91d6d5f9a76ad4018766a476680b 55cd339e8ab6c72b5facdb2a2a50ac25bd086647dd3e2e6e99e84ca2c3609fdf177f eb26d' }, { 1:4, 2:'our-secret', -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4 27188' }, { 1:2, -1:1, 2:'peregrin.took@tuckborough.example', -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91 d6280', -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf 822bb', -4:h'02d1f7e6f26c43d4868d87ceb2353161740aacf1f7163647984b522a848 df1c3' }, { 1:4, 2:'our-secret2', -1:h'849b5786457c1491be3a76dcea6c4271' }, { 1:4, 2:'018c0ae5-4d9b-471b-bfd6-eef314bc7037', -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4 27188' } ] Acknowledgments This document is a product of the COSE working group of the IETF. The following individuals are to blame for getting me started on this project in the first place: Richard Barnes, Matt Miller, and Martin Thomson. The initial version of the draft was based to some degree on the outputs of the JOSE and S/MIME working groups. The following individuals provided input into the final form of the document: Carsten Bormann, John Bradley, Brain Campbell, Michael B. Schaad Expires May 26, 2017 [Page 120] Internet-Draft CBOR Object Signing and Encryption (COSE) November 2016 Jones, Ilari Liusvaara, Francesca Palombini, Goran Selander, and Ludwig Seitz. Author's Address Jim Schaad August Cellars Email: ietf@augustcellars.com Schaad Expires May 26, 2017 [Page 121] ./draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt0000664000764400076440000013226012665667627023014 0ustar iustyiusty AVTCORE WG J. Lennox Internet-Draft Vidyo Intended status: Standards Track M. Westerlund Expires: September 3, 2016 Ericsson Q. Wu Huawei C. Perkins University of Glasgow March 2, 2016 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback draft-ietf-avtcore-rtp-multi-stream-optimisation-12 Abstract RTP allows multiple RTP streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 3, 2016. Lennox, et al. Expires September 3, 2016 [Page 1] Internet-Draft Grouping RTCP Reception Statistics March 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTCP Reporting Groups . . . . . . . . . . . . . . . . . . . . 3 3.1. Semantics and Behaviour of RTCP Reporting Groups . . . . 4 3.2. Identifying Members of an RTCP Reporting Group . . . . . 5 3.2.1. Definition and Use of the RTCP RGRP SDES Item . . . . 5 3.2.2. Definition and Use of the RTCP RGRS Packet . . . . . 6 3.3. Interactions with the RTP/AVPF Feedback Profile . . . . . 8 3.4. Interactions with RTCP Extended Report (XR) Packets . . . 9 3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9 3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 12 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 12 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for group communication, supporting multiparty multimedia sessions. A single RTP session can support multiple participants sending at once, and can also support participants sending multiple simultaneous RTP streams. Examples of the latter might include a participant with multiple cameras who chooses to send multiple views of a scene, or a participant that sends audio and video flows multiplexed in a single RTP session. Rules for handling RTP sessions containing multiple RTP Lennox, et al. Expires September 3, 2016 [Page 2] Internet-Draft Grouping RTCP Reception Statistics March 2016 streams are described in [RFC3550] with some clarifications in [I-D.ietf-avtcore-rtp-multi-stream]. An RTP endpoint will have one or more synchronisation sources (SSRCs). It will have at least one RTP Stream, and thus SSRC, for each media source it sends, and might use multiple SSRCs per media source when using media scalability features [RFC6190], forward error correction, RTP retransmission [RFC4588], or similar mechanisms. An endpoint that is not sending any RTP stream, will have at least one SSRC to use for reporting and any feedback messages. Each SSRC has to send RTCP sender reports corresponding to the RTP packets it sends, and receiver reports for traffic it receives. That is, every SSRC will send RTCP packets to report on every other SSRC. This rule is simple, but can be quite inefficient for endpoints that send large numbers of RTP streams in a single RTP session. Consider a session comprising ten participants, each sending three media sources, each with their own RTP stream. There will be 30 SSRCs in such an RTP session, and each of those 30 SSRCs will send an RTCP Sender Report/ Receiver Report packet (containing several report blocks) per reporting interval as each SSRC reports on all the others. However, the three SSRCs comprising each participant are commonly co-located such that they see identical reception quality. If there was a way to indicate that several SSRCs are co-located, and see the same reception quality, then two-thirds of those RTCP reports could be suppressed. This would allow the remaining RTCP reports to be sent more often, while keeping within the same RTCP bandwidth fraction. This memo defines such an RTCP extension, RTCP Reporting Groups. This extension is used to indicate the SSRCs that originate from the same endpoint, and therefore have identical reception quality, hence allowing the endpoints to suppress unnecessary RTCP reception quality reports. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. RTCP Reporting Groups An RTCP Reporting Group is a set of synchronization sources (SSRCs) that are co-located at a single endpoint (which could be an end host or a middlebox) in an RTP session. Since they are co-located, every SSRC in the RTCP reporting group will have an identical view of the network conditions, and see the same lost packets, jitter, etc. This allows a single representative to send RTCP reception quality reports Lennox, et al. Expires September 3, 2016 [Page 3] Internet-Draft Grouping RTCP Reception Statistics March 2016 on behalf of the rest of the reporting group, reducing the number of RTCP packets that need to be sent without loss of information. 3.1. Semantics and Behaviour of RTCP Reporting Groups A group of co-located SSRCs that see identical network conditions can form an RTCP reporting group. If reporting groups are in use, an RTP endpoint with multiple SSRCs MAY put those SSRCs into a reporting group if their view of the network is identical; i.e., if they report on traffic received at the same interface of an RTP endpoint. SSRCs with different views of the network MUST NOT be put into the same reporting group. An endpoint that has combined its SSRCs into an RTCP reporting group will choose one (or a subset) of those SSRCs to act as "reporting source(s)" for that RTCP reporting group. A reporting source will send RTCP SR/RR reception quality reports on behalf of the other members of the RTCP reporting group. A reporting source MUST suppress the RTCP SR/RR reports that relate to other members of the reporting group, and only report on remote SSRCs. The other members (non reporting sources) of the RTCP reporting group will suppress their RTCP reception quality reports, and instead send an RTCP RGRS packet (see Section 3.2.2) to indicate that they are part of an RTCP reporting group and give the SSRCs of the reporting sources. If there are large numbers of remote SSRCs in the RTP session, then the reception quality reports generated by the reporting source might grow too large to fit into a single compound RTCP packet, forcing the reporting source to use a round-robin policy to determine what remote SSRCs it includes in each compound RTCP packet, and so reducing the frequency of reports on each SSRC. To avoid this, in sessions with large numbers of remote SSRCs, an RTCP reporting group MAY use more than one reporting source. If several SSRCs are acting as reporting sources for an RTCP reporting group, then each reporting source MUST have non-overlapping sets of remote SSRCs it reports on. An endpoint MUST NOT create an RTCP reporting group that comprises only a single local SSRC (i.e., an RTCP reporting group where the reporting source is the only member of the group), unless it is anticipated that the group might have additional SSRCs added to it in the future. If a reporting source leaves the RTP session (i.e., if it sends a RTCP BYE packet, or leaves the session without sending BYE under the rules of [RFC3550] section 6.3.7), the remaining members of the RTCP reporting group MUST either (a) have another reporting source, if one exists, report on the remote SSRCs the leaving SSRC reported on, (b) choose a new reporting source, or (c) disband the RTCP reporting Lennox, et al. Expires September 3, 2016 [Page 4] Internet-Draft Grouping RTCP Reception Statistics March 2016 group and begin sending reception quality reports following [RFC3550] and [I-D.ietf-avtcore-rtp-multi-stream]. The RTCP timing rules assign different bandwidth fractions to senders and receivers. This lets senders transmit RTCP reception quality reports more often than receivers. If a reporting source in an RTCP reporting group is a receiver, but one or more non-reporting SSRCs in the RTCP reporting group are senders, then the endpoint MAY treat the reporting source as a sender for the purpose of RTCP bandwidth allocation, increasing its RTCP bandwidth allocation, provided it also treats one of the senders as if it were a receiver and makes the corresponding reduction in RTCP bandwidth for that SSRC. However, the application needs to consider the impact on the frequency of transmitting of the synchronization information included in RTCP Sender Reports. 3.2. Identifying Members of an RTCP Reporting Group When RTCP Reporting Groups are in use, the other SSRCs in the RTP session need to be able to identify which SSRCs are members of an RTCP reporting group. Two RTCP extensions are defined to support this: the RTCP RGRP SDES item is used by the reporting source(s) to identify an RTCP reporting group, and the RTCP RGRS packet is used by other members of an RTCP reporting group to identify the reporting source(s). 3.2.1. Definition and Use of the RTCP RGRP SDES Item This document defines a new RTCP SDES item to identify an RTCP reporting group. The motivation for giving a reporting group an identify is to ensure that the RTCP reporting group and its member SSRCs can be correctly associated when there are multiple reporting sources, and to ensure that a reporting SSRC can be associated with the correct reporting group if an SSRC collision occurs. This document defines the RTCP Source Description (SDES) RGRP item. The RTCP SDES RGRP item MUST be sent by the reporting sources in a reporting group, and MUST NOT be sent by other members of the reporting group or by SSRCs that are not members of any RTCP reporting group. Specifically, every reporting source in an RTCP reporting group MUST include an RTCP SDES packet containing an RGRP item in every compound RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). Syntactically, the format of the RTCP SDES RGRP item is identical to that of the RTCP SDES CNAME item [RFC7022], except that the SDES item type field MUST have value RGRP=(TBA) instead of CNAME=1. The value Lennox, et al. Expires September 3, 2016 [Page 5] Internet-Draft Grouping RTCP Reception Statistics March 2016 of the RTCP SDES RGRP item MUST be chosen with the same concerns about global uniqueness and the same privacy considerations as the RTCP SDES CNAME. The value of the RTCP SDES RGRP item MUST be stable throughout the lifetime of the reporting group, even if some or all of the reporting sources change their SSRC due to collisions, or if the set of reporting sources changes. Note to RFC Editor: please replace (TBA) in the above paragraph with the RTCP SDES item type number assigned to the RGRP item, then delete this note. An RTP mixer or translator that forwards RTCP SR or RR packets from members of a reporting group MUST forward the corresponding RTCP SDES RGRP items as well, even if it otherwise strips SDES items other than the CNAME item. 3.2.2. Definition and Use of the RTCP RGRS Packet A new RTCP packet type is defined to allow the members of an RTCP reporting group to identify the reporting sources for that group. This allows participants in an RTP session to distinguish an SSRC that is sending empty RTCP reception reports because it is a member of an RTCP reporting group, from an SSRC that is sending empty RTCP reception reports because it is not receiving any traffic. It also explicitly identifies the reporting sources, allowing other members of the RTP session to know which SSRCs are acting as the reporting sources for an RTCP reporting group, and allowing them to detect if RTCP packets from any of the reporting sources are being lost. The format of the RTCP RGRS packet is defined below. It comprises the fixed RTCP header that indicates the packet type and length, the SSRC of the packet sender, and a list of reporting sources for the RTCP reporting group of which the packet sender is a member. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT=RGRS(TBA) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : List of SSRC(s) for the Reporting Source(s) : : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the RTCP RGRS packet have the following definition: Lennox, et al. Expires September 3, 2016 [Page 6] Internet-Draft Grouping RTCP Reception Statistics March 2016 version (V): 2 bits unsigned integer. This field identifies the RTP version. The current RTP version is 2. padding (P): 1 bit. If set, the padding bit indicates that the RTCP packet contains additional padding octets at the end that are not part of the control information but are included in the length field. See [RFC3550]. Source Count (SC): 5 bits unsigned integer. Indicates the number of reporting source SSRCs that are included in this RTCP packet. As the RTCP RGRS packet MUST NOT be not sent by reporting sources, all the SSRCs in the list of reporting sources will be different from the SSRC of the packet sender. Every RTCP RGRS packet MUST contain at least one reporting source SSRC. Payload type (PT): 8 bits unsigned integer. The RTCP packet type number that identifies the packet as being an RTCP RGRS packet. The RGRS RTCP packet has the value [TBA]. Note to RFC Editor: please replace [TBA] here, and in the packet format diagram above, with the RTCP packet type that IANA assigns to the RTCP RGRS packet. Length: 16 bits unsigned integer. The length of this packet in 32-bit words minus one, including the header and any padding. This is in line with the definition of the length field used in RTCP sender and receiver reports [RFC3550]. Since all RTCP RGRS packets include at least one reporting source SSRC, the length will always be 2 or greater. SSRC of packet sender: 32 bits. The SSRC of the sender of this packet. List of SSRCs for the Reporting Source(s): A variable length size (as indicated by SC header field) of the 32 bit SSRC values of the reporting sources for the RTCP Reporting Group of which the packet sender is a member. Every source that belongs to an RTCP reporting group but is not a reporting source MUST include an RTCP RGRS packet in every compound RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). Each RTCP RGRS packet MUST contain the SSRC identifier of at least one reporting source. If there are more reporting sources in an RTCP reporting group than can fit into an RTCP RGRS packet, the members of that reporting group MUST send the SSRCs of the reporting sources in a round-robin fashion in consecutive RTCP RGRS packets, such that all Lennox, et al. Expires September 3, 2016 [Page 7] Internet-Draft Grouping RTCP Reception Statistics March 2016 the SSRCs of the reporting sources are included over the course of several RTCP reporting intervals. An RTP mixer or translator that forwards RTCP SR or RR packets from members of a reporting group MUST also forward the corresponding RGRS RTCP packets. If the RTP mixer or translator rewrites SSRC values of the packets it forwards, it MUST make the corresponding changes to the RTCP RGRS packets. 3.3. Interactions with the RTP/AVPF Feedback Profile Use of the RTP/AVPF Feedback Profile [RFC4585] allows SSRCs to send rapid RTCP feedback requests and codec control messages. If use of the RTP/AVPF profile has been negotiated in an RTP session, members of an RTCP reporting group can send rapid RTCP feedback and codec control messages following [RFC4585] and [RFC5104], as updated by Section 5.4 of [I-D.ietf-avtcore-rtp-multi-stream], and by the following considerations. The members of an RTCP reporting group will all see identical network conditions. Accordingly, one might therefore think that it doesn't matter which SSRC in the reporting group sends the RTP/AVPF feedback or codec control messages. There might be, however, cases where the sender of the feedback/codec control message has semantic importance, or when only a subset of the members of an RTCP reporting group might want to send RTP/AVPF feedback or a codec control message in response to a particular event. For example, an RTP video sender might choose to treat packet loss feedback received from SSRCs known to be audio receivers with less urgency than feedback that it receives from video receivers when deciding what packets to retransmit, and a multimedia receiver using reporting groups might want to choose the outgoing SSRC for feedback packets to reflect this. Each member of an RTCP reporting group SHOULD therefore send RTP/AVPF feedback/codec control messages independently of the other members of the reporting group, to respect the semantic meaning of the message sender. The suppression rules of [RFC4585] will ensure that only a single copy of each feedback packet is (typically) generated, even if several members of a reporting group send the same feedback. When an endpoint knows that several members of its RTCP reporting group will be sending identical feedback, and that the sender of the feedback is not semantically important, then that endpoint MAY choose to send all its feedback from the reporting source and deterministically suppress feedback packets generated by the other sources in the reporting group. It is important to note that the RTP/AVPF timing rules operate on a per-SSRC basis. Using a single reporting source to send all feedback Lennox, et al. Expires September 3, 2016 [Page 8] Internet-Draft Grouping RTCP Reception Statistics March 2016 for a reporting group will hence limit the amount of feedback that can be sent to that which can be sent by one SSRC. If this limit is a problem, then the reporting group can allow each of its members to send its own feedback, using its own SSRC. If the RTP/AVPF feedback messages or codec control requests are sent as compound RTCP packets, then those compound RTCP packets MUST include either an RTCP RGRS packet or an RTCP SDES RGRP item, depending on whether they are sent by the reporting source or a non- reporting source in the RTCP reporting group respectively. The contents of non-compound RTCP feedback or codec control messages are not affected by the use of RTCP reporting groups. 3.4. Interactions with RTCP Extended Report (XR) Packets When using RTCP Extended Reports (XR) [RFC3611] with RTCP reporting groups, it is RECOMMENDED that the reporting source is used to send the RTCP XR packets. If multiple reporting sources are in use, the reporting source that sends the SR/RR packets that relate to a particular remote SSRC SHOULD send the RTCP XR reports about that SSRC. This is motivated as one commonly combine the RTCP XR metrics with the regular report block to more fully understand the situation. Receiving these blocks in different compound packets reduces their value as the measuring intervals are not synchronized in those cases. Some RTCP XR report blocks are specific to particular types of media, and might be relevant to only some members of a reporting group. For example, it would make no sense for an SSRC that is receiving video to send a VoIP metric RTCP XR report block. Such media specific RTCP XR report blocks MUST be sent by the SSRC to which they are relevant, and MUST NOT be included in the common report sent by the reporting source. This might mean that some SSRCs send RTCP XR packets in compound RTCP packets that contain an empty RTCP SR/RR packet, and that the time period covered by the RTCP XR packet is different to that covered by the RTCP SR/RR packet. If it is important that the RTCP XR packet and RTCP SR/RR packet cover the same time period, then that source SHOULD be removed from the RTCP reporting group, and send standard RTCP packets instead. 3.5. Middlebox Considerations Many different types of middlebox are used with RTP. RTCP reporting groups are potentially relevant to those types of RTP middlebox that have their own SSRCs and generate RTCP reports for the traffic they receive. RTP middleboxes that do not have their own SSRC, and that don't send RTCP reports on the traffic they receive, cannot use the RTCP reporting groups extension, since they generate no RTCP reports to group. Lennox, et al. Expires September 3, 2016 [Page 9] Internet-Draft Grouping RTCP Reception Statistics March 2016 An RTP middlebox that has several SSRCs of its own can use the RTCP reporting groups extension to group the RTCP reports it generates. This can occur, for example, if a middlebox is acting as an RTP mixer for both audio and video flows that are multiplexed onto a single RTP session, where the middlebox has one SSRC for the audio mixer and one for the video mixer part, and when the middlebox wants to avoid cross reporting between audio and video. A middlebox cannot use the RTCP reporting groups extension to group RTCP packets from the SSRCs that it is forwarding. It can, however, group the RTCP packets from the SSRCs it is forwarding into compound RTCP packets following the rules in Section 6.1 of [RFC3550] and Section 5.3 of [I-D.ietf-avtcore-rtp-multi-stream]. If the middlebox is using RTCP reporting groups for its own SSRCs, it MAY include RTCP packets from the SSRCs that it is forwarding as part of the compound RTCP packets its reporting source generates. A middlebox that forwards RTCP SR or RR packets sent by members of a reporting group MUST forward the corresponding RTCP SDES RGRP items, as described in Section 3.2.1. A middlebox that forwards RTCP SR or RR packets sent by member of a reporting group MUST also forward the corresponding RTCP RGRS packets, as described in Section 3.2.2. Failure to forward these packets can cause compatibility problems, as described in Section 4.2. If a middlebox rewrites SSRC values in the RTP and RTCP packets that it is forwarding, then it MUST make the corresponding changes in RTCP SDES packets containing RGRP items and in RTCP RGRS packets, to allow them to be associated with the rewritten SSRCs. 3.6. SDP Signalling for Reporting Groups This document defines the "a=rtcp-rgrp" Session Description Protocol (SDP) [RFC4566] attribute to indicate if the session participant is capable of supporting RTCP Reporting Groups for applications that use SDP for configuration of RTP sessions. It is a property attribute, and hence takes no value. The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] is IDENTICAL, as the functionality applies on RTP session level. A participant that proposes the use of RTCP Reporting Groups SHALL itself support the reception of RTCP Reporting Groups. The formal definition of this attribute is: Lennox, et al. Expires September 3, 2016 [Page 10] Internet-Draft Grouping RTCP Reception Statistics March 2016 Name: rtcp-rgrp Value: Usage Level: session, media Charset Dependent: no Example: a=rtcp-rgrp When using SDP Offer/Answer [RFC3264], the following procedures are to be used: o Generating the initial SDP offer: If the offerer supports the RTCP reporting group extensions, and is willing to accept RTCP packets containing those extensions, then it MUST include an "a=rtcp-rgrp" attribute in the initial offer. If the offerer does not support RTCP reporting groups extensions, or is not willing to accept RTCP packets containing those extensions, then it MUST NOT include the "a=rtcp-rgrp" attribute in the offer. o Generating the SDP answer: If the SDP offer contains an "a=rtcp- rgrp" attribute, and if the answerer supports RTCP reporting groups and is willing to receive RTCP packets using the RTCP reporting groups extensions, then the answerer MAY include an "a=rtcp-rgrp" attribute in the answer and MAY send RTCP packets containing the RTCP reporting groups extensions. If the offer does not contain an "a=rtcp-rgrp" attribute, or if the offer does contain such an attribute but the answerer does not wish to accept RTCP packets using the RTCP reporting groups extensions, then the answer MUST NOT include an "a=rtcp-rgrp" attribute. o Offerer Processing of the SDP Answer: If the SDP answer contains an "a=rtcp-rgrp" attribute, and the corresponding offer also contained an "a=rtcp-rgrp" attribute, then the offerer MUST be prepared to accept and process RTCP packets that contain the reporting groups extension, and MAY send RTCP packets that contain the reporting groups extension. If the SDP answer contains an "a=rtcp-rgrp" attribute, but the corresponding offer did not contain the "a=rtcp-rgrp" attribute, then the offerer MUST reject the call. If the SDP answer does not contain an "a=rtcp-rgrp" attribute, then the offerer MUST NOT send packets containing the RTCP reporting groups extensions, and does not need to process packet containing the RTCP reporting groups extensions. In declarative usage of SDP, such as the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) [RFC2974], the presence of the attribute indicates that the session participant MAY use RTCP Reporting Groups in its RTCP transmissions. An implementation that doesn't explicitly support RTCP Reporting Groups MAY join a RTP session as long as it has been verified that Lennox, et al. Expires September 3, 2016 [Page 11] Internet-Draft Grouping RTCP Reception Statistics March 2016 the implementation doesn't suffer from the problems discussed in Section 4.2. 4. Properties of RTCP Reporting Groups This section provides additional information on what the resulting properties are with the design specified in Section 3. The content of this section is non-normative. 4.1. Bandwidth Benefits of RTCP Reporting Groups To understand the benefits of RTCP reporting groups, consider a scenario in which the two endpoints in a session each have a hundred sources, of which eight each are sending within any given reporting interval. For ease of analysis, we can make the simplifying approximation that the duration of the RTCP reporting interval is equal to the total size of the RTCP packets sent during an RTCP interval, divided by the RTCP bandwidth. (This will be approximately true in scenarios where the bandwidth is not so high that the minimum RTCP interval is reached.) For further simplification, we can assume RTCP senders are following the recommendations regarding Compound RTCP Packets in [I-D.ietf-avtcore-rtp-multi-stream]; thus, the per-packet transport- layer overhead will be small relative to the RTCP data. Thus, only the actual RTCP data itself need be considered. In a report interval in this scenario, there will, as a baseline, be 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to approximately 6.5 kB of RTCP per report interval, assuming 16-byte CNAMEs and no other SDES information. Using the original [RFC3550] everyone-reports-on-every-sender feedback rules, each of the 184 receivers will send 16 report blocks, and each of the 16 senders will send 15. This amounts to approximately 76 kB of report block traffic per interval; 92% of RTCP traffic consists of report blocks. If reporting groups are used, however, there is only 0.4 kB of reports per interval, with no loss of useful information. Additionally, there will be (assuming 16-byte RGRPs, and a single reporting source per reporting group) an additional 2.4 kB per cycle of RGRP SDES items and RGRS packets. Put another way, the unmodified [RFC3550] reporting interval is approximately 9 times longer than if reporting groups are in use. Lennox, et al. Expires September 3, 2016 [Page 12] Internet-Draft Grouping RTCP Reception Statistics March 2016 4.2. Compatibility of RTCP Reporting Groups The RTCP traffic generated by receivers using RTCP Reporting Groups might appear, to observers unaware of these semantics, to be generated by receivers who are experiencing a network disconnection, as the non-reporting sources appear not to be receiving a given sender at all. This could be a potentially critical problem for such a sender using RTCP for congestion control, as such a sender might think that it is sending so much traffic that it is causing complete congestion collapse. However, such an interpretation of the session statistics would require a fairly sophisticated RTCP analysis. Any receiver of RTCP statistics which is just interested in information about itself needs to be prepared that any given reception report might not contain information about a specific media source, because reception reports in large conferences can be round-robined. Thus, it is unclear to what extent such backward compatibility issues would actually cause trouble in practice. 5. Security Considerations The security considerations of [RFC3550] and [I-D.ietf-avtcore-rtp-multi-stream] apply. If the RTP/AVPF profile is in use, then the security considerations of [RFC4585] (and [RFC5104], if used) also apply. If RTCP XR is used, the security consideration of [RFC3611] and any XR report blocks used also apply. The RTCP SDES RGRP item is vulnerable to malicious modifications unless integrity protected is used. A modification of this item's length field cause the parsing of the RTCP packet in which it is contained to fail. Depending on the implementation, parsing of the full compound RTCP packet can also fail causing the whole packet to be discarded. A modification to the value of this SDES item would make the receiver of the report think that the sender of the report was a member of a different RTCP reporting group. This will potentially create an inconsistency, when the RGRS reports the source as being in the same reporting group as another source with another reporting group identifier. What impact on a receiver implementation such inconsistencies would have are difficult to fully predict. One case is when congestion control or other adaptation mechanisms are used, an inconsistent report can result in a media sender to reduce its bit-rate. However, a direct modification of the receiver report or a feedback message itself would be a more efficient attack, and equally costly to perform. Lennox, et al. Expires September 3, 2016 [Page 13] Internet-Draft Grouping RTCP Reception Statistics March 2016 The new RGRS RTCP Packet type is very simple. The common RTCP packet type header shares the security risks with previous RTCP packet types. Errors or modification of the length field can cause the full compound packet to fail header validation (see Appendix A.2 in [RFC3550]) resulting in the whole compound RTCP packet being discarded. Modification of the SC or P fields would cause inconsistency when processing the RTCP packet, likely resulting it being classified as invalid. A modification of the PT field would cause the packet being interpreted under some other packet type's rules. In such case the result might be more or less predictable but packet type specific. Modification of the SSRC of packet sender would attribute this packet to another sender. Resulting in a receiver believing the reporting group applies also for this SSRC, if it exists. If it doesn't exist, unless also corresponding modifications are done on a SR/RR packet and a SDES packet the RTCP packet SHOULD be discarded. If consistent changes are done, that could be part of a resource exhaustion attack on a receiver implementation. Modification of the "List of SSRCs for the Reporting Source(s)" would change the SSRC the receiver expect to report on behalf of this SSRC. If that SSRC exist, that could potentially change the report group used for this SSRC. A change to another reporting group belonging to another endpoint is likely detectable as there would be a mismatch between the SSRC of the packet sender's endpoint information, transport addresses, SDES CNAME etc and the corresponding information from the reporting group indicated. In general the reporting group is providing limited impacts attacks. The most significant result from an deliberate attack would be to cause the information to be discarded or be inconsistent, including discard of all RTCP packets that are modified. This causes a lack of information at any receiver entity, possibly disregarding the endpoints participation in the session. To protect against this type of attacks from external non trusted entities, integrity and source authentication SHOULD be applied. This can be done, for example, by using SRTP [RFC3711] with appropriate key-management, other options exist as discussed in RTP Security Options [RFC7201]. The Report Group Identifier has a potential privacy impacting properties. If this would be generated by an implementation in such a way that is long term stable or predictable, it could be used for tracking a particular end-point. Therefore it is RECOMMENDED that it be generated as a short-term persistent RGRP, following the rules for short-term persistent CNAMEs in [RFC7022]. The rest of the information revealed, i.e. the SSRCs, the size of reporting group and the number of reporting sources in a reporting group is of less sensitive nature, considering that the SSRCs and the communication Lennox, et al. Expires September 3, 2016 [Page 14] Internet-Draft Grouping RTCP Reception Statistics March 2016 would anyway be revealed without this extension. By encrypting the report group extensions the SSRC values would preserved confidential, but can still be revealed if SRTP [RFC3711] is used. The size of the reporting groups and number of reporting sources are likely determinable from analysis of the packet pattern and sizes. However, this information appears to have limited value. 6. IANA Considerations (Note to the RFC-Editor: in the following, please replace "TBA" with the IANA-assigned value, and "XXXX" with the number of this document, then delete this note) The IANA is requested to register one new RTCP SDES items in the "RTCP SDES Item Types" registry, as follows: Value Abbrev Name Reference TBA RGRP Reporting Group Identifier [RFCXXXX] The definition of the RTCP SDES RGRP item is given in Section 3.2.1 of this memo. The IANA is also requested to register one new RTCP packet type in the "RTCP Control Packet Types (PT)" Registry as follows: Value Abbrev Name Reference TBA RGRS Reporting Group Reporting Sources [RFCXXXX] The definition of the RTCP RGRS packet type is given in Section 3.2.2 of this memo. The IANA is also requested to register one new SDP attribute: SDP Attribute ("att-field"): Attribute name: rtcp-rgrp Long form: RTCP Reporting Groups Type of name: att-field Type of attribute: Media or session level Subject to charset: No Purpose: Negotiate or configure the use of the RTCP Reporting Group Extension. Reference: [RFCXXXX] Values: None The definition of the "a=rtcp-rgrp" SDES attribute is given in Section 3.6 of this memo. Lennox, et al. Expires September 3, 2016 [Page 15] Internet-Draft Grouping RTCP Reception Statistics March 2016 7. References 7.1. Normative References [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 (work in progress), January 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . 7.2. Informative References [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, . Lennox, et al. Expires September 3, 2016 [Page 16] Internet-Draft Grouping RTCP Reception Statistics March 2016 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . Lennox, et al. Expires September 3, 2016 [Page 17] Internet-Draft Grouping RTCP Reception Statistics March 2016 Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Lennox, et al. Expires September 3, 2016 [Page 18] ./draft-ietf-jose-cfrg-curves-06.txt0000664000764400076440000005663012755342652016571 0ustar iustyiusty Network Working Group I. Liusvaara Internet-Draft Independent Intended status: Standards Track August 18, 2016 Expires: February 19, 2017 CFRG ECDH and signatures in JOSE draft-ietf-jose-cfrg-curves-06 Abstract This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JOSE. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 19, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liusvaara Expires February 19, 2017 [Page 1] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key type "OKP" . . . . . . . . . . . . . . . . . . . . . . . 3 3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Signing . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Verification . . . . . . . . . . . . . . . . . . . . 4 3.2. ECDH-ES . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Performing the ECDH Operation . . . . . . . . . . . . 5 4. Security considerations . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 A.1. Ed25519 Private Key . . . . . . . . . . . . . . . . . . . 8 A.2. Ed25519 Public Key . . . . . . . . . . . . . . . . . . . 9 A.3. JWK Thumbprint Canonicalization . . . . . . . . . . . . . 9 A.4. Ed25519 Signing . . . . . . . . . . . . . . . . . . . . . 9 A.5. Ed25519 Validation . . . . . . . . . . . . . . . . . . . 10 A.6. ECDH-ES with X25519 . . . . . . . . . . . . . . . . . . . 11 A.7. ECDH-ES with X448 . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Internet Research Task Force (IRTF) Crypto Forum Research Group (CFRG) selected new Diffie-Hellman algorithms ("X25519" and "X448"; [RFC7748]) and signature algorithms ("Ed25519" and "Ed448"; [I-D.irtf-cfrg-eddsa]) for asymmetric key cryptography. This document defines how to use those algorithms in JOSE in interoperable manner. This document defines the conventions to use in the context of [RFC7515], [RFC7516], and [RFC7517]. While the CFRG also defined two pairs of isogenous elliptic curves that underlie these algorithms, these curves are not directly exposed, as the algorithms laid on top are sufficient for the purposes of JOSE and are much easier to use. All inputs to and outputs from the ECDH and signature functions are defined to be octet strings, with the exception of outputs of verification functions, which are booleans. Liusvaara Expires February 19, 2017 [Page 2] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. "JWS Signing Input" and "JWS Signature" are defined by [RFC7515]. "Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static" is defined by [RFC7518], section 4.6. The JOSE key format ("JSON Web Key (JWK)") is defined by [RFC7517] and thumbprints for it ("JSON Web Key (JWK) Thumbprint") in [RFC7638]. 2. Key type "OKP" A new key type (kty) value "OKP" (Octet Key Pair) is defined for public key algorithms that use octet strings as private and public keys. It has the following parameters: o The parameter "kty" MUST be "OKP". o The parameter "crv" MUST be present and contain the subtype of the key (from the "JSON Web Elliptic Curve" registry). o The parameter "x" MUST be present and contain the public key encoded using the base64url [RFC4648] encoding. o The parameter "d" MUST be present for private keys and contain the private key encoded using the base64url encoding. This parameter MUST NOT be present for public keys. Note: Do not assume that there is an underlying elliptic curve, despite the existence of the "crv" and "x" parameters. (For instance, this key type could be extended to represent DH algorithms based on hyperelliptic surfaces.) When calculating JWK Thumbprints [RFC7638], the three public key fields are included in the hash input in lexicographic order: "crv", "kty", and "x". 3. Algorithms Liusvaara Expires February 19, 2017 [Page 3] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 3.1. Signatures For purpose of using EdDSA for signing data using "JSON Web Signature (JWS)" ([RFC7515]), algorithm "EdDSA" is defined here, to be applied as the value of the "alg" parameter. The following key subtypes are defined here for use with EdDSA: "crv" EdDSA Variant Ed25519 Ed25519 Ed448 Ed448 The key type used with these keys is "OKP" and the algorithm used for signing is "EdDSA". These subtypes MUST NOT be used for ECDH-ES. The EdDSA variant used is determined by the subtype of the key (Ed25519 for "Ed25519" and Ed448 for "Ed448"). 3.1.1. Signing Signing for these is preformed by applying the signing algorithm defined in [I-D.irtf-cfrg-eddsa] to the private key (as private key), public key (as public key) and the JWS Signing Input (as message). The resulting signature is the JWS Signature. All inputs and outputs are octet strings. 3.1.2. Verification Verification is performed by applying the verification algorithm defined in [I-D.irtf-cfrg-eddsa] to the public key (as public key), the JWS Signing Input (as message) and the JWS Signature (as signature). All inputs are octet strings. If the algorithm accepts, the signature is valid; otherwise, the signature is invalid. 3.2. ECDH-ES The following key subtypes are defined here for purpose of "Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static" (ECDH- ES): "crv" ECDH Function Applied X25519 X25519 X448 X448 The key type used with these keys is "OKP". These subtypes MUST NOT be used for signing. Liusvaara Expires February 19, 2017 [Page 4] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 [RFC7518] Section 4.6 defines the ECDH-ES algorithms "ECDH- ES+A128KW", "ECDH-ES+A192KW", "ECDH-ES+A256KW" and "ECDH-ES". 3.2.1. Performing the ECDH Operation The "x" parameter of the "epk" field is set as follows: Apply the appropriate ECDH function to the ephemeral private key (as scalar input) and the standard basepoint (as u-coordinate input). The base64url encoding of the output is the value for the "x" parameter of the "epk" field. All inputs and outputs are octet strings. The Z value (raw key agreement output) for key agreement (to be used in subsequent KDF as per [RFC7518] section 4.6.2) is determined as follows: Apply the appropriate ECDH function to the ephemeral private key (as scalar input) and receiver public key (as u-coordinate input). The output is the Z value. All inputs and outputs are octet strings. 4. Security considerations Security considerations from [RFC7748] and [I-D.irtf-cfrg-eddsa] apply here. Do not separate key material from information about what key subtype it is for. When using keys, check that the algorithm is compatible with the key subtype for the key. To do otherwise opens the system up to attacks via mixing up algorithms. It is particularly dangerous to mix up signature and MAC algorithms. Although for Ed25519 and Ed448, the signature binds the key used for signing, do not assume this, as there are many signature algorithms that fail to make such a binding. If key-binding is desired, include the key used for signing either inside the JWS protected header or the data to sign. If key generation or batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED. Signing and non-batch signature verification are deterministic operations and do not need random numbers of any kind. The JWA ECDH-ES KDF construction does not mix keys into the final shared secret. While in key exchange such could be a bad mistake, here either the receiver public key has to be chosen maliciously or the sender has to be malicious in order to cause problems. In either case, all security evaporates. Liusvaara Expires February 19, 2017 [Page 5] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 The nominal security strengths of X25519 and X448 are ~126 and ~223 bits. Therefore, using 256-bit symmetric encryption (especially key wrapping and encryption) with X448 is RECOMMENDED. 5. Acknowledgements Thanks to Michael B. Jones for his comments on an initial pre-draft and editorial help. Thanks to Matt Miller for some editorial help. 6. IANA considerations The following is added to the "JSON Web Key Types" registry: o "kty" Parameter Value: "OKP" o Key Type Description: Octet string key pairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 2 of [RFC-THIS] The following is added to the "JSON Web Key Parameters" registry: o Parameter Name: "crv" o Parameter Description: The subtype of keypair o Parameter Information Class: Public o Used with "kty" Value(s): "OKP" o Change Controller: IESG o Specification Document(s): Section 2 of [RFC-THIS] o Parameter Name: "d" o Parameter Description: The private key o Parameter Information Class: Private o Used with "kty" Value(s): "OKP" o Change Controller: IESG o Specification Document(s): Section 2 of [RFC-THIS] o Parameter Name: "x" o Parameter Description: The public key o Parameter Information Class: Public o Used with "kty" Value(s): "OKP" o Change Controller: IESG o Specification Document(s): Section 2 of [RFC-THIS] The following is added to the "JSON Web Signature and Encryption Algorithms" registry: Liusvaara Expires February 19, 2017 [Page 6] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 o Algorithm Name: "EdDSA" o Algorithm Description: EdDSA signature algorithms o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3 of [RFC-THIS] o Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa] The following is added to the "JSON Web Key Elliptic Curve" registry: o Curve Name: "Ed25519" o Curve Description: Ed25519 signature algorithm keypairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3 of [RFC-THIS] o Curve Name: "Ed448" o Curve Description: Ed448 signature algorithm keypairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3 of [RFC-THIS] o Curve name: "X25519" o Curve Description: X25519 function keypairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.2 of [RFC-THIS] o Analysis Documents(s): [RFC7748] o Curve Name: "X448" o Curve Description: X448 function keypairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.2 of [RFC-THIS] o Analysis Documents(s): [RFC7748] 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . Liusvaara Expires February 19, 2017 [Page 7] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [I-D.irtf-cfrg-eddsa] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-06 (work in progress), August 2016. 7.2. Informative References [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . Appendix A. Examples To the extent possible, the examples use material taken from test vectors of [RFC7748] and [I-D.irtf-cfrg-eddsa]. A.1. Ed25519 Private Key {"kty":"OKP","crv":"Ed25519", "d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A" "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} The hexadecimal dump of private key is: 9d 61 b1 9d ef fd 5a 60 ba 84 4a f4 92 ec 2c c4 44 49 c5 69 7b 32 69 19 70 3b ac 03 1c ae 7f 60 And of the public key is: Liusvaara Expires February 19, 2017 [Page 8] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 d7 5a 98 01 82 b1 0a b7 d5 4b fe d3 c9 64 07 3a 0e e1 72 f3 da a6 23 25 af 02 1a 68 f7 07 51 1a A.2. Ed25519 Public Key This is the public parts of the previous private key (which just omits "d"): {"kty":"OKP","crv":"Ed25519", "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} A.3. JWK Thumbprint Canonicalization The JWK Thumbprint canonicalization of the two above examples (with linebreak inserted for formatting reasons) is: {"crv":"Ed25519","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI aaPcHURo"} Which has the SHA-256 hash (in hexadecimal) of 90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89, which results in the base64url encoded JWK Thumbprint representation of "kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k". A.4. Ed25519 Signing The JWS protected header is: {"alg":"EdDSA"} This has the base64url encoding of: eyJhbGciOiJFZERTQSJ9 The payload is (text): Example of Ed25519 signing This has the base64url encoding of: RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc The JWS signing input is (concatenation of base64url encoding of the (protected) header, a dot and base64url encoding of the payload) is: eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc Liusvaara Expires February 19, 2017 [Page 9] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 Applying the Ed25519 signing algorithm using the private key, public key, and the JWS signing input yields the signature (hex): 86 0c 98 d2 29 7f 30 60 a3 3f 42 73 96 72 d6 1b 53 cf 3a de fe d3 d3 c6 72 f3 20 dc 02 1b 41 1e 9d 59 b8 62 8d c3 51 e2 48 b8 8b 29 46 8e 0e 41 85 5b 0f b7 d8 3b b1 5b e9 02 bf cc b8 cd 0a 02 Converting this to base64url yields: hgyY0il_MGCjP0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt 9g7sVvpAr_MuM0KAg So the compact serialization of the JWS is (concatenation of signing input, a dot, and base64url encoding of the signature): eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu M0KAg A.5. Ed25519 Validation The JWS from above example is: eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu M0KAg This has 2 dots in it, so it might be valid a JWS. Base64url decoding the protected header yields: {"alg":"EdDSA"} So this is an EdDSA signature. Now the key has: "kty":"OKP" and "crv":"Ed25519", so the signature is Ed25519 signature. The signing input is the part before second dot: eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc Applying Ed25519 verification algorithm to the public key, JWS signing input and the signature yields true. So the signature is valid. The message is the base64url decoding of the part between the dots: Example of Ed25519 Signing Liusvaara Expires February 19, 2017 [Page 10] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 A.6. ECDH-ES with X25519 The public key to encrypt to is: {"kty":"OKP","crv":"X25519","kid":"Bob" "x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"} The public key from the target key is (hex): de 9e db 7d 7b 7d c1 b4 d3 5b 61 c2 ec e4 35 37 3f 83 43 c8 5b 78 67 4d ad fc 7e 14 6f 88 2b 4f The ephemeral secret happens to be (hex): 77 07 6d 0a 73 18 a5 7d 3c 16 c1 72 51 b2 66 45 df 4c 2f 87 eb c0 99 2a b1 77 fb a5 1d b9 2c 2a So the ephemeral public key is X25519(ephkey,G) (hex): 85 20 f0 09 89 30 a7 54 74 8b 7d dc b4 3e f7 5a 0d bf 3a 0d 26 38 1a f4 eb a4 a9 8e aa 9b 4e 6a This is represented as the ephemeral public key value: {"kty":"OKP","crv":"X25519", "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"} So the protected header could, for example, be: {"alg":"ECDH-ES+A128KW","epk":{"kty":"OKP","crv":"X25519", "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}, "enc":"A128GCM","kid":"Bob"} And the sender computes as the DH Z value as X25519(ephkey,recv_pub) (hex): 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 The receiver computes as the DH Z value as X25519(seckey,ephkey_pub) (hex): 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 Which is the same as the sender's value (the both sides run this through the KDF before using it as a direct encryption key or AES128-KW key). Liusvaara Expires February 19, 2017 [Page 11] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 A.7. ECDH-ES with X448 The public key to encrypt to (with linebreak inserted for formatting reasons) is: {"kty":"OKP","crv":"X448","kid":"Dave", "x":"PreoKbDNIPW8_AtZm2_sz22kYnEHvbDU80W0MCfYuXL8PjT7QjKhPKcG3LV67D2 uB73BxnvzNgk"} The public key from target key is (hex): 3e b7 a8 29 b0 cd 20 f5 bc fc 0b 59 9b 6f ec cf 6d a4 62 71 07 bd b0 d4 f3 45 b4 30 27 d8 b9 72 fc 3e 34 fb 42 32 a1 3c a7 06 dc b5 7a ec 3d ae 07 bd c1 c6 7b f3 36 09 The ephemeral secret happens to be (hex): 9a 8f 49 25 d1 51 9f 57 75 cf 46 b0 4b 58 00 d4 ee 9e e8 ba e8 bc 55 65 d4 98 c2 8d d9 c9 ba f5 74 a9 41 97 44 89 73 91 00 63 82 a6 f1 27 ab 1d 9a c2 d8 c0 a5 98 72 6b So the ephemeral public key is X448(ephkey,G) (hex): 9b 08 f7 cc 31 b7 e3 e6 7d 22 d5 ae a1 21 07 4a 27 3b d2 b8 3d e0 9c 63 fa a7 3d 2c 22 c5 d9 bb c8 36 64 72 41 d9 53 d4 0c 5b 12 da 88 12 0d 53 17 7f 80 e5 32 c4 1f a0 This is packed into ephemeral public key value (linebreak inserted for formatting purposes): {"kty":"OKP","crv":"X448", "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 TF3-A5TLEH6A"} So the protected header could for example be (linebreak inserted for formatting purposes): {"alg":"ECDH-ES+A256KW","epk":{"kty":"OKP","crv":"X448", "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 TF3-A5TLEH6A"},"enc":"A256GCM","kid":"Dave"} And the sender computes as the DH Z value as X448(ephkey,recv_pub) (hex): Liusvaara Expires February 19, 2017 [Page 12] Internet-Draft CFRG ECDH and signatures in JOSE August 2016 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 44 9a 50 37 51 4a 87 9d The receiver computes as the DH Z value as X448(seckey,ephkey_pub) (hex): 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 44 9a 50 37 51 4a 87 9d Which is the same as the sender's value (the both sides run this through KDF before using as direct encryption key or AES256-KW key). Author's Address Ilari Liusvaara Independent Email: ilariliusvaara@welho.com Liusvaara Expires February 19, 2017 [Page 13] ./draft-ietf-avtext-avpf-ccm-layered-04.txt0000664000764400076440000006243413035210416020012 0ustar iustyiusty Network Working Group S. Wenger Internet-Draft J. Lennox Updates: 5104 (if approved) Vidyo, Inc. Intended status: Standards Track B. Burman Expires: July 14, 2017 M. Westerlund Ericsson January 10, 2017 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs draft-ietf-avtext-avpf-ccm-layered-04 Abstract This document updates RFC5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) as defined in RFC5104 when using it with layered codecs. In particular, a Decoder Refresh Point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless on whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 as updated by RFC 5506 have also been analyzed, and no corresponding shortcomings have been found. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Wenger, et al. Expires July 14, 2017 [Page 1] Internet-Draft CCM-Layered January 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Updated definition of Decoder Refresh Point . . . . . . . . . 4 4. Full Intra Request for Layered Codecs . . . . . . . . . . . . 5 5. Identifying the use of layered bitstreams (Informative) . . . 5 6. Layered Codecs and non-FIR codec control messages (Informative) . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Picture Loss Indication (PLI) . . . . . . . . . . . . . . 6 6.2. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . 6 6.3. Reference Picture Selection Indication (RPSI) . . . . . . 7 6.4. Temporal-Spatial Trade-off Request and Notification (TSTR/TSTN) . . . . . . . . . . . . . . . . . . . . . . . 7 6.5. H.271 Video Back Channel Message (VBCM) . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction and Problem Statement The Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] and Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) [RFC5104] specify a number of payload-specific feedback messages which a media receiver can use to inform a media sender of certain conditions, or make certain requests. The feedback messages are being sent as RTCP receiver reports, and RFC 4585 specifies timing rules that make the use of those messages practical for time-sensitive codec control. Since the time those RFCs were developed, layered codecs have gained in popularity and deployment. Layered codecs use multiple sub- bitstreams called layers to represent the content in different Wenger, et al. Expires July 14, 2017 [Page 2] Internet-Draft CCM-Layered January 2017 fidelities. Depending on the media codec and its RTP payload format in use, a number of options exist how to transport those layers in RTP. With reference to A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources [RFC7656]): single layers or groups of layers may be sent in their own RTP streams in Multiple RTP streams on a Single media Transport (MRST) or Multiple RTP streams on Multiple media Transports (MRMT) mode; using media-codec specific multiplexing mechanisms, multiple layers may be sent in a single RTP stream in Single RTP stream on a Single media Transport (SRST) mode. The dependency relationship between layers in a truly layered, pyramid-shaped bitstream forms a directed graph, with the base layer at the root. Enhancement layers depend on the base layer and potentially on other enhancement layers, and the target layer and all layers it depends on have to be decoded jointly in order to re-create the uncompressed media signal at the fidelity of the target layer. Such a layering structure is assumed henceforth; for more exotic layering structures please see Section 5. Implementation experience has shown that the Full Intra Request (FIR) command as defined in [RFC5104] is underspecified when used with layered codecs and when more than one RTP stream is used to transport the layers of a layered bitstream at a given fidelity. In particular, from the [RFC5104] specification language it is not clear whether an FIR received for only a single RTP stream of multiple RTP streams covering the same layered bitstream necessarily triggers the sending of a Decoder Refresh Point (as defined in [RFC5104] section 2.2) for all layers, or only for the layer which is transported in the RTP stream that the FIR request is associated with. This document fixes this shortcoming by: a. Updating the definition of the Decoder Refresh Point (as defined in [RFC5104] section 2.2) to cover layered codecs, in line with the corresponding definitions used in a popular layered codec format, namely H.264/SVC [H.264]. Specifically, a decoder refresh point, in conjunction with layered codecs, resets the state of the whole decoder, which implies that it includes hard or gradual single-layer decoder refresh for all layers; b. Require a media sender to send a Decoder Refresh Point after the media sender has received a FIR over an RTCP stream associated with any of the RTP streams over which a part of the layered bitstream is transported; Wenger, et al. Expires July 14, 2017 [Page 3] Internet-Draft CCM-Layered January 2017 c. Require that a media receiver sends the FIR on the RTCP stream associated with the base layer. The option of receiving FIR on enhancement layer-associated RTCP stream as specified in point b) above is kept for backward compatibility; and d. Providing guidance on how to detect that a layered bitstream is in use for which the above rules apply. While, clearly, the reaction to FIR for layered codecs in [RFC5104] and companion documents is underspecified, it appears that this is not the case for any of the other payload-specific codec control messages defined in any of [RFC4585], [RFC5104]. A brief summary of the analysis that led to this conclusion is also included in this document. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Updated definition of Decoder Refresh Point The remainder of this section replaces the definition of Decoder Refresh Point in section 2.2 of [RFC5104] in its entirety. Decoder Refresh Point: A bit string, packetized in one or more RTP packets, that completely resets the decoder to a known state. Examples for "hard" single layer decoder refresh points are Intra pictures in H.261 [H.261], H.263 [H.263], MPEG-1 [MPEG-1], MPEG-2 [MPEG-2], and MPEG-4 [MPEG-4]; Instantaneous Decoder Refresh (IDR) pictures in H.264 [H.264], and H.265 [H.265]; and Keyframes in VP8 [RFC6386] and VP9 [I-D.grange-vp9-bitstream]. "Gradual" decoder refresh points may also be used; see for example H.264 [H.264]. While both "hard" and "gradual" decoder refresh points are acceptable in the scope of this specification, in most cases the user experience will benefit from using a "hard" decoder refresh point. A decoder refresh point also contains all header information above the syntactical level of the picture layer that is conveyed in-band. In [H.264], for example, a decoder refresh point contains those parameter set Network Adaptation Layer (NAL) units that generate parameter sets necessary for the decoding of the following slice/data partition NAL units. (That is assuming the parameter sets have not been conveyed out of band.) Wenger, et al. Expires July 14, 2017 [Page 4] Internet-Draft CCM-Layered January 2017 When a layered codec is in use, the above definition--in particular, the requirement to completely reset the decoder to a known state-- implies that the decoder refresh point includes hard or gradual single layer decoder refresh points for all layers. 4. Full Intra Request for Layered Codecs A media receiver or middlebox may decide to send a FIR command based on the guidance provided in Section 4.3.1 of [RFC5104]. When sending the FIR command, it MUST target the RTP stream that carries the base layer of the layered bitstream, and this is done by setting the Feedback Control Information (FCI, and in particular the SSRC field therein) to refer to the SSRC of the forward RTP stream that carries the base layer. When a Full Intra Request Command is received by the designated media sender in the RTCP stream associated with any of the RTP streams in which any layer of a layered bitstream are sent, the designated media sender MUST send a Decoder Refresh Point (Section 3) as defined above at its earliest opportunity. The requirements related to congestion control on the forward RTP streams as specified in sections 3.5.1. and 5. of [RFC5104] apply for the RTP streams both in isolation and combined. Note: the requirement to react to FIR commands associated with enhancement layers is included for robustness and backward compatibility reasons. 5. Identifying the use of layered bitstreams (Informative) The above modifications to RFC 5104 unambiguously define how to deal with FIR when layered bitstreams are in use. However, it is surprisingly difficult to identify the use of a layered bitstream. In general, it is expected that implementers know when layered bitstreams (in its commonly understood sense: with inter-layer prediction between pyramided-arranged layers) are in use and when not, and can therefore implement the above updates to RFC 5104 correctly. However, there are scenarios in which layered codecs are employed creating non-pyramid shaped bitstreams. Those scenarios may be viewed as somewhat exotic today but clearly are supported by certain video coding syntaxes, such as H.264/SVC. When blindly applying the above rules to those non-pyramid-arranged layering structures, suboptimal system behavior would result. Nothing would break, and there would not be an interoperability failure, but the user experience may suffer through the sending or receiving of Decoder Refresh Points at times or on parts of the bitstream that are unnecessary from a user experience viewpoint. Therefore, this Wenger, et al. Expires July 14, 2017 [Page 5] Internet-Draft CCM-Layered January 2017 informative section is included that provides the current understanding of when a layered bitstream is in use and when not. The key observation made here is that the RTP payload format negotiated for the RTP streams, in isolation, is not necessarily an indicator for the use of a layered bitstream. Some layered codecs (including H.264/SVC) can form decodable bitstreams including only (one or more) enhancement layers, without the base layer, effectively creating simulcastable sub-bitstreams within a single scalable bitstream (as defined in the video coding standard), but without inter-layer prediction. In such a scenario, it is potentially, though not necessarily, counter-productive to send a decoder refresh point on all RTP streams using that payload format and SSRC. It is beyond the scope of this document to discuss optimized reactions to FIRs received on RTP streams carrying such exotic bitstreams. One good indication of the likely use of pyramid-shaped layering with interlayer prediction is when the various RTP streams are "bound" together on the signaling level. In an SDP environment, this would be the case if they are marked as being dependent on each other using The Session Description Protocol (SDP) Grouping Framework [RFC5888] and the layer dependency RFC 5583 [RFC5583]. 6. Layered Codecs and non-FIR codec control messages (Informative) Between them, AVPF [RFC4585] and Codec Control Messages [RFC5104] define a total of seven Payload-specific Feedback messages. For the FIR command message, guidance has been provided above. In this section, some information is provided with respect to the remaining six codec control messages. 6.1. Picture Loss Indication (PLI) PLI is defined in section 6.3.1 of [RFC4585]. The prudent response to a PLI message received for an enhancement layer is to "repair" that enhancement layer and all dependent enhancement layers through appropriate source-coding specific means. However, the reference layer(s) used by the enhancement layer for which the PLI was received does not require repair. The encoder can figure out by itself what constitutes a dependent enhancement layer and does not need help from the system stack in doing so. Thus, there is nothing that needs to be specified herein. 6.2. Slice Loss Indication (SLI) SLI is defined in section 6.3.2 of [RFC4585]. The current understanding is that the prudent response to a SLI message received for an enhancement layer is to "repair" the affected spatial area of Wenger, et al. Expires July 14, 2017 [Page 6] Internet-Draft CCM-Layered January 2017 that enhancement layer and all dependent enhancement layers through appropriate source-coding specific means. As in PLI, the reference layers used by the enhancement layer for which the SLI was received do not need to be repaired. Again, as in PLI, the encoder can determine by itself what constitutes a dependent enhancement layer and does not need help from the system stack in doing so. Thus, there is nothing that needs to be specified herein. SLI has seen very little implementation and, as far as it is known, none in conjunction with layered systems. 6.3. Reference Picture Selection Indication (RPSI) RPSI is defined in section 6.3.3 of [RFC4585]. While a technical equivalent of RPSI has been in use with non-layered systems for many years, no implementations are known in conjunction of layered codecs. The current understanding is that the reception of an RPSI message on any layer indicating a missing reference picture forces the encoder to appropriately handle that missing reference picture in the layer indicated, and all dependent layers. Thus, RPSI should work without further need for specification language. 6.4. Temporal-Spatial Trade-off Request and Notification (TSTR/TSTN) TSTN/TSTR are defined in section 4.3.2 and 4.3.3 of [RFC5104], respectively. The TSTR request communicates guidance of the preferred trade-off between spatial quality and frame rate. A technical equivalent of TSTN/TSTR has seen deployment for many years in non-scalable systems. The Temporal-Spatial Trade-off request and notification messages include an SSRC target, which, similarly to FIR, may refer to an RTP stream carrying a base layer, an enhancement layer, or multiple layers. Therefore, the current understanding is that the semantics of the message applies to the layers present in the targeted RTP stream. It is noted that per-layer TSTR/TSTN is a mechanism that is, in some ways, counterproductive in a system using layered codecs. Given a sufficiently complex layered bitstream layout, a sending system has flexibility in adjusting the spatio/temporal quality balance by adding and removing temporal, spatial, or quality enhancement layers. At present it is unclear whether an allowed (or even recommended) option to the reception of a TSTR is to adjust the bit allocation within the layer(s) present in the addressed RTP stream, or to adjust the layering structure accordingly--which can involve more than just the addressed RTP stream. Wenger, et al. Expires July 14, 2017 [Page 7] Internet-Draft CCM-Layered January 2017 Until there is a sufficient critical mass of implementation practice, it is probably prudent for an implementer not to assume either of the two options or any middleground that may exist between the two. Instead, it is suggested that an implementation be liberal in accepting TSTR messages, and upon receipt responding in TSTN indicating "no change". Further, it is suggested that new implementations do not send TSTR messages except when operating in SRST mode as defined in [RFC7656]. Finally implementers are encouraged to contribute to the IETF documentation of any implementation requirements that make per-layer TSTR/TSTN useful. 6.5. H.271 Video Back Channel Message (VBCM) VBCM is defined in section 4.3.4 of [RFC5104]. What was said above for RPSI (Section 6.3) applies here as well. 7. Acknowledgements The authors want to thank Mo Zanaty for useful discussions. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations The security considerations of AVPF [RFC4585] (as updated by Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences [RFC5506]) and Codec Control Messages [RFC5104] apply. The clarified response to FIR does not introduce additional security considerations. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . Wenger, et al. Expires July 14, 2017 [Page 8] Internet-Draft CCM-Layered January 2017 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . 10.2. Informative References [H.261] ITU-T, "ITU-T Rec. H.261: Video codec for audiovisual services at p x 64 kbit/s", 1993, . [H.263] ITU-T, "ITU-T Rec. H.263: Video coding for low bit rate communication", 2005, . [H.264] ITU-T, "ITU-T Rec. H.264: Advanced video coding for generic audiovisual services", 2014, . [H.265] ITU-T, "ITU-T Rec. H.265: High efficiency video coding", 2015, . [I-D.grange-vp9-bitstream] Grange, A. and H. Alvestrand, "A VP9 Bitstream Overview", draft-grange-vp9-bitstream-00 (work in progress), February 2013. [MPEG-1] ISO/IEC, "ISO/IEC 11172-2:1993 Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 2: Video", 1993. [MPEG-2] ISO/IEC, "ISO/IEC 13818-2:2013 Information technology -- Generic coding of moving pictures and associated audio information -- Part 2: Video", 2013. [MPEG-4] ISO/IEC, "ISO/IEC 14496-2:2004 Information technology -- Coding of audio-visual objects -- Part 2: Visual", 2004. [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, . Wenger, et al. Expires July 14, 2017 [Page 9] Internet-Draft CCM-Layered January 2017 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . Appendix A. Change Log NOTE TO RFC EDITOR: Please remove this section prior to publication. draft-wenger-avtext-avpf-ccm-layered-00-00: initial version draft-ietf-avtext-avpf-ccm-layered-00: resubmit as avtext WG draft per IETF95 and list confirmation by Rachel 4/25/2016 draft-ietf-avtext-avpf-ccm-layered-00: In section "Identifying the use of Layered Codecs (Informative)", removed last sentence that could be misread that the explicit signaling of simulcasting in conjunction with payload formats supporting layered coding implies no layering. draft-ietf-avtext-avpf-ccm-layered-01: clarifications in section 5. draft-ietf-avtext-avpf-ccm-layered-02: addressing WGLC comments, mostly editorial; see reflector discussions 09/2016 draft-ietf-avtext-avpf-ccm-layered-03: addressing AD writeup comments, editorial Authors' Addresses Stephan Wenger Vidyo, Inc. Email: stewe@stewe.org Wenger, et al. Expires July 14, 2017 [Page 10] Internet-Draft CCM-Layered January 2017 Jonathan Lennox Vidyo, Inc. Email: jonathan@vidyo.com Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden Email: bo.burman@ericsson.com Magnus Westerlund Ericsson Farogatan 2 SE- 164 80 Kista Sweden Phone: +46107148287 Email: magnus.westerlund@ericsson.com Wenger, et al. Expires July 14, 2017 [Page 11] ./draft-ietf-ospf-ttz-06.txt0000664000764400076440000017027713034422657015172 0ustar iustyiusty Internet Engineering Task Force H. Chen Internet-Draft R. Li Intended status: Experimental Huawei Technologies Expires: July 12, 2017 A. Retana Cisco Systems, Inc. Y. Yang Sockrate Z. Liu China Mobile January 8, 2017 OSPF Topology-Transparent Zone draft-ietf-ospf-ttz-06.txt Abstract This document presents a topology-transparent zone (TTZ) in an OSPF area. 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. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 12, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires July 12, 2017 [Page 1] Internet-Draft Topology-Transparent Zone January 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Chen, et al. Expires July 12, 2017 [Page 2] Internet-Draft Topology-Transparent Zone January 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 5.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 5.2. TTZ Example . . . . . . . . . . . . . . . . . . . . . . . 6 6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 8 6.1. General Format of TTZ LSA . . . . . . . . . . . . . . . . 8 6.2. TTZ ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. TTZ Router TLV . . . . . . . . . . . . . . . . . . . . . . 9 6.4. TTZ Options TLV . . . . . . . . . . . . . . . . . . . . . 10 6.5. Link Scope TTZ LSA . . . . . . . . . . . . . . . . . . . . 11 7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 12 7.1. TTZ Migration Process . . . . . . . . . . . . . . . . . . 13 8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14 8.1. Discovery of TTZ Neighbors . . . . . . . . . . . . . . . . 14 8.2. Adjacency between TTZ Edge and TTZ External Router . . . . 17 9. Advertisement of LSAs . . . . . . . . . . . . . . . . . . . . 17 9.1. Advertisement of LSAs within TTZ . . . . . . . . . . . . . 17 9.2. Advertisement of LSAs through TTZ . . . . . . . . . . . . 18 10. Computation of Routing Table . . . . . . . . . . . . . . . . . 18 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 18 11.2. Migration to TTZ . . . . . . . . . . . . . . . . . . . . . 19 11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 21 12. Manageability Considerations . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 15. Contributors and Other Authors . . . . . . . . . . . . . . . . 23 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 17.1. Normative References . . . . . . . . . . . . . . . . . . . 24 17.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Prototype Implementation . . . . . . . . . . . . . . 25 A.1. What are Implemented and Tested . . . . . . . . . . . . . 25 A.2. Implementation Experience . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Chen, et al. Expires July 12, 2017 [Page 3] Internet-Draft Topology-Transparent Zone January 2017 1. Introduction Networks expand as business grows and traffic increases. For scalability and manageability, a hierarchical network architecture is usually deployed in OSPF networks by re-grouping routers into areas, which is often challenging and causes service interruptions. At first, reorganizing a network from one area into multiple areas or from a number of existing areas into even more areas is a very challenging and time consuming task since it involves significant network architecture changes. Considering the one area case, originally the network has only one area, which is the backbone. This original backbone area will be reorganized into a new backbone and a number of non-backbone areas. In general, each of the non- backbone areas is connected to the new backbone area through the Area Border Routers (ABRs) between the non-backbone and the backbone area (refer to RFC 2328 section 3). It demands careful re-designing of network topology in advance to guarantee backbone area continuity and non-backbone area reachability, and requires significant modifications of configurations on many routers to ensure consistent routing. Secondly, the services carried by the network may be interrupted while the network is being reorganized from one area into multiple areas or from a number of existing areas into even more areas since every OSPF interface with an area change is going down with its old area and then up with a new area. This document presents a topology-transparent zone (TTZ) in an OSPF area and describes extensions to OSPFv2 for supporting the topology- transparent zone, which is scalable and resolves the issues above. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. 2. Terminology TTZ link or TTZ internal link: A link whose ends are within a single TTZ. TTZ internal router: A router whose links are TTZ internal links inside a single TTZ. TTZ external router: A router outside of a TTZ that has no TTZ internal links. TTZ external link: A link not configured to be within a TTZ. Chen, et al. Expires July 12, 2017 [Page 4] Internet-Draft Topology-Transparent Zone January 2017 TTZ edge router: A router is called TTZ edge router if some, but not all, of its links are within a single TTZ. TTZ router: A TTZ internal router or a TTZ edge router. 3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 4. Requirements A Topology-Transparent Zone may be deployed to resolve some critical issues in existing networks and future networks. The requirements for a TTZ are listed as follows: o Routers outside a TTZ MUST NOT require any changes to operate with the TTZ. o A TTZ MUST be enclosed in a single area. o A TTZ MUST hide the topology of the TTZ from any router outside of the TTZ. 5. Topology-Transparent Zone 5.1. Overview of Topology-Transparent Zone A Topology-Transparent Zone is identified by a TTZ identifier (ID), and it consists of a group of routers and a number of links connecting the routers. A TTZ MUST be contained within an OSPF area. A TTZ ID is a 32-bit number that is unique for identifying a TTZ. The TTZ ID SHOULD NOT be 0, to avoid confusion with Area 0. The same TTZ ID MUST be configured on the routers and/or links that make up a specific instance of a TTZ. All TTZ instances in an OSPF area MUST be unique. In addition to having similar functions of an OSPF area, an OSPF TTZ makes some improvements on an OSPF area, which include: o An OSPF TTZ represents a set of TTZ edge routers, connected by a full mesh of virtual connections between them. Chen, et al. Expires July 12, 2017 [Page 5] Internet-Draft Topology-Transparent Zone January 2017 o Non-TTZ link state information is handled as normal. TTZ Routers receive the link state information about the topology outside of the TTZ, store the information, and flood the information through the TTZ to the routers outside of the TTZ. 5.2. TTZ Example The figure below shows an area containing a TTZ: TTZ 600. TTZ 600 ---- TTZ Internal Link \ ==== Normal Link Area X \ ^~^~^~^~^~^~^~^~^~^~^~^~ ( ) ===[R15]========(==[T61]----[T81]---[T63]==)======[R29]=== || ( | \ / | ) || || ( | \ / | ) || || ( [T75] \ / | ) || || ( | ___\ / | ) || || ( | / [T71] [T79] ) || || ( | [T73] / \ | ) || || ( | / \ | ) || || ( | / \ | ) || || ( | / \ | ) || ===[R17]========(==[T65]---[T77]----[T67]==)======[R31]=== \\ (// \\) // || //v~v~v~v~v~v~v~v~v~v~v~\\ || || // \\ || || // \\ || \\ // \\ // ======[R23]==============================[R25]===== // \\ // \\ All the routers in the figure are in area X. Routers with T (i.e., T61, T63, T65, T67, T71, T73, T75, T77, T79 and T81) are also in TTZ 600, which contains the TTZ internal links connecting them. To create a TTZ, we need configure it (refer to section 11). There are two types of routers in a TTZ: TTZ internal and TTZ edge routers. TTZ 600 has four TTZ edge routers T61, T63, T65 and T67. Each of them has at least one adjacent router in TTZ 600 and one adjacent router outside of TTZ 600. For instance, router T61 is a TTZ edge router since it has an adjacent router R15 outside of TTZ 600 and three adjacent routers T75, T71 and T81 in TTZ 600. In addition, TTZ 600 comprises six TTZ internal routers T71, T73, T75, T77, T79 and T81. Each of them has all its adjacent routers in Chen, et al. Expires July 12, 2017 [Page 6] Internet-Draft Topology-Transparent Zone January 2017 TTZ 600. For instance, router T71 is a TTZ internal router since its adjacent routers T61, T63, T65, T67 and T73 are all in TTZ 600. It should be noted that by definition, a TTZ internal router cannot also be an ABR. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. For instance, TTZ 600 does not send the information about TTZ internal router T71 to any router outside of TTZ 600; it does not send the information about the link between TTZ router T61 and T71 to any router outside of TTZ 600. The figure below illustrates area X from the point of view on a router outside of TTZ 600 after TTZ 600 is created. Area X ==== Normal Link ===[R15]===========[T61]=========[T63]=========[R29]=== || || \\ // || || || || \\ // || || || || \\ // || || || || \\// || || || || //\ || || || || // \\ || || || || // \\ || || || || // \\ || || || || // \\ || || ===[R17]===========[T65]=========[T67]=========[R31]=== \\ // \\ // || // \\ || || // \\ || || // \\ || \\ // \\ // ======[R23]============================[R25]===== // \\ // \\ From a router outside of the TTZ, a TTZ is seen as the TTZ edge routers connected each other. For instance, router R15 sees that T61, T63, T65 and T67 are connected each other. In addition, a router outside of the TTZ sees TTZ edge routers having normal connections to the routers outside of the TTZ. For example, router R15 sees that T61, T63, T65 and T67 have the normal connections to R15, R29, R17 and R23, R25 and R31 respectively. Chen, et al. Expires July 12, 2017 [Page 7] Internet-Draft Topology-Transparent Zone January 2017 6. Extensions to OSPF Protocols The link state information about a TTZ includes router LSAs, which can be contained and advertised in opaque LSAs [RFC5250] within the TTZ. Some control information regarding a TTZ can also be contained and advertised in opaque LSAs within the TTZ. These opaque LSAs are called TTZ opaque LSAs or TTZ LSAs for short. 6.1. General Format of TTZ LSA The following is the general format of a TTZ LSA. It has an LS Type = 10/9 and TTZ-LSA-Type, and contains a number of TLVs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS Type = 10/9| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TTZ-LSA-Type(9)| Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There are three TTZ LSAs of LS Type 10 defined: o TTZ Router LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Router TLV. o TTZ Control LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Options TLV. o TTZ Indication LSA: a TTZ LSA containing a TTZ ID TLV with E = 0, which indicates that the router originating this LSA is a TTZ internal router. There is one TTZ LSA of LS Type 9: o TTZ Discovery LSA: a TTZ LSA containing a TTZ ID TLV and a optional TTZ Options TLV. Chen, et al. Expires July 12, 2017 [Page 8] Internet-Draft Topology-Transparent Zone January 2017 6.2. TTZ ID TLV A TTZ ID TLV has the following format. It contains a TTZ ID (refer to section 5.1) and some flags. It has the TLV-Length of 8 octets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTZ-ID-TLV-Type (1) | TLV-Length (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTZ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (MUST be zero) |E|Z| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E = 1: Indicating a router is a TTZ Edge router Z = 1: Indicating a router has migrated to TTZ When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it MUST set flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, and to 0 if it is a TTZ internal router. It MUST set flag Z to 1 after it has migrated to TTZ, and to 0 before it migrates to TTZ or after it rolls back from TTZ (refer to section 6.4). 6.3. TTZ Router TLV The format of a TTZ Router TLV is as follows. It has the same content as a standard OSPF Router LSA (RFC 2328) with the following modifications. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTZ-RT-TLV-Type (2) | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ For a router link, the existing eight bit Link Type field for a router link is split into two fields as follows: Chen, et al. Expires July 12, 2017 [Page 9] Internet-Draft Topology-Transparent Zone January 2017 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | I | Type-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I bit flag: 1: Router link is a TTZ internal link. 0: Router link is a TTZ external link. Type-1: The kind of the link. The values for Type-1 are the same as those for Type defined in RFC 2328 section 12.4.1. The Link Type field is 8 bits, the values 128-255 of the field are reserved (refer to RFC 4940), which allows the reuse of the bottom 7 bits to indicate the type of a TTZ internal or external link. 6.4. TTZ Options TLV The format of a TTZ Options TLV is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTZ-OP-TLV-Type (3) | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OP | Reserved (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OP Value Meaning (Operation) 0x001 (T): Advertising TTZ Topology Information for Migration 0x010 (M): Migrating to TTZ 0x011 (N): Advertising Normal Topology Information for Rollback 0x100 (R): Rolling back from TTZ A OP field of three bits is defined. It may have a value of 0x001 for T, 0x010 for M, 0x011 for N, or 0x100 for R, which indicates one of the four operations above. When any of the other values is received, it is ignored. Advertising TTZ Topology Information for Migration (T): After a user configures a TTZ router to advertise TTZ topology information, advertising TTZ topology information for migration is triggered. The TTZ router originates a TTZ Control LSA having a TTZ Options TLV with OP for T. It also originates its other TTZ LSA such as a TTZ router LSA or TTZ indication LSA. When another TTZ router receives the LSA with OP for T, it originates its TTZ LSA as described in section 7. Migrating to TTZ (M): After a user configures a TTZ router to migrate to TTZ, migrating to TTZ is triggered. The TTZ router originates a Chen, et al. Expires July 12, 2017 [Page 10] Internet-Draft Topology-Transparent Zone January 2017 TTZ Control LSA having a TTZ Options TLV with OP for M and migrates to TTZ. When another TTZ router receives the LSA with OP for M, it also migrates to TTZ. When a router migrates to TTZ, it computes routes using the TTZ topology and the topology outside of the TTZ. For a TTZ internal router, it also updates its TTZ indication LSA with Z = 1. For a TTZ edge router, it updates its TTZ router LSA with Z = 1 and its router LSA for virtualizing the TTZ. A TTZ router determines whether it is internal or edge based on configurations (refer to section 11.1). Advertising Normal Topology Information for Rollback (N): After a user configures a TTZ router to advertise normal topology information, advertising Normal topology information for rollback is triggered. The TTZ router originates a TTZ Control LSA having a TTZ Options TLV with OP for N. It also advertises its normal LSAs such as its normal router LSA and stops advertising its other TTZ LSAs. When another TTZ router receives the LSA with OP for N, it forwards the LSA, advertises its normal LSAs, and stops advertising its TTZ LSAs. Rolling back from TTZ (R): After a user configures a TTZ router to roll back from TTZ, rolling back from TTZ is triggered. The TTZ router originates a TTZ Control LSA having a TTZ Options TLV with OP for R and rolls back from TTZ. When another TTZ router receives the LSA with OP for R, it also rolls back from TTZ. After a TTZ router originates a TTZ control LSA in response to a configuration described above to control TTZ, it flushes the TTZ control LSA if OP in the LSA is set for the configuration and the configuration is removed. 6.5. Link Scope TTZ LSA A TTZ LSA of LS Type 9 has the following format. Chen, et al. Expires July 12, 2017 [Page 11] Internet-Draft Topology-Transparent Zone January 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS Type = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TTZ-LSA-Type(9)| Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TTZ ID TLV ~ +---------------------------------------------------------------+ | | ~ (TTZ Options TLV) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It contains a mandatory TTZ ID TLV, which may be followed by a optional TTZ Options TLV. It is used to discover a TTZ neighbor. 7. Constructing LSAs for TTZ For a TTZ, its topology is represented by the LSAs generated by its TTZ routers for the link states in the TTZ, which include TTZ router LSAs by TTZ edge routers, TTZ indication LSAs by TTZ internal routers, normal router LSAs and network LSAs. The TTZ router LSAs and TTZ indication LSAs MUST be generated after advertising TTZ topology information for migration is triggered. A TTZ edge router generates a TTZ router LSA that has a TTZ ID TLV and a TTZ Router TLV. The former includes the ID of the TTZ to which the router belongs and flag E set to 1, which indicates the originator of the LSA is a TTZ Edge router. The TTZ router TLV contains the TTZ external links to the routers outside of the TTZ and the TTZ internal links to the routers inside the TTZ as described in section 6. The TTZ router LSA containing this TLV is constructed and advertised within the TTZ. A TTZ internal router generates a TTZ indication LSA that has a TTZ ID TLV containing the ID of the TTZ to which the router belongs and flag E set to 0, which indicates the originator of the LSA is a TTZ internal router. For a TTZ internal router, its regular Router LSA is still generated. If a TTZ router is a Designated Router (DR), it Chen, et al. Expires July 12, 2017 [Page 12] Internet-Draft Topology-Transparent Zone January 2017 originates its regular network LSA. After receiving a trigger to migrate to TTZ such as a TTZ control LSA with OP for M, a TTZ edge router MUST originate its normal router LSA for virtualizing a TTZ, which comprises three groups of links in general. The first group are the router links connecting the TTZ external routers. These router links are normal router links. There is a router link for every adjacency between this TTZ edge router and a TTZ external router. The second group are the "virtual" router links connecting to the other TTZ edge routers. For each of the other TTZ edge routers, there is a corresponding point-to-point router link to it from this TTZ edge router. The cost of the link is the cost of the shortest path from this TTZ edge router to the other TTZ edge router within the TTZ. In addition, the LSA may contain a third group of links, which are the stub links for the loopback addresses inside the TTZ to be accessed by nodes outside of the TTZ. 7.1. TTZ Migration Process After migration to TTZ is triggered, a TTZ router computes routes using its TTZ topology (refer to section 10) and a TTZ edge router originates its normal router LSA for virtualizing the TTZ in two steps: Step 1: The router updates its router LSA by adding a point-to-point link to each of the other known edge routers in the TTZ, and also by adding the stub links for the loopback addresses in the TTZ to be accessed outside of the TTZ according to configuration policies of operators. Step 2: After MaxLSAGenAdvTime (0.3 s) or sr-time + MaxLSAAdvTime (0.1 s), it removes the TTZ links from its router LSA, where sr- time is the time from updating its router LSA to receiving the ack for its router LSA and receiving the updated router LSAs originated by the other TTZ edge routers. In other words, it removes the TTZ links from its router LSA after sending its updated router LSA and receiving the updated router LSAs originated by the other TTZ edge routers for MaxLSAAdvTime or after sending its updated router LSA for MaxLSAGenAdvTime. MaxLSAAdvTime and MaxLSAGenAdvTime SHOULD be set to 100ms and 300ms respectively, but MAY be configurable. The former is the maximum time for an LSA to be advertised to all the routers in an Chen, et al. Expires July 12, 2017 [Page 13] Internet-Draft Topology-Transparent Zone January 2017 area. The latter is the maximum time for all TTZ router LSAs to be generated by all TTZ edge routers and advertised to all the routers in an area after a first TTZ router LSA is generated. This is to avoid a possible short route down or change in a TTZ external router while the TTZ is being virtualized. If each TTZ edge router originates its router LSA by adding its point-to-point links to the other TTZ edge routers and removing its TTZ links in one step, a route taking a path through the TTZ in the TTZ external router may be down or changed before all the router LSAs generated by the TTZ edge routers reach the TTZ external router. When the TTZ external router computes routes with some router LSAs originated by the TTZ edge routers, bi-directional check for some of the point-to-point links will fail. Thus the route taking the path through the shortest path for the point-to-point link failing the bi-directional check will be down or changed. To roll back from a TTZ smoothly after receiving a trigger to roll back from TTZ, a TTZ edge router MUST originate its normal router LSA in the above two steps in a reverse way. Step 1: Initially, it updates its normal router LSA by adding the normal links for the links configured as TTZ links into the LSA. Step 2: It then removes the point-to-point links to the other edge routers of the TTZ for virtualizing the TTZ and the stub links for the loopback addresses from its updated router LSA after sending its updated router LSA and receiving the updated router LSAs originated by the other TTZ edge routers for MaxLSAAdvTime or after sending its updated router LSA for MaxLSAGenAdvTime. 8. Establishing Adjacencies This section describes the TTZ adjacencies. 8.1. Discovery of TTZ Neighbors For two routers A and B connected by a P2P link and having a normal adjacency, they TTZ discover each other through a TTZ LSA of LS Type 9 with a TTZ ID TLV. We call this LSA D-LSA for short. If two ends of the link have different TTZ IDs or only one end is configured with TTZ ID, TTZ adjacency over the link MUST NOT be "formed". If two ends of the link have the same TTZ ID and Z flag value, A and B are TTZ neighbors. The following is a sequence of events related Chen, et al. Expires July 12, 2017 [Page 14] Internet-Draft Topology-Transparent Zone January 2017 to TTZ for this case. A B Configure TTZ Configure TTZ D-LSA (TTZ-ID=100) ----------------------> Same TTZ ID and Z A is B's TTZ Neighbor D-LSA (TTZ-ID=100) Same TTZ ID and Z <---------------------- B is A's TTZ Neighbor A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B sends A a D-LSA with TTZ-ID after the TTZ is configured on it. When A receives the D-LSA from B and determines they have the same TTZ ID and Z flag value, B is A's TTZ neighbor. A also sends B all the TTZ LSAs it has and originates its TTZ LSA when one of the following conditions is met. o Z = 0 and there is a TTZ LSA with OP for T. o Z = 1. B is symmetric to A and acts similarly to A. If two ends of the link have the same TTZ ID but Z flags are different, a TTZ adjacency over the link MUST be "formed" in the following steps. Suppose that A has migrated to TTZ and B has not (i.e., flag Z in A's D-LSA is 1 and flag Z in B's D-LSA is 0). A B Configure TTZ Configure TTZ D-LSA(TTZ-ID=100,Z=1) ----------------------> Same TTZ ID, but different Z A is B's TTZ Neighbor D-LSA(TTZ-ID=100,Z=0) Same TTZ ID, but <---------------------- different Z B is A's TTZ Neighbor TTZ LSAs -----------------------> TTZ LSAs <----------------------- When A receives the D-LSA from B and determines they have the same Chen, et al. Expires July 12, 2017 [Page 15] Internet-Draft Topology-Transparent Zone January 2017 TTZ ID but its Z = 1 and B's Z = 0, A sends B all the TTZ LSAs it has and triggers B to migrate to TTZ. A updates and sends B its D-LSA by adding an TTZ Options TLV with OP for M after sending B all the TTZ LSAs. D-LSA(TTZ-ID=100,OP=M) Add TTZ Options -----------------------> Migrate to TTZ TLV with OP for M D-LSA(TTZ-ID=100,Z=1) Migrated to TTZ <----------------------- Set Z=1 D-LSA(TTZ-ID=100,Z=1) Remove -----------------------> TTZ Options TLV When B receives the D-LSA from A and determines they have the same TTZ ID but its Z = 0 and A's Z = 1, B sends A all the TTZ LSAs it has. When B receives the D-LSA from A with OP for M, it starts to migrate to TTZ. B updates and advertises its LSAs as needed. After receiving B's D-LSA with Z = 1, A updates and sends B its D-LSA by removing the TTZ Options TLV. It also updates and advertises its LSAs as needed. For a number of routers connected through a broadcast link and having normal adjacencies among them, they also TTZ discover each other through D-LSAs. The DR (Designated Router) for the link MUST "form" TTZ adjacencies with the other routers if all the routers attached to the link have the same TTZ ID configured on the connections to the link. Otherwise, the DR MUST NOT "form" any TTZ adjacency with any router attached to the link. For a number of routers connected through a broadcast link and having TTZ adjacencies among them, if a mis-configured router is introduced on the broadcast link, the DR for the link MUST NOT "form" any TTZ adjacency with this mis-configured router. For routers connected via a link without any adjacency among them, they TTZ discover each other through D-LSAs in the same way as described above after they form a normal adjacency. A TTZ adjacency over a link MUST be removed when one of the following events happens. Chen, et al. Expires July 12, 2017 [Page 16] Internet-Draft Topology-Transparent Zone January 2017 o TTZ ID on one end of the link is changed to a different one. o TTZ ID on one end of the link is removed. o The D-LSA is not received after the D-LSA-MAX-RETRANSMIT-TIME or is explicitly flushed. The D-LSA-MAX-RETRANSMIT-TIME SHOULD be set to 60 minutes, but MAY be configurable. o Normal adjacency over the link is down. When the TTZ ID on one end of the link is removed, the corresponding D-LSA is flushed. 8.2. Adjacency between TTZ Edge and TTZ External Router A TTZ edge router forms an adjacency with any TTZ external router to which it is connected. When the TTZ edge router synchronizes its link state database with the TTZ external router, it sends the TTZ external router the information about all the LSAs except for the LSAs belonging to the TTZ that are hidden from any router outside of the TTZ. At the end of the link state database synchronization, the TTZ edge router originates its own router LSA for virtualizing the TTZ and sends this LSA to its adjacent routers including the TTZ external router. 9. Advertisement of LSAs LSAs can be divided into a couple of classes according to their Advertisements. The first class of LSAs is advertised within a TTZ. The second is advertised through a TTZ. 9.1. Advertisement of LSAs within TTZ Any LSA about a link state in a TTZ is advertised only within the TTZ. It is not advertised to any router outside of the TTZ. For example, a router LSA generated for a TTZ internal router is advertised only within the TTZ. Any network LSA generated for a broadcast or NBMA network in a TTZ is advertised only within the TTZ. It is not advertised outside of the TTZ. Any opaque LSA generated for a TTZ internal TE link is advertised only within the TTZ. Chen, et al. Expires July 12, 2017 [Page 17] Internet-Draft Topology-Transparent Zone January 2017 After migrating to TTZ, every edge router of a TTZ MUST NOT advertise any LSA about a link state in the TTZ to any router outside of the TTZ. The TTZ edge router determines whether an LSA is about a TTZ internal link state by checking if the advertising router of the LSA is a TTZ internal router (i.e., there is a TTZ indication LSA generated by the TTZ internal router and having the same advertising router). For any TTZ LSA originated by a router within the TTZ, every edge router of the TTZ MUST NOT advertise it to any router outside of the TTZ. 9.2. Advertisement of LSAs through TTZ Any LSA about a link state outside of a TTZ received by an edge router of the TTZ is advertised using the TTZ as transit. For example, when an edge router of a TTZ receives an LSA from a router outside of the TTZ, it floods it to its neighboring routers both inside the TTZ and outside of the TTZ. This LSA may be any LSA such as a router LSA that is advertised within an OSPF area. The routers in the TTZ continue to flood the LSA. When another edge router of the TTZ receives the LSA, it floods the LSA to its neighboring routers both outside of the TTZ and inside the TTZ. 10. Computation of Routing Table After a router migrates to TTZ, the computation of the routing table on the router is the same as that described in RFC 2328 section 16 with one exception. The router in a TTZ ignores the router LSAs generated by the TTZ edge routers for virtualizing the TTZ. It computes routes using the TTZ router LSAs and the regular LSAs, excluding the router LSAs for virtualizing the TTZ. That is that it computes routes using the TTZ topology and the topology outside of the TTZ, excluding the links for virtualizing the TTZ. 11. Operations 11.1. Configuring TTZ This section proposes some options for configuring a TTZ. 1. Configuring TTZ on Every Link in TTZ If every link in a TTZ is configured with a same TTZ ID as a TTZ link, the TTZ is determined. A router with some links in a TTZ and Chen, et al. Expires July 12, 2017 [Page 18] Internet-Draft Topology-Transparent Zone January 2017 some links not in this TTZ is a TTZ edge router. A router with all its links in a TTZ is a TTZ internal router. 2. Configuring TTZ on Routers in TTZ A same TTZ ID is configured on every TTZ internal router in a TTZ, and on every TTZ edge router's links connecting to the routers in the TTZ. A router configured with the TTZ ID on some of its links is a TTZ edge router. A router configured with the TTZ ID only is a TTZ internal router. All the links on a TTZ internal router are TTZ links. This option is simpler than option 1 above. For a TTZ edge router X with different TTZ IDs on its different links, router X connects two or more different TTZs. In this case, router X originates its router LSA for virtualizing the TTZs. This LSA includes the normal links connecting to routers outside of these TTZs and the virtual links to the other edge routers of each of these TTZs. Router X also originates its TTZ router LSA for each of TTZs. The TTZ router LSA for TTZ N includes the links to routers outside of these TTZs, the virtual links to the other edge routers of the other TTZs, and the TTZ links to the routers in TTZ N. 11.2. Migration to TTZ For a group of routers and a number of links connecting the routers in an area, making them transfer to work as a TTZ without any service interruption takes a few of steps or stages. At first, a user configures the TTZ feature on every router in the TTZ. In this stage, a router does not originate or advertise its TTZ topology information. It will discover its TTZ neighbors. Secondly, after configuring the TTZ, a user issues a configuration on one router in the TTZ, which triggers every router in the TTZ to generate and advertise TTZ information among the routers in the TTZ. When the router receives the configuration, it originates a TTZ control LSA with OP for T (indicating TTZ information generation and advertisement for migration). It also originates its TTZ LSA such as TTZ router LSA or TTZ indication LSA, and advertises the LSA to its TTZ neighbors. When another router in the TTZ receives the LSA with OP for T, it originates its TTZ LSA. In this stage, every router in the TTZ has dual roles. One is to function as a normal router. The other is to generate and advertise TTZ information. Thirdly, a user checks whether a router in the TTZ is ready for migration to TTZ. A router in the TTZ is ready after it has received Chen, et al. Expires July 12, 2017 [Page 19] Internet-Draft Topology-Transparent Zone January 2017 all the TTZ LSAs including TTZ router LSAs from TTZ edge routers and TTZ indication LSAs from TTZ internal routers. This information may be displayed on a router through a configuration. And then a user activates the TTZ through using a configuration such as migrate to TTZ on one router in the TTZ. The router migrates to TTZ, generates and advertises a TTZ control LSA with OP for M (indicating Migrating to TTZ) after it receives the configuration. After another router in the TTZ receives the TTZ control LSA with OP for M, it also migrates to TTZ. Thus, activating the TTZ on one TTZ router propagates to every router in the TTZ, which migrates to TTZ. For an edge router of the TTZ, migrating to work as a TTZ router comprises generating a router LSA to virtualize the TTZ and flooding this LSA to all its neighboring routers in two steps as described in section 7. In normal operations for migration to TTZ and rollback from TTZ, a user issues a series of configurations according to certain procedures. In an abnormal case, for example two conflicting configurations are issued on two TTZ routers in a TTZ at the same time, a TTZ router issues an error and logs the error when it detects a conflict. A conflicting configuration may be detected on a router on which the configuration is issued. Thus some abnormal cases may be prevented. When a configuration for migration/rollback is issued on a router, the router checks whether it is in a correct sequence of configurations for migration/rollback through using the information it has. For migrating a part of an area to a TTZ, the correct sequence of configurations is as follows in general: 1) configure TTZ on every router in the part of the area to be migrated to TTZ; 2) configure on one router in the TTZ to trigger every router in the TTZ to generate and advertise TTZ information for migration; and 3) configure on one router in the TTZ to trigger every router in the TTZ to migrate to TTZ. After receiving a configuration on a router to migrate to TTZ, which is for 3), the router checks whether 2) is performed through checking if it has received/originated TTZ LSAs. If it has not, it issues an error to an operator (generation and advertisement of TTZ information for migration to TTZ is not done yet) and rejects the configuration at this time. Chen, et al. Expires July 12, 2017 [Page 20] Internet-Draft Topology-Transparent Zone January 2017 After a router receives a TTZ LSA with OP for M for 3) from another router, it checks whether 2) is performed through checking if it has received/originated TTZ LSAs. If it has not, it issues an error and logs the error, and does not migrate to TTZ. In this case, it does not originate its router LSA for virtualizing the TTZ if it is a TTZ edge router. After receiving a configuration on a router to generate and advertise TTZ information, which is for 2), the router checks whether 1) is performed through checking if TTZ is configured on it. If it is not, it issues an error to an operator (TTZ is not configured on it yet) and rejects the configuration at this time. For rolling back from TTZ, the correct sequence of configurations is below. 1) configure on one router in the TTZ to trigger every router in the TTZ to advertise normal LSAs and stop advertising TTZ LSAs; 2) configure on one router in the TTZ to trigger every router in the TTZ to roll back from TTZ. After receiving a configuration on a router to roll back from TTZ, which is for 2), the router checks whether 1) is performed through checking if it has received TTZ LSA with OP for N. If it has not, it issues an error to an operator (advertise normal LSAs and stop advertising TTZ LSAs for rolling back from TTZ is not done yet) and rejects the configuration at this time. After a router receives a TTZ LSA with OP for R for 2) from another router, it checks whether 1) is performed through checking if it has received TTZ LSA with OP for N. If it has not, it issues an error and logs the error, and does not roll back from TTZ. After receiving a configuration on a router to advertise normal LSAs and stop advertising TTZ LSAs for rolling back from TTZ, which is for 1), the router checks whether it has any TTZ LSAs. If it does not, it issues an error to an operator (no TTZ to be rolled back) and rejects the configuration at this time. 11.3. Adding a Router into TTZ When a non TTZ router (say R1) is connected via a P2P link to a migrated TTZ router (say T1), and there is a normal adjacency between them over the link, a user can configure TTZ on both ends of the link to add R1 into the TTZ to which T1 belongs. They TTZ discover each other as described in section 8. Chen, et al. Expires July 12, 2017 [Page 21] Internet-Draft Topology-Transparent Zone January 2017 When a number of non TTZ routers are connected via a broadcast or NBMA link to a migrated TTZ router (say T1), and there are normal adjacencies among them, a user configures TTZ on the connection to the link on every router to add the non TTZ routers into the TTZ to which T1 belongs. The DR for the link "forms" TTZ adjacencies with the other routers connected to the link if they all have the same TTZ ID configured for the link. This is determined through the TTZ discovery process described in section 8. 12. Manageability Considerations Section 11 (Operations) outlines the configuration process and deployment scenarios for a TTZ. The configurable item is enabling a TTZ on a router and/or an interface on a router. The TTZ function may be controlled by a policy module and assigned a suitable user privilege level to enable. A suitable model may be required to verify the TTZ status on routers participating in the TTZ, including their role as internal or edge TTZ router. The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those indicated in [RFC2328]. 13. Security Considerations A notable beneficial security aspect of TTZ is that the TTZ is enclosed in a single area, and TTZ could be used to mask the internal topology. External routers that are not participating in the TTZ will not be aware of the internal TTZ topology. It should be noted that a malicious node could inject TTZ LSAs with the OP Field set to M or R, which could trigger the migration into/from a TTZ and may result in the isolation of some routers in the network. Good security practice might reuse the OSPF authentication and other security mechanisms described in [RFC2328] and [RFC7474], to mitigate this type of risk. 14. IANA Considerations Under Registry Name: Opaque Link-State Advertisements (LSA) Option Types [RFC5250], IANA is requested to assign a new Opaque type registry value for Topology-Transparent Zone (TTZ) LSA as follows: +====================+===============+=======================+ | Registry Value | Opaque Type | reference | +====================+===============+=======================+ | IANA TBD | TTZ LSA | This document | | (9 Suggested) | | | Chen, et al. Expires July 12, 2017 [Page 22] Internet-Draft Topology-Transparent Zone January 2017 +--------------------+---------------+-----------------------+ IANA is to create and maintain a new registry: o OSPFv2 TTZ LSA TLVs Initial values for the registry are given below. The future assignments are to be made through IETF Review. Value OSPFv2 TTZ LSA TLV Name Definition ----- ----------------------- ---------- 0 Reserved 1 TTZ ID TLV see section 6.2 2 TTZ Router TLV see section 6.3 3 TTZ Options TLV see section 6.4 4-32767 Unassigned 32768-65535 Reserved 15. Contributors and Other Authors 1. Other Authors Mehmet Toy USA Email: mehmet.toy@verizon.com Gregory Cauchie FRANCE Email: greg.cauchie@gmail.com Anil Kumar S N India Email: anil.sn@huawei.com Ning So USA Email: ningso01@gmail.com Chen, et al. Expires July 12, 2017 [Page 23] Internet-Draft Topology-Transparent Zone January 2017 Lei Liu USA Email: lliu@us.fujitsu.com 2. Contributors Veerendranatha Reddy Vallem India Email: veerendranatharv@huawei.com William McCall USA will.mccall@rightside.co 16. Acknowledgement The authors would like to thank Acee Lindem, Abhay Roy, Christian Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, Kiran Makhijani, Padmadevi Pillay Esnault and Yang Yu for their valuable comments on this draft. 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ RFC2328, April 1998, . [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . Chen, et al. Expires July 12, 2017 [Page 24] Internet-Draft Topology-Transparent Zone January 2017 [RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007, . 17.2. Informative References [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . Appendix A. Prototype Implementation A.1. What are Implemented and Tested 1. CLI Commands for TTZ The CLIs implemented and tested include: o the CLIs of the simpler option for configuring TTZ, and o the CLIs for controlling migration to TTZ. 2. Extensions to OSPF Protocols for TTZ All the extensions defined in section "Extensions to OSPF Protocols" are implemented and tested except for rolling back from TTZ. The testing results illustrate: o A TTZ is virtualized to outside as its edge routers connected each other. Any router outside of the TTZ sees the edge routers (as normal routers) connecting each other and to some other routers. o The link state information about the routers and links inside the TTZ is contained within the TTZ. It is not advertised to any router outside of the TTZ. o TTZ is transparent. From a router inside a TTZ, it sees the topology (link state) outside of the TTZ. From a router outside of the TTZ, it sees the topology beyond the TTZ. The link state information outside of the TTZ is advertised through the TTZ. Chen, et al. Expires July 12, 2017 [Page 25] Internet-Draft Topology-Transparent Zone January 2017 o TTZ is backward compatible. Any router outside of a TTZ does not need to support or know TTZ. 3. Smooth Migration to TTZ The procedures and related protocol extensions for smooth migration to TTZ are implemented and tested. The testing results show: o A part of an OSPF area is smoothly migrated to a TTZ without any routing disruptions. The routes on every router are stable while the part of the area is being migrated to the TTZ. o Migration to TTZ is very easy to operate. 4. Add a Router to TTZ Adding a router into TTZ is implemented and tested. The testing results illustrate: o A router can be easily added into a TTZ and becomes a TTZ router. o The router added into the TTZ is not seen on any router outside of the TTZ, but it is a part of the TTZ. 5. Leak TTZ Loopbacks Outside Leaking loopback addresses in a TTZ to routers outside of the TTZ is implemented and tested. The testing results illustrate: o The loopback addresses inside the TTZ are advertised to the routers outside of the TTZ. o The loopback addresses are accessible from a router outside of the TTZ. A.2. Implementation Experience The implementation of TTZ re-uses the existing OSPF code along with additional simple logic. A couple of engineers started to work on implementing the TTZ from the middle of June, 2014 and finished coding it just before the end of July, 2014. After some testing and bug fixes, it works as expected. In our implementation, the link state information in a TTZ opaque LSA is stored in the same link state database as the link state information in a normal LSA. For each TTZ link in the TTZ opaque LSA, there is an additional flag, which is used to differentiate between a TTZ link and a Normal link. Chen, et al. Expires July 12, 2017 [Page 26] Internet-Draft Topology-Transparent Zone January 2017 Before migration to TTZ, every router in the TTZ computes its routing table using the normal links. After migration to TTZ, every router in the TTZ computes its routing table using the TTZ links and normal links. In the case where both the TTZ link and the normal link exist, the TTZ link is used. Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA USA Email: huaimo.chen@huawei.com Renwei Li Huawei Technologies 2330 Central expressway Santa Clara, CA USA Email: renwei.li@huawei.com Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Raleigh, NC 27709 USA Email: aretana@cisco.com Yi Yang Sockrate USA Email: yyang1998@gmail.com Chen, et al. Expires July 12, 2017 [Page 27] Internet-Draft Topology-Transparent Zone January 2017 Zhiheng Liu China Mobile No.32 Xuanwumen West Street, Xicheng District Beijing, 100053 China Email: liu.cmri@gmail.com Chen, et al. Expires July 12, 2017 [Page 28] ./draft-ietf-avtext-rid-09.txt0000664000764400076440000004622412775522766015505 0ustar iustyiusty Network Working Group A. Roach Internet-Draft Mozilla Intended status: Standards Track S. Nandakumar Expires: April 9, 2017 Cisco Systems P. Thatcher Google October 06, 2016 RTP Stream Identifier Source Description (SDES) draft-ietf-avtext-rid-09 Abstract This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Roach, et al. Expires April 9, 2017 [Page 1] Internet-Draft RtpStreamId SDES October 2016 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage of RtpStreamId and RepairedRtpStreamId in RTP and RTCP 3 3.1. RTCP 'RtpStreamId' SDES Extension . . . . . . . . . . . . 5 3.2. RTCP 'RepairedRtpStreamId' SDES Extension . . . . . . . . 5 3.3. RTP 'RtpStreamId' and 'RepairedRtpStreamId' Header Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4.1. New RtpStreamId SDES item . . . . . . . . . . . . . . . . 6 4.2. New RepairRtpStreamId SDES item . . . . . . . . . . . . . 6 4.3. New RtpStreamId Header Extension URI . . . . . . . . . . 7 4.4. New RepairRtpStreamId Header Extension URI . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction RTP sessions frequently consist of multiple streams, each of which is identified at any given time by its SSRC; however, the SSRC associated with a stream is not guaranteed to be stable over its lifetime. Within a session, these streams can be tagged with a number of identifiers, including CNAMEs and MSIDs [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time. While approaches that use unique Payload Types (PTs) per stream have been used in some applications, this is a semantic overloading of that field, and one for which its size is inadequate: in moderately complex systems that use PT to uniquely identify every potential combination of codec configuration and unique stream, it is possible to simply run out of values. To address this situation, we define a new RTCP Stream Identifier Source Description (SDES) identifier, RtpStreamId, that uniquely identifies a single RTP stream. A key motivator for defining this identifier is the ability to differentiate among different encodings of a single Source Stream that are sent simultaneously (i.e., simulcast). This need for unique identification extends to dependent Roach, et al. Expires April 9, 2017 [Page 2] Internet-Draft RtpStreamId SDES October 2016 streams (e.g., where layers used by a layered codec are transmitted on separate streams). At the same time, when redundancy RTP streams are in use, we also need an identifier that connects such streams to the RTP stream for which they are providing redundancy. For this purpose, we define an additional SDES identifier, RepairedRtpStreamId. This identifier can appear only in packets associated with a redundancy RTP stream. They carry the same value as the RtpStreamId of the RTP stream that the redundant RTP stream is correcting. 2. Terminology In this document, the terms "source stream", "RTP stream", "source RTP stream", "dependent stream", "received RTP stream", and "redundancy RTP stream" are used as defined in [RFC7656]. The following acronyms are also used: o CNAME: Canonical End-Point Identifier, defined in [RFC3550] o MID: Media Identification, defined in [I-D.ietf-mmusic-sdp-bundle-negotiation] o MSID: Media Stream Identifier, defined in [I-D.ietf-mmusic-msid] o RTCP: Real-time Transport Control Protocol, defined in [RFC3550] o RTP: Real-time Transport Protocol, defined in [RFC3550] o SDES: Source Description, defined in [RFC3550] o SSRC: Synchronization Source, defined in [RFC3550] 3. Usage of RtpStreamId and RepairedRtpStreamId in RTP and RTCP The RTP fixed header includes the payload type number and the SSRC values of the RTP stream. RTP defines how you de-multiplex streams within an RTP session; however, in some use cases, applications need further identifiers in order to effectively map the individual RTP Streams to their equivalent payload configurations in the SDP. This specification defines two new RTCP SDES items [RFC3550]. The first item is 'RtpStreamId', which is used to carry RTP stream identifiers within RTCP SDES packets. This makes it possible for a receiver to associate received RTP packets (identifying the RTP stream) with a media description having the format constraint specified. The second is 'RepairedRtpStreamId', which can be used in Roach, et al. Expires April 9, 2017 [Page 3] Internet-Draft RtpStreamId SDES October 2016 redundancy RTP streams to indicate the RTP stream repaired by a redundancy RTP stream. To be clear: the value carried in a RepairedRtpStreamId will always match the RtpStreamId value from another RTP stream in the same session. For example, if a source RTP stream is identified by RtpStreamId "A", then any redundancy RTP stream that repairs that source RTP stream will contain a RepairedRtpStreamId of "A" (if this mechanism is being used to perform such correlation). These redundant RTP streams may also contain their own unique RtpStreamId. This specification also uses the RTP header extension for RTCP SDES items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RtpStreamId and RepairedRtpStreamId values in RTP packets. This allows correlation at stream startup, or after stream changes where the use of RTCP may not be sufficiently responsive. This speed of response is necessary since, in many cases, the stream cannot be properly processed until it can be identified. RtpStreamId and RepairedRtpStreamId values are scoped by source identifier (e.g., CNAME) and by media session. When the media is multiplexed using the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation], these values are further scoped by their associated MID values. For example: an RtpStreamId of "1" may be present in the stream identified with a CNAME of "1234@example.com", and may also be present in a stream with a CNAME of "5678@example.org", and these would refer to different streams. Similarly, an RtpStreamId of "1" may be present with an MID of "A", and again with a MID of "B", and also refer to two different streams. Note that the RepairedRtpStreamId mechanism is limited to indicating one repaired stream per redundancy stream. If systems require correlation for schemes in which a redundancy stream contains information used to repair more than one stream, they will have to use a more complex mechanism than the one defined in this specification. As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited to a total of 255 octets in length. RtpStreamId and RepairedStreamId are constrained to contain only alphanumeric characters. For avoidance of doubt, the only allowed byte values for these IDs are decimal 48 through 57, 65 through 90, and 97 through 122. Roach, et al. Expires April 9, 2017 [Page 4] Internet-Draft RtpStreamId SDES October 2016 3.1. RTCP 'RtpStreamId' SDES Extension 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RtpStreamId=TBD| length | RtpStreamId ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RtpStreamId payload is ASCII encoded and is not null-terminated. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. 3.2. RTCP 'RepairedRtpStreamId' SDES Extension 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Repaired...=TBD| length | RepairRtpStreamId ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RepairedRtpStreamId payload is ASCII encoded and is not null- terminated. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. 3.3. RTP 'RtpStreamId' and 'RepairedRtpStreamId' Header Extensions Because recipients of RTP packets will typically need to know which streams they correspond to immediately upon receipt, this specification also defines a means of carrying RtpStreamId and RepairedRtpStreamId identifiers in RTP extension headers, using the technique described in [I-D.ietf-avtext-sdes-hdr-ext]. As described in that document, the header extension element can be encoded using either the one-byte or two-byte header, and the identification-tag payload is ASCII-encoded. As the identifier is included in an RTP header extension, there should be some consideration given to the packet expansion caused by the identifier. To avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the header extension's size needs to be taken into account when encoding media. Note that the set of header extensions included in the packet needs to be padded to the next 32-bit boundary [RFC5285]. Roach, et al. Expires April 9, 2017 [Page 5] Internet-Draft RtpStreamId SDES October 2016 In many cases, a one-byte identifier will be sufficient to distinguish streams in a session; implementations are strongly encouraged to use the shortest identifier that fits their purposes. Implementors are warned, in particular, not to include any information in the identifier that is derived from potentially user- identifying information, such as user ID or IP address. To avoid identification of specific implementations based on their pattern of tag generation, implementations are encouraged to use a simple scheme that starts with the ASCII digit "1", and increments by one for each subsequent identifier. 4. IANA Considerations 4.1. New RtpStreamId SDES item RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. This document adds the RtpStreamId SDES item to the IANA "RTP SDES item types" registry as follows: Value: TBD Abbrev.: RtpStreamId Name: RTP Stream Identifier Reference: RFCXXXX 4.2. New RepairRtpStreamId SDES item RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. This document adds the RepairedRtpStreamId SDES item to the IANA "RTP SDES item types" registry as follows: Value: TBD Abbrev.: RepairedRtpStreamId Name: Repaired RTP Stream Identifier Reference: RFCXXXX Roach, et al. Expires April 9, 2017 [Page 6] Internet-Draft RtpStreamId SDES October 2016 4.3. New RtpStreamId Header Extension URI RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. This document defines a new extension URI in the RTP SDES Compact Header Extensions sub-registry of the RTP Compact Header Extensions registry sub-registry, as follows Extension URI: urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Description: RTP Stream Identifier Contact: adam@nostrum.com Reference: RFCXXXX 4.4. New RepairRtpStreamId Header Extension URI RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. This document defines a new extension URI in the RTP SDES Compact Header Extensions sub-registry of the RTP Compact Header Extensions registry sub-registry, as follows Extension URI: urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-sream-id Description: RTP Repaired Stream Identifier Contact: adam@nostrum.com Reference: RFCXXXX 5. Security Considerations Although the identifiers defined in this document are limited to be strictly alphanumeric, SDES items have the potential to carry any string. As a consequence, there exists a risk that it might carry privacy-sensitive information. Implementations need to take care when generating identifiers so that they do not contain information that can identify the user or allow for long term tracking of the device. Following the generation recommendations in Section 3.3 will result in non-instance-specific labels, with only minor fingerprinting possibilities in the total number of used RtpStreamIds and RepairedRtpStreamIds. Even if the SDES items are generated to convey as little information as possible, implementors are strongly encouraged to encrypt SDES items - both in RTCP and RTP header extensions - so as to preserve privacy against third parties. As the SDES items are used for identification of the RTP streams for different application purposes, it is important that the intended values are received. An attacker, either a third party or malicious RTP middlebox, that removes, or changes the values for these SDES Roach, et al. Expires April 9, 2017 [Page 7] Internet-Draft RtpStreamId SDES October 2016 items, can severely impact the application. The impact can include failure to decode or display the media content of the RTP stream. It can also result in incorrectly attributing media content to identifiers of the media source, such as incorrectly identifying the speaker. To prevent this from occurring due to third party attacks, integrity and source authentication is needed. Options for Securing RTP Sessions [RFC7201] discusses options for how encryption, integrity and source authentication can be accomplished. 6. Acknowledgements Many thanks for review and input from Cullen Jennings, Magnus Westerlund, Colin Perkins, Jonathan Lennox, and Paul Kyzivat. Magnus Westerlund provided substantially all of the Security Considerations section. 7. References 7.1. Normative References [I-D.ietf-avtext-sdes-hdr-ext] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for RTCP Source Description Items", draft-ietf-avtext-sdes-hdr-ext-07 (work in progress), June 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-32 (work in progress), August 2016. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . Roach, et al. Expires April 9, 2017 [Page 8] Internet-Draft RtpStreamId SDES October 2016 7.2. Informative References [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", draft-ietf-mmusic-msid-15 (work in progress), July 2016. [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . Authors' Addresses Adam Roach Mozilla Email: adam@nostrum.com Suhas Nandakumar Cisco Systems Email: snandaku@cisco.com Peter Thatcher Google Email: pthatcher@google.com Roach, et al. Expires April 9, 2017 [Page 9] ./draft-ietf-httpauth-mutual-algo-07.txt0000664000764400076440000007773513012206325017464 0ustar iustyiusty HTTPAUTH Working Group Y. Oiwa Internet-Draft H. Watanabe Intended status: Experimental H. Takagi Expires: May 18, 2017 ITRI, AIST K. Maeda T. Hayashi Lepidum Y. Ioku Individual November 14, 2016 Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms draft-ietf-httpauth-mutual-algo-07 Abstract This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 18, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Oiwa, et al. Expires May 18, 2017 [Page 1] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Cryptographic Overview (Non-normative) . . . . . . . . . . . . 3 3. Authentication Algorithms . . . . . . . . . . . . . . . . . . 4 3.1. Support Functions and Notations . . . . . . . . . . . . . 5 3.2. Functions for Discrete Logarithm Settings . . . . . . . . 6 3.3. Functions for Elliptic-Curve Settings . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. General Implementation Considerations . . . . . . . . . . 9 5.2. Cryptographic Assumptions and Considerations . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. (Informative) Group Parameters for Discrete Logarithm Based Algorithms . . . . . . . . . . . . . 11 Appendix B. (Informative) Derived Numerical Values . . . . . . . 13 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 14 C.1. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 14 C.2. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 14 C.3. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 14 C.4. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 14 C.5. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 14 C.6. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 14 C.7. Changes in Httpauth WG revision 00 . . . . . . . . . . . . 14 C.8. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 14 C.9. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 15 C.10. Changes in revision 02 . . . . . . . . . . . . . . . . . . 15 C.11. Changes in revision 01 . . . . . . . . . . . . . . . . . . 15 C.12. Changes in revision 00 . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Oiwa, et al. Expires May 18, 2017 [Page 2] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 1. Introduction This document specifies algorithms for use with Mutual authentication protocol for Hyper-Text Transport Protocol (HTTP) [I-D.ietf-httpauth-mutual] (referred as the "core specification" hereafter). The algorithms are based on "Augmented Password-based Authenticated Key Exchange" (Augmented PAKE) techniques. In particular, it uses one of three key exchange algorithms defined in ISO 11770-4: "Key management - Mechanisms based on weak secrets" [ISO.11770-4.2006] as its basis. In very brief summary, Mutual authentication protocol exchanges four values, K_c1, K_s1, VK_c and VK_s, to perform authenticated key exchanges, using the password-derived secret pi and its "augmented version" J(pi). This document defines the set of functions K_c1, K_s1, and J for a specific algorithm family. Please note that from the view of cryptographic literature, the original functionality of Augmented PAKE is separated into the functions K_c1 and K_s1 as defined in this draft, and the functions VK_c and VK_s, which are defined in Section 11 of [I-D.ietf-httpauth-mutual] as "default functions". For the purpose of security analysis, please also refer to these functions. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "natural numbers" refers to the non-negative integers (including zero) throughout this document. This document treats both the input (domain) and the output (codomain) of hash functions to be octet strings. When a natural number output of hash function H is required, it will be notated like INT(H(s)). 2. Cryptographic Overview (Non-normative) The cryptographic primitive used in this algorithm specification is based on a variant of augmented PAKE proposed by T. Kwon, called APKAS-AMP, originally submitted to IEEE P1363.2. The general flow of the successful exchange is shown below, for informative purposes only. The multiplicative notations are used for group operators, and all modulus operations for finite groups (mod q and mod r) are Oiwa, et al. Expires May 18, 2017 [Page 3] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 omitted. C: S_c1 = random C: K_c1 = g^(S_c1) ----- ID, K_c1 -----> C: t_1 = H1(K_c1) S: t_1 = H1(K_c1) S: fetch J = g^pi by ID S: S_s1 = random S: K_s1 = (J * K_c1^(t_1))^(S_s1) <----- K_s1 ----- C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1) C: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi)) S: z' = (K_c1 * g^(t_2))^(S_s1) (assumption at this point: z = z' if authentication succeeded) C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z') ----- VK_c -------> S: assert(VK_c = VK_c') C: VK_s' = H3(K_c1, K_s1, z) S: VK_s = H3(K_c1, K_s1, z') <----- VK_s ------ C: assert(VK_s = VK_s') Note that the concrete (binary) message formats (mapping to HTTP messages), as well as the formal definitions of equations for the latter two messages, are defined in core specification [I-D.ietf-httpauth-mutual]. The formal definitions for values corresponding to the first two messages are defined in the following sections. 3. Authentication Algorithms This document specifies one family of APKAS-AMP based algorithm. This family consists of four authentication algorithms, which differ only in their underlying mathematical groups and security parameters. These algorithms do not add any additional parameters. The tokens for these algorithms are o iso-kam3-dl-2048-sha256: for the 2048-bit discrete logarithm setting with the SHA-256 hash function. o iso-kam3-dl-4096-sha512: for the 4096-bit discrete logarithm setting with the SHA-512 hash function. o iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic- curve setting with the SHA-256 hash function. Oiwa, et al. Expires May 18, 2017 [Page 4] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 o iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic- curve setting with the SHA-512 hash function. For discrete logarithm settings, the underlying groups are the 2048- bit and 4096-bit MODP groups defined in [RFC3526]. See Appendix A for the exact specifications of the groups and associated parameters. The hash functions H are SHA-256 for the 2048-bit group and SHA-512 for the 4096-bit group, respectively, defined in FIPS PUB 180-2 [FIPS.180-2.2002]. The hash iteration count nIterPi is 16384. The representation of the parameters kc1, ks1, vkc, and vks is base64- fixed-number. For the elliptic-curve settings, the underlying groups are the elliptic curves over the prime fields P-256 and P-521, respectively, specified in the appendix D.1.2 of the FIPS PUB 186-4 [FIPS.186-4.2013] specification. The hash functions H, which are referenced by the core document, are SHA-256 for the P-256 curve and SHA-512 for the P-521 curve, respectively. Cofactors of these curves are 1. The hash iteration count nIterPi is 16384. The representation of the parameters kc1, ks1, vkc, and vks is hex-fixed- number. Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3) defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006] with a few modifications/improvements. However, implementers should use this document as the normative reference, because the algorithm has been changed in several minor details as well as with major improvements. 3.1. Support Functions and Notations The algorithm definitions use the support functions and notations defined below: The integers in the specification are in decimal by default, or in hexadecimal when prefixed with "0x". The functions named octet(), OCTETS(), and INT() are those defined in the core specification [I-D.ietf-httpauth-mutual]. Note: The definition of OCTETS() is different from the function GE2OS_x in the original ISO specification, which takes the shortest representation without preceding zeros. All of the algorithms defined in this specification use the default functions defined in the core specification (defined in Section 11 of [I-D.ietf-httpauth-mutual]) for computing the values pi, VK_c and VK_s. Oiwa, et al. Expires May 18, 2017 [Page 5] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 3.2. Functions for Discrete Logarithm Settings In this section, an equation (x / y mod z) denotes a natural number w less than z that satisfies (w * y) mod z = x mod z. For the discrete logarithm, we refer to some of the domain parameters by using the following symbols: o q: for "the prime" defining the MODP group. o g: for "the generator" associated with the group. o r: for the order of the subgroup generated by g. The function J is defined as J(pi) = g^(pi) mod q. The value of K_c1 is derived as K_c1 = g^(S_c1) mod q, where S_c1 is a random integer within range [1, r-1] and r is the size of the subgroup generated by g. In addition, S_c1 MUST be larger than log(q)/log(g) (so that g^(S_c1) > q). The server MUST check the condition 1 < K_c1 < q-1 upon reception. Let an intermediate value t_1 be t_1 = INT(H(octet(1) | OCTETS(K_c1))), the value of K_s1 is derived from J(pi) and K_c1 as: K_s1 = (J(pi) * K_c1^(t_1))^(S_s1) mod q where S_s1 is a random number within range [1, r-1]. The value of K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held, the server MUST reject the exchange. The client MUST check this condition upon reception. Let an intermediate value t_2 be t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), the value z on the client side is derived by the following equation: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi) mod r) mod q. Oiwa, et al. Expires May 18, 2017 [Page 6] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 The value z on the server side is derived by the following equation: z = (K_c1 * g^(t_2))^(S_s1) mod q. (Note: the original ISO specification contained a message pair containing verification of value z along with the "transcript" of the protocol exchange. This functionality is contained in the functions VK_c and VK_s.) 3.3. Functions for Elliptic-Curve Settings For the elliptic-curve setting, we refer to some of the domain parameters by the following symbols: o q: for the prime used to define the group. o G: for the point defined with the underlying group called "the generator". o h: for the cofactor of the group. o r: for the order of the subgroup generated by G. The function P(p) converts a curve point p into an integer representing point p, by computing x * 2 + (y mod 2), where (x, y) are the coordinates of point p. P'(z) is the inverse of function P, that is, it converts an integer z to a point p that satisfies P(p) = z. If such p exists, it is uniquely defined. Otherwise, z does not represent a valid curve point. The operator + indicates the elliptic-curve group operation, and the operation [x] * p denotes an integer-multiplication of point p: it calculates p + p + ... (x times) ... + p. See the literature on elliptic-curve cryptography for the exact algorithms used for those functions (e.g. Section 3 of [RFC6090], which uses different notations, though). 0_E represents the infinity point. The equation (x / y mod z) denotes a natural number w less than z that satisfies (w * y) mod z = x mod z. The function J is defined as J(pi) = [pi] * G. The value of K_c1 is derived as K_c1 = P(K_c1'), where K_c1' = [S_c1] * G, where S_c1 is a random number within range [1, r-1]. The server MUST Oiwa, et al. Expires May 18, 2017 [Page 7] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 check that the value of received K_c1 represents a valid curve point, and [h] * K_c1' is not equal to 0_E. Let an intermediate integer t_1 be t_1 = INT(H(octet(1) | OCTETS(K_c1))), the value of K_s1 is derived from J(pi) and K_c1' = P'(K_c1) as: K_s1 = P([S_s1] * (J(pi) + [t_1] * K_c1')), where S_s1 is a random number within range [1, r-1]. The value of K_s1 MUST represent a valid curve point and satisfy [h] * P'(K_s1) <> 0_E. If this condition is not satisfied, the server MUST reject the exchange. The client MUST check this condition upon reception. Let an intermediate integer t_2 be t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), the value z on the client side is derived by the following equation: z = P([(S_c1 + t_2) / (S_c1 * t_1 + pi) mod r] * P'(K_s1)). The value z on the server side is derived by the following equation: z = P([S_s1] * (P'(K_c1) + [t_2] * G)). 4. IANA Considerations This document defines four new tokens to be added to the "HTTP Mutual authentication algorithms" registry; iso-kam3-dl-2048-sha256, iso-kam3-dl-4096-sha512, iso-kam3-ec-p256-sha256 and iso-kam3-ec-p521-sha512, as follows: +-------------------------+-------------------------+---------------+ | Token | Description | Specification | +-------------------------+-------------------------+---------------+ | iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | This document | | | 2048-bit DL | | | iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | This document | | | 4096-bit DL | | | iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | This document | | | 256-bit EC | | | iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | This document | | | 521-bit EC | | +-------------------------+-------------------------+---------------+ Oiwa, et al. Expires May 18, 2017 [Page 8] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 5. Security Considerations Please refer to the corresponding section of the core specification [I-D.ietf-httpauth-mutual] for algorithm-independent considerations. 5.1. General Implementation Considerations o During the exchange, the value VK_s, defined in [I-D.ietf-httpauth-mutual], MUST only be sent when the server has received a correct (expected) value of VK_c. This is a cryptographic requirement, stated in [ISO.11770-4.2006]. o All random numbers used in these algorithms MUST be at least cryptographically computationally secure against forward and backward guessing attacks. o Computation times of all numerical operations on discrete logarithm group elements and elliptic-curve points MUST be normalized and made independent of the exact values, to prevent timing-based side-channel attacks. 5.2. Cryptographic Assumptions and Considerations The notices in this subsection are for those who analyze the security of this algorithm, and those who might want to make a derived work from this algorithm specification. o handling of an invalid K_s1 value in the exchange has been changed from the original ISO specification. The original specifies that the sender should retry with another random S_s1 value, while we specify that the exchange must be rejected. This is due to an observation that this condition is less likely to result from the random error caused by an unlucky choice of S_s1, but more likely the result of a systematic failure from an invalid J(pi) value (even implying possible denial-of-service attacks). o The usual construction of authenticated key exchange algorithms consists of a key exchange phase and a key verification phase. The latter usually involves some kinds of exchange transaction to be verified, to avoid security risks or vulnerabilities caused by mixing values from from two or more key exchanges. In the design of the algorithms in this document, such a functionality is defined in a generalized manner in the core specification [I-D.ietf-httpauth-mutual] (see definitions of VK_c and VK_s). If the algorithm defined above is used in other protocols, this aspect MUST be given careful consideration. Oiwa, et al. Expires May 18, 2017 [Page 9] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 o The domain parameters chosen and specified in this draft are based on a few assumptions. In the discrete-logarithm setting, q has to be a safe prime ([(q - 1) / 2] must also be prime), and r should be the largest possible value [(q - 1) / 2]. In the elliptic- curve setting, r has to be prime. Defining a variation of this algorithm using a different domain parameter SHOULD be attentive to these conditions. 6. References 6.1. Normative References [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [FIPS.186-4.2013] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013, . [I-D.ietf-httpauth-mutual] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "Mutual Authentication Protocol for HTTP", draft-ietf-httpauth-mutual-11 (work in progress), November 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, . 6.2. Informative References [ISO.11770-4.2006] International Organization for Standardization, "Information technology - Security techniques - Key management - Part 4: Mechanisms based on weak secrets", ISO Standard 11770-4, May 2006. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Oiwa, et al. Expires May 18, 2017 [Page 10] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/ RFC6090, February 2011, . Appendix A. (Informative) Group Parameters for Discrete Logarithm Based Algorithms The MODP group used for the iso-kam3-dl-2048-sha256 algorithm is defined by the following parameters. The prime is: q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF. The generator is: g = 2. The size of the subgroup generated by g is: r = (q - 1) / 2 = 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 0AB9472D 45565534 7FFFFFFF FFFFFFFF. The MODP group used for the iso-kam3-dl-4096-sha512 algorithm is defined by the following parameters. The prime is: Oiwa, et al. Expires May 18, 2017 [Page 11] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 FFFFFFFF FFFFFFFF. The generator is: g = 2. The size of the subgroup generated by g is: Oiwa, et al. Expires May 18, 2017 [Page 12] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 r = (q - 1) / 2 = 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32 767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263 D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735 F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006 5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598 A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED 12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553 143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6 8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54 C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC FFFFFFFF FFFFFFFF. Appendix B. (Informative) Derived Numerical Values This section provides several numerical values for implementing this protocol, derived from the above specifications. The values shown in this section are for informative purposes only. +----------------+---------+---------+---------+---------+----------+ | | dl-2048 | dl-4096 | ec-p256 | ec-p521 | | +----------------+---------+---------+---------+---------+----------+ | Size of K_c1 | 2048 | 4096 | 257 | 522 | (bits) | | etc. | | | | | | | hSize, Size of | 256 | 512 | 256 | 512 | (bits) | | H(...) | | | | | | | length of | 256 | 512 | 33 | 66 | (octets) | | OCTETS(K_c1) | | | | | | | etc. | | | | | | | length of kc1, | 344 * | 684 * | 66 | 132 | (octets) | | ks1 param. | | | | | | | values. | | | | | | | length of vkc, | 44 * | 88 * | 64 | 128 | (octets) | | vks param. | | | | | | | values. | | | | | | Oiwa, et al. Expires May 18, 2017 [Page 13] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 | minimum | 2048 | 4096 | 1 | 1 | | | allowed S_c1 | | | | | | +----------------+---------+---------+---------+---------+----------+ (The numbers marked with an * do not include any enclosing quotation marks.) Appendix C. (Informative) Draft Change Log C.1. Changes in Httpauth WG Revision 06 o Authors' addresses updated. C.2. Changes in Httpauth WG Revision 05 o Several comments from reviewers are reflected to the text. C.3. Changes in Httpauth WG revision 04 o Authors address updated. C.4. Changes in Httpauth WG revision 03 o IANA registration information added. C.5. Changes in Httpauth WG revision 02 o No technical changes: references updated. C.6. Changes in Httpauth WG revision 01 o Changed behavior on failed generation of K_s1. o Security considerations updated. C.7. Changes in Httpauth WG revision 00 o Added a note on the choice of elliptic curves. C.8. Changes in HTTPAUTH revision 02 o Added nIterPi parameter to adjust to the changes to the core draft. o Added a note on the verification of exchange transaction. Oiwa, et al. Expires May 18, 2017 [Page 14] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 C.9. Changes in HTTPAUTH revision 01 o Notation change: integer output of hash function will be notated as INT(H(*)), changed from H(*). C.10. Changes in revision 02 o Implementation hints in appendix changed (number of characters for base64-fixed-number does not contain double-quotes). C.11. Changes in revision 01 o Parameter names renamed. o Some expressions clarified without changing the value. C.12. Changes in revision 00 The document is separated from the revision 08 of the core documentation. Authors' Addresses Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: y.oiwa@aist.go.jp Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: h-watanabe@aist.go.jp Oiwa, et al. Expires May 18, 2017 [Page 15] Internet-Draft HTTP Mutual Authentication: algorithms November 2016 Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: takagi.hiromitsu@aist.go.jp Kaoru Maeda Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Email: maeda@lepidum.co.jp Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Email: hayashi@lepidum.co.jp Yuichi Ioku Individual Email: mutual-work@ioku.org Oiwa, et al. Expires May 18, 2017 [Page 16] ./draft-ietf-avtext-splicing-notification-09.txt0000664000764400076440000013076712750316522021211 0ustar iustyiusty AVTEXT Working Group J. Xia INTERNET-DRAFT R. Even Intended Status: Standards Track R. Huang Expires: February 4, 2017 Huawei L. Deng China Mobile August 3, 2016 RTP/RTCP extension for RTP Splicing Notification draft-ietf-avtext-splicing-notification-09 Abstract Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Xia Expires February 4, 2017 [Page 1] INTERNET DRAFT RTP Splicing Notification August 3, 2016 Copyright and License Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Overview of RTP Splicing . . . . . . . . . . . . . . . . . . 4 2.2 Overview of Splicing Interval . . . . . . . . . . . . . . . 5 3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5 3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9 6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 14 8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 14 8.3 SDP Grouping Semantic Extension . . . . . . . . . . . . . . 14 9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 10.2 Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Xia Expires February 4, 2017 [Page 2] INTERNET DRAFT RTP Splicing Notification August 3, 2016 1 Introduction Splicing is a process that replaces some multimedia content with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. In some predictable splicing cases, e.g., advertisement insertion, the splicing duration needs to be inside of the specific, pre-designated time slot. Certain timing information about when to start and end the splicing must be first acquired by the splicer in order to start the splicing. This document refers to this information as the Splicing Interval. [SCTE35] provides a method that encapsulates the Splicing Interval inside the MPEG2-TS layer in cable TV systems. When transported in RTP, an middle box designed as the splicer to decode the RTP packets and search for the Splicing Interval inside the payloads is required. The need for such processing increases the workload of the middle box and limits the number of RTP sessions the middle box can support. The document defines an RTP header extension [RFC5285bis] used by the main RTP sender to provide the Splicing Interval by including it in the RTP packets. However, the Splicing Interval conveyed in the RTP header extension might not reach the splicer successfully. Any splicing un-aware middlebox on the path between the RTP sender might strip this RTP header extension. To increase robustness against such case, the document also defines a new RTCP packet type to carry the same Splicing Interval to the splicer. Since RTCP is also unreliable and may not be so immediate as the in-band way, it's only considered as a complement to the RTP header extension. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In addition, we define following terminologies: Main RTP sender: The sender of RTP packets carrying the main RTP stream. Splicer: An intermediary node that inserts substitutive content into a main Xia Expires February 4, 2017 [Page 3] INTERNET DRAFT RTP Splicing Notification August 3, 2016 RTP stream. The splicer sends substitutive content to the RTP receiver instead of the main content during splicing. It is also responsible for processing RTCP traffic between the RTP sender and the RTP receiver. Splicing-In Point A virtual point in the RTP stream, suitable for substitutive content entry, typically in the boundary between two independently decodable frames. Splicing-Out Point A virtual point in the RTP stream, suitable for substitutive content exit, typically in the boundary between two independently decodable frames. Splicing Interval: The NTP-format timestamps, representing the main RTP sender wallclock time, for the Splicing-In point and Splicing-Out point per [RFC6828] allowing the splicer to know when to start and end the RTP splicing. Substitutive RTP Sender: The sender of RTP packets carrying the RTP stream that will replace the content in the main RTP stream. 2 Overview 2.1 Overview of RTP Splicing RTP Splicing is intended to replace some multimedia content with certain substitutive multimedia content, and then forward it to the receivers for a period of time. This process is authorized by the main RTP sender that offers a specific time window for inserting the substitutive multimedia content in the main content. A typical usage is that IPTV service provider uses its own regional advertising content to replace national advertising content, the time window of which is explicitly indicated by the IPTV service provider. The splicer is a middlebox handling RTP splicing. It receives main content and substitutive content simultaneously but only chooses to send one of them to the receiver at any point of time. When RTP splicing begins, the splicer sends the substitutive content to the receivers instead of the main content. When RTP splicing ends, the splicer switches back to sending the main content to the receivers. Xia Expires February 4, 2017 [Page 4] INTERNET DRAFT RTP Splicing Notification August 3, 2016 This implies that the receiver is explicitly configured to receive the traffic via the splicer, and will return any RTCP feedback to it in the presence of the splicer. The middlebox working as the splicer can be implemented as either an RTP mixer or as an RTP translator. If implemented as an RTP mixer, the splicer will use its own SSRC, sequence number space, and timing model when generating the output stream to receivers, using the CSRC list to indicate whether the original or substitutive content is being delivered. The splicer, on behalf of the content provider, can omit the CSRC list from the RTP packets it generates. This simplifies the design of the receivers, since they don't need to parse the CSRC list, but makes it harder to determine when the splicing is taking place (it requires inspection of the RTP payload data, rather than just the RTP headers). A splicer working as an RTP mixer splits the flow between the sender and receiver into two, and requires separate control loops, for RTCP and congestion control. [RFC6828] offers an example of an RTP mixer approach. A splicer implemented as an RTP translator [RFC3550] will forward the RTP packets from the original and substitutive senders with their SSRCs intact, but will need to rewrite RTCP sender report packets to account for the splicing. In this case, the congestion control loops run between original sender and receiver, and between the substitutive sender and receiver. The splicer needs to ensure that the RTCP feedback message from the receiver are passed to the right sender to let the congestion control work. 2.2 Overview of Splicing Interval To handle splicing on the RTP layer at the reserved time slots set by the main RTP sender, the splicer must first know the Splicing Interval from the main RTP sender before it can start splicing. When a new splicing is forthcoming, the main RTP sender needs to send the Splicing Interval to the splicer. The Splicing Interval SHOULD be sent by RTP header extension or RTCP extension message more than once to mitigate the possible packet loss. To enable the splicer to get the substitutive content before the splicing starts, the main RTP sender MUST send the Splicing Interval far ahead. For example, the main RTP sender can estimate when to send the Splicing Interval based on the round-trip time (RTT) following the mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender. The substitutive sender also needs to learn the Splicing Interval from the main RTP sender in advance, and thus estimates when to transfer the substitutive content to the splicer. The Splicing Interval could be transmitted from the main RTP sender to the Xia Expires February 4, 2017 [Page 5] INTERNET DRAFT RTP Splicing Notification August 3, 2016 substitutive content using some out-of-band mechanisms, for example, a proprietary mechanism to exchange the Splicing Interval, or the substitutive sender is implemented together with the main RTP sender inside a single device. To ensure the Splicing Interval is valid for both the main RTP sender and the substitutive RTP sender, the two senders MUST share a common reference clock so that the splicer can achieve accurate splicing. The requirements for the common reference clock (e.g. resolution, skew) depend on the codec used by the media content. In this document, the main RTP sender uses a pair of NTP-format timestamps, to indicate when to start and end the splicing to the splicer: the timestamp of the first substitutive RTP packet at the splicing in point, and the timestamp of the first main RTP packet at the splicing out point. When the substitutive RTP sender gets the Splicing Interval, it must prepare the substitutive stream. The main and the substitutive content providers MUST ensure that the RTP timestamp of the first substitutive RTP packet that would be presented to the receivers corresponds to the same time instant as the former NTP-format timestamp in the Splicing Interval. To enable the splicer to know the first substitutive RTP packet it needs to send, the substitutive RTP sender MUST send the substitutive RTP packet ahead of the Splicing In point, allowing the splicer to find out the timestamp of this first RTP packet in the substitutive RTP stream, e.g., using a prior RTCP SR (Sender Report) message. When the splicing will end, the main content provider and the substitutive content provider MUST ensure the RTP timestamp of the first main RTP packet that would be presented on the receivers corresponds to the same time instant as the latter NTP-format timestamp in the Splicing Interval. 3 Conveying Splicing Interval in RTP/RTCP extensions This memo defines two backwards compatible RTP extensions to convey the Splicing Interval to the splicer: an RTP header extension and an RTCP splicing notification message. 3.1 RTP Header Extension The RTP header extension mechanism defined in [RFC5285bis] can be adapted to carry the Splicing Interval consisting of a pair of NTP- format timestamps. Xia Expires February 4, 2017 [Page 6] INTERNET DRAFT RTP Splicing Notification August 3, 2016 This RTP header extension carries the 7 octets splicing-out NTP- format timestamp (lower 24-bit part of the Seconds of a NTP-format timestamp and the 32 bits of the Fraction of a NTP-format timestamp as defined in [RFC5905]), followed by the 8 octets splicing-in NTP- format timestamp (64-bit NTP-format timestamp as defined in [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are inferred from the top 8 bits of the splicing-in NTP timestamp, under the assumption that the splicing-out time is after the splicing-in time, and the splicing interval is less than 2^25 seconds. Therefore, if the value of 7 octets splicing-out NTP-format timestamp is smaller than the value of 7 lower octets splicing-in NTP-format, it implies a wrap of the 56-bit splicing-out NTP-format timestamp which means the top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 bits of splicing-out NTP timestamp is equal to the top 8 bits of splicing-in NTP Timestamp. This RTP header extension can be encoded using either the one-byte or two-byte header defined in [RFC5285bis]. Figure 1 and 2 show the splicing interval header extension with each of the two header formats. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | ID | L=14 | OUT NTP timestamp format - Seconds (bit 8-31) |x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | OUT NTP timestamp format - Fraction (bit 0-31) |e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | IN NTP timestamp format - Seconds (bit 0-31) |s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | IN NTP timestamp format - Fraction (bit 0-31) |o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n Figure 1: Splicing Interval Using the One-Byte Header Format Xia Expires February 4, 2017 [Page 7] INTERNET DRAFT RTP Splicing Notification August 3, 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | ID | L=15 | OUT NTP timestamp - Seconds |x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t |Out Secds(cont)| OUT NTP timestamp format - Fraction |e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n |Out Fract(cont)| IN NTP timestamp format - Seconds |s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | In Secds(cont)| IN NTP timestamp format - Fraction |o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | In Fract(cont)| 0 (pad) | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Splicing Interval Using the Two-Byte Header Format Since the inclusion of an RTP header extension will reduce the efficiency of RTP header compression, it is RECOMMENDED that the main sender inserts the RTP header extensions into only a number of RTP packets, instead of all the RTP packets, prior to the splicing in. After the splicer obtains the RTP header extension and derives the Splicing Interval, it generates its own stream and is not allowed to include the RTP header extension in outgoing packets to reduce header overhead. 3.2 RTCP Splicing Notification Message In addition to the RTP header extension, the main RTP sender includes the Splicing Interval in an RTCP splicing notification message. Whether or not the timestamps are included in the RTP header extension, the main RTP sender MUST send the RTCP splicing notification message. This provide robustness in the case where a middlebox strips RTP header extensions. The main RTP sender MUST make sure the splicing information contained in the RTCP splicing notification message consistent with the information included in the RTP header extensions. The RTCP splicing notification message is a new RTCP packet type. It has a fixed header followed by a pair of NTP-format timestamps: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|reserved | PT=TBA | length | Xia Expires February 4, 2017 [Page 8] INTERNET DRAFT RTP Splicing Notification August 3, 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IN NTP Timestamp (most significant word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IN NTP Timestamp (least significant word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUT NTP Timestamp (most significant word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUT NTP Timestamp (least significant word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: RTCP Splicing Notification Message The RSI packet includes the following fields: Length: 16 bits As defined in [RFC3550], the length of the RTCP packet in 32-bit words minus one, including the header and any padding. SSRC: 32 bits The SSRC of the Main RTP Sender. Timestamp: 64 bits Indicates the wallclock time when this splicing starts and ends. The full-resolution NTP-format timestamp is used, which is a 64- bit, unsigned, fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. This format is same as the NTP timestamp field in the RTCP Sender Report (Section 6.4.1 of [RFC3550]). The RTCP splicing notification message can be included in the RTCP compound packet together with RTCP SR generated at the main RTP sender, and hence follows the compound RTCP rules defined in Section 6.1 in [RFC3550]. If the use of non-compound RTCP [RFC5506] was previously negotiated between the sender and the splicer, the RTCP splicing notification message may be sent as non-compound RTCP packets. In some cases that the mapping from RTP timestamp to NTP timestamp changes, e.g., clock drift happening before the splicing event, it may be required to send RTCP SR or even updated Splicing Interval information timely to update the timestamp mapping for accurate splicing. Xia Expires February 4, 2017 [Page 9] INTERNET DRAFT RTP Splicing Notification August 3, 2016 Since the RTCP splicing notification message is intentionally sent by the main RTP sender to the splicer, the splicer is not allowed to forward this message to the receivers so as to avoid their useless processing and additional RTCP bandwidth consumption in the downstream. 4 Reducing Splicing Latency When splicing starts or ends, the splicer outputs the multimedia content from another sender to the receivers. Given that the receivers must first acquire certain information ([RFC6285] refers to this information as Reference Information) to start processing the multimedia data, either the main RTP sender or the substitutive sender SHOULD provide the Reference Information together with its multimedia content to reduce the delay caused by acquiring the Reference Information. The methods by which the Reference Information is distributed to the receivers is out of scope of this memo. Another latency element is synchronization caused delay. The receivers must receive enough synchronization metadata prior to synchronizing the separate components of the multimedia streams when splicing starts or ends. Either the main RTP sender or the substitutive sender SHOULD send the synchronization metadata early enough so that the receivers can play out the multimedia in a synchronized fashion. The main RTP sender or the substitutive sender can estimate when to send the synchronization metadata based on, for example, the round-trip time (RTT) following the mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender or the substitutive sender. The main RTP sender and the substitutive sender can also be coordinated by some proprietary out- of-band mechanisms to decide when and whom to send the metadata. If both send the information, the splicer SHOULD pick one based on the current situation, e.g., choosing main RTP sender when synchronizing the main media content while choosing the information from the substitutive sender when synchronizing the spliced content. The mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to reduce the possible synchronization delay. Xia Expires February 4, 2017 [Page 10] INTERNET DRAFT RTP Splicing Notification August 3, 2016 5 Failure Cases This section examines the implications of losing RTCP splicing notification message and the other failure case, e.g., the RTP header extension is stripped on the path. Given that there may be a splicing un-aware middlebox on the path between the main RTP sender and the splicer, the main and the substitutive RTP senders can use one heuristic to verify whether or not the Splicing Interval reaches the splicer. The splicer can be implemented to have its own SSRC, and send RTCP reception reports to the senders of the main and substitutive RTP streams. This allows the senders to detect problems on the path to the splicer. Alternatively, it is possible to implement the splicer such that it has no SSRC, and does not send RTCP reports; this prevents the senders from being able to monitor the quality to the path to the splicer. If the splicer has an SSRC and sends its own RTCP reports, it can choose not to pass RTCP reports it receives from the receivers to the senders. This will stop the senders from being able to monitor the quality of the paths from the splicer to the receivers. A splicer that has an SSRC can choose to pass RTCP reception reports from the receivers back to the senders, after modifications to account for the splicing. This will allow the senders the monitor the quality of the paths from the splicer to the receivers. A splicer that does not have its own SSRC has to forward and translation RTCP reports from the receiver, otherwise the senders will not see any receivers in the RTP session. If the splicer is implemented as a mixer, it will have its own SSRC and will send its own RTCP reports, and will forward translated RTCP reports from the receivers. Upon the detection of a failure, the splicer can communicate with the main sender and the substitutive sender in some out of band signaling ways to fall back to the payload specific mechanisms it supports, e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon the splicing. 6 Session Description Protocol (SDP) Signaling This document defines the URI for declaring this header extension in an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- interval". Xia Expires February 4, 2017 [Page 11] INTERNET DRAFT RTP Splicing Notification August 3, 2016 This document extends the standard semantics defined in SDP Grouping Framework [RFC5888] with a new semantic: SPLICE to represent the relationship between the main RTP stream and the substitutive RTP stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP stream is the one with the extended extmap attribute, and the other one is substitutive stream. A single m-line MUST NOT be included in different SPLICE groups at the same time. The main RTP sender provides the information about both main and substitutive sources. The extended SDP attribute specified in this document is applicable for offer/answer content [RFC3264] and do not affect any rules when negotiating offer and answer. When used with multiple m-lines, substitutive RTP MUST be applied only to the RTP packets whose SDP m- line is in the same group with the substitutive stream using SPLICE and has the extended splicing extmap attribute. This semantic is also applicable for BUNDLE cases. The following examples show how SDP signaling could be used for splicing in different cases. 6.1 Declarative SDP v=0 o=xia 1122334455 1122334466 IN IP4 splicing.example.com s=RTP Splicing Example t=0 0 a=group:SPLICE 1 2 m=video 30000 RTP/AVP 100 i=Main RTP Stream c=IN IP4 233.252.0.1/127 a=rtpmap:100 MP2T/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=mid:1 m=video 30002 RTP/AVP 100 i=Substitutive RTP Stream c=IN IP4 233.252.0.2/127 a=sendonly a=rtpmap:100 MP2T/90000 a=mid:2 Figure 3: Example SDP for a single-channel splicing scenario The splicer receiving the SDP message above receives one MPEG2-TS stream (payload 100) from the main RTP sender (with multicast destination address of 233.252.0.1) on port 30000, and/or receives another MPEG2-TS stream from the substitutive RTP sender (with multicast destination address of 233.252.0.2) on port 30002. But at a particular point in time, the splicer only selects one stream and Xia Expires February 4, 2017 [Page 12] INTERNET DRAFT RTP Splicing Notification August 3, 2016 outputs the content from the chosen stream to the downstream receivers. 6.2 Offer/Answer without BUNDLE SDP Offer - from main RTP sender v=0 o=xia 1122334455 1122334466 IN IP4 splicing.example.com s=RTP Splicing Example t=0 0 a=group:SPLICE 1 2 m=video 30000 RTP/AVP 31 100 i=Main RTP Stream c=IN IP4 splicing.example.com a=rtpmap:31 H261/90000 a=rtpmap:100 MP2T/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=sendonly a=mid:1 m=video 40000 RTP/AVP 31 100 i=Substitutive RTP Stream c=IN IP4 substitutive.example.com a=rtpmap:31 H261/90000 a=rtpmap:100 MP2T/90000 a=sendonly a=mid:2 SDP Answer - from splicer v=0 o=xia 1122334455 1122334466 IN IP4 splicer.example.com s=RTP Splicing Example t=0 0 a=group:SPLICE 1 2 m=video 30000 RTP/AVP 100 i=Main RTP Stream c=IN IP4 splicer.example.com a=rtpmap:100 MP2T/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=recvonly a=mid:1 m=video 40000 RTP/AVP 100 i=Substitutive RTP Stream c=IN IP4 splicer.example.com a=rtpmap:100 MP2T/90000 a=recvonly a=mid:2 Xia Expires February 4, 2017 [Page 13] INTERNET DRAFT RTP Splicing Notification August 3, 2016 6.3 Offer/Answer with BUNDLE: All Media are spliced In this example, the bundled audio and video media have their own substitutive media for splicing: 1. An Offer, in which the offerer assigns a unique address and a substitutive media to each bundled "m="line for splicing within the BUNDLE group. 2. An answer, in which the answerer selects its own BUNDLE address, and leave the substitutive media untouched. SDP Offer - from main RTP sender v=0 o=alice 1122334455 1122334466 IN IP4 splicing.example.com s=RTP Splicing Example c=IN IP4 splicing.example.com t=0 0 a=group:SPLICE foo 1 a=group:SPLICE bar 2 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=sendonly m=video 10002 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=sendonly m=audio 20000 RTP/AVP 0 8 97 i=Substitutive audio RTP Stream c=IN IP4 substitive.example.com a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=sendonly a=mid:1 m=video 20002 RTP/AVP 31 32 i=Substitutive video RTP Stream Xia Expires February 4, 2017 [Page 14] INTERNET DRAFT RTP Splicing Notification August 3, 2016 c=IN IP4 substitive.example.com a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=mid:2 a=sendonly SDP Answer - from the splicer v=0 o=bob 2808844564 2808844564 IN IP4 splicer.example.com s=RTP Splicing Example c=IN IP4 splicer.example.com t=0 0 a=group:SPLICE foo 1 a=group:SPLICE bar 2 a=group:BUNDLE foo bar m=audio 30000 RTP/AVP 0 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=recvonly m=video 30000 RTP/AVP 32 a=mid:bar b=AS:1000 a=rtpmap:32 MPV/90000 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=recvonly m=audio 30002 RTP/AVP 0 i=Substitutive audio RTP Stream c=IN IP4 splicer.example.com a=rtpmap:0 PCMU/8000 a=recvonly a=mid:1 m=video 30004 RTP/AVP 32 i=Substitutive video RTP Stream c=IN IP4 splicer.example.com a=rtpmap:32 MPV/90000 a=mid:2 a=recvonly 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced In this example, the substitutive media only applies for video when splicing: 1. An Offer, in which the offerer assigns a unique address to each bundled "m="line within the BUNDLE group, and assigns a substitutive Xia Expires February 4, 2017 [Page 15] INTERNET DRAFT RTP Splicing Notification August 3, 2016 media to the bundled video "m=" line for splicing. 2. An answer, in which the answerer selects its own BUNDLE address, and leave the substitutive media untouched. SDP Offer - from the main RTP sender: v=0 o=alice 1122334455 1122334466 IN IP4 splicing.example.com s=RTP Splicing Example c=IN IP4 splicing.example.com t=0 0 a=group:SPLICE bar 2 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=sendonly m=video 10002 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=sendonly m=video 20000 RTP/AVP 31 32 i=Substitutive video RTP Stream c=IN IP4 substitutive.example.com a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=mid:2 a=sendonly SDP Answer - from the splicer: v=0 o=bob 2808844564 2808844564 IN IP4 splicer.example.com s=RTP Splicing Example c=IN IP4 splicer.example.com t=0 0 a=group:SPLICE bar 2 a=group:BUNDLE foo bar m=audio 30000 RTP/AVP 0 a=mid:foo b=AS:200 Xia Expires February 4, 2017 [Page 16] INTERNET DRAFT RTP Splicing Notification August 3, 2016 a=rtpmap:0 PCMU/8000 a=recvonly m=video 30000 RTP/AVP 32 a=mid:bar b=AS:1000 a=rtpmap:32 MPV/90000 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=recvonly m=video 30004 RTP/AVP 32 i=Substitutive video RTP Stream c=IN IP4 splicer.example.com a=rtpmap:32 MPV/90000 a=mid:2 a=recvonly 7 Security Considerations The security considerations of the RTP specification [RFC3550] and the general mechanism for RTP header extensions [RFC5285bis] apply. The splicer can either be a mixer or a translator, and all the security considerations of these two RTP intermediaries topologies described in [RFC7667] and [RFC7201] are applicable for the splicer. The splicer replaces some content with other content in RTP packet, thus breaking any RTP-level end-to-end security, such as source authentication and integrity protection. End to end source authentication is not possible with any known existing splicing solution. A new solution can theoretically be developed that enables identification of the participating entities and what each provides, i.e., the different media sources, main and substituting, and the splicer which provides the RTP-level integration of the media payloads in a common timeline and synchronization context. Since the splicer breaks RTP-level end-to-end security, it needs to be part of the signaling context and the necessary security associations (e.g., SRTP crypto contexts) established for the RTP session participants. When using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer would have to be provisioned with the same security association as the main RTP sender. If there is a concern about the confidentiality of the splicing time information, the header extension defined in this document MUST be also protected, for example, header extension encryption [RFC6904] can be used in this case. However, the malicious endpoint may get the splicing time information by other means, e.g., inferring from the communication between the main and substitutive content sources. To avoid the insertion of invalid substitutive content, the splicer MUST have some mechanisms to authenticate the substitutive stream source. Xia Expires February 4, 2017 [Page 17] INTERNET DRAFT RTP Splicing Notification August 3, 2016 For cases that the splicing time information is changed by a malicious endpoint, the splicing, for example, may fail since it will not be available at the right time for the substitutive media to arrive. Another case is that an attacker may prevent the receivers receiving the content from the main sender by inserting extra splicing time information. To avoid the above cases happening, the authentication of the RTP header extension for splicing time information SHOULD be considered. When a splicer implemented as a mixer sends the stream to the receivers, CSRC list, which can be used to detect RTP-level forwarding loops as defined in Section 8.2 of [RFC3550], may be removed for simplifying the receivers that can not handle multiple sources in the RTP stream. Hence, loops may occur to cause packets to loop back to upstream of the splicer and may form a serious denial- of-service threat. In such a case, non-RTP means, e.g., signaling among all the participants, MUST be used to detect and resolve loops. 8 IANA Considerations 8.1 RTCP Control Packet Types Based on the guidelines suggested in [RFC5226], a new RTCP packet format has been registered with the RTCP Control Packet Type (PT) Registry: Name: SNM Long name: Splicing Notification Message Value: TBA Reference: This document 8.2 RTP Compact Header Extensions The IANA has also registered a new RTP Compact Header Extension [RFC5285bis], according to the following: Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval Description: Splicing Interval Contact: Jinwei Xia Reference: This document 8.3 SDP Grouping Semantic Extension Xia Expires February 4, 2017 [Page 18] INTERNET DRAFT RTP Splicing Notification August 3, 2016 This document request IANA to register the new SDP grouping semantic extension called "SPLICE". Semantics: Splice Token:SPLICE Reference: This document 9 Acknowledgement The authors would like to thank the following individuals who help to review this document and provide very valuable comments: Colin Perkins, Bo Burman, Stephen Botzko, Ben Campbell. 10 References 10.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC5285bis] Even, R., Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", draft-ietf-avtcore- rfc5285-bis-02, May 2016. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010. [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, April 2014. Xia Expires February 4, 2017 [Page 19] INTERNET DRAFT RTP Splicing Notification August 3, 2016 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, November 2015. 10.2 Informative References [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011. [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)", April 2013. [SCTE35] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Cueing Message for Cable", 2011. [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, January 2013. Authors' Addresses Jinwei Xia Huawei Email: xiajinwei@huawei.com Roni Even Huawei Email: ron.even.tlv@gmail.com Rachel Huang Xia Expires February 4, 2017 [Page 20] INTERNET DRAFT RTP Splicing Notification August 3, 2016 Huawei Email: rachel.huang@huawei.com Lingli Deng China Mobile Email: denglingli@chinamobile.com Xia Expires February 4, 2017 [Page 21] ./draft-ietf-lwig-cellular-06.txt0000664000764400076440000011550712642451747016150 0ustar iustyiusty Network Working Group J. Arkko Internet-Draft A. Eriksson Intended status: Informational A. Keranen Expires: July 7, 2016 Ericsson January 4, 2016 Building Power-Efficient CoAP Devices for Cellular Networks draft-ietf-lwig-cellular-06 Abstract This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 7, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Arkko, et al. Expires July 7, 2016 [Page 1] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Goals for Low-Power Operation . . . . . . . . . . . . . . . . 3 3. Link-Layer Assumptions . . . . . . . . . . . . . . . . . . . 5 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Discovery and Registration . . . . . . . . . . . . . . . . . 8 6. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Real-Time Reachable Devices . . . . . . . . . . . . . . . . . 10 8. Sleepy Devices . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Implementation Considerations . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This memo discusses the use of the Constrained Application Protocol (CoAP) protocol [RFC7252] in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. CoAP has many advantages, including being simple to implement; a thousand lines for the entire software above IP layer is plenty for a CoAP-based sensor, for instance. However, while many of these advantages are obvious and easily obtained, optimizing power consumption remains challenging and requires careful design [I-D.arkko-core-sleepy-sensors]. The memo targets primarily 3GPP cellular networks in their 2G, 3G, and LTE variants and their future enhancements, including possible power efficiency improvements at the radio and link layers. The exact standards or details of the link layer or radios are not relevant for our purposes, however. To be more precise, the material in this memo is suitable for any large-scale, public network that employs point-to-point communications model and radio technology for the devices in the network. Our focus is devices that need to be optimized for power usage, and on devices that employ CoAP. As a general technology, CoAP is similar to HTTP. It can be used in various ways and network entities Arkko, et al. Expires July 7, 2016 [Page 2] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 may take on different roles. This freedom allows the technology to be used in efficient and less efficient ways. Some guidance is needed to understand what communication models over CoAP are recommended when low power usage is a critical goal. The recommendations in this memo should be taken as complementary to device hardware optimization, microelectronics improvements, and further evolution of the underlying link and radio layers. Further gains in power efficiency can certainly be gained on several fronts; the approach that we take in this memo is to do what can be done at the IP, transport, and application layers to provide the best possible power efficiency. Application implementors generally have to use the current generation microelectronics, currently available radio networks and standards, and so on. This focus in our memo should by no means be taken as an indication that further evolution in these other areas is unnecessary. Such evolution is useful, is ongoing, and is generally complementary to the techniques presented in this memo. The evolution of underlying technologies may change what techniques described here are useful for a particular application, however. The rest of this memo is structured as follows. Section 2 discusses the need and goals for low-power devices. Section 3 outlines our expectations for the low layer communications model. Section 4 describes the two scenarios that we address, and Section 5, Section 6, Section 7 and Section 8 give guidelines for use of CoAP in these scenarios. 2. Goals for Low-Power Operation There are many situations where power usage optimization is unnecessary. Optimization may not be necessary on devices that can run on power feed over wired communications media, such as in Power- over-Ethernet (PoE) solutions. These devices may require a rudimentary level of power optimization techniques just to keep overall energy costs and aggregate power feed sizes at a reasonable level, but more extreme techniques necessary for battery powered devices are not required. The situation is similar with devices that can easily be connected to mains power. Other types of devices may get an occasional charge of power from energy harvesting techniques. For instance, some environmental sensors can run on solar cells. Typically, these devices still have to regulate their power usage in a strict manner, for instance to be able to use as small and inexpensive solar cells as possible. In battery operated devices the power usage is even more important. For instance, one of the authors employs over a hundred different sensor devices in his home network. A majority of these devices are Arkko, et al. Expires July 7, 2016 [Page 3] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 wired and run on PoE, but in most environments this would be impractical because the necessary wires do not exist. The future is in wireless solutions that can cover buildings and other environments without assuming a pre-existing wired infrastructure. In addition, in many cases it is impractical to provide a mains power source. Often there are no power sockets easily available in the locations that the devices need to be in, and even if there were, setting up the wires and power adapters would be more complicated than installing a standalone device without any wires. Yet, with a large number of devices the battery lifetimes become critical. Cost and practical limits dictate that devices can be largely just bought and left on their own. For instance, with hundred devices, even a ten-year battery lifetime results in a monthly battery change for one device within the network. This may be impractical in many environments. In addition, some devices may be physically difficult to reach for a battery change. Or, a large group of devices -- such as utility meters or environmental sensors -- cannot be economically serviced too often, even if in theory the batteries could be changed. Many of these situations lead to a requirement for minimizing power usage and/or maximizing battery lifetimes. Using the power usage strategies described in [RFC7228], mains-powered sensor-type devices can use the Always-on strategy whereas battery or energy harvesting devices need to adjust behavior based on the communication interval. For intervals in the order of seconds, Low-power strategy is appropriate. For intervals ranging from minutes to hours either Low- power or Normally-off strategies are suitable. Finally, for intervals lasting days and longer, Normally-off is usually the best choice. Unfortunately, much of our current technology has been built with different objectives in mind. Networked devices that are "always on", gadgets that require humans to recharge them every couple of days, and protocols that have been optimized to maximize throughput rather than conserve resources. Long battery lifetimes are required for many applications, however. In some cases these lifetimes should be in the order of years or even a decade or longer. Some communication devices already reach multi- year lifetimes, and continuous improvement in low-power electronics and advances in radio technology keep pushing these lifetimes longer. However, it is perhaps fair to say that battery lifetimes are generally too short at present time. Power usage can not be evaluated solely based on lower layer communications. The entire system, including upper layer protocols and applications is responsible for the power consumption as a whole. The lower communication layers have already adopted many techniques Arkko, et al. Expires July 7, 2016 [Page 4] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 that can be used to reduce power usage, such as scheduling device wake-up times. Further reductions will likely need some co-operation from the upper layers so that unnecessary communications, denial-of- service attacks on power consumption, and other power drains are eliminated. Of course, application requirements ultimately determine what kinds of communications are necessary. For instance, some applications require more data to be sent than others. The purpose of the guidelines in this memo is not to prefer one or the other application, but to provide guidance on how to minimize the amount of communications overhead that is not directly required by the application. While such optimization is generally useful, it is relatively speaking most noticeable in applications that transfer only a small amount of data, or operate only infrequently. 3. Link-Layer Assumptions We assume that the underlying communications network can be any large-scale, public network that employs point-to-point communications model and radio technology. 2G, 3G, and LTE networks are examples of such networks, but not the only possible networks with these characteristics. In the following we look at some of these characteristics and their implications. Note that in most cases these characteristics are not properties of the specific networks but rather inherent in the concept of public networks. Public networks Using a public network service implies that applications can be deployed without having to build a network to go with them. For economic reasons, only the largest users (such as utility companies) could afford to build their own network, and even they would not be able to provide a world-wide coverage. This means that applications where coverage is important can be built. For instance, most transport sector applications require national or even world-wide coverage to work. But there are other implications, as well. By definition, the network is not tailored for this application and with some exceptions, the traffic passes through the Internet. One implication of this is that there are generally no application- specific network configurations or discovery support. For instance, the public network helps devices to get on the Internet, set up default routers, configure DNS servers, and so on, but does nothing for configuring possible higher-layer functions, such as Arkko, et al. Expires July 7, 2016 [Page 5] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 servers the device might need to contact to perform its application functions. Public networks often provide web proxies and other functionality that can in some cases make a significant improvement for delays and cost of communication over the wireless link. For instance, resolving server DNS names in a proxy instead of the user's device may cut down on the general chattiness of the communications, therefore reducing overall delay in completing the entire transaction. Likewise, a CoAP proxy or pub/sub broker [I-D.koster-core-coap-pubsub] can assist a CoAP device in communication. However, unlike HTTP web proxies, CoAP proxies and brokers are not yet widely deployed in public networks. Similarly, given the lack of available IPv4 addresses, the chances are that many devices are behind a network address translation (NAT) device. This means that they are not easily reachable as servers. Alternatively, the devices may be directly on the global Internet (either on IPv4 or IPv6) and easily reachable as servers. Unfortunately, this may mean that they also receive unwanted traffic, which may have implications for both power consumption and service costs. Point-to-point link model This is a common link model in cellular networks. One implication of this model is that there will be no other nodes on the same link, except maybe for the service provider's router. As a result, multicast discovery can not be reasonably used for any local discovery purposes. While the configuration of the service provider's router for specific users is theoretically possible, in practice this is difficult to achieve, at least for any small user that can not afford a network-wide contract for a private APN (Access Point Name). The public network access service has little per-user tailoring. Radio technology The use of radio technology means that power is needed to operate the radios. Transmission generally requires more power than reception. However, radio protocols have generally been designed so that a device checks periodically whether it has messages. In a situation where messages arrive seldom or not at all, this checking consumes energy. Research has shown that these periodic checks (such as LTE paging message reception) are often a far bigger contributor to energy consumption than message transmission. Arkko, et al. Expires July 7, 2016 [Page 6] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 Note that for situations where there are several applications on the same device wishing to communicate with the Internet in some manner, bundling those applications together so that they can communicate at the same time can be very useful. Some guidance for these techniques in the smartphone context can be found in [Android-Bundle]. Naturally, each device has a freedom to decide when it sends messages. In addition, we assume that there is some way for the devices to control when or how often it wants to receive messages. Specific methods for doing this depend on the specific network being used and also tend to change as improvements in the design of these networks are incorporated. The reception control methods generally come in two variants, fine grained mechanisms that deal with how often the device needs to wake-up for paging messages, and more crude mechanisms where the device simply disconnects from the network for a period of time. There are associated costs and benefits to each method, but those are not relevant for this memo, as long as some control method exists. Furthermore, devices could use Delay-Tolerant Networking (DTN) [RFC4838] mechanisms to relax the requirements for timeliness of connectivity and message delivery. 4. Scenarios Not all applications or situations are equal. They may require different solutions or communication models. This memo focuses on two common scenarios at cellular networks: Real-Time Reachable Devices This scenario involves all communication that requires real-time or near real-time communications with a device. That is, a network entity must be able to reach the device with a small time lag at any time, and no pre-agreed wake-up schedule can be arranged. By "real-time" we mean any reasonable end-to-end communications latency, be it measured in milliseconds or seconds. However, unpredictable sleep states are not expected. Examples of devices in this category include sensors that must be measurable from a remote source at any instant in time, such as process automation sensors and actuators that require immediate action, such as light bulbs or door locks. Sleepy Devices This scenario involves freedom to choose when device communicates. The device is often expected to be able to be in a sleep state for Arkko, et al. Expires July 7, 2016 [Page 7] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 much of its time. The device itself can choose when it communicates, or it lets the network assist in this task. Examples of devices in this category include sensors that track slowly changing values, such as temperature sensors and actuators that control a relatively slow process, such as heating systems. Note that there may be hard real-time requirements, but they are expressed in terms of how fast the device can communicate, not in terms of how fast it can respond to a network stimuli. For instance, a fire detector can be classified as a sleepy device as long as it can internally quickly wake up on detecting fire and initiate the necessary communications without delay. 5. Discovery and Registration In both scenarios the device will be attached to a public network. Without special arrangements, the device will also get a dynamically assigned IP address or an IPv6 prefix. At least one but typically several router hops separate the device from its communicating peers such as application servers. As a result, the address or even the existence of the device is typically not immediately obvious to the other nodes participating in the application. As discussed earlier, multicast discovery has limited value in public networks; network nodes cannot practically discover individual devices in a large public network. And the devices can not discover who they need to talk, as the public network offers just basic Internet connectivity. Our recommendation is to initiate a discovery and registration process. This allows each device to inform its peers that it has connected to the network and that it is reachable at a given IP address. Registration also facilitates low-power operation since a device can delegate part of the discovery signaling and reachability requirements to another node. The registration part is easy e.g., with a resource directory. The device should perform the necessary registration with these devices, for instance, as specified in [I-D.ietf-core-resource-directory]. In order to do this registration, the device needs to know its CoRE Link Format description, as specified in [RFC6690]. In essence, the registration process involves performing a GET on .well-known/ core/?rt=core-rd at the address of the resource directory, and then doing a POST on the path of the discovered resource. Other mechanisms enabling device discovery and delegation of functionality to a non-sleepy node include [I-D.vial-core-mirror-proxy] and [I-D.koster-core-coap-pubsub]. Arkko, et al. Expires July 7, 2016 [Page 8] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 However, current CoAP specifications provide only limited support for discovering the resource directory or other registration services. Local multicast discovery only works in LAN-type networks, but not in these public cellular networks. Our recommended alternate methods for discovery are the following: Manual Configuration The DNS name of the resource directory is manually configured. This approach is suitable in situations where the owner of the devices has the resources and capabilities to do the configuration. For instance, a utility company can typically program its metering devices to point to the company servers. Manufacturer Server The DNS name of the directory or proxy is hardwired to the software by the manufacturer, and the directory or proxy is actually run by the manufacturer. This approach is suitable in many consumer usage scenarios, where it would be unreasonable to assume that the consumer runs any specific network services. The manufacturer's web interface and the directory/proxy servers can co-operate to provide the desired functionality to the end user. For instance, the end user can register a device identity in the manufacturer's web interface and ask specific actions to be taken when the device does something. Delegating Manufacturer Server The DNS name of the directory or proxy is hardwired to the software by the manufacturer, but this directory or proxy merely redirects the request to a directory or proxy run by the whoever bought the device. This approach is suitable in many enterprise environments, as it allows the enterprise to be in charge of actual data collection and device registries; only the initial bootstrap goes through the manufacturer. In many cases there are even legal requirements (such as EU privacy laws) that prevent providing unnecessary information to third parties. Common Global Resolution Infrastructure The delegating manufacturer server model could be generalized into a reverse-DNS -like discovery infrastructure that could answer the question "this is device with identity ID, where is my home registration server?". However, at present no such resolution system exists. (Note: The EPCGlobal system for RFID resolution is reminiscent of this approach.) Arkko, et al. Expires July 7, 2016 [Page 9] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 Besides manual configuration, these alternate mechanisms are mostly suitable for large manufacturers and deployments. Good automated mechanism for discovery of devices that are manufactured and deployed in small quantities are still needed. 6. Data Formats A variety of data formats exist for passing around data. These data formats include XML, JavaScript Object Notation (JSON) [RFC7159], Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text formats. Message lengths can have a significant effect on the amount of energy required for the communications, and such it is highly desirable to keep message lengths minimal. At the same time, extreme optimization can affect flexibility and ease of programming. The authors recommend [I-D.jennings-core-senml] as a compact, yet easily processed and extendable textual format. 7. Real-Time Reachable Devices These devices are often best modeled as CoAP servers. The device will have limited control on when it receives messages, and it will have to listen actively for messages, up to the limits of the underlying link layer. If the device acts also in client role in some phase of its operation, it can control how many transmissions it makes on its own behalf. The packet reception checks should be tailored according to the requirements of the application. If sub-second response time is not needed, a more infrequent checking process may save some power. For sensor-type devices, the CoAP Observe extension [RFC7641] may be supported. This allows the sensor to track changes to the sensed value, and make an immediate observation response upon a change. This may reduce the amount of polling needed to be done by the client. Unfortunately, it does not reduce the time that the device needs to be listening for requests. Subscription requests from other clients than the currently registered one may come at any time, the current client may change its request, and the device still needs to respond to normal queries as a server. As a result, the sensor can not rely having to communicate only on its own choice of observation interval. In order to act as a server, the device needs to be placed in a public IPv4 address, be reachable over IPv6, or hosted in a private network. If the the device is hosted on a private network, then all other nodes need to access this device also need to reside in the same private network. There are multiple ways to provide private networks over public cellular networks. One approach is to dedicate Arkko, et al. Expires July 7, 2016 [Page 10] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 a special APN for the private network. Corporate access via cellular networks has often been arranged in this manner, for instance. Another approach is to use Virtual Private Networking (VPN) technology, for instance IPsec-based VPNs. Power consumption from unwanted traffic is problematic in these devices, unless placed in a private network or protected by a operator-provided firewall service. Devices on an IPv6 network will have some protection through the nature of the 2^64 address allocation for a single terminal in a 3GPP cellular network; the attackers will be unable to guess the full IP address of the device. However, this protects only the device from processing a packet, but since the network will still deliver the packet to any of the addresses within the assigned 64-bit prefix, packet reception costs are still incurred. Note that the the VPN approach can not prevent unwanted traffic received at the tunnel endpoint address, and may require keep-alive traffic. Special APNs can solve this issue, but require explicit arrangement with the service provider. 8. Sleepy Devices These devices are best modeled as devices that can delegate queries to some other node. For instance, as mirror proxy [I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe [I-D.koster-core-coap-pubsub] clients. When the device initializes itself, it makes a registration of itself in a proxy as described above in Section 5 and then continues to send periodic updates of sensor values. As a result, the device acts only as a client, not a server, and can shut down all communication channels while it is during its sleeping period. The length of the sleeping period depends on power and application requirements. Some environmental sensors might use a day or a week as the period, while other devices may use a smaller values ranging from minutes to hours. Other approaches for delegation include CoAP-options described in [I-D.castellani-core-alive] [I-D.fossati-core-publish-monitor-options]. In this memo we use mirror proxies as an example, because of their ability to work with both HTTP and CoAP implementations; but the concepts are similar and the IETF work is still in progress so the final protocol details are yet to be decided. The ability to shut down communications and act as only a client has four impacts: Arkko, et al. Expires July 7, 2016 [Page 11] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 o Radio transmission and reception can be turned off during the sleeping period, reducing power consumption significantly. o However, some power and time is consumed by having to re-attach to the network after the end of a sleep period. o The window of opportunity for unwanted traffic to arrive is much smaller, as the device is listening for traffic only part of the time. Note that networks may cache packets for some time though. On the other hand, stateful firewalls can effectively remove much of unwanted traffic for client type devices. o The device may exist behind a NAT or a firewall without being impacted. Note that "Simple Security" basic IPv6 firewall capability [RFC6092] blocks inbound UDP traffic by default, so just moving to IPv6 is not direct solution to this problem. For sleepy devices that represent actuators, it is also possible to use the mirror proxy model. The device can make periodic polls to the proxy to determine if a variable has changed. 8.1. Implementation Considerations There are several challenges in implementing sleepy devices. They need hardware that can be put to an appropriate sleep mode but yet awakened when it is time to do something again. This is not always easy in all hardware platforms. It is important to be able to shut down as much of the hardware as possible, preferably down to everything else except a clock circuit. The platform also needs to support re-awakening at suitable time scales, as otherwise the device needs to be powered up too frequently. Most commercial cellular modem platforms do not allow applications to suspend the state of the communications stack. Hence, after a power- off period they need to re-establish communications, which takes some amount of time and extra energy. Implementations should have a coordinated understanding of the state and sleeping schedule. For instance, it makes no sense to keep a CPU powered up, waiting for a message when the lower layer has been told that the next possible paging opportunity is some time away. The cellular networks have a number of adjustable configuration parameters, such as the maximum used paging interval. Proper setting of these values has an impact on the power consumption of the device, but with the current business practices, such settings are rarely negotiated when the user's subscription is provisioned. Arkko, et al. Expires July 7, 2016 [Page 12] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 9. Security Considerations There are no particular security aspects with what has been discussed in this memo, except for the ability to delegate queries for a resource to another node. Depending on how this is done, there are obvious security issues which have largely NOT yet been addressed in the relevant Internet Drafts [I-D.vial-core-mirror-proxy] [I-D.castellani-core-alive] [I-D.fossati-core-publish-monitor-options]. However, we point out that in general, security issues in delegation can be solved either through reliance on your local network support nodes (which may be quite reasonable in many environments) or explicit end-to-end security. Explicit end-to-end security through nodes that are awake at different times means in practice end-to-end data object security. We have implemented one such mechanism for sleepy nodes as described in [I-D.aks-lwig-crypto-sensors]. The security considerations relating to CoAP [RFC7252] and the relevant link layers should apply. Note that cellular networks universally employ per-device authentication, integrity protection, and for most of the world, encryption of all their communications. Additional protection of transport sessions is possible through mechanisms described in [RFC7252] or data objects. 10. IANA Considerations There are no IANA impacts in this memo. 11. References 11.1. Normative References [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Arkko, et al. Expires July 7, 2016 [Page 13] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", draft-ietf-core-resource-directory-05 (work in progress), October 2015. [W3C.REC-exi-20110310] Kamiya, T. and J. Schneider, "Efficient XML Interchange (EXI) Format 1.0", World Wide Web Consortium Recommendation REC- exi-20110310 http://www.w3.org/TR/2011/REC-exi-20110310, March 2011. [I-D.jennings-core-senml] Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, "Media Types for Sensor Markup Language (SENML)", draft- jennings-core-senml-02 (work in progress), October 2015. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . 11.2. Informative References [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, . [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, . [I-D.arkko-core-sleepy-sensors] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- sleepy-sensors-01 (work in progress), July 2011. Arkko, et al. Expires July 7, 2016 [Page 14] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 [I-D.aks-lwig-crypto-sensors] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", draft-aks-lwig-crypto-sensors-00 (work in progress), October 2015. [I-D.castellani-core-alive] Castellani, A. and S. Loreto, "CoAP Alive Message", draft- castellani-core-alive-00 (work in progress), March 2012. [I-D.fossati-core-publish-monitor-options] Fossati, T., Giacomin, P., and S. Loreto, "Publish and Monitor Options for CoAP", draft-fossati-core-publish- monitor-options-01 (work in progress), March 2012. [I-D.vial-core-mirror-proxy] Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- proxy-01 (work in progress), July 2012. [I-D.koster-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-koster-core-coap-pubsub-04 (work in progress), November 2015. [Android-Bundle] "Optimizing Downloads for Efficient Network Access", Android developer note http://developer.android.com/training/efficient-downloads/ efficient-network-access.html, February 2013. Appendix A. Acknowledgments The authors would like to thank Zach Shelby, Jan Holler, Salvatore Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes Tschofenig, and Anna Larmo for interesting discussions in this problem space. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Arkko, et al. Expires July 7, 2016 [Page 15] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 Anders Eriksson Ericsson Stockholm 164 83 Sweden Email: anders.e.eriksson@ericsson.com Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Arkko, et al. Expires July 7, 2016 [Page 16] ./draft-ietf-bfcpbis-rfc4582bis-16.txt0000664000764400076440000067005012621510104016562 0ustar iustyiusty BFCPbis Working Group G. Camarillo Internet-Draft Ericsson Obsoletes: 4582 (if approved) K. Drage Intended status: Standards Track Alcatel-Lucent Expires: May 16, 2016 T. Kristensen Cisco J. Ott Aalto University C. Eckel Cisco November 13, 2015 The Binary Floor Control Protocol (BFCP) draft-ietf-bfcpbis-rfc4582bis-16 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 16, 2016. Camarillo, et al. Expires May 16, 2016 [Page 1] Internet-Draft BFCP November 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . 8 3.2. Obtaining Information to Contact a Floor Control Server . 8 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 8 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 9 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 4.1. Floor Participant to Floor Control Server Interface . . . 10 4.2. Floor Chair to Floor Control Server Interface . . . . . . 14 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . 15 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . 18 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . 21 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . 21 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 22 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . 22 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . 23 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 24 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . 25 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 26 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 27 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 28 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . 29 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 29 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 30 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 31 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . 31 Camarillo, et al. Expires May 16, 2016 [Page 2] Internet-Draft BFCP November 2015 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . 32 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . 33 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . 33 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . 33 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 33 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . 34 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 34 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . 34 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . 35 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 35 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 35 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . 35 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . 36 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 36 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . 37 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . 37 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . 38 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . 39 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . 40 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 41 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . 41 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 42 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 43 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 43 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . 45 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . 46 9. Authentication and Authorization . . . . . . . . . . . . . . 46 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . 47 10. Floor Participant Operations . . . . . . . . . . . . . . . . 48 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . 48 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . 48 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . 49 10.1.3. Reception of a Subsequent FloorRequestStatus Message 50 10.2. Cancelling a Floor Request and Releasing a Floor . . . . 50 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . 50 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . 51 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 51 11.1. Sending a ChairAction Message . . . . . . . . . . . . . 51 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . 53 12. General Client Operations . . . . . . . . . . . . . . . . . . 53 Camarillo, et al. Expires May 16, 2016 [Page 3] Internet-Draft BFCP November 2015 12.1. Requesting Information about Floors . . . . . . . . . . 53 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . 53 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . 54 12.1.3. Reception of a Subsequent FloorStatus Message . . . 55 12.2. Requesting Information about Floor Requests . . . . . . 55 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . 55 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . 55 12.3. Requesting Information about a User . . . . . . . . . . 56 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . 56 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . 57 12.4. Obtaining the Capabilities of a Floor Control Server . . 57 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . 57 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . 57 13. Floor Control Server Operations . . . . . . . . . . . . . . . 58 13.1. Reception of a FloorRequest Message . . . . . . . . . . 58 13.1.1. Generating the First FloorRequestStatus Message . . 59 13.1.2. Generation of Subsequent FloorRequestStatus Messages 60 13.2. Reception of a FloorRequestQuery Message . . . . . . . . 61 13.3. Reception of a UserQuery Message . . . . . . . . . . . . 63 13.4. Reception of a FloorRelease Message . . . . . . . . . . 64 13.5. Reception of a FloorQuery Message . . . . . . . . . . . 65 13.5.1. Generation of the First FloorStatus Message . . . . 66 13.5.2. Generation of Subsequent FloorStatus Messages . . . 67 13.6. Reception of a ChairAction Message . . . . . . . . . . . 68 13.7. Reception of a Hello Message . . . . . . . . . . . . . . 69 13.8. Error Message Generation . . . . . . . . . . . . . . . . 69 14. Security Considerations . . . . . . . . . . . . . . . . . . . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . 71 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . 72 15.3. Request Status Subregistry . . . . . . . . . . . . . . . 73 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . 74 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 75 16.1. Extensions for an unreliable transport . . . . . . . . . 75 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . 76 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 18.1. Normative References . . . . . . . . . . . . . . . . . . 78 18.2. Informational References . . . . . . . . . . . . . . . . 79 Appendix A. Example Call Flows for BFCP over an Unreliable Transport . . . . . . . . . . . . . . . . . . . . . 81 Appendix B. Motivation for Supporting an Unreliable Transport . 85 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 85 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 87 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . 88 Camarillo, et al. Expires May 16, 2016 [Page 4] Internet-Draft BFCP November 2015 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . 89 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 1. Introduction Within a conference, some applications need to manage the access to a set of shared resources, such as the right to send media to a particular media session. Floor control enables such applications to provide users with coordinated (shared or exclusive) access to these resources. The Requirements for Floor Control Protocol [15] list a set of requirements that need to be met by floor control protocols. The Binary Floor Control Protocol (BFCP), which is specified in this document, meets these requirements. In addition, BFCP has been designed so that it can be used in low- bandwidth environments. The binary encoding used by BFCP achieves a small message size (when message signatures are not used) that keeps the time it takes to transmit delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expected that future extensions to these messages will not increase the size of these messages in a significant way. The remainder of this document is organized as follows: Section 2 defines the terminology used throughout this document, Section 3 discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP and which ones are performed using different mechanisms), Section 4 provides a non-normative overview of BFCP operation, and subsequent sections provide the normative specification of BFCP. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. Media Participant: An entity that has access to the media resources of a conference (e.g., it can receive a media stream). In floor- controlled conferences, a given media participant is typically colocated with a floor participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. Camarillo, et al. Expires May 16, 2016 [Page 5] Internet-Draft BFCP November 2015 The protocol between a floor participant and a media participant (that are not colocated) is outside the scope of this document. Client: A floor participant or a floor chair that communicates with a floor control server using BFCP. Floor: A temporary permission to access or manipulate a specific shared resource or set of resources. Floor Chair: A logical entity that manages one floor (grants, denies, or revokes a floor). An entity that assumes the logical role of a floor chair for a given transaction may assume a different role (e.g., floor participant) for a different transaction. The roles of floor chair and floor participant are defined on a transaction-by- transaction basis. BFCP transactions are defined in Section 8. Floor Control: A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. Floor Control Server: A logical entity that maintains the state of the floor(s), including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server. The floor control server of a conference may perform other logical roles (e.g., floor participant) in another conference. Floor Participant: A logical entity that requests floors, and possibly information about them, from a floor control server. An entity that assumes the logical role of a floor participant for a given transaction may assume a different role (e.g., a floor chair) for a different transaction. The roles of floor participant and floor chair are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8. In floor-controlled conferences, a given floor participant is typically colocated with a media participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. Participant: An entity that acts as a floor participant, as a media participant, or as both. BFCP Connection: A transport association between BFCP entities, used to exchange BFCP messages. Transaction Failure Window: When communicating over an unreliable transport, this is some period of time less than or equal to T1*2^4 Camarillo, et al. Expires May 16, 2016 [Page 6] Internet-Draft BFCP November 2015 (see Section 8.3). For reliable transports, this period of time is unbounded. 3. Scope As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [15]. Floor control complements other functions defined in the XCON conferencing framework [16]. The floor control protocol BFCP defined in this document only specifies a means to arbitrate access to floors. The rules and constraints for floor arbitration and the results of floor assignments are outside the scope of this document and are defined by other protocols [16]. Figure 1 shows the tasks that BFCP can perform. +---------+ | Floor | | Chair | | | +---------+ ^ | | | Notification | | Decision | | | | Floor | v +-------------+ Request +---------+ +-------------+ | Floor |----------->| Floor | Notification | Floor | | Participant | | Control |------------->| Participant | | |<-----------| Server | | | +-------------+ Granted or +---------+ +-------------+ Denied Figure 1: Functionality provided by BFCP BFCP provides a means: o for floor participants to send floor requests to floor control servers. o for floor control servers to grant or deny requests to access a given resource from floor participants. o for floor chairs to send floor control servers decisions regarding floor requests. Camarillo, et al. Expires May 16, 2016 [Page 7] Internet-Draft BFCP November 2015 o for floor control servers to keep floor participants and floor chairs informed about the status of a given floor or a given floor request. Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential for creating floors and establishing BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform them. 3.1. Floor Creation The association of a given floor with a resource or a set of resources (e.g., media streams) is out of the scope of BFCP as described in [16]. Floor creation and termination are also outside the scope of BFCP; these aspects are handled using the conference control protocol for manipulating the conference object. Consequently, the floor control server needs to stay up to date on changes to the conference object (e.g., when a new floor is created). Conference control clients using CCMP [21] can specify such floor- related settings in the element [20] of the to-be created conference object provided in the body of a CCMP confRequest/ create message issued to the conference control server. 3.2. Obtaining Information to Contact a Floor Control Server A client needs a set of data in order to establish a BFCP connection to a floor control server. This data includes the transport address of the server, the conference identifier, and a user identifier. Clients can obtain this information in different ways. One is to use an SDP offer/answer [14] exchange, which is described in [10]. How to establish a connection to a BFCP floor control server outside the context of an offer/answer exchange when using a reliable transport is described in [4]. Other mechanisms are described in the XCON framework [16] (and other related documents). For unreliable transports, the use of an SDP offer/answer exchange is the only specified mechanism. 3.3. Obtaining Floor-Resource Associations Floors are associated with resources. For example, a floor that controls who talks at a given time has a particular audio session as its associated resource. Associations between floors and resources are part of the conference object. Camarillo, et al. Expires May 16, 2016 [Page 8] Internet-Draft BFCP November 2015 Floor participants and floor chairs need to know which resources are associated with which floors. They can obtain this information by using different mechanisms, such as an SDP offer/answer [14] exchange. How to use an SDP offer/answer exchange to obtain these associations is described in [10]. Note that floor participants perform SDP offer/answer exchanges with the conference focus of the conference. So, the conference focus needs to obtain information about associations between floors and resources in order to be able to provide this information to a floor participant in an SDP offer/answer exchange. Other mechanisms for obtaining this information, including discussion of how the information is made available to a (SIP) Focus, are described in the XCON framework [16] (and other related documents). According to the conferencing system policies, conference control clients using CCMP [21] can modify the floor settings of a conference by issuing CCMP confRequest/update messages providing the specific updates to the element of the target conference object. More information about CCMP and BFCP interaction can be found in [22]. 3.4. Privileges of Floor Control A participant whose floor request is granted has the right to use the resource or resources associated with the floor that was requested. For example, the participant may have the right to send media over a particular audio stream. Nevertheless, holding a floor does not imply that others will not be able to use its associated resources at the same time, even if they do not have the right to do so. Determination of which media participants can actually use the resources in the conference is discussed in the XCON Framework [16]. 4. Overview of Operation This section provides a non-normative description of BFCP operations. Section 4.1 describes the interface between floor participants and floor control servers, and Section 4.2 describes the interface between floor chairs and floor control servers. BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consist of a common header followed by a set of attributes. The common header contains, among other information, a 32-bit conference identifier. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers. Camarillo, et al. Expires May 16, 2016 [Page 9] Internet-Draft BFCP November 2015 BFCP supports nested attributes (i.e., attributes that contain attributes). These are referred to as grouped attributes. There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions. Section 8 describes both types of transactions in detail. 4.1. Floor Participant to Floor Control Server Interface Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not be colocated with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of the common header, and the identity of the beneficiary of the floor (in third- party floor requests) in a BENEFICIARY-ID attribute. Third-party floor requests can be sent, for example, by floor participants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media). FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message. Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest. Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request. Messages from the floor participant related to a particular floor request also use the same Floor Request ID as the first FloorRequestStatus Message from the floor control server. Camarillo, et al. Expires May 16, 2016 [Page 10] Internet-Draft BFCP November 2015 Figures 2 and 3 below show examples of call flows where BFCP is used over a reliable transport. Appendix A shows the same call flow examples using an unreliable transport. Figure 2 shows how a floor participant requests a floor, obtains it, and, at a later time, releases it. This figure illustrates the use, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute. Floor Participant Floor Control Server |(1) FloorRequest | |Transaction ID: 123 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(3) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(4) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | Camarillo, et al. Expires May 16, 2016 [Page 11] Internet-Draft BFCP November 2015 | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(5) FloorRelease | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 | |---------------------------------------------->| | | |(6) FloorRequestStatus | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| Figure 2: Requesting and releasing a floor Figure 3 shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message. Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0 given this example uses a reliable transport. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted. Floor Participant Floor Control Server |(1) FloorQuery | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorStatus | Camarillo, et al. Expires May 16, 2016 [Page 12] Internet-Draft BFCP November 2015 |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(3) FloorStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(4) FloorStatus | |Transaction ID: 0 | Camarillo, et al. Expires May 16, 2016 [Page 13] Internet-Draft BFCP November 2015 |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| Figure 3: Obtaining status information about a floor FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request. A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same time). The floor control server treats a multi-floor floor request as an atomic package. That is, the floor control server either grants the request for all floors or denies the request for all floors. 4.2. Floor Chair to Floor Control Server Interface Figure 4 shows a floor chair instructing a floor control server to grant a floor. Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., granting a floor), it does not necessarily need to perform them exactly as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server. For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. In Camarillo, et al. Expires May 16, 2016 [Page 14] Internet-Draft BFCP November 2015 another example, a floor chair may instruct the floor control server to grant a floor to a participant. The floor control server needs to revoke the floor from its current holder before granting it to the new participant. So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state. Floor Chair Floor Control Server |(1) ChairAction | |Transaction ID: 769 | |User ID: 357 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | Request Status: Granted | |---------------------------------------------->| | | |(2) ChairActionAck | |Transaction ID: 769 | |User ID: 357 | |<----------------------------------------------| Figure 4: Chair instructing the floor control server 5. Packet Format BFCP packets consist of a 12-octet common header followed by attributes. All the protocol values MUST be sent in network byte order. 5.1. COMMON-HEADER Format The following is the format of the common header. Camarillo, et al. Expires May 16, 2016 [Page 15] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |R|F| Res | Primitive | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | User ID | +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Fragment Offset (if F is set) | Fragment Length (if F is set) | +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---- These fragment fields are never present when using reliable transports Figure 5: COMMON-HEADER format Ver: This 3-bit field defines the version of BFCP that this message adheres to. This specification defines two versions: 1 and 2. The version field MUST be set to 1 when using BFCP over a reliable transport. The version field MUST be set to 2 when using BFCP over an unreliable transport. If a floor control server receives a message with an unsupported version field value or a message with a version number that is not permitted with the transport over which it was received, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version). Note that BFCP entities supporting only the [3] subset will not support this parameter value. R: The Transaction Responder (R) flag-bit has relevance only for use of BFCP over an unreliable transport. When cleared, it indicates that this message is a request initiating a new transaction, and the Transaction ID that follows has been generated for this transaction. When set, it indicates that this message is a response to a previous request, and the Transaction ID that follows is the one associated with that request. When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender and MUST be ignored by the receiver. F: The Fragmentation (F) flag-bit has relevance only for use of BFCP over an unreliable transport. When cleared, the message is not fragmented. When set, it indicates that the message is a fragment of a large fragmented BFCP message. (The optional fields Fragment Offset and Fragment Length described below are present only if the F flag is set). When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender and the flag MUST be ignored by the receiver. In the latter case, the receiver Camarillo, et al. Expires May 16, 2016 [Page 16] Internet-Draft BFCP November 2015 should also process the COMMON-HEADER as not having the Fragment Offset and Fragment Length fields present. Res: The 3 bits in the reserved field MUST be set to zero by the sender of the message and MUST be ignored by the receiver. Primitive: This 8-bit field identifies the main purpose of the message. The following primitive values are defined: +-------+-----------------------+--------------------------+ | Value | Primitive | Direction | +-------+-----------------------+--------------------------+ | 1 | FloorRequest | P -> S | | 2 | FloorRelease | P -> S | | 3 | FloorRequestQuery | P -> S ; Ch -> S | | 4 | FloorRequestStatus | P <- S ; Ch <- S | | 5 | UserQuery | P -> S ; Ch -> S | | 6 | UserStatus | P <- S ; Ch <- S | | 7 | FloorQuery | P -> S ; Ch -> S | | 8 | FloorStatus | P <- S ; Ch <- S | | 9 | ChairAction | Ch -> S | | 10 | ChairActionAck | Ch <- S | | 11 | Hello | P -> S ; Ch -> S | | 12 | HelloAck | P <- S ; Ch <- S | | 13 | Error | P <- S ; Ch <- S | | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | | 15 | FloorStatusAck | P -> S ; Ch -> S | | 16 | Goodbye | P -> S ; Ch -> S ; | | | | P <- S ; Ch <- S | | 17 | GoodbyeAck | P -> S ; Ch -> S ; | | | | P <- S ; Ch <- S | +-------+-----------------------+--------------------------+ S: Floor Control Server / P: Floor Participant / Ch: Floor Chair Table 1: BFCP primitives Payload Length: This 16-bit field contains the length of the message in 4-octet units, excluding the common header. If a Floor Control Server receives a message with an incorrect Payload Length field value, the receiving server MUST send an Error message with parameter value 13 (Incorrect Message Length) to indicate this and then discard the message. Other entities that receive a message with an incorrect length MUST discard the message. Note: BFCP is designed to achieve small message size, as explained in Section 1, and BFCP entities are required to keep the BFCP message size smaller than the size limited by the 16-bit Payload Camarillo, et al. Expires May 16, 2016 [Page 17] Internet-Draft BFCP November 2015 Length field. To convey information not strictly related to floor control, other protocols should be used such as the XCON framework (cf. Section 3). Conference ID: This 32-bit unsigned integer field identifies the conference to which the message belongs. It is RECOMMENDED that the conference identifier be randomly chosen. (Note that the use of predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP susceptible to off-path data injection attacks, where an attacker can forge a request or response message.) Transaction ID: This field contains a 16-bit value that allows users to match a given message with its response (see Section 8). User ID: This field contains a 16-bit unsigned integer that uniquely identifies a participant within a conference. The identity used by a participant in BFCP, which is carried in the User ID field, is generally mapped to the identity used by the same participant in the session establishment protocol (e.g., in SIP). The way this mapping is performed is outside the scope of this specification. Fragment Offset: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in previous fragments, excluding the common header. Fragment Length: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in this fragment, excluding the common header. BFCP entities that receive message fragments that, individually or collectively, exceed the Payload Length value MUST discard the message. Additionally, if the receiver is a Floor Control Server, it must also send an Error message with parameter value 13 (Incorrect Message Length) 5.2. Attribute Format BFCP attributes are encoded in TLV (Type-Length-Value) format. Attributes are 32-bit aligned. Camarillo, et al. Expires May 16, 2016 [Page 18] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Attribute Contents / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Attribute format Type: This 7-bit field contains the type of the attribute. Each attribute, identified by its type, has a particular format. The attribute formats defined are: Unsigned16: The contents of the attribute consist of a 16-bit unsigned integer. OctetString16: The contents of the attribute consist of 16 bits of arbitrary data. OctetString: The contents of the attribute consist of arbitrary data of variable length. Grouped: The contents of the attribute consist of a sequence of attributes. Note that extension attributes defined in the future may define new attribute formats. The following attribute types are defined: Camarillo, et al. Expires May 16, 2016 [Page 19] Internet-Draft BFCP November 2015 +------+---------------------------+---------------+ | Type | Attribute | Format | +------+---------------------------+---------------+ | 1 | BENEFICIARY-ID | Unsigned16 | | 2 | FLOOR-ID | Unsigned16 | | 3 | FLOOR-REQUEST-ID | Unsigned16 | | 4 | PRIORITY | OctetString16 | | 5 | REQUEST-STATUS | OctetString16 | | 6 | ERROR-CODE | OctetString | | 7 | ERROR-INFO | OctetString | | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | | 9 | STATUS-INFO | OctetString | | 10 | SUPPORTED-ATTRIBUTES | OctetString | | 11 | SUPPORTED-PRIMITIVES | OctetString | | 12 | USER-DISPLAY-NAME | OctetString | | 13 | USER-URI | OctetString | | 14 | BENEFICIARY-INFORMATION | Grouped | | 15 | FLOOR-REQUEST-INFORMATION | Grouped | | 16 | REQUESTED-BY-INFORMATION | Grouped | | 17 | FLOOR-REQUEST-STATUS | Grouped | | 18 | OVERALL-REQUEST-STATUS | Grouped | +------+---------------------------+---------------+ Table 2: BFCP attributes M: The 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is required. If a Floor Control Server receives an unrecognized attribute with the 'M' bit set the server MUST send an Error message with parameter value 4 (Unknown Mandatory Attribute) to indicate this. The 'M' bit is significant for extension attributes defined in other documents only. All attributes specified in this document MUST be understood by the receiver so that the setting of the 'M' bit is irrelevant for these. Unrecognized attributes, such as those that might be specified in future extensions, that do not have the "M" bit set are ignored, but the message is processed. Length: This 8-bit field contains the length of the attribute in octets, excluding any padding defined for specific attributes. The length of attributes that are not grouped includes the Type, 'M' bit, and Length fields. The Length in grouped attributes is the length of the grouped attribute itself (including Type, 'M' bit, and Length fields) plus the total length (including padding) of all the included attributes. Attribute Contents: The contents of the different attributes are defined in the following sections. Camarillo, et al. Expires May 16, 2016 [Page 20] Internet-Draft BFCP November 2015 5.2.1. BENEFICIARY-ID The following is the format of the BENEFICIARY-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: BENEFICIARY-ID format Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference. Note that although the formats of the Beneficiary ID and of the User ID field in the common header are similar, their semantics are different. The Beneficiary ID is used in third-party floor requests and to request information about a particular participant. 5.2.2. FLOOR-ID The following is the format of the FLOOR-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: FLOOR-ID format Floor ID: This field contains a 16-bit value that uniquely identifies a floor within a conference. 5.2.3. FLOOR-REQUEST-ID The following is the format of the FLOOR-REQUEST-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: FLOOR-REQUEST-ID format Camarillo, et al. Expires May 16, 2016 [Page 21] Internet-Draft BFCP November 2015 Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server. 5.2.4. PRIORITY The following is the format of the PRIORITY attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: PRIORITY format Prio: This field contains a 3-bit priority value, as shown in Table 3. Senders SHOULD NOT use values higher than 4 in this field. Receivers MUST treat values higher than 4 as if the value received were 4 (Highest). The default priority value when the PRIORITY attribute is missing is 2 (Normal). +-------+----------+ | Value | Priority | +-------+----------+ | 0 | Lowest | | 1 | Low | | 2 | Normal | | 3 | High | | 4 | Highest | +-------+----------+ Table 3: Priority values Reserved: The 13 bits in the reserved field MUST be set to zero by the sender of the message and MUST be ignored by the receiver. 5.2.5. REQUEST-STATUS The following is the format of the REQUEST-STATUS attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: REQUEST-STATUS format Camarillo, et al. Expires May 16, 2016 [Page 22] Internet-Draft BFCP November 2015 Request Status: This 8-bit field contains the status of the request, as described in the following table. +-------+-----------+ | Value | Status | +-------+-----------+ | 1 | Pending | | 2 | Accepted | | 3 | Granted | | 4 | Denied | | 5 | Cancelled | | 6 | Released | | 7 | Revoked | +-------+-----------+ Table 4: Request Status values Queue Position: This 8-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, if the floor control server does not implement a floor request queue, or if the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero. A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state. 5.2.6. ERROR-CODE The following is the format of the ERROR-CODE attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 0|M| Length | Error Code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Error Specific Details | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: ERROR-CODE format Camarillo, et al. Expires May 16, 2016 [Page 23] Internet-Draft BFCP November 2015 Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognized by the receiver, then the receiver MUST assume that an error exists, and therefore that the original message that triggered the Error message to be sent is processed, but the nature of the error is unclear. +-------+-----------------------------------------------------------+ | Value | Meaning | +-------+-----------------------------------------------------------+ | 1 | Conference does not Exist | | 2 | User does not Exist | | 3 | Unknown Primitive | | 4 | Unknown Mandatory Attribute | | 5 | Unauthorized Operation | | 6 | Invalid Floor ID | | 7 | Floor Request ID Does Not Exist | | 8 | You have Already Reached the Maximum Number of Ongoing | | | Floor Requests for this Floor | | 9 | Use TLS | | 10 | Unable to Parse Message | | 11 | Use DTLS | | 12 | Unsupported Version | | 13 | Incorrect Message Length | | 14 | Generic Error | +-------+-----------------------------------------------------------+ Table 5: Error Code meaning Note: The Generic Error error code is intended to be used when an error occurs and the other specific error codes do not apply. Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 4 (Unknown Mandatory Attribute). See Section 5.2.6.1 for its definition. Padding: One, two, or three octets of padding added so that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.6.1. Error-Specific Details for Error Code 4 The following is the format of the Error-Specific Details field for Error Code 4. Camarillo, et al. Expires May 16, 2016 [Page 24] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Unknown attributes format Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver. R: This bit is reserved. It MUST be set to zero by the sender of the message and MUST be ignored by the receiver. 5.2.7. ERROR-INFO The following is the format of the ERROR-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: ERROR-INFO format Text: This field contains UTF-8 [9] encoded text. In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the Camarillo, et al. Expires May 16, 2016 [Page 25] Internet-Draft BFCP November 2015 receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.8. PARTICIPANT-PROVIDED-INFO The following is the format of the PARTICIPANT-PROVIDED-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: PARTICIPANT-PROVIDED-INFO format Text: This field contains UTF-8 [9] encoded text. Padding: One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.9. STATUS-INFO The following is the format of the STATUS-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: STATUS-INFO format Text: This field contains UTF-8 [9] encoded text. Camarillo, et al. Expires May 16, 2016 [Page 26] Internet-Draft BFCP November 2015 In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.10. SUPPORTED-ATTRIBUTES The following is the format of the SUPPORTED-ATTRIBUTES attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: SUPPORTED-ATTRIBUTES format Supp. Attr.: These fields contain the Types of the attributes that are supported by the floor control server in the following format: R: Reserved: This bit MUST be set to zero upon transmission and MUST be ignored upon reception. Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.11. SUPPORTED-PRIMITIVES The following is the format of the SUPPORTED-PRIMITIVES attribute. Camarillo, et al. Expires May 16, 2016 [Page 27] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primitive | Primitive | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: SUPPORTED-PRIMITIVES format Primitive: These fields contain the types of the BFCP messages that are supported by the floor control server. See Table 1 for the list of BFCP primitives. Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.12. USER-DISPLAY-NAME The following is the format of the USER-DISPLAY-NAME attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: USER-DISPLAY-NAME format Text: This field contains the UTF-8 encoded name of the user. Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by Camarillo, et al. Expires May 16, 2016 [Page 28] Internet-Draft BFCP November 2015 the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.13. USER-URI The following is the format of the USER-URI attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: USER-URI format Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user. Messages containing a user's URI in a USER-URI attribute also contain the user's User ID. This way, a client receiving such a message can correlate the user's URI (e.g., the SIP URI the user used to join a conference) with the user's User ID. Padding: One, two, or three octets of padding added so that the contents of the USER-URI attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.14. BENEFICIARY-INFORMATION The BENEFICIARY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as BENEFICIARY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the BENEFICIARY-INFORMATION-HEADER: Camarillo, et al. Expires May 16, 2016 [Page 29] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 0|M| Length | Beneficiary ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: BENEFICIARY-INFORMATION-HEADER format Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference. The following is the ABNF (Augmented Backus-Naur Form) [5] of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE Figure 22: BENEFICIARY-INFORMATION format 5.2.15. FLOOR-REQUEST-INFORMATION The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 1|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) Camarillo, et al. Expires May 16, 2016 [Page 30] Internet-Draft BFCP November 2015 FLOOR-REQUEST-INFORMATION = FLOOR-REQUEST-INFORMATION-HEADER [OVERALL-REQUEST-STATUS] 1*FLOOR-REQUEST-STATUS [BENEFICIARY-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT-PROVIDED-INFO] *EXTENSION-ATTRIBUTE Figure 24: FLOOR-REQUEST-INFORMATION format 5.2.16. REQUESTED-BY-INFORMATION The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 0|M| Length | Requested-by ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: REQUESTED-BY-INFORMATION-HEADER format Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference. The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE Figure 26: REQUESTED-BY-INFORMATION format 5.2.17. FLOOR-REQUEST-STATUS The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-STATUS- HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-STATUS-HEADER: Camarillo, et al. Expires May 16, 2016 [Page 31] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 1|M| Length | Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: FLOOR-REQUEST-STATUS-HEADER format Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference. The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO] *EXTENSION-ATTRIBUTE Figure 28: FLOOR-REQUEST-STATUS format 5.2.18. OVERALL-REQUEST-STATUS The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS- HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 1 0|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: OVERALL-REQUEST-STATUS-HEADER format Floor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) Camarillo, et al. Expires May 16, 2016 [Page 32] Internet-Draft BFCP November 2015 OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO] *EXTENSION-ATTRIBUTE Figure 30: OVERALL-REQUEST-STATUS format 5.3. Message Format This section contains the normative ABNF (Augmented Backus-Naur Form) [5] of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 5.3.1. FloorRequest Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message: FloorRequest = COMMON-HEADER 1*FLOOR-ID [BENEFICIARY-ID] [PARTICIPANT-PROVIDED-INFO] [PRIORITY] *EXTENSION-ATTRIBUTE Figure 31: FloorRequest format 5.3.2. FloorRelease Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message: FloorRelease = COMMON-HEADER FLOOR-REQUEST-ID *EXTENSION-ATTRIBUTE Figure 32: FloorRelease format 5.3.3. FloorRequestQuery Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message: Camarillo, et al. Expires May 16, 2016 [Page 33] Internet-Draft BFCP November 2015 FloorRequestQuery = COMMON-HEADER FLOOR-REQUEST-ID *EXTENSION-ATTRIBUTE Figure 33: FloorRequestQuery format 5.3.4. FloorRequestStatus The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message: FloorRequestStatus = COMMON-HEADER FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 34: FloorRequestStatus format 5.3.5. UserQuery Floor participants and floor chairs request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message: UserQuery = COMMON-HEADER [BENEFICIARY-ID] *EXTENSION-ATTRIBUTE Figure 35: UserQuery format 5.3.6. UserStatus The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message: UserStatus = COMMON-HEADER [BENEFICIARY-INFORMATION] *FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 36: UserStatus format Camarillo, et al. Expires May 16, 2016 [Page 34] Internet-Draft BFCP November 2015 5.3.7. FloorQuery Floor participants and floor chairs request information about a floor or floors by sending a FloorQuery message to the floor control server. The following is the format of the FloorQuery message: FloorQuery = COMMON-HEADER *FLOOR-ID *EXTENSION-ATTRIBUTE Figure 37: FloorQuery format 5.3.8. FloorStatus The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message: FloorStatus = COMMON-HEADER *FLOOR-ID *FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 38: FloorStatus format 5.3.9. ChairAction Floor chairs send instructions to floor control servers by sending them ChairAction messages. The following is the format of the ChairAction message: ChairAction = COMMON-HEADER FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 39: ChairAction format 5.3.10. ChairActionAck Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message: ChairActionAck = COMMON-HEADER *EXTENSION-ATTRIBUTE Figure 40: ChairActionAck format Camarillo, et al. Expires May 16, 2016 [Page 35] Internet-Draft BFCP November 2015 5.3.11. Hello Floor participants and floor chairs MAY check the liveliness of floor control servers by sending a Hello message. Additionally, clients communicating with a floor control server over a an unreliable transport use the Hello message to initiate communication with the server. The following is the format of the Hello message: Hello = COMMON-HEADER *EXTENSION-ATTRIBUTE Figure 41: Hello format 5.3.12. HelloAck Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message: HelloAck = COMMON-HEADER SUPPORTED-PRIMITIVES SUPPORTED-ATTRIBUTES *EXTENSION-ATTRIBUTE Figure 42: HelloAck format 5.3.13. Error Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message: Error = COMMON-HEADER ERROR-CODE [ERROR-INFO] *EXTENSION-ATTRIBUTE Figure 43: Error format 5.3.14. FloorRequestStatusAck When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorRequestStatus message from the floor control server (cf. Section 13.1.2) by sending a FloorRequestStatusAck message. The following is the format of the FloorRequestStatusAck message: Camarillo, et al. Expires May 16, 2016 [Page 36] Internet-Draft BFCP November 2015 FloorRequestStatusAck = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 44: FloorRequestStatusAck format 5.3.15. FloorStatusAck When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorStatus message from the floor control server (cf. Section 13.5.2) by sending a FloorStatusAck message. The following is the format of the FloorStatusAck message: FloorStatusAck = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 45: FloorStatusAck format 5.3.16. Goodbye BFCP entities communicating over an unreliable transport that wish to dissociate themselves from their remote participant do so through the transmission of a Goodbye. The following is the format of the Goodbye message: Goodbye = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 46: Goodbye format 5.3.17. GoodbyeAck BFCP entities communicating over an unreliable transport acknowledge the receipt of a Goodbye message from a peer. The following is the format of the GoodbyeAck message: GoodbyeAck = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 47: GoodbyeAck format 6. Transport The transport over which BFCP entities exchange messages depends on the information the clients obtain for how to to contact the floor control server, as described in Section 3.2. Two transports are supported: TCP, appropriate where connectivity is not impeded by Camarillo, et al. Expires May 16, 2016 [Page 37] Internet-Draft BFCP November 2015 network elements such as NAT devices or media relays; and UDP for those deployments where TCP may not be applicable or appropriate. Informational note: In practice, products are configured to try one transport first and use the other transport as a fallback. Whether TCP or UDP is chosen as underlying transport depends on the type of product and the deployment environment. See Appendix B for additional considerations. 6.1. Reliable Transport BFCP entities may elect to exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing needs to be implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes. A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed. If a BFCP entity (a client or a floor control server) receives data that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished. The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server. Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server. If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it is RECOMMENDED that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished. If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been Camarillo, et al. Expires May 16, 2016 [Page 38] Internet-Draft BFCP November 2015 kicked out from the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client. In cases where a BFCP entity reestablishes a connection due to protocol errors as described above, the entity SHOULD NOT repeatedly reestablish the connection. Rather, if the same protocol errors persist, the entity MUST cease attempts and SHOULD report the error to the human user and/or log the event. This does not preclude the entity from reestablishing a connection when facing a different set of errors. That said, entities MUST avoid overloading the server with reestablishment requests. A connection MUST NOT be reestablished too frequently. The frequency is a matter of implementation, but SHOULD NOT be attempted more than once in a 30 second period of time. 6.2. Unreliable Transport BFCP entities may elect to exchange BFCP messages using UDP datagrams. UDP is an unreliable transport where neither delivery nor ordering is assured. Each BFCP UDP datagram MUST contain exactly one BFCP message or message fragment. To keep large BFCP messages from being fragmented at the IP layer, the fragmentation of BFCP messages that exceed the path MTU size is performed at the BFCP level. Considerations related to fragmentation are covered in Section 6.2.3. The message format for BFCP messages is the same regardless of whether the messages are sent in UDP datagrams or over a TCP stream. Clients MUST announce their presence to the floor control server by sending a Hello message. The floor control server responds to the Hello message with a HelloAck message. The client considers the floor control service as present and available only upon receiving the HelloAck message. The behavior when timers fire, including the determination that a connection is broken, is described in Section 8.3. As described in Section 8, each request sent by a floor participant or chair forms a client transaction that expects an acknowledgement message back from the floor control server within a transaction failure window. Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery subscription) require acknowledgement messages from the floor participant and chair entities to which they were sent. If a Floor Control Server receives data that cannot be parsed, the receiving server MUST send an Error message with parameter value 10 (Unable to parse message) indicating receipt of a malformed message, Camarillo, et al. Expires May 16, 2016 [Page 39] Internet-Draft BFCP November 2015 given that it is possible to parse the received message to such an extent that an Error message may be built. Entities MUST have at most one outstanding request transaction per peer at any one time. Implicit subscriptions occur for a client- initiated request transaction whose acknowledgement is implied by the first server-initiated response for that transaction, followed by zero of more subsequent server-initiated messages corresponding to the same transaction. An example is a FloorRequest message for which there are potentially multiple responses from the floor control server as it processes intermediate states until a terminal state (e.g., Granted or Denied) is attained. The subsequent changes in state for the request are new transactions whose Transaction ID is determined by the floor control server and whose receipt by the client participant is acknowledged with a FloorRequestStatusAck message. By restricting entities to having at most one pending transaction open in a BFCP connection, both the out-of-order receipt of messages as well as the possibility for congestion are mitigated. Additional details regarding congestion control are provided in Section 6.2.1. A server-initiated request (e.g., a FloorStatus with an update from the floor control server) received by a participant before the initial FloorRequestStatus message that closes the client-initiated transaction that was instigated by the FloorRequest MUST be treated as superseding the information conveyed in any such late arriving response. As the floor control server cannot send a second update to the implicit floor status subscription until the first is acknowledged, ordinality is maintained. If a client wishes to end its BFCP connection with a floor control server, it is REQUIRED that the client send a Goodbye message to dissociate itself from any allocated resources. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been kicked out from the conference), it is REQUIRED that the floor control server send a Goodbye message towards the client. 6.2.1. Congestion Control BFCP may be characterized to generate "low data-volume" traffic, per the classification in [13]. Nevertheless is it necessary to ensure suitable and necessary congestion control mechanisms are used for BFCP over UDP. As described in Section 6.2, within the same BFCP connection, every entity - client or server - is only allowed to send one request at a time, and await the acknowledging response. This way at most one datagram is sent per RTT given the message is not lost during transmission. In case the message is lost, the request Camarillo, et al. Expires May 16, 2016 [Page 40] Internet-Draft BFCP November 2015 retransmission timer T1 specified in Section 8.3.1 will fire and the message is retransmitted up to three times, in addition to the original transmission of the message. The default initial interval MUST be set to 500ms, but is adjusted dynamically as described in Section 8.3.1. The interval MUST be doubled after each retransmission attempt. This is similar to the specification of the timer A and its initial value T1 in SIP as described in Section 17.1.1.2 of [18], except that the value of T1 in this protocol is not fixed from one transaction to another. 6.2.2. ICMP Error Handling ICMP is not usable when BFCP is running over an unreliable transport due to risks associated with off-path attacks. Any ICMP messages associated with BFCP running over an unreliable transport MUST be ignored. 6.2.3. Fragmentation Handling When using UDP, a single BFCP message could be fragmented at the IP layer if its overall size exceeds the path MTU of the network. To avoid this happening at the IP layer, a fragmentation scheme for BFCP is defined below. BFCP is designed for achieving small message size, due to the binary encoding as described in Section 1. The fragmentation scheme is therefore deliberately kept simple and straightforward, since the probability of fragmentation of BFCP messages being required is small. By design, the fragmentation scheme does not acknowledge individual BFCP message fragments. The whole BFCP message is acknowledged if received completely. BFCP entities SHOULD consider the path MTU size available between the sender and the receiver and MAY run MTU discovery, such as [23][24][25], for this purpose. When transmitting a BFCP message with size greater than the path MTU, the sender MUST fragment the message into a series of N contiguous data ranges. The size of each of these N messages MUST be smaller than the path MTU to help prevent fragmentation overlap attacks. The value for N is defined as ceil((message size - COMMON-HEADER size) / (path MTU size - COMMON-HEADER size)), where ceil is the integer ceiling function and the COMMON-HEADER size includes the Fragment Offset and Fragment Length fields. The sender then creates N BFCP fragment messages (one for each data range) with the same Transaction ID. The size of each of these N messages, with the COMMON-HEADER included, MUST be smaller than the path MTU. The F flag in the Camarillo, et al. Expires May 16, 2016 [Page 41] Internet-Draft BFCP November 2015 COMMON-HEADER in all the fragments is set to indicate fragmentation of the BFCP message. For each of these fragments the Fragment Offset and Fragment Length fields are included in the COMMON-HEADER. The Fragment Offset field denotes the number of 4-octet units contained in the previous fragments, excluding the common header. The Fragment Length contains the length of the fragment itself, also excluding the common header. Note that the Payload Length field contains the length of the entire, unfragmented message. When a BFCP implementation receives a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission Timer expires. The state machine should handle the BFCP message only after all the fragments for the message have been received. If a fragment of a BFCP message is lost, the sender will not receive an acknowledgement for the message. Therefore the sender will retransmit the message with same transaction ID as specified in Section 8.3. If the acknowledgement message sent by the receiver is lost, then the entire message will be resent by the sender. The receiver MUST then retransmit the acknowledgement. The receiver MAY discard an incomplete buffer utilizing the Response Retransmission Timer, starting the timer after the receipt of the first fragment. A Denial of Service (DoS) attack utilizing the fragmentation scheme described above is mitigated by the fact that the Response Retransmission Timer is started after receipt of the first BFCP message fragment. In addition, the Payload Length field can be compared with the Fragment Offset and Fragment Length fields to verify the message fragments as they arrive. To make DoS attacks with spoofed IP addresses difficult, BFCP entities SHOULD use the cookie exchange mechanism in DTLS [8]. When deciding message fragment size based on path MTU, the BFCP fragmentation handling should take into account how the DTLS record framing expands the datagram size as described in Section 4.1.1.1 of [8]. 6.2.4. NAT Traversal One of the key benefits when using UDP for BFCP communication is the ability to leverage the existing NAT traversal infrastructure and strategies deployed to facilitate transport of the media associated with the video conferencing sessions. Depending on the given deployment, this infrastructure typically includes some subset of ICE [17]. Camarillo, et al. Expires May 16, 2016 [Page 42] Internet-Draft BFCP November 2015 In order to facilitate the initial establishment of NAT bindings, and to maintain those bindings once established, BFCP entities using an unreliable transport are RECOMMENDED to use STUN [12] Binding Indication for keep-alives, as described for ICE [17]. Section 6.7 of [26] provides useful recommendations for middlebox interaction when DTLS is used. Informational note: Since the version number is set to 2 when BFCP is used over an unreliable transport, cf. the Ver field in Section 5.1, it is straight forward to distinguish between STUN and BFCP packets even without checking the STUN magic cookie [12]. In order to facilitate traversal of BFCP packets through NATs, BFCP entities using an unreliable transport are RECOMMENDED to use symmetric ports for sending and receiving BFCP packets, as recommended for RTP/RTCP [11]. 7. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [7] and MUST support DTLS [8] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards compatibility with existing implementations of RFC 4582. In accordance with the recommendations and guidelines in [28], BFCP entities SHOULD support the following cipher suites: o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 8. Protocol Transactions In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. Camarillo, et al. Expires May 16, 2016 [Page 43] Internet-Draft BFCP November 2015 Server-initiated transactions have different requirements and behavior depending on underlying transport: When using a reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). They do not trigger any response. When using an unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor control server. When using BFCP over an unreliable transport, retransmission timer T1 (see Section 8.3) MUST be used for all requests until the transaction is completed. Note that while T1 varies over time, it remains constant for the duration of a given transaction and is only updated at the completion of a transaction. 8.1. Client Behavior A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously. The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server. When using BFCP over an unreliable transport, it is important to choose a Transaction ID value that lets the receiver distinguish the reception of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using an unreliable transport MUST use monotonically increasing Transaction ID values (except for wrap-around). A client receiving a server-initiated transaction over an unreliable transport MUST copy the Transaction ID from the request received from the server into the response. 8.2. Server Behavior A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over a reliable transport. Over an unreliable transport, the Transaction ID shall have the same properties as for Camarillo, et al. Expires May 16, 2016 [Page 44] Internet-Draft BFCP November 2015 client-initiated transactions. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair. 8.3. Timers When BFCP entities are communicating over an unreliable transport, two retransmission timers are employed to help mitigate against loss of datagrams. Retransmission and response caching are not required when BFCP entities communicate over a reliable transport. 8.3.1. Request Retransmission Timer, T1 T1 is a timer that schedules retransmission of a request until an appropriate response is received or until the maximum number of retransmissions have occurred. The timer is computed using the smoothed round-trip time algorithm defind in [2] with an initial retransmission timeout (RTO) value of 500ms and clock granularity (G) of 100ms. In contrast to step 2.4 of Section 2 of [2], if the computed value of RTO is less than 500ms, then RTO shall be set to 500ms. Timer T1 MUST be adjusted with the reception of a response to each request transmitted in order to compute an accurate RTO value, which is the effective T1 value. The RTT value R is the time in milliseconds from the point when a request is transmitted to the time the initial response to that request is received. Responses to retransmitted packets MUST NOT be used to recompute the RTO value, as one cannot determine if a response is to an initial or retransmitted request. If T1 always expires on the initial transmission of a new request, this would suggest the recommended initial T1 (and RTO) value is too low and SHOULD be increased by doubling the initial values of T1 (and RTO) until T1 does not expire when sending a new request. When retransmitting a request, timer T1 is doubled with each retransmission, failing after three unacknowledged retransmission attempts. If a valid response is not received for a client- or server-initiated transaction, the implementation MUST consider the BFCP connection as broken. Implementations SHOULD follow the reestablishment procedure described in section 6. 8.3.2. Response Retransmission Timer, T2 T2 is a timer that, when fired, signals that the BFCP entity can release knowledge of the transaction against which it is running. It is started upon the first transmission of the response to a request and is the only mechanism by which that response is released by the Camarillo, et al. Expires May 16, 2016 [Page 45] Internet-Draft BFCP November 2015 BFCP entity. Any subsequent retransmissions of the same request can be responded to by replaying the cached response, whilst that value is retained until the timer has fired. Refer to Section 6.2.3 for the role this timer has in the fragmentation handling scheme. 8.3.3. Timer Values The table below defines the different timers required when BFCP entities communicate over an unreliable transport. +-------+--------------------------------------+----------------+ | Timer | Description | Value/s | +-------+--------------------------------------+----------------+ | T1 | Initial request retransmission timer | 0.5s (initial) | | T2 | Response retransmission timer | (T1*2^4)*1.25 | +-------+--------------------------------------+----------------+ Table 6: Timers The initial value for T1 is 500ms, which is an estimate of the RTT for completing the transaction. Computation of this value follows the procedures described in Section 8.3.1, which includes exponential backoffs on retransmissions. T2 MUST be set such that it encompasses all legal retransmissions per T1 plus a factor to accommodate network latency between BFCP entities, processing delays, etc. 9. Authentication and Authorization BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, and the extensions in this document are supported, the BFCP clients MUST authenticate the floor control server and the floor control servers MUST authenticate the client before communicating as described above. Note that BFCP entities supporting only the [3] subset may not comply with this mandatory authentication requirement. BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP. Camarillo, et al. Expires May 16, 2016 [Page 46] Internet-Draft BFCP November 2015 Note that future extensions may define additional authentication mechanisms. In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an Error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further. 9.1. TLS/DTLS Based Mutual Authentication BFCP supports TLS/DTLS based mutual authentication between clients and floor control servers. If TLS/DTLS is used, an initial integrity-protected channel is REQUIRED between the client and the floor control server that can be used to exchange their certificates (which MAY be self-signed certificates) or, more commonly, the fingerprints of these certificates. These certificates are used at TLS/DTLS establishment time. The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in [10]. BFCP messages received over an authenticated TLS/DTLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ DTLS by generating an Error message, as described in Section 13.8, with an Error code with a value of 9 (Use TLS) or a value of 11 (Use DTLS) respectively. Clients configured to require the use of TLS/ DTLS MUST ignore unauthenticated messages. Note that future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority). As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server MUST check that messages arriving over a given authenticated TLS/DTLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS/DTLS connection is allowed to use). Camarillo, et al. Expires May 16, 2016 [Page 47] Internet-Draft BFCP November 2015 10. Floor Participant Operations This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs). 10.1. Requesting a Floor A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server. 10.1.1. Sending a FloorRequest Message The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor. Note that the name space for both the User ID and the Beneficiary ID is the same. That is, a given participant is identified by a single 16-bit value that can be used in the User ID in the common header and in several attributes: BENEFICIARY-ID, BENEFICIARY- INFORMATION, and REQUESTED-BY-INFORMATION. The floor participant MUST insert at least one FLOOR-ID attribute in the FloorRequest message. If the client inserts more than one FLOOR- ID attribute, the floor control server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message. The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption. Camarillo, et al. Expires May 16, 2016 [Page 48] Internet-Draft BFCP November 2015 The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute. 10.1.2. Receiving a Response A message from the floor control server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication. The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus message. This way, the floor participant can associate subsequent incoming FloorRequestStatus messages with the ongoing floor request. The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request. The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. If the floor request value is unknown, then the response is still processed. However, no meaningful value can be reported to the user. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user. The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user. Camarillo, et al. Expires May 16, 2016 [Page 49] Internet-Draft BFCP November 2015 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY- INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in the common header. The PRIORITY attribute, when present, contains the priority that was requested by the generator of the FloorRequest message. If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message. 10.1.3. Reception of a Subsequent FloorRequestStatus Message When communicating over an unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction. 10.2. Cancelling a Floor Request and Releasing a Floor A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it. 10.2.1. Sending a FloorRelease Message The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. Note that the FloorRelease message is used to release a floor or floors that were granted and to cancel ongoing floor requests (from the protocol perspective, both are ongoing floor requests). Using the same message in both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire. Camarillo, et al. Expires May 16, 2016 [Page 50] Internet-Draft BFCP November 2015 The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling. Note that if the floor participant requested several floors as an atomic operation (i.e., in a single FloorRequest message), all the floors are released as an atomic operation as well (i.e., all are released at the same time). 10.2.2. Receiving a Response A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRelease message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication. If the response is a FloorRequestStatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message. It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled or Released. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, as its Transaction ID will not match that of the FloorRelease. 11. Chair Operations This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections. Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message. 11.1. Sending a ChairAction Message The ABNF in Section 5.3.9 describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. Camarillo, et al. Expires May 16, 2016 [Page 51] Internet-Draft BFCP November 2015 The floor chair sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor chair sets the User ID in the common header to the floor chair's identifier. The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message. For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor control server will deny the floor request as a whole, regardless of the other floor chair's decision. The floor chair provides the new status of the floor request as it relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request. If the floor chair does not wish to provide a queue position, all the bits of the Queue Position field MUST be set to zero. The floor chair MUST use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and MUST use the Status Denied to reject floor requests in any other status (e.g., Pending and Accepted). The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the ChairAction message to provide a new overall status for the floor request. If the new overall status of the floor request is Accepted, the floor chair can use the Queue Position field to provide a queue position for the floor request. Note that a particular floor control server can implement a different queue for each floor containing all the floor requests that relate to that particular floor, a general queue for all floor requests, or both. Also note that a floor request can involve several floors and that a ChairAction message can only deal with a subset of these floors (e.g., if a single floor chair is not authorized to manage all the floors). In this case, the floor control server will combine the instructions received from the different floor chairs in FLOOR-REQUEST-STATUS attributes to come up with the overall status of the floor request. Camarillo, et al. Expires May 16, 2016 [Page 52] Internet-Draft BFCP November 2015 Note that, while the action of a floor chair may communicate information in the OVERALL-REQUEST-STATUS attribute, the floor control server may override, modify, or ignore this field's content. The floor chair MAY include STATUS-INFO attributes to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intended for human consumption. 11.2. Receiving a Response A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication. A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message. 12. General Client Operations This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both. 12.1. Requesting Information about Floors A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server. 12.1.1. Sending a FloorQuery Message The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. Camarillo, et al. Expires May 16, 2016 [Page 53] Internet-Draft BFCP November 2015 The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorQuery message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute. 12.1.2. Receiving a Response A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. On reception of the FloorQuery message, the floor control server MUST respond with a FloorStatus message or with an Error message. If the response is a FloorStatus message, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either. FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request. After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about. Camarillo, et al. Expires May 16, 2016 [Page 54] Internet-Draft BFCP November 2015 12.1.3. Reception of a Subsequent FloorStatus Message When communicating over an unreliable transport and upon receiving a FloorStatus message from a floor control server, the participant MUST respond with a FloorStatusAck message within the transaction failure window to complete the transaction. 12.2. Requesting Information about Floor Requests A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server. Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request. 12.2.1. Sending a FloorRequestQuery Message The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. The client MUST insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server. 12.2.2. Receiving a Response A message from the floor control server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1. On receiving Camarillo, et al. Expires May 16, 2016 [Page 55] Internet-Draft BFCP November 2015 such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute. If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message. 12.3. Requesting Information about a User A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a floor participant, after experiencing connectivity problems (e.g., its TCP connection with the floor control server was down for a while and eventually was re-established), may need to request information about all the floor requests associated to itself that still exist. 12.3.1. Sending a UserQuery Message The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in the common header of the message), the client MUST insert a BENEFICIARY-ID attribute. Camarillo, et al. Expires May 16, 2016 [Page 56] Internet-Draft BFCP November 2015 12.3.2. Receiving a Response A message from the floor control server is considered a response to the UserQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the UserQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes. If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message. 12.4. Obtaining the Capabilities of a Floor Control Server A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server. 12.4.1. Sending a Hello Message The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. 12.4.2. Receiving Responses A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server. Camarillo, et al. Expires May 16, 2016 [Page 57] Internet-Draft BFCP November 2015 If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message. 13. Floor Control Server Operations This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections. On reception of a message from a client, the floor control server MUST check whether the value of the Primitive is supported. If it is not, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive). On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist). On reception of a message from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message. On reception of a message from a client, the floor control server MUST check whether it understands all the mandatory ('M' bit set) attributes in the message. If the floor control server does not understand all of them, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 4 (Unknown Mandatory Attribute). The Error message SHOULD list the attributes that were not understood. 13.1. Reception of a FloorRequest Message On reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. BFCP allows floor participants to have several ongoing floor requests for the same floor (e.g., the same floor participant can occupy more than one position in a queue at the same time). A floor control server that only supports a certain number of ongoing floor requests per floor participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Camarillo, et al. Expires May 16, 2016 [Page 58] Internet-Draft BFCP November 2015 Ongoing Floor Requests for this Floor) to inform the floor participant. When communicating over an unreliable transport and upon receiving a FloorRequest from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. 13.1.1. Generating the First FloorRequestStatus Message The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates. The policy that a floor control server follows to grant or deny floors is outside the scope of this document. A given floor control server may perform these decisions automatically while another may contact a human acting as a chair every time a decision needs to be made. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the FloorRequestStatus, as described in Section 8.2. Additionally, the floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request. The floor control server MUST assign an identifier that is unique within the conference to this floor request, and MUST insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floor participant (or by a chair or chairs) to refer to this specific floor request in the future. The floor control server MUST copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors being requested (i.e., the floors associated with this particular floor request). The floor control server SHOULD copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped Camarillo, et al. Expires May 16, 2016 [Page 59] Internet-Draft BFCP November 2015 attribute. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY- INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY copy (if present) the PRIORITY attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute. Note that this attribute carries the priority requested by the participant. The priority that the floor control server assigns to the floor request depends on the priority requested by the participant and the rights the participant has according to the policy of the conference. For example, a participant that is only allowed to use the Normal priority may request Highest priority for a floor request. In that case, the floor control server would ignore the priority requested by the participant. The floor control server MAY copy (if present) the PARTICIPANT- PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- INFORMATION grouped attribute. 13.1.2. Generation of Subsequent FloorRequestStatus Messages A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages. When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.) When using BFCP over a reliable transport, the floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0. When using BFCP over an unreliable transport, the Transaction Camarillo, et al. Expires May 16, 2016 [Page 60] Internet-Draft BFCP November 2015 ID MUST be non-zero and unique in the context of outstanding transactions over an unreliable transport as described in Section 8. The rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy. A floor control server may choose to send a new FloorRequestStatus message every time the floor request moves in the floor request queue, while another may choose only to send a new FloorRequestStatus message when the floor request is Granted or Denied. The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates to provide extra information about its decisions regarding the floor request (e.g., why it was denied). Floor participants and floor chairs may request to be informed about the status of a floor following the procedures in Section 12.1. If the processing of a floor request changes the status of a floor (e.g., the floor request is granted and consequently the floor has a new holder), the floor control server needs to follow the procedures in Section 13.5 to inform the clients that have requested that information. The common header and the rest of the attributes are the same as in the first FloorRequestStatus message. The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked. When communicating over an unreliable transport and a FloorRequestStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorRequestStatus message according to Section 6.2. 13.2. Reception of a FloorRequestQuery Message On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. Camarillo, et al. Expires May 16, 2016 [Page 61] Internet-Draft BFCP November 2015 When communicating over an unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The floor control server MUST copy the contents of the FLOOR-REQUEST- ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. Camarillo, et al. Expires May 16, 2016 [Page 62] Internet-Draft BFCP November 2015 13.3. Reception of a UserQuery Message On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a UserQuery from a participant, the floor control server MUST respond with a UserStatus message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the UserStatus message, as described in Section 8.2. The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the common header of the UserQuery message. The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute. The floor control server SHOULD add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST- INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR- REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. Camarillo, et al. Expires May 16, 2016 [Page 63] Internet-Draft BFCP November 2015 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request. The floor control server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- INFORMATION grouped attribute. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. 13.4. Reception of a FloorRelease Message On reception of a FloorRelease message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a FloorRelease from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. Camarillo, et al. Expires May 16, 2016 [Page 64] Internet-Draft BFCP November 2015 The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2. The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request. The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST- INFORMATION attribute. The floor control server MUST identify the floors being released (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHOULD be Released, if the floor (or floors) had been previously granted, or Cancelled, if the floor (or floors) had not been previously granted. The floor control server MAY add a STATUS- INFO attribute with extra information about the floor request. 13.5. Reception of a FloorQuery Message On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. When communicating over an unreliable transport and upon receiving a FloorQuery from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction. A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor Control Servers keep clients informed by using FloorStatus messages. An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors. Camarillo, et al. Expires May 16, 2016 [Page 65] Internet-Draft BFCP November 2015 The information FloorQuery messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests, while a regular user may not be authorized to do so. 13.5.1. Generation of the First FloorStatus Message The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2. If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant. If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST- INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST- INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR- REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Camarillo, et al. Expires May 16, 2016 [Page 66] Internet-Draft BFCP November 2015 The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. 13.5.2. Generation of Subsequent FloorStatus Messages If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8). After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8). The rate at which the floor control server sends FloorStatus messages is a matter of local policy. A floor control server may choose to send a new FloorStatus message every time a new floor request arrives, while another may choose to only send a new FloorStatus message when a new floor request is Granted. When communicating over an unreliable transport and a FloorStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorStatus message according to Section 6.2. Camarillo, et al. Expires May 16, 2016 [Page 67] Internet-Draft BFCP November 2015 13.6. Reception of a ChairAction Message On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a ChairAction from a chair, the floor control server MUST respond with a ChairActionAck message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2. The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor) but does not necessarily need to perform it as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server. For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state. If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that the floor control server assign a queue position (e.g., the last in the queue) to the floor request based on the local policy of the floor control server. (Of course, such a request only applies if the floor control server implements a queue.) Camarillo, et al. Expires May 16, 2016 [Page 68] Internet-Draft BFCP November 2015 13.7. Reception of a Hello Message On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. If the version of BFCP specified in the Version field of the COMMON- HEADER is supported by the floor control server, it MUST respond with the same version number in the HelloAck; this defines the version for all subsequent BFCP messages within this BFCP Connection. When communicating over an unreliable transport and upon receiving a Hello from a participant, the floor control server MUST respond with a HelloAck message within the transaction failure window to complete the transaction. The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2. The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server. The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server. 13.8. Error Message Generation Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in Section 5.3.13 describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2. The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR- INFO attribute with extra information about the error. Camarillo, et al. Expires May 16, 2016 [Page 69] Internet-Draft BFCP November 2015 14. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. An example of other mechanisms is IPSec [19] to effectively secure a non-secure BFCP connection. The remainder of this section analyzes some of the threats against BFCP and how they are addressed. An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections. The floor control server assumes that attackers cannot hijack the TLS/DTLS connection and, therefore, that messages over the TLS/DTLS connection come from the client that was initially authenticated. An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections, as well as ensuring clients only send and accept messages over authenticated TLS/DTLS connections. Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS/DTLS connections prevents this attack. An attacker may attempt to fetch a valid message sent by a client to a floor control server and replay it over a connection between the attacker and the floor control server. This attack is prevented by having floor control servers check that messages arriving over a given authenticated TLS/DTLS connection use an authorized user ID (i.e., a user ID that the user that established the authenticated TLS/DTLS connection is allowed to use). Camarillo, et al. Expires May 16, 2016 [Page 70] Internet-Draft BFCP November 2015 Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS/DTLS confidentiality prevents this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an encryption algorithm according to Section 7. 15. IANA Considerations [Note to IANA: Much of this text exists from the previous version of this document. While the old and new additions to the registries are presented here, the items for which IANA needs to take action with respect to this draft are highlighted with "Note to IANA", as with this note and the one immediately following. Throughout this document, though, RFC XXXX needs to be replaced with this RFC and the IANA registries for BFCP should to refer only to this RFC.] [Note to IANA: This section instructs the IANA to register new entries in the BFCP Primitive subregistry in Section 15.2 and for the BFCP Error Code subregistry in Section 15.4.] The IANA has created a registry for BFCP parameters called "Binary Floor Control Protocol (BFCP) Parameters". This registry has a number of subregistries, which are described in the following sections. 15.1. Attribute Subregistry This section establishes the Attribute subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP attributes shall be "Specification Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics. For each BFCP attribute, the IANA registers its type, its name, and the reference to the RFC where the attribute is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 71] Internet-Draft BFCP November 2015 +------+---------------------------+------------+ | Type | Attribute | Reference | +------+---------------------------+------------+ | 1 | BENEFICIARY-ID | [RFC XXXX] | | 2 | FLOOR-ID | [RFC XXXX] | | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | | 4 | PRIORITY | [RFC XXXX] | | 5 | REQUEST-STATUS | [RFC XXXX] | | 6 | ERROR-CODE | [RFC XXXX] | | 7 | ERROR-INFO | [RFC XXXX] | | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | | 9 | STATUS-INFO | [RFC XXXX] | | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | | 12 | USER-DISPLAY-NAME | [RFC XXXX] | | 13 | USER-URI | [RFC XXXX] | | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | +------+---------------------------+------------+ Table 7: Initial values of the BFCP Attribute subregistry 15.2. Primitive Subregistry [Note to IANA: This section instructs the IANA to register the following new values for the BFCP Primitive subregistry: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] This section establishes the Primitive subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP primitives shall be "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics. For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 72] Internet-Draft BFCP November 2015 +-------+-----------------------+------------+ | Value | Primitive | Reference | +-------+-----------------------+------------+ | 1 | FloorRequest | [RFC XXXX] | | 2 | FloorRelease | [RFC XXXX] | | 3 | FloorRequestQuery | [RFC XXXX] | | 4 | FloorRequestStatus | [RFC XXXX] | | 5 | UserQuery | [RFC XXXX] | | 6 | UserStatus | [RFC XXXX] | | 7 | FloorQuery | [RFC XXXX] | | 8 | FloorStatus | [RFC XXXX] | | 9 | ChairAction | [RFC XXXX] | | 10 | ChairActionAck | [RFC XXXX] | | 11 | Hello | [RFC XXXX] | | 12 | HelloAck | [RFC XXXX] | | 13 | Error | [RFC XXXX] | | 14 | FloorRequestStatusAck | [RFC XXXX] | | 15 | FloorStatusAck | [RFC XXXX] | | 16 | Goodbye | [RFC XXXX] | | 17 | GoodbyeAck | [RFC XXXX] | +-------+-----------------------+------------+ Table 8: Initial values of the BFCP primitive subregistry 15.3. Request Status Subregistry This section establishes the Request Status subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP request status shall be "Specification Required". For the purposes of this subregistry, the BFCP request status for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the request status. For each BFCP request status, the IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 73] Internet-Draft BFCP November 2015 +-------+-----------+------------+ | Value | Status | Reference | +-------+-----------+------------+ | 1 | Pending | [RFC XXXX] | | 2 | Accepted | [RFC XXXX] | | 3 | Granted | [RFC XXXX] | | 4 | Denied | [RFC XXXX] | | 5 | Cancelled | [RFC XXXX] | | 6 | Released | [RFC XXXX] | | 7 | Revoked | [RFC XXXX] | +-------+-----------+------------+ Table 9: Initial values of the Request Status subregistry 15.4. Error Code Subregistry [Note to IANA: This section instructs the IANA to register the following new values for the BFCP Error Code subregistry: 10, 11, 12, 13 and 14.] This section establishes the Error Code subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP error codes shall be "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it. For each BFCP primitive, the IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 74] Internet-Draft BFCP November 2015 +-------+--------------------------------------+------------+ | Value | Meaning | Reference | +-------+--------------------------------------+------------+ | 1 | Conference does not Exist | [RFC XXXX] | | 2 | User does not Exist | [RFC XXXX] | | 3 | Unknown Primitive | [RFC XXXX] | | 4 | Unknown Mandatory Attribute | [RFC XXXX] | | 5 | Unauthorized Operation | [RFC XXXX] | | 6 | Invalid Floor ID | [RFC XXXX] | | 7 | Floor Request ID Does Not Exist | [RFC XXXX] | | 8 | You have Already Reached the Maximum | [RFC XXXX] | | | Number of Ongoing Floor Requests for | | | | this Floor | | | 9 | Use TLS | [RFC XXXX] | | 10 | Unable to parse message | [RFC XXXX] | | 11 | Use DTLS | [RFC XXXX] | | 12 | Unsupported Version | [RFC XXXX] | | 13 | Incorrect Message Length | [RFC XXXX] | | 14 | Generic Error | [RFC XXXX] | +-------+--------------------------------------+------------+ Table 10: Initial Values of the Error Code subregistry 16. Changes from RFC 4582 Following is the list of technical changes and other non-trivial fixes from [3]. 16.1. Extensions for an unreliable transport Main purpose of this work was to revise the specification to support BFCP over an unreliable transport, resulting in the following changes: 1. Overview of Operation (Section 4): Changed the description of client-initiated and server-initiated transactions, referring to Section 8. 2. COMMON-HEADER Format (Section 5.1): Ver(sion) field, where the value 2 is used for the extensions for an unreliable transport. Added new R and F flag-bits for an unreliable transport. Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length fields. 3. New primitives (Section 5.1): Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck. Camarillo, et al. Expires May 16, 2016 [Page 75] Internet-Draft BFCP November 2015 4. New error codes (Section 5.2.6): Added three new error codes: "Unable to Parse Message", "Use DTLS" and "Unsupported Version". Note that two additional error codes were added, see Section 16.2. 5. ABNF for new primitives (Section 5.3): New subsections with normative ABNF for the new primitives. 6. Transport split in two (Section 6): Section 6 specifying the transport was split in two subsections; Section 6.1 for a reliable transport and Section 6.2 for an unreliable transport. Where the specification for an unreliable transport amongst other issues deals with reliability, congestion control, fragmentation and ICMP. 7. Mandate DTLS (Section 7 and Section 9): Mandate DTLS support when transport over UDP is used. 8. Transaction changes (Section 8): Server-initiated transactions over an unreliable transport has non-zero and unique Transaction ID. Over an unreliable transport, the retransmit timers T1 and T2 described in Section 8.3 apply. 9. Requiring timely response (Section 8.3, Section 10.1.2, Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, Section 12.4.2, Section 10.1.3 and Section 12.1.3): Describing that a given response must be sent within the transaction failure window to complete the transaction. 10. Updated IANA Considerations (Section 15): Added the new primitives and error codes to Section 15.2 and Section 15.4 respectively. 11. Examples over an unreliable transport (Appendix A): Added sample interactions over an unreliable transport for the scenarios in Figure 2 and Figure 3 12. Motivation for an unreliable transport (Appendix B): Introduction to and motivation for extending BFCP to support an unreliable transport. 16.2. Other changes Clarifications and bug fixes: Camarillo, et al. Expires May 16, 2016 [Page 76] Internet-Draft BFCP November 2015 1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, Figure 28, Figure 30, and the ABNF figures in Section 5.3): Although formally correct in [3], the notation has changed in a number of Figures to an equivalent form for clarity, e.g., s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in the other figures. 2. Typo (Section 12.4.2): Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the second paragraph. 3. Corrected attribute type (Section 13.1.1): Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in the eighth paragraph, since the note below describes priority and that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. 4. New error codes (Section 5.2.6): Added two additional error codes: "Incorrect Message Length" and "Generic Error". 5. Assorted clarifications (Across the document): Language clarifications as a result of reviews. Also, the normative language where tightened where appropriate, i.e. changed from SHOULD strength to MUST in a number of places. 17. Acknowledgements The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for RFC 4582 [3]. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments during the work with RFC 4582. The authors also acknowledge contributions to the revision of BFCP for use over an unreliable transport from Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a thorough review revealing issues that needed clarification and changes. Useful and important final reviews were done by Mary Barnes. Paul Jones helped tremendously as editor for changes addressing IESG review comments. 18. References Camarillo, et al. Expires May 16, 2016 [Page 77] Internet-Draft BFCP November 2015 18.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [2] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, DOI 10.17487/RFC2988, November 2000, . [3] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, . [4] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/ RFC5018, September 2007, . [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [10] Camarillo, G., Kristensen, T., and P. Jones, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12 (work in progress), September 2015. Camarillo, et al. Expires May 16, 2016 [Page 78] Internet-Draft BFCP November 2015 [11] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, . [12] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [13] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, . 18.2. Informational References [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [15] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, DOI 10.17487/RFC4376, February 2006, . [16] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, . [17] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [19] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . Camarillo, et al. Expires May 16, 2016 [Page 79] Internet-Draft BFCP November 2015 [20] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, . [21] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, DOI 10.17487/RFC6503, March 2012, . [22] Barnes, M., Miniero, L., Presta, R., and S. Romano, "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March 2012, . [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [24] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [25] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [26] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [27] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/ RFC6951, May 2013, . [28] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . Camarillo, et al. Expires May 16, 2016 [Page 80] Internet-Draft BFCP November 2015 [29] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, . [30] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/ RFC6081, January 2011, . [31] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [32] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [33] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in progress), July 2010. [34] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", draft-ietf-mmusic- media-path-middleboxes-07 (work in progress), May 2013. [35] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", 2005, . [36] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", April 2005, . Appendix A. Example Call Flows for BFCP over an Unreliable Transport With reference to Section 4.1, the following figures show representative call-flows for requesting and releasing a floor, and obtaining status information about a floor when BFCP is deployed over an unreliable transport. The figures here show a loss-less interaction. Floor Participant Floor Control Server |(1) FloorRequest | |Transaction Responder: 0 | |Transaction ID: 123 | Camarillo, et al. Expires May 16, 2016 [Page 81] Internet-Draft BFCP November 2015 |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction Responder: 1 | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(3) FloorRequestStatus | |Transaction Responder: 0 | |Transaction ID: 124 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(4) FloorRequestStatusAck | |Transaction Responder: 1 | |Transaction ID: 124 | |User ID: 234 | |---------------------------------------------->| | | |(5) FloorRequestStatus | |Transaction Responder: 0 | |Transaction ID: 125 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(6) FloorRequestStatusAck | Camarillo, et al. Expires May 16, 2016 [Page 82] Internet-Draft BFCP November 2015 |Transaction Responder: 1 | |Transaction ID: 125 | |User ID: 234 | |---------------------------------------------->| | | |(7) FloorRelease | |Transaction Responder: 0 | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 | |---------------------------------------------->| | | |(8) FloorRequestStatus | |Transaction Responder: 1 | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| Figure 48: Requesting and releasing a floor Note that in Figure 48, the FloorRequestStatus message from the floor control server to the floor participant is a transaction-closing message as a response to the client-initiated transaction with Transaction ID 154. As such, it is not followed by a FloorRequestStatusAck message from the floor participant to the floor control server. Floor Participant Floor Control Server |(1) FloorQuery | |Transaction Responder: 0 | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorStatus | |Transaction Responder: 1 | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | Camarillo, et al. Expires May 16, 2016 [Page 83] Internet-Draft BFCP November 2015 | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(3) FloorStatus | |Transaction Responder: 0 | |Transaction ID: 258 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(4) FloorStatusAck | |Transaction Responder: 1 | |Transaction ID: 258 | |User ID: 234 | |---------------------------------------------->| Camarillo, et al. Expires May 16, 2016 [Page 84] Internet-Draft BFCP November 2015 | | |(5) FloorStatus | |Transaction Responder: 0 | |Transaction ID: 259 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(6) FloorStatusAck | |Transaction Responder: 1 | |Transaction ID: 259 | |User ID: 234 | |---------------------------------------------->| Figure 49: Obtaining status information about a floor Appendix B. Motivation for Supporting an Unreliable Transport This appendix is contained in this document as an aid to understand the background and rationale for adding support for unreliable transport. B.1. Motivation In existing video conferencing deployments, BFCP is used to manage the floor for the content sharing associated with the conference. For peer to peer scenarios, including business to business conferences and point to point conferences in general, it is frequently the case that one or both endpoints exists behind a NAT. BFCP roles are negotiated in the offer/answer exchange as specified in [10], resulting in one endpoint being responsible for opening the TCP connection used for the BFCP communication. Camarillo, et al. Expires May 16, 2016 [Page 85] Internet-Draft BFCP November 2015 +---------+ | Network | +---------+ +-----+ / \ +-----+ | NAT |/ \| NAT | +-----+ +-----+ +----+ / \ +----+ |BFCP|/ \|BFCP| | UA | | UA | +----+ +----+ Figure 50: Use Case The communication session between the video conferencing endpoints typically consists of a number of RTP over UDP media streams, for audio and video, and a BFCP connection for floor control. Existing deployments are most common in, but not limited to, enterprise networks. In existing deployments, NAT traversal for the RTP streams works using ICE and/or other methods, including those described in [34]. When enhancing an existing SIP based video conferencing deployment with support for content sharing, the BFCP connection often poses a problem. The reasons for this fall into two general classes. First, there may be a strong preference for UDP based signaling in general. On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter- working gateways), TCP can suffer from head of line blocking, and it uses many kernel buffers. Network operators view UDP as a way to avoid both of these. Second, establishment and traversal of the TCP connection involving ephemeral ports, as is typically the case with BFCP over TCP, can be problematic, as described in Appendix A of [32]. A broad study of NAT behavior and peer-to-peer TCP establishment for a comprehensive set of TCP NAT traversal techniques over a wide range of commercial NAT products concluded it was not possible to establish a TCP connection in 11% of the cases [35]. The results are worse when focusing on enterprise NATs. A study of hole punching as a NAT traversal technique across a wide variety of deployed NATs reported consistently higher success rates when using UDP than when using TCP [36]. It is worth noticing that BFCP over UDP is already being used in real deployments, underlining the necessity to specify a common way to exchange BFCP messages where TCP is not appropriate, to avoid a situation where multiple different and non-interoperable implementations would co-exist in the market. The purpose of this draft is to formalize and publish the extension from the standard specification to facilitate complete interoperability between implementations. Camarillo, et al. Expires May 16, 2016 [Page 86] Internet-Draft BFCP November 2015 B.1.1. Alternatives Considered In selecting the approach of defining UDP as an alternate transport for BFCP, several alternatives were considered and explored to some degree. Each of these is discussed briefly in the following subsections. In summary, while the not chosen alternatives work in a number of scenarios, they are not sufficient, in and of themselves, to address the use case targeted by this draft. The last alternative, presented in Appendix B.1.1.7, is the selected one and is specified in this draft. It is also worth noting that the IETF Transport Area were asked for a way to tunnel TCP over UDP, but at that point there was no consensus on how to achieve that. B.1.1.1. ICE TCP ICE TCP [32] extends ICE to TCP based media, including the ability to offer a mix of TCP and UDP based candidates for a single stream. ICE TCP has, in general, a lower success probability for enabling TCP connectivity without a relay if both of the hosts are behind a NAT (see Appendix A of [32]) than enabling UDP connectivity in the same scenarios. The happens because many of the currently deployed NATs in video conferencing networks do not support the flow of TCP hand shake packets seen in case of TCP simultaneous-open, either because they do not allow incoming TCP SYN packets from an address to which a SYN packet has been sent to recently, or because they do not properly process the subsequent SYNACK. Implementing various techniques advocated for candidate collection in [32] should increase the success probability, but many of these techniques require support from some network elements (e.g., from the NATs). Such support is not common in enterprise NATs. B.1.1.2. Teredo Teredo [29] enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. Teredo extensions [30] provide additional capabilities to Teredo, including support for more types of NATs and support for more efficient communication. As defined, Teredo could be used to make BFCP work for the video conferencing use cases addressed in this draft. However, running the service requires the help of "Teredo servers" and "Teredo relays" [29]. These servers and relays generally do not exist in the existing video conferencing deployments. It also requires IPv6 awareness on the endpoints. It should also be noted that ICMP6, as used with Teredo to complete an initial protocol exchange and confirm Camarillo, et al. Expires May 16, 2016 [Page 87] Internet-Draft BFCP November 2015 that the appropriate NAT bindings have been set up, is not a conventional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls discard ICMP messages. As these networks continue to evolve and tackle the transaction to IPv6, Teredo servers and relays may be deployed, making Teredo available as a suitable alternative to BFCP over UDP. B.1.1.3. GUT GUT [33] attempts to facilitate tunneling over UDP by encapsulating the native transport protocol and its payload (in general the whole IP payload) within a UDP packet destined to the well-known port GUT_P. Unfortunately, it requires user-space TCP, for which there is not a readily available implementation, and creating one is a large project in itself. This draft has expired and its future is still not clear as it has not yet been adopted by a working group. B.1.1.4. UPnP IGD Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on the edge of the network, providing connectivity to the Internet for computers internal to the LAN, but do not allow Internet devices to connect to computers on the internal LAN. IGDs enable a computer on an internal LAN to create port mappings on their NAT, through which hosts on the Internet can send data that will be forwarded to the computer on the internal LAN. IGDs may be self-contained hardware devices or may be software components provided within an operating system. In considering UPnP IGD, several issues exist. Not all NATs support UPnP, and many that do support it are configured with it turned off by default. NATs are often multilayered, and UPnP does not work well with such NATs. For example, a typical DSL modems acts as a NAT, and the user plugs in a wireless access point behind that, which adds another layer NAT. The client can discover the first layer of NAT using multicast but it is harder to figure out how to discover and control NATs in the next layer up. B.1.1.5. NAT PMP The NAT Port Mapping Protocol (NAT PMP) allows a computer in a private network (behind a NAT router) to automatically configure the router to allow parties outside the private network to contact it. NAT PMP runs over UDP. It essentially automates the process of port forwarding. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it. Camarillo, et al. Expires May 16, 2016 [Page 88] Internet-Draft BFCP November 2015 Many NATs do not support PMP. In those that do support it, it has similar issues with negotiation of multilayer NATs as UPnP. Video conferencing is used extensively in enterprise networks, and NAT PMP is not generally available in enterprise-class routers. B.1.1.6. SCTP It would be quite straight forward to specify a BFCP binding for SCTP [31], and then tunnel SCTP over UDP in the use case described in Appendix B.1. SCTP is gaining some momentum currently. There was ongoing discussion in the RTCWeb WG regarding this approach, which resulted in [27]. However, this approach for tunneling over UDP was not mature enough when considered and not even fully specified. B.1.1.7. BFCP over UDP transport To overcome the problems with establishing TCP flows between BFCP entities, an alternative is to define UDP as an alternate transport for BFCP, leveraging the same mechanisms in place for the RTP over UDP media streams for the BFCP communication. When using UDP as the transport, it is recommended to follow the guidelines provided in [13]. Minor changes to the transaction model are introduced in that all requests now have an appropriate response to complete the transaction. The requests are sent with a retransmit timer associated with the response to achieve reliability. This alternative does not change the semantics of BFCP. It permits UDP as an alternate transport. Existing implementations, in the spirit of the approach detailed in earlier versions of this draft, have demonstrated this approach to be feasible. Initial compatibility among implementations has been achieved at previous interoperability events. The authors view this extension as a pragmatic solution to an existing deployment challenge. This is the chosen approach, and the extensions are specified in this document. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 FI-02420 Jorvas Finland Email: gonzalo.camarillo@ericsson.com Camarillo, et al. Expires May 16, 2016 [Page 89] Internet-Draft BFCP November 2015 Keith Drage Alcatel-Lucent Quadrant, StoneHill Green, Westlea Swindon, Wilts UK Email: drage@alcatel-lucent.com Tom Kristensen Cisco Philip Pedersens vei 1 NO-1366 Lysaker Norway Email: tomkrist@cisco.com, tomkri@ifi.uio.no Joerg Ott Aalto University Otakaari 5 A FI-02150 Espoo Finland Email: jo@comnet.tkk.fi Charles Eckel Cisco 707 Tasman Drive California, CA 95035 United States Email: eckelcu@cisco.com Camarillo, et al. Expires May 16, 2016 [Page 90] ./draft-ietf-sidr-origin-validation-signaling-11.txt0000664000764400076440000003055613035307113021710 0ustar iustyiusty SIDR P. Mohapatra Internet-Draft Sproute Networks Intended status: Standards Track K. Patel Expires: July 14, 2017 Cisco J. Scudder Juniper Networks D. Ward Cisco R. Bush Internet Initiative Japan, Inc. January 10, 2017 BGP Prefix Origin Validation State Extended Community draft-ietf-sidr-origin-validation-signaling-11 Abstract This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Mohapatra, et al. Expires July 14, 2017 [Page 1] Internet-Draft Prefix Origin Validation State Ext. Comm. January 2017 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Origin Validation State Extended Community . . . . . . . . . 2 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 3 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Origin Validation State Extended Community The origin validation state extended community is an opaque extended community [RFC4360] with the following encoding: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x43 | 0x00 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |validationstate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mohapatra, et al. Expires July 14, 2017 [Page 2] Internet-Draft Prefix Origin Validation State Ext. Comm. January 2017 The value of the high-order octet of the extended Type Field is 0x43, which indicates it is non-transitive. The value of the low-order octet of the extended type field as assigned by IANA is 0x00. The Reserved field MUST be set to 0 and ignored upon the receipt of this community. The last octet of the extended community is an unsigned integer that gives the route's validation state [RFC6811]. It can assume the following values: +-------+-----------------------------+ | Value | Meaning | +-------+-----------------------------+ | 0 | Lookup result = "valid" | | 1 | Lookup result = "not found" | | 2 | Lookup result = "invalid" | +-------+-----------------------------+ If the router is configured to support the extensions defined in this draft, it SHOULD attach the origin validation state extended community to BGP UPDATE messages sent to IBGP peers by mapping the computed validation state in the last octet of the extended community. Similarly on the receiving IBGP speakers, the validation state of an IBGP route SHOULD be derived directly from the last octet of the extended community, if present. An implementation SHOULD NOT send more than one instance of the origin validation state extended community. However, if more than one instance is received, an implementation MUST disregard all instances other than the one with the numerically-greatest validation state value. If the value received is greater than the largest specified value (2), the implementation MUST apply a strategy similar to attribute discard [RFC7606] by discarding the erroneous community and logging the error for further analysis. By default, implementations MUST drop the origin validation state extended community if received from an EBGP peer, without further processing it. Similarly, by default an implementation SHOULD NOT send the community to EBGP peers. However it SHOULD be possible to configure an implementation to send or accept the community when warranted. An example of a case where the community would reasonably be received from, or sent to, an EBGP peer is when two adjacent ASes are under control of the same administration. A second example is documented in [I-D.ietf-sidr-route-server-rpki-light]. 3. Deployment Considerations In deployment scenarios where not all the speakers in an autonomous system are upgraded to support the extensions defined in this document, it is necessary to define policies that match on the origin Mohapatra, et al. Expires July 14, 2017 [Page 3] Internet-Draft Prefix Origin Validation State Ext. Comm. January 2017 validation extended community and set another BGP attribute [RFC6811] that influences the best path selection the same way as what would have been enabled by an implementation of this extension. 4. Acknowledgements The authors would like to acknowledge the valuable review and suggestions from Wesley George, Roque Gagliano and Bruno Decraene on this document. 5. IANA Considerations IANA has assigned the value 0x00 from the "Non-Transitive Opaque Extended Community Sub-Types" registry. The value is called "BGP Origin Validation State Extended Community". 6. Security Considerations Security considerations such as those described in [RFC4272] continue to apply. Since this document introduces an extended community that will generally be used to affect route selection, the analysis in Section 4.5 ("Falsification") of [RFC4593] is relevant. These issues are neither new, nor unique to the origin validation extended community. The security considerations provided in [RFC6811] apply equally to this application of origin validation. In addition, this document describes a scheme where router A outsources validation to some router B. If this scheme is used, the participating routers should have the appropriate trust relationship -- B should trust A either because they are under the same administrative control or for some other reason (for example, consider [I-D.ietf-sidr-route-server-rpki-light]). The security properties of the propagation path between the two routers should also be considered. See [RFC7454] Section 5.1 for advice regarding protection of the propagation path. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Mohapatra, et al. Expires July 14, 2017 [Page 4] Internet-Draft Prefix Origin Validation State Ext. Comm. January 2017 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . 7.2. Informative References [I-D.ietf-sidr-route-server-rpki-light] King, T., Kopp, D., Lambrianidis, A., and A. Fenioux, "Signaling Prefix Origin Validation Results from a Route- Server to Peers", draft-ietf-sidr-route-server-rpki- light-01 (work in progress), December 2016. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, . [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, DOI 10.17487/RFC4593, October 2006, . [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . Authors' Addresses Pradosh Mohapatra Sproute Networks Email: mpradosh@yahoo.com Mohapatra, et al. Expires July 14, 2017 [Page 5] Internet-Draft Prefix Origin Validation State Ext. Comm. January 2017 Keyur Patel Cisco 170 W. Tasman Drive San Jose, CA 95124 Email: keyupate@cisco.com John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 Email: jgs@juniper.net Dave Ward Cisco 170 W. Tasman Drive San Jose, CA 95124 Email: dward@cisco.com Randy Bush Internet Initiative Japan, Inc. 5147 Crystal Springs Bainbridge Island, Washington 98110 Email: randy@psg.com Mohapatra, et al. Expires July 14, 2017 [Page 6] ./draft-ietf-clue-data-model-schema-17.txt0000664000764400076440000045012312753613400017563 0ustar iustyiusty CLUE Working Group R. Presta Internet-Draft S P. Romano Intended status: Standards Track University of Napoli Expires: February 14, 2017 August 13, 2016 An XML Schema for the CLUE data model draft-ietf-clue-data-model-schema-17 Abstract This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 14, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Presta & Romano Expires February 14, 2017 [Page 1] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. . . . . . . . . . . . . . . . . . . . . . . . 19 6. . . . . . . . . . . . . . . . . . . . . . . . 19 7. . . . . . . . . . . . . . . . . . . . . . . . 19 8. . . . . . . . . . . . . . . . . . . . . . . 19 9. . . . . . . . . . . . . . . . . . . . . . . . . 19 10. . . . . . . . . . . . . . . . . . . . . . . 19 11. . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. captureID attribute . . . . . . . . . . . . . . . . . . . 22 11.2. mediaType attribute . . . . . . . . . . . . . . . . . . . 22 11.3. . . . . . . . . . . . . . . . . . . . 22 11.4. . . . . . . . . . . . . . . . . . . . . . 22 11.5. . . . . . . . . . . . . . . . . . . 23 11.5.1. . . . . . . . . . . . . . . . . . . . 24 11.5.2. . . . . . . . . . . . . . . . . . . . . 25 11.6. . . . . . . . . . . . . . . . . . 26 11.7. . . . . . . . . . . . . . . . . . . . . . . . . 26 11.8. . . . . . . . . . . . . . . . . . . . 26 11.9. . . . . . . . . . . . . . . . . . . . 27 11.10. . . . . . . . . . . . . . . . . . . . . . . . . 27 11.11. . . . . . . . . . . . . . . . . . . . . . . 28 11.12. . . . . . . . . . . . . . . . . . . . . . . 29 11.13. . . . . . . . . . . . . . . . . . . . . . . 29 11.14. . . . . . . . . . . . . . . . . . . . . . . . 29 11.15. . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.16. . . . . . . . . . . . . . . . . . . . . . . . 30 11.17. . . . . . . . . . . . . . . . . . . . . . . . 30 11.18. . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.19. . . . . . . . . . . . . . . . . . . . . . 31 11.20. . . . . . . . . . . . . . . . . . . . . . 31 11.21. . . . . . . . . . . . . . . . . . . . . 32 11.21.1. . . . . . . . . . . . . . . . . . . . . 32 12. Audio captures . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. . . . . . . . . . . . . . . . . . . 33 13. Video captures . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Text captures . . . . . . . . . . . . . . . . . . . . . . . . 34 15. Other capture types . . . . . . . . . . . . . . . . . . . . . 34 16. . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1. . . . . . . . . . . . . . . . . . . . 36 16.2. . . . . . . . . . . . . . . . . . . . . . . 36 Presta & Romano Expires February 14, 2017 [Page 2] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 16.3. sceneID attribute . . . . . . . . . . . . . . . . . . . . 36 16.4. scale attribute . . . . . . . . . . . . . . . . . . . . . 36 17. . . . . . . . . . . . . . . . . . . . . . . . . . 37 17.1. . . . . . . . . . . . . . . . . . . . . 38 17.2. sceneViewID attribute . . . . . . . . . . . . . . . . . . 38 18. . . . . . . . . . . . . . . . . . . . . . . . 38 18.1. . . . . . . . . . . . . . . . . . . . 39 18.2. . . . . . . . . . . . . . . . . . . . . 39 18.3. encodingGroupID attribute . . . . . . . . . . . . . . . . 39 19. . . . . . . . . . . . . . . . . . . . . . . 39 19.1. setID attribute . . . . . . . . . . . . . . . . . . . . . 40 19.2. mediaType attribute . . . . . . . . . . . . . . . . . . . 40 19.3. . . . . . . . . . . . . . . . . . . . 41 19.4. . . . . . . . . . . . . . . . . . . . . 41 19.5. . . . . . . . . . . . . . . . . . . . 41 20. . . . . . . . . . . . . . . . . . . . . . . . . . 41 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 21.1. . . . . . . . . . . . . . . . . . . . . . . . . 42 21.1.1. personID attribute . . . . . . . . . . . . . . . . . 42 21.1.2. . . . . . . . . . . . . . . . . . . . . 42 21.1.3. . . . . . . . . . . . . . . . . . . . . 43 22. . . . . . . . . . . . . . . . . . . . . . . 43 22.1. . . . . . . . . . . . . . . . . . . . . . . . 44 22.2. . . . . . . . . . . . . . . . . . . . . . . 44 22.3. . . . . . . . . . . . . . . . . . . . 44 23. . . . . . . . . . . . . . . . . . . . . . . . . . . 44 24. XML Schema extensibility . . . . . . . . . . . . . . . . . . . 45 24.1. Example of extension . . . . . . . . . . . . . . . . . . 46 25. Security considerations . . . . . . . . . . . . . . . . . . . 48 26. IANA considerations . . . . . . . . . . . . . . . . . . . . . 49 26.1. XML namespace registration . . . . . . . . . . . . . . . 49 26.2. XML Schema registration . . . . . . . . . . . . . . . . . 50 26.3. MIME Media Type Registration for "application/clue_info+xml" . . . . . . . . . . . . . . . 50 26.4. Registry for acceptable values . . . . . . . . . . 51 26.5. Registry for acceptable values . . . . . . 51 26.6. Registry for acceptable values . . 51 26.7. Registry for acceptable values . . . . . . . 52 27. Sample XML file . . . . . . . . . . . . . . . . . . . . . . . 52 28. MCC example . . . . . . . . . . . . . . . . . . . . . . . . . 60 29. Diff with draft-ietf-clue-data-model-schema-16 version . . . . 71 30. Diff with draft-ietf-clue-data-model-schema-15 version . . . . 71 31. Diff with draft-ietf-clue-data-model-schema-14 version . . . . 71 32. Diff with draft-ietf-clue-data-model-schema-13 version . . . . 71 33. Diff with draft-ietf-clue-data-model-schema-12 version . . . . 71 34. Diff with draft-ietf-clue-data-model-schema-11 version . . . . 71 35. Diff with draft-ietf-clue-data-model-schema-10 version . . . . 71 36. Diff with draft-ietf-clue-data-model-schema-09 version . . . . 72 Presta & Romano Expires February 14, 2017 [Page 3] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 37. Diff with draft-ietf-clue-data-model-schema-08 version . . . . 72 38. Diff with draft-ietf-clue-data-model-schema-07 version . . . . 72 39. Diff with draft-ietf-clue-data-model-schema-06 version . . . . 72 40. Diff with draft-ietf-clue-data-model-schema-04 version . . . . 73 41. Diff with draft-ietf-clue-data-model-schema-03 version . . . . 74 42. Diff with draft-ietf-clue-data-model-schema-02 version . . . . 74 43. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74 44. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 44.1. Normative References . . . . . . . . . . . . . . . . . . 74 44.2. Informative References . . . . . . . . . . . . . . . . . 76 Presta & Romano Expires February 14, 2017 [Page 4] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 1. Introduction This document provides an XML schema file for the definition of CLUE data model types. For the benefit of the reader, the term 'CLUE' stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. A thorough definition of the CLUE framework can be found in [I-D.ietf-clue-framework]. The schema is based on information contained in [I-D.ietf-clue-framework]. It encodes information and constraints defined in the aforementioned document in order to provide a formal representation of the concepts therein presented. The document aims at the definition of a coherent structure for information associated with the description of a telepresence scenario. Such information is used within the CLUE protocol messages ([I-D.ietf-clue-protocol]) enabling the dialogue between a Media Provider and a Media Consumer. CLUE protocol messages, indeed, are XML messages allowing (i) a Media Provider to advertise its telepresence capabilities in terms of media captures, capture scenes, and other features envisioned in the CLUE framework, according to the format herein defined and (ii) a Media Consumer to request the desired telepresence options in the form of capture encodings, represented as described in this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definitions This document refers to the same definitions used in [I-D.ietf-clue-framework], except for the "CLUE Participant" definition. We briefly recall herein some of the main terms used in the document. Audio Capture: Media Capture for audio. Denoted as ACn in the examples in this document. Capture: Same as Media Capture. Capture Device: A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder. Presta & Romano Expires February 14, 2017 [Page 5] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Capture Encoding: A specific encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP. Capture Scene: A structure representing a spatial region captured by one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a Capture Scene MAY correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures. Capture Scene View: A list of Media Captures of the same media type that together form one way to represent the entire Capture Scene. CLUE Participant: This term is imported from the CLUE protocol ([I-D.ietf-clue-protocol]) document. Consumer: Short for Media Consumer. Encoding or Individual Encoding: A set of parameters representing a way to encode a Media Capture to become a Capture Encoding. Encoding Group: A set of encoding parameters representing a total media encoding capability to be sub-divided across potentially multiple Individual Encodings. Endpoint A CLUE-capable device which is the logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices which source and sink media streams, and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video or timed text. Media Capture: A source of Media, such as from one or more Capture Devices or constructed from other Media streams. Media Consumer: A CLUE-capable device that intends to receive Capture Encodings. Media Provider: A CLUE-capable device that intends to send Capture Encodings. Presta & Romano Expires February 14, 2017 [Page 6] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Multiple Content Capture: A Capture that mixes and/or switches other Captures of a single type (e.g., all audio or all video.) Particular Media Captures may or may not be present in the resultant Capture Encoding depending on time or space. Denoted as MCCn in the example cases in this document. Multipoint Control Unit (MCU): A CLUE-capable device that connects two or more endpoints together into one single multimedia conference [RFC7667]. An MCU includes an [RFC4353] like Mixer, without the [RFC4353] requirement to send media to each participant. Plane of Interest: The spatial plane containing the most relevant subject matter. Provider: Same as Media Provider. Render: The process of reproducing the received Streams like, for instance, displaying of the remote video on the Media Consumer's screens, or playing of the remote audio through loudspeakers. Scene: Same as Capture Scene. Simultaneous Transmission Set: A set of Media Captures that can be transmitted simultaneously from a Media Provider. Single Media Capture: A capture which contains media from a single source capture device, e.g., an audio capture from a single microphone, a video capture from a single camera. Spatial Relation: The arrangement in space of two objects, in contrast to relation in time or other relationships. Stream: A Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550]. Stream Characteristics: The union of the features used to describe a Stream in the CLUE environment and in the SIP-SDP environment. Video Capture: A Media Capture for video. 4. XML Schema This section contains the CLUE data model schema definition. The element and attribute definitions are formal representations of the concepts needed to describe the capabilities of a Media Provider and the streams that are requested by a Media Consumer given the Presta & Romano Expires February 14, 2017 [Page 7] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Media Provider's ADVERTISEMENT ([I-D.ietf-clue-protocol]). The main groups of information are: : the list of media captures available (Section 5) : the list of encoding groups (Section 6) : the list of capture scenes (Section 7) : the list of simultaneous transmission sets (Section 8) : the list of global views sets (Section 9) : meta data about the participants represented in the telepresence session (Section 21) : the list of instantiated capture encodings (Section 10) All of the above refers to concepts that have been introduced in [I-D.ietf-clue-framework] and further detailed in this document. Presta & Romano Expires February 14, 2017 [Page 8] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 9] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 10] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <personType> registry", accessible at TBD-IANA. Presta & Romano Expires February 14, 2017 [Page 11] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <view> registry", accessible at TBD-IANA. Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <presentation> registry", accessible at TBD-IANA. Presta & Romano Expires February 14, 2017 [Page 12] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 13] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <sensitivityPattern> registry", accessible at TBD-IANA. Presta & Romano Expires February 14, 2017 [Page 14] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 15] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 16] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 17] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Following sections describe the XML schema in more detail. As a general remark, please notice that optional elements that don't define what their absence means are intended to be associated with undefined properties. Presta & Romano Expires February 14, 2017 [Page 18] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 5. represents the list of one or more media captures available at the Media Provider's side. Each media capture is represented by a element (Section 11). 6. represents the list of the encoding groups organized on the Media Provider's side. Each encoding group is represented by an element (Section 18). 7. represents the list of the capture scenes organized on the Media Provider's side. Each capture scene is represented by a element. (Section 16). 8. contains the simultaneous sets indicated by the Media Provider. Each simultaneous set is represented by a element. (Section 19). 9. contains a set of alternative representations of all the scenes that are offered by a Media Provider to a Media Consumer. Each alternative is named "global view" and it is represented by a element. (Section 20). 10. is a list of capture encodings. It can represent the list of the desired capture encodings indicated by the Media Consumer or the list of instantiated captures on the provider's side. Each capture encoding is represented by a element. (Section 22). 11. A Media Capture is the fundamental representation of a media flow that is available on the provider's side. Media captures are characterized (i) by a set of features that are independent from the specific type of medium, and (ii) by a set of features that are media-specific. The features that are common to all media types appear within the media capture type, that has been designed as an abstract complex type. Media-specific captures, such as video Presta & Romano Expires February 14, 2017 [Page 19] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 captures, audio captures and others, are specializations of that abstract media capture type, as in a typical generalization- specialization hierarchy. The following is the XML Schema definition of the media capture type: Presta & Romano Expires February 14, 2017 [Page 20] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 21] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.1. captureID attribute The "captureID" attribute is a mandatory field containing the identifier of the media capture. Such an identifier serves as the way the capture is referenced from other data model elements (e.g., simultaneous sets, capture encodings, and others via ). 11.2. mediaType attribute The "mediaType" attribute is a mandatory attribute specifying the media type of the capture. Common standard values are "audio", "video", "text", as defined in [RFC6838]. Other values can be provided. It is assumed that implementations agree on the interpretation of those other values. The "mediaType" attribute is as generic as possible. Here is why: (i) the basic media capture type is an abstract one; (ii) "concrete" definitions for the standard ([RFC6838]) audio, video and text capture types have been specified; (iii) a generic "otherCaptureType" type has been defined; (iv) the "mediaType" attribute has been generically defined as a string, with no particular template. From the considerations above, it is clear that if one chooses to rely on a brand new media type and wants to interoperate with others, an application-level agreement is needed on how to interpret such information. 11.3. is a mandatory field containing the value of the identifier of the capture scene the media capture is defined in, i.e., the value of the sceneID (Section 16.3) attribute of that capture scene. Indeed, each media capture MUST be defined within one and only one capture scene. When a media capture is spatially definable, some spatial information is provided along with it in the form of point coordinates (see Section 11.5). Such coordinates refer to the space of coordinates defined for the capture scene containing the capture. 11.4. is an optional field containing the identifier of the encoding group the media capture is associated with, i.e., the value of the encodingGroupID (Section 18.3) attribute of that encoding group. Media captures that are not associated with any encoding group can not be instantiated as media streams. Presta & Romano Expires February 14, 2017 [Page 22] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.5. Media captures are divided into two categories: (i) non spatially definable captures and (ii) spatially definable captures. Captures are spatially definable when at least (i) it is possible to provide the coordinates of the device position within the telepresence room of origin (capture point) together with its capturing direction specified by a second point (point on line of capture), or (ii) it is possible to provide the represented area within the telepresence room, by listing the coordinates of the four co-planar points identifying the plane of interest (area of capture). The coordinates of the above mentioned points MUST be expressed according to the coordinate space of the capture scene the media captures belongs to. Non spatially definable captures cannot be characterized within the physical space of the telepresence room of origin. Captures of this kind are for example those related to recordings, text captures, DVDs, registered presentations, or external streams that are played in the telepresence room and transmitted to remote sites. Spatially definable captures represent a part of the telepresence room. The captured part of the telepresence room is described by means of the element. By comparing the element of different media captures within the same capture scene, a consumer can better determine the spatial relationships between them and render them correctly. Non spatially definable captures do not embed such element in their XML description: they are instead characterized by having the tag set to "true" (see Section 11.6). The definition of the spatial information type is the following: Presta & Romano Expires February 14, 2017 [Page 23] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 The contains the coordinates of the capture device that is taking the capture (i.e., the capture point), as well as, optionally, the pointing direction (i.e., the point on line of capture) (see Section 11.5.1). The is an optional field containing four points defining the captured area covered by the capture (see Section 11.5.2). The scale of the points coordinates is specified in the scale (Section 16.4) attribute of the capture scene the media capture belongs to. Indeed, all the spatially definable media captures referring to the same capture scene share the same coordinate system and express their spatial information according to the same scale. 11.5.1. The element is used to represent the position and optionally the line of capture of a capture device. MUST be included in spatially definable audio captures, while it is optional for spatially definable video captures. The XML Schema definition of the element type is the following: Presta & Romano Expires February 14, 2017 [Page 24] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 The point type contains three spatial coordinates (x,y,z) representing a point in the space associated with a certain capture scene. The element includes a mandatory element and an optional element, both of the type "pointType". specifies the three coordinates identifying the position of the capture device. is another pointType element representing the "point on line of capture", that gives the pointing direction of the capture device. The coordinates of the point on line of capture MUST NOT be identical to the capture point coordinates. For a spatially definable video capture, if the point on line of capture is provided, it MUST belong to the region between the point of capture and the capture area. For a spatially definable audio capture, if the point on line of capture is not provided, the sensitivity pattern should be considered omnidirectional. 11.5.2. is an optional element that can be contained within the spatial information associated with a media capture. It represents the spatial area captured by the media capture. MUST be included in the spatial information of spatially definable video captures, while it MUST NOT be associated with audio captures. The XML representation of that area is provided through a set of four point-type elements, , , , and that MUST be co-planar. The four coplanar points are identified from the perspective of the capture device. The XML schema definition is the following: Presta & Romano Expires February 14, 2017 [Page 25] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.6. When media captures are non spatially definable, they MUST be marked with the boolean element set to "true" and no MUST be provided. Indeed, and are mutually exclusive tags, according to the section within the XML Schema definition of the media capture type. 11.7. A media capture can be (i) an individual media capture or (ii) a multiple content capture (MCC). A multiple content capture is made by different captures that can be arranged spatially (by a composition operation), or temporally (by a switching operation), or that can result from the orchestration of both the techniques. If a media capture is an MCC, then it MAY show in its XML data model representation the element. It is composed by a list of media capture identifiers ("mediaCaptureIDREF") and capture scene view identifiers ("sceneViewIDREF"), where the latter ones are used as shortcuts to refer to multiple capture identifiers. The referenced captures are used to create the MCC according to a certain strategy. If the element does not appear in a MCC, or it has no child elements, then the MCC is assumed to be made of multiple sources but no information regarding those sources is provided. 11.8. is an optional element for multiple content captures that contains a numeric identifier. Multiple content captures marked with the same identifier in the Presta & Romano Expires February 14, 2017 [Page 26] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 contain at all times captures coming from the same sources. It is the Media Provider that determines what the source for the captures is. In this way, the Media Provider can choose how to group together single captures for the purpose of keeping them synchronized according to the element. 11.9. is an optional boolean element for multiple content captures. It indicates whether or not the Provider allows the Consumer to choose a specific subset of the captures referenced by the MCC. If this attribute is true, and the MCC references other captures, then the Consumer MAY specify in a CONFIGURE message a specific subset of those captures to be included in the MCC, and the Provider MUST then include only that subset. If this attribute is false, or the MCC does not reference other captures, then the Consumer MUST NOT select a subset. If is not shown in the XML description of the MCC, its value is to be considered "false". 11.10. is an optional element that can be used only for multiple content captures. It indicates the criteria applied to build the multiple content capture using the media captures referenced in the list. The value is in the form of a token that indicates the policy and an index representing an instance of the policy, separated by a ":" (e.g., SoundLevel:2, RoundRobin:0, etc.). The XML schema defining the type of the element is the following: At the time of writing, only two switching policies are defined in [I-D.ietf-clue-framework]: SoundLevel: the content of the MCC is determined by a sound level detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC. Index 0 represents the most current instance of the policy, i.e., the currently active speaker, 1 represents the previous instance, Presta & Romano Expires February 14, 2017 [Page 27] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 i.e., the previous active speaker, and so on. RoundRobin: the content of the MCC is determined by a time based algorithm. Other values for the element can be used. In this case, it is assumed that implementations agree on the meaning of those other values and/or those new switching policies are defined in later documents. 11.11. is an optional element that can be used only for multiple content captures (MCC). It provides information about the number of media captures that can be represented in the multiple content capture at a time. If is not provided, all the media captures listed in the element can appear at a time in the capture encoding. The type definition is provided below. When the "exactNumber" attribute is set to "true", it means the element carries the exact number of the media captures appearing at a time. Otherwise, the number of the represented media captures MUST be considered "<=" the value. For instance, an audio MCC having the value set to 1 means that a media stream from the MCC will only contain audio from a single one of its constituent captures at a time. On the other hand, if the value is set to 4 and the exactNumber attribute Presta & Romano Expires February 14, 2017 [Page 28] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 is set to "true", it would mean that the media stream received from the MCC will always contain a mix of audio from exactly four of its constituent captures. 11.12. is a boolean element that MUST be used for single- content captures. Its value is fixed and set to "true". Such element indicates the capture that is being described is not a multiple content capture. Indeed, and the aforementioned tags related to MCC attributes (from Section 11.7 to Section 11.11) are mutually exclusive, according to the section within the XML Schema definition of the media capture type. 11.13. is used to provide human-readable textual information. This element is included in the XML definition of media captures, capture scenes and capture scene views to the aim of providing human- readable description of, respectively, media captures, capture scenes and capture scene views. According to the data model definition of a media capture (Section 11)), zero or more elements can be used, each providing information in a different language. The element definition is the following: As can be seen, is a string element with an attribute ("lang") indicating the language used in the textual description. Such an attribute is compliant with the Language-Tag ABNF production from [RFC5646]. 11.14. is an optional unsigned integer field indicating the importance of a media capture according to the Media Provider's Presta & Romano Expires February 14, 2017 [Page 29] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 perspective. It can be used on the receiver's side to automatically identify the most relevant contribution from the Media Provider. The higher the importance, the lower the contained value. If no priority is assigned, no assumptions regarding relative importance of the media capture can be assumed. 11.15. is an optional element containing the language used in the capture. Zero or more elements can appear in the XML description of a media capture. Each such element has to be compliant with the Language-Tag ABNF production from [RFC5646]. 11.16. is an optional element indicating whether or not the capture device originating the capture may move during the telepresence session. That optional element can assume one of the three following values: static SHOULD NOT change for the duration of the CLUE session, across multiple ADVERTISEMENT messages. dynamic MAY change in each new ADVERTISEMENT message. Can be assumed to remain unchanged until there is a new ADVERTISEMENT message. highly-dynamic MAY change dynamically, even between consecutive ADVERTISEMENT messages. The spatial information provided in an ADVERTISEMENT message is simply a snapshot of the current values at the time when the message is sent. 11.17. The optional element contains the value of the captureID attribute (Section 11.1) of the media capture to which the considered media capture refers. The media capture marked with a element can be for example the translation of the referred media capture in a different language. 11.18. The element is an optional tag describing what is represented in the spatial area covered by a media capture. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Presta & Romano Expires February 14, 2017 [Page 30] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are: "room", "table", "lectern", "individual", and "audience". 11.19. The element is an optional tag used for media captures conveying information about presentations within the telepresence session. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are "slides" and "images". 11.20. The element is a boolean element indicating that there is text embedded in the media capture (e.g., in a video capture). The language used in such embedded textual description is reported in "lang" attribute. The XML Schema definition of the element is: Presta & Romano Expires February 14, 2017 [Page 31] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.21. This optional element is used to indicate which telepresence session participants are represented within the media captures. For each participant, a element is provided. 11.21.1. contains the identifier of the represented person, i.e., the value of the related personID attribute (Section 21.1.1). Metadata about the represented participant can be retrieved by accessing the list (Section 21). 12. Audio captures Audio captures inherit all the features of a generic media capture and present further audio-specific characteristics. The XML Schema definition of the audio capture type is reported below: Presta & Romano Expires February 14, 2017 [Page 32] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 An example of audio-specific information that can be included is represented by the element. (Section 12.1). 12.1. The element is an optional field describing the characteristics of the nominal sensitivity pattern of the microphone capturing the audio signal. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are "uni", "shotgun", "omni", "figure8", "cardioid" and "hyper-cardioid". 13. Video captures Video captures, similarly to audio captures, extend the information of a generic media capture with video-specific features. The XML Schema representation of the video capture type is provided in the following: Presta & Romano Expires February 14, 2017 [Page 33] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 14. Text captures Also text captures can be described by extending the generic media capture information, similarly to audio captures and video captures. There are no known properties of a text-based media which aren't already covered by the generic mediaCaptureType. Text captures are hence defined as follows: Text captures MUST be marked as non spatially definable (i.e., they MUST present in their XML description the (Section 11.6) element set to "true"). 15. Other capture types Other media capture types can be described by using the CLUE data model. They can be represented by exploiting the "otherCaptureType" type. This media capture type is conceived to be filled in with elements defined within extensions of the current schema, i.e., with elements defined in other XML schemas (see Section 24 for an example). The otherCaptureType inherits all the features envisioned for the abstract mediaCaptureType. The XML Schema representation of the otherCaptureType is the following: Presta & Romano Expires February 14, 2017 [Page 34] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 When defining new media capture types that are going to be described by means of the element, spatial properties of such new media capture types SHOULD be defined (e.g., whether or not they are spatially definable, whether or not they should be associated with an area of capture, or other properties that may be defined). 16. A Media Provider organizes the available captures in capture scenes in order to help the receiver both in the rendering and in the selection of the group of captures. Capture scenes are made of media captures and capture scene views, that are sets of media captures of the same media type. Each capture scene view is an alternative to represent completely a capture scene for a fixed media type. The XML Schema representation of a element is the following: Presta & Romano Expires February 14, 2017 [Page 35] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Each capture scene is identified by a "sceneID" attribute. The element can contain zero or more textual elements, defined as in Section 11.13. Besides , there is the optional element (Section 16.1), which contains structured information about the scene in the vcard format, and the optional element (Section 16.2), which is the list of the capture scene views. When no is provided, the capture scene is assumed to be made of all the media captures which contain the value of its sceneID attribute in their mandatory captureSceneIDREF attribute. 16.1. The element contains optional information about the capture scene according to the vcard format, as specified in the Xcard RFC [RFC6351]. 16.2. The element is a mandatory field of a capture scene containing the list of scene views. Each scene view is represented by a element (Section 17). 16.3. sceneID attribute The sceneID attribute is a mandatory attribute containing the identifier of the capture scene. 16.4. scale attribute The scale attribute is a mandatory attribute that specifies the scale of the coordinates provided in the spatial information of the media Presta & Romano Expires February 14, 2017 [Page 36] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 capture belonging to the considered capture scene. The scale attribute can assume three different values: "mm" - the scale is in millimeters. Systems which know their physical dimensions (for example professionally installed telepresence room systems) should always provide such real-world measurements. "unknown" - the scale is the same for every media capture in the capture scene but the unity of measure is undefined. Systems which are not aware of specific physical dimensions yet still know relative distances should select "unknown" in the scale attribute of the capture scene to be described. "noscale" - there is no common physical scale among the media captures of the capture scene. That means the scale could be different for each media capture. 17. A element represents a capture scene view, which contains a set of media captures of the same media type describing a capture scene. A element is characterized as follows. Presta & Romano Expires February 14, 2017 [Page 37] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 One or more optional elements provide human-readable information about what the scene view contains. is defined as already seen in Section 11.13. The remaining child elements are described in the following subsections. 17.1. The is the list of the identifiers of the media captures included in the scene view. It is an element of the captureIDListType type, which is defined as a sequence of , each containing the identifier of a media capture listed within the element: 17.2. sceneViewID attribute The sceneViewID attribute is a mandatory attribute containing the identifier of the capture scene view represented by the element. 18. The element represents an encoding group, which is made by a set of one or more individual encodings and some parameters that apply to the group as a whole. Encoding groups contain references to individual encodings that can be applied to media captures. The definition of the element is the following: Presta & Romano Expires February 14, 2017 [Page 38] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 In the following, the contained elements are further described. 18.1. is an optional field containing the maximum bitrate expressed in bits per second that can be shared by the individual encodings included in the encoding group. 18.2. is the list of the individual encodings grouped together in the encoding group. Each individual encoding is represented through its identifier contained within an element. 18.3. encodingGroupID attribute The encodingGroupID attribute contains the identifier of the encoding group. 19. represents a simultaneous transmission set, i.e., a list of captures of the same media type that can be transmitted at the same time by a Media Provider. There are different simultaneous Presta & Romano Expires February 14, 2017 [Page 39] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 transmission sets for each media type. Besides the identifiers of the captures ( elements), also the identifiers of capture scene views and of capture scene can be exploited as shortcuts ( and elements). As an example, let's consider the situation where there are two capture scene views (S1 and S7). S1 contains captures AC11, AC12, AC13. S7 contains captures AC71, AC72. Provided that AC11, AC12, AC13, AC71, AC72 can be simultaneously sent to the media consumer, instead of having 5 elements listed in the simultaneous set (i.e., one for AC11, one for AC12, and so on), there can be just two elements (one for S1 and one for S7). 19.1. setID attribute The "setID" attribute is a mandatory field containing the identifier of the simultaneous set. 19.2. mediaType attribute The "mediaType" attribute is an optional attribute containing the media type of the captures referenced by the simultaneous set. When only capture scene identifiers are listed within a simultaneous set, the media type attribute MUST appear in the XML description in order to determine which media captures can be simultaneously sent together. Presta & Romano Expires February 14, 2017 [Page 40] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 19.3. contains the identifier of the media capture that belongs to the simultaneous set. 19.4. contains the identifier of the scene view containing a group of captures that are able to be sent simultaneously with the other captures of the simultaneous set. 19.5. contains the identifier of the capture scene where all the included captures of a certain media type are able to be sent together with the other captures of the simultaneous set. 20. is a set of captures of the same media type representing a summary of the complete Media Provider's offer. The content of a global view is expressed by leveraging only scene view identifiers, put within elements. Each global view is identified by a unique identifier within the "globalViewID" attribute. 21. Information about the participants that are represented in the media captures is conveyed via the element. As it can be seen from the XML Schema depicted below, for each participant, a element is provided. Presta & Romano Expires February 14, 2017 [Page 41] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 21.1. includes all the metadata related to a person represented within one or more media captures. Such element provides the vcard of the subject (via the element, see Section 21.1.2) and his conference role(s) (via one or more elements, see Section 21.1.3). Furthermore, it has a mandatory "personID" attribute (Section 21.1.1). 21.1.1. personID attribute The "personID" attribute carries the identifier of a represented person. Such an identifier can be used to refer to the participant, as in the element in the media captures representation (Section 11.21). 21.1.2. The element is the XML representation of all the fields composing a vcard as specified in the Xcard RFC [RFC6351]. The vcardType is imported by the Xcard XML Schema provided in Appendix A of [I-D.ietf-ecrit-additional-data]. As such schema specifies, the element within is mandatory. Presta & Romano Expires February 14, 2017 [Page 42] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 21.1.3. The value of the element determines the role of the represented participant within the telepresence session organization. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are: "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice- chairman", "observer". A participant can play more than one conference role. In that case, more than one element will appear in his description. 22. A capture encoding is given from the association of a media capture with an individual encoding, to form a capture stream as defined in [I-D.ietf-clue-framework]. Capture encodings are used within CONFIGURE messages from a Media Consumer to a Media Provider for representing the streams desired by the Media Consumer. For each desired stream, the Media Consumer needs to be allowed to specify: (i) the capture identifier of the desired capture that has been advertised by the Media Provider; (ii) the encoding identifier of the encoding to use, among those advertised by the Media Provider; (iii) optionally, in case of multi-content captures, the list of the capture identifiers of the desired captures. All the mentioned identifiers are intended to be included in the ADVERTISEMENT message that the CONFIGURE message refers to. The XML model of is provided in the following. Presta & Romano Expires February 14, 2017 [Page 43] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 22.1. is the mandatory element containing the identifier of the media capture that has been encoded to form the capture encoding. 22.2. is the mandatory element containing the identifier of the applied individual encoding. 22.3. is an optional element to be used in case of configuration of MCC. It contains the list of capture identifiers and capture scene view identifiers the Media Consumer wants within the MCC. That element is structured as the element used to describe the content of an MCC. The total number of media captures listed in the MUST be lower than or equal to the value carried within the attribute of the MCC. 23. The element includes all the information needed to represent the Media Provider's description of its telepresence capabilities according to the CLUE framework. Indeed, it is made by: the list of the available media captures ( (Section 5)) the list of encoding groups ( (Section 6)) Presta & Romano Expires February 14, 2017 [Page 44] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 the list of capture scenes ( (Section 7)) the list of simultaneous transmission sets ( (Section 8)) the list of global views sets ( (Section 9)) meta data about the participants represented in the telepresence session ( (Section 21)) It has been conceived only for data model testing purposes and, though it resembles the body of an ADVERTISEMENT message, it is not actually used in the CLUE protocol message definitions. The telepresence capabilities descriptions compliant to this data model specification that can be found in Section 27 and Section 28 are provided by using the element. 24. XML Schema extensibility The telepresence data model defined in this document is meant to be extensible. Extensions are accomplished by defining elements or attributes qualified by namespaces other than "urn:ietf:params:xml:ns:clue-info" and "urn:ietf:params:xml:ns:vcard-4.0" for use wherever the schema allows such extensions (i.e., where the XML Schema definition specifies "anyAttribute" or "anyElement"). Elements or attributes from unknown namespaces MUST be ignored. Extensibility was purposefully favored as much as possible based on expectations about custom Presta & Romano Expires February 14, 2017 [Page 45] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 implementations. Hence, the schema offers people enough flexibility as to define custom extensions, without losing compliance with the standard. This is achieved by leveraging elements and attributes, which is a common approach with schemas, still matching the UPA (Unique Particle Attribution) constraint. 24.1. Example of extension When extending the CLUE data model, a new schema with a new namespace associated with it needs to be specified. In the following, an example of extension is provided. The extension defines a new audio capture attribute ("newAudioFeature") and an attribute for characterizing the captures belonging to an "otherCaptureType" defined by the user. An XML document compliant with the extension is also included. The XML file results validated against the current CLUE data model schema. Presta & Romano Expires February 14, 2017 [Page 46] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 CS1 true true EG1 newAudioFeatureValue CS1 true EG1 OtherValue 300000 ENC4 ENC5 Presta & Romano Expires February 14, 2017 [Page 47] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 25. Security considerations This document defines an XML Schema data model for telepresence scenarios. The modeled information is identified in the CLUE framework as necessary in order to enable a full-fledged media stream negotiation and rendering. Indeed, the XML elements herein defined are used within CLUE protocol messages to describe both the media streams representing the Media Provider's telepresence offer and the desired selection requested by the Media Consumer. Security concerns described in [I-D.ietf-clue-framework], Section 15, apply to this document. Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints. Indeed, authenticated access is strongly advisable, especially if you convey information about individuals () and/or scenes (). There might be more exceptions, depending on the level of criticality that is associated with the setup and configuration of a specific session. In principle, one might even decide that no protection at all is needed for a particular session; here is why authentication has not been identified as a mandatory requirement. Going deeper into details, some information published by the Media Provider might reveal sensitive data about who and what is represented in the transmitted streams. The vCard included in the elements (Section 21.1) mandatorily contains the identity of the represented person. Optionally vCards can also carry the person's contact addresses, together with his/her photo and other personal data. Similar privacy-critical information can be conveyed by means of elements (Section 16.1) describing the capture scenes. The elements (Section 11.13) also can specify details about the content of media captures, capture scenes and scene views that should be protected. Integrity attacks to the data model information encapsulated in CLUE messages can invalidate the success of the telepresence session's setup by misleading the Media Consumer's and Media Provider's interpretation of the offered and desired media streams. The assurance of the authenticated access and of the integrity of the data model information is up to the involved transport mechanisms, namely the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel]. XML parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the XML Presta & Romano Expires February 14, 2017 [Page 48] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 parser. In an extreme situation, the entire machine could be compromised. 26. IANA considerations This document registers a new XML namespace, a new XML schema, the MIME type for the schema and four new registries associated, respectively, with acceptable , , and values. 26.1. XML namespace registration URI: urn:ietf:params:xml:ns:clue-info Registrant Contact: IETF CLUE Working Group , Roberta Presta XML: BEGIN CLUE Data Model Namespace

Namespace for CLUE Data Model

urn:ietf:params:xml:ns:clue-info

See RFC XXXX.

END Presta & Romano Expires February 14, 2017 [Page 49] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 26.2. XML Schema registration This section registers an XML schema per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:clue-info Registrant Contact: CLUE working group (clue@ietf.org), Roberta Presta (roberta.presta@unina.it). Schema: The XML for this schema can be found as the entirety of Section 4 of this document. 26.3. MIME Media Type Registration for "application/clue_info+xml" This section registers the "application/clue_info+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/clue_info+xml MIME media type name: application MIME subtype name: clue_info+xml Required parameters: (none) Optional parameters: charset Same as the charset parameter of "application/xml" as specified in [RFC7303], Section 3.2. Encoding considerations: Same as the encoding considerations of "application/xml" as specified in [RFC7303], Section 3.2. Security considerations: This content type is designed to carry data related to telepresence information. Some of the data could be considered private. This media type does not provide any protection and thus other mechanisms such as those described in Section 25 are required to protect the data. This media type does not contain executable content. Interoperability considerations: None. Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Applications that use this media type: CLUE-capable telepresence systems. Presta & Romano Expires February 14, 2017 [Page 50] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Additional Information: Magic Number(s): (none), File extension(s): .clue, Macintosh File Type Code(s): TEXT. Person & email address to contact for further information: Roberta Presta (roberta.presta@unina.it). Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC7303], and many of the considerations described there also apply to application/clue_info+xml. 26.4. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 11.18. The initial values for this registry are "room", "table", "lectern", "individual", and "audience". New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 11.18, marked as "TBD-IANA". 26.5. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 11.19. The initial values for this registry are "slides" and "images". New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 11.19, marked as "TBD-IANA". 26.6. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 12.1. The initial values for this registry are "uni", "shotgun", "omni", "figure8", "cardioid" and "hyper-cardioid". Presta & Romano Expires February 14, 2017 [Page 51] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 12.1, marked as "TBD-IANA". 26.7. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 21.1.3. The initial values for this registry are "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman", "observer". New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 21.1.3, marked as "TBD-IANA". 27. Sample XML file The following XML document represents a schema compliant example of a CLUE telepresence scenario. Taking inspiration from the examples described in the framework draft ([I-D.ietf-clue-framework]), it is provided the XML representation of an endpoint-style Media Provider's ADVERTISEMENT. There are three cameras, where the central one is also capable of capturing a zoomed-out view of the overall telepresence room. Besides the three video captures coming from the cameras, the Media Provider makes available a further multi-content capture of the loudest segment of the room, obtained by switching the video source across the three cameras. For the sake of simplicity, only one audio capture is advertised for the audio of the whole room. The three cameras are placed in front of three participants (Alice, Bob and Ciccio), whose vcard and conference role details are also provided. Media captures are arranged into four capture scene views: 1. (VC0, VC1, VC2) - left, center and right camera video captures 2. (VC3) - video capture associated with loudest room segment Presta & Romano Expires February 14, 2017 [Page 52] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 3. (VC4) - video capture zoomed out view of all people in the room 4. (AC0) - main audio There are two encoding groups: (i) EG0, for video encodings, and (ii) EG1, for audio encodings. As to the simultaneous sets, VC1 and VC4 cannot be transmitted simultaneously since they are captured by the same device, i.e., the central camera (VC4 is a zoomed-out view while VC1 is a focused view of the front participant). On the other hand, VC3 and VC4 cannot be simultaneous either, since VC3, the loudest segment of the room, might be at a certain point in time focusing on the central part of the room, i.e., the same as VC1. The simultaneous sets would then be the following: SS1 made by VC3 and all the captures in the first capture scene view (VC0,VC1,VC2); SS2 made by VC0, VC2, VC4 CS1 0.0 0.0 10.0 0.0 1.0 10.0 true Presta & Romano Expires February 14, 2017 [Page 53] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 EG1 main audio from the room 1 it static room alice bob ciccio CS1 -2.0 0.0 10.0 -3.0 20.0 9.0 -1.0 20.0 9.0 -3.0 20.0 11.0 -1.0 20.0 11.0 Presta & Romano Expires February 14, 2017 [Page 54] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true Presta & Romano Expires February 14, 2017 [Page 55] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 Presta & Romano Expires February 14, 2017 [Page 56] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual Presta & Romano Expires February 14, 2017 [Page 57] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed out view of all people in the room 2 it static room alice bob ciccio Presta & Romano Expires February 14, 2017 [Page 58] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 VC0 VC1 VC2 VC3 VC4 AC0 Presta & Romano Expires February 14, 2017 [Page 59] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 VC3 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Ciccio chairman timekeeper 28. MCC example Enhancing the scenario presented in the previous example, the Media Provider is able to advertise a composed capture VC7 made by a big picture representing the current speaker (VC3) and two picture-in- picture boxes representing the previous speakers (the previous one Presta & Romano Expires February 14, 2017 [Page 60] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 -VC5- and the oldest one -VC6). The provider does not want to instantiate and send VC5 and VC6, so it does not associate any encoding group with them. Their XML representations are provided for enabling the description of VC7. A possible description for that scenario could be the following: CS1 0.0 0.0 10.0 0.0 1.0 10.0 true EG1 main audio from the room 1 it static room alice bob ciccio Presta & Romano Expires February 14, 2017 [Page 61] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 CS1 0.5 1.0 0.5 0.5 0.0 0.5 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 Presta & Romano Expires February 14, 2017 [Page 62] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 Presta & Romano Expires February 14, 2017 [Page 63] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 Presta & Romano Expires February 14, 2017 [Page 64] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 Presta & Romano Expires February 14, 2017 [Page 65] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 true EG0 zoomed out view of all people in the room 2 it static room alice bob ciccio CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 Presta & Romano Expires February 14, 2017 [Page 66] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 SoundLevel:1 penultimate loudest room segment it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:2 last but two loudest room segment it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 VC3 VC5 VC6 3 EG0 big picture of the current speaker + pips about previous speakers 3 it static individual 600000 ENC1 ENC2 ENC3 Presta & Romano Expires February 14, 2017 [Page 68] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 300000 ENC4 ENC5 participants' individual videos VC0 VC1 VC2 loudest segment of the room VC3 loudest segment of the room + pips VC7 room audio AC0 room video VC4 Presta & Romano Expires February 14, 2017 [Page 69] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 VC3 VC7 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Ciccio chairman timekeeper Presta & Romano Expires February 14, 2017 [Page 70] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 29. Diff with draft-ietf-clue-data-model-schema-16 version As per Alexey Melnikov's and Stefan Winter's comments: replaced wrong references to RFC2119 in section 11.3 and section 11.5. The updated reference is to RFC5646. 30. Diff with draft-ietf-clue-data-model-schema-15 version Applied modifications as per the following reviews: (i) Alexey Melnikov's discuss and comments (abstract amendments, typo corrections, insertion of references, etc.); (ii) Kathleen Moriarty's discuss and comments (amendments to the Security Considerations section); (iii) Stefan Winter's OPS-DIR review (use of enumerated types in the schema). 31. Diff with draft-ietf-clue-data-model-schema-14 version Applied modifications as per the following reviews: (i) Henry S. Thompson's APPS-DIR review; (ii) Stefan Winter's OPS-DIR review; (iii) Francis Dupont's GEN-ART review; (iv) Rich Salz's review (as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.) 32. Diff with draft-ietf-clue-data-model-schema-13 version Applied modifications as per the latest Area Director (Alissa Cooper's) review comments. 33. Diff with draft-ietf-clue-data-model-schema-12 version Removed some typos and inconsistencies. Applied modifications as per Alissa Cooper's review comments. 34. Diff with draft-ietf-clue-data-model-schema-11 version Applied modifications as per Mark Duckworth's review (example corrections and maxCapturesType modification) maxCapturesType has been changed from positiveInteger to unsignedShort excluding value 0. 35. Diff with draft-ietf-clue-data-model-schema-10 version Minor modifications have been applied to address nits at page https:/ /www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/ draft-ietf-clue-data-model-schema-10.txt. Presta & Romano Expires February 14, 2017 [Page 71] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 36. Diff with draft-ietf-clue-data-model-schema-09 version o We have introduced a element containing a mandatory and an optional in the definition of as per Paul's review o A new type definition for switching policies (resembled by element) has been provided in order to have acceptable values in the form of "token:index". o Minor modifications suggested in WGLC reviews have been applied. 37. Diff with draft-ietf-clue-data-model-schema-08 version o Typos correction 38. Diff with draft-ietf-clue-data-model-schema-07 version o IANA Considerations: text added o maxCaptureEncodings removed o personTypeType values aligned with CLUE framework o allowSubsetChoice added for multiple content captures o embeddedText moved from videoCaptureType definition to mediaCaptureType definition o typos removed from section Terminology 39. Diff with draft-ietf-clue-data-model-schema-06 version o Capture Scene Entry/Entries renamed as Capture Scene View/Views in the text, / renamed as / in the XML schema. o Global Scene Entry/Entries renamed as Global View/Views in the text, / renamed as / o Security section added. o Extensibility: a new type is introduced to describe other types of media capture (otherCaptureType), text and example added. o Spatial information section updated: capture point optional, text now is coherent with the framework one. Presta & Romano Expires February 14, 2017 [Page 72] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 o Audio capture description: added, removed, disallowed. o Simultaneous set definition: added to refer to capture scene identifiers as shortcuts and an optional mediaType attribute which is mandatory to use when only capture scene identifiers are listed. o Encoding groups: removed the constraint of the same media type. o Updated text about media captures without (optional in the XML schema). o "mediaType" attribute removed from homogeneous groups of capture (scene views and globlal views) o "mediaType" attribute removed from the global view textual description. o "millimeters" scale value changed in "mm" 40. Diff with draft-ietf-clue-data-model-schema-04 version globalCaptureEntries/Entry renamed as globalSceneEntries/Entry; sceneInformation added; Only capture scene entry identifiers listed within global scene entries (media capture identifiers removed); renamed as in the >clueInfo< template renamed as to synch with the framework terminology renamed as to synch with the framework terminology renamed as in the media capture type definition to remove ambiguity Examples have been updated with the new definitions of and of . Presta & Romano Expires February 14, 2017 [Page 73] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 41. Diff with draft-ietf-clue-data-model-schema-03 version encodings section has been removed global capture entries have been introduced capture scene entry identifiers are used as shortcuts in listing the content of MCC (similarly to simultaneous set and global capture entries) Examples have been updated. A new example with global capture entries has been added. has been made optional. has been renamed into Obsolete comments have been removed. participants information has been added. 42. Diff with draft-ietf-clue-data-model-schema-02 version captureParameters and encodingParameters have been removed from the captureEncodingType data model example has been updated and validated according to the new schema. Further description of the represented scenario has been provided. A multiple content capture example has been added. Obsolete comments and references have been removed. 43. Acknowledgments The authors thank all the CLUErs for their precious feedbacks and support. Thanks also to Alissa Cooper, whose AD reviews helped us improve the quality of the document. 44. References 44.1. Normative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf-clue-datachannel-14 (work in progress), August 2016. Presta & Romano Expires February 14, 2017 [Page 74] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-25 (work in progress), January 2016. [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft-ietf-clue-protocol-08 (work in progress), May 2016. [I-D.ietf-ecrit-additional-data] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", draft-ietf-ecrit-additional-data-38 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, < http://www.rfc-editor.org/info/ rfc2119>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/ RFC5226, May 2008, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, . [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, . 44.2. Informative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/ RFC6838, January 2013, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Presta & Romano Expires February 14, 2017 [Page 76] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Authors' Addresses Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: roberta.presta@unina.it Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it Presta & Romano Expires February 14, 2017 [Page 77] ./draft-ietf-mmusic-msid-15.txt0000664000764400076440000010607112737413570015625 0ustar iustyiusty Network Working Group H. Alvestrand Internet-Draft Google Intended status: Standards Track July 7, 2016 Expires: January 8, 2017 WebRTC MediaStream Identification in the Session Description Protocol draft-ietf-mmusic-msid-15 Abstract This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Alvestrand Expires January 8, 2017 [Page 1] Internet-Draft MSID in SDP July 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Structure Of This Document . . . . . . . . . . . . . . . 3 1.3. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 4 1.4. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Handling of non-signalled tracks . . . . . . . . . . . . 7 3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 8 3.2.1. Generating the initial offer . . . . . . . . . . . . 8 3.2.2. Answerer processing of the Offer . . . . . . . . . . 9 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 9 3.2.4. Offerer processing of the answer . . . . . . . . . . 9 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 9 3.3. Example SDP description . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.1. Attribute registration in existing registries . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Design considerations, rejected alternatives . . . . 13 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 13 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 14 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 14 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 14 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 14 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 15 Alvestrand Expires January 8, 2017 [Page 2] Internet-Draft MSID in SDP July 2016 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 15 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 15 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 15 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 16 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 16 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 17 B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 17 B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 17 B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 17 B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 17 B.21. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction 1.1. Terminology This document uses terminology from [I-D.ietf-rtcweb-overview]. In addition, the following terms are used as described below: RTP stream Defined in [RFC7656] as a stream of RTP packets containing media data. MediaStream Defined in [W3C.CR-mediacapture-streams-20160519]as an assembly of MediaStreamTracks. One MediaStream can contain multiple MediaStreamTracks, of the same or different types. MediaStreamTrack Defined in [W3C.CR-mediacapture-streams-20160519]as an unidirectional flow of media data (either audio or video, but not both). Corresponds to the [RFC7656] term "Source Stream". One MediaStreamTrack can be present in zero, one or multiple MediaStreams. Media description Defined in [RFC4566] as a set of fields starting with an "m=" field and terminated by eitehr the next "m=" field or by the end of the session description. 1.2. Structure Of This Document This document adds a new Session Description Protocol (SDP) [RFC4566] mechanism that can attach identifiers to the RTP streams and attaching identifiers to the groupings they form. It is designed for use with WebRTC[I-D.ietf-rtcweb-overview] . Section 1.3 gives the background on why a new mechanism is needed. Alvestrand Expires January 8, 2017 [Page 3] Internet-Draft MSID in SDP July 2016 Section 2 gives the definition of the new mechanism. Section 3 gives the necessary semantic information and procedures for using the msid attribute to signal the association of MediaStreamTracks to MediaStreams in support of the WebRTC API [W3C.WD-webrtc-20160531]. 1.3. Why A New Mechanism Is Needed When media is carried by RTP [RFC3550], each RTP stream is distinguished inside an RTP session by its SSRC; each RTP session is distinguished from all other RTP sessions by being on a different transport association (strictly speaking, 2 transport associations, one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing [RFC5761] is used). SDP [RFC4566] gives a format for describing an SDP session that can contain multiple media descriptions. According to the model used in [I-D.ietf-rtcweb-jsep], each media description describes exactly one media source, and if multiple media sources are carried in an RTP session, this is signalled using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each media source is carried in its own RTP session. The SDP grouping framework [RFC5888] can be used to group media descriptions. However, for the use case of WebRTC, there is the need for an application to specify some application-level information about the association between the media description and the group. This is not possible using the SDP grouping framework. 1.4. The WEBRTC MediaStream The W3C WebRTC API specification [W3C.WD-webrtc-20160531] specifies that communication between WebRTC entities is done via MediaStreams, which contain MediaStreamTracks. A MediaStreamTrack is generally carried using a single SSRC in an RTP session (forming an RTP stream. The collision of terminology is unfortunate.) There might possibly be additional SSRCs, possibly within additional RTP sessions, in order to support functionality like forward error correction or simulcast. These additional SSRCs are not affected by this specification. MediaStreamTracks are unidirectional; they carry media on one direction only. In the RTP specification, RTP streams are identified using the SSRC field. Streams are grouped into RTP Sessions, and also carry a CNAME. Neither CNAME nor RTP session correspond to a MediaStream. Alvestrand Expires January 8, 2017 [Page 4] Internet-Draft MSID in SDP July 2016 Therefore, the association of an RTP stream to MediaStreams need to be explicitly signaled. WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where one SDP media description is used to describe each MediaStreamTrack, and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group MediaStreamTracks into RTP sessions. Therefore, the need is to specify the ID of a MediaStreamTrack and its associated MediaStream for each media description, which can be accomplished with a media-level SDP attribute. This usage is described in Section 3. 2. The Msid Mechanism This document defines a new SDP [RFC4566] media-level "msid" attribute. This new attribute allows endpoints to associate RTP streams that are described in different media descriptions with the same MediaStreams as defined in [W3C.WD-webrtc-20160531], and to carry an identifier for each MediaStreamTrack in its "appdata" field. The value of the "msid" attribute consists of an identifier and an optional "appdata" field. The name of the attribute is "msid". The value of the attribute is specified by the following ABNF [RFC5234] grammar: msid-value = msid-id [ SP msid-appdata ] msid-id = 1*64token-char ; see RFC 4566 msid-appdata = 1*64token-char ; see RFC 4566 An example msid value for a group with the identifier "examplefoo" and application data "examplebar" might look like this: msid:examplefoo examplebar The identifier is a string of ASCII characters that are legal in a "token", consisting of between 1 and 64 characters. Application data (msid-appdata) is carried on the same line as the identifier, separated from the identifier by a space. The identifier (msid-id) uniquely identifies a group within the scope of an SDP description. Alvestrand Expires January 8, 2017 [Page 5] Internet-Draft MSID in SDP July 2016 There may be multiple msid attributes in a single media description. This represents the case where a single MediaStreamTrack is present in multiple MediaStreams; the value of "msid-appdata" MUST be identical for all occurences. Multiple media descriptions with the same value for msid-id and msid- appdata are not permitted. Endpoints can update the associations between RTP streams as expressed by msid attributes at any time. The msid attributes depend on the association of RTP streams with media descriptions, but does not depend on the association of RTP streams with RTP transports; therefore, its mux category (as defined in [I-D.ietf-mmusic-sdp-mux-attributes]) is NORMAL - the process of deciding on MSID attributes doesn't have to take into consideration whether the RTP streams are bundled or not. 3. Procedures This section describes the procedures for associating media descriptions representing MediaStreamTracks within MediaStreams as defined in [W3C.WD-webrtc-20160531]. In the Javascript API described in that specification, each MediaStream and MediaStreamTrack has an "id" attribute, which is a DOMString. The value of the "msid-id" field in the msid consists of the "id" attribute of a MediaStream, as defined in the MediaStream's WebIDL specification. The value of the "msid-appdata" field in the msid consists of the "id" attribute of a MediaStreamTrack, as defined in the MediaStreamTrack's WebIDL specification. When an SDP session description is updated, a specific "msid-id" value continues to refer to the same MediaStream, and a specific "msid-appdata" to the same MediaStreamTrack. There is no memory apart from the currently valid SDP descriptions; if an msid "identifier" value disappears from the SDP and appears in a later negotiation, it will be taken to refer to a new MediaStream. If the MSID attribute does not conform to the ABNF given here, it SHOULD be ignored. The following is a high level description of the rules for handling SDP updates. Detailed procedures are in Section 3.2. Alvestrand Expires January 8, 2017 [Page 6] Internet-Draft MSID in SDP July 2016 o When a new msid "identifier" value occurs in a session description, the recipient can signal to its application that a new MediaStream has been added. o When a session description is updated to have media descriptions with an msid "identifier" value, with one or more different "appdata" values, the recipient can siggnal to its application that new MediaStreamTracks have been added to the MediaStream. This is done for each different msid "identifier" value. o When a session description is updated to no longer list any msid attribute on a specific media description, the recipient can signal to its application that the corresponding MediaStreamTrack has ended. In addition to signaling that the track is closed when its msid attribute disappears from the SDP, the track will also be signaled as being closed when all associated SSRCs have disappeared by the rules of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), or when the corresponding media description is disabled by setting the port number to zero. Changing the direction of the media description (by setting "sendonly", "recvonly" or "inactive" attributes) will not close the MediaStreamTrack. The association between SSRCs and media descriptions is specified in [I-D.ietf-rtcweb-jsep]. 3.1. Handling of non-signalled tracks Entities that do not use msid will not send msid. This means that there will be some incoming RTP packets that the recipient has no predefined MediaStream id value for. Note that this handling is triggered by incoming RTP packets, not by SDP negotiation. When MSID is used, the only time this can happen is when, after the initial negotiation, a negotiation is performed where the answerer adds a MediaStreamTrack to an already established connection and starts sending data before the answer is received by the offerer. For initial negotiation, packets won't flow until the ICE candidates and fingerprints have been exchanged, so this is not an issue. The recipient of those packets will perform the following steps: o When RTP packets are initially received, it will create an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType), and use the MID RTP header extension Alvestrand Expires January 8, 2017 [Page 7] Internet-Draft MSID in SDP July 2016 [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate the RTP packets with a specific media section. o If the connection is not in the RTCSignalingState "stable", it will wait at this point. o When the connection is in the RTCSignalingState "stable", it will assign ID values. The following steps are performed to assign ID values: o If there is an msid attribute, it will use that attribute to populate the "id" field of the MediaStreamTrack and associated MediaStreams, as described above. o If there is no msid attribute, the identifier of the MediaStreamTrack will be set to a randomly generated string, and it will be signalled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". o After deciding on the "id" field to be applied to the MediaStreamTrack, the track will be signalled to the user. The process above may involve a considerable amount of buffering before the stable state is entered. If the implementation wishes to limit this buffering, it MUST signal to the user that media has been discarded. It follows from the above that MediaStreamTracks in the "default" MediaStream cannot be closed by removing the msid attribute; the application must instead signal these as closed when the SSRC disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 or by disabling the media description by setting its port to zero. 3.2. Detailed Offer/Answer Procedures These procedures are given in terms of RFC 3264-recommended sections. They describe the actions to be taken in terms of MediaStreams and MediaStreamTracks; they do not include event signalling inside the application, which is described in JSEP. 3.2.1. Generating the initial offer For each media description in the offer, if there is an associated outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to the section for each MediaStream with which the MediaStreamTrack is associated. The "identifier" field of the attribute is set to the Alvestrand Expires January 8, 2017 [Page 8] Internet-Draft MSID in SDP July 2016 WebIDL "id" attribute of the MediaStream, and the "appdata" field is set to the WebIDL "id" attribute of the MediaStreamTrack. 3.2.2. Answerer processing of the Offer For each media description in the offer, and for each "a=msid" attribute in the media description, the receiver of the offer will perform the following steps: o Extract the "appdata" field of the "a=msid" attribute o Check if a MediaStreamTrack with the same WebIDL "id" attribute as the "appdata" field already exists, and is not in the "ended" state. If it is not found, create it. o Extract the "identifier" field of the "a=msid" attribte. o Check if a MediaStream with the same WebIDL "id" attribute already exists. If not, create it. o Add the MediaStreamTrack to the MediaStream o Signal to the user that a new MediaStreamTrack is available. 3.2.3. Generating the answer The answer is generated in exactly the same manner as the offer. "a=msid" values in the offer do not influence the answer. 3.2.4. Offerer processing of the answer The answer is processed in exactly the same manner as the offer. 3.2.5. Modifying the session On subsequent exchanges, precisely the same procedure as for the initial offer/answer is followed, but with one additional step in the parsing of the offer and answer: o For each MediaStreamTrack that has been created as a result of previous offer/answer exchanges, and is not in the "ended" state, check to see if there is still an "a=msid" attribute in the present SDP whose "appdata" field is the same as the WebIDL "id" attribute of the track. o If no such attribute is found, stop the MediaStreamTrack. This will set its state to "ended". Alvestrand Expires January 8, 2017 [Page 9] Internet-Draft MSID in SDP July 2016 3.3. Example SDP description The following SDP description shows the representation of a WebRTC PeerConnection with two MediaStreams, each of which has one audio and one video track. Only the parts relevant to the MSID are shown. Line wrapping, empty lines and comments are added for clarity. They are not part of the SDP. # First MediaStream - id is 4701... m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 a=msid:47017fee-b6c1-4162-929c-a25110252400 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 m=video 56502 UDP/TLS/RTP/SAVPF 100 101 a=msid:47017fee-b6c1-4162-929c-a25110252400 b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0 # Second MediaStream - id is 6131.... m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae b94006c5-cade-4e0a-9ed9-d3e6747be7d9 m=video 56504 UDP/TLS/RTP/SAVPF 100 101 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae f30bdb4a-1497-49b5-3198-e0c9a23172e0 4. IANA Considerations 4.1. Attribute registration in existing registries This document requests IANA to register the "msid" attribute in the "att-field (media level only)" registry within the SDP parameters registry, according to the procedures of [RFC4566] The required information for "msid" is: o Contact name, email: IETF, contacted via mmusic@ietf.org, or a successor address designated by IESG o Attribute name: msid o Long-form attribute name: MediaStream group Identifier Alvestrand Expires January 8, 2017 [Page 10] Internet-Draft MSID in SDP July 2016 o Subject to charset: The attribute value contains only ASCII characters, and is therefore not subject to the charset attribute. o Purpose: The attribute can be used to signal the relationship between a WebRTC MediaStream and a set of media descriptions. o Appropriate values: The details of appropriate values are given in RFC XXXX. o MUX category: NORMAL The MUX category is defined in [I-D.ietf-mmusic-sdp-mux-attributes]. 5. Security Considerations An adversary with the ability to modify SDP descriptions has the ability to switch around tracks between MediaStreams. This is a special case of the general security consideration that modification of SDP descriptions needs to be confined to entities trusted by the application. If implementing buffering as mentioned in Section 3.1, the amount of buffering should be limited to avoid memory exhaustion attacks. Careless generation of identifiers can leak privacy-sensitive information. [W3C.CR-mediacapture-streams-20160519] recommends that identifiers are generated using UUID class 3 or 4 as a basis, which avoids such leakage. No other attacks have been identified that depend on this mechanism. 6. Acknowledgements This note is based on sketches from, among others, Justin Uberti and Cullen Jennings. Special thanks to Flemming Andreassen, Ben Campbell, Miguel Garcia, Martin Thomson, Ted Hardie, Adam Roach, Magnus Westerlund, Alissa Cooper, Sue Hares and Paul Kyzivat for their work in reviewing this draft, with many specific language suggestions. 7. References 7.1. Normative References Alvestrand Expires January 8, 2017 [Page 11] Internet-Draft MSID in SDP July 2016 [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-02 (work in progress), July 2014. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-07 (work in progress), July 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [W3C.CR-mediacapture-streams-20160519] Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A., and B. Aboba, "Media Capture and Streams", World Wide Web Consortium CR CR-mediacapture-streams-20160519, May 2016, . [W3C.WD-webrtc-20160531] Wilson, C. and J. Kalliokoski, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc-20160531, May 2016, . 7.2. Informative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-07 (work in progress), April 2014. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-10 (work in progress), June 2014. Alvestrand Expires January 8, 2017 [Page 12] Internet-Draft MSID in SDP July 2016 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . Appendix A. Design considerations, rejected alternatives One suggested mechanism has been to use CNAME instead of a new attribute. This was abandoned because CNAME identifies a synchronization context; one can imagine both wanting to have tracks from the same synchronization context in multiple MediaStreams and wanting to have tracks from multiple synchronization contexts within one MediaStream (but the latter is impossible, since a MediaStream is defined to impose synchronization on its members). Another suggestion has been to put the msid value within an attribute of RTCP SR (sender report) packets. This doesn't offer the ability to know that you have seen all the tracks currently configured for a MediaStream. A suggestion that survived for a number of drafts was to define "msid" as a generic mechanism, where the particular semantics of this usage of the mechanism would be defined by an "a=wms-semantic" attribute. This was removed in April 2015. Appendix B. Change log This appendix should be deleted before publication as an RFC. B.1. Changes from alvestrand-rtcweb-msid-00 to -01 Added track identifier. Added inclusion-by-reference of draft-lennox-mmusic-source-selection for track muting. Some rewording. Alvestrand Expires January 8, 2017 [Page 13] Internet-Draft MSID in SDP July 2016 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 Split document into sections describing a generic grouping mechanism and sections describing the application of this grouping mechanism to the WebRTC MediaStream concept. Removed the mechanism for muting tracks, since this is not central to the MSID mechanism. B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 Changed the draft name according to the wishes of the MMUSIC group chairs. Added text indicting cases where it's appropriate to have the same appdata for multiple SSRCs. Minor textual updates. B.4. Changes from alvestrand-mmusic-msid-00 to -01 Increased the amount of explanatory text, much based on a review by Miguel Garcia. Removed references to BUNDLE, since that spec is under active discussion. Removed distinguished values of the MSID identifier. B.5. Changes from alvestrand-mmusic-msid-01 to -02 Changed the order of the "msid-semantic: " attribute's value fields and allowed multiple identifiers. This makes the attribute useful as a marker for "I understand this semantic". Changed the syntax for "identifier" and "appdata" to be "token". Changed the registry for the "msid-semantic" attribute values to be a new registry, based on advice given in Atlanta. B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 Updated terminology to refer to m-lines rather than RTP sessions when discussing SDP formats and the ability of other linking mechanisms to refer to SSRCs. Changed the "default" mechanism to return independent streams after considering the synchronization problem. Alvestrand Expires January 8, 2017 [Page 14] Internet-Draft MSID in SDP July 2016 Removed the space from between "msid-semantic" and its value, to be consistent with RFC 5576. B.7. Changes from mmusic-msid-00 to -01 Reworked msid mechanism to be a per-m-line attribute, to align with draft-roach-mmusic-unified-plan. B.8. Changes from mmusic-msid-01 to -02 Corrected several missed cases where the word "ssrc" was not changed to "M-line". Added pointer to unified-plan (which should be moved to point to -jsep) Removed suggestion that ssrc-group attributes can be used with "msid- semantic", it is now only the msid-semantic registry. B.9. Changes from mmusic-msid-02 to -03 Corrected even more cases where the word "ssrc" was not changed to "M-line". Added the functionality of using an asterisk (*) in the msid-semantic line, in order to remove the need for listing all msids in the msid- semantic line whne only one msid-semantic is in use. Removed some now-unnecessary text. B.10. Changes from mmusic-msid-03 to -04 Changed title to reflect focus on WebRTC MediaStreams Added a section on receiver-side media stream control, using the "msid-control" attribute. B.11. Changes from -04 to -05 Removed the msid-control section after WG discussion. Removed some text that seemed only to pertain to resolved issues. B.12. Changes from -05 to -06 Addressed issues found in Fleming Andreassen's review Referenced JSEP rather than unified-plan for the M-line mapping model Alvestrand Expires January 8, 2017 [Page 15] Internet-Draft MSID in SDP July 2016 Relaxed MSID definition to allow "token-char" in values rather than a-z 0-9 hyphen; tightened ABNF by adding length description to it. Deleted discussion of abandoned alternatives, as part of preparing for publication. Added a "detailed procedures" section to the WMS semantics description. Added IANA registration of the "msid-semantic" attribute. B.13. Changes from -06 to -07 Changed terminology from referring to "WebRTC device" to referring to "entities that implement the WMS semantic". Changed names for ABNF constructions based on a proposal by Paul Kyzivat. Included a section on generic offer/answer semantics. B.14. Changes from -07 to -08 Removed Appendix B that described the (now obsolete) ssrc-specific usage of MSID. Adopted a restructuring of the IANA section based on a suggestion from Martin Thomson. A number of text and ABNF clarifications based on suggestions from Ted Hardie, Paul Kyzivat and Adam Roach. Changed the "non-signalled track handling" to create a single stream with multiple tracks again, according to discussions at TPAC in November 2014 B.15. Changes from -08 to -09 Removed "wms-semantic" and all mention of multiple semantics for msid, as agreed at the Dallas IETF, March 2015. Addressed a number of review comments from Fleming Andresen and others. Changed the term "m-line" to "media description", since that is the term used in RFC 4566. Alvestrand Expires January 8, 2017 [Page 16] Internet-Draft MSID in SDP July 2016 Tried to make sure this document does not describe the API to the application. B.16. Changes from -09 to -10 Addressed review comments from Paul Kyzivat. B.17. Changes from -10 to -11 Defined the semantics of multiple MSIDs in a media section to be a MediaStreamTrack present in multiple MediaStreams. Made an explicit note that MediaStreamTracks are unidirectional. Disallowed the option of sending multiple media sections with the same msid (id and appdata identical). B.18. Changes from -11 to -12 Added mux-category to the IANA considerations section. B.19. Changes from -12 to -13 Modified registration description to delete dependency on -4566-bis B.20. Changes from -13 to -14 Addressed nits found in Gen-ART review B.21. Changes from -14 to -15 Added the terminology section. Switched from "(RTP) media stream" to "RTP stream" per RFC 7656. Added a mention of random ID generation to the security considerations section. Moved definition pointers for MediaStream and MediaStreamTrack to the "mediacapture-streams" document. Added note that syntactically invalid MSID fields SHOULD be ignored. Various small changes based on review feedback during IESG processing. Alvestrand Expires January 8, 2017 [Page 17] Internet-Draft MSID in SDP July 2016 Author's Address Harald Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Alvestrand Expires January 8, 2017 [Page 18] ./draft-ietf-clue-framework-25.txt0000664000764400076440000055466312643774145016344 0ustar iustyiustyCLUE WG M. Duckworth, Ed. Internet Draft Polycom Intended status: Standards Track A. Pepperell Expires: July 8, 2016 Acano S. Wenger Vidyo January 8, 2016 Framework for Telepresence Multi-Streams draft-ietf-clue-framework-25.txt Abstract This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 8, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Duckworth et. al. Expires July 8, 2016 [Page 1] Internet-Draft CLUE Telepresence Framework January 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................4 3. Definitions....................................................4 4. Overview and Motivation........................................7 5. Description of the Framework/Model............................10 6. Spatial Relationships.........................................15 7. Media Captures and Capture Scenes.............................17 7.1. Media Captures...........................................17 7.1.1. Media Capture Attributes............................18 7.2. Multiple Content Capture.................................24 7.2.1. MCC Attributes......................................25 7.3. Capture Scene............................................30 7.3.1. Capture Scene attributes............................33 7.3.2. Capture Scene View attributes.......................33 7.4. Global View List.........................................34 8. Simultaneous Transmission Set Constraints.....................35 9. Encodings.....................................................37 9.1. Individual Encodings.....................................37 9.2. Encoding Group...........................................38 9.3. Associating Captures with Encoding Groups................39 10. Consumer's Choice of Streams to Receive from the Provider....40 10.1. Local preference........................................43 10.2. Physical simultaneity restrictions......................43 10.3. Encoding and encoding group limits......................43 11. Extensibility................................................44 12. Examples - Using the Framework (Informative).................44 12.1. Provider Behavior.......................................44 12.1.1. Three screen Endpoint Provider.....................44 12.1.2. Encoding Group Example.............................51 12.1.3. The MCU Case.......................................52 Duckworth et. al. Expires July 8, 2016 [Page 2] Internet-Draft CLUE Telepresence Framework January 2016 12.2. Media Consumer Behavior.................................53 12.2.1. One screen Media Consumer..........................53 12.2.2. Two screen Media Consumer configuring the example..54 12.2.3. Three screen Media Consumer configuring the example55 12.3. Multipoint Conference utilizing Multiple Content Captures55 12.3.1. Single Media Captures and MCC in the same Advertisement..............................................55 12.3.2. Several MCCs in the same Advertisement.............59 12.3.3. Heterogeneous conference with switching and composition................................................60 12.3.4. Heterogeneous conference with voice activated switching..................................................67 13. Acknowledgements.............................................70 14. IANA Considerations..........................................70 15. Security Considerations......................................70 16. Changes Since Last Version...................................73 17. Normative References.........................................81 18. Informative References.......................................82 19. Authors' Addresses...........................................83 1. Introduction Current telepresence systems, though based on open standards such as RTP [RFC3550] and SIP [RFC3261], cannot easily interoperate with each other. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of multiple audio and video streams comprising the media flows. This document provides a framework for protocols to enable interoperability by handling multiple streams in a standardized way. The framework is intended to support the use cases described in Use Cases for Telepresence Multistreams [RFC7205] and to meet the requirements in Requirements for Telepresence Multistreams [RFC7262]. This includes cases using multiple media streams that are not necessarily telepresence. This document occasionally refers to the term "CLUE", in capital letters. CLUE is an acronym for "ControLling mUltiple streams for tElepresence", which is the name of the IETF working group in which this document and certain companion documents have been developed. Often, CLUE-something refers to something that has been designed by the CLUE working group; for example, this document may be called the CLUE-framework. Duckworth et. al. Expires July 8, 2016 [Page 3] Internet-Draft CLUE Telepresence Framework January 2016 The basic session setup for the use cases is based on SIP [RFC3261] and SDP offer/answer [RFC3264]. In addition to basic SIP & SDP offer/answer, CLUE specific signaling is required to exchange the information describing the multiple media streams. The motivation for this framework, an overview of the signaling, and information required to be exchanged is described in subsequent sections of this document. Companion documents describe the signaling details [I-D.ietf-clue-signaling] and the data model [I-D.ietf-clue-data- model-schema] and protocol [I-D.ietf-clue-protocol]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Definitions The terms defined below are used throughout this document and companion documents. In order to easily identify the use of a defined term, those terms are capitalized. Advertisement: a CLUE message a Media Provider sends to a Media Consumer describing specific aspects of the content of the media, and any restrictions it has in terms of being able to provide certain Streams simultaneously. Audio Capture: Media Capture for audio. Denoted as ACn in the examples in this document. Capture: Same as Media Capture. Capture Device: A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder. Capture Encoding: A specific encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP. Duckworth et. al. Expires July 8, 2016 [Page 4] Internet-Draft CLUE Telepresence Framework January 2016 Capture Scene: a structure representing a spatial region captured by one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a Capture Scene may correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures. Capture Scene View (CSV): a list of Media Captures of the same media type that together form one way to represent the entire Capture Scene. CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- protocol] and the principles of CLUE negotiation, and seeks CLUE- enabled calls. CLUE-enabled call: A call in which two CLUE-capable devices have successfully negotiated support for a CLUE data channel in SDP [RFC4566]. A CLUE-enabled call is not necessarily immediately able to send CLUE-controlled media; negotiation of the data channel and of the CLUE protocol must complete first. Calls between two CLUE- capable devices which have not yet successfully completed negotiation of support for the CLUE data channel in SDP are not considered CLUE- enabled. Conference: used as defined in [RFC4353], A Framework for Conferencing within the Session Initiation Protocol (SIP). Configure Message: A CLUE message a Media Consumer sends to a Media Provider specifying which content and Media Streams it wants to receive, based on the information in a corresponding Advertisement message. Consumer: short for Media Consumer. Encoding: short for Individual Encoding. Encoding Group: A set of encoding parameters representing a total media encoding capability to be sub-divided across potentially multiple Individual Encodings. Endpoint: A CLUE-capable device which is the logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices Duckworth et. al. Expires July 8, 2016 [Page 5] Internet-Draft CLUE Telepresence Framework January 2016 which source and sink media streams, and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. Global View: A set of references to one or more Capture Scene Views of the same media type that are defined within Scenes of the same advertisement. A Global View is a suggestion from the Provider to the Consumer for one set of CSVs that provide a useful representation of all the scenes in the advertisement. Global View List: A list of Global Views included in an Advertisement. A Global View List may include Global Views of different media types. Individual Encoding: a set of parameters representing a way to encode a Media Capture to become a Capture Encoding. Multipoint Control Unit (MCU): a CLUE-capable device that connects two or more endpoints together into one single multimedia conference [RFC5117]. An MCU includes an [RFC4353]-like Mixer, without the [RFC4353] requirement to send media to each participant. Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video or timed text. Media Capture: a source of Media, such as from one or more Capture Devices or constructed from other Media streams. Media Consumer: a CLUE-capable device that intends to receive Capture Encodings. Media Provider: a CLUE-capable device that intends to send Capture Encodings. Multiple Content Capture (MCC): A Capture that mixes and/or switches other Captures of a single type. (E.g. all audio or all video.) Particular Media Captures may or may not be present in the resultant Capture Encoding depending on time or space. Denoted as MCCn in the example cases in this document. Plane of Interest: The spatial plane within a scene containing the most relevant subject matter. Duckworth et. al. Expires July 8, 2016 [Page 6] Internet-Draft CLUE Telepresence Framework January 2016 Provider: Same as Media Provider. Render: the process of generating a representation from media, such as displayed motion video or sound emitted from loudspeakers. Scene: Same as Capture Scene Simultaneous Transmission Set: a set of Media Captures that can be transmitted simultaneously from a Media Provider. Single Media Capture: A capture which contains media from a single source capture device, e.g. an audio capture from a single microphone, a video capture from a single camera. Spatial Relation: The arrangement in space of two objects, in contrast to relation in time or other relationships. Stream: a Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550]. Stream Characteristics: the media stream attributes commonly used in non-CLUE SIP/SDP environments (such as: media codec, bit rate, resolution, profile/level etc.) as well as CLUE specific attributes, such as the Capture ID or a spatial location. Video Capture: Media Capture for video. Denoted as VCn in the example cases in this document. Video Composite: A single image that is formed, normally by an RTP mixer inside an MCU, by combining visual elements from separate sources. 4. Overview and Motivation This section provides an overview of the functional elements defined in this document to represent a telepresence or multistream system. The motivations for the framework described in this document are also provided. Two key concepts introduced in this document are the terms "Media Provider" and "Media Consumer". A Media Provider represents the entity that sends the media and a Media Consumer represents the entity that receives the media. A Media Provider provides Media in the form of RTP packets, a Media Consumer consumes those RTP packets. Media Providers and Media Consumers can reside in Duckworth et. al. Expires July 8, 2016 [Page 7] Internet-Draft CLUE Telepresence Framework January 2016 Endpoints or in Multipoint Control Units (MCUs). A Media Provider in an Endpoint is usually associated with the generation of media for Media Captures; these Media Captures are typically sourced from cameras, microphones, and the like. Similarly, the Media Consumer in an Endpoint is usually associated with renderers, such as screens and loudspeakers. In MCUs, Media Providers and Consumers can have the form of outputs and inputs, respectively, of RTP mixers, RTP translators, and similar devices. Typically, telepresence devices such as Endpoints and MCUs would perform as both Media Providers and Media Consumers, the former being concerned with those devices' transmitted media and the latter with those devices' received media. In a few circumstances, a CLUE-capable device includes only Consumer or Provider functionality, such as recorder-type Consumers or webcam-type Providers. The motivations for the framework outlined in this document include the following: (1) Endpoints in telepresence systems typically have multiple Media Capture and Media Render devices, e.g., multiple cameras and screens. While previous system designs were able to set up calls that would capture media using all cameras and display media on all screens, for example, there was no mechanism that could associate these Media Captures with each other in space and time, in a cross- vendor interoperable way. (2) The mere fact that there are multiple capturing and rendering devices, each of which may be configurable in aspects such as zoom, leads to the difficulty that a variable number of such devices can be used to capture different aspects of a region. The Capture Scene concept allows for the description of multiple setups for those multiple capture devices that could represent sensible operation points of the physical capture devices in a room, chosen by the operator. A Consumer can pick and choose from those configurations based on its rendering abilities and inform the Provider about its choices. Details are provided in section 7. (3) In some cases, physical limitations or other reasons disallow the concurrent use of a device in more than one setup. For example, the center camera in a typical three-camera conference room can set its zoom objective either to capture only the middle few seats, or all seats of a room, but not both concurrently. The Simultaneous Transmission Set concept allows a Provider to signal Duckworth et. al. Expires July 8, 2016 [Page 8] Internet-Draft CLUE Telepresence Framework January 2016 such limitations. Simultaneous Transmission Sets are part of the Capture Scene description, and are discussed in section 8. (4) Often, the devices in a room do not have the computational complexity or connectivity to deal with multiple encoding options simultaneously, even if each of these options is sensible in certain scenarios, and even if the simultaneous transmission is also sensible (i.e. in case of multicast media distribution to multiple endpoints). Such constraints can be expressed by the Provider using the Encoding Group concept, described in section 9. (5) Due to the potentially large number of RTP streams required for a Multimedia Conference involving potentially many Endpoints, each of which can have many Media Captures and media renderers, it has become common to multiplex multiple RTP streams onto the same transport address, so to avoid using the port number as a multiplexing point and the associated shortcomings such as NAT/firewall traversal. The large number of possible permutations of sensible options a Media Provider can make available to a Media Consumer makes a mechanism desirable that allows it to narrow down the number of possible options that a SIP offer/answer exchange has to consider. Such information is made available using protocol mechanisms specified in this document and companion documents. The Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages. Also, there are aspects of the control of both Endpoints and MCUs that dynamically change during the progress of a call, such as audio-level based screen switching, layout changes, and so on, which need to be conveyed. Note that these control aspects are complementary to those specified in traditional SIP based conference management such as BFCP. An exemplary call flow can be found in section 5. Finally, all this information needs to be conveyed, and the notion of support for it needs to be established. This is done by the negotiation of a "CLUE channel", a data channel negotiated early during the initiation of a call. An Endpoint or MCU that rejects the establishment of this data channel, by definition, does not support CLUE based mechanisms, whereas an Endpoint or MCU that accepts it is indicating support for CLUE as specified in this document and its companion documents. Duckworth et. al. Expires July 8, 2016 [Page 9] Internet-Draft CLUE Telepresence Framework January 2016 5. Description of the Framework/Model The CLUE framework specifies how multiple media streams are to be handled in a telepresence conference. A Media Provider (transmitting Endpoint or MCU) describes specific aspects of the content of the media and the media stream encodings it can send in an Advertisement; and the Media Consumer responds to the Media Provider by specifying which content and media streams it wants to receive in a Configure message. The Provider then transmits the asked-for content in the specified streams. This Advertisement and Configure typically occur during call initiation, after CLUE has been enabled in a call, but MAY also happen at any time throughout the call, whenever there is a change in what the Consumer wants to receive or (perhaps less common) the Provider can send. An Endpoint or MCU typically act as both Provider and Consumer at the same time, sending Advertisements and sending Configurations in response to receiving Advertisements. (It is possible to be just one or the other.) The data model [I-D.ietf-clue-data-model-schema]is based around two main concepts: a Capture and an Encoding. A Media Capture (MC), such as of type audio or video, has attributes to describe the content a Provider can send. Media Captures are described in terms of CLUE-defined attributes, such as spatial relationships and purpose of the capture. Providers tell Consumers which Media Captures they can provide, described in terms of the Media Capture attributes. A Provider organizes its Media Captures into one or more Capture Scenes, each representing a spatial region, such as a room. A Consumer chooses which Media Captures it wants to receive from the Capture Scenes. In addition, the Provider can send the Consumer a description of the Individual Encodings it can send in terms of identifiers which relate to items in SDP [RFC4566]. The Provider can also specify constraints on its ability to provide Media, and a sensible design choice for a Consumer is to take these into account when choosing the content and Capture Encodings it requests in the later offer/answer exchange. Some constraints are Duckworth et. al. Expires July 8, 2016 [Page 10] Internet-Draft CLUE Telepresence Framework January 2016 due to the physical limitations of devices--for example, a camera may not be able to provide zoom and non-zoom views simultaneously. Other constraints are system based, such as maximum bandwidth. The following diagram illustrates the information contained in an Advertisement. Duckworth et. al. Expires July 8, 2016 [Page 11] Internet-Draft CLUE Telepresence Framework January 2016 ................................................................... . Provider Advertisement +--------------------+ . . | Simultaneous Sets | . . +------------------------+ +--------------------+ . . | Capture Scene N | +--------------------+ . . +-+----------------------+ | | Global View List | . . | Capture Scene 2 | | +--------------------+ . . +-+----------------------+ | | +----------------------+ . . | Capture Scene 1 | | | | Encoding Group N | . . | +---------------+ | | | +-+--------------------+ | . . | | Attributes | | | | | Encoding Group 2 | | . . | +---------------+ | | | +-+--------------------+ | | . . | | | | | Encoding Group 1 | | | . . | +----------------+ | | | | parameters | | | . . | | V i e w s | | | | | bandwidth | | | . . | | +---------+ | | | | | +-------------------+| | | . . | | |Attribute| | | | | | | V i d e o || | | . . | | +---------+ | | | | | | E n c o d i n g s || | | . . | | | | | | | | Encoding 1 || | | . . | | View 1 | | | | | | || | | . . | | (list of MCs) | | |-+ | +-------------------+| | | . . | +----|-|--|------+ |-+ | | | | . . +---------|-|--|---------+ | +-------------------+| | | . . | | | | | A u d i o || | | . . | | | | | E n c o d i n g s || | | . . v | | | | Encoding 1 || | | . . +---------|--|--------+ | | || | | . . | Media Capture N |------>| +-------------------+| | | . . +-+---------v--|------+ | | | | | . . | Media Capture 2 | | | | |-+ . . +-+--------------v----+ |-------->| | | . . | Media Capture 1 | | | | |-+ . . | +----------------+ |---------->| | . . | | Attributes | | |_+ +----------------------+ . . | +----------------+ |_+ . . +---------------------+ . . . ................................................................... Figure 1: Advertisement Structure A very brief outline of the call flow used by a simple system (two Endpoints) in compliance with this document can be described as follows, and as shown in the following figure. Duckworth et. al. Expires July 8, 2016 [Page 12] Internet-Draft CLUE Telepresence Framework January 2016 +-----------+ +-----------+ | Endpoint1 | | Endpoint2 | +----+------+ +-----+-----+ | INVITE (BASIC SDP+CLUECHANNEL) | |--------------------------------->| | 200 0K (BASIC SDP+CLUECHANNEL)| |<---------------------------------| | ACK | |--------------------------------->| | | |<################################>| | BASIC MEDIA SESSION | |<################################>| | | | CONNECT (CLUE CTRL CHANNEL) | |=================================>| | ... | |<================================>| | CLUE CTRL CHANNEL ESTABLISHED | |<================================>| | | | ADVERTISEMENT 1 | |*********************************>| | ADVERTISEMENT 2 | |<*********************************| | | | CONFIGURE 1 | |<*********************************| | CONFIGURE 2 | |*********************************>| | | | REINVITE (UPDATED SDP) | |--------------------------------->| | 200 0K (UPDATED SDP)| |<---------------------------------| | ACK | |--------------------------------->| | | |<################################>| | UPDATED MEDIA SESSION | |<################################>| | | v v Figure 2: Basic Information Flow Duckworth et. al. Expires July 8, 2016 [Page 13] Internet-Draft CLUE Telepresence Framework January 2016 An initial offer/answer exchange establishes a basic media session, for example audio-only, and a CLUE channel between two Endpoints. With the establishment of that channel, the endpoints have consented to use the CLUE protocol mechanisms and, therefore, MUST adhere to the CLUE protocol suite as outlined herein. Over this CLUE channel, the Provider in each Endpoint conveys its characteristics and capabilities by sending an Advertisement as specified herein. The Advertisement is typically not sufficient to set up all media. The Consumer in the Endpoint receives the information provided by the Provider, and can use it for several purposes. It uses it, along with information from an offer/answer exchange, to construct a CLUE Configure message to tell the Provider what the Consumer wishes to receive. Also, the Consumer may use the information provided to tailor the SDP it is going to send during any following SIP offer/answer exchange, and its reaction to SDP it receives in that step. It is often a sensible implementation choice to do so. Spatial relationships associated with the Media can be included in the Advertisement, and it is often sensible for the Media Consumer to take those spatial relationships into account when tailoring the SDP. The Consumer can also limit the number of encodings it must set up resources to receive, and not waste resources on unwanted encodings, because it has the Provider's Advertisement information ahead of time to determine what it really wants to receive. The Consumer can also use the Advertisement information for local rendering decisions. This initial CLUE exchange is followed by an SDP offer/answer exchange that not only establishes those aspects of the media that have not been "negotiated" over CLUE, but has also the effect of setting up the media transmission itself, involving potentially security exchanges, ICE, and whatnot. This step is plain vanilla SIP. During the lifetime of a call, further exchanges MAY occur over the CLUE channel. In some cases, those further exchanges lead to a modified system behavior of Provider or Consumer (or both) without any other protocol activity such as further offer/answer exchanges. For example, a Configure Message requesting the Provider to place a different Capture source into a Capture Encoding, signaled over the CLUE channel, ought not to lead to heavy-handed mechanisms like SIP re-invites. However, in other cases, after the CLUE negotiation an additional offer/answer exchange becomes necessary. For example, Duckworth et. al. Expires July 8, 2016 [Page 14] Internet-Draft CLUE Telepresence Framework January 2016 if both sides decide to upgrade the call from a single screen to a multi-screen call and more bandwidth is required for the additional video channels compared to what was previously negotiated using offer/answer, a new O/A exchange is required. One aspect of the protocol outlined herein and specified in more detail in companion documents is that it makes available, to the Consumer, information regarding the Provider's capabilities to deliver Media, and attributes related to that Media such as their spatial relationship. The operation of the renderer inside the Consumer is unspecified in that it can choose to ignore some information provided by the Provider, and/or not render media streams available from the Provider (although the Consumer follows the CLUE protocol and, therefore, gracefully receives and responds to the Provider's information using a Configure operation). A CLUE-capable device interoperates with a device that does not support CLUE. The CLUE-capable device can determine, by the result of the initial offer/answer exchange, if the other device supports and wishes to use CLUE. The specific mechanism for this is described in [I-D.ietf-clue-signaling]. If the other device does not use CLUE, then the CLUE-capable device falls back to behavior that does not require CLUE. As for the media, Provider and Consumer have an end-to-end communication relationship with respect to (RTP transported) media; and the mechanisms described herein and in companion documents do not change the aspects of setting up those RTP flows and sessions. In other words, the RTP media sessions conform to the negotiated SDP whether or not CLUE is used. 6. Spatial Relationships In order for a Consumer to perform a proper rendering, it is often necessary or at least helpful for the Consumer to have received spatial information about the streams it is receiving. CLUE defines a coordinate system that allows Media Providers to describe the spatial relationships of their Media Captures to enable proper scaling and spatially sensible rendering of their streams. The coordinate system is based on a few principles: o Each Capture Scene has a distinct coordinate system, unrelated to the coordinate systems of other scenes. Duckworth et. al. Expires July 8, 2016 [Page 15] Internet-Draft CLUE Telepresence Framework January 2016 o Simple systems which do not have multiple Media Captures to associate spatially need not use the coordinate model, although it can still be useful to provide an Area of Capture. o Coordinates can be either in real, physical units (millimeters), have an unknown scale or have no physical scale. Systems which know their physical dimensions (for example professionally installed Telepresence room systems) MUST provide those real- world measurements to enable the best user experience for advanced receiving systems that can utilize this information. Systems which don't know specific physical dimensions but still know relative distances MUST use 'unknown scale'. 'No scale' is intended to be used only where Media Captures from different devices (with potentially different scales) will be forwarded alongside one another (e.g. in the case of an MCU). * "Millimeters" means the scale is in millimeters. * "Unknown" means the scale is not necessarily millimeters, but the scale is the same for every Capture in the Capture Scene. * "No Scale" means the scale could be different for each capture- an MCU Provider that advertises two adjacent captures and picks sources (which can change quickly) from different endpoints might use this value; the scale could be different and changing for each capture. But the areas of capture still represent a spatial relation between captures. o The coordinate system is right-handed Cartesian X, Y, Z with the origin at a spatial location of the Provider's choosing. The Provider MUST use the same coordinate system with the same scale and origin for all coordinates within the same Capture Scene. The direction of increasing coordinate values is: X increases from left to right, from the point of view of an observer at the front of the room looking toward the back Y increases from the front of the room to the back of the room Z increases from low to high (i.e. floor to ceiling) Cameras in a scene typically point in the direction of increasing Y, from front to back. But there could be multiple cameras pointing in different directions. If the physical space does not have a well-defined front and back, the provider chooses any direction for X and Y and Z consistent with right-handed coordinates. Duckworth et. al. Expires July 8, 2016 [Page 16] Internet-Draft CLUE Telepresence Framework January 2016 7. Media Captures and Capture Scenes This section describes how Providers can describe the content of media to Consumers. 7.1. Media Captures Media Captures are the fundamental representations of streams that a device can transmit. What a Media Capture actually represents is flexible: o It can represent the immediate output of a physical source (e.g. camera, microphone) or 'synthetic' source (e.g. laptop computer, DVD player) o It can represent the output of an audio mixer or video composer o It can represent a concept such as 'the loudest speaker' o It can represent a conceptual position such as 'the leftmost stream' To identify and distinguish between multiple Capture instances Captures have a unique identity. For instance: VC1, VC2 and AC1, AC2, where VC1 and VC2 refer to two different video captures and AC1 and AC2 refer to two different audio captures. Some key points about Media Captures: . A Media Capture is of a single media type (e.g. audio or video) . A Media Capture is defined in a Capture Scene and is given an Advertisement unique identity. The identity may be referenced outside the Capture Scene that defines it through a Multiple Content Capture (MCC) . A Media Capture may be associated with one or more Capture Scene Views . A Media Capture has exactly one set of spatial information . A Media Capture can be the source of at most one Capture Encoding Each Media Capture can be associated with attributes to describe what it represents. Duckworth et. al. Expires July 8, 2016 [Page 17] Internet-Draft CLUE Telepresence Framework January 2016 7.1.1. Media Capture Attributes Media Capture Attributes describe information about the Captures. A Provider can use the Media Capture Attributes to describe the Captures for the benefit of the Consumer of the Advertisement message. All these attributes are optional. Media Capture Attributes include: . Spatial information, such as point of capture, point on line of capture, and area of capture, all of which, in combination define the capture field of, for example, a camera . Other descriptive information to help the Consumer choose between captures (e.g. description, presentation, view, priority, language, person information and type) The sub-sections below define the Capture attributes. 7.1.1.1. Point of Capture The Point of Capture attribute is a field with a single Cartesian (X, Y, Z) point value which describes the spatial location of the capturing device (such as camera). For an Audio Capture with multiple microphones, the Point of Capture defines the nominal mid- point of the microphones. 7.1.1.2. Point on Line of Capture The Point on Line of Capture attribute is a field with a single Cartesian (X, Y, Z) point value which describes a position in space of a second point on the axis of the capturing device, toward the direction it is pointing; the first point being the Point of Capture (see above). Together, the Point of Capture and Point on Line of Capture define the direction and axis of the capturing device, for example the optical axis of a camera or the axis of a microphone. The Media Consumer can use this information to adjust how it renders the received media if it so chooses. For an Audio Capture, the Media Consumer can use this information along with the Audio Capture Sensitivity Pattern to define a 3- dimensional volume of capture where sounds can be expected to be picked up by the microphone providing this specific audio capture. If the Consumer wants to associate an Audio Capture with a Video Capture, it can compare this volume with the area of capture for Duckworth et. al. Expires July 8, 2016 [Page 18] Internet-Draft CLUE Telepresence Framework January 2016 video media to provide a check on whether the audio capture is indeed spatially associated with the video capture. For example, a video area of capture that fails to intersect at all with the audio volume of capture, or is at such a long radial distance from the microphone point of capture that the audio level would be very low, would be inappropriate. 7.1.1.3. Area of Capture The Area of Capture is a field with a set of four (X, Y, Z) points as a value which describes the spatial location of what is being "captured". This attribute applies only to video captures, not other types of media. By comparing the Area of Capture for different Video Captures within the same Capture Scene a Consumer can determine the spatial relationships between them and render them correctly. The four points MUST be co-planar, forming a quadrilateral, which defines the Plane of Interest for the particular Media Capture. If the Area of Capture is not specified, it means the Video Capture might be spatially related to other Captures in the same Scene, but there is no detailed information on the relationship.For a switched Capture that switches between different sections within a larger area, the area of capture MUST use coordinates for the larger potential area. 7.1.1.4. Mobility of Capture The Mobility of Capture attribute indicates whether or not the point of capture, line on point of capture, and area of capture values stay the same over time, or are expected to change (potentially frequently). Possible values are static, dynamic, and highly dynamic. An example for "dynamic" is a camera mounted on a stand which is occasionally hand-carried and placed at different positions in order to provide the best angle to capture a work task. A camera worn by a person who moves around the room is an example for "highly dynamic". In either case, the effect is that the capture point, capture axis and area of capture change with time. The capture point of a static Capture MUST NOT move for the life of the CLUE session. The capture point of dynamic Captures is categorized by a change in position followed by a reasonable period Duckworth et. al. Expires July 8, 2016 [Page 19] Internet-Draft CLUE Telepresence Framework January 2016 of stability--in the order of magnitude of minutes. Highly dynamic captures are categorized by a capture point that is constantly moving. If the "area of capture", "capture point" and "line of capture" attributes are included with dynamic or highly dynamic Captures they indicate spatial information at the time of the Advertisement. 7.1.1.5. Audio Capture Sensitivity Pattern The Audio Capture Sensitivity Pattern attribute applies only to audio captures. This attribute gives information about the nominal sensitivity pattern of the microphone which is the source of the Capture. Possible values include patterns such as omni, shotgun, cardioid, hyper-cardioid. 7.1.1.6. Description The Description attribute is a human-readable description (which could be in multiple languages) of the Capture. 7.1.1.7. Presentation The Presentation attribute indicates that the capture originates from a presentation device, that is one that provides supplementary information to a conference through slides, video, still images, data etc. Where more information is known about the capture it MAY be expanded hierarchically to indicate the different types of presentation media, e.g. presentation.slides, presentation.image etc. Note: It is expected that a number of keywords will be defined that provide more detail on the type of presentation. Refer to [I- D.ietf-clue-data-model-schema] for how to extend the model. 7.1.1.8. View The View attribute is a field with enumerated values, indicating what type of view the Capture relates to. The Consumer can use this information to help choose which Media Captures it wishes to receive. Possible values are: Room - Captures the entire scene Table - Captures the conference table with seated people Duckworth et. al. Expires July 8, 2016 [Page 20] Internet-Draft CLUE Telepresence Framework January 2016 Individual - Captures an individual person Lectern - Captures the region of the lectern including the presenter, for example in a classroom style conference room Audience - Captures a region showing the audience in a classroom style conference room 7.1.1.9. Language The Language attribute indicates one or more languages used in the content of the Media Capture. Captures MAY be offered in different languages in case of multilingual and/or accessible conferences. A Consumer can use this attribute to differentiate between them and pick the appropriate one. Note that the Language attribute is defined and meaningful both for audio and video captures. In case of audio captures, the meaning is obvious. For a video capture, "Language" could, for example, be sign interpretation or text. The Language attribute is coded per [RFC5646]. 7.1.1.10. Person Information The Person Information attribute allows a Provider to provide specific information regarding the people in a Capture (regardless of whether or not the capture has a Presentation attribute). The Provider may gather the information automatically or manually from a variety of sources however the xCard [RFC6351] format is used to convey the information. This allows various information such as Identification information (section 6.2/[RFC6350]), Communication Information (section 6.4/[RFC6350]) and Organizational information (section 6.6/[RFC6350]) to be communicated. A Consumer may then automatically (i.e. via a policy) or manually select Captures based on information about who is in a Capture. It also allows a Consumer to render information regarding the people participating in the conference or to use it for further processing. The Provider may supply a minimal set of information or a larger set of information. However it MUST be compliant to [RFC6350] and supply a "VERSION" and "FN" property. A Provider may supply multiple xCards per Capture of any KIND (section 6.1.4/[RFC6350]). Duckworth et. al. Expires July 8, 2016 [Page 21] Internet-Draft CLUE Telepresence Framework January 2016 In order to keep CLUE messages compact the Provider SHOULD use a URI to point to any LOGO, PHOTO or SOUND contained in the xCARD rather than transmitting the LOGO, PHOTO or SOUND data in a CLUE message. 7.1.1.11. Person Type The Person Type attribute indicates the type of people contained in the capture with respect to the meeting agenda (regardless of whether or not the capture has a Presentation attribute). As a capture may include multiple people the attribute may contain multiple values. However values MUST NOT be repeated within the attribute. An Advertiser associates the person type with an individual capture when it knows that a particular type is in the capture. If an Advertiser cannot link a particular type with some certainty to a capture then it is not included. A Consumer on reception of a capture with a person type attribute knows with some certainly that the capture contains that person type. The capture may contain other person types but the Advertiser has not been able to determine that this is the case. The types of Captured people include: . Chair - the person responsible for running the meeting according to the agenda. . Vice-Chair - the person responsible for assisting the chair in running the meeting. . Minute Taker - the person responsible for recording the minutes of the meeting. . Attendee - the person has no particular responsibilities with respect to running the meeting. . Observer - an Attendee without the right to influence the discussion. . Presenter - the person is scheduled on the agenda to make a presentation in the meeting. Note: This is not related to any "active speaker" functionality. . Translator - the person is providing some form of translation or commentary in the meeting. . Timekeeper - the person is responsible for maintaining the meeting schedule. Duckworth et. al. Expires July 8, 2016 [Page 22] Internet-Draft CLUE Telepresence Framework January 2016 Furthermore the person type attribute may contain one or more strings allowing the Provider to indicate custom meeting specific types. 7.1.1.12. Priority The Priority attribute indicates a relative priority between different Media Captures. The Provider sets this priority, and the Consumer MAY use the priority to help decide which Captures it wishes to receive. The "priority" attribute is an integer which indicates a relative priority between Captures. For example it is possible to assign a priority between two presentation Captures that would allow a remote Endpoint to determine which presentation is more important. Priority is assigned at the individual Capture level. It represents the Provider's view of the relative priority between Captures with a priority. The same priority number MAY be used across multiple Captures. It indicates they are equally important. If no priority is assigned no assumptions regarding relative importance of the Capture can be assumed. 7.1.1.13. Embedded Text The Embedded Text attribute indicates that a Capture provides embedded textual information. For example the video Capture may contain speech to text information composed with the video image. 7.1.1.14. Related To The Related To attribute indicates the Capture contains additional complementary information related to another Capture. The value indicates the identity of the other Capture to which this Capture is providing additional information. For example, a conference can utilize translators or facilitators that provide an additional audio stream (i.e. a translation or description or commentary of the conference). Where multiple captures are available, it may be advantageous for a Consumer to select a complementary Capture instead of or in addition to a Capture it relates to. Duckworth et. al. Expires July 8, 2016 [Page 23] Internet-Draft CLUE Telepresence Framework January 2016 7.2. Multiple Content Capture The MCC indicates that one or more Single Media Captures are multiplexed (temporally and/or spatially) or mixed in one Media Capture. Only one Capture type (i.e. audio, video, etc.) is allowed in each MCC instance. The MCC may contain a reference to the Single Media Captures (which may have their own attributes) as well as attributes associated with the MCC itself. A MCC may also contain other MCCs. The MCC MAY reference Captures from within the Capture Scene that defines it or from other Capture Scenes. No ordering is implied by the order that Captures appear within a MCC. A MCC MAY contain no references to other Captures to indicate that the MCC contains content from multiple sources but no information regarding those sources is given. MCCs either contain the referenced Captures and no others, or have no referenced captures and therefore may contain any Capture. One or more MCCs may also be specified in a CSV. This allows an Advertiser to indicate that several MCC captures are used to represent a capture scene. Table 14 provides an example of this case. As outlined in section 7.1. each instance of the MCC has its own Capture identity i.e. MCC1. It allows all the individual captures contained in the MCC to be referenced by a single MCC identity. The example below shows the use of a Multiple Content Capture: +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | {MC attributes} | | VC2 | {MC attributes} | | VC3 | {MC attributes} | | MCC1(VC1,VC2,VC3) | {MC and MCC attributes} | | CSV(MCC1) | | +---------------------------------------------------------+ Table 1: Multiple Content Capture concept This indicates that MCC1 is a single capture that contains the Captures VC1, VC2 and VC3 according to any MCC1 attributes. Duckworth et. al. Expires July 8, 2016 [Page 24] Internet-Draft CLUE Telepresence Framework January 2016 7.2.1. MCC Attributes Media Capture Attributes may be associated with the MCC instance and the Single Media Captures that the MCC references. A Provider should avoid providing conflicting attribute values between the MCC and Single Media Captures. Where there is conflict the attributes of the MCC override any that may be present in the individual Captures. A Provider MAY include as much or as little of the original source Capture information as it requires. There are MCC specific attributes that MUST only be used with Multiple Content Captures. These are described in the sections below. The attributes described in section 7.1.1. MAY also be used with MCCs. The spatial related attributes of an MCC indicate its area of capture and point of capture within the scene, just like any other media capture. The spatial information does not imply anything about how other captures are composed within an MCC. For example: A virtual scene could be constructed for the MCC capture with two Video Captures with a "MaxCaptures" attribute set to 2 and an "Area of Capture" attribute provided with an overall area. Each of the individual Captures could then also include an "Area of Capture" attribute with a sub-set of the overall area. The Consumer would then know how each capture is related to others within the scene, but not the relative position of the individual captures within the composed capture. +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | AreaofCapture=(0,0,0)(9,0,0) | | | (0,0,9)(9,0,9) | | VC2 | AreaofCapture=(10,0,0)(19,0,0) | | | (10,0,9)(19,0,9) | | MCC1(VC1,VC2) | MaxCaptures=2 | | | AreaofCapture=(0,0,0)(19,0,0) | | | (0,0,9)(19,0,9) | | CSV(MCC1) | | +---------------------------------------------------------+ Table 2: Example of MCC and Single Media Capture attributes Duckworth et. al. Expires July 8, 2016 [Page 25] Internet-Draft CLUE Telepresence Framework January 2016 The sub-sections below describe the MCC only attributes. 7.2.1.1. Maximum Number of Captures within a MCC The Maximum Number of Captures MCC attribute indicates the maximum number of individual Captures that may appear in a Capture Encoding at a time. The actual number at any given time can be less than or equal to this maximum. It may be used to derive how the Single Media Captures within the MCC are composed / switched with regards to space and time. A Provider can indicate that the number of Captures in a MCC Capture Encoding is equal "=" to the MaxCaptures value or that there may be any number of Captures up to and including "<=" the MaxCaptures value. This allows a Provider to distinguish between a MCC that purely represents a composition of sources versus a MCC that represents switched or switched and composed sources. MaxCaptures may be set to one so that only content related to one of the sources are shown in the MCC Capture Encoding at a time or it may be set to any value up to the total number of Source Media Captures in the MCC. The bullets below describe how the setting of MaxCapture versus the number of Captures in the MCC affects how sources appear in a Capture Encoding: . When MaxCaptures is set to <= 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC this is a switched case. Zero or 1 Captures may be switched into the Capture Encoding. Note: zero is allowed because of the "<=". . When MaxCaptures is set to = 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC this is a switched case. Only one Capture source is contained in a Capture Encoding at a time. . When MaxCaptures is set to <= N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified) this is a switched and composed case. The Capture Encoding may contain purely switched sources (i.e. <=2 allows for 1 source on its own), or may contain composed and switched sources (i.e. a composition of 2 sources switched between the sources). . When MaxCaptures is set to = N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified) this Duckworth et. al. Expires July 8, 2016 [Page 26] Internet-Draft CLUE Telepresence Framework January 2016 is a switched and composed case. The Capture Encoding contains composed and switched sources (i.e. a composition of N sources switched between the sources). It is not possible to have a single source. . When MaxCaptures is set to <= to the number of Captures in the MCC this is a switched and composed case. The Capture Encoding may contain media switched between any number (up to the MaxCaptures) of composed sources. . When MaxCaptures is set to = to the number of Captures in the MCC this is a composed case. All the sources are composed into a single Capture Encoding. If this attribute is not set then as default it is assumed that all source media capture content can appear concurrently in the Capture Encoding associated with the MCC. For example: The use of MaxCaptures equal to 1 on a MCC with three Video Captures VC1, VC2 and VC3 would indicate that the Advertiser in the Capture Encoding would switch between VC1, VC2 or VC3 as there may be only a maximum of one Capture at a time. 7.2.1.2. Policy The Policy MCC Attribute indicates the criteria that the Provider uses to determine when and/or where media content appears in the Capture Encoding related to the MCC. The attribute is in the form of a token that indicates the policy and an index representing an instance of the policy. The same index value can be used for multiple MCCs. The tokens are: SoundLevel - This indicates that the content of the MCC is determined by a sound level detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC. RoundRobin - This indicates that the content of the MCC is determined by a time based algorithm. For example: the Provider provides content from a particular source for a period of time and then provides content from another source and so on. An index is used to represent an instance in the policy setting. An index of 0 represents the most current instance of the policy, i.e. Duckworth et. al. Expires July 8, 2016 [Page 27] Internet-Draft CLUE Telepresence Framework January 2016 the active speaker, 1 represents the previous instance, i.e. the previous active speaker and so on. The following example shows a case where the Provider provides two media streams, one showing the active speaker and a second stream showing the previous speaker. +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | | | VC2 | | | MCC1(VC1,VC2) | Policy=SoundLevel:0 | | | MaxCaptures=1 | | MCC2(VC1,VC2) | Policy=SoundLevel:1 | | | MaxCaptures=1 | | CSV(MCC1,MCC2) | | +---------------------------------------------------------+ Table 3: Example Policy MCC attribute usage 7.2.1.3. Synchronisation Identity The Synchronisation Identity MCC attribute indicates how the individual Captures in multiple MCC Captures are synchronised. To indicate that the Capture Encodings associated with MCCs contain Captures from the same source at the same time a Provider should set the same Synchronisation Identity on each of the concerned MCCs. It is the Provider that determines what the source for the Captures is, so a Provider can choose how to group together Single Media Captures into a combined "source" for the purpose of switching them together to keep them synchronized according to the SynchronisationID attribute. For example when the Provider is in an MCU it may determine that each separate CLUE Endpoint is a remote source of media. The Synchronisation Identity may be used across media types, i.e. to synchronize audio and video related MCCs. Without this attribute it is assumed that multiple MCCs may provide content from different sources at any particular point in time. For example: Duckworth et. al. Expires July 8, 2016 [Page 28] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | Description=Left | | VC2 | Description=Centre | | VC3 | Description=Right | | AC1 | Description=Room | | CSV(VC1,VC2,VC3) | | | CSV(AC1) | | +=======================+=================================+ | Capture Scene #2 | | +-----------------------|---------------------------------+ | VC4 | Description=Left | | VC5 | Description=Centre | | VC6 | Description=Right | | AC2 | Description=Room | | CSV(VC4,VC5,VC6) | | | CSV(AC2) | | +=======================+=================================+ | Capture Scene #3 | | +-----------------------|---------------------------------+ | VC7 | | | AC3 | | +=======================+=================================+ | Capture Scene #4 | | +-----------------------|---------------------------------+ | VC8 | | | AC4 | | +=======================+=================================+ | Capture Scene #5 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC4,VC7) | SynchronisationID=1 | | | MaxCaptures=1 | | MCC2(VC2,VC5,VC8) | SynchronisationID=1 | | | MaxCaptures=1 | | MCC3(VC3,VC6) | MaxCaptures=1 | | MCC4(AC1,AC2,AC3,AC4) | SynchronisationID=1 | | | MaxCaptures=1 | | CSV(MCC1,MCC2,MCC3) | | | CSV(MCC4) | | +=======================+=================================+ Table 4: Example Synchronisation Identity MCC attribute usage Duckworth et. al. Expires July 8, 2016 [Page 29] Internet-Draft CLUE Telepresence Framework January 2016 The above Advertisement would indicate that MCC1, MCC2, MCC3 and MCC4 make up a Capture Scene. There would be four Capture Encodings (one for each MCC). Because MCC1 and MCC2 have the same SynchronisationID, each Encoding from MCC1 and MCC2 respectively would together have content from only Capture Scene 1 or only Capture Scene 2 or the combination of VC7 and VC8 at a particular point in time. In this case the Provider has decided the sources to be synchronized are Scene #1, Scene #2, and Scene #3 and #4 together. The Encoding from MCC3 would not be synchronised with MCC1 or MCC2. As MCC4 also has the same Synchronisation Identity as MCC1 and MCC2 the content of the audio Encoding will be synchronised with the video content. 7.2.1.4. Allow Subset Choice The Allow Subset Choice MCC attribute is a boolean value, indicating whether or not the Provider allows the Consumer to choose a specific subset of the Captures referenced by the MCC. If this attribute is true, and the MCC references other Captures, then the Consumer MAY select (in a Configure message) a specific subset of those Captures to be included in the MCC, and the Provider MUST then include only that subset. If this attribute is false, or the MCC does not reference other Captures, then the Consumer MUST NOT select a subset. 7.3. Capture Scene In order for a Provider's individual Captures to be used effectively by a Consumer, the Provider organizes the Captures into one or more Capture Scenes, with the structure and contents of these Capture Scenes being sent from the Provider to the Consumer in the Advertisement. A Capture Scene is a structure representing a spatial region containing one or more Capture Devices, each capturing media representing a portion of the region. A Capture Scene includes one or more Capture Scene Views (CSV), with each CSV including one or more Media Captures of the same media type. There can also be Media Captures that are not included in a Capture Scene View. A Capture Scene represents, for example, the video image of a group of people seated next to each other, along with the sound of their voices, which could be represented by some number of VCs and ACs in the Capture Scene Views. An MCU can also describe in Capture Scenes what it constructs from media Streams it receives. Duckworth et. al. Expires July 8, 2016 [Page 30] Internet-Draft CLUE Telepresence Framework January 2016 A Provider MAY advertise one or more Capture Scenes. What constitutes an entire Capture Scene is up to the Provider. A simple Provider might typically use one Capture Scene for participant media (live video from the room cameras) and another Capture Scene for a computer generated presentation. In more complex systems, the use of additional Capture Scenes is also sensible. For example, a classroom may advertise two Capture Scenes involving live video, one including only the camera capturing the instructor (and associated audio), the other including camera(s) capturing students (and associated audio). A Capture Scene MAY (and typically will) include more than one type of media. For example, a Capture Scene can include several Capture Scene Views for Video Captures, and several Capture Scene Views for Audio Captures. A particular Capture MAY be included in more than one Capture Scene View. A Provider MAY express spatial relationships between Captures that are included in the same Capture Scene. However, there is no spatial relationship between Media Captures from different Capture Scenes. In other words, Capture Scenes each use their own spatial measurement system as outlined above in section 6. A Provider arranges Captures in a Capture Scene to help the Consumer choose which captures it wants to render. The Capture Scene Views in a Capture Scene are different alternatives the Provider is suggesting for representing the Capture Scene. Each Capture Scene View is given an advertisement unique identity. The order of Capture Scene Views within a Capture Scene has no significance. The Media Consumer can choose to receive all Media Captures from one Capture Scene View for each media type (e.g. audio and video), or it can pick and choose Media Captures regardless of how the Provider arranges them in Capture Scene Views. Different Capture Scene Views of the same media type are not necessarily mutually exclusive alternatives. Also note that the presence of multiple Capture Scene Views (with potentially multiple encoding options in each view) in a given Capture Scene does not necessarily imply that a Provider is able to serve all the associated media simultaneously (although the construction of such an over-rich Capture Scene is probably not sensible in many cases). What a Provider can send simultaneously is determined through the Simultaneous Transmission Set mechanism, described in section 8. Captures within the same Capture Scene View MUST be of the same media type - it is not possible to mix audio and video captures in Duckworth et. al. Expires July 8, 2016 [Page 31] Internet-Draft CLUE Telepresence Framework January 2016 the same Capture Scene View, for instance. The Provider MUST be capable of encoding and sending all Captures (that have an encoding group) in a single Capture Scene View simultaneously. The order of Captures within a Capture Scene View has no significance. A Consumer can decide to receive all the Captures in a single Capture Scene View, but a Consumer could also decide to receive just a subset of those captures. A Consumer can also decide to receive Captures from different Capture Scene Views, all subject to the constraints set by Simultaneous Transmission Sets, as discussed in section 8. When a Provider advertises a Capture Scene with multiple CSVs, it is essentially signaling that there are multiple representations of the same Capture Scene available. In some cases, these multiple views would be used simultaneously (for instance a "video view" and an "audio view"). In some cases the views would conceptually be alternatives (for instance a view consisting of three Video Captures covering the whole room versus a view consisting of just a single Video Capture covering only the center of a room). In this latter example, one sensible choice for a Consumer would be to indicate (through its Configure and possibly through an additional offer/answer exchange) the Captures of that Capture Scene View that most closely matched the Consumer's number of display devices or screen layout. The following is an example of 4 potential Capture Scene Views for an endpoint-style Provider: 1. (VC0, VC1, VC2) - left, center and right camera Video Captures 2. (MCC3) - Video Capture associated with loudest room segment 3. (VC4) - Video Capture zoomed out view of all people in the room 4. (AC0) - main audio The first view in this Capture Scene example is a list of Video Captures which have a spatial relationship to each other. Determination of the order of these captures (VC0, VC1 and VC2) for rendering purposes is accomplished through use of their Area of Capture attributes. The second view (MCC3) and the third view (VC4) are alternative representations of the same room's video, which might be better suited to some Consumers' rendering capabilities. The inclusion of the Audio Capture in the same Capture Scene indicates that AC0 is associated with all of those Duckworth et. al. Expires July 8, 2016 [Page 32] Internet-Draft CLUE Telepresence Framework January 2016 Video Captures, meaning it comes from the same spatial region. Therefore, if audio were to be rendered at all, this audio would be the correct choice irrespective of which Video Captures were chosen. 7.3.1. Capture Scene attributes Capture Scene Attributes can be applied to Capture Scenes as well as to individual media captures. Attributes specified at this level apply to all constituent Captures. Capture Scene attributes include . Human-readable description of the Capture Scene, which could be in multiple languages; . xCard scene information . Scale information (millimeters, unknown, no scale), as described in Section 6. 7.3.1.1. Scene Information The Scene information attribute provides information regarding the Capture Scene rather than individual participants. The Provider may gather the information automatically or manually from a variety of sources. The scene information attribute allows a Provider to indicate information such as: organizational or geographic information allowing a Consumer to determine which Capture Scenes are of interest in order to then perform Capture selection. It also allows a Consumer to render information regarding the Scene or to use it for further processing. As per 7.1.1.10. the xCard format is used to convey this information and the Provider may supply a minimal set of information or a larger set of information. In order to keep CLUE messages compact the Provider SHOULD use a URI to point to any LOGO, PHOTO or SOUND contained in the xCARD rather than transmitting the LOGO, PHOTO or SOUND data in a CLUE message. 7.3.2. Capture Scene View attributes A Capture Scene can include one or more Capture Scene Views in addition to the Capture Scene wide attributes described above. Capture Scene View attributes apply to the Capture Scene View as a Duckworth et. al. Expires July 8, 2016 [Page 33] Internet-Draft CLUE Telepresence Framework January 2016 whole, i.e. to all Captures that are part of the Capture Scene View. Capture Scene View attributes include: . Human-readable description (which could be in multiple languages) of the Capture Scene View 7.4. Global View List An Advertisement can include an optional Global View list. Each item in this list is a Global View. The Provider can include multiple Global Views, to allow a Consumer to choose sets of captures appropriate to its capabilities or application. The choice of how to make these suggestions in the Global View list for what represents all the scenes for which the Provider can send media is up to the Provider. This is very similar to how each CSV represents a particular scene. As an example, suppose an advertisement has three scenes, and each scene has three CSVs, ranging from one to three video captures in each CSV. The Provider is advertising a total of nine video Captures across three scenes. The Provider can use the Global View list to suggest alternatives for Consumers that can't receive all nine video Captures as separate media streams. For accommodating a Consumer that wants to receive three video Captures, a Provider might suggest a Global View containing just a single CSV with three Captures and nothing from the other two scenes. Or a Provider might suggest a Global View containing three different CSVs, one from each scene, with a single video Capture in each. Some additional rules: . The ordering of Global Views in the Global View list is insignificant. . The ordering of CSVs within each Global View is insignificant. . A particular CSV may be used in multiple Global Views. . The Provider must be capable of encoding and sending all Captures within the CSVs of a given Global View simultaneously. The following figure shows an example of the structure of Global Views in a Global View List. Duckworth et. al. Expires July 8, 2016 [Page 34] Internet-Draft CLUE Telepresence Framework January 2016 ........................................................ . Advertisement . . . . +--------------+ +-------------------------+ . . |Scene 1 | |Global View List | . . | | | | . . | CSV1 (v)<----------------- Global View (CSV 1) | . . | <-------. | | . . | | *--------- Global View (CSV 1,5) | . . | CSV2 (v) | | | | . . | | | | | . . | CSV3 (v)<---------*------- Global View (CSV 3,5) | . . | | | | | | . . | CSV4 (a)<----------------- Global View (CSV 4) | . . | <-----------. | | . . +--------------+ | | *----- Global View (CSV 4,6) | . . | | | | | . . +--------------+ | | | +-------------------------+ . . |Scene 2 | | | | . . | | | | | . . | CSV5 (v)<-------' | | . . | <---------' | . . | | | (v) = video . . | CSV6 (a)<-----------' (a) = audio . . | | . . +--------------+ . `......................................................' Figure 3: Global View List Structure 8. Simultaneous Transmission Set Constraints In many practical cases, a Provider has constraints or limitations on its ability to send Captures simultaneously. One type of limitation is caused by the physical limitations of capture mechanisms; these constraints are represented by a Simultaneous Transmission Set. The second type of limitation reflects the encoding resources available, such as bandwidth or video encoding throughput (macroblocks/second). This type of constraint is captured by Individual Encodings and Encoding Groups, discussed below. Some Endpoints or MCUs can send multiple Captures simultaneously; however sometimes there are constraints that limit which Captures can be sent simultaneously with other Captures. A device may not Duckworth et. al. Expires July 8, 2016 [Page 35] Internet-Draft CLUE Telepresence Framework January 2016 be able to be used in different ways at the same time. Provider Advertisements are made so that the Consumer can choose one of several possible mutually exclusive usages of the device. This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each media type in the Advertisement. This is easier to show in an example. Consider the example of a room system where there are three cameras each of which can send a separate Capture covering two persons each- VC0, VC1, VC2. The middle camera can also zoom out (using an optical zoom lens) and show all six persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where two participants sit or the whole six seats, but not both at the same time. As a result, VC1 and VC3 cannot be sent simultaneously. Simultaneous Transmission Sets are expressed as sets of the Media Captures that the Provider could transmit at the same time (though, in some cases, it is not intuitive to do so). If a Multiple Content Capture is included in a Simultaneous Transmission Set it indicates that the Capture Encoding associated with it could be transmitted as the same time as the other Captures within the Simultaneous Transmission Set. It does not imply that the Single Media Captures contained in the Multiple Content Capture could all be transmitted at the same time. In this example the two Simultaneous Transmission Sets are shown in Table 5. If a Provider advertises one or more mutually exclusive Simultaneous Transmission Sets, then for each media type the Consumer MUST ensure that it chooses Media Captures that lie wholly within one of those Simultaneous Transmission Sets. +-------------------+ | Simultaneous Sets | +-------------------+ | {VC0, VC1, VC2} | | {VC0, VC3, VC2} | +-------------------+ Table 5: Two Simultaneous Transmission Sets A Provider OPTIONALLY can include the Simultaneous Transmission Sets in its Advertisement. These constraints apply across all the Duckworth et. al. Expires July 8, 2016 [Page 36] Internet-Draft CLUE Telepresence Framework January 2016 Capture Scenes in the Advertisement. It is a syntax conformance requirement that the Simultaneous Transmission Sets MUST allow all the media Captures in any particular Capture Scene View to be used simultaneously. Similarly, the Simultaneous Transmission Sets MUST reflect the simultaneity expressed by any Global View. For shorthand convenience, a Provider MAY describe a Simultaneous Transmission Set in terms of Capture Scene Views and Capture Scenes. If a Capture Scene View is included in a Simultaneous Transmission Set, then all Media Captures in the Capture Scene View are included in the Simultaneous Transmission Set. If a Capture Scene is included in a Simultaneous Transmission Set, then all its Capture Scene Views (of the corresponding media type) are included in the Simultaneous Transmission Set. The end result reduces to a set of Media Captures, of a particular media type, in either case. If an Advertisement does not include Simultaneous Transmission Sets, then the Provider MUST be able to simultaneously provide all the Captures from any one CSV of each media type from each Capture Scene. Likewise, if there are no Simultaneous Transmission Sets and there is a Global View list, then the Provider MUST be able to simultaneously provide all the Captures from any particular Global View (of each media type) from the Global View list. If an Advertisement includes multiple Capture Scene Views in a Capture Scene then the Consumer MAY choose one Capture Scene View for each media type, or MAY choose individual Captures based on the Simultaneous Transmission Sets. 9. Encodings Individual encodings and encoding groups are CLUE's mechanisms allowing a Provider to signal its limitations for sending Captures, or combinations of Captures, to a Consumer. Consumers can map the Captures they want to receive onto the Encodings, with the encoding parameters they want. As for the relationship between the CLUE- specified mechanisms based on Encodings and the SIP offer/answer exchange, please refer to section 5. 9.1. Individual Encodings An Individual Encoding represents a way to encode a Media Capture as a Capture Encoding, to be sent as an encoded media stream from the Provider to the Consumer. An Individual Encoding has a set of parameters characterizing how the media is encoded. Duckworth et. al. Expires July 8, 2016 [Page 37] Internet-Draft CLUE Telepresence Framework January 2016 Different media types have different parameters, and different encoding algorithms may have different parameters. An Individual Encoding can be assigned to at most one Capture Encoding at any given time. Individual Encoding parameters are represented in SDP [RFC4566], not in CLUE messages. For example, for a video encoding using H.26x compression technologies, this can include parameters such as: . Maximum bandwidth; . Maximum picture size in pixels; . Maximum number of pixels to be processed per second; The bandwidth parameter is the only one that specifically relates to a CLUE Advertisement, as it can be further constrained by the maximum group bandwidth in an Encoding Group. 9.2. Encoding Group An Encoding Group includes a set of one or more Individual Encodings, and parameters that apply to the group as a whole. By grouping multiple individual Encodings together, an Encoding Group describes additional constraints on bandwidth for the group. A single Encoding Group MAY refer to Encodings for different media types. The Encoding Group data structure contains: . Maximum bitrate for all encodings in the group combined; . A list of identifiers for the Individual Encodings belonging to the group. When the Individual Encodings in a group are instantiated into Capture Encodings, each Capture Encoding has a bitrate that MUST be less than or equal to the max bitrate for the particular Individual Encoding. The "maximum bitrate for all encodings in the group" parameter gives the additional restriction that the sum of all the individual Capture Encoding bitrates MUST be less than or equal to this group value. The following diagram illustrates one example of the structure of a media Provider's Encoding Groups and their contents. Duckworth et. al. Expires July 8, 2016 [Page 38] Internet-Draft CLUE Telepresence Framework January 2016 ,-------------------------------------------------. | Media Provider | | | | ,--------------------------------------. | | | ,--------------------------------------. | | | | ,--------------------------------------. | | | | | Encoding Group | | | | | | ,-----------. | | | | | | | | ,---------. | | | | | | | | | | ,---------.| | | | | | | Encoding1 | |Encoding2| |Encoding3|| | | `.| | | | | | `---------'| | | `.| `-----------' `---------' | | | `--------------------------------------' | `-------------------------------------------------' Figure 4: Encoding Group Structure A Provider advertises one or more Encoding Groups. Each Encoding Group includes one or more Individual Encodings. Each Individual Encoding can represent a different way of encoding media. For example one Individual Encoding may be 1080p60 video, another could be 720p30, with a third being CIF, all in, for example, H.264 format. While a typical three codec/display system might have one Encoding Group per "codec box" (physical codec, connected to one camera and one screen), there are many possibilities for the number of Encoding Groups a Provider may be able to offer and for the encoding values in each Encoding Group. There is no requirement for all Encodings within an Encoding Group to be instantiated at the same time. 9.3. Associating Captures with Encoding Groups Each Media Capture, including MCCs, MAY be associated with one Encoding Group. To be eligible for configuration, a Media Capture MUST be associated with one Encoding Group, which is used to instantiate that Capture into a Capture Encoding. When an MCC is configured all the Media Captures referenced by the MCC will appear in the Capture Encoding according to the attributes of the chosen encoding of the MCC. This allows an Advertiser to specify encoding attributes associated with the Media Captures without the need to provide an individual Capture Encoding for each of the inputs. Duckworth et. al. Expires July 8, 2016 [Page 39] Internet-Draft CLUE Telepresence Framework January 2016 If an Encoding Group is assigned to a Media Capture referenced by the MCC it indicates that this Capture may also have an individual Capture Encoding. For example: +--------------------+------------------------------------+ | Capture Scene #1 | | +--------------------+------------------------------------+ | VC1 | EncodeGroupID=1 | | VC2 | | | MCC1(VC1,VC2) | EncodeGroupID=2 | | CSV(VC1) | | | CSV(MCC1) | | +--------------------+------------------------------------+ Table 6: Example usage of Encoding with MCC and source Captures This would indicate that VC1 may be sent as its own Capture Encoding from EncodeGroupID=1 or that it may be sent as part of a Capture Encoding from EncodeGroupID=2 along with VC2. More than one Capture MAY use the same Encoding Group. The maximum number of Capture Encodings that can result from a particular Encoding Group constraint is equal to the number of individual Encodings in the group. The actual number of Capture Encodings used at any time MAY be less than this maximum. Any of the Captures that use a particular Encoding Group can be encoded according to any of the Individual Encodings in the group. It is a protocol conformance requirement that the Encoding Groups MUST allow all the Captures in a particular Capture Scene View to be used simultaneously. 10. Consumer's Choice of Streams to Receive from the Provider After receiving the Provider's Advertisement message (that includes media captures and associated constraints), the Consumer composes its reply to the Provider in the form of a Configure message. The Consumer is free to use the information in the Advertisement as it chooses, but there are a few obviously sensible design choices, which are outlined below. Duckworth et. al. Expires July 8, 2016 [Page 40] Internet-Draft CLUE Telepresence Framework January 2016 If multiple Providers connect to the same Consumer (i.e. in an MCU- less multiparty call), it is the responsibility of the Consumer to compose Configures for each Provider that both fulfill each Provider's constraints as expressed in the Advertisement, as well as its own capabilities. In an MCU-based multiparty call, the MCU can logically terminate the Advertisement/Configure negotiation in that it can hide the characteristics of the receiving endpoint and rely on its own capabilities (transcoding/transrating/...) to create Media Streams that can be decoded at the Endpoint Consumers. The timing of an MCU's sending of Advertisements (for its outgoing ports) and Configures (for its incoming ports, in response to Advertisements received there) is up to the MCU and implementation dependent. As a general outline, a Consumer can choose, based on the Advertisement it has received, which Captures it wishes to receive, and which Individual Encodings it wants the Provider to use to encode the Captures. On receipt of an Advertisement with an MCC the Consumer treats the MCC as per other non-MCC Captures with the following differences: - The Consumer would understand that the MCC is a Capture that includes the referenced individual Captures (or any Captures, if none are referenced) and that these individual Captures are delivered as part of the MCC's Capture Encoding. - The Consumer may utilise any of the attributes associated with the referenced individual Captures and any Capture Scene attributes from where the individual Captures were defined to choose Captures and for rendering decisions. - If the MCC attribute Allow Subset Choice is true, then the Consumer may or may not choose to receive all the indicated Captures. It can choose to receive a sub-set of Captures indicated by the MCC. For example if the Consumer receives: MCC1(VC1,VC2,VC3){attributes} A Consumer could choose all the Captures within a MCC however if the Consumer determines that it doesn't want VC3 it can return MCC1(VC1,VC2). If it wants all the individual Captures then it Duckworth et. al. Expires July 8, 2016 [Page 41] Internet-Draft CLUE Telepresence Framework January 2016 returns only the MCC identity (i.e. MCC1). If the MCC in the advertisement does not reference any individual captures, or the Allow Subset Choice attribute is false, then the Consumer cannot choose what is included in the MCC, it is up to the Provider to decide. A Configure Message includes a list of Capture Encodings. These are the Capture Encodings the Consumer wishes to receive from the Provider. Each Capture Encoding refers to one Media Capture and one Individual Encoding. For each Capture the Consumer wants to receive, it configures one of the Encodings in that Capture's Encoding Group. The Consumer does this by telling the Provider, in its Configure Message, which Encoding to use for each chosen Capture. Upon receipt of this Configure from the Consumer, common knowledge is established between Provider and Consumer regarding sensible choices for the media streams. The setup of the actual media channels, at least in the simplest case, is left to a following offer/answer exchange. Optimized implementations may speed up the reaction to the offer/answer exchange by reserving the resources at the time of finalization of the CLUE handshake. CLUE advertisements and configure messages don't necessarily require a new SDP offer/answer for every CLUE message exchange. But the resulting encodings sent via RTP must conform to the most recent SDP offer/answer result. In order to meaningfully create and send an initial Configure, the Consumer needs to have received at least one Advertisement, and an SDP offer defining the Individual Encodings, from the Provider. In addition, the Consumer can send a Configure at any time during the call. The Configure MUST be valid according to the most recently received Advertisement. The Consumer can send a Configure either in response to a new Advertisement from the Provider or on its own, for example because of a local change in conditions (people leaving the room, connectivity changes, multipoint related considerations). When choosing which Media Streams to receive from the Provider, and the encoding characteristics of those Media Streams, the Consumer advantageously takes several things into account: its local preference, simultaneity restrictions, and encoding limits. Duckworth et. al. Expires July 8, 2016 [Page 42] Internet-Draft CLUE Telepresence Framework January 2016 10.1. Local preference A variety of local factors influence the Consumer's choice of Media Streams to be received from the Provider: o if the Consumer is an Endpoint, it is likely that it would choose, where possible, to receive video and audio Captures that match the number of display devices and audio system it has o if the Consumer is an MCU, it may choose to receive loudest speaker streams (in order to perform its own media composition) and avoid pre-composed video Captures o user choice (for instance, selection of a new layout) may result in a different set of Captures, or different encoding characteristics, being required by the Consumer 10.2. Physical simultaneity restrictions Often there are physical simultaneity constraints of the Provider that affect the Provider's ability to simultaneously send all of the captures the Consumer would wish to receive. For instance, an MCU, when connected to a multi-camera room system, might prefer to receive both individual video streams of the people present in the room and an overall view of the room from a single camera. Some Endpoint systems might be able to provide both of these sets of streams simultaneously, whereas others might not (if the overall room view were produced by changing the optical zoom level on the center camera, for instance). 10.3. Encoding and encoding group limits Each of the Provider's encoding groups has limits on bandwidth, and the constituent potential encodings have limits on the bandwidth, computational complexity, video frame rate, and resolution that can be provided. When choosing the Captures to be received from a Provider, a Consumer device MUST ensure that the encoding characteristics requested for each individual Capture fits within the capability of the encoding it is being configured to use, as well as ensuring that the combined encoding characteristics for Captures fit within the capabilities of their associated encoding groups. In some cases, this could cause an otherwise "preferred" choice of capture encodings to be passed over in favor of different Capture Encodings--for instance, if a set of three Captures could only be provided at a low resolution Duckworth et. al. Expires July 8, 2016 [Page 43] Internet-Draft CLUE Telepresence Framework January 2016 then a three screen device could switch to favoring a single, higher quality, Capture Encoding. 11. Extensibility One important characteristics of the Framework is its extensibility. The standard for interoperability and handling multiple streams must be future-proof. The framework itself is inherently extensible through expanding the data model types. For example: o Adding more types of media, such as telemetry, can done by defining additional types of Captures in addition to audio and video. o Adding new functionalities, such as 3-D video Captures, say, may require additional attributes describing the Captures. The infrastructure is designed to be extended rather than requiring new infrastructure elements. Extension comes through adding to defined types. 12. Examples - Using the Framework (Informative) This section gives some examples, first from the point of view of the Provider, then the Consumer, then some multipoint scenarios 12.1. Provider Behavior This section shows some examples in more detail of how a Provider can use the framework to represent a typical case for telepresence rooms. First an endpoint is illustrated, then an MCU case is shown. 12.1.1. Three screen Endpoint Provider Consider an Endpoint with the following description: 3 cameras, 3 displays, a 6 person table o Each camera can provide one Capture for each 1/3 section of the table Duckworth et. al. Expires July 8, 2016 [Page 44] Internet-Draft CLUE Telepresence Framework January 2016 o A single Capture representing the active speaker can be provided (voice activity based camera selection to a given encoder input port implemented locally in the Endpoint) o A single Capture representing the active speaker with the other 2 Captures shown picture in picture (PiP) within the stream can be provided (again, implemented inside the endpoint) o A Capture showing a zoomed out view of all 6 seats in the room can be provided The video and audio Captures for this Endpoint can be described as follows. Video Captures: o VC0- (the left camera stream), encoding group=EG0, view=table o VC1- (the center camera stream), encoding group=EG1, view=table o VC2- (the right camera stream), encoding group=EG2, view=table o MCC3- (the loudest panel stream), encoding group=EG1, view=table, MaxCaptures=1, policy=SoundLevel o MCC4- (the loudest panel stream with PiPs), encoding group=EG1, view=room, MaxCaptures=3, policy=SoundLevel o VC5- (the zoomed out view of all people in the room), encoding group=EG1, view=room o VC6- (presentation stream), encoding group=EG1, presentation The following diagram is a top view of the room with 3 cameras, 3 displays, and 6 seats. Each camera captures 2 people. The six seats are not all in a straight line. Duckworth et. al. Expires July 8, 2016 [Page 45] Internet-Draft CLUE Telepresence Framework January 2016 ,-. d ( )`--.__ +---+ `-' / `--.__ | | ,-. | `-.._ |_-+Camera 2 (VC2) ( ).' <--(AC1)-+-''`+-+ `-' |_...---'' | | ,-.c+-..__ +---+ ( )| ``--..__ | | `-' | ``+-..|_-+Camera 1 (VC1) ,-. | <--(AC2)..--'|+-+ ^ ( )| __..--' | | | `-'b|..--' +---+ |X ,-. |``---..___ | | | ( )\ ```--..._|_-+Camera 0 (VC0) | `-' \ <--(AC0) ..-''`-+ | ,-. \ __.--'' | | <----------+ ( ) |..-'' +---+ Y `-' a (0,0,0) origin is under Camera 1 Figure 5: Room Layout Top View Duckworth et. al. Expires July 8, 2016 [Page 46] Internet-Draft CLUE Telepresence Framework January 2016 The two points labeled b and c are intended to be at the midpoint between the seating positions, and where the fields of view of the cameras intersect. The plane of interest for VC0 is a vertical plane that intersects points 'a' and 'b'. The plane of interest for VC1 intersects points 'b' and 'c'. The plane of interest for VC2 intersects points 'c' and 'd'. This example uses an area scale of millimeters. Areas of capture: bottom left bottom right top left top right VC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-673,3000,757) VC1 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 673,3000,757) VC2 ( 673,3000,0) (2011,2850,0) ( 673,3000,757) (2011,3000,757) MCC3(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) MCC4(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) VC5 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) VC6 none Points of capture: VC0 (-1678,0,800) VC1 (0,0,800) VC2 (1678,0,800) MCC3 none MCC4 none VC5 (0,0,800) VC6 none In this example, the right edge of the VC0 area lines up with the left edge of the VC1 area. It doesn't have to be this way. There could be a gap or an overlap. One additional thing to note for this example is the distance from a to b is equal to the distance from b to c and the distance from c to d. All these distances are 1346 mm. This is the planar width of each area of capture for VC0, VC1, and VC2. Note the text in parentheses (e.g. "the left camera stream") is not explicitly part of the model, it is just explanatory text for this example, and is not included in the model with the media Duckworth et. al. Expires July 8, 2016 [Page 47] Internet-Draft CLUE Telepresence Framework January 2016 captures and attributes. Also, MCC4 doesn't say anything about how a capture is composed, so the media consumer can't tell based on this capture that MCC4 is composed of a "loudest panel with PiPs". Audio Captures: Three ceiling microphones are located between the cameras and the table, at the same height as the cameras. The microphones point down at an angle toward the seating positions. o AC0 (left), encoding group=EG3 o AC1 (right), encoding group=EG3 o AC2 (center) encoding group=EG3 o AC3 being a simple pre-mixed audio stream from the room (mono), encoding group=EG3 o AC4 audio stream associated with the presentation video (mono) encoding group=EG3, presentation Point of capture: Point on Line of Capture: AC0 (-1342,2000,800) (-1342,2925,379) AC1 ( 1342,2000,800) ( 1342,2925,379) AC2 ( 0,2000,800) ( 0,3000,379) AC3 ( 0,2000,800) ( 0,3000,379) AC4 none The physical simultaneity information is: Simultaneous transmission set #1 {VC0, VC1, VC2, MCC3, MCC4, VC6} Simultaneous transmission set #2 {VC0, VC2, VC5, VC6} This constraint indicates it is not possible to use all the VCs at the same time. VC5 cannot be used at the same time as VC1 or MCC3 or MCC4. Also, using every member in the set simultaneously may not make sense - for example MCC3(loudest) and MCC4 (loudest with PiP). In addition, there are encoding constraints that make choosing all of the VCs in a set impossible. VC1, MCC3, MCC4, VC5, VC6 all use EG1 and EG1 has only 3 ENCs. This constraint Duckworth et. al. Expires July 8, 2016 [Page 48] Internet-Draft CLUE Telepresence Framework January 2016 shows up in the encoding groups, not in the simultaneous transmission sets. In this example there are no restrictions on which Audio Captures can be sent simultaneously. Encoding Groups: This example has three encoding groups associated with the video captures. Each group can have 3 encodings, but with each potential encoding having a progressively lower specification. In this example, 1080p60 transmission is possible (as ENC0 has a maxPps value compatible with that). Significantly, as up to 3 encodings are available per group, it is possible to transmit some video Captures simultaneously that are not in the same view in the Capture Scene. For example VC1 and MCC3 at the same time. The information below about Encodings is a summary of what would be conveyed in SDP, not directly in the CLUE Advertisement. encodeGroupID=EG0, maxGroupBandwidth=6000000 encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=124416000, maxBandwidth=4000000 encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30, maxPps=27648000, maxBandwidth=4000000 encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30, maxPps=15552000, maxBandwidth=4000000 encodeGroupID=EG1 maxGroupBandwidth=6000000 encodeID=ENC3, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=124416000, maxBandwidth=4000000 encodeID=ENC4, maxWidth=1280, maxHeight=720, maxFrameRate=30, maxPps=27648000, maxBandwidth=4000000 encodeID=ENC5, maxWidth=960, maxHeight=544, maxFrameRate=30, maxPps=15552000, maxBandwidth=4000000 encodeGroupID=EG2 maxGroupBandwidth=6000000 encodeID=ENC6, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=124416000, maxBandwidth=4000000 encodeID=ENC7, maxWidth=1280, maxHeight=720, maxFrameRate=30, maxPps=27648000, maxBandwidth=4000000 encodeID=ENC8, maxWidth=960, maxHeight=544, maxFrameRate=30, maxPps=15552000, maxBandwidth=4000000 Figure 6: Example Encoding Groups for Video For audio, there are five potential encodings available, so all five Audio Captures can be encoded at the same time. Duckworth et. al. Expires July 8, 2016 [Page 49] Internet-Draft CLUE Telepresence Framework January 2016 encodeGroupID=EG3, maxGroupBandwidth=320000 encodeID=ENC9, maxBandwidth=64000 encodeID=ENC10, maxBandwidth=64000 encodeID=ENC11, maxBandwidth=64000 encodeID=ENC12, maxBandwidth=64000 encodeID=ENC13, maxBandwidth=64000 Figure 7: Example Encoding Group for Audio Capture Scenes: The following table represents the Capture Scenes for this Provider. Recall that a Capture Scene is composed of alternative Capture Scene Views covering the same spatial region. Capture Scene #1 is for the main people captures, and Capture Scene #2 is for presentation. Each row in the table is a separate Capture Scene View +------------------+ | Capture Scene #1 | +------------------+ | VC0, VC1, VC2 | | MCC3 | | MCC4 | | VC5 | | AC0, AC1, AC2 | | AC3 | +------------------+ +------------------+ | Capture Scene #2 | +------------------+ | VC6 | | AC4 | +------------------+ Table 7: Example Capture Scene Views Different Capture Scenes are distinct from each other, and are non-overlapping. A Consumer can choose a view from each Capture Scene. In this case the three Captures VC0, VC1, and VC2 are one way of representing the video from the Endpoint. These three Captures should appear adjacent next to each other. Alternatively, another way of representing the Capture Scene is Duckworth et. al. Expires July 8, 2016 [Page 50] Internet-Draft CLUE Telepresence Framework January 2016 with the capture MCC3, which automatically shows the person who is talking. Similarly for the MCC4 and VC5 alternatives. As in the video case, the different views of audio in Capture Scene #1 represent the "same thing", in that one way to receive the audio is with the 3 Audio Captures (AC0, AC1, AC2), and another way is with the mixed AC3. The Media Consumer can choose an audio CSV it is capable of receiving. The spatial ordering is understood by the Media Capture attributes Area of Capture, Point of Capture and Point on Line of Capture. A Media Consumer would likely want to choose a Capture Scene View to receive based in part on how many streams it can simultaneously receive. A consumer that can receive three video streams would probably prefer to receive the first view of Capture Scene #1 (VC0, VC1, VC2) and not receive the other views. A consumer that can receive only one video stream would probably choose one of the other views. If the consumer can receive a presentation stream too, it would also choose to receive the only view from Capture Scene #2 (VC6). 12.1.2. Encoding Group Example This is an example of an Encoding Group to illustrate how it can express dependencies between Encodings. The information below about Encodings is a summary of what would be conveyed in SDP, not directly in the CLUE Advertisement. encodeGroupID=EG0 maxGroupBandwidth=6000000 encodeID=VIDENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeID=VIDENC1, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeID=AUDENC0, maxBandwidth=96000 encodeID=AUDENC1, maxBandwidth=96000 encodeID=AUDENC2, maxBandwidth=96000 Here, the Encoding Group is EG0. Although the Encoding Group is capable of transmitting up to 6Mbit/s, no individual video Encoding can exceed 4Mbit/s. This encoding group also allows up to 3 audio encodings, AUDENC<0- 2>. It is not required that audio and video encodings reside Duckworth et. al. Expires July 8, 2016 [Page 51] Internet-Draft CLUE Telepresence Framework January 2016 within the same encoding group, but if so then the group's overall maxBandwidth value is a limit on the sum of all audio and video encodings configured by the consumer. A system that does not wish or need to combine bandwidth limitations in this way should instead use separate encoding groups for audio and video in order for the bandwidth limitations on audio and video to not interact. Audio and video can be expressed in separate encoding groups, as in this illustration. encodeGroupID=EG0 maxGroupBandwidth=6000000 encodeID=VIDENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeID=VIDENC1, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeGroupID=EG1 maxGroupBandwidth=500000 encodeID=AUDENC0, maxBandwidth=96000 encodeID=AUDENC1, maxBandwidth=96000 encodeID=AUDENC2, maxBandwidth=96000 12.1.3. The MCU Case This section shows how an MCU might express its Capture Scenes, intending to offer different choices for consumers that can handle different numbers of streams. Each MCC is for video. A single Audio Capture is provided for all single and multi-screen configurations that can be associated (e.g. lip-synced) with any combination of Video Captures (the MCCs) at the consumer. +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | MCC | for a single screen consumer | | MCC1, MCC2 | for a two screen consumer | | MCC3, MCC4, MCC5 | for a three screen consumer | | MCC6, MCC7, MCC8, MCC9| for a four screen consumer | | AC0 | AC representing all participants| | CSV(MCC0) | | | CSV(MCC1,MCC2) | | | CSV(MCC3,MCC4,MCC5) | | | CSV(MCC6,MCC7, | | | MCC8,MCC9) | | | CSV(AC0) | | +-----------------------+---------------------------------+ Duckworth et. al. Expires July 8, 2016 [Page 52] Internet-Draft CLUE Telepresence Framework January 2016 Table 8: MCU main Capture Scenes If / when a presentation stream becomes active within the conference the MCU might re-advertise the available media as: +------------------+--------------------------------------+ | Capture Scene #2 | note | +------------------+--------------------------------------+ | VC10 | video capture for presentation | | AC1 | presentation audio to accompany VC10 | | CSV(VC10) | | | CSV(AC1) | | +------------------+--------------------------------------+ Table 9: MCU presentation Capture Scene 12.2. Media Consumer Behavior This section gives an example of how a Media Consumer might behave when deciding how to request streams from the three screen endpoint described in the previous section. The receive side of a call needs to balance its requirements, based on number of screens and speakers, its decoding capabilities and available bandwidth, and the provider's capabilities in order to optimally configure the provider's streams. Typically it would want to receive and decode media from each Capture Scene advertised by the Provider. A sane, basic, algorithm might be for the consumer to go through each Capture Scene View in turn and find the collection of Video Captures that best matches the number of screens it has (this might include consideration of screens dedicated to presentation video display rather than "people" video) and then decide between alternative views in the video Capture Scenes based either on hard-coded preferences or user choice. Once this choice has been made, the consumer would then decide how to configure the provider's encoding groups in order to make best use of the available network bandwidth and its own decoding capabilities. 12.2.1. One screen Media Consumer MCC3, MCC4 and VC5 are all different views by themselves, not grouped together in a single view, so the receiving device should choose between one of those. The choice would come down to Duckworth et. al. Expires July 8, 2016 [Page 53] Internet-Draft CLUE Telepresence Framework January 2016 whether to see the greatest number of participants simultaneously at roughly equal precedence (VC5), a switched view of just the loudest region (MCC3) or a switched view with PiPs (MCC4). An endpoint device with a small amount of knowledge of these differences could offer a dynamic choice of these options, in- call, to the user. 12.2.2. Two screen Media Consumer configuring the example Mixing systems with an even number of screens, "2n", and those with "2n+1" cameras (and vice versa) is always likely to be the problematic case. In this instance, the behavior is likely to be determined by whether a "2 screen" system is really a "2 decoder" system, i.e., whether only one received stream can be displayed per screen or whether more than 2 streams can be received and spread across the available screen area. To enumerate 3 possible behaviors here for the 2 screen system when it learns that the far end is "ideally" expressed via 3 capture streams: 1. Fall back to receiving just a single stream (MCC3, MCC4 or VC5 as per the 1 screen consumer case above) and either leave one screen blank or use it for presentation if / when a presentation becomes active. 2. Receive 3 streams (VC0, VC1 and VC2) and display across 2 screens (either with each capture being scaled to 2/3 of a screen and the center capture being split across 2 screens) or, as would be necessary if there were large bezels on the screens, with each stream being scaled to 1/2 the screen width and height and there being a 4th "blank" panel. This 4th panel could potentially be used for any presentation that became active during the call. 3. Receive 3 streams, decode all 3, and use control information indicating which was the most active to switch between showing the left and center streams (one per screen) and the center and right streams. For an endpoint capable of all 3 methods of working described above, again it might be appropriate to offer the user the choice of display mode. Duckworth et. al. Expires July 8, 2016 [Page 54] Internet-Draft CLUE Telepresence Framework January 2016 12.2.3. Three screen Media Consumer configuring the example This is the most straightforward case - the Media Consumer would look to identify a set of streams to receive that best matched its available screens and so the VC0 plus VC1 plus VC2 should match optimally. The spatial ordering would give sufficient information for the correct Video Capture to be shown on the correct screen, and the consumer would either need to divide a single encoding group's capability by 3 to determine what resolution and frame rate to configure the provider with or to configure the individual Video Captures' Encoding Groups with what makes most sense (taking into account the receive side decode capabilities, overall call bandwidth, the resolution of the screens plus any user preferences such as motion vs. sharpness). 12.3. Multipoint Conference utilizing Multiple Content Captures The use of MCCs allows the MCU to construct outgoing Advertisements describing complex media switching and composition scenarios. The following sections provide several examples. Note: In the examples the identities of the CLUE elements (e.g. Captures, Capture Scene) in the incoming Advertisements overlap. This is because there is no co-ordination between the endpoints. The MCU is responsible for making these unique in the outgoing advertisement. 12.3.1. Single Media Captures and MCC in the same Advertisement Four endpoints are involved in a Conference where CLUE is used. An MCU acts as a middlebox between the endpoints with a CLUE channel between each endpoint and the MCU. The MCU receives the following Advertisements. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | | EncodeGroupID=1 | | CSV(VC1) | | +---------------------------------------------------------+ Table 10: Advertisement received from Endpoint A Duckworth et. al. Expires July 8, 2016 [Page 55] Internet-Draft CLUE Telepresence Framework January 2016 +-----------------------+---------------------------------+ | Capture Scene #1 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Speaker | | | EncodeGroupID=1 | | VC2 | Description=Audience | | | EncodeGroupID=1 | | CSV(VC1, VC2) | | +---------------------------------------------------------+ Table 11: Advertisement received from Endpoint B +-----------------------+---------------------------------+ | Capture Scene #1 | Description=USAConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | | EncodeGroupID=1 | | CSV(VC1) | | +---------------------------------------------------------+ Table 12: Advertisement received from Endpoint C Note: Endpoint B above indicates that it sends two streams. If the MCU wanted to provide a Multiple Content Capture containing a round robin switched view of the audience from the 3 endpoints and the speaker it could construct the following advertisement: Advertisement sent to Endpoint F Duckworth et. al. Expires July 8, 2016 [Page 56] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | CSV(VC1) | | +=======================+=================================+ | Capture Scene #2 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC2 | Description=Speaker | | VC3 | Description=Audience | | CSV(VC2, VC3) | | +=======================+=================================+ | Capture Scene #3 | Description=USAConfRoom | +-----------------------|---------------------------------+ | VC4 | Description=Audience | | CSV(VC4) | | +=======================+=================================+ | Capture Scene #4 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC2,VC3,VC4) | Policy=RoundRobin:1 | | | MaxCaptures=1 | | | EncodingGroup=1 | | CSV(MCC1) | | +=======================+=================================+ Table 13: Advertisement sent to Endpoint F - One Encoding Alternatively if the MCU wanted to provide the speaker as one media stream and the audiences as another it could assign an encoding group to VC2 in Capture Scene 2 and provide a CSV in Capture Scene #4 as per the example below. Advertisement sent to Endpoint F Duckworth et. al. Expires July 8, 2016 [Page 57] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | CSV(VC1) | | +=======================+=================================+ | Capture Scene #2 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC2 | Description=Speaker | | | EncodingGroup=1 | | VC3 | Description=Audience | | CSV(VC2, VC3) | | +=======================+=================================+ | Capture Scene #3 | Description=USAConfRoom | +-----------------------|---------------------------------+ | VC4 | Description=Audience | | CSV(VC4) | | +=======================+=================================+ | Capture Scene #4 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC3,VC4) | Policy=RoundRobin:1 | | | MaxCaptures=1 | | | EncodingGroup=1 | | | AllowSubset=True | | MCC2(VC2) | MaxCaptures=1 | | | EncodingGroup=1 | | CSV2(MCC1,MCC2) | | +=======================+=================================+ Table 14: Advertisement sent to Endpoint F - Two Encodings Therefore a Consumer could choose whether or not to have a separate speaker related stream and could choose which endpoints to see. If it wanted the second stream but not the Australian conference room it could indicate the following captures in the Configure message: +-----------------------+---------------------------------+ | MCC1(VC3,VC4) | Encoding | | VC2 | Encoding | +-----------------------|---------------------------------+ Table 15: MCU case: Consumer Response Duckworth et. al. Expires July 8, 2016 [Page 58] Internet-Draft CLUE Telepresence Framework January 2016 12.3.2. Several MCCs in the same Advertisement Multiple MCCs can be used where multiple streams are used to carry media from multiple endpoints. For example: A conference has three endpoints D, E and F. Each end point has three video captures covering the left, middle and right regions of each conference room. The MCU receives the following advertisements from D and E. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | CaptureArea=Left | | | EncodingGroup=1 | | VC2 | CaptureArea=Centre | | | EncodingGroup=1 | | VC3 | CaptureArea=Right | | | EncodingGroup=1 | | CSV(VC1,VC2,VC3) | | +---------------------------------------------------------+ Table 16: Advertisement received from Endpoint D +-----------------------+---------------------------------+ | Capture Scene #1 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC1 | CaptureArea=Left | | | EncodingGroup=1 | | VC2 | CaptureArea=Centre | | | EncodingGroup=1 | | VC3 | CaptureArea=Right | | | EncodingGroup=1 | | CSV(VC1,VC2,VC3) | | +---------------------------------------------------------+ Table 17: Advertisement received from Endpoint E The MCU wants to offer Endpoint F three Capture Encodings. Each Capture Encoding would contain all the Captures from either Endpoint D or Endpoint E depending based on the active speaker. The MCU sends the following Advertisement: Duckworth et. al. Expires July 8, 2016 [Page 59] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | | | VC2 | | | VC3 | | | CSV(VC1,VC2,VC3) | | +=======================+=================================+ | Capture Scene #2 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC4 | | | VC5 | | | VC6 | | | CSV(VC4,VC5,VC6) | | +=======================+=================================+ | Capture Scene #3 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC4) | CaptureArea=Left | | | MaxCaptures=1 | | | SynchronisationID=1 | | | EncodingGroup=1 | | MCC2(VC2,VC5) | CaptureArea=Centre | | | MaxCaptures=1 | | | SynchronisationID=1 | | | EncodingGroup=1 | | MCC3(VC3,VC6) | CaptureArea=Right | | | MaxCaptures=1 | | | SynchronisationID=1 | | | EncodingGroup=1 | | CSV(MCC1,MCC2,MCC3) | | +=======================+=================================+ Table 18: Advertisement sent to Endpoint F 12.3.3. Heterogeneous conference with switching and composition Consider a conference between endpoints with the following characteristics: Endpoint A - 4 screens, 3 cameras Endpoint B - 3 screens, 3 cameras Endpoint C - 3 screens, 3 cameras Duckworth et. al. Expires July 8, 2016 [Page 60] Internet-Draft CLUE Telepresence Framework January 2016 Endpoint D - 3 screens, 3 cameras Endpoint E - 1 screen, 1 camera Endpoint F - 2 screens, 1 camera Endpoint G - 1 screen, 1 camera This example focuses on what the user in one of the 3-camera multi- screen endpoints sees. Call this person User A, at Endpoint A. There are 4 large display screens at Endpoint A. Whenever somebody at another site is speaking, all the video captures from that endpoint are shown on the large screens. If the talker is at a 3- camera site, then the video from those 3 cameras fills 3 of the screens. If the talker is at a single-camera site, then video from that camera fills one of the screens, while the other screens show video from other single-camera endpoints. User A hears audio from the 4 loudest talkers. User A can also see video from other endpoints, in addition to the current talker, although much smaller in size. Endpoint A has 4 screens, so one of those screens shows up to 9 other Media Captures in a tiled fashion. When video from a 3 camera endpoint appears in the tiled area, video from all 3 cameras appears together across the screen with correct spatial relationship among those 3 images. +---+---+---+ +-------------+ +-------------+ +-------------+ | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ +-------------+ +-------------+ +-------------+ Figure 8: Endpoint A - 4 Screen Display User B at Endpoint B sees a similar arrangement, except there are only 3 screens, so the 9 other Media Captures are spread out across the bottom of the 3 displays, in a picture-in-picture (PiP) format. When video from a 3 camera endpoint appears in the PiP area, video from all 3 cameras appears together across a single screen with correct spatial relationship. Duckworth et. al. Expires July 8, 2016 [Page 61] Internet-Draft CLUE Telepresence Framework January 2016 +-------------+ +-------------+ +-------------+ | | | | | | | | | | | | | | | | | | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | +-------------+ +-------------+ +-------------+ Figure 9: Endpoint B - 3 Screen Display with PiPs When somebody at a different endpoint becomes the current talker, then User A and User B both see the video from the new talker appear on their large screen area, while the previous talker takes one of the smaller tiled or PiP areas. The person who is the current talker doesn't see themselves; they see the previous talker in their large screen area. One of the points of this example is that endpoints A and B each want to receive 3 capture encodings for their large display areas, and 9 encodings for their smaller areas. A and B are be able to each send the same Configure message to the MCU, and each receive the same conceptual Media Captures from the MCU. The differences are in how they are rendered and are purely a local matter at A and B. The Advertisements for such a scenario are described below. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=Endpoint x | +-----------------------|---------------------------------+ | VC1 | EncodingGroup=1 | | VC2 | EncodingGroup=1 | | VC3 | EncodingGroup=1 | | AC1 | EncodingGroup=2 | | CSV1(VC1, VC2, VC3) | | | CSV2(AC1) | | +---------------------------------------------------------+ Table 19: Advertisement received at the MCU from Endpoints A to D Duckworth et. al. Expires July 8, 2016 [Page 62] Internet-Draft CLUE Telepresence Framework January 2016 +-----------------------+---------------------------------+ | Capture Scene #1 | Description=Endpoint y | +-----------------------|---------------------------------+ | VC1 | EncodingGroup=1 | | AC1 | EncodingGroup=2 | | CSV1(VC1) | | | CSV2(AC1) | | +---------------------------------------------------------+ Table 20: Advertisement received at the MCU from Endpoints E to G Rather than considering what is displayed CLUE concentrates more on what the MCU sends. The MCU doesn't know anything about the number of screens an endpoint has. As Endpoints A to D each advertise that three Captures make up a Capture Scene, the MCU offers these in a "site" switching mode. That is that there are three Multiple Content Captures (and Capture Encodings) each switching between Endpoints. The MCU switches in the applicable media into the stream based on voice activity. Endpoint A will not see a capture from itself. Using the MCC concept the MCU would send the following Advertisement to endpoint A: +=======================+=================================+ | Capture Scene #1 | Description=Endpoint B | +-----------------------|---------------------------------+ | VC4 | CaptureArea=Left | | VC5 | CaptureArea=Center | | VC6 | CaptureArea=Right | | AC1 | | | CSV(VC4,VC5,VC6) | | | CSV(AC1) | | +=======================+=================================+ | Capture Scene #2 | Description=Endpoint C | +-----------------------|---------------------------------+ | VC7 | CaptureArea=Left | | VC8 | CaptureArea=Center | | VC9 | CaptureArea=Right | | AC2 | | | CSV(VC7,VC8,VC9) | | | CSV(AC2) | | +=======================+=================================+ | Capture Scene #3 | Description=Endpoint D | Duckworth et. al. Expires July 8, 2016 [Page 63] Internet-Draft CLUE Telepresence Framework January 2016 +-----------------------|---------------------------------+ | VC10 | CaptureArea=Left | | VC11 | CaptureArea=Center | | VC12 | CaptureArea=Right | | AC3 | | | CSV(VC10,VC11,VC12) | | | CSV(AC3) | | +=======================+=================================+ | Capture Scene #4 | Description=Endpoint E | +-----------------------|---------------------------------+ | VC13 | | | AC4 | | | CSV(VC13) | | | CSV(AC4) | | +=======================+=================================+ | Capture Scene #5 | Description=Endpoint F | +-----------------------|---------------------------------+ | VC14 | | | AC5 | | | CSV(VC14) | | | CSV(AC5) | | +=======================+=================================+ | Capture Scene #6 | Description=Endpoint G | +-----------------------|---------------------------------+ | VC15 | | | AC6 | | | CSV(VC15) | | | CSV(AC6) | | +=======================+=================================+ Table 21: Advertisement sent to endpoint A - Source Part The above part of the Advertisement presents information about the sources to the MCC. The information is effectively the same as the received Advertisements except that there are no Capture Encodings associated with them and the identities have been re-numbered. In addition to the source Capture information the MCU advertises "site" switching of Endpoints B to G in three streams. +=======================+=================================+ | Capture Scene #7 | Description=Output3streammix | +-----------------------|---------------------------------+ | MCC1(VC4,VC7,VC10, | CaptureArea=Left | | VC13) | MaxCaptures=1 | Duckworth et. al. Expires July 8, 2016 [Page 64] Internet-Draft CLUE Telepresence Framework January 2016 | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC2(VC5,VC8,VC11, | CaptureArea=Center | | VC14) | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC3(VC6,VC9,VC12, | CaptureArea=Right | | VC15) | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC4() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=2 | | | | | MCC5() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:1 | | | EncodingGroup=2 | | | | | MCC6() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:2 | | | EncodingGroup=2 | | | | | MCC7() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:3 | | | EncodingGroup=2 | | | | | CSV(MCC1,MCC2,MCC3) | | | CSV(MCC4,MCC5,MCC6, | | | MCC7) | | +=======================+=================================+ Table 22: Advertisement send to endpoint A - switching part The above part describes the switched 3 main streams that relate to site switching. MaxCaptures=1 indicates that only one Capture from Duckworth et. al. Expires July 8, 2016 [Page 65] Internet-Draft CLUE Telepresence Framework January 2016 the MCC is sent at a particular time. SynchronisationID=1 indicates that the source sending is synchronised. The provider can choose to group together VC13, VC14, and VC15 for the purpose of switching according to the SynchronisationID. Therefore when the provider switches one of them into an MCC, it can also switch the others even though they are not part of the same Capture Scene. All the audio for the conference is included in this Scene #7. There isn't necessarily a one to one relation between any audio capture and video capture in this scene. Typically a change in loudest talker will cause the MCU to switch the audio streams more quickly than switching video streams. The MCU can also supply nine media streams showing the active and previous eight speakers. It includes the following in the Advertisement: +=======================+=================================+ | Capture Scene #8 | Description=Output9stream | +-----------------------|---------------------------------+ | MCC8(VC4,VC5,VC6,VC7, | MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:0 | | VC12,VC13,VC14,VC15)| EncodingGroup=1 | | | | | MCC9(VC4,VC5,VC6,VC7, | MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:1 | | VC12,VC13,VC14,VC15)| EncodingGroup=1 | | | | to to | | | | | MCC16(VC4,VC5,VC6,VC7,| MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:8 | | VC12,VC13,VC14,VC15)| EncodingGroup=1 | | | | | CSV(MCC8,MCC9,MCC10, | | | MCC11,MCC12,MCC13,| | | MCC14,MCC15,MCC16)| | +=======================+=================================+ Table 23: Advertisement sent to endpoint A - 9 switched part The above part indicates that there are 9 capture encodings. Each of the Capture Encodings may contain any captures from any source site with a maximum of one Capture at a time. Which Capture is Duckworth et. al. Expires July 8, 2016 [Page 66] Internet-Draft CLUE Telepresence Framework January 2016 present is determined by the policy. The MCCs in this scene do not have any spatial attributes. Note: The Provider alternatively could provide each of the MCCs above in its own Capture Scene. If the MCU wanted to provide a composed Capture Encoding containing all of the 9 captures it could advertise in addition: +=======================+=================================+ | Capture Scene #9 | Description=NineTiles | +-----------------------|---------------------------------+ | MCC13(MCC8,MCC9,MCC10,| MaxCaptures=9 | | MCC11,MCC12,MCC13,| EncodingGroup=1 | | MCC14,MCC15,MCC16)| | | | | | CSV(MCC13) | | +=======================+=================================+ Table 24: Advertisement sent to endpoint A - 9 composed part As MaxCaptures is 9 it indicates that the capture encoding contains information from 9 sources at a time. The Advertisement to Endpoint B is identical to the above other than the captures from Endpoint A would be added and the captures from Endpoint B would be removed. Whether the Captures are rendered on a four screen display or a three screen display is up to the Consumer to determine. The Consumer wants to place video captures from the same original source endpoint together, in the correct spatial order, but the MCCs do not have spatial attributes. So the Consumer needs to associate incoming media packets with the original individual captures in the advertisement (such as VC4, VC5, and VC6) in order to know the spatial information it needs for correct placement on the screens. The Provider can use the RTCP CaptureId SDES item and associated RTP header extension, as described in [I-D.ietf-clue-rtp-mapping], to convey this information to the Consumer. 12.3.4. Heterogeneous conference with voice activated switching This example illustrates how multipoint "voice activated switching" behavior can be realized, with an endpoint making its own decision about which of its outgoing video streams is considered the "active Duckworth et. al. Expires July 8, 2016 [Page 67] Internet-Draft CLUE Telepresence Framework January 2016 talker" from that endpoint. Then an MCU can decide which is the active talker among the whole conference. Consider a conference between endpoints with the following characteristics: Endpoint A - 3 screens, 3 cameras Endpoint B - 3 screens, 3 cameras Endpoint C - 1 screen, 1 camera This example focuses on what the user at endpoint C sees. The user would like to see the video capture of the current talker, without composing it with any other video capture. In this example endpoint C is capable of receiving only a single video stream. The following tables describe advertisements from A and B to the MCU, and from the MCU to C, that can be used to accomplish this. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=Endpoint x | +-----------------------|---------------------------------+ | VC1 | CaptureArea=Left | | | EncodingGroup=1 | | VC2 | CaptureArea=Center | | | EncodingGroup=1 | | VC3 | CaptureArea=Right | | | EncodingGroup=1 | | MCC1(VC1,VC2,VC3) | MaxCaptures=1 | | | CaptureArea=whole scene | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | AC1 | CaptureArea=whole scene | | | EncodingGroup=2 | | CSV1(VC1, VC2, VC3) | | | CSV2(MCC1) | | | CSV3(AC1) | | +---------------------------------------------------------+ Table 25: Advertisement received at the MCU from Endpoints A and B Endpoints A and B are advertising each individual video capture, and also a switched capture MCC1 which switches between the other three based on who is the active talker. These endpoints do not Duckworth et. al. Expires July 8, 2016 [Page 68] Internet-Draft CLUE Telepresence Framework January 2016 advertise distinct audio captures associated with each individual video capture, so it would be impossible for the MCU (as a media consumer) to make its own determination of which video capture is the active talker based just on information in the audio streams. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=conference | +-----------------------|---------------------------------+ | MCC1() | CaptureArea=Left | | | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC2() | CaptureArea=Center | | | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC3() | CaptureArea=Right | | | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC4() | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC5() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=2 | | | | | MCC6() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:1 | | | EncodingGroup=2 | | CSV1(MCC1,MCC2,MCC3 | | | CSV2(MCC4) | | | CSV3(MCC5,MCC6) | | +---------------------------------------------------------+ Duckworth et. al. Expires July 8, 2016 [Page 69] Internet-Draft CLUE Telepresence Framework January 2016 Table 26: Advertisement sent from the MCU to C The MCU advertises one scene, with four video MCCs. Three of them in CSV1 give a left, center, right view of the conference, with "site switching". MCC4 provides a single video capture representing a view of the whole conference. The MCU intends for MCC4 to be switched between all the other original source captures. In this example advertisement the MCU is not giving all the information about all the other endpoints' scenes and which of those captures is included in the MCCs. The MCU could include all that information if it wants to give the consumers more information, but it is not necessary for this example scenario. The Provider advertises MCC5 and MCC6 for audio. Both are switched captures, with different SoundLevel policies indicating they are the top two dominant talkers. The Provider advertises CSV3 with both MCCs, suggesting the Consumer should use both if it can. Endpoint C, in its configure message to the MCU, requests to receive MCC4 for video, and MCC5 and MCC6 for audio. In order for the MCU to get the information it needs to construct MCC4, it has to send configure messages to A and B asking to receive MCC1 from each of them, along with their AC1 audio. Now the MCU can use audio energy information from the two incoming audio streams from A and B to determine which of those alternatives is the current talker. Based on that, the MCU uses either MCC1 from A or MCC1 from B as the source of MCC4 to send to C. 13. Acknowledgements Allyn Romanow and Brian Baldino were authors of early versions. Mark Gorzynski also contributed much to the initial approach. Many others also contributed, including Christian Groves, Jonathan Lennox, Paul Kyzivat, Rob Hansen, Roni Even, Christer Holmberg, Stephen Botzko, Mary Barnes, John Leslie, Paul Coverdale. 14. IANA Considerations None. 15. Security Considerations There are several potential attacks related to telepresence, and specifically the protocols used by CLUE, in the case of Duckworth et. al. Expires July 8, 2016 [Page 70] Internet-Draft CLUE Telepresence Framework January 2016 conferencing sessions, due to the natural involvement of multiple endpoints and the many, often user-invoked, capabilities provided by the systems. An MCU involved in a CLUE session can experience many of the same attacks as that of a conferencing system such as that enabled by the XCON framework [RFC5239]. Examples of attacks include the following: an endpoint attempting to listen to sessions in which it is not authorized to participate, an endpoint attempting to disconnect or mute other users, and theft of service by an endpoint in attempting to create telepresence sessions it is not allowed to create. Thus, it is RECOMMENDED that an MCU implementing the protocols necessary to support CLUE, follow the security recommendations specified in the conference control protocol documents. In the case of CLUE, SIP is the conferencing protocol, thus the security considerations in [RFC4579] MUST be followed. Other security issues related to MCUs are discussed in the XCON framework [RFC5239]. The use of xCard with potentially sensitive information provides another reason to implement recommendations of section 11/[RFC5239]. One primary security concern, surrounding the CLUE framework introduced in this document, involves securing the actual protocols and the associated authorization mechanisms. These concerns apply to endpoint to endpoint sessions, as well as sessions involving multiple endpoints and MCUs. Figure 2 in section 5 provides a basic flow of information exchange for CLUE and the protocols involved. As described in section 5, CLUE uses SIP/SDP to establish the session prior to exchanging any CLUE specific information. Thus the security mechanisms recommended for SIP [RFC3261], including user authentication and authorization, MUST be supported. In addition, the media MUST be secured. DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by other means (see [RFC7201] [RFC7202]). Media security is also discussed in [I-D.ietf-clue-signaling] and [I-D.ietf-clue- rtp-mapping]. Note that SIP call setup is done before any CLUE specific information is available so the authentication and authorization are based on the SIP mechanisms. The entity that will be authenticated may use the Endpoint identity or the endpoint user identity; this is an application issue and not a CLUE specific issue. Duckworth et. al. Expires July 8, 2016 [Page 71] Internet-Draft CLUE Telepresence Framework January 2016 A separate data channel is established to transport the CLUE protocol messages. The contents of the CLUE protocol messages are based on information introduced in this document. The CLUE data model [I-D.ietf-clue-data-model-schema] defines through an XML schema the syntax to be used. Some of the information which could possibly introduce privacy concerns is the xCard information as described in section 7.1.1.10. The decision about which xCard information to send in the CLUE channel is an application policy for point to point and multipoint calls based on the authenticated identity that can be the endpoint identity or the user of the endpoint. For example the telepresence multipoint application can authenticate a user before starting a CLUE exchange with the telepresence system and have a policy per user. In addition, the (text) description field in the Media Capture attribute (section 7.1.1.6) could possibly reveal sensitive information or specific identities. The same would be true for the descriptions in the Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) attributes. An implementation SHOULD give users control over what sensitive information is sent in an Advertisement. One other important consideration for the information in the xCard as well as the description field in the Media Capture and Capture Scene View attributes is that while the endpoints involved in the session have been authenticated, there is no assurance that the information in the xCard or description fields is authentic. Thus, this information MUST NOT be used to make any authorization decisions. While other information in the CLUE protocol messages does not reveal specific identities, it can reveal characteristics and capabilities of the endpoints. That information could possibly uniquely identify specific endpoints. It might also be possible for an attacker to manipulate the information and disrupt the CLUE sessions. It would also be possible to mount a DoS attack on the CLUE endpoints if a malicious agent has access to the data channel. Thus, it MUST be possible for the endpoints to establish a channel which is secure against both message recovery and message modification. Further details on this are provided in the CLUE data channel solution document [I-D.ietf-clue-datachannel]. There are also security issues associated with the authorization to perform actions at the CLUE endpoints to invoke specific capabilities (e.g., re-arranging screens, sharing content, etc.). However, the policies and security associated with these actions Duckworth et. al. Expires July 8, 2016 [Page 72] Internet-Draft CLUE Telepresence Framework January 2016 are outside the scope of this document and the overall CLUE solution. 16. Changes Since Last Version NOTE TO THE RFC-Editor: Please remove this section prior to publication as an RFC. Changes from 24 to 25: Updates from IESG review. 1. A few clarifications in various places. 2. Change references to RFC5239 and RFC5646 from informative to normative. Changes from 23 to 24: 1. Updates to Security Considerations section. 2. Update version number of references to other CLUE documents in progress. Changes from 22 to 23: 1. Updates to Security Considerations section. 2. Update version number of references to other CLUE documents in progress. 3. Change some "MAY" to "may". 4. Fix a few grammatical errors. Changes from 21 to 22: 1. Add missing references. 2. Update version number of referenced working group drafts. 3. Minor updates for idnits issues. Changes from 20 to 21: 1. Clarify CLUE can be useful for multi-stream non-telepresence cases. 2. Remove unnecessary ambiguous sentence about optional use of CLUE protocol. Duckworth et. al. Expires July 8, 2016 [Page 73] Internet-Draft CLUE Telepresence Framework January 2016 3. Clarify meaning if Area of Capture is not specified. 4. Remove use of "conference" where it didn't fit according to the definition. Use "CLUE session" or "meeting" instead. 5. Embedded Text Attribute: Remove restriction it is for video only. 6. Minor cleanup in section 12 examples. 7. Minor editorial corrections suggested by Christian Groves. Changes from 19 to 20: 1. Define term "CLUE" in introduction. 2. Add MCC attribute Allow Subset Choice. 3. Remove phrase about reducing SDP size, replace with potentially saving consumer resources. 4. Change example of a CLUE exchange that does not require SDP exchange. 5. Language attribute uses RFC5646. 6. Change Member person type to Attendee. Add Observer type. 7. Clarify DTLS/SRTP MUST be supported. 8. Change SHOULD NOT to MUST NOT regarding using xCard or description information for authorization decisions. 9. Clarify definition of Global View. 10. Refer to signaling doc regarding interoperating with a device that does not support CLUE. 11. Various minor editorial changes from working group last call feedback. 12. Capitalize defined terms. Changes from 18 to 19: 1. Remove the Max Capture Encodings media capture attribute. 2. Refer to RTP mapping document in the MCC example section. 3. Update references to current versions of drafts in progress. Changes from 17 to 18: Duckworth et. al. Expires July 8, 2016 [Page 74] Internet-Draft CLUE Telepresence Framework January 2016 1. Add separate definition of Global View List. 2. Add diagram for Global View List structure. 3. Tweak definitions of Media Consumer and Provider. Changes from 16 to 17: 1. Ticket #59 - rename Capture Scene Entry (CSE) to Capture Scene View (CSV) 2. Ticket #60 - rename Global CSE List to Global View List 3. Ticket #61 - Proposal for describing the coordinate system. Describe it better, without conflicts if cameras point in different directions. 4. Minor clarifications and improved wording for Synchronisation Identity, MCC, Simultaneous Transmission Set. 5. Add definitions for CLUE-capable device and CLUE-enabled call, taken from the signaling draft. 6. Update definitions of Capture Device, Media Consumer, Media Provider, Endpoint, MCU, MCC. 7. Replace "middle box" with "MCU". 8. Explicitly state there can also be Media Captures that are not included in a Capture Scene View. 9. Explicitly state "A single Encoding Group MAY refer to encodings for different media types." 10. In example 12.1.1 add axes and audio captures to the diagram, and describe placement of microphones. 11. Add references to data model and signaling drafts. 12. Split references into Normative and Informative sections. Add heading number for references section. Changes from 15 to 16: 1. Remove Audio Channel Format attribute Duckworth et. al. Expires July 8, 2016 [Page 75] Internet-Draft CLUE Telepresence Framework January 2016 2. Add Audio Capture Sensitivity Pattern attribute 3. Clarify audio spatial information regarding point of capture and point on line of capture. Area of capture does not apply to audio. 4. Update section 12 example for new treatment of audio spatial information. 5. Clean up wording of some definitions, and various places in sections 5 and 10. 6. Remove individual encoding parameter paragraph from section 9. 7. Update Advertisement diagram. 8. Update Acknowledgements. 9. References to use cases and requirements now refer to RFCs. 10. Minor editorial changes. Changes from 14 to 15: 1. Add "=" and "<=" qualifiers to MaxCaptures attribute, and clarify the meaning regarding switched and composed MCC. 2. Add section 7.3.3 Global Capture Scene Entry List, and a few other sentences elsewhere that refer to global CSE sets. 3. Clarify: The Provider MUST be capable of encoding and sending all Captures (*that have an encoding group*) in a single Capture Scene Entry simultaneously. 4. Add voice activated switching example in section 12. 5. Change name of attributes Participant Info/Type to Person Info/Type. 6. Clarify the Person Info/Type attributes have the same meaning regardless of whether or not the capture has a Presentation attribute. Duckworth et. al. Expires July 8, 2016 [Page 76] Internet-Draft CLUE Telepresence Framework January 2016 7. Update example section 12.1 to be consistent with the rest of the document, regarding MCC and capture attributes. 8. State explicitly each CSE has a unique ID. Changes from 13 to 14: 1. Fill in section for Security Considerations. 2. Replace Role placeholder with Participant Information, Participant Type, and Scene Information attributes. 3. Spatial information implies nothing about how constituent media captures are combined into a composed MCC. 4. Clean up MCC example in Section 12.3.3. Clarify behavior of tiled and PIP display windows. Add audio. Add new open issue about associating incoming packets to original source capture. 5. Remove editor's note and associated statement about RTP multiplexing at end of section 5. 6. Remove editor's note and associated paragraph about overloading media channel with both CLUE and non-CLUE usage, in section 5. 7. In section 10, clarify intent of media encodings conforming to SDP, even with multiple CLUE message exchanges. Remove associated editor's note. Changes from 12 to 13: 1. Added the MCC concept including updates to existing sections to incorporate the MCC concept. New MCC attributes: MaxCaptures, SynchronisationID and Policy. 2. Removed the "composed" and "switched" Capture attributes due to overlap with the MCC concept. 3. Removed the "Scene-switch-policy" CSE attribute, replaced by MCC and SynchronisationID. 4. Editorial enhancements including numbering of the Capture attribute sections, tables, figures etc. Duckworth et. al. Expires July 8, 2016 [Page 77] Internet-Draft CLUE Telepresence Framework January 2016 Changes from 11 to 12: 1. Ticket #44. Remove note questioning about requiring a Consumer to send a Configure after receiving Advertisement. 2. Ticket #43. Remove ability for consumer to choose value of attribute for scene-switch-policy. 3. Ticket #36. Remove computational complexity parameter, MaxGroupPps, from Encoding Groups. 4. Reword the Abstract and parts of sections 1 and 4 (now 5) based on Mary's suggestions as discussed on the list. Move part of the Introduction into a new section Overview & Motivation. 5. Add diagram of an Advertisement, in the Overview of the Framework/Model section. 6. Change Intended Status to Standards Track. 7. Clean up RFC2119 keyword language. Changes from 10 to 11: 1. Add description attribute to Media Capture and Capture Scene Entry. 2. Remove contradiction and change the note about open issue regarding always responding to Advertisement with a Configure message. 3. Update example section, to cleanup formatting and make the media capture attributes and encoding parameters consistent with the rest of the document. Changes from 09 to 10: 1. Several minor clarifications such as about SDP usage, Media Captures, Configure message. 2. Simultaneous Set can be expressed in terms of Capture Scene and Capture Scene Entry. 3. Removed Area of Scene attribute. Duckworth et. al. Expires July 8, 2016 [Page 78] Internet-Draft CLUE Telepresence Framework January 2016 4. Add attributes from draft-groves-clue-capture-attr-01. 5. Move some of the Media Capture attribute descriptions back into this document, but try to leave detailed syntax to the data model. Remove the OUTSOURCE sections, which are already incorporated into the data model document. Changes from 08 to 09: 1. Use "document" instead of "memo". 2. Add basic call flow sequence diagram to introduction. 3. Add definitions for Advertisement and Configure messages. 4. Add definitions for Capture and Provider. 5. Update definition of Capture Scene. 6. Update definition of Individual Encoding. 7. Shorten definition of Media Capture and add key points in the Media Captures section. 8. Reword a bit about capture scenes in overview. 9. Reword about labeling Media Captures. 10. Remove the Consumer Capability message. 11. New example section heading for media provider behavior 12. Clarifications in the Capture Scene section. 13. Clarifications in the Simultaneous Transmission Set section. 14. Capitalize defined terms. 15. Move call flow example from introduction to overview section 16. General editorial cleanup 17. Add some editors' notes requesting input on issues Duckworth et. al. Expires July 8, 2016 [Page 79] Internet-Draft CLUE Telepresence Framework January 2016 18. Summarize some sections, and propose details be outsourced to other documents. Changes from 06 to 07: 1. Ticket #9. Rename Axis of Capture Point attribute to Point on Line of Capture. Clarify the description of this attribute. 2. Ticket #17. Add "capture encoding" definition. Use this new term throughout document as appropriate, replacing some usage of the terms "stream" and "encoding". 3. Ticket #18. Add Max Capture Encodings media capture attribute. 4. Add clarification that different capture scene entries are not necessarily mutually exclusive. Changes from 05 to 06: 1. Capture scene description attribute is a list of text strings, each in a different language, rather than just a single string. 2. Add new Axis of Capture Point attribute. 3. Remove appendices A.1 through A.6. 4. Clarify that the provider must use the same coordinate system with same scale and origin for all coordinates within the same capture scene. Changes from 04 to 05: 1. Clarify limitations of "composed" attribute. 2. Add new section "capture scene entry attributes" and add the attribute "scene-switch-policy". 3. Add capture scene description attribute and description language attribute. 4. Editorial changes to examples section for consistency with the rest of the document. Duckworth et. al. Expires July 8, 2016 [Page 80] Internet-Draft CLUE Telepresence Framework January 2016 Changes from 03 to 04: 1. Remove sentence from overview - "This constitutes a significant change ..." 2. Clarify a consumer can choose a subset of captures from a capture scene entry or a simultaneous set (in section "capture scene" and "consumer's choice..."). 3. Reword first paragraph of Media Capture Attributes section. 4. Clarify a stereo audio capture is different from two mono audio captures (description of audio channel format attribute). 5. Clarify what it means when coordinate information is not specified for area of capture, point of capture, area of scene. 6. Change the term "producer" to "provider" to be consistent (it was just in two places). 7. Change name of "purpose" attribute to "content" and refer to RFC4796 for values. 8. Clarify simultaneous sets are part of a provider advertisement, and apply across all capture scenes in the advertisement. 9. Remove sentence about lip-sync between all media captures in a capture scene. 10. Combine the concepts of "capture scene" and "capture set" into a single concept, using the term "capture scene" to replace the previous term "capture set", and eliminating the original separate capture scene concept. 17. Normative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol Data Channel", draft- ietf-clue-datachannel-11 (work in progress), November 2015. [I-D.ietf-clue-data-model-schema] Presta, R., Romano, S P., "An XML Schema for the CLUE data model", draft-ietf-clue-data-model-schema-11 (work in progress), October 2015. Duckworth et. al. Expires July 8, 2016 [Page 81] Internet-Draft CLUE Telepresence Framework January 2016 [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft- ietf-clue-protocol-06 (work in progress), October 2015. [I-D.ietf-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., Hansen, R., "CLUE Signaling", draft-ietf-clue-signaling-06 (work in progress), August 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobsen, V., Perkins, C., "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4579] Johnston, A., Levin, O., "SIP Call Control - Conferencing for User Agents", RFC 4579, August 2006 [RFC5239] Barnes, M., Boulton, C., Levin, O., "A Framework for Centralized Conferencing", RFC 5239, June 2008. [RFC5646] Phillips, A., Davis, M., "Tags for Identifying Languages", RFC 5646, September 2009. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011. [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, August 2011. Duckworth et. al. Expires July 8, 2016 [Page 82] Internet-Draft CLUE Telepresence Framework January 2016 18. Informative References [I-D.ietf-clue-rtp-mapping] Even, R., Lennox, J., "Mapping RP streams to CLUE media captures", draft-ietf-clue-rtp-mapping-05 (work in progress), October 2015. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. [RFC7201] Westerlund, M., Perkins, C., "Options for Securing RTP Sessions", RFC 7201, April 2014. [RFC7202] Perkins, C., Westerlund, M., "Why RTP Does Not Mandate a Single Media Security Solution ", RFC 7202, April 2014. [RFC7205] Romanow, A., Botzko, S., Duckworth, M., Even, R., "Use Cases for Telepresence Multistreams", RFC 7205, April 2014. [RFC7262] Romanow, A., Botzko, S., Barnes, M., "Requirements for Telepresence Multistreams", RFC 7262, June 2014. 19. Authors' Addresses Mark Duckworth (editor) Polycom Andover, MA 01810 USA Email: mark.duckworth@polycom.com Andrew Pepperell Acano Uxbridge, England UK Duckworth et. al. Expires July 8, 2016 [Page 83] Internet-Draft CLUE Telepresence Framework January 2016 Email: apeppere@gmail.com Stephan Wenger Vidyo, Inc. 433 Hackensack Ave. Hackensack, N.J. 07601 USA Email: stewe@stewe.org Duckworth et. al. Expires July 8, 2016 [Page 84] ./draft-ietf-mmusic-mux-exclusive-10.txt0000664000764400076440000006145112752134702017476 0ustar iustyiusty Network Working Group C. Holmberg Internet-Draft Ericsson Updates: 5761 (if approved) August 8, 2016 Intended status: Standards Track Expires: February 9, 2017 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP draft-ietf-mmusic-mux-exclusive-10.txt Abstract This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Holmberg Expires February 9, 2017 [Page 1] Internet-Draft Exclusive RTP/RTCP Mux August 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . . 3 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 7 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 8 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction [RFC5761] defines how to multiplex RTP and RTCP on a single IP address and port, referred to as RTP/RTCP multiplexing. [RFC5761] also defines an Session Description Protocol (SDP) [RFC4566] attribute, 'rtcp-mux' that can be used by entities to indicate support, and negotiate usage of, RTP/RTCP multiplexing. As defined in [RFC5761], if the peer endpoint does not support RTP/ RTCP multiplexing, both endpoints should use separate ports for sending and receiving of RTCP (referred to as fallback to usage of separate ports for RTP and RTCP). Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose to not implement separation of RTP and RTCP. Examples of such applications are W3C WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required to interoperate with non-WEBRTC clients. For such applications, this document defines an SDP attribute to signal intent to require multiplexing. The use of this attribute in SDP offers [RFC3264] by Holmberg Expires February 9, 2017 [Page 2] Internet-Draft Exclusive RTP/RTCP Mux August 2016 entities that ever need to interoperate with peers that do not support RTC/RTCP multiplexing may harm interoperability. Also, while the SDP answerer [RFC3264] might support, and prefer usage of, fallback to non-multiplex, the attribute indicates that fallback to non-multiplex cannot be enabled. One example of where non-multiplex is preferred is where an endpoint is connected to a radio interface, and wants to use different bearers (possibly with different quality characteristics) for RTP and RTCP. Another example is where the one endpoint is acting as a gateway to a network where RTP/RTCP multiplexing cannot be used. In such case there endpoint may prefer non-multiplexing also towards the other network. Otherwise the endpoint would have to perform de-multiplexing of RTP and RTCP. This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The document also describes the Interactive Connectivity Establishment (ICE) [RFC5245] considerations when indicating exclusive support of RTP/RTCP multiplexing. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. SDP rtcp-mux-only Attribute This section defines a new SDP media-level attribute, 'rtcp-mux- only'. Holmberg Expires February 9, 2017 [Page 3] Internet-Draft Exclusive RTP/RTCP Mux August 2016 Name: rtcp-mux-only Value: N/A Usage Level: media Charset Dependent: no Syntax: rtcp-mux-only Example: a=rtcp-mux-only In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to indicate exclusive support of RTP/RTCP multiplexing for the RTP- based media associated with the SDP media description ("m=" line). In an SDP answer, the 'rtcp-mux-only' attribute indicates that the answerer supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line). The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based media. The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- mux-only' attribute is 'IDENTICAL', which means that the attribute, if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. The 'rtcp-mux-only' attribute applies to the whole associated media description. The attribute MUST NOT be defined per source (using the SDP 'ssrc' attribute [RFC5576]). The SDP offer/answer [RFC3264] procedures associated with the attribute are defined in Section 4 4. SDP Offer/Answer Procedures Holmberg Expires February 9, 2017 [Page 4] Internet-Draft Exclusive RTP/RTCP Mux August 2016 4.1. General This section defines the SDP offer/answer [RFC3264] procedures for indicating exclusive support of, and negotiating usage of, RTP/RTCP multiplexing. The procedures in this section apply to individual RTP-based SDP media descriptions ("m=" lines). 4.2. Generating the Initial SDP Offer When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761]. If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an SDP media description ("m=" line), and if the offerer also associates an SDP 'rtcp-mux-only' attribute with the same SDP media description ("m=" line), the address and port values of the SDP 'rtcp' attribute MUST match the corresponding values for RTP. NOTE: This specification does not mandate the usage of the SDP 'rtcp' attribute for RTP/RTCP multiplexing. 4.3. Generating the Answer When an answerer receives an offer that contains an SDP 'rtcp-mux- only' attribute, associated with an RTP-based SDP media description ("m=" line), if the answerer accepts the usage of RTP/RTCP multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only' attribute with the corresponding SDP media description ("m=") in the associated answer. If the answerer does not accept the usage of RTP/ RTCP multiplexing, the answerer MUST either reject the SDP media description ("m=") by setting the port value to zero in the associated answer, or reject the whole offer, following the procedures in [RFC3264]. In addition, if the answerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line) in the answer, and if the corresponding "m=" line in the associated offer contained an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate Holmberg Expires February 9, 2017 [Page 5] Internet-Draft Exclusive RTP/RTCP Mux August 2016 an SDP 'rtcp-mux' attribute with the same "m=" line, following the procedures in [RFC5761]. 4.4. Offerer Processing of the SDP Answer If an offerer associated an SDP 'rtcp-mux-only' attribute with an RTP-based SDP media description ("m=" line) in an offer, and if the corresponding SDP media description ("m=" line) in the associated answer contains an SDP 'rtcp-mux-only' attribute, and/or an SDP 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP multiplexing procedures [RFC5761] to the associated RTP-based media. If the corresponding SDP media description ("m=" line) in the associated answer does not contain an SDP 'rtcp-mux-only' attribute, nor an SDP 'rtcp-mux' attribute, the offerer MUST either take appropriate actions in order to disable the associated RTP-based media, or send a new offer without associating an SDP 'rtcp-mux-only' attribute with the SDP media description ("m=" line). NOTE: This document does not mandate specific actions on how to terminate the RTP media. The offerer might e.g. send a new offer where the port value of the SDP media description is set to zero in order to terminate the RTP media. 4.5. Modifying the Session When an offerer sends a subsequent offer, if the offerer and answerer have previously negotiated usage of exclusive RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with the corresponding SDP media description ("m=" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761]. If the offerer does not associate the attributes with the corresponding SDP media description ("m=" line) it is an indication that the offerer no longer wants to use RTP/RTCP multiplexing, and instead MUST fallback to usage of separate ports for RTP and RTCP once the offer has been accepted by the answerer. When an offerer sends a subsequent offer, if the offerer and answerer have not previously negotiated usage of RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, following the procedures in Section 4.2. The offerer MUST process the associated answer following the procedures in Section 4.4. Holmberg Expires February 9, 2017 [Page 6] Internet-Draft Exclusive RTP/RTCP Mux August 2016 It is RECOMMENDED to not switch between usage of RTP/RTCP multiplexing and usage of separate ports for RTP and RTCP in a subsequent offer, unless there is a use-case that mandates it. 5. Update to RFC 5761 5.1. General This section updates sections 5.1.1 and 5.1.3 of RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports, and that the offerer shall terminate the affected streams if the answerer does not indicate support of RTP/RTCP multiplexing. It also clarifies that, when the offerer is not able to send and receive RTCP on separate ports, the offerer will not provide an SDP 'candidate' attribute for RTCP, nor will the offerer provide a fallback port for RTCP (using the SDP 'rtcp' attribute). 5.2. Update to 4th paragraph of section 5.1.1 OLD TEXT: If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute. NEW TEXT: If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute. However, if the offerer indicated in the offer that it is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Holmberg Expires February 9, 2017 [Page 7] Internet-Draft Exclusive RTP/RTCP Mux August 2016 5.3. Update to 2nd paragraph of section 5.1.3 OLD TEXT: If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired. NEW TEXT: If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired. However, if the offerer indicates in the offer that it is not able to send and receive RTCP on a separate port, the offerer MUST NOT include "a=candidate:" lines for RTCP, and the offerer MUST NOT provide a fallback port for RTCP using the "a=rtcp:" line. 6. ICE Considerations As defined in [RFC5245], if an entity is aware that the remote peer supports, and is willing to use, RTP/RTCP multiplexing, the entity will only provide RTP candidates (component ID 1). However, only providing RTP candidates does not as such imply exclusive support of RTP/RTCP multiplexing. RTCP candidates would not be provided also in cases where RTCP is not supported at all. Therefore, additional information is needed in order to indicate support of exclusive RTP/ RTCP multiplexing. This document defines such mechanism using the SDP 'rtcp-mux-only' attributes. 7. Security Considerations This document does not introduce new security considerations in additions to those specified in [RFC3605] and [RFC5761]. Holmberg Expires February 9, 2017 [Page 8] Internet-Draft Exclusive RTP/RTCP Mux August 2016 8. IANA Considerations This document updates the "Session Description Protocol Parameters" registry as specified in Section 8.2.2 of [RFC4566]. Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media level attributes. Attribute name: rtcp-mux-only Type of attribute: media-level Subject to charset: no Purpose: Indicate exclusive support of RTP/RTCP multiplexing Appropriate Values: N/A Contact name: Christer Holmberg (christer.holmberg@ericsson.com) Mux Category: IDENTICAL 9. Acknowledgments Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas Frankkila and Martin Thomson for their comments and input on the document. Thanks to Francis Dupont for the genart review. 10. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09 o Changes based on IESG review comments from Alexey Melnikov and Mirja Kuhlewind: o - References to draft-mux-attributes and draft-sdp-bundle made normative. o - Text added regarding cases where entities might want to use non- multiplexed RTP and RTCP. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-08 o Editorial changes based on genart comments from Francis Dupont. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07 o Comments from Ben Campbell. Holmberg Expires February 9, 2017 [Page 9] Internet-Draft Exclusive RTP/RTCP Mux August 2016 o - Additional text regarding applications for which the mechanism is suitable. o - Removal of pre-RFC5378 disclaimer. o - Editorial fixes. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06 o - Editorial fix. o - Addition of pre-RFC5378 disclaimer. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05 o Editorial fix. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04 o Changes based on comments from Flemming Andreasen. o - Attribute mux category changed to IDENTICAL. o - Reference to draft-5245bis changed to RFC 5245. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03 o Editorial changes based on comments from Martin Thomson. o Change of attribute name. o RFC 5761 updates added. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 o Minor editorial fix. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 o Mux category and source-specific applicability added. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 o Defined new SDP attribute for indicating rtcp-mux-exclusive. o Updates to RFC 5761 removed. o IANA considerations added. Holmberg Expires February 9, 2017 [Page 10] Internet-Draft Exclusive RTP/RTCP Mux August 2016 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 o Intended status changed to "Standards track". Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 o Clarified that the SDP rtcp attribute may contain the optional IP address part. Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 o Additional updates to Section 5.1.1 of RFC 5761. o ICE considerations added. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . Holmberg Expires February 9, 2017 [Page 11] Internet-Draft Exclusive RTP/RTCP Mux August 2016 [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13 (work in progress), June 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-31 (work in progress), June 2016. 11.2. Informative References [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [W3C.WD-webrtc-20120209] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20120209, February 2012, . Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires February 9, 2017 [Page 12] ./draft-ietf-core-http-mapping-17.txt0000664000764400076440000026263513017065074016741 0ustar iustyiusty CoRE Working Group A. Castellani Internet-Draft University of Padova Intended status: Standards Track S. Loreto Expires: June 1, 2017 Ericsson A. Rahman InterDigital Communications, LLC T. Fossati Nokia E. Dijk Philips Lighting November 28, 2016 Guidelines for HTTP-to-CoAP Mapping Implementations draft-ietf-core-http-mapping-17 Abstract This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 1, 2017. Castellani, et al. Expires June 1, 2017 [Page 1] Internet-Draft HTTP-to-CoAP Mapping November 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. HTTP-to-CoAP Proxy . . . . . . . . . . . . . . . . . . . . . 5 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. URI Terminology . . . . . . . . . . . . . . . . . . . . . 8 5.2. Null Mapping . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Default Mapping . . . . . . . . . . . . . . . . . . . . . 8 5.3.1. Optional Scheme Omission . . . . . . . . . . . . . . 9 5.3.2. Encoding Caveats . . . . . . . . . . . . . . . . . . 9 5.4. URI Mapping Template . . . . . . . . . . . . . . . . . . 9 5.4.1. Simple Form . . . . . . . . . . . . . . . . . . . . . 10 5.4.2. Enhanced Form . . . . . . . . . . . . . . . . . . . . 11 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13 6. Media Type Mapping . . . . . . . . . . . . . . . . . . . . . 15 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. 'application/coap-payload' Media Type . . . . . . . . . . 16 6.3. Loose Media Type Mapping . . . . . . . . . . . . . . . . 17 6.4. Media Type to Content Format Mapping Algorithm . . . . . 18 6.5. Content Transcoding . . . . . . . . . . . . . . . . . . . 19 6.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 19 6.5.2. CoRE Link Format . . . . . . . . . . . . . . . . . . 20 6.5.3. Diagnostic Messages . . . . . . . . . . . . . . . . . 20 7. Response Code Mapping . . . . . . . . . . . . . . . . . . . . 21 8. Additional Mapping Guidelines . . . . . . . . . . . . . . . . 23 8.1. Caching and Congestion Control . . . . . . . . . . . . . 23 8.2. Cache Refresh via Observe . . . . . . . . . . . . . . . . 24 8.3. Use of CoAP Blockwise Transfer . . . . . . . . . . . . . 24 8.4. CoAP Multicast . . . . . . . . . . . . . . . . . . . . . 25 8.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 26 Castellani, et al. Expires June 1, 2017 [Page 2] Internet-Draft HTTP-to-CoAP Mapping November 2016 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9.1. New 'core.hc' Resource Type . . . . . . . . . . . . . . . 26 9.2. New 'coap-payload' Internet Media Type . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Traffic Overflow . . . . . . . . . . . . . . . . . . . . 29 10.3. Handling Secured Exchanges . . . . . . . . . . . . . . . 30 10.4. URI Mapping . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Media Type Mapping Source Code . . . . . . . . . . . 34 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction CoAP (Constrained Application Protocol) [RFC7252] has been designed with the twofold aim to be an application protocol specialized for constrained environments and to be easily used in Representational State Transfer (REST) [Fielding] based architectures such as the Web. The latter goal has led to defining CoAP to easily interoperate with HTTP [RFC7230] through an intermediary proxy which performs cross- protocol conversion. Section 10 of [RFC7252] describes the fundamentals of the CoAP-to- HTTP and the HTTP-to-CoAP cross-protocol mapping process. However, [RFC7252] focuses on the basic mapping of request methods and simple response code mapping between HTTP and CoAP, while leaving many details of the cross-protocol proxy for future definition. Therefore, a primary goal of this document is to define a consistent set of guidelines that an HTTP-to-CoAP proxy implementation should adhere to. The key benefit to adhering to such guidelines is to reduce variation between proxy implementations, thereby increasing interoperability between an HTTP client and a CoAP server independent of the proxy that implements the cross-protocol mapping. (For example, a proxy conforming to these guidelines made by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines without breaking API semantics.) This document describes HTTP mappings that apply to protocol elements defined in the base CoAP specification [RFC7252]. It is up to CoAP protocol extensions (new methods, response codes, options, content- formats) to describe their own HTTP mappings, if applicable. The rest of this document is organized as follows: Castellani, et al. Expires June 1, 2017 [Page 3] Internet-Draft HTTP-to-CoAP Mapping November 2016 o Section 2 defines proxy terminology; o Section 3 introduces the HTTP-to-CoAP proxy; o Section 4 lists use cases in which HTTP clients need to contact CoAP servers; o Section 5 introduces a null, default, and advanced HTTP-to-CoAP URI mapping syntax; o Section 6 describes how to map HTTP media types to CoAP content formats and vice versa; o Section 7 describes how to map CoAP responses to HTTP responses; o Section 8 describes additional mapping guidelines related to caching, congestion, timeouts, etc.; o Section 10 discusses possible security impact of HTTP-to-CoAP protocol mapping. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This specification requires readers to be familiar with the vocabulary and concepts discussed in [RFC7228], in particular, the terms "Constrained Nodes" and "Constrained Networks". In addition, this specification makes use of the following terms: HC Proxy A proxy performing a cross-protocol mapping, in the context of this document an HTTP-to-CoAP (HC) mapping. Specifically, the HC Proxy acts as an HTTP server and a CoAP client. The HC Proxy can take on the role of a Forward, Reverse or Interception Proxy. Forward Proxy (or Forward HC Proxy) A message forwarding agent that is selected by the HTTP client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI. The user decides (is willing) to use the proxy as the forwarding/de-referencing agent for a predefined subset of the URI space. In [RFC7230] this is called a Proxy. [RFC7252] defines Forward-Proxy similarly. Castellani, et al. Expires June 1, 2017 [Page 4] Internet-Draft HTTP-to-CoAP Mapping November 2016 Reverse Proxy (or Reverse HC Proxy) As in [RFC7230], a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying server's protocol. A Reverse HC Proxy behaves as an origin (HTTP) server on its connection from the HTTP client. The HTTP client uses the "origin-form" (Section 5.3.1 of [RFC7230]) as a request-target URI. (Note that a Reverse Proxy appears to an HTTP client as an origin server while a Forward Proxy does not. So, when communicating with a Reverse Proxy a client may be unaware it is communicating with a proxy at all.) Interception Proxy (or Interception HC Proxy) As in [RFC3040], a proxy that receives inbound HTTP traffic flows through the process of traffic redirection, transparent to the HTTP client. 3. HTTP-to-CoAP Proxy An HC Proxy is accessed by an HTTP client that needs to fetch a resource on a CoAP server. The HC Proxy handles the HTTP request by mapping it to the equivalent CoAP request, which is then forwarded to the appropriate CoAP server. The received CoAP response is then mapped to an appropriate HTTP response and finally sent back to the originating HTTP client. Section 10.2 of [RFC7252] defines basic normative requirements on HTTP-to-CoAP mapping. This document provides additional details and guidelines for the implementation of an HC Proxy. Castellani, et al. Expires June 1, 2017 [Page 5] Internet-Draft HTTP-to-CoAP Mapping November 2016 Constrained Network .-------------------. / .------. \ / | CoAP | \ / |server| \ || '------' || || || .--------. HTTP Request .------------. CoAP Req .------. || | HTTP |---------------->|HTTP-to-CoAP|----------->| CoAP | || | Client |<----------------| Proxy |<-----------|Server| || '--------' HTTP Response '------------' CoAP Resp '------' || || || || .------. || || | CoAP | || \ |server| .------. / \ '------' | CoAP | / \ |server| / \ '------' / '-----------------' Figure 1: HTTP-To-CoAP Proxy Deployment Scenario Figure 1 illustrates an example deployment scenario. There, an HC Proxy is located at the boundary of the Constrained Network domain and acts as an Application Layer Gateway (ALG) that allows only a very specific type of traffic (i.e., authorized inbound HTTP requests and their associated outbound CoAP responses) to pass through. All other kinds of traffic are segregated within the respective network segments. 4. Use Cases To illustrate a few situations in which HTTP to CoAP protocol translation may be used, three use cases are described below. 1. Legacy building control application without CoAP: A building control application that uses HTTP but not CoAP can check the status of CoAP sensors and/or control actuators via an HC Proxy. 2. Making sensor data available to 3rd parties on the Web: For demonstration or public interest purposes, an HC Proxy may be configured to expose the contents of a CoAP sensor to the world via the web (HTTP and/or HTTPS). Some sensors may only accept secure 'coaps' requests, therefore the proxy is configured to translate requests to those devices accordingly. The HC Proxy is furthermore configured to only pass through GET requests in order to protect the constrained network. Castellani, et al. Expires June 1, 2017 [Page 6] Internet-Draft HTTP-to-CoAP Mapping November 2016 3. Smartphone and home sensor: A smartphone can access directly a CoAP home sensor using a mutually authenticated 'https' request, provided its home router runs an HC Proxy and is configured with the appropriate certificate. An HTML5 [W3C.REC-html5-20141028] application on the smartphone can provide a friendly UI using the standard (HTTP) networking functions of HTML5. A key point in the above use cases is the expected nature of the URI to be used by the HTTP client initiating the HTTP request to the HC Proxy. Specifically, in use case #1, there will be no 'coap' or 'coaps' related information embedded in the HTTP URI as it is a legacy HTTP client sending the request. Use case #2 is also expected to be similar. In contrast, in use case #3, it is likely that the HTTP client will specifically embed 'coap' or 'coaps' related information in the HTTP URI of the HTTP request to the HC Proxy. 5. URI Mapping Though, in principle, a CoAP URI could be directly used by an HTTP client to de-reference a CoAP resource through an HC Proxy, the reality is that all major web browsers, networking libraries and command line tools do not allow making HTTP requests using URIs with a scheme 'coap' or 'coaps'. Thus, there is a need for web applications to embed or "pack" a CoAP URI into an HTTP URI so that it can be (non-destructively) transported from the HTTP client to the HC Proxy. The HC Proxy can then "unpack" the CoAP URI and finally de-reference it via a CoAP request to the target Server. URI Mapping is the term used in this document to describe the process through which the URI of a CoAP resource is transformed into an HTTP URI so that: o The requesting HTTP client can handle it; o The receiving HC Proxy can extract the intended CoAP URI unambiguously. To this end, the remainder of this section will identify: o The default mechanism to map a CoAP URI into an HTTP URI; o The URI template format to express a class of CoAP-HTTP URI mapping functions; o The discovery mechanism based on CoRE Link Format [RFC6690] through which clients of an HC Proxy can dynamically learn about Castellani, et al. Expires June 1, 2017 [Page 7] Internet-Draft HTTP-to-CoAP Mapping November 2016 the supported URI Mapping Template(s), as well as the URI where the HC Proxy function is anchored. 5.1. URI Terminology In the remainder of this section, the following terms will be used with a distinctive meaning: HC Proxy URI: URI which refers to the HC Proxy function. It conforms to syntax defined in Section 2.7 of [RFC7230]. Target CoAP URI: URI which refers to the (final) CoAP resource that has to be de-referenced. It conforms to syntax defined in Section 6 of [RFC7252]. Specifically, its scheme is either 'coap' or 'coaps'. Hosting HTTP URI: URI that conforms to syntax in Section 2.7 of [RFC7230]. Its authority component refers to an HC Proxy, whereas path and/ or query component(s) embed the information used by an HC Proxy to extract the Target CoAP URI. 5.2. Null Mapping The null mapping is the case where there is no Target CoAP URI appended to the HC Proxy URI. In other words, it is a "pure" HTTP URI that is sent to the HC Proxy. This would typically occur in situations like Use Case #1 described in Section 4, and the Proxy would typically be a Reverse Proxy. In this scenario, the HC Proxy will determine through its own private algorithms what the Target CoAP URI should be. 5.3. Default Mapping The default mapping is for the Target CoAP URI to be appended as-is (with the only caveat discussed in Section 5.3.2) to the HC Proxy URI, to form the Hosting HTTP URI. This is the Effective Request URI (see Section 5.5 of [RFC7230]) that will then be sent by the HTTP client in the HTTP request to the HC Proxy. For example: given an HC Proxy URI https://p.example.com/hc/ and a Target CoAP URI coap://s.example.com/light, the resulting Hosting HTTP URI would be https://p.example.com/hc/coap://s.example.com/ light. Castellani, et al. Expires June 1, 2017 [Page 8] Internet-Draft HTTP-to-CoAP Mapping November 2016 Provided a correct Target CoAP URI, the Hosting HTTP URI resulting from the default mapping will be a syntactically valid HTTP URI. Furthermore, the Target CoAP URI can always be extracted unambiguously from the Hosting HTTP URI. There is no default for the HC Proxy URI. Therefore, it is either known in advance, e.g., as a configuration preset, or dynamically discovered using the mechanism described in Section 5.5. The default URI mapping function SHOULD be implemented and SHOULD be activated by default in an HC Proxy, unless there are valid reasons (e.g., application specific) to use a different mapping function. 5.3.1. Optional Scheme Omission When constructing a Hosting HTTP URI by embedding a Target CoAP URI, the scheme (i.e., 'coap' or 'coaps'), the scheme component delimiter (":"), and the double slash ("//") preceding the authority MAY be omitted if a local default - not defined by this document - applies. If no prior mutual agreement exists between the client and the HC Proxy, then a Target CoAP URI without the scheme component is syntactically incorrect, and therefore: o It MUST NOT be emitted by clients; o It MUST elicit a suitable client error status (i.e., 4xx) by the HC Proxy. 5.3.2. Encoding Caveats When the authority of the Target CoAP URI is given as an IPv6address, then the surrounding square brackets must be percent-encoded in the Hosting HTTP URI, in order to comply with the syntax defined in Section 3.3. of [RFC3986] for a URI path segment. E.g.: coap://[2001:db8::1]/light?on becomes https://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. (Note that the percent-encoded square brackets shall be reverted to their non-percent-encoded form when the HC Proxy unpacks the Target CoAP URI.) Everything else can be safely copied verbatim from the Target CoAP URI to the Hosting HTTP URI. 5.4. URI Mapping Template This section defines a format for the URI template [RFC6570] used by an HC Proxy to inform its clients about the expected syntax for the Hosting HTTP URI. This will then be used by the HTTP client to Castellani, et al. Expires June 1, 2017 [Page 9] Internet-Draft HTTP-to-CoAP Mapping November 2016 construct the Effective Request URI to be sent in the HTTP request to the HC Proxy. When instantiated, a URI Mapping Template is always concatenated to an HC Proxy URI provided by the HC Proxy via discovery (see Section 5.5), or by other means. A simple form (Section 5.4.1) and an enhanced form (Section 5.4.2) are provided to fit different users' requirements. Both forms are expressed as level 2 URI templates [RFC6570] to take care of the expansion of values that are allowed to include reserved URI characters. The syntax of all URI formats is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234]. 5.4.1. Simple Form The simple form MUST be used for mappings where the Target CoAP URI is going to be copied (using rules of Section 5.3.2) at some fixed position into the Hosting HTTP URI. The "tu" template variable is intended to be used in a template definition to represent a Target CoAP URI: tu = [ ( "coap:" / "coaps:" ) "//" ] host [ ":" port ] path-abempty [ "?" query ] Note that the same considerations as in Section 5.3.1 apply, in that the CoAP scheme may be omitted from the Hosting HTTP URI. 5.4.1.1. Examples All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use https://p.example.com/hc/ as the HC Proxy URI. Note that these examples all define mapping templates that deviate from the default template of Section 5.3 in order to illustrate the use of the above template variables. 1. Target CoAP URI is a query argument of the Hosting HTTP URI: Castellani, et al. Expires June 1, 2017 [Page 10] Internet-Draft HTTP-to-CoAP Mapping November 2016 ?target_uri={+tu} coap://s.example.com/light => https://p.example.com/hc/?target_uri=coap://s.example.com/light whereas coaps://s.example.com/light => https://p.example.com/hc/?target_uri=coaps://s.example.com/light 2. Target CoAP URI in the path component of the Hosting HTTP URI: forward/{+tu} coap://s.example.com/light => https://p.example.com/hc/forward/coap://s.example.com/light whereas coaps://s.example.com/light => https://p.example.com/hc/forward/coaps://s.example.com/light 3. Target CoAP URI is a query argument of the Hosting HTTP URI; client decides to omit the scheme because a default is agreed beforehand between client and proxy: ?coap_uri={+tu} coap://s.example.com/light => https://p.example.com/hc/?coap_uri=s.example.com/light 5.4.2. Enhanced Form The enhanced form can be used to express more sophisticated mappings of the Target CoAP URI into the Hosting HTTP URI, i.e., mappings that do not fit into the simple form. Castellani, et al. Expires June 1, 2017 [Page 11] Internet-Draft HTTP-to-CoAP Mapping November 2016 There MUST be at most one instance of each of the following template variables in a template definition: s = "coap" / "coaps" ; from [RFC7252], Sections 6.1 and 6.2 hp = host [":" port] ; from [RFC3986], Sections 3.2.2 and 3.2.3 p = path-abempty ; from [RFC3986], Section 3.3 q = query ; from [RFC3986], Section 3.4 qq = [ "?" query ] ; qq is empty if and only if 'query' is empty The qq form is used when the path and the (optional) query components are to be copied verbatim from the Target CoAP URI into the Hosting HTTP URI, i.e., as "{+p}{+qq}". Instead, the q form is used when the query and path are mapped as separate entities, e.g., as in "coap_path={+p}&coap_query={+q}". 5.4.2.1. Examples All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use https://p.example.com/hc/ as the HC Proxy URI. 1. Target CoAP URI components in path segments, and optional query in query component: {+s}/{+hp}{+p}{+qq} coap://s.example.com/light => https://p.example.com/hc/coap/s.example.com/light whereas coap://s.example.com/light?on => https://p.example.com/hc/coap/s.example.com/light?on 2. Target CoAP URI components split in individual query arguments: Castellani, et al. Expires June 1, 2017 [Page 12] Internet-Draft HTTP-to-CoAP Mapping November 2016 ?s={+s}&hp={+hp}&p={+p}&q={+q} coap://s.example.com/light => https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light&q= whereas coaps://s.example.com/light?on => https://p.example.com/hc/?s=coaps&hp=s.example.com&p=/light&q=on 5.5. Discovery In order to accommodate site-specific needs while allowing third parties to discover the proxy function, the HC Proxy SHOULD publish information related to the location and syntax of the HC Proxy function using the CoRE Link Format [RFC6690] interface. To this aim a new Resource Type, "core.hc", is defined in this document. It can be used as the value for the "rt" attribute in a query to the /.well-known/core in order to locate the URI where the HC Proxy function is anchored, i.e., the HC Proxy URI. Along with it, the new target attribute "hct" is defined in this document. This attribute MAY be returned in a "core.hc" link to provide the URI Mapping Template associated with the mapping resource. The default template given in Section 5.3, i.e., {+tu}, MUST be assumed if no "hct" attribute is found in the returned link. If a "hct" attribute is present in the returned link, then a client MUST use it to create the Hosting HTTP URI. The URI mapping SHOULD be discoverable (as specified in [RFC6690]) on both the HTTP and the CoAP side of the HC Proxy, with one important difference: on the CoAP side the link associated with the "core.hc" resource needs an explicit anchor referring to the HTTP origin [RFC6454], while on the HTTP interface the link context is already the HTTP origin carried in the request's Host header, and doesn't have to be made explicit. 5.5.1. Examples o The first example exercises the CoAP interface and assumes that the default template, {+tu}, is used. For example, a smartphone may discover the public HC Proxy before leaving the home network. Then when outside the home network, the smartphone will be able to query the appropriate home sensor. Castellani, et al. Expires June 1, 2017 [Page 13] Internet-Draft HTTP-to-CoAP Mapping November 2016 Req: GET coap://[ff02::1]/.well-known/core?rt=core.hc Res: 2.05 Content ;anchor="https://p.example.com";rt="core.hc" o The second example - also on the CoAP side of the HC Proxy - uses a custom template, i.e., one where the CoAP URI is carried inside the query component, thus the returned link carries the URI template to be used in an explicit "hct" attribute: Req: GET coap://[ff02::1]/.well-known/core?rt=core.hc Res: 2.05 Content ;anchor="https://p.example.com"; rt="core.hc";hct="?uri={+tu}" On the HTTP side, link information can be serialized in more than one way: o using the 'application/link-format' content type: Req: GET /.well-known/core?rt=core.hc HTTP/1.1 Host: p.example.com Res: HTTP/1.1 200 OK Content-Type: application/link-format Content-Length: 18 ;rt="core.hc" o using the 'application/link-format+json' content type as defined in [I-D.ietf-core-links-json]: Req: GET /.well-known/core?rt=core.hc HTTP/1.1 Host: p.example.com Res: HTTP/1.1 200 OK Content-Type: application/link-format+json Content-Length: 31 [{"href":"/hc/","rt":"core.hc"}] Castellani, et al. Expires June 1, 2017 [Page 14] Internet-Draft HTTP-to-CoAP Mapping November 2016 o using the Link header: Req: GET /.well-known/core?rt=core.hc HTTP/1.1 Host: p.example.com Res: HTTP/1.1 200 OK Link: ;rt="core.hc" 6. Media Type Mapping 6.1. Overview An HC Proxy needs to translate HTTP media types (Section 3.1.1.1 of [RFC7231]) and content encodings (Section 3.1.2.2 of [RFC7231]) into CoAP content formats (Section 12.3 of [RFC7252]) and vice versa. Media type translation can happen in GET, PUT or POST requests going from HTTP to CoAP, and in 2.xx (i.e., successful) responses going from CoAP to HTTP. Specifically, PUT and POST need to map both the Content-Type and Content-Encoding HTTP headers into a single CoAP Content-Format option, whereas GET needs to map Accept and Accept- Encoding HTTP headers into a single CoAP Accept option. To generate the HTTP response, the CoAP Content-Format option is mapped back to a suitable HTTP Content-Type and Content-Encoding combination. An HTTP request carrying a Content-Type and Content-Encoding combination which the HC Proxy is unable to map to an equivalent CoAP Content-Format, SHALL elicit a 415 (Unsupported Media Type) response by the HC Proxy. On the content negotiation side, failure to map Accept and Accept-* headers SHOULD be silently ignored: the HC Proxy SHOULD therefore forward as a CoAP request with no Accept option. The HC Proxy thus disregards the Accept/Accept-* header fields by treating the response as if it is not subject to content negotiation, as mentioned in Sections 5.3.* of [RFC7231]. However, an HC Proxy implementation is free to attempt mapping a single Accept header in a GET request to multiple CoAP GET requests, each with a single Accept option, which are then tried in sequence until one succeeds. Note that an HTTP Accept */* MUST be mapped to a CoAP request without Accept option. While the CoAP to HTTP direction has always a well-defined mapping (with the exception examined in Section 6.2), the HTTP to CoAP direction is more problematic because the source set, i.e., potentially 1000+ IANA registered media types, is much bigger than Castellani, et al. Expires June 1, 2017 [Page 15] Internet-Draft HTTP-to-CoAP Mapping November 2016 the destination set, i.e., the mere 6 values initially defined in Section 12.3 of [RFC7252]. Depending on the tight/loose coupling with the application(s) for which it proxies, the HC Proxy could implement different media type mappings. When tightly coupled, the HC Proxy knows exactly which content formats are supported by the applications, and can be strict when enforcing its forwarding policies in general, and the media type mapping in particular. On the other hand, when the HC Proxy is a general purpose ALG, being too strict could significantly reduce the amount of traffic that it would be able to successfully forward. In this case, the "loose" media type mapping detailed in Section 6.3 MAY be implemented. The latter grants more evolution of the surrounding ecosystem, at the cost of allowing more attack surface. In fact, as a result of such strategy, payloads would be forwarded more liberally across the unconstrained/constrained network boundary of the communication path. 6.2. 'application/coap-payload' Media Type If the HC Proxy receives a CoAP response with a Content-Format that it does not recognize (e.g., because the value has been registered after the proxy has been deployed, or the CoAP server uses an experimental value which is not registered), then the HC Proxy SHALL return a generic "application/coap-payload" media type with numeric parameter "cf" as defined in Section 9.2. For example, the CoAP content format '60' ("application/cbor") would be represented by "application/coap-payload;cf=60", if the HC Proxy doesn't recognize the content format '60'. A HTTP client may use the media type "application/coap-payload" as a means to send a specific content format to a CoAP server via an HC Proxy if the client has determined that the HC Proxy does not directly support the type mapping it needs. This case may happen when dealing for example with newly registered, yet to be registered, or experimental CoAP content formats. However, unless explicitly configured to allow pass-through of unknown content formats, the HC Proxy SHOULD NOT forward requests carrying a Content-Type or Accept header with an "application/coap-payload", and return an appropriate client error instead. Castellani, et al. Expires June 1, 2017 [Page 16] Internet-Draft HTTP-to-CoAP Mapping November 2016 6.3. Loose Media Type Mapping By structuring the type information in a super-class (e.g., "text") followed by a finer grained sub-class (e.g., "html"), and optional parameters (e.g., "charset=utf-8"), Internet media types provide a rich and scalable framework for encoding the type of any given entity. This approach is not applicable to CoAP, where Content Formats conflate an Internet media type (potentially with specific parameters) and a content encoding into one small integer value. To remedy this loss of flexibility, we introduce the concept of a "loose" media type mapping, where media types that are specializations of a more generic media type can be aliased to their super-class and then mapped (if possible) to one of the CoAP content formats. For example, "application/soap+xml" can be aliased to "application/xml", which has a known conversion to CoAP. In the context of this "loose" media type mapping, "application/octet- stream" can be used as a fallback when no better alias is found for a specific media type. Table 1 defines the default lookup table for the "loose" media type mapping. It is expected that an implementation can refine it either given application-specific knowledge, or because new Content-Formats are defined. Given an input media type, the table returns its best generalized media type using the most specific match i.e., the table entries are compared to the input in top to bottom order until an entry matches. +-----------------------------+--------------------------+ | Internet media type pattern | Generalized media type | +-----------------------------+--------------------------+ | application/*+xml | application/xml | | application/*+json | application/json | | application/*+cbor | application/cbor | | text/xml | application/xml | | text/* | text/plain | | */* | application/octet-stream | +-----------------------------+--------------------------+ Table 1: Media type generalization lookup table The "loose" media type mapping is an OPTIONAL feature. Implementations supporting this kind of mapping should provide a flexible way to define the set of media type generalizations allowed. Castellani, et al. Expires June 1, 2017 [Page 17] Internet-Draft HTTP-to-CoAP Mapping November 2016 6.4. Media Type to Content Format Mapping Algorithm This section defines the algorithm used to map an HTTP Internet media type to its correspondent CoAP content format; it can be used as a building block for translating HTTP Content-Type and Accept headers into CoAP Content-Format and Accept Options. The algorithm uses an IANA-maintained table, "CoAP Content-Formats", as established by Section 12.3 of [RFC7252] plus, possibly, any locally defined extension of it. Optionally, the table and lookup mechanism described in Section 6.3 can be used if the implementation chooses so. Note that the algorithm assumes an "identity" Content-Encoding and expects the resource body has been already successfully content- decoded or transcoded to the desired format. In the following (Figure 2): o media_type is the media type to translate; o coap_cf_registry is a lookup table matching the CoAP Content Format Registry; o loose_mapper is an optional lookup table describing the loose media type mappings (e.g., the one defined in Table 1); The full source code is provided in Appendix A. Castellani, et al. Expires June 1, 2017 [Page 18] Internet-Draft HTTP-to-CoAP Mapping November 2016 def mt2cf(media_type, encoding=None, coap_cf_registry=CoAPContentFormatRegistry(), loose_mapper=None): """Return a CoAP Content-Format given an Internet Media Type and its optional encoding. The current (as of 2016/10/24) CoAP Content Format Registry is supplied by default. An optional 'loose-mapping' implementation can be supplied by the caller.""" assert media_type is not None assert coap_cf_registry is not None # Lookup the CoAP Content-Formats registry content_format = coap_cf_registry.lookup(media_type, encoding) # If an exact match is not found and a loose mapper has been # supplied, try to use it to get a media type with which to # re-try the CoAP Content-Formats registry lookup. if content_format is None and loose_mapper is not None: content_format = coap_cf_registry.lookup( loose_mapper.lookup(media_type), encoding) return content_format Figure 2 6.5. Content Transcoding 6.5.1. General Payload content transcoding is an OPTIONAL feature. Implementations supporting this feature should provide a flexible way to define the set of transcodings allowed. The HC Proxy might decide to transcode the received representation to a different (compatible) format when an optimized version of a specific format exists. For example, a XML-encoded resource could be transcoded to Efficient XML Interchange (EXI) format, or a JSON- encoded resource into CBOR [RFC7049], effectively achieving compression without losing any information. However, there are a few important factors to keep in mind when enabling a transcoding function: 1. Maliciously crafted inputs coming from the HTTP side might inflate in size (see for example Section 4.2 of [RFC7049]), therefore creating a security threat for both the HC Proxy and the target resource; Castellani, et al. Expires June 1, 2017 [Page 19] Internet-Draft HTTP-to-CoAP Mapping November 2016 2. Transcoding can lose information in non-obvious ways. For example, encoding a XML document using schema-informed EXI encoding leads to a loss of information when the destination does not know the exact schema version used by the encoder. That means that whenever the HC Proxy transcodes an application/XML to application/EXI in-band metadata could be lost. 3. When content-type is mapped, there is a risk that the content with the destination type would have malware not active in the source type. It is crucial that these risks are well understood and carefully weighed against the actual benefits before deploying the transcoding function. 6.5.2. CoRE Link Format The CoRE Link Format [RFC6690] is a set of links (i.e., URIs and their formal relationships) which is carried as content payload in a CoAP response. These links usually include CoAP URIs that might be translated by the HC Proxy to the correspondent HTTP URIs using the implemented URI mapping function (see Section 5). Such a process would inspect the forwarded traffic and attempt to re-write the body of resources with an application/link-format media type, mapping the embedded CoAP URIs to their HTTP counterparts. Some potential issues with this approach are: 1. The client may be interested in retrieving original (unaltered) CoAP payloads through the HC Proxy, not modified versions. 2. Tampering with payloads is incompatible with resources that are integrity protected (although this is a problem with transcoding in general). 3. The HC Proxy needs to fully understand [RFC6690] syntax and semantics, otherwise there is an inherent risk to corrupt the payloads. Therefore, CoRE Link Format payload should only be transcoded at the risk and discretion of the proxy implementer. 6.5.3. Diagnostic Messages CoAP responses may, in certain error cases, contain a diagnostic message in the payload explaining the error situation, as described in Section 5.5.2 of [RFC7252]. If present, the CoAP response diagnostic payload SHOULD be copied in the HTTP response body. The CoAP diagnostic message MUST NOT be copied into the HTTP reason- Castellani, et al. Expires June 1, 2017 [Page 20] Internet-Draft HTTP-to-CoAP Mapping November 2016 phrase, since it potentially contains CR-LF characters which are incompatible with HTTP reason-phrase syntax. 7. Response Code Mapping Table 2 defines the HTTP response status codes to which each CoAP response code SHOULD be mapped. Multiple appearances of a HTTP status code in the second column indicates multiple equivalent HTTP responses are possible based on the same CoAP response code, depending on the conditions cited in the Notes (third column and text below table). +-------------------------------+----------------------------+------+ | CoAP Response Code | HTTP Status Code | Note | +-------------------------------+----------------------------+------+ | 2.01 Created | 201 Created | 1 | | 2.02 Deleted | 200 OK | 2 | | | 204 No Content | 2 | | 2.03 Valid | 304 Not Modified | 3 | | | 200 OK | 4 | | 2.04 Changed | 200 OK | 2 | | | 204 No Content | 2 | | 2.05 Content | 200 OK | | | 2.31 Continue | N/A | 10 | | 4.00 Bad Request | 400 Bad Request | | | 4.01 Unauthorized | 403 Forbidden | 5 | | 4.02 Bad Option | 400 Bad Request | 6 | | 4.02 Bad Option | 500 Internal Server Error | 6 | | 4.03 Forbidden | 403 Forbidden | | | 4.04 Not Found | 404 Not Found | | | 4.05 Method Not Allowed | 400 Bad Request | 7 | | 4.06 Not Acceptable | 406 Not Acceptable | | | 4.08 Request Entity Incomplt. | N/A | 10 | | 4.12 Precondition Failed | 412 Precondition Failed | | | 4.13 Request Ent. Too Large | 413 Payload Too Large | 11 | | 4.15 Unsupported Content-Fmt. | 415 Unsupported Media Type | | | 5.00 Internal Server Error | 500 Internal Server Error | | | 5.01 Not Implemented | 501 Not Implemented | | | 5.02 Bad Gateway | 502 Bad Gateway | | | 5.03 Service Unavailable | 503 Service Unavailable | 8 | | 5.04 Gateway Timeout | 504 Gateway Timeout | | | 5.05 Proxying Not Supported | 502 Bad Gateway | 9 | +-------------------------------+----------------------------+------+ Table 2: CoAP-HTTP Response Code Mappings Notes: Castellani, et al. Expires June 1, 2017 [Page 21] Internet-Draft HTTP-to-CoAP Mapping November 2016 1. A CoAP server may return an arbitrary format payload along with this response. If present, this payload MUST be returned as entity in the HTTP 201 response. Section 7.3.2 of [RFC7231] does not put any requirement on the format of the entity. (In the past, [RFC2616] did.) 2. The HTTP code is 200 or 204 respectively for the case that a CoAP server returns a payload or not. [RFC7231] Section 5.3 requires code 200 in case a representation of the action result is returned for DELETE/POST/PUT, and code 204 if not. Hence, a proxy MUST transfer any CoAP payload contained in a CoAP 2.02 response to the HTTP client using a 200 OK response. 3. HTTP code 304 (Not Modified) is sent if the HTTP client performed a conditional HTTP request and the CoAP server responded with 2.03 (Valid) to the corresponding CoAP validation request. Note that Section 4.1 of [RFC7232] puts some requirements on header fields that must be present in the HTTP 304 response. 4. A 200 response to a CoAP 2.03 occurs only when the HC Proxy, for efficiency reasons, is running a local cache. An unconditional HTTP GET which produces a cache-hit, could trigger a re- validation (i.e., a conditional GET) on the CoAP side. The proxy receiving 2.03 updates the freshness of its cached representation and returns it to the HTTP client. 5. A HTTP 401 Unauthorized (Section 3.1 of [RFC7235]) response is not applicable because there is no equivalent in CoAP of WWW- Authenticate which is mandatory in a HTTP 401 response. 6. If the proxy has a way to determine that the Bad Option is due to the straightforward mapping of a client request header into a CoAP option, then returning HTTP 400 (Bad Request) is appropriate. In all other cases, the proxy MUST return HTTP 500 (Internal Server Error) stating its inability to provide a suitable translation to the client's request. 7. A CoAP 4.05 (Method Not Allowed) response SHOULD normally be mapped to a HTTP 400 (Bad Request) code, because the HTTP 405 response would require specifying the supported methods - which are generally unknown. In this case the HC Proxy SHOULD also return a HTTP reason-phrase in the HTTP status line that starts with the string "CoAP server returned 4.05" in order to facilitate troubleshooting. However, if the HC Proxy has more granular information about the supported methods for the requested resource (e.g., via a Resource Directory ([I-D.ietf-core-resource-directory])) then it MAY send back a Castellani, et al. Expires June 1, 2017 [Page 22] Internet-Draft HTTP-to-CoAP Mapping November 2016 HTTP 405 (Method Not Allowed) with a properly filled in "Allow" response-header field (Section 7.4.1 of [RFC7231]). 8. The value of the HTTP "Retry-After" response-header field is taken from the value of the CoAP Max-Age Option, if present. 9. This CoAP response can only happen if the proxy itself is configured to use a CoAP forward-proxy (Section 5.7 of [RFC7252]) to execute some, or all, of its CoAP requests. 10. Only used in CoAP blockwise transfer [RFC7959] between HC Proxy and CoAP server; never translated into a HTTP response. 11. Only returned to the HTTP client if the HC Proxy was unable to successfully complete the request by retrying it with CoAP blockwise transfer; see Section 8.3. 8. Additional Mapping Guidelines 8.1. Caching and Congestion Control An HC Proxy should cache CoAP responses, and reply whenever applicable with a cached representation of the requested resource. If the HTTP client drops the connection after the HTTP request was made, an HC Proxy should wait for the associated CoAP response and cache it if possible. Subsequent requests to the HC Proxy for the same resource can use the result present in cache, or, if a response has still to come, the HTTP requests will wait on the open CoAP request. According to [RFC7252], a proxy must limit the number of outstanding requests to a given CoAP server to NSTART. To limit the amount of aggregate traffic to a constrained network, the HC Proxy should also put a limit on the number of concurrent CoAP requests pending on the same constrained network; further incoming requests may either be queued or dropped (returning 503 Service Unavailable). This limit and the proxy queueing/dropping behavior should be configurable. Highly volatile resources that are being frequently requested may be observed [RFC7641] by the HC Proxy to keep their cached representation fresh while minimizing the amount of CoAP traffic in the constrained network (see Section 8.2). Castellani, et al. Expires June 1, 2017 [Page 23] Internet-Draft HTTP-to-CoAP Mapping November 2016 8.2. Cache Refresh via Observe There are cases where using the CoAP observe protocol [RFC7641] to handle proxy cache refresh is preferable to the validation mechanism based on ETag as defined in [RFC7252]. Such scenarios include sleepy CoAP nodes - with possibly high variance in requests' distribution - which would greatly benefit from a server-driven cache update mechanism. Ideal candidates for CoAP observe are also crowded or very low throughput networks, where reduction of the total number of exchanged messages is an important requirement. This subsection aims at providing a practical evaluation method to decide whether refreshing a cached resource R is more efficiently handled via ETag validation or by establishing an observation on R. The idea being that the HC Proxy proactively installs an observation on a "popular enough" resource and actively monitors: a. Its update pattern on the CoAP side; and b. The request pattern on the HTTP side; and uses the formula below to determine whether the observation should be kept alive or shut down. Let T_R be the mean time between two client requests to resource R, let T_C be the mean time between two representation changes of R, and let M_R be the mean number of CoAP messages per second exchanged to and from resource R. If we assume that the initial cost for establishing the observation is negligible, an observation on R reduces M_R if and only if T_R < 2*T_C with respect to using ETag validation, that is if and only if the mean arrival rate of requests for resource R is greater than half the change rate of R. When observing the resource R, M_R is always upper bounded by 2/T_C. 8.3. Use of CoAP Blockwise Transfer An HC Proxy SHOULD support CoAP blockwise transfers [RFC7959] to allow transport of large CoAP payloads while avoiding excessive link- layer fragmentation in constrained networks, and to cope with small datagram buffers in CoAP endpoints as described in [RFC7252] Section 4.6. An HC Proxy SHOULD attempt to retry a payload-carrying CoAP PUT or POST request with blockwise transfer if the destination CoAP server responded with 4.13 (Request Entity Too Large) to the original request. An HC Proxy SHOULD attempt to use blockwise transfer when sending a CoAP PUT or POST request message that is larger than Castellani, et al. Expires June 1, 2017 [Page 24] Internet-Draft HTTP-to-CoAP Mapping November 2016 BLOCKWISE_THRESHOLD bytes. The value of BLOCKWISE_THRESHOLD is implementation-specific; for example, it can be: o Calculated based on a known or typical UDP datagram buffer size for CoAP endpoints, or o Set to N times the known size of a link-layer frame in a constrained network where e.g., N=5, or o Preset to a known IP MTU value, or o Set to a known Path MTU value. The value BLOCKWISE_THRESHOLD, or the parameters from which it is calculated, should be configurable in a proxy implementation. The maximum block size the proxy will attempt to use in CoAP requests should also be configurable. The HC Proxy SHOULD detect CoAP endpoints not supporting blockwise transfers. This can be done by checking for a 4.02 (Bad Option) response returned by an endpoint in response to a CoAP request with a Block* Option, and subsequent absence of the 4.02 in response to the same request without Block* Options. This allows the HC Proxy to be more efficient, not attempting repeated blockwise transfers to CoAP servers that do not support it. 8.4. CoAP Multicast An HC Proxy MAY support CoAP multicast. If it does, the HC Proxy sends out a multicast CoAP request if the Target CoAP URI's authority is a multicast IP literal or resolves to a multicast IP address. If the HC Proxy does not support CoAP multicast, it SHOULD respond 403 (Forbidden) to any valid HTTP request that maps to a CoAP multicast request. Details related to supporting CoAP multicast are currently out of scope of this document since in a proxy scenario an HTTP client typically expects to receive a single response, not multiple. However, an HC Proxy that implements CoAP multicast may include application-specific functions to aggregate multiple CoAP responses into a single HTTP response. We suggest using the "application/http" internet media type (Section 8.3.2 of [RFC7230]) to enclose a set of one or more HTTP response messages, each representing the mapping of one CoAP response. For further considerations related to the handling of multicast requests, see Section 10.1. Castellani, et al. Expires June 1, 2017 [Page 25] Internet-Draft HTTP-to-CoAP Mapping November 2016 8.5. Timeouts If the CoAP server takes a long time in responding, the HTTP client or any other proxy in between may timeout. Further discussion of timeouts in HTTP is available in Section 6.2.4 of [RFC7230]. An HC Proxy MUST define an internal timeout for each pending CoAP request, because the CoAP server may silently die before completing the request. Assuming the Proxy uses confirmable CoAP requests, such timeout value T SHOULD be at least T = MAX_RTT + MAX_SERVER_RESPONSE_DELAY where MAX_RTT is defined in [RFC7252] and MAX_SERVER_RESPONSE_DELAY is defined in [RFC7390]. 9. IANA Considerations 9.1. New 'core.hc' Resource Type This document registers a new Resource Type (rt=) Link Target Attribute, 'core.hc', in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry. Attribute Value: core.hc Description: HTTP to CoAP mapping base resource. Reference: See Section 5.5. 9.2. New 'coap-payload' Internet Media Type This document defines the "application/coap-payload" media type with a single parameter "cf". This media type represents any payload that a CoAP message can carry, having a content format that can be identified by an integer in range 0-65535 corresponding to a CoAP Content-Format parameter ([RFC7252], Section 12.3). The parameter "cf" is the integer defining the CoAP content format. Type name: application Subtype name: coap-payload Required parameters: cf (CoAP Content-Format integer in range 0-65535 denoting the content format of the CoAP payload carried, as defined by the "CoAP Content-Formats" subregistry that is part of the "Constrained RESTful Environments (CoRE) Parameters" registry.) Castellani, et al. Expires June 1, 2017 [Page 26] Internet-Draft HTTP-to-CoAP Mapping November 2016 Optional parameters: None Encoding considerations: Common use is BINARY. The specific CoAP content format encoding considerations for the selected Content- Format (cf parameter) apply. The encoding can vary based on the value of the cf parameter. Security considerations: The specific CoAP content format security considerations for the selected Content-Format (cf parameter) apply. Interoperability considerations: This media type can never be used directly in CoAP messages because there are no means available to encode the mandatory 'cf' parameter in CoAP. Published specification: (this I-D - TBD) Applications that use this media type: HTTP-to-CoAP Proxies. Fragment identifier considerations: CoAP does not support URI fragments; therefore a CoAP payload fragment cannot be identified. Fragments are not applicable for this media type. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person and email address to contact for further information: Esko Dijk ("esko@ieee.org") Intended usage: COMMON Restrictions on usage: An application (or user) can only use this media type if it has to represent a CoAP payload of which the specified CoAP Content-Format is an unrecognized number; such that a proper translation directly to the equivalent HTTP media type is not possible. Author: CoRE WG Change controller: IETF Castellani, et al. Expires June 1, 2017 [Page 27] Internet-Draft HTTP-to-CoAP Mapping November 2016 Provisional registration: No 10. Security Considerations The security considerations in Section 9.2 of [RFC7230] apply in full to the HC Proxy. This section discusses security aspects and requirements that are specific to the deployment and operation of an HC Proxy. An HC Proxy located at the boundary of a constrained network is an easy single point of failure for reducing availability. As such, special care should be taken in designing, developing and operating it, keeping in mind that, in most cases, it has fewer limitations than the constrained devices it is serving. In particular, its quality of implementation and operation - i.e., use of current software development practices, careful selection of third party libraries, sane configuration defaults, an expedited way to upgrade a running instance - are all essential attributes of the HC Proxy. The correctness of request parsing in general (including any content transcoding), and of URI translation in particular, is essential to the security of the HC Proxy function. This is especially true when the internal network hosts devices with genuinely limited capabilities. For this purpose, see also Sections 9.3, 9.4, 9.5 and 9.6 of [RFC7230] for well-known issues related to HTTP request parsing and Section 11.1 of [RFC7252] for an overview of CoAP specific concerns related to URI processing - in particular, the potential impact on access control mechanisms that are based on URIs. An HC Proxy MUST implement TLS with PSK [RFC4279] and SHOULD implement TLS [RFC5246] with support for client authentication using X.509 certificates. A prerequisite of the latter is the availability of a Certification Authority (CA) to issue suitable certificates. Although this can be a challenging requirement in certain application scenarios, it is worth noting that there exist open-source tools (e.g., [OpenSSL]) that can be used to set up and operate an application-specific CA. By default, the HC Proxy MUST authenticate all incoming requests prior to forwarding them to the CoAP server. This default behavior MAY be explicitly disabled by an administrator. The following subparagraphs categorize and discuss a set of specific security issues related to the translation, caching and forwarding functionality exposed by an HC Proxy. Castellani, et al. Expires June 1, 2017 [Page 28] Internet-Draft HTTP-to-CoAP Mapping November 2016 10.1. Multicast Multicast requests impose a non-trivial cost on the constrained network and endpoints and might be exploited as a DoS attack vector (see also Section 10.2). From a privacy perspective, they can be used to gather detailed information about the resources hosted in the constrained network. For example, an outsider that is able to successfully query the /.well-known/core could obtain a comprehensive list of the target's home appliances and devices. From a security perspective, they can be used to carry out a network reconnaissance attack to gather information about possible vulnerabilities that could be exploited at a later point in time. For these reasons, it is RECOMMENDED that requests to multicast resources are access controlled with a default-deny policy. It is RECOMMENDED that the requestor of a multicast resource be strongly authenticated. If privacy and / or security are first class requirements, for example whenever the HTTP request transits through the public Internet, the request SHOULD be transported over a mutually authenticated and encrypted TLS connection. 10.2. Traffic Overflow Due to the typically constrained nature of CoAP nodes, particular attention should be given to the implementation of traffic reduction mechanisms (see Section 8.1), because an inefficient proxy implementations can be targeted by unconstrained Internet attackers. Bandwidth or complexity involved in such attacks is very low. An amplification attack to the constrained network may be triggered by a multicast request generated by a single HTTP request which is mapped to a CoAP multicast resource, as discussed in Section 11.3 of [RFC7252]. The risk likelihood of this amplification technique is higher than an amplification attack carried out by a malicious constrained device (e.g., ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a multicast destination [RFC4732]) since it does not require direct access to the constrained network. The feasibility of this attack, which disrupts availability of the targeted CoAP server, can be limited by access controlling the exposed multicast resources, so that only known/authorized users can access such URIs. Castellani, et al. Expires June 1, 2017 [Page 29] Internet-Draft HTTP-to-CoAP Mapping November 2016 10.3. Handling Secured Exchanges An HTTP request can be sent to the HC Proxy over a secured connection. However, there may not always exist a secure connection mapping to CoAP. For example, a secure distribution method for multicast traffic is complex and may not be implemented (see [RFC7390]). An HC Proxy should implement rules for security context translations. For example, all 'https' unicast requests are translated to 'coaps' requests, or 'https' requests are translated to unsecured 'coap' requests. Another rule could specify the security policy and parameters used for DTLS sessions [RFC7925]. Such rules will largely depend on the application and network context in which the HC Proxy operates. These rules should be configurable. It is RECOMMENDED that, by default, accessing a 'coaps' URI is only allowed from a corresponding 'https' URI. By default, an HC Proxy SHOULD reject any secured CoAP client request (i.e., one with a 'coaps' scheme) if there is no configured security policy mapping. This recommendation may be relaxed in case the destination network is believed to be secured by other means. Assuming that CoAP nodes are isolated behind a firewall as in the HC Proxy deployment shown in Figure 1, the HC Proxy may be configured to translate the incoming HTTPS request using plain CoAP (NoSec mode). 10.4. URI Mapping The following risks related to the URI mapping described in Section 5 and its use by HC Proxy have been identified: DoS attack on the constrained/CoAP network. Mitigation: by default deny any Target CoAP URI whose authority is (or maps to) a multicast address. Then explicitly white-list multicast resources/authorities that are allowed to be de- referenced. See also Section 8.4. Leaking information on the constrained/CoAP network resources and topology. Mitigation: by default deny any Target CoAP URI (especially /.well-known/core is a resource to be protected), and then explicitly white-list resources that are allowed to be seen from outside. The internal CoAP Target resource is totally transparent from outside. Castellani, et al. Expires June 1, 2017 [Page 30] Internet-Draft HTTP-to-CoAP Mapping November 2016 Mitigation: implement an HTTPS-only interface, which makes the Target CoAP URI totally opaque to a passive attacker. 11. Acknowledgments An initial version of Table 2 in Section 7 has been provided in revision -05 of the CoRE CoAP I-D. Special thanks to Peter van der Stok for countless comments and discussions on this document that contributed to its current structure and text. Thanks to Abhijan Bhattacharyya, Alexey Melnikov, Brian Frank, Carsten Bormann, Christian Amsuess, Christian Groves, Cullen Jennings, Dorothy Gellert, Francesco Corazza, Francis Dupont, Hannes Tschofenig, Jaime Jimenez, Kathleen Moriarty, Kepeng Li, Kerry Lynn, Klaus Hartke, Larry Masinter, Linyi Tian, Michele Rossi, Michele Zorzi, Nicola Bui, Peter Saint-Andre, Sean Leonard, Spencer Dawkins, Stephen Farrell, Suresh Krishnan, Zach Shelby for helpful comments and discussions that have shaped the document. The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n.251557. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Castellani, et al. Expires June 1, 2017 [Page 31] Internet-Draft HTTP-to-CoAP Mapping November 2016 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . Castellani, et al. Expires June 1, 2017 [Page 32] Internet-Draft HTTP-to-CoAP Mapping November 2016 12.2. Informative References [Fielding] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", PhD Dissertation, University of California, Irvine, ISBN 0-599-87118-0, 2000. [I-D.ietf-core-links-json] Li, K., Rahman, A., and C. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-06 (work in progress), July 2016. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", draft-ietf-core-resource-directory-09 (work in progress), October 2016. [OpenSSL] The OpenSSL Project, , "ca - sample minimal CA application", 1998-2016, . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, . [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, DOI 10.17487/RFC3040, January 2001, . [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . Castellani, et al. Expires June 1, 2017 [Page 33] Internet-Draft HTTP-to-CoAP Mapping November 2016 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . [W3C.REC-html5-20141028] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C Recommendation REC-html5-20141028, 2014, . Appendix A. Media Type Mapping Source Code #!/usr/bin/env python import unittest import re class CoAPContentFormatRegistry(object): """Map an Internet media type (and optional inherent encoding) to a CoAP content format. """ TEXT_PLAIN = 0 LINK_FORMAT = 40 XML = 41 OCTET_STREAM = 42 EXI = 47 JSON = 50 CBOR = 60 GROUP_JSON = 256 # http://www.iana.org/assignments/core-parameters/core-parameters.xhtml # as of 2016/10/24. LOOKUP_TABLE = { ("text/plain;charset=utf-8", None): TEXT_PLAIN, Castellani, et al. Expires June 1, 2017 [Page 34] Internet-Draft HTTP-to-CoAP Mapping November 2016 ("application/link-format", None): LINK_FORMAT, ("application/xml", None): XML, ("application/octet-stream", None): OCTET_STREAM, ("application/exi", None): EXI, ("application/json", None): JSON, ("application/cbor", None): CBOR, ("application/coap-group+json", "utf-8"): GROUP_JSON, } def lookup(self, media_type, encoding): """Return the CoAP Content Format matching the supplied media type (and optional encoding), or None if no match can be found.""" return CoAPContentFormatRegistry.LOOKUP_TABLE.get( (media_type, encoding), None) class LooseMediaTypeMapper(object): # Order matters in this table: more specific types have higher rank # compared to less specific types. # This code only performs a shallow validation of acceptable # characters, and assumes overall validation of media type and # subtype has been done beforehand. LOOKUP_TABLE = [ (re.compile("application/.+\+xml$"), "application/xml"), (re.compile("application/.+\+json$"), "application/json"), (re.compile("application/.+\+cbor$"), "application/cbor"), (re.compile("text/xml$"), "application/xml"), (re.compile("text/[a-z\.\-\+]+$"), "text/plain;charset=utf-8"), (re.compile("[a-z]+/[a-z\.\-\+]+$"), "application/octet-stream") ] def lookup(self, media_type): """Return the best loose media type match available using the contents of LOOKUP_TABLE.""" for entry in LooseMediaTypeMapper.LOOKUP_TABLE: if entry[0].match(media_type) is not None: return entry[1] return None def mt2cf(media_type, encoding=None, coap_cf_registry=CoAPContentFormatRegistry(), loose_mapper=None): """Return a CoAP Content-Format given an Internet Media Type and its optional encoding. The current (as of 2016/10/24) CoAP Content Format Registry is supplied by default. An optional 'loose-mapping' implementation can be supplied by the caller.""" Castellani, et al. Expires June 1, 2017 [Page 35] Internet-Draft HTTP-to-CoAP Mapping November 2016 assert media_type is not None assert coap_cf_registry is not None # Lookup the CoAP Content-Formats registry content_format = coap_cf_registry.lookup(media_type, encoding) # If an exact match is not found and a loose mapper has been # supplied, try to use it to get a media type with which to # re-try the CoAP Content-Formats registry lookup. if content_format is None and loose_mapper is not None: content_format = coap_cf_registry.lookup( loose_mapper.lookup(media_type), encoding) return content_format class TestMT2CF(unittest.TestCase): def testMissingContentType(self): with self.assertRaises(AssertionError): mt2cf(None) def testMissingContentFormatRegistry(self): with self.assertRaises(AssertionError): mt2cf(None, coap_cf_registry=None) def testTextPlain(self): self.assertEqual(mt2cf("text/plain;charset=utf-8"), CoAPContentFormatRegistry.TEXT_PLAIN) def testLinkFormat(self): self.assertEqual(mt2cf("application/link-format"), CoAPContentFormatRegistry.LINK_FORMAT) def testXML(self): self.assertEqual(mt2cf("application/xml"), CoAPContentFormatRegistry.XML) def testOctetStream(self): self.assertEqual(mt2cf("application/octet-stream"), CoAPContentFormatRegistry.OCTET_STREAM) def testEXI(self): self.assertEqual(mt2cf("application/exi"), CoAPContentFormatRegistry.EXI) def testJSON(self): self.assertEqual(mt2cf("application/json"), Castellani, et al. Expires June 1, 2017 [Page 36] Internet-Draft HTTP-to-CoAP Mapping November 2016 CoAPContentFormatRegistry.JSON) def testCBOR(self): self.assertEqual(mt2cf("application/cbor"), CoAPContentFormatRegistry.CBOR) def testCoAPGroupJSON(self): self.assertEqual(mt2cf("application/coap-group+json", "utf-8"), CoAPContentFormatRegistry.GROUP_JSON) def testUnknownMediaType(self): self.assertFalse(mt2cf("unknown/media-type")) def testLooseXML1(self): self.assertEqual( mt2cf( "application/somesubtype+xml", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.XML) def testLooseXML2(self): self.assertEqual( mt2cf( "text/xml", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.XML) def testLooseJSON(self): self.assertEqual( mt2cf( "application/somesubtype+json", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.JSON) def testLooseCBOR(self): self.assertEqual( mt2cf( "application/somesubtype+cbor", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.CBOR) def testLooseText(self): self.assertEqual( mt2cf( "text/somesubtype", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.TEXT_PLAIN) Castellani, et al. Expires June 1, 2017 [Page 37] Internet-Draft HTTP-to-CoAP Mapping November 2016 def testLooseUnknown(self): self.assertEqual( mt2cf( "application/somesubtype-of-some-sort+format", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.OCTET_STREAM) def testLooseInvalidStartsWithNonAlpha(self): self.assertFalse( mt2cf( " application/somesubtype", loose_mapper=LooseMediaTypeMapper())) def testLooseInvalidEndsWithUnexpectedChar(self): self.assertFalse( mt2cf( "application/somesubtype ", loose_mapper=LooseMediaTypeMapper())) def testLooseInvalidUnexpectedCharInTheMiddle(self): self.assertFalse( mt2cf( "application /somesubtype", loose_mapper=LooseMediaTypeMapper())) def testLooseInvalidNoSubType1(self): self.assertFalse( mt2cf( "application", loose_mapper=LooseMediaTypeMapper())) def testLooseInvalidNoSubType2(self): self.assertFalse( mt2cf( "application/", loose_mapper=LooseMediaTypeMapper())) if __name__ == "__main__": unittest.main(verbosity=2) Appendix B. Change Log [Note to RFC Editor: Please remove this section before publication.] Changes from ietf-16 to ietf-17: o Intended status from Informational to Standards Track; Castellani, et al. Expires June 1, 2017 [Page 38] Internet-Draft HTTP-to-CoAP Mapping November 2016 o Stephen Farrell's DISCUSS o Added 2.31 and 4.08 CoAP response codes to the Response Code Mapping table. o Editorial fixes Changes from ietf-15 to ietf-16 (Apps-Dir review): o Larry Masinter's comments. Changes from ietf-14 to ietf-15 (IESG review): o Kathleen Moriarty's DISCUSS and COMMENT; o Stephen Farrell's COMMENT; o Suresh Krishnan DISCUSS; o Spencer Dawkins' DISCUSS and COMMENT; Changes from ietf-13 to ietf-14: o Addressed Gen-ART and AD review comments. Changes from ietf-12 to ietf-13 (Christian Amsuess' comments): o More missing slashes in URI mapping template examples. Changes from ietf-11 to ietf-12 (2nd WGLC): o Addressed a few editorial issues (including a clarification on when to use qq vs q in the URI mapping template). o Fixed missing slash in one template example. o Added para about the need for future CoAP protocol elements to define their own HTTP mappings. Changes from ietf-10 to ietf-11 (Chair review): o Removed cu/su distinction from the URI mapping template. o Addressed a few editorial issues. Changes from ietf-09 to ietf-10: Castellani, et al. Expires June 1, 2017 [Page 39] Internet-Draft HTTP-to-CoAP Mapping November 2016 o Addressed Ticket #401 - Clarified that draft covers not only Reverse HC Proxy but that many parts also apply to Forward and Interception Proxies. o Clarified that draft concentrates on the HTTP-to-CoAP mapping direction (i.e., the HC Proxy is an HTTP server and a CoAP client). o Clarified the "null mapping" case where no CoAP URI information is embedded in the HTTP request URI. o Moved multicast related security text to the "Security Considerations" to consolidate all security information in one location. o Removed references to "placement" of proxy (e.g., server-side vs client-side) as is confusing and provides little added value. o Fixed version numbers on references that were corrupted in last revision due to outdated xml2rfc conversion tool local cache. o Various editorial improvements. Changes from ietf-08 to ietf-09: o Clean up requirements language as per Klaus' comment. Changes from ietf-07 to ietf-08: o Addressed WGLC review comments from Klaus Hartke as per the correspondence of March 9, 2016 on the CORE WG mailing list. Changes from ietf-06 to ietf-07: o Addressed Ticket #384 - Section 5.4.1 describes briefly (informative) how to discover CoAP resources from an HTTP client. o Addressed Ticket #378 - For HTTP media type to CoAP content format mapping and vice versa: a new draft (TBD) may be proposed in CoRE which describes an approach for automatic updating of the media type mapping. This was noted in Section 6.1 but is otherwise outside the scope of this draft. o Addressed Ticket #377 - Added IANA section that defines a new HTTP media type "application/coap-payload" and created new Section 6.2 on how to use it. Castellani, et al. Expires June 1, 2017 [Page 40] Internet-Draft HTTP-to-CoAP Mapping November 2016 o Addressed Ticket #376 - Updated Table 2 (and corresponding note 7) to indicate that a CoAP 4.05 (Method Not Allowed) Response Code should be mapped to an HTTP 400 (Bad Request). o Added note to comply to ABNF when translating CoAP diagnostic payload to reason-phrase in Section 6.5.3. Changes from ietf-05 to ietf-06: o Fully restructured the draft, bringing introductory text more to the front and allocating main sections to each of the key topics; addressing Ticket #379; o Addressed Ticket #382, fix of enhanced form URI template definition of q in Section 5.3.2; o Addressed Ticket #381, found a mapping 4.01 to 401 Unauthorized in Section 7; o Addressed Ticket #380 (Add IANA registration for "core.hc" Resource Type) in Section 9; o Addressed Ticket #376 (CoAP 4.05 response can't be translated to HTTP 405 by HC Proxy) in Section 7 by use of empty 'Allow' header; o Removed details on the pros and cons of HC Proxy placement options; o Addressed review comments of Carsten Bormann; o Clarified failure in mapping of HTTP Accept headers (Section 6.3); o Clarified detection of CoAP servers not supporting blockwise (Section 8.3); o Changed CoAP request timeout min value to MAX_RTT + MAX_SERVER_RESPONSE_DELAY (Section 8.6); o Added security section item (Section 10.3) related to use of CoAP blockwise transfers; o Many editorial improvements. Changes from ietf-04 to ietf-05: o Addressed Ticket #366 (Mapping of CoRE Link Format payloads to be valid in HTTP Domain?) in Section 6.3.3.2 (Content Transcoding - CORE Link Format); Castellani, et al. Expires June 1, 2017 [Page 41] Internet-Draft HTTP-to-CoAP Mapping November 2016 o Addressed Ticket #375 (Add requirement on mapping of CoAP diagnostic payload) in Section 6.3.3.3 (Content Transcoding - Diagnostic Messages); o Addressed comment from Yusuke (http://www.ietf.org/mail- archive/web/core/current/msg05491.html) in Section 6.3.3.1 (Content Transcoding - General); o Various editorial improvements. Changes from ietf-03 to ietf-04: o Expanded use case descriptions in Section 4; o Fixed/enhanced discovery examples in Section 5.4.1; o Addressed Ticket #365 (Add text on media type conversion by HTTP- CoAP proxy) in new Section 6.3.1 (Generalized media type mapping) and new Section 6.3.2 (Content translation); o Updated HTTPBis WG draft references to recently published RFC numbers. o Various editorial improvements. Changes from ietf-02 to ietf-03: o Closed Ticket #351 "Add security implications of proposed default HTTP-CoAP URI mapping"; o Closed Ticket #363 "Remove CoAP scheme in default HTTP-CoAP URI mapping"; o Closed Ticket #364 "Add discovery of HTTP-CoAP mapping resource(s)". Changes from ietf-01 to ietf-02: o Selection of single default URI mapping proposal as proposed to WG mailing list 2013-10-09. Changes from ietf-00 to ietf-01: o Added URI mapping proposals to Section 4 as per the Email proposals to WG mailing list from Esko. Castellani, et al. Expires June 1, 2017 [Page 42] Internet-Draft HTTP-to-CoAP Mapping November 2016 Authors' Addresses Angelo P. Castellani University of Padova Via Gradenigo 6/B Padova 35131 Italy Email: angelo@castellani.net Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal H3A 3G4 Canada Phone: +1 514 585 0761 Email: Akbar.Rahman@InterDigital.com Thomas Fossati Nokia 3 Ely Road Milton, Cambridge CB24 6DD UK Email: thomas.fossati@nokia.com Esko Dijk Philips Lighting High Tech Campus 7 Eindhoven 5656 AE The Netherlands Email: esko.dijk@philips.com Castellani, et al. Expires June 1, 2017 [Page 43] ./draft-ietf-eppext-keyrelay-12.txt0000664000764400076440000010231312723255340016510 0ustar iustyiusty eppext H.W. Ribbers Internet-Draft M.W. Groeneweg Intended status: Standards Track SIDN Expires: December 2, 2016 R. Gieben A.L.J Verschuren May 31, 2016 Key Relay Mapping for the Extensible Provisioning Protocol draft-ietf-eppext-keyrelay-12 Abstract This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC5730. This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 2, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Ribbers, et al. Expires December 2, 2016 [Page 1] Internet-Draft EPP Keyrelay May 2016 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.2. Secure Transfer of DNSSEC Key Material . . . . . . . . . 3 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 2.1. DNSSEC Key Material . . . . . . . . . . . . . . . . . . . 5 2.1.1. element . . . . . . . . . . . . . . . 5 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 6 3.1.3. EPP Command . . . . . . . . . . . . . . . 9 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 9 3.2.1. EPP Command . . . . . . . . . . . . . . . . 9 3.2.2. EPP Command . . . . . . . . . . . . . . . . 11 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 11 3.2.4. EPP Command . . . . . . . . . . . . . . . 12 3.2.5. EPP Command . . . . . . . . . . . . . . . . 12 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13 5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 16 A.1. draft-gieben-epp-keyrelay-00 . . . . . . . . . . . . . . 16 A.2. draft-gieben-epp-keyrelay-01 . . . . . . . . . . . . . . 16 A.3. draft-gieben-epp-keyrelay-02 . . . . . . . . . . . . . . 16 A.4. draft-gieben-epp-keyrelay-03 . . . . . . . . . . . . . . 16 A.5. draft-ietf-eppext-keyrelay-00 . . . . . . . . . . . . . . 17 A.6. draft-ietf-eppext-keyrelay-01 . . . . . . . . . . . . . . 17 A.7. draft-ietf-eppext-keyrelay-02 . . . . . . . . . . . . . . 17 A.8. draft-ietf-eppext-keyrelay-03 . . . . . . . . . . . . . . 17 A.9. draft-ietf-eppext-keyrelay-04 . . . . . . . . . . . . . . 17 A.10. draft-ietf-eppext-keyrelay-05 . . . . . . . . . . . . . . 18 A.11. draft-ietf-eppext-keyrelay-06 . . . . . . . . . . . . . . 18 A.12. draft-ietf-eppext-keyrelay-07 . . . . . . . . . . . . . . 18 Ribbers, et al. Expires December 2, 2016 [Page 2] Internet-Draft EPP Keyrelay May 2016 A.13. draft-ietf-eppext-keyrelay-08 . . . . . . . . . . . . . . 18 A.14. draft-ietf-eppext-keyrelay-09 . . . . . . . . . . . . . . 18 A.15. draft-ietf-eppext-keyrelay-10 . . . . . . . . . . . . . . 18 A.16. draft-ietf-eppext-keyrelay-11 . . . . . . . . . . . . . . 18 A.17. draft-ietf-regext-keyrelay-00 . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction There are certain transactions initiated by a DNS-operator that require an authenticated exchange of information between DNS- operators. Often, there is no direct channel between these parties or it is non-scalable and insecure. One such transaction is the exchange of DNSSEC key material when changing the DNS operator for DNSSEC signed zones. We suggest that DNS-operators use the administrative EPP channel to bootstrap the delegation by relaying DNSSEC key material for the zone. In this document we define an EPP extension to sent DNSSEC key material between EPP clients. This allows DNS operators to bootstrap automatically, reliable and securely the transfer of a domain name while keeping the DNSSEC chain of trust intact. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. In examples, "C:" represents lines sent by a protocol client, and "S:" represents lines returned by a protocol server. Indentation and white space in examples is provided only to illustrate element relationships and is not a mandatory feature of this protocol. 1.2. Secure Transfer of DNSSEC Key Material Exchanging DNSSEC key material in preparation of a domain name transfer is one of the phases in the lifecycle of a domain name [I-D.koch-dnsop-dnssec-operator-change]. Ribbers, et al. Expires December 2, 2016 [Page 3] Internet-Draft EPP Keyrelay May 2016 DNS-operators need to exchange DNSSEC key material before the registration data can be changed to keep the DNSSEC chain of trust intact. This exchange is normally initiated through the gaining registrar. The gaining and losing DNS operators could talk directly to each other (the ~ arrow in Figure 1) to exchange the DNSKEY, but often there is no trusted path between the two. As both can securely interact with the registry over the administrative channel through the registrar, the registry can act as a relay for the key material exchange. The registry is merely used as a relay channel. Therefore it is up to the losing DNS-operator to complete the intended transaction. The registry SHOULD have certain policies in place that require the losing DNS operator to cooperate with this transaction, however this is beyond this document. This document focuses on the EPP protocol syntax. +--------------------+ DNSKEY +---------------------+ |gaining DNS operator| ~~~~~~~~> | losing DNS operator | +--------------------+ +---------------------+ | ^ | | V | +--------------------+ +---------------------+ | gaining registrar | | registrar of record | +--------------------+ +---------------------+ | ^ EPP keyrelay | | EPP poll V | +-----------------------------+ | registry | +-----------------------------+ Figure 1: Transfer of DNSSEC key material. There is no distinction in the EPP protocol between Registrars and DNS-operators, there is only mention of an EPP client and EPP server. Therefore the term EPP client will be used for the interaction with the EPP server for relaying DNSSEC key material. 2. Object Attributes Ribbers, et al. Expires December 2, 2016 [Page 4] Internet-Draft EPP Keyrelay May 2016 2.1. DNSSEC Key Material The DNSSEC key material is represented in EPP by a element. 2.1.1. element The contains the following elements: o One REQUIRED element that contains the DNSSEC key material as described in [RFC5910], Section 4 o An OPTIONAL element that describes the expected lifetime of the relayed key(s) in the zone. When the element is provided the losing DNS operator SHOULD remove the inserted key material from the zone after the expire time. This may be because the transaction that needed the insertion should either be completed or abandoned by that time. If a client receives a key relay object that has been sent previously it MUST update the expire time of the key material. This enables the clients to update the lifetime of the key material when a transfer is delayed. The element MUST contain exactly one of the following child elements: * : The DNSSEC key material is valid from the current date and time until it expires on the specified date and time. If a date in the past is provided this MUST be interpreted as a revocation of a previously sent key relay object. * : The DNSSEC key material is valid from the current date and time until the end of the specified duration. If a period of zero is provided this MUST be interpreted as a revocation of a previously sent key relay object. 3. EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mapping described here is specifically for use in this key relay mapping. 3.1. EPP Query Commands EPP provides three commands to retrieve object information: to determine if an object is known to the server, to retrieve Ribbers, et al. Expires December 2, 2016 [Page 5] Internet-Draft EPP Keyrelay May 2016 detailed information associated with an object, and to retrieve object transfer status information. 3.1.1. EPP Command Check semantics do not apply to key relay objects, so there is no mapping defined for the EPP command and the EPP response. 3.1.2. EPP Command Info command semantics do not apply to the key relay objects, so there is no mapping defined for the EPP Command. The EPP response for key relay objects is used in the EPP poll response, as described in [RFC5730]. The key relay object created with the command, described in Section 3.2.1 is inserted into the receiving client's poll queue. The receiving client will receive the key relay object using the EPP command, as described in [RFC5730]. When a command has been processed successfully for a key relay poll message, the EPP element MUST contain a child element that is identified by the keyrelay namespace. The element contains the following child elements: o A REQUIRED element containing the domain name for which the DNSSEC key material is relayed. o A REQUIRED element that contains authorization information associated with the domain object ([RFC5731], Section 3.2.1). o One or more REQUIRED elements containing data to be relayed, as defined in Section 2.1. A server MAY apply a server policy that specifies the number of elements that can be incorporated. When a server policy is violated, a server MUST respond with an EPP result code 2308 "Data management policy violation". o An OPTIONAL element that contains the date and time of the submitted command. o An OPTIONAL element that contains the identifier of the client that requested the key relay. Ribbers, et al. Expires December 2, 2016 [Page 6] Internet-Draft EPP Keyrelay May 2016 o An OPTIONAL element that contains the identifier of the client that SHOULD act upon the key relay. Example response: Ribbers, et al. Expires December 2, 2016 [Page 7] Internet-Draft EPP Keyrelay May 2016 S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 1999-04-04T22:01:00.0Z S: Keyrelay action completed successfully. S: S: S: S: example.org S: S: JnSdBAZSxxzJ S: S: S: S: 256 S: 3 S: 8 S: cmlraXN0aGViZXN0 S: S: S: P1M13D S: S: S: S: 1999-04-04T22:01:00.0Z S: S: S: ClientX S: S: S: ClientY S: S: S: S: S: ABC-12345 S: 54321-ZYX S: S: S: Ribbers, et al. Expires December 2, 2016 [Page 8] Internet-Draft EPP Keyrelay May 2016 3.1.3. EPP Command Transfer semantics do not apply to key relay objects, so there is no mapping defined for the EPP command. 3.2. EPP Transform Commands EPP provides five commands to transform objects: to create an instance of an object, to delete an instance of an object, to extend the validity period of an object, to manage object sponsorship changes, and to change information associated with an object. 3.2.1. EPP Command The EPP command provides a transform operation that allows a client to create a key relay object that includes the domain name and DNSSEC key material to be relayed. When the command is validated, the server MUST insert an EPP message, using the key relay info response (See Section 3.1.2), in the receiving client's poll queue that belongs to the registrar on record of the provided domain name. In addition to the standard EPP command elements, the command MUST contain a element that is identified by the keyrelay namespace. The element contains the following child elements: o A REQUIRED element containing the domain name for which the DNSSEC key material is relayed. o A REQUIRED element that contains authorization information associated with the domain object ([RFC5731], Section 3.2.1). o One or more REQUIRED element containing data to be relayed, as defined in Section 2.1 Example commands: Note that in the provided example the second element has a period of zero and thus represents the revocation of a previously sent key relay object (see Section 2.1.1). Ribbers, et al. Expires December 2, 2016 [Page 9] Internet-Draft EPP Keyrelay May 2016 C: C: C: C: C: C: example.org C: C: JnSdBAZSxxzJ C: C: C: C: 256 C: 3 C: 8 C: cmlraXN0aGViZXN0 C: C: C: P1M13D C: C: C: C: C: 256 C: 3 C: 8 C: bWFyY2lzdGhlYmVzdA== C: C: C: P0D C: C: C: C: C: ABC-12345 C: C: When a server has succesfully processed the command it MUST respond with a standard EPP response. See [RFC5730], Section 2.6. Example response: Ribbers, et al. Expires December 2, 2016 [Page 10] Internet-Draft EPP Keyrelay May 2016 S: S: S: S: S: Command completed successfully S: S: S: ABC-12345 S: 54321-ZYX S: S: S: When a server cannot process the command due to the server policy it MUST return an EPP 2308 error message. This might be the case when the server knows that the receiving client does not support keyrelay transactions. See [RFC5730], Section 2.6. Example response: S: S: S: S: S: Data management policy violation S: S: S: ABC-12345 S: 54321-ZYX S: S: S: 3.2.2. EPP Command Delete semantics do not apply to key relay objects, so there is no mapping defined for the EPP command and the EPP response. 3.2.3. EPP Command Renew semantics do not apply to key relay objects, so there is no mapping defined for the EPP command and the EPP response. Ribbers, et al. Expires December 2, 2016 [Page 11] Internet-Draft EPP Keyrelay May 2016 3.2.4. EPP Command Transfer semantics do not apply to key relay objects, so there is no mapping defined for the EPP command and the EPP response. 3.2.5. EPP Command Update semantics do not apply to key relay objects, so there is no mapping defined for the EPP command and the EPP response. 4. Formal Syntax Extensible Provisioning Protocol v1.0 protocol extension schema for relaying DNSSEC key material. Ribbers, et al. Expires December 2, 2016 [Page 12] Internet-Draft EPP Keyrelay May 2016 5. IANA Considerations 5.1. XML Namespace This document uses URNs to describe a XML namespace conforming to the registry mechanism described in [RFC3688]. The following URI assignment is requested of IANA: URI: urn:ietf:params:xml:ns:keyrelay-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: See the "Formal Syntax" section of this document. 5.2. XML Schema This document uses URNs to describe a XML schema conforming to the registry mechanism described in [RFC3688]. The following URI assignment is requested of IANA: Ribbers, et al. Expires December 2, 2016 [Page 13] Internet-Draft EPP Keyrelay May 2016 URI: urn:ietf:params:xml:schema:keyrelay-1.0 XML: See the "Formal Syntax" section of this document. 5.3. EPP Extension Registry The EPP extension described in this document should be registered by the IANA in the EPP Extension Registry described in [RFC7451]. The details of the registration are as follows: Name of Extension: "Key Relay Mapping for the Extensible Provisioning Protocol" Document status: Standards Track Reference: (insert reference to RFC version of this document) Registrant Name and Email Address: IESG, iesg@ietf.org TLDs: Any IPR Disclosure: https://datatracker.ietf.org/ipr/2393/ Status: Active Notes: None 6. Security Considerations A server SHOULD NOT perform any transformation on data under server management when processing a command. The intent of this command is to put DNSSEC key material on the poll queue of another client. To make sure that this EPP extension is interoperable with the different server policies that already have implemented EPP this extension it is not classified as must not. Any EPP client can use this mechanism to put data on the message queue of another EPP client, allowing for the potential of a denial of service attack. However this can, and should be detected by the server. A server MAY set a server policy which limits or rejects a command if it detects the mechanism is being abused. For the data a correct element should be used as an indication that putting the key material on the receiving EPP clients poll queue is authorized by the _registrant_ of that domain name. The authorization of EPP clients Ribbers, et al. Expires December 2, 2016 [Page 14] Internet-Draft EPP Keyrelay May 2016 to perform DNS changes is not covered in this document as it depends on registry specific policy. A client that uses this mechanism to send DNSSEC key material to another client could verify through DNS that the DNSSEC key material is added to the authoritive zone of the domain. This check can be used to verify that the DNSSEC key material has traveled end-to-end from the gaining DNS operator to the losing DNS operator. This check does not tell anything about the DNSSEC chain of trust and can merely be used as a verification of a succesful transfer of the DNSSEC key material. 7. Acknowledgements We like to thank the following individuals for their valuable input, review, constructive criticism in earlier revisions or support for the concepts described in this document: Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer and Scott Hollenbeck. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009. [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, August 2009. [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010. 8.2. Informative References Ribbers, et al. Expires December 2, 2016 [Page 15] Internet-Draft EPP Keyrelay May 2016 [I-D.koch-dnsop-dnssec-operator-change] Koch, P., Sanz, M., and A. Verschuren, "Changing DNS Operators for DNSSEC signed Zones", draft-koch-dnsop- dnssec-operator-change-06 (work in progress), February 2014. [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, February 2015. Appendix A. Changelog [This section should be removed by the RFC editor before publishing] A.1. draft-gieben-epp-keyrelay-00 1. Initial document. A.2. draft-gieben-epp-keyrelay-01 1. Style and grammar changes; 2. Added an expire element as per suggestion by Klaus Malorny; 3. Make the authInfo element mandatory and make the registry check it as per feedback by Klaus Malorny and James Gould. A.3. draft-gieben-epp-keyrelay-02 1. Added element to identify the relaying EPP client as suggested by Klaus Malorny; 2. Corrected XML for missing and excess clTRID as noted by Patrick Mevzek; 3. Added clarifications for the examples based on feedback by Patrick Mevzeck; 4. Reviewed the consistency of using DNS operator versus registrar after review comments by Patrick Faltstrom and Ed Lewis. A.4. draft-gieben-epp-keyrelay-03 1. Style and grammar changes 2. Corrected acknowledgement section 3. Corrected XML for Expire element to not be mandatory but only occur once. Ribbers, et al. Expires December 2, 2016 [Page 16] Internet-Draft EPP Keyrelay May 2016 A.5. draft-ietf-eppext-keyrelay-00 1. Added feedback from Seth Goldman and put him in the acknowledgement section. 2. IDnits formatting ajustments A.6. draft-ietf-eppext-keyrelay-01 1. Introducing the command, and thus separating the data and the command. 2. Updated the Introduction, describing the general use of relay vs the intended use-case of relaying DNSSEC key data. 3. Restructuring the document to make it more inline with existing EPP extensions. A.7. draft-ietf-eppext-keyrelay-02 1. Updated the XML structure by removing the command based on WG feedback 2. Updated the wording A.8. draft-ietf-eppext-keyrelay-03 1. Updated the document title in the EPP Extension Registry section 2. Restored Acknowledgement section, thanks to Marco Davids 3. Incorperated feedback from Patrick Mevzek A.9. draft-ietf-eppext-keyrelay-04 1. Incorperated feedback from James Gould 2. Added additional text when server is aware that receiving clients do not support keyrelay transactions or DNSSEC as suggested by Kees Monshouwer. 3. Added additional text for supporting key revocation as suggested by Kees Monshouwer 4. Updated some of the wording 5. Fix the usage of multiple keys in a create message Ribbers, et al. Expires December 2, 2016 [Page 17] Internet-Draft EPP Keyrelay May 2016 A.10. draft-ietf-eppext-keyrelay-05 1. Review comments after WG last call A.11. draft-ietf-eppext-keyrelay-06 1. Review comments by Ulrich Wisser during IESG writeup A.12. draft-ietf-eppext-keyrelay-07 1. fixed changelog A.13. draft-ietf-eppext-keyrelay-08 1. fixed issue with authinfo 2. fixed issue with relative period in example xml A.14. draft-ietf-eppext-keyrelay-09 1. fixed issue with naming A.15. draft-ietf-eppext-keyrelay-10 1. removed 4 spaces A.16. draft-ietf-eppext-keyrelay-11 1. Processed editorial changes from AD review 2. Processed comments made during IETF last call A.17. draft-ietf-regext-keyrelay-00 1. Processed comments made during IESG review Authors' Addresses Rik Ribbers SIDN Meander 501 Arnhem 6825 MD NL Email: rik.ribbers@sidn.nl URI: https://www.sidn.nl/ Ribbers, et al. Expires December 2, 2016 [Page 18] Internet-Draft EPP Keyrelay May 2016 Marc Groeneweg SIDN Meander 501 Arnhem 6825 MD NL Email: marc.groeneweg@sidn.nl URI: https://www.sidn.nl/ Miek Gieben Email: miek@miek.nl Antoin Verschuren Email: ietf@antoin.nl Ribbers, et al. Expires December 2, 2016 [Page 19] ./draft-ietf-hip-rfc5206-bis-14.txt0000664000764400076440000026570212777023032016016 0ustar iustyiusty Network Working Group T. Henderson, Ed. Internet-Draft University of Washington Obsoletes: 5206 (if approved) C. Vogt Intended status: Standards Track Independent Expires: April 13, 2017 J. Arkko Ericsson October 10, 2016 Host Mobility with the Host Identity Protocol draft-ietf-hip-rfc5206-bis-14 Abstract This document defines a mobility extension to the Host Identity Protocol (HIP). Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts. The same LOCATOR_SET parameter can also be used to support end-host multihoming (specified in RFC[Replace with the RFC number for draft- ietf-hip-multihoming]). This document obsoletes RFC 5206. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 13, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Henderson, et al. Expires April 13, 2017 [Page 1] Internet-Draft HIP Host Mobility October 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 7 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 9 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mobility messaging through rendezvous server . . . . 11 3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 12 3.3. Other Considerations . . . . . . . . . . . . . . . . . . 12 3.3.1. Address Verification . . . . . . . . . . . . . . . . 12 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 13 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14 4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 15 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 17 4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 17 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Locator Data Structure and Status . . . . . . . . . . . . 18 5.2. Sending the LOCATOR_SET . . . . . . . . . . . . . . . . . 19 5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 20 5.4. Verifying Address Reachability . . . . . . . . . . . . . 22 5.5. Changing the Preferred Locator . . . . . . . . . . . . . 23 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 24 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 24 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 29 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 30 6.4. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. Differences from RFC 5206 . . . . . . . . . . . . . . . . . . 31 Henderson, et al. Expires April 13, 2017 [Page 2] Internet-Draft HIP Host Mobility October 2016 9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Normative references . . . . . . . . . . . . . . . . . . 33 10.2. Informative references . . . . . . . . . . . . . . . . . 34 Appendix A. Document Revision History . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction and Scope The Host Identity Protocol [RFC7401] (HIP) supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities. When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) are instead bound to representations of these host identities, and the IP addresses are only used for packet forwarding. However, each host needs to also know at least one IP address at which its peers are reachable. Initially, these IP addresses are the ones used during the HIP base exchange. One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. There are potentially many variations of mobility and multihoming possible. The scope of this document encompasses messaging and elements of procedure for basic network-level host mobility, leaving more complicated mobility scenarios, multihoming, and other variations for further study. More specifically, the following are in scope: This document defines a LOCATOR_SET parameter for use in HIP messages. The LOCATOR_SET parameter allows a HIP host to notify a peer about alternate locators at which it is reachable. The locators may be merely IP addresses, or they may have additional multiplexing and demultiplexing context to aid with the packet handling in the lower layers. For instance, an IP address may need to be paired with an ESP Security Parameter Index (SPI) so that packets are sent on the correct SA for a given address. This document also specifies the messaging and elements of procedure for end-host mobility of a HIP host. In particular, message flows to enable successful host mobility, including address verification methods, are defined herein. The HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] can be used to manage simultaneous mobility of both hosts, initial reacahability of a mobile host, location privacy, and some modes of NAT traversal. Use of the HIP rendezvous server to manage the simultaneous mobility of both hosts is specified herein. Henderson, et al. Expires April 13, 2017 [Page 3] Internet-Draft HIP Host Mobility October 2016 The following topics are out of scope: While the same LOCATOR_SET parameter supports host multihoming (simultaneous use of a number of addresses), procedures for host multihoming are out of scope, and are specified in [I-D.ietf-hip-multihoming]. While HIP can potentially be used with transports other than the ESP transport format [RFC7402], this document largely assumes the use of ESP and leaves other transport formats for further study. We do not consider localized mobility management extensions (i.e., mobility management techniques that do not involve directly signaling the correspondent node); this document is concerned with end-to-end mobility. Finally, making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document. The main sections of this document are organized as follows. Section 3 provides a summary overview of operations, scenarios, and other considerations. Section 4 specifies the messaging parameter syntax. Section 5 specifies the processing rules for messages. Section 6 describes security considerations for this specification. 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. LOCATOR_SET. A HIP parameter containing zero or more Locator fields. Locator. A name that controls how the packet is routed through the network and demultiplexed by the end host. It may include a concatenation of traditional network addresses such as an IPv6 address and end-to-end identifiers such as an ESP SPI. It may also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a network address. Address. A name that denotes a point-of-attachment to the network. The two most common examples are an IPv4 address and an IPv6 address. The set of possible addresses is a subset of the set of possible locators. Henderson, et al. Expires April 13, 2017 [Page 4] Internet-Draft HIP Host Mobility October 2016 Preferred locator. A locator on which a host prefers to receive data. Certain locators are labelled as preferred when a host advertises its locator set to its peer. By default, the locators used in the HIP base exchange are the preferred locators. The use of preferred locators, including the scenario where multiple address scopes and families may be in use, is defined more in [I-D.ietf-hip-multihoming] than in this document. Credit Based Authorization. A mechanism allowing a host to send a certain amount of data to a peer's newly announced locator before the result of mandatory address verification is known. 3. Protocol Model This section is an overview; more detailed specification follows this section. 3.1. Operating Environment The Host Identity Protocol (HIP) [RFC7401] is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities, and establishing security associations (SAs) for the ESP transport format [RFC7402] and possibly other protocols in the future. +--------------------+ +--------------------+ | | | | | +------------+ | | +------------+ | | | Key | | HIP | | Key | | | | Management | <-+-----------------------+-> | Management | | | | Process | | | | Process | | | +------------+ | | +------------+ | | ^ | | ^ | | | | | | | | v | | v | | +------------+ | | +------------+ | | | IPsec | | ESP | | IPsec | | | | Stack | <-+-----------------------+-> | Stack | | | | | | | | | | | +------------+ | | +------------+ | | | | | | | | | | Initiator | | Responder | +--------------------+ +--------------------+ Figure 1: HIP Deployment Model Henderson, et al. Expires April 13, 2017 [Page 5] Internet-Draft HIP Host Mobility October 2016 The general deployment model for HIP is shown above, assuming operation in an end-to-end fashion. This document specifies an extension to the HIP protocol to enable end-host mobility. In summary, these extensions to the HIP base protocol enable the signaling of new addressing information to the peer in HIP messages. The messages are authenticated via a signature or keyed hash message authentication code (HMAC) based on its Host Identity. This document specifies the format of this new addressing (LOCATOR_SET) parameter, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for a concurrent address verification mechanism. --------- | TCP | (sockets bound to HITs) --------- | --------- ----> | ESP | {HIT_s, HIT_d} <-> SPI | --------- | | ---- --------- | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} ---- --------- | --------- | IP | --------- Figure 2: Architecture for HIP Host Mobility (MH) Figure 2 depicts a layered architectural view of a HIP-enabled stack using the ESP transport format. In HIP, upper-layer protocols (including TCP and ESP in this figure) are bound to Host Identity Tags (HITs) and not IP addresses. The HIP sublayer is responsible for maintaining the binding between HITs and IP addresses. The SPI is used to associate an incoming packet with the right HITs. The block labeled "MH" is introduced below. Consider first the case in which there is no mobility or multihoming, as specified in the base protocol specification [RFC7401]. The HIP base exchange establishes the HITs in use between the hosts, the SPIs to use for ESP, and the IP addresses (used in both the HIP signaling packets and ESP data packets). Note that there can only be one such set of bindings in the outbound direction for any given packet, and the only fields used for the binding at the HIP layer are the fields exposed by ESP (the SPI and HITs). For the inbound direction, the SPI is all that is required to find the right host context. ESP Henderson, et al. Expires April 13, 2017 [Page 6] Internet-Draft HIP Host Mobility October 2016 rekeying events change the mapping between the HIT pair and SPI, but do not change the IP addresses. Consider next a mobility event, in which a host moves to another IP address. Two things need to occur in this case. First, the peer needs to be notified of the address change using a HIP UPDATE message. Second, each host needs to change its local bindings at the HIP sublayer (new IP addresses). It may be that both the SPIs and IP addresses are changed simultaneously in a single UPDATE; the protocol described herein supports this. Although internal notification of transport layer protocols regarding the path change (e.g. to reset congestion control variables) may be desired, this specification does not address such internal notification. In addition, elements of procedure for traversing network address translators (NATs) and firewalls, including NATs and firewalls that may understand the HIP protocol, may complicate the above basic scenario and are not covered by this document. 3.1.1. Locator This document defines a generalization of an address called a "locator". A locator specifies a point-of-attachment to the network but may also include additional end-to-end tunneling or per-host demultiplexing context that affects how packets are handled below the logical HIP sublayer of the stack. This generalization is useful because IP addresses alone may not be sufficient to describe how packets should be handled below HIP. For example, in a host multihoming context, certain IP addresses may need to be associated with certain ESP SPIs to avoid violating the ESP anti-replay window. Addresses may also be affiliated with transport ports in certain tunneling scenarios. Locators may simply be traditional network addresses. The format of the locator fields in the LOCATOR_SET parameter is defined in Section 4. 3.1.2. Mobility Overview When a host moves to another address, it notifies its peer of the new address by sending a HIP UPDATE packet containing a single LOCATOR_SET parameter and a single ESP_INFO parameter. This UPDATE packet is acknowledged by the peer. For reliability in the presence of packet loss, the UPDATE packet is retransmitted as defined in the HIP protocol specification [RFC7401]. The peer can authenticate the contents of the UPDATE packet based on the signature and keyed hash of the packet. When using ESP Transport Format [RFC7402], the host may at the same time decide to rekey its security association and possibly generate a new Diffie-Hellman key; all of these actions are triggered by Henderson, et al. Expires April 13, 2017 [Page 7] Internet-Draft HIP Host Mobility October 2016 including additional parameters in the UPDATE packet, as defined in the base protocol specification [RFC7401] and ESP extension [RFC7402]. When using ESP (and possibly other transport modes in the future), the host is able to receive packets that are protected using a HIP created ESP SA from any address. Thus, a host can change its IP address and continue to send packets to its peers without necessarily rekeying. However, the peers are not able to send packets to these new addresses before they can reliably and securely update the set of addresses that they associate with the sending host. Furthermore, mobility may change the path characteristics in such a manner that reordering occurs and packets fall outside the ESP anti-replay window for the SA, thereby requiring rekeying. 3.2. Protocol Overview In this section, we briefly introduce a number of usage scenarios for HIP host mobility. These scenarios assume that HIP is being used with the ESP transform [RFC7402], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC7401] and with the use of ESP with HIP [RFC7402]. According to these specifications, the data traffic in a HIP session is protected with ESP, and the ESP SPI acts as an index to the right host-to-host context. More specification details are found later in Section 4 and Section 5. The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Both of the hosts therefore have one incoming and one outgoing SA. Further, each SA uses the same pair of IP addresses, which are the ones used in the base exchange. The readdressing protocol is an asymmetric protocol where a mobile host informs a peer host about changes of IP addresses on affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. In support of mobility, the LOCATOR_SET parameter is carried in UPDATE packets. The scenarios below at times describe addresses as being in either an ACTIVE, UNVERIFIED, or DEPRECATED state. From the perspective of a host, newly-learned addresses of the peer needs to be verified before put into active service, and addresses removed by the peer are put into a deprecated state. Under limited conditions described below (Section 5.6), an UNVERIFIED address may be used. The addressing states are defined more formally in Section 5.1. Henderson, et al. Expires April 13, 2017 [Page 8] Internet-Draft HIP Host Mobility October 2016 Hosts that use link-local addresses as source addresses in their HIP handshakes may not be reachable by a mobile peer. Such hosts SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR_SET parameter. 3.2.1. Mobility with a Single SA Pair (No Rekeying) A mobile host sometimes needs to change an IP address bound to an interface. The change of an IP address might be needed due to a change in the advertised IPv6 prefixes on the link, a reconnected PPP link, a new DHCP lease, or an actual movement to another subnet. In order to maintain its communication context, the host needs to inform its peers about the new IP address. This first example considers the case in which the mobile host has only one interface, one IP address in use within the HIP session, a single pair of SAs (one inbound, one outbound), and no rekeying occurs on the SAs. We also assume that the new IP addresses are within the same address family (IPv4 or IPv6) as the previous address. This is the simplest scenario, depicted in Figure 3. Note that the conventions for message parameter notations in figures (use of parentheses and brackets) is defined in Section 2.2 of [RFC7401]. Mobile Host Peer Host UPDATE(ESP_INFO, LOCATOR_SET, SEQ) -----------------------------------> UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> Figure 3: Readdress without Rekeying, but with Address Check The steps of the packet processing are as follows: 1. The mobile host may be disconnected from the peer host for a brief period of time while it switches from one IP address to another; this case is sometimes referred to in the literature as a "break-before-make" case. The host may also obtain its new IP address before loosing the old one ("make-before-break" case). In either case, upon obtaining a new IP address, the mobile host sends a LOCATOR_SET parameter to the peer host in an UPDATE message. The UPDATE message also contains an ESP_INFO parameter containing the values of the old and new SPIs for a security association. In this case, the OLD SPI and NEW SPI parameters both are set to the value of the preexisting incoming SPI; this ESP_INFO does not trigger a rekeying event but is instead included for possible parameter-inspecting firewalls on the path Henderson, et al. Expires April 13, 2017 [Page 9] Internet-Draft HIP Host Mobility October 2016 ([RFC5207] specifies some such firewall scenarios in which the HIP-aware firewall may want to associate ESP flows to host identities). The LOCATOR_SET parameter contains the new IP address (Locator Type of "1", defined below) and a locator lifetime. The mobile host waits for this UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC7401]. 2. The peer host receives the UPDATE, validates it, and updates any local bindings between the HIP association and the mobile host's destination address. The peer host MUST perform an address verification by placing a nonce in the ECHO_REQUEST parameter of the UPDATE message sent back to the mobile host. It also includes an ESP_INFO parameter with the OLD SPI and NEW SPI parameters both set to the value of the preexisting incoming SPI, and sends this UPDATE (with piggybacked acknowledgment) to the mobile host at its new address. This UPDATE also acknowledges the mobile host's UPDATE that triggered the exchange. The peer host waits for its UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC7401]. The peer MAY use the new address immediately, but it MUST limit the amount of data it sends to the address until address verification completes. 3. The mobile host completes the readdress by processing the UPDATE ACK and echoing the nonce in an ECHO_RESPONSE, containing the ACK of the peer's UPDATE. This UPDATE is not protected by a retransmission timer because it does not contain a SEQ parameter requesting acknowledgment. Once the peer host receives this ECHO_RESPONSE, it considers the new address to be verified and can put the address into full use. While the peer host is verifying the new address, the new address is marked as UNVERIFIED in the interim, and the old address is DEPRECATED. Once the peer host has received a correct reply to its UPDATE challenge, it marks the new address as ACTIVE and removes the old address. 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) The mobile host may decide to rekey the SAs at the same time that it notifies the peer of the new address. In this case, the above procedure described in Figure 3 is slightly modified. The UPDATE message sent from the mobile host includes an ESP_INFO with the OLD SPI set to the previous SPI, the NEW SPI set to the desired new SPI value for the incoming SA, and the KEYMAT Index desired. Optionally, the host may include a DIFFIE_HELLMAN parameter for a new Diffie- Hellman key. The peer completes the request for a rekey as is Henderson, et al. Expires April 13, 2017 [Page 10] Internet-Draft HIP Host Mobility October 2016 normally done for HIP rekeying, except that the new address is kept as UNVERIFIED until the UPDATE nonce challenge is received as described above. Figure 4 illustrates this scenario. Mobile Host Peer Host UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN]) -----------------------------------> UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> Figure 4: Readdress with Mobile-Initiated Rekey 3.2.3. Mobility messaging through rendezvous server Section 6.11 of [RFC7401] specifies procedures for sending HIP UPDATE packets. The UPDATE packets are protected by a timer subject to exponential backoff and resent UPDATE_RETRY_MAX times. It may be, however, that the peer is itself in the process of moving when the local host is trying to update the IP address bindings of the HIP association. This is sometimes called the "double-jump" mobility problem; each host's UPDATE packets are simultaneously sent to a stale address of the peer, and the hosts are no longer reachable from one another. The HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis] specifies a rendezvous service that permits the I1 packet from the base exchange to be relayed from a stable or well-known public IP address location to the current IP address of the host. It is possible to support double-jump mobility with this rendezvous service if the following extensions to the specifications of [I-D.ietf-hip-rfc5204-bis] and [RFC7401] are followed. 1. The mobile host sending an UPDATE to the peer, and not receiving an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the peer, if such a server is known. The host MAY try the RVS of the peer up to UPDATE_RETRY_MAX times as specified in [RFC7401]. The host MAY try to use the peer's RVS before it has tried UPDATE_RETRY_MAX times to the last working address (i.e. the RVS MAY be tried in parallel with retries to the last working address). The aggressiveness of a host replicating its UPDATEs to multiple destinations, to try candidates in parallel instead of serially, is a policy choice outside of this specification. 2. A rendezvous server supporting the UPDATE forwarding extensions specified herein MUST modify the UPDATE in the same manner as it Henderson, et al. Expires April 13, 2017 [Page 11] Internet-Draft HIP Host Mobility October 2016 modifies the I1 packet before forwarding. Specifically, it MUST rewrite the IP header source and destination addresses, recompute the IP header checksum, and include the FROM and RVS_HMAC parameters. 3. A host receiving an UPDATE packet MUST be prepared to process the FROM and RVS_HMAC parameters, and MUST include a VIA_RVS parameter in the UPDATE reply that contains the ACK of the UPDATE SEQ. 4. An initiator receiving a VIA_RVS in the UPDATE reply should initiate address reachability tests (described later in this document) towards the end host's address and not towards the address included in the VIA_RVS. This scenario requires that hosts using rendezvous servers also take steps to update their current address bindings with their rendezvous server upon a mobility event. [I-D.ietf-hip-rfc5204-bis] does not specify how to update the rendezvous server with a client host's new address. [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may send a REG_REQUEST in either an I2 packet (if there is no active association) or an UPDATE packet (if such association exists). According to procedures described in [I-D.ietf-hip-rfc5203-bis], if a mobile host has an active registration, it may use mobility updates specified herein, within the context of that association, to readdress the association. 3.2.4. Network Renumbering It is expected that IPv6 networks will be renumbered much more often than most IPv4 networks. From an end-host point of view, network renumbering is similar to mobility, and procedures described herein also apply to notify a peer of a changed address. 3.3. Other Considerations 3.3.1. Address Verification When a HIP host receives a set of locators from another HIP host in a LOCATOR_SET, it does not necessarily know whether the other host is actually reachable at the claimed addresses. In fact, a malicious peer host may be intentionally giving bogus addresses in order to cause a packet flood towards the target addresses [RFC4225]. Therefore, the HIP host needs to first check that the peer is reachable at the new address. Address verification is implemented by the challenger sending some piece of unguessable information to the new address, and waiting for Henderson, et al. Expires April 13, 2017 [Page 12] Internet-Draft HIP Host Mobility October 2016 some acknowledgment from the Responder that indicates reception of the information at the new address. This may include the exchange of a nonce, or the generation of a new SPI and observation of data arriving on the new SPI. More details are found in Section 5.4 of this document. An additional potential benefit of performing address verification is to allow NATs and firewalls in the network along the new path to obtain the peer host's inbound SPI. 3.3.2. Credit-Based Authorization Credit-Based Authorization (CBA) allows a host to securely use a new locator even though the peer's reachability at the address embedded in the locator has not yet been verified. This is accomplished based on the following three hypotheses: 1. A flooding attacker typically seeks to somehow multiply the packets it generates for the purpose of its attack because bandwidth is an ample resource for many victims. 2. An attacker can often cause unamplified flooding by sending packets to its victim, either by directly addressing the victim in the packets, or by guiding the packets along a specific path by means of an IPv6 Routing header, if Routing headers are not filtered by firewalls. 3. Consequently, the additional effort required to set up a redirection-based flooding attack (without CBA and return routability checks) would pay off for the attacker only if amplification could be obtained this way. On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents amplifications. This is accomplished by limiting the data a host can send to an unverified address of a peer by the data recently received from that peer. Redirection-based flooding attacks thus become less attractive than, for example, pure direct flooding, where the attacker itself sends bogus packets to the victim. Figure 5 illustrates Credit-Based Authorization: Host B measures the amount of data recently received from peer A and, when A readdresses, sends packets to A's new, unverified address as long as the sum of the packet sizes does not exceed the measured, received data volume. When insufficient credit is left, B stops sending further packets to A until A's address becomes ACTIVE. The address changes may be due to mobility, multihoming, or any other reason. Not shown in Figure 5 Henderson, et al. Expires April 13, 2017 [Page 13] Internet-Draft HIP Host Mobility October 2016 are the results of credit aging (Section 5.6.2), a mechanism used to dampen possible time-shifting attacks. +-------+ +-------+ | A | | B | +-------+ +-------+ | | address |------------------------------->| credit += size(packet) ACTIVE | | |------------------------------->| credit += size(packet) |<-------------------------------| do not change credit | | + address change | + address verification starts | address |<-------------------------------| credit -= size(packet) UNVERIFIED |------------------------------->| credit += size(packet) |<-------------------------------| credit -= size(packet) | | |<-------------------------------| credit -= size(packet) | X credit < size(packet) | | => do not send packet! + address verification concludes | address | | ACTIVE |<-------------------------------| do not change credit | | Figure 5: Readdressing Scenario This document does not specify how to set the credit limit value, but the goal is to allow data transfers to proceed without much interruption while the new address is verified. A simple heuristic to accomplish this, if the sender knows roughly its round-trip time (RTT) and current sending rate to the host, is to allow enough credit to support maintaining the sending rate for a duration corresponding to two or three RTTs. 3.3.3. Preferred Locator When a host has multiple locators, the peer host needs to decide which to use for outbound packets. It may be that a host would prefer to receive data on a particular inbound interface. HIP allows a particular locator to be designated as a Preferred locator and communicated to the peer (see Section 4). Henderson, et al. Expires April 13, 2017 [Page 14] Internet-Draft HIP Host Mobility October 2016 4. LOCATOR_SET Parameter Format The LOCATOR_SET parameter has a type number value that is considered to be a 'critical parameter' as per the definition in [RFC7401]; such parameter types MUST be recognized and processed by the recipient. The parameter consists of the standard HIP parameter Type and Length fields, plus zero or more Locator sub-parameters. Each Locator sub- parameter contains a Traffic Type, Locator Type, Locator Length, Preferred locator bit, Locator Lifetime, and a Locator encoding. A LOCATOR_SET containing zero Locator fields is permitted but has the effect of deprecating all addresses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Locator Type | Locator Length | Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Locator Type | Locator Length | Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: LOCATOR_SET Parameter Format Type: 193 Length: Length in octets, excluding Type and Length fields, and excluding padding. Henderson, et al. Expires April 13, 2017 [Page 15] Internet-Draft HIP Host Mobility October 2016 Traffic Type: Defines whether the locator pertains to HIP signaling, user data, or both. Locator Type: Defines the semantics of the Locator field. Locator Length: Defines the length of the Locator field, in units of 4-byte words (Locators up to a maximum of 4*255 octets are supported). Reserved: Zero when sent, ignored when received. P: Preferred locator. Set to one if the locator is preferred for that Traffic Type; otherwise, set to zero. Locator Lifetime: Locator lifetime, in seconds. Locator: The locator whose semantics and encoding are indicated by the Locator Type field. All Locator sub-fields are integral multiples of four octets in length. The Locator Lifetime indicates how long the following locator is expected to be valid. The lifetime is expressed in seconds. Each locator MUST have a non-zero lifetime. The address is expected to become deprecated when the specified number of seconds has passed since the reception of the message. A deprecated address SHOULD NOT be used as a destination address if an alternate (non-deprecated) is available and has sufficient address scope. 4.1. Traffic Type and Preferred Locator The following Traffic Type values are defined: 0: Both signaling (HIP control packets) and user data. 1: Signaling packets only. 2: Data packets only. The "P" bit, when set, has scope over the corresponding Traffic Type. That is, when a "P" bit is set for Traffic Type "2", for example, it means that the locator is preferred for data packets. If there is a conflict (for example, if the "P" bit is set for an address of Type "0" and a different address of Type "2"), the more specific Traffic Type rule applies (in this case, "2"). By default, the IP addresses used in the base exchange are Preferred locators for both signaling and user data, unless a new Preferred locator supersedes them. If no locators are indicated as preferred for a given Traffic Type, the Henderson, et al. Expires April 13, 2017 [Page 16] Internet-Draft HIP Host Mobility October 2016 implementation may use an arbitrary destination locator from the set of active locators. 4.2. Locator Type and Locator The following Locator Type values are defined, along with the associated semantics of the Locator field: 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] (128 bits long). This locator type is defined primarily for non- ESP-based usage. 1: The concatenation of an ESP SPI (first 32 bits) followed by an IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 128 bits). This IP address is defined primarily for ESP-based usage. 4.3. UPDATE Packet with Included LOCATOR_SET A number of combinations of parameters in an UPDATE packet are possible (e.g., see Section 3.2). In this document, procedures are defined only for the case in which one LOCATOR_SET and one ESP_INFO parameter is used in any HIP packet. Any UPDATE packet that includes a LOCATOR_SET parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The UPDATE MAY also include a HOST_ID parameter (which may be useful for HIP-aware firewalls inspecting the HIP messages for the first time). If the UPDATE includes the HOST_ID parameter, the receiving host MUST verify that the HOST_ID corresponds to the HOST_ID that was used to establish the HIP association, and the HIP_SIGNATURE MUST verify with the public key associated with this HOST_ID parameter. The relationship between the announced Locators and any ESP_INFO parameters present in the packet is defined in Section 5.2. This document does not support any elements of procedure for sending more than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. 5. Processing Rules This section describes rules for sending and receiving the LOCATOR_SET parameter, testing address reachability, and using Credit-Based Authorization (CBA) on UNVERIFIED locators. Henderson, et al. Expires April 13, 2017 [Page 17] Internet-Draft HIP Host Mobility October 2016 5.1. Locator Data Structure and Status Each locator announced in a LOCATOR_SET parameter is represented by a piece of state that contains the following data: o the actual bit pattern representing the locator, o the lifetime (seconds), o the status (UNVERIFIED, ACTIVE, DEPRECATED), o the Traffic Type scope of the locator, and o whether the locator is preferred for any particular scope. The status is used to track the reachability of the address embedded within the LOCATOR_SET parameter: UNVERIFIED indicates that the reachability of the address has not been verified yet, ACTIVE indicates that the reachability of the address has been verified and the address has not been deprecated, DEPRECATED indicates that the locator lifetime has expired. The following state changes are allowed: UNVERIFIED to ACTIVE The reachability procedure completes successfully. UNVERIFIED to DEPRECATED The locator lifetime expires while the locator is UNVERIFIED. ACTIVE to DEPRECATED The locator lifetime expires while the locator is ACTIVE. ACTIVE to UNVERIFIED There has been no traffic on the address for some time, and the local policy mandates that the address reachability needs to be verified again before starting to use it again. DEPRECATED to UNVERIFIED The host receives a new lifetime for the locator. A DEPRECATED address MUST NOT be changed to ACTIVE without first verifying its reachability. Henderson, et al. Expires April 13, 2017 [Page 18] Internet-Draft HIP Host Mobility October 2016 Note that the state of whether or not a locator is preferred is not necessarily the same as the value of the Preferred bit in the Locator sub-parameter received from the peer. Peers may recommend certain locators to be preferred, but the decision on whether to actually use a locator as a preferred locator is a local decision, possibly influenced by local policy. In addition to state maintained about status and remaining lifetime for each locator learned from the peer, an implementation would typically maintain similar state about its own locators that have been offered to the peer. An unbounded locator lifetime can be signified by setting the value of the lifetime field to the maximum (unsigned) value. Finally, the locators used to establish the HIP association are by default assumed to be the initial preferred locators in ACTIVE state, with an unbounded lifetime. 5.2. Sending the LOCATOR_SET The decision of when to send the LOCATOR_SET is a local policy issue. However, it is RECOMMENDED that a host send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. Rapidly sending LOCATOR_SETs that force the peer to change the preferred address SHOULD be avoided. The sending of a new LOCATOR_SET parameter replaces the locator information from any previously sent LOCATOR_SET parameter, and therefore if a host sends a new LOCATOR_SET parameter, it needs to continue to include all active locators. Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. We now describe a few cases introduced in Section 3.2. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that separate the HIP control plane from data plane traffic). Other mobility cases are possible but are left for further study. 1. Host mobility with no multihoming and no rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR_SET parameter. The ESP_INFO contains the current value of the SPI in both the OLD SPI and NEW SPI fields. The LOCATOR_SET contains a single Locator with a "Locator Type" of "1"; the SPI MUST match that of the ESP_INFO. The Preferred bit SHOULD be set and the "Locator Lifetime" is set according to local policy. The UPDATE also contains a SEQ parameter as usual. Henderson, et al. Expires April 13, 2017 [Page 19] Internet-Draft HIP Host Mobility October 2016 This packet is retransmitted as defined in the HIP protocol specification [RFC7401]. The UPDATE should be sent to the peer's preferred IP address with an IP source address corresponding to the address in the LOCATOR_SET parameter. 2. Host mobility with no multihoming but with rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR_SET parameter (with a single address). The ESP_INFO contains the current value of the SPI in the OLD SPI and the new value of the SPI in the NEW SPI, and a KEYMAT Index as selected by local policy. Optionally, the host may choose to initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter. The LOCATOR_SET contains a single Locator with "Locator Type" of "1"; the SPI MUST match that of the NEW SPI in the ESP_INFO. Otherwise, the steps are identical to the case in which no rekeying is initiated. 5.3. Handling Received LOCATOR_SETs A host SHOULD be prepared to receive a single LOCATOR_SET parameter in a HIP UPDATE packet. Reception of multiple LOCATOR_SET parameters in a single packet, or in HIP packets other than UPDATE, is outside of the scope of this specification. Because a host sending the LOCATOR_SET may send the same parameter in different UPDATE messages to different destination addresses, including possibly the rendezvous server of the host, the host receiving the LOCATOR_SET MUST be prepared to handle the possibility of duplicate LOCATOR_SETs sent to more than one of the host's addresses. As a result, the host MUST detect and avoid reprocessing a LOCATOR_SET parameter that is redundant with a LOCATOR_SET parameter that has been recently received and processed. This document describes sending both ESP_INFO and LOCATOR_SET parameters in an UPDATE. The ESP_INFO parameter is included when there is a need to rekey or key a new SPI, and is otherwise included for the possible benefit of HIP-aware NATs and firewalls. The LOCATOR_SET parameter contains a complete listing of the locators that the host wishes to make or keep active for the HIP association. In general, the processing of a LOCATOR_SET depends upon the packet type in which it is included. Here, we describe only the case in which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are sent in an UPDATE message; other cases are for further study. The steps below cover each of the cases described in Section 5.2. The processing of ESP_INFO and LOCATOR_SET parameters is intended to be modular and support future generalization to the inclusion of Henderson, et al. Expires April 13, 2017 [Page 20] Internet-Draft HIP Host Mobility October 2016 multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host SHOULD first process the ESP_INFO before the LOCATOR_SET, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type "1" locator will only contain a reference to the new SPI. When a host receives a validated HIP UPDATE with a LOCATOR_SET and ESP_INFO parameter, it processes the ESP_INFO as follows. The ESP_INFO parameter indicates whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of HIP-aware NATs and firewalls. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter: 1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for HIP-aware NATs and firewalls) and no rekeying is necessary. 2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW SPI is a different non-zero value, the existing SA is being rekeyed and the host follows HIP ESP rekeying procedures by creating a new outbound SA with an SPI corresponding to the NEW SPI, with no addresses bound to this SPI. Note that locators in the LOCATOR_SET parameter will reference this new SPI instead of the old SPI. 3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new non-zero value, then a new SA is being requested by the peer. This case is also treated like a rekeying event; the receiving host MUST create a new SA and respond with an UPDATE ACK. 4. (deprecating the SA) If the OLD SPI indicates an existing SPI and the NEW SPI is zero, the SA is being deprecated and all locators uniquely bound to the SPI are put into the DEPRECATED state. If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped. Next, the locators in the LOCATOR_SET parameter are processed. For each locator listed in the LOCATOR_SET parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it may be allowed that the host runs HIP with itself. The below assumes that all locators are of Type "1" with a Traffic Type of "0"; other cases are for further study. Henderson, et al. Expires April 13, 2017 [Page 21] Internet-Draft HIP Host Mobility October 2016 For each Type "1" address listed in the LOCATOR_SET parameter, the host checks whether the address is already bound to the SPI indicated. If the address is already bound, its lifetime is updated. If the status of the address is DEPRECATED, the status is changed to UNVERIFIED. If the address is not already bound, the address is added, and its status is set to UNVERIFIED. Mark all addresses corresponding to the SPI that were NOT listed in the LOCATOR_SET parameter as DEPRECATED. As a result, at the end of processing, the addresses listed in the LOCATOR_SET parameter have either a state of UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR_SET parameter have a state of DEPRECATED. Once the host has processed the locators, if the LOCATOR_SET parameter contains a new Preferred locator, the host SHOULD initiate a change of the Preferred locator. This requires that the host first verifies reachability of the associated address, and only then changes the Preferred locator; see Section 5.5. If a host receives a locator with an unsupported Locator Type, and when such a locator is also declared to be the Preferred locator for the peer, the host SHOULD send a NOTIFY error with a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field containing the locator(s) that the receiver failed to process. Otherwise, a host MAY send a NOTIFY error if a (non-preferred) locator with an unsupported Locator Type is received in a LOCATOR_SET parameter. A host MAY add the source IP address of a received HIP packet as a candidate locator for the peer even if it is not listed in the peer's LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the LOCATOR_SET. 5.4. Verifying Address Reachability A host MUST verify the reachability of an UNVERIFIED address. The status of a newly learned address MUST initially be set to UNVERIFIED unless the new address is advertised in a R1 packet as a new Preferred locator. A host MAY also want to verify the reachability of an ACTIVE address again after some time, in which case it would set the status of the address to UNVERIFIED and reinitiate address verification. A typical verification that is protected by retransmission timers is to include an ECHO REQUEST within an UPDATE sent to the new address. A host typically starts the address-verification procedure by sending a nonce to the new address. A host MAY choose from different message Henderson, et al. Expires April 13, 2017 [Page 22] Internet-Draft HIP Host Mobility October 2016 exchanges or different nonce values so long as it establishes that the peer has received and replied to the nonce at the new address. For example, when the host is changing its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD be random and the random value MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE. However, if the host is not changing its SPI, it MAY still use the ECHO_REQUEST parameter for verification but with some other random value. A host MAY also use other message exchanges as confirmation of the address reachability. In some cases, it MAY be sufficient to use the arrival of data on a newly advertised SA as implicit address reachability verification as depicted in Figure 7, instead of waiting for the confirmation via a HIP packet. In this case, a host advertising a new SPI as part of its address reachability check SHOULD be prepared to receive traffic on the new SA. Mobile host Peer host UPDATE(ESP_INFO, LOCATOR_SET, ...) ----------------------------------> prepare incoming SA UPDATE(ESP_INFO, ...) with new SPI <----------------------------------- switch to new outgoing SA data on new SA -----------------------------------> mark address ACTIVE UPDATE(ACK, ECHO_RESPONSE) later arrives -----------------------------------> Figure 7: Address Activation Via Use of a New SA When address verification is in progress for a new Preferred locator, the host SHOULD select a different locator listed as ACTIVE, if one such locator is available, to continue communications until address verification completes. Alternatively, the host MAY use the new Preferred locator while in UNVERIFIED status to the extent Credit- Based Authorization permits. Credit-Based Authorization is explained in Section 5.6. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE. 5.5. Changing the Preferred Locator A host MAY want to change the Preferred outgoing locator for different reasons, e.g., because traffic information or ICMP error messages indicate that the currently used preferred address may have Henderson, et al. Expires April 13, 2017 [Page 23] Internet-Draft HIP Host Mobility October 2016 become unreachable. Another reason may be due to receiving a LOCATOR_SET parameter that has the "P" bit set. To change the Preferred locator, the host initiates the following procedure: 1. If the new Preferred locator has ACTIVE status, the Preferred locator is changed and the procedure succeeds. 2. If the new Preferred locator has UNVERIFIED status, the host starts to verify its reachability. The host SHOULD use a different locator listed as ACTIVE until address verification completes if one such locator is available. Alternatively, the host MAY use the new Preferred locator, even though in UNVERIFIED status, to the extent Credit-Based Authorization permits. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE and its use is no longer governed by Credit-Based Authorization. 3. If the peer host has not indicated a preference for any address, then the host picks one of the peer's ACTIVE addresses randomly or according to local policy. This case may arise if, for example, ICMP error messages that deprecate the Preferred locator arrive, but the peer has not yet indicated a new Preferred locator. 4. If the new Preferred locator has DEPRECATED status and there is at least one non-deprecated address, the host selects one of the non-deprecated addresses as a new Preferred locator and continues. If the selected address is UNVERIFIED, the address verification procedure described above will apply. 5.6. Credit-Based Authorization To prevent redirection-based flooding attacks, the use of a Credit- Based Authorization (CBA) approach MUST be used when a host sends data to an UNVERIFIED locator. The following algorithm addresses the security considerations for prevention of amplification and time- shifting attacks. Other forms of credit aging, and other values for the CreditAgingFactor and CreditAgingInterval parameters in particular, are for further study, and so are the advanced CBA techniques specified in [CBA-MIPv6]. 5.6.1. Handling Payload Packets A host maintains a "credit counter" for each of its peers. Whenever a packet arrives from a peer, the host SHOULD increase that peer's credit counter by the size of the received packet. When the host has Henderson, et al. Expires April 13, 2017 [Page 24] Internet-Draft HIP Host Mobility October 2016 a packet to be sent to the peer, and when the peer's Preferred locator is listed as UNVERIFIED and no alternative locator with status ACTIVE is available, the host checks whether it can send the packet to the UNVERIFIED locator. The packet SHOULD be sent if the value of the credit counter is higher than the size of the outbound packet. If the credit counter is too low, the packet MUST be discarded or buffered until address verification succeeds. When a packet is sent to a peer at an UNVERIFIED locator, the peer's credit counter MUST be reduced by the size of the packet. The peer's credit counter is not affected by packets that the host sends to an ACTIVE locator of that peer. Figure 8 depicts the actions taken by the host when a packet is received. Figure 9 shows the decision chain in the event a packet is sent. Inbound packet | | +----------------+ +---------------+ | | Increase | | Deliver | +-----> | credit counter |-------------> | packet to | | by packet size | | application | +----------------+ +---------------+ Figure 8: Receiving Packets with Credit-Based Authorization Henderson, et al. Expires April 13, 2017 [Page 25] Internet-Draft HIP Host Mobility October 2016 Outbound packet | _________________ | / \ +---------------+ | / Is the preferred \ No | Send packet | +-----> | destination address |-------------> | to preferred | \ UNVERIFIED? / | address | \_________________/ +---------------+ | | Yes | v _________________ / \ +---------------+ / Does an ACTIVE \ Yes | Send packet | | destination address |-------------> | to ACTIVE | \ exist? / | address | \_________________/ +---------------+ | | No | v _________________ / \ +---------------+ / Credit counter \ No | | | >= |-------------> | Drop or | \ packet size? / | buffer packet | \_________________/ +---------------+ | | Yes | v +---------------+ +---------------+ | Reduce credit | | Send packet | | counter by |----------------> | to preferred | | packet size | | address | +---------------+ +---------------+ Figure 9: Sending Packets with Credit-Based Authorization 5.6.2. Credit Aging A host ensures that the credit counters it maintains for its peers gradually decrease over time. Such "credit aging" prevents a malicious peer from building up credit at a very slow speed and using this, all at once, for a severe burst of redirected packets. Henderson, et al. Expires April 13, 2017 [Page 26] Internet-Draft HIP Host Mobility October 2016 Credit aging may be implemented by multiplying credit counters with a factor, CreditAgingFactor (a fractional value less than one), in fixed time intervals of CreditAgingInterval length. Choosing appropriate values for CreditAgingFactor and CreditAgingInterval is important to ensure that a host can send packets to an address in state UNVERIFIED even when the peer sends at a lower rate than the host itself. When CreditAgingFactor or CreditAgingInterval are too small, the peer's credit counter might be too low to continue sending packets until address verification concludes. The parameter values proposed in this document are as follows: CreditAgingFactor 7/8 CreditAgingInterval 5 seconds These parameter values work well when the host transfers a file to the peer via a TCP connection and the end-to-end round-trip time does not exceed 500 milliseconds. Alternative credit-aging algorithms may use other parameter values or different parameters, which may even be dynamically established. 6. Security Considerations The HIP mobility mechanism provides a secure means of updating a host's IP address via HIP UPDATE packets. Upon receipt, a HIP host cryptographically verifies the sender of an UPDATE, so forging or replaying a HIP UPDATE packet is very difficult (see [RFC7401]). Therefore, security issues reside in other attack domains. The two we consider are malicious redirection of legitimate connections as well as redirection-based flooding attacks using this protocol. This can be broken down into the following: 1) Impersonation attacks - direct conversation with the misled victim - man-in-the-middle attack 2) DoS attacks - flooding attacks (== bandwidth-exhaustion attacks) * tool 1: direct flooding * tool 2: flooding by botnets * tool 3: redirection-based flooding Henderson, et al. Expires April 13, 2017 [Page 27] Internet-Draft HIP Host Mobility October 2016 - memory-exhaustion attacks - computational-exhaustion attacks 3) Privacy concerns We consider these in more detail in the following sections. In Section 6.1 and Section 6.2, we assume that all users are using HIP. In Section 6.3 we consider the security ramifications when we have both HIP and non-HIP hosts. 6.1. Impersonation Attacks An attacker wishing to impersonate another host will try to mislead its victim into directly communicating with them, or carry out a man- in-the-middle (MitM) attack between the victim and the victim's desired communication peer. Without mobility support, such attacks are possible only if the attacker resides on the routing path between its victim and the victim's desired communication peer, or if the attacker tricks its victim into initiating the connection over an incorrect routing path (e.g., by acting as a router or using spoofed DNS entries). The HIP extensions defined in this specification change the situation in that they introduce an ability to redirect a connection, both before and after establishment. If no precautionary measures are taken, an attacker could potentially misuse the redirection feature to impersonate a victim's peer from any arbitrary location. However, the authentication and authorization mechanisms of the HIP base exchange [RFC7401] and the signatures in the UPDATE message prevent this attack. Furthermore, ownership of a HIP association is securely linked to a HIP HI/HIT. If an attacker somehow uses a bug in the implementation to redirect a HIP connection, the original owner can always reclaim their connection (they can always prove ownership of the private key associated with their public HI). MitM attacks are possible if an on-path attacker is present during the initial HIP base exchange and if the hosts do not authenticate each other's identities. However, once such an opportunistic base exchange has taken place, a MitM attacker that comes later to the path cannot steal the HIP connection because it is very difficult for an attacker to create an UPDATE packet (or any HIP packet) that will be accepted as a legitimate update. UPDATE packets use HMAC and are signed. Even when an attacker can snoop packets to obtain the SPI and HIT/HI, they still cannot forge an UPDATE packet without knowledge of the secret keys. Also, replay attacks on the UPDATE packet are prevented as described in [RFC7401]. Henderson, et al. Expires April 13, 2017 [Page 28] Internet-Draft HIP Host Mobility October 2016 6.2. Denial-of-Service Attacks 6.2.1. Flooding Attacks The purpose of a denial-of-service attack is to exhaust some resource of the victim such that the victim ceases to operate correctly. A denial-of-service attack can aim at the victim's network attachment (flooding attack), its memory, or its processing capacity. In a flooding attack, the attacker causes an excessive number of bogus or unwanted packets to be sent to the victim, which fills their available bandwidth. Note that the victim does not necessarily need to be a node; it can also be an entire network. The attack functions the same way in either case. An effective DoS strategy is distributed denial of service (DDoS). Here, the attacker conventionally distributes some viral software to as many nodes as possible. Under the control of the attacker, the infected nodes (e.g. nodes in a botnet), jointly send packets to the victim. With such an 'army', an attacker can take down even very high bandwidth networks/victims. With the ability to redirect connections, an attacker could realize a DDoS attack without having to distribute viral code. Here, the attacker initiates a large download from a server, and subsequently uses the HIP mobility mechanism to redirect this download to its victim. The attacker can repeat this with multiple servers. This threat is mitigated through reachability checks and credit-based authorization. Reachability checks, which when conducted using HIP can leverage the built-in authentication properties of HIP, can prevent redirection-based flooding attacks. However, the delay of such a check can have a noticeable impact on application performance. To reduce the impact of the delay, credit-based authorization can be used to send a limited number of packets to the new address while the validity of the IP address is still in question. Both strategies do not eliminate flooding attacks per se, but they preclude: (i) their use from a location off the path towards the flooded victim; and (ii) any amplification in the number and size of the redirected packets. As a result, the combination of a reachability check and credit-based authorization lowers a HIP redirection-based flooding attack to the level of a direct flooding attack in which the attacker itself sends the flooding traffic to the victim. 6.2.2. Memory/Computational-Exhaustion DoS Attacks We now consider whether or not the proposed extensions to HIP add any new DoS attacks (consideration of DoS attacks using the base HIP exchange and updates is discussed in [RFC7401]). A simple attack is to send many UPDATE packets containing many IP addresses that are not Henderson, et al. Expires April 13, 2017 [Page 29] Internet-Draft HIP Host Mobility October 2016 flagged as preferred. The attacker continues to send such packets until the number of IP addresses associated with the attacker's HI crashes the system. Therefore, a HIP association SHOULD limit the number of IP addresses that can be associated with any HI. Other forms of memory/computationally exhausting attacks via the HIP UPDATE packet are handled in the base HIP document [RFC7401]. A central server that has to deal with a large number of mobile clients MAY consider increasing the SA lifetimes to try to slow down the rate of rekeying UPDATEs or increasing the cookie difficulty to slow down the rate of attack-oriented connections. 6.3. Mixed Deployment Environment We now assume an environment with both HIP and non-HIP aware hosts. Four cases exist. 1. A HIP host redirects its connection onto a non-HIP host. The non-HIP host will drop the reachability packet, so this is not a threat unless the HIP host is a MitM that could somehow respond successfully to the reachability check. 2. A non-HIP host attempts to redirect their connection onto a HIP host. This falls into IPv4 and IPv6 security concerns, which are outside the scope of this document. 3. A non-HIP host attempts to steal a HIP host's session (assume that Secure Neighbor Discovery is not active for the following). The non-HIP host contacts the service that a HIP host has a connection with and then attempts to change its IP address to steal the HIP host's connection. What will happen in this case is implementation dependent but such a request should fail by being ignored or dropped. Even if the attack were successful, the HIP host could reclaim its connection via HIP. 4. A HIP host attempts to steal a non-HIP host's session. A HIP host could spoof the non-HIP host's IP address during the base exchange or set the non-HIP host's IP address as its preferred address via an UPDATE. Other possibilities exist, but a solution is to prevent the local redirection of sessions that were previously using an unverified address, but outside of the existing HIP context, into the HIP SAs until the address change can be verified. Henderson, et al. Expires April 13, 2017 [Page 30] Internet-Draft HIP Host Mobility October 2016 6.4. Privacy Concerns The exposure of a host's IP addresses through HIP mobility extensions may raise privacy concerns. The administrator of a host may be trying to hide its location in some context through the use of a VPN or other virtual interfaces. Similar privacy issues also arise in other frameworks such as WebRTC and are not specific to HIP. Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges. While this issue may be more relevant in a host multihoming scenario in which multiple IP addresses might be exposed ([I-D.ietf-hip-multihoming]), it is worth noting also here that mobility events might cause an implementation to try to inadvertently use a locator that the adminstrator would rather avoid exposing to the peer host. 7. IANA Considerations [RFC5206], obsoleted by this document, specified an allocation for a LOCATOR parameter in the HIP Parameters registry, with a type value of 193. This document requests IANA to rename the parameter to 'LOCATOR_SET' and to update the reference from [RFC5206] to this specification. [RFC5206], obsoleted by this document, specified an allocation a LOCATOR_TYPE_UNSUPPORTED type in the Notify Message Type registry, with a type value of 46. This document requests IANA to update the reference from [RFC5206] to this specification. 8. Differences from RFC 5206 This section summarizes the technical changes made from [RFC5206]. This section is informational, intended to help implementors of the previous protocol version. If any text in this section contradicts text in other portions of this specification, the text found outside of this section should be considered normative. This document specifies extensions to the HIP Version 2 protocol, while [RFC5206] specifies extensions to the HIP Version 1 protocol. [RFC7401] documents the differences between these two protocol versions. [RFC5206] included procedures for both HIP host mobility and basic host multihoming. In this document, only host mobility procedures are included; host multihoming procedures are now specified in [I-D.ietf-hip-multihoming]. In particular, multihoming-related procedures related to the exposure of multiple locators in the base exchange packets, the transmission, reception, and processing of Henderson, et al. Expires April 13, 2017 [Page 31] Internet-Draft HIP Host Mobility October 2016 multiple locators in a single UPDATE packet, handovers across IP address families, and other multihoming-related specification has been removed. The following additional changes have been made: o The LOCATOR parameter in [RFC5206] has been renamed to LOCATOR_SET. o Specification text regarding the handling of mobility when both hosts change IP addresses at nearly the same time (a 'double-jump' mobility scenario) has been added. o Specification text regarding the mobility event in which the host briefly has an active new locator and old locator at the same time (a 'make-before-break' mobility scenario) has been added. o Specification text has been added to note that a host may add the source IP address of a received HIP packet as a candidate locator for the peer even if it is not listed in the peer's LOCATOR_SET, but that it should prefer locators explicitly listed in the LOCATOR_SET. o This document clarifies that the HOST_ID parameter may be included in UPDATE messages containing LOCATOR_SET parameters, for the possible benefit of HIP-aware firewalls. o The previous specification mentioned that it may be possible to include multiple LOCATOR_SET and ESP_INFO parameters in an UPDATE. This document only specifies the case of a single LOCATOR_SET and ESP_INFO parameter in an UPDATE. o The previous specification mentioned that it may be possible to send LOCATOR_SET parameters in packets other than the UPDATE. This document only specifies the use of the UPDATE packet. o This document describes a simple heuristic for setting the credit value for Credit-Based Authorization. o This specification mandates that a host must be able to receive and avoid reprocessing redundant LOCATOR_SET parameters that may have been sent in parallel to multiple addresses of the host. 9. Authors and Acknowledgments Pekka Nikander and Jari Arkko originated this document, and Christian Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Henderson, et al. Expires April 13, 2017 [Page 32] Internet-Draft HIP Host Mobility October 2016 Perkins contributed the initial draft of the security section. Petri Jokela was a co-author of the initial individual submission. Credit-Based Authorization was originally introduced in [SIMPLE-CBA], and portions of this document have been adopted from that earlier draft. The authors thank Jeff Ahrenholz, Baris Boyvat, Rene Hummen, Miika Komu, Mika Kousa, Jan Melen, and Samu Varjonen for improvements to the document. 10. References 10.1. Normative references [I-D.ietf-hip-rfc5203-bis] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", draft-ietf-hip-rfc5203-bis-11 (work in progress), August 2016. [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rfc5204-bis-08 (work in progress), August 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . Henderson, et al. Expires April 13, 2017 [Page 33] Internet-Draft HIP Host Mobility October 2016 10.2. Informative references [CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", February 2005. [I-D.ietf-hip-multihoming] Henderson, T., Vogt, C., and J. Arkko, "Host Multihoming with the Host Identity Protocol", draft-ietf-hip- multihoming-11 (work in progress), September 2016. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, DOI 10.17487/RFC4225, December 2005, . [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008, . [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, DOI 10.17487/RFC5207, April 2008, . [SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for Concurrent Reachability Verification", February 2006. Henderson, et al. Expires April 13, 2017 [Page 34] Internet-Draft HIP Host Mobility October 2016 Appendix A. Document Revision History To be removed upon publication +----------+--------------------------------------------------------+ | Revision | Comments | +----------+--------------------------------------------------------+ | draft-00 | Initial version from RFC5206 xml (unchanged). | | | | | draft-01 | Remove multihoming-specific text; no other changes. | | | | | draft-02 | Update references to point to -bis drafts; no other | | | changes. | | | | | draft-03 | issue 4: add make before break use case | | | | | | issue 6: peer locator exposure policies | | | | | | issue 10: rename LOCATOR to LOCATOR_SET | | | | | | issue 14: use of UPDATE packet's IP address | | | | | draft-04 | Document refresh; no other changes. | | | | | draft-05 | Document refresh; no other changes. | | | | | draft-06 | Document refresh; no other changes. | | | | | draft-07 | Document refresh; IANA considerations updated. | | | | | draft-08 | Remove sending LOCATOR_SET in R1, I2, and NOTIFY | | | (multihoming) | | | | | | State that only one LOCATOR_SET parameter may be sent | | | in an UPDATE packet (according to this draft) | | | (multihoming) | | | | | | Remove text about cross-family handovers (multihoming) | | | | | draft-09 | Add specification text regarding double-jump mobility | | | procedures. | | | | | draft-10 | issue 21: clarified that HI MAY be included in UPDATE | | | for benefit of middleboxes | | | | | | changed one informative reference from RFC 4423-bis to | | | RFC 7401 | | | | Henderson, et al. Expires April 13, 2017 [Page 35] Internet-Draft HIP Host Mobility October 2016 | | removed discussion about possible multiple LOCATOR_SET | | | and ESP_INFO parameters in an UPDATE (per previous | | | mailing list discussion) | | | | | | removed discussion about handling LOCATOR_SET | | | parameters in packets other than UPDATE (per previous | | | mailing list discussion) | | | | | draft-11 | Editorial improvements from WGLC | | | | | draft-12 | Update author affiliations and IPR boilerplate to | | | trust200902 | | | | | draft-13 | Editorial improvements to IANA considerations section. | | | | | | Moved citation of [SIMPLE-CBA] to Section 9 and | | | slightly updated text for redirection-based flooding | | | attacks in the Security Considerations section. | | | | | | Editorial improvements based on last call comments. | | | | | draft-14 | Added section to summarize changes from RFC5206. | | | | | | Replace references to 'middleboxes' with more specific | | | 'NATs and firewalls'. | | | | | | Describe a simple heuristic for setting the credit | | | value based on sending rate and RTT. | | | | | | Add subsection about privacy concerns of locator | | | exposure to the Security Considerations section. | | | | | | Clarify that a host must be able to receive and avoid | | | reprocessing redundant LOCATOR_SET parameters that may | | | have been sent in parallel to multiple addresses of | | | the host. | | | | | | Clarify that multicast or broadcast addresses must not | | | be announced in a LOCATOR_SET. | | | | | | Editorial improvements based on last call comments. | +----------+--------------------------------------------------------+ Authors' Addresses Henderson, et al. Expires April 13, 2017 [Page 36] Internet-Draft HIP Host Mobility October 2016 Thomas R. Henderson (editor) University of Washington Campus Box 352500 Seattle, WA USA EMail: tomhend@u.washington.edu Christian Vogt Independent 3473 North First Street San Jose, CA 95134 USA EMail: mail@christianvogt.net Jari Arkko Ericsson JORVAS FIN-02420 FINLAND Phone: +358 40 5079256 EMail: jari.arkko@piuha.net Henderson, et al. Expires April 13, 2017 [Page 37] ./draft-ietf-mmusic-sdp-mux-attributes-16.txt0000664000764400076440000071172613026002640020444 0ustar iustyiusty Network Working Group S. Nandakumar Internet-Draft Cisco Intended status: Standards Track December 19, 2016 Expires: June 22, 2017 A Framework for SDP Attributes when Multiplexing draft-ietf-mmusic-sdp-mux-attributes-16 Abstract The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 22, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Nandakumar Expires June 22, 2017 [Page 1] Internet-Draft SDP Attribute Multiplexing December 2016 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. SDP Attribute Analysis Framework . . . . . . . . . . . . . . 6 4.1. Category: NORMAL . . . . . . . . . . . . . . . . . . . . 7 4.2. Category: CAUTION . . . . . . . . . . . . . . . . . . . . 7 4.3. Category: IDENTICAL . . . . . . . . . . . . . . . . . . . 8 4.4. Category: SUM . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Category: TRANSPORT . . . . . . . . . . . . . . . . . . . 9 4.6. Category: INHERIT . . . . . . . . . . . . . . . . . . . . 10 4.7. Category: IDENTICAL-PER-PT . . . . . . . . . . . . . . . 10 4.8. Category: SPECIAL . . . . . . . . . . . . . . . . . . . . 11 4.9. Category: TBD . . . . . . . . . . . . . . . . . . . . . . 11 5. Analysis of Existing Attributes . . . . . . . . . . . . . . . 12 5.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 12 5.2. RFC4585: RTP/AVPF . . . . . . . . . . . . . . . . . . . . 14 5.3. RFC5761: Multiplexing RTP and RTCP . . . . . . . . . . . 14 5.4. RFC3312: Integration of Resource Management and SIP . . . 14 5.5. RFC4574: SDP Label Attribute . . . . . . . . . . . . . . 15 5.6. RFC5432: QOS Mechanism Selection in SDP . . . . . . . . . 15 5.7. RFC4568: SDP Security Descriptions . . . . . . . . . . . 16 5.8. RFC5762: RTP over DCCP . . . . . . . . . . . . . . . . . 16 5.9. RFC6773: DCCP-UDP Encapsulation . . . . . . . . . . . . . 17 5.10. RFC5506: Reduced-Size RTCP in RTP Profile . . . . . . . . 18 5.11. RFC6787: Media Resource Control Protocol Version 2 . . . 18 5.12. RFC5245: ICE . . . . . . . . . . . . . . . . . . . . . . 19 5.13. RFC5285: RTP Header Extensions . . . . . . . . . . . . . 20 5.14. RFC3605: RTCP attribute in SDP . . . . . . . . . . . . . 21 5.15. RFC5576: Source-Specific SDP Attributes . . . . . . . . . 21 5.16. RFC7273: RTP Clock Source Signalling . . . . . . . . . . 22 5.17. RFC6236: Image Attributes in SDP . . . . . . . . . . . . 23 5.18. RFC7197: Duplication Delay Attribute in SDP . . . . . . . 24 5.19. RFC7266: RTCP XR Blocks for MOS Metric Reporting . . . . 24 5.20. RFC6285: Rapid Acquisition of Multicast RTP Sessions . . 24 5.21. RFC6230: Media Control Channel Framework . . . . . . . . 25 5.22. RFC6364: SDP Elements for FEC Framework . . . . . . . . . 25 5.23. RFC4796: Content Attribute . . . . . . . . . . . . . . . 26 5.24. RFC3407: SDP Simple Capability Declaration . . . . . . . 26 5.25. RFC6284: Port Mapping between Unicast and Multicast RTP Sessions . . . . . . . . . . . . . . . . . . . . . . . . 27 5.26. RFC6714: MSRP-CEMA . . . . . . . . . . . . . . . . . . . 28 5.27. RFC4583: SDP Format for BFCP Streams . . . . . . . . . . 28 Nandakumar Expires June 22, 2017 [Page 2] Internet-Draft SDP Attribute Multiplexing December 2016 5.28. RFC5547: SDP Offer/Answer for File Transfer . . . . . . . 29 5.29. RFC6849: SDP and RTP Media Loopback Extension . . . . . . 29 5.30. RFC5760: RTCP with Unicast Feedback . . . . . . . . . . . 30 5.31. RFC3611: RTCP XR . . . . . . . . . . . . . . . . . . . . 30 5.32. RFC5939: SDP Capability Negotiation . . . . . . . . . . . 31 5.33. RFC6871: SDP Media Capabilities Negotiation . . . . . . . 31 5.34. RFC7006: Miscellaneous Capabilities Negotiation SDP . . . 32 5.35. RFC4567: Key Management Extensions for SDP and RTSP . . . 33 5.36. RFC4572: Comedia over TLS in SDP . . . . . . . . . . . . 34 5.37. RFC4570: SDP Source Filters . . . . . . . . . . . . . . . 34 5.38. RFC6128: RTCP Port for Multicast Sessions . . . . . . . . 35 5.39. RFC6189: ZRTP . . . . . . . . . . . . . . . . . . . . . . 35 5.40. RFC4145: Connection-Oriented Media . . . . . . . . . . . 36 5.41. RFC6947: The SDP altc Attribute . . . . . . . . . . . . . 36 5.42. RFC7195: SDP Extension for Circuit Switched Bearers in PSTN . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.43. RFC7272: IDMS Using the RTP Control Protocol (RTCP) . . . 37 5.44. RFC5159: Open Mobile Alliance (OMA) Broadcast (BCAST) SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 38 5.45. RFC6193: Media Description for IKE in SDP . . . . . . . . 38 5.46. RFC2326: Real Time Streaming Protocol . . . . . . . . . . 39 5.47. RFC6064: SDP and RTSP Extensions for 3GPP . . . . . . . . 40 5.48. RFC3108: ATM SDP . . . . . . . . . . . . . . . . . . . . 42 5.49. 3GPP TS 26.114 . . . . . . . . . . . . . . . . . . . . . 44 5.50. 3GPP TS 183.063 . . . . . . . . . . . . . . . . . . . . . 45 5.51. 3GPP TS 24.182 . . . . . . . . . . . . . . . . . . . . . 45 5.52. 3GPP TS 24.183 . . . . . . . . . . . . . . . . . . . . . 46 5.53. 3GPP TS 24.229 . . . . . . . . . . . . . . . . . . . . . 46 5.54. ITU T.38 . . . . . . . . . . . . . . . . . . . . . . . . 47 5.55. ITU-T Q.1970 . . . . . . . . . . . . . . . . . . . . . . 49 5.56. ITU-T H.248.15 . . . . . . . . . . . . . . . . . . . . . 49 5.57. RFC4975: The Message Session Relay Protocol . . . . . . . 50 5.58. Historical Attributes . . . . . . . . . . . . . . . . . . 51 6. bwtype Attribute Analysis . . . . . . . . . . . . . . . . . . 51 6.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 52 6.2. RFC3556: SDP Bandwidth Modifiers for RTCP Bandwidth . . . 52 6.3. RFC3890: Bandwidth Modifier for SDP . . . . . . . . . . . 53 7. rtcp-fb Attribute Analysis . . . . . . . . . . . . . . . . . 53 7.1. RFC4585: RTP/AVPF . . . . . . . . . . . . . . . . . . . . 53 7.2. RFC5104: Codec Control Messages in AVPF . . . . . . . . . 54 7.3. RFC6285: Unicast-Based Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . . . . . . . . . . . . . . . . 55 7.4. RFC6679: ECN for RTP over UDP/IP . . . . . . . . . . . . 55 7.5. RFC6642: Third-Party Loss Report . . . . . . . . . . . . 56 7.6. RFC5104: Codec Control Messages in AVPF . . . . . . . . . 57 8. group Attribute Analysis . . . . . . . . . . . . . . . . . . 57 8.1. RFC5888: SDP Grouping Framework . . . . . . . . . . . . . 57 8.2. RFC3524: Mapping Media Streams to Resource Nandakumar Expires June 22, 2017 [Page 3] Internet-Draft SDP Attribute Multiplexing December 2016 Reservation Flows . . . . . . . . . . . . . . . . . . . . 58 8.3. RFC4091: ANAT Semantics . . . . . . . . . . . . . . . . . 58 8.4. RFC5956: FEC Grouping Semantics in SDP . . . . . . . . . 58 8.5. RFC5583: Signaling Media Decoding Dependency in SDP . . . 59 8.6. RFC7104: Duplication Grouping Semantics in the SDP . . . 59 9. ssrc-group Attribute Analysis . . . . . . . . . . . . . . . . 60 9.1. RFC5576: Source-Specific SDP Attributes . . . . . . . . . 60 9.2. RFC7104: Duplication Grouping Semantics in the SDP . . . 60 10. QoS Mechanism Token Analysis . . . . . . . . . . . . . . . . 61 10.1. RFC5432: QoS Mechanism Selection in SDP . . . . . . . . 61 11. k= Attribute Analysis . . . . . . . . . . . . . . . . . . . . 61 11.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 62 12. content Attribute Analysis . . . . . . . . . . . . . . . . . 62 12.1. RFC4796 . . . . . . . . . . . . . . . . . . . . . . . . 62 13. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 63 13.1. RFC5109: RTP Payload Format for Generic FEC . . . . . . 63 14. Multiplexing Considerations for Encapsulating Attributes . . 63 14.1. RFC3407: cpar Attribute Analysis . . . . . . . . . . . . 64 14.2. RFC5939 Analysis . . . . . . . . . . . . . . . . . . . . 64 14.2.1. Recommendation: Procedures for Potential Configuration Pairing . . . . . . . . . . . . . . . 65 14.2.1.1. Example: Transport Capability Multiplexing . . . 66 14.2.1.2. Example: Attribute Capability Multiplexing . . . 67 14.3. RFC6871 Analysis . . . . . . . . . . . . . . . . . . . . 68 14.3.1. Recommendation: Dealing with Payload Type Numbers . 68 14.3.1.1. Example: Attribute Capability Under Shared Payload Type . . . . . . . . . . . . . . . . . . 68 14.3.2. Recommendation: Dealing with Latent Configurations . 69 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 15.1. New 'Multiplexing Categories' subregistry . . . . . . . 70 15.2. 'Mux Category' column for subregistries . . . . . . . . 71 15.2.1. Table: SDP bwtype . . . . . . . . . . . . . . . . . 71 15.2.2. Table: att-field (session level) . . . . . . . . . . 71 15.2.3. Table: att-field (both session and media level) . . 72 15.2.4. Table: att-field (media level only) . . . . . . . . 74 15.2.5. Table: att-field (source level) . . . . . . . . . . 77 15.2.6. Table: content SDP Parameters . . . . . . . . . . . 78 15.2.7. Table: Semantics for the 'group' SDP Attribute . . . 78 15.2.8. Table: 'rtcp-fb' Attribute Values . . . . . . . . . 79 15.2.9. Table: 'ack' and 'nack' Attribute Values . . . . . . 79 15.2.10. Table: 'depend' SDP Attribute Values . . . . . . . . 79 15.2.11. Table: 'cs-correlation' Attribute Values . . . . . . 80 15.2.12. Table: Semantics for the 'ssrc-group' SDP Attribute 80 15.2.13. Table: SDP/RTSP key management protocol identifiers 80 15.2.14. Table: Codec Control Messages . . . . . . . . . . . 81 15.2.15. Table: QoS Mechanism Tokens . . . . . . . . . . . . 81 15.2.16. Table: SDP Capability Negotiation Option Tags . . . 81 15.2.17. Table: Timestamp Reference Clock Source Parameters . 82 Nandakumar Expires June 22, 2017 [Page 4] Internet-Draft SDP Attribute Multiplexing December 2016 15.2.18. Table: Media Clock Source Parameters . . . . . . . . 82 16. Security Considerations . . . . . . . . . . . . . . . . . . . 83 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 83 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 87 19.1. Normative References . . . . . . . . . . . . . . . . . . 87 19.2. Informative References . . . . . . . . . . . . . . . . . 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95 1. Introduction SDP defines several attributes for capturing characteristics that apply to the individual media descriptions (described by "m=" lines") and the overall multimedia session. Typically different media types (audio, video, etc.) described using different media descriptions represent separate RTP sessions that are carried over individual transport layer flows. However [I-D.ietf-mmusic-sdp-bundle-negotiation] defines a way to use a single address:port combination (BUNDLE address) for receiving media associated with multiple SDP media descriptions. This would, for example allow the usage of a single set of Interactive Connectivity Establishment (ICE) [RFC5245] candidates for multiple media descriptions. This in turn has made it necessary to understand the interpretation and usage of the SDP attributes defined for the multiplexed media descriptions. Given the number of SDP attributes registered with the [IANA] and possibility of new attributes being defined in the future, there is need for a framework to analyze these attributes for their applicability in the transport multiplexing use-cases. The document starts with providing the motivation for requiring such a framework. This is followed by introduction to the SDP attribute analysis framework/procedures, following which several sections apply the framework to the SDP attributes registered with the [IANA]. 2. Terminology 5-tuple: A collection of the following values: source address, source port, destination address, destination port, and transport-layer protocol. 3GPP: Third Generation Partnership Project; see http://www.3gpp.org for more information about this organization. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Nandakumar Expires June 22, 2017 [Page 5] Internet-Draft SDP Attribute Multiplexing December 2016 3. Motivation The time and complications of setting up ICE [RFC5245] and Datagram Transport Layer Security (DTLS) based Secure Real-time Transport Protocol (SRTP) [RFC5763] transports for use by RTP, reasons to conserve ports bindings on the Network Address Translators (NAT), forms a requirement to try and reduce the number of transport level flows needed. This has resulted in the definition of ways, such as [I-D.ietf-mmusic-sdp-bundle-negotiation] to multiplex RTP over a single transport flow in order to preserve network resources such as port numbers. This imposes further restrictions on applicability of the SDP attributes as they are defined today. The specific problem is that there are attribute combinations which make sense when specified on independent "m=" lines -- as with classical SDP -- that do not make sense when those "m=" lines are then multiplexed over the same transport. To give an obvious example, ICE permits each "m=" line to have an independently specified ice-ufrag attribute. However, if the media from multiple "m=" lines is multiplexed over the same ICE component, then the meaning of media-level ice-ufrag attributes becomes muddled. At the time of writing this document there are close to 250 SDP attributes registered with the [IANA] and more will be added in the future. There is no clearly defined procedure to establish the validity/applicability of these attributes when used with transport multiplexing. 4. SDP Attribute Analysis Framework Attributes in an SDP session description can be defined at the session-level or media-level or source-level. Informally, there are various semantic groupings for these attributes. One such grouping could be notes as below: o Attributes related to media content such as media type, encoding schemes and payload types. o Attributes specifying media transport characteristics like RTP/RTP Control Protocol (RTCP) port numbers, network addresses and QOS. o Metadata description attributes capturing session timing and origin information. o Attributes establishing relationships between media descriptions such as grouping framework [RFC5888] Nandakumar Expires June 22, 2017 [Page 6] Internet-Draft SDP Attribute Multiplexing December 2016 The proposed framework analyzes the SDP attributes usage under multiplexing and assigns each SDP attribute to an appropriate multiplexing category. Since the multiplexing categories defined in this specification are independent of any informal semantic groupings of the SDP attributes, the categorizations assigned are normative. 4.1. Category: NORMAL The attributes in the NORMAL category can be independently specified when multiplexed and they retain their original semantics. In the example given below, the direction and label attributes are independently specified for audio and video "m=" lines. These attributes are not impacted by multiplexing these media streams over a single transport layer flow. v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 99 a=sendonly a=label:1 a=rtpmap:99 iLBC/8000 m=video 49172 RTP/AVP 31 a=recvonly a=label:2 a=rtpmap:31 H261/90000 4.2. Category: CAUTION The attributes in the CAUTION category are advised against multiplexing since their usage under multiplexing might lead to incorrect behavior. Example: Multiplexing media descriptions over a single Datagram Congestion Control Protocol (DCCP) transport [RFC5762] is not recommended since DCCP being a connection oriented protocol doesn't allow multiple connections on the same 5-tuple. Nandakumar Expires June 22, 2017 [Page 7] Internet-Draft SDP Attribute Multiplexing December 2016 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s= c=IN IP4 client.biloxi.example.com t=0 0 m=video 5004 DCCP/RTP/AVP 99 a=rtpmap:99 h261/9000 a=dccp-service-code:SC=x52545056 a=setup:passive a=connection:new m=video 5004 DCCP/RTP/AVP 100 a=rtpmap:100 h261/9000 a=dccp-service-code:SC=x5254504f a=setup:passive a=connection:new 4.3. Category: IDENTICAL The attributes and their associated values (if any) in the IDENTICAL category MUST be repeated across all the media descriptions under multiplexing. Attributes such as rtcp-mux fall into this category. Since RTCP reporting is done per RTP session, RTCP Multiplexing MUST be enabled for both the audio and video "m=" lines if they are transported over a single 5-tuple. v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s= c=IN IP4 client.biloxi.example.com t=0 0 m=audio 34567 RTP/AVP 97 a=rtcp-mux m=video 34567 RTP/AVP 31 a=rtpmap:31 H261/90000 a=rtcp-mux 4.4. Category: SUM The attributes in the SUM category can be set as they are normally used but software using them in the multiplexing scenario MUST apply the sum of all the attributes being multiplexed instead of trying to use them independently. This is typically used for bandwidth or other rate limiting attributes to the underlying transport. The software parsing the SDP sample below, should use the aggregate Application Specific (AS) bandwidth value from the individual media Nandakumar Expires June 22, 2017 [Page 8] Internet-Draft SDP Attribute Multiplexing December 2016 descriptions to determine the AS value for the multiplexed session. Thus the calculated AS value would be 256+64 kilobits per second for the given example. v=0 o=test 2890844526 2890842807 IN IP4 client.biloxi.example.com c=IN IP4 client.biloxi.example.com t=0 0 m=audio 49170 RTP/AVP 0 b=AS:64 m=video 51372 RTP/AVP 31 b=AS:256 4.5. Category: TRANSPORT The attributes in the TRANSPORT category can be set normally for multiple items in a multiplexed group but the software MUST pick the one that's associated with the "m=" line whose information is used for setting up the underlying transport. In the example below, "a=crypto" attribute is defined for both the audio and the video "m=" lines. The video media line's a=crypto attribute is chosen since its mid value (bar) appears first in the a=group:BUNDLE line. This is due to BUNDLE grouping semantic [I-D.ietf-mmusic-sdp-bundle-negotiation] which mandates the values from "m=" line corresponding to the mid appearing first on the a=group:BUNDLE line to be considered for setting up the RTP Transport. v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=group:BUNDLE bar foo m=audio 49172 RTP/AVP 99 a=mid:foo a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 a=rtpmap:99 iLBC/8000 m=video 51374 RTP/AVP 31 a=mid:bar a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:EcGZiNWpFJhQXdspcl1ekcmVCNWpVLcfHAwJSoj|2^20|1:32 a=rtpmap:96 H261/90000 Nandakumar Expires June 22, 2017 [Page 9] Internet-Draft SDP Attribute Multiplexing December 2016 4.6. Category: INHERIT The attributes in the INHERIT category encapsulate other SDP attributes or parameters. These attributes inherit their multiplexing characteristics from the attributes or parameters they encapsulate. Such attributes are defined in [RFC3407], [RFC5939] and [RFC6871] as part of a generic framework for indicating and negotiating transport, media, and media format related capabilities in the SDP. The inheritance manifests itself when the encapsulated attribute or parameter is being leveraged. In the case of SDP Capability Negotiation [RFC5939] for example, this occurs when a capability (encapsulating attribute) is used as part of a configuration; the configuration inherits the multiplexing category of each of its constituent (encapsulated) attributes and parameters. The inherited attributes MUST be coherent in order to form a valid configuration from a multiplexing point of view (see Section 14 for further details). v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=video 3456 RTP/AVP 100 a=rtpmap:100 VP8/90000 a=fmtp:100 max-fr=30;max-fs=8040 a=sqn: 0 a=cdsc: 1 video RTP/AVP 100 a=cpar: a=rtcp-mux m=video 3456 RTP/AVP 101 a=rtpmap:101 VP8/90000 a=fmtp:100 max-fr=15;max-fs=1200 a=cdsc: 2 video RTP/AVP 101 a=cpar: a=rtcp-mux In the above example, the category IDENTICAL is inherited by the cpar encapsulated rtcp-mux attribute. 4.7. Category: IDENTICAL-PER-PT The attributes in the IDENTICAL-PER-PT category define the RTP payload configuration on per Payload Type basis and MUST have identical values across all the media descriptions for a given RTP Payload Type when repeated. These Payload Types identify the same codec configuration as defined in the Section 10.1.2 of [I-D.ietf-mmusic-sdp-bundle-negotiation] under this context. Nandakumar Expires June 22, 2017 [Page 10] Internet-Draft SDP Attribute Multiplexing December 2016 In the SDP example below, Payload Types 96 and 97 are repeated across all the video "m=" lines and all the payload specific parameters (ex: rtpmap, fmtp) are identical (Note: some line breaks included are due to formatting only). v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=group:BUNDLE cam1 cam2 m=video 96 97 a=mid:cam1 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42400d; max-fs=3600; max-fps=3000; max-mbps=108000; max-br=1000 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42400a; max-fs=240; max-fps=3000; max-mbps=7200; max-br=200 m=video 96 97 a=mid:cam2 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42400d; max-fs=3600; max-fps=3000; max-mbps=108000; max-br=1000 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42400a; max-fs=240; max-fps=3000; max-mbps=7200; max-br=200 4.8. Category: SPECIAL For the attributes in the SPECIAL category, the text in the specification defining the attribute MUST be consulted for further handling when multiplexed. As an exampe, for the attribute extmap [RFC5285], the specification defining the extension needs to be referred to understand the multiplexing implications. 4.9. Category: TBD The attributes in the TBD category have not been analyzed under the proposed multiplexing framework and SHOULD NOT be multiplexed. Nandakumar Expires June 22, 2017 [Page 11] Internet-Draft SDP Attribute Multiplexing December 2016 5. Analysis of Existing Attributes This section analyzes attributes listed in [IANA], grouped under the IETF document that defines them. The "Level" column indicates whether the attribute is currently specified as: o S -- Session level o M -- Media level o B -- Both (Implies either a session level or a media level attribute) o SR -- Source-level (for a single SSRC) [RFC5576] The "Mux Category" column identifies multiplexing category assigned per attribute and the "Notes" column captures additional informative details regarding the assigned category, wherever necessary. 5.1. RFC4566: SDP [RFC4566] defines SDP that is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. +-----------------+---------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +-----------------+---------------------+-------+-------------------+ | sendrecv | Not impacted | B | NORMAL | | | | | | | sendonly | Not impacted | B | NORMAL | | | | | | | recvonly | Not impacted | B | NORMAL | | | | | | | inactive | Not impacted | B | NORMAL | | | | | | | cat | Not impacted | S | NORMAL | | | | | | | ptime | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | maxptime | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | Nandakumar Expires June 22, 2017 [Page 12] Internet-Draft SDP Attribute Multiplexing December 2016 | | configuration | | | | | | | | | orient | Not Impacted | M | NORMAL | | | | | | | framerate | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | quality | Not Impacted | M | NORMAL | | | | | | | rtpmap | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | fmtp | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | keywds | Not impacted | S | NORMAL | | | | | | | type | Not Impacted | S | NORMAL | | | | | | | type:broadcast | Not Impacted | S | NORMAL | | | | | | | type:H332 | Not Impacted | S | NORMAL | | | | | | | type:meeting | Not Impacted | S | NORMAL | | | | | | | type:moderated | Not Impacted | S | NORMAL | | | | | | | type:test | Not Impacted | S | NORMAL | | | | | | | tool | Not Impacted | S | NORMAL | | | | | | | charset | Not Impacted | S | NORMAL | | | | | | | sdplang | Not Impacted | B | NORMAL | | | | | | | lang | Not Impacted | B | NORMAL | | | | | | +-----------------+---------------------+-------+-------------------+ 5.1 RFC4566 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 13] Internet-Draft SDP Attribute Multiplexing December 2016 5.2. RFC4585: RTP/AVPF [RFC4585] defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. +----------+----------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +----------+----------------------------+-------+-------------------+ | rtcp-fb | Since RTCP feedback | M | IDENTICAL-PER-PT | | | attributes are Payload | | | | | Type (PT) scoped, their | | | | | values MUST be identical | | | | | for a given PT across the | | | | | multiplexed "m=" lines. | | | | | | | | +----------+----------------------------+-------+-------------------+ 5.2 RFC4585 Attribute Analysis 5.3. RFC5761: Multiplexing RTP and RTCP [RFC5761] discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It describes when such multiplexing is and is not appropriate, and it explains how the SDP can be used to signal multiplexed sessions. +-----------+----------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-----------+----------------------------------+-------+------------+ | rtcp-mux | RTP and RTCP Multiplexing | M | IDENTICAL | | | affects the entire RTP session | | | | | | | | +-----------+----------------------------------+-------+------------+ 5.3 RFC5761 Attribute Analysis 5.4. RFC3312: Integration of Resource Management and SIP [RFC3312] defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. Nandakumar Expires June 22, 2017 [Page 14] Internet-Draft SDP Attribute Multiplexing December 2016 +-------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------+-----------------------+-------+--------------+ | des | Refer to notes below | M | CAUTION | | | | | | | conf | Refer to notes below | M | CAUTION | | | | | | | curr | Refer to notes below | M | CAUTION | | | | | | +-------+-----------------------+-------+--------------+ 5.4 RFC3312 Attribute Analysis NOTE: A mismatched set of preconditions across media descriptions results in Session establishment failures due to inability to meet right resource reservations requested. 5.5. RFC4574: SDP Label Attribute [RFC4574] defines a new SDP media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. +--------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------+---------------+-------+--------------+ | label | Not Impacted | M | NORMAL | | | | | | +--------+---------------+-------+--------------+ 5.5 RFC4574 Attribute Analysis 5.6. RFC5432: QOS Mechanism Selection in SDP [RFC5432] defines procedures to negotiate QOS mechanisms using the SDP offer/answer model. Nandakumar Expires June 22, 2017 [Page 15] Internet-Draft SDP Attribute Multiplexing December 2016 +----------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------------+-----------------------+-------+--------------+ | qos-mech-send | Refer to Section 10 | B | TRANSPORT | | | | | | | qos-mech-recv | Refer to Section 10 | B | TRANSPORT | | | | | | +----------------+-----------------------+-------+--------------+ 5.6 RFC5432 Attribute Analysis 5.7. RFC4568: SDP Security Descriptions [RFC4568] defines a SDP cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. +---------+------------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +---------+------------------------------------+-------+------------+ | crypto | crypto attribute MUST be the one | M | TRANSPORT | | | that corresponds to the "m=" line | | | | | chosen for setting up the | | | | | underlying transport flow | | | | | | | | +---------+------------------------------------+-------+------------+ 5.7 RFC4568 Attribute Analysis 5.8. RFC5762: RTP over DCCP RTP is a widely used transport for real-time multimedia on IP networks. DCCP is a transport protocol that provides desirable services for real-time applications. [RFC5762] specifies a mapping of RTP onto DCCP, along with associated signaling, such that real- time applications can make use of the services provided by DCCP. Nandakumar Expires June 22, 2017 [Page 16] Internet-Draft SDP Attribute Multiplexing December 2016 +--------------------+-------------------------+---------+----------+ | Name | Notes | Current | Mux | | | | | Category | +--------------------+-------------------------+---------+----------+ | dccp-service-code | If RFC6773 is not being | M | CAUTION | | | used in addition to | | | | | RFC5762, the port in | | | | | the "m=" line is a DCCP | | | | | port. DCCP being a | | | | | connection oriented | | | | | protocol does not allow | | | | | multiple connections on | | | | | the same 5-tuple | | | | | | | | +--------------------+-------------------------+---------+----------+ 5.8 RFC5762 Attribute Analysis NOTE: If RFC6773 is being used in addition to RFC5762 and provided that DCCP-in-UDP layer has additional demultiplexing, then it can be possible to use different DCCP service codes for each DCCP flow, given each uses a different DCCP port. Although doing so might conflict with the media type of the "m=" line. None of this is standardized yet and it wouldn't work as explained. Hence performing multiplexing is not recommended even in this alternate scenario. 5.9. RFC6773: DCCP-UDP Encapsulation [RFC6773] specifies an alternative encapsulation of DCCP, referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middle boxes without modification of those middle boxes. +------------+-----------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------------+-----------------------------------+-------+----------+ | dccp-port | Multiplexing is not recommended | M | CAUTION | | | due to potential conflict between | | | | | the port used for DCCP | | | | | en/decapsulation and the RTP | | | | | | | | +------------+-----------------------------------+-------+----------+ 5.9 RFC6773 Attribute Analysis NOTE: RFC6773 is about tunneling DCCP in UDP, with the UDP port being the port of the DCCP en-/de-capsulation service. This encapsulation Nandakumar Expires June 22, 2017 [Page 17] Internet-Draft SDP Attribute Multiplexing December 2016 allows arbitrary DCCP packets to be encapsulated and the DCCP port chosen can conflict with the port chosen for the RTP traffic. For multiplexing several DCCP-in-UDP encapsulations on the same UDP port with no RTP traffic on the same port implies collapsing several DCCP port spaces together. This can or cannot work depending on the nature of DCCP encapsulation and ports choices thus rendering it to be very application dependent. 5.10. RFC5506: Reduced-Size RTCP in RTP Profile [RFC5506] discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size. +-------------+--------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-------------+--------------------------------+-------+------------+ | rtcp-rsize | Reduced size RTCP affects the | M | IDENTICAL | | | entire RTP session | | | | | | | | +-------------+--------------------------------+-------+------------+ 5.10 RFC5506 Attribute Analysis 5.11. RFC6787: Media Resource Control Protocol Version 2 The Media Resource Control Protocol Version 2 (MRCPv2) 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 the SIP, to coordinate MRCPv2 clients and servers, and manage session between them, and 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 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [RFC6787] defines attributes for this purpose. Nandakumar Expires June 22, 2017 [Page 18] Internet-Draft SDP Attribute Multiplexing December 2016 +-----------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-----------+---------------+-------+--------------+ | resource | Not Impacted | M | NORMAL | | | | | | | channel | Not Impacted | M | NORMAL | | | | | | | cmid | Not Impacted | M | NORMAL | | | | | | +-----------+---------------+-------+--------------+ 5.11 RFC6787 Attribute Analysis 5.12. RFC5245: ICE [RFC5245] describes a protocol for NAT traversal for UDP-based multimedia sessions established with the offer/answer model. ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the SIP. Nandakumar Expires June 22, 2017 [Page 19] Internet-Draft SDP Attribute Multiplexing December 2016 +--------------------+-------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +--------------------+-------------------------+-------+------------+ | ice-lite | Not Impacted | S | NORMAL | | | | | | | ice-options | Not Impacted | S | NORMAL | | | | | | | ice-mismatch | Not Impacted | S | NORMAL | | | | | | | ice-pwd | ice-pwd MUST be the one | B | TRANSPORT | | | that corresponds to the | | | | | "m=" line chosen for | | | | | setting up the | | | | | underlying transport | | | | | flow | | | | | | | | | ice-ufrag | ice-ufrag MUST be the | B | TRANSPORT | | | one that corresponds to | | | | | the "m=" line chosen | | | | | for setting up the | | | | | underlying transport | | | | | flow | | | | | | | | | candidate | ice candidate MUST be | M | TRANSPORT | | | the one that | | | | | corresponds to the "m=" | | | | | line chosen for setting | | | | | up the underlying | | | | | transport flow | | | | | | | | | remote-candidates | ice remote candidate | M | TRANSPORT | | | MUST be the one that | | | | | corresponds to the "m=" | | | | | line chosen for setting | | | | | up the underlying | | | | | transport flow | | | | | | | | +--------------------+-------------------------+-------+------------+ 5.12 RFC5245 Attribute Analysis 5.13. RFC5285: RTP Header Extensions [RFC5285] provides a general mechanism to use the header extension feature of RTP. It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual Nandakumar Expires June 22, 2017 [Page 20] Internet-Draft SDP Attribute Multiplexing December 2016 extensions in use in a session are signaled in the setup information for that session. +---------+--------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +---------+--------------------------------------+-------+----------+ | extmap | Refer to the document defining the | B | SPECIAL | | | specific RTP Extension | | | | | | | | +---------+--------------------------------------+-------+----------+ 5.13 RFC5285 Attribute Analysis 5.14. RFC3605: RTCP attribute in SDP Originally, SDP assumed that RTP and RTCP were carried on consecutive ports. However, this is not always true when NATs are involved. [RFC3605] specifies an early mechanism to indicate the RTCP port. +-------+--------------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-------+--------------------------------------+-------+------------+ | rtcp | RTCP Port MUST be the one that | M | TRANSPORT | | | corresponds to the "m=" line chosen | | | | | for setting up the underlying | | | | | transport flow. | | | | | | | | +-------+--------------------------------------+-------+------------+ 5.14 RFC3605 Attribute Analysis 5.15. RFC5576: Source-Specific SDP Attributes [RFC5576] defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. Nandakumar Expires June 22, 2017 [Page 21] Internet-Draft SDP Attribute Multiplexing December 2016 +----------------+----------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +----------------+----------------------+-------+-------------------+ | ssrc | Refer to Notes below | M | NORMAL | | | | | | | ssrc-group | Refer to Section 9 | M | NORMAL | | | for specific | | | | | analysis of the | | | | | grouping semantics | | | | | | | | | cname | Not Impacted | SR | NORMAL | | | | | | | previous-ssrc | Refer to notes below | SR | NORMAL | | | | | | | fmtp | The attribute value | SR | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | +----------------+----------------------+-------+-------------------+ 5.15 RFC5576 Attribute Analysis NOTE: If SSRCs are repeated across "m=" lines being multiplexed, they MUST all represent the same underlying RTP Source. 5.16. RFC7273: RTP Clock Source Signalling [RFC7273] specifies SDP signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session. Nandakumar Expires June 22, 2017 [Page 22] Internet-Draft SDP Attribute Multiplexing December 2016 +--------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------------------+---------------+-------+--------------+ | ts-refclk | Not Impacted | B | NORMAL | | | | | | | mediaclk | Not Impacted | B | NORMAL | | | | | | | ts-refclk:ntp | Not Impacted | B | NORMAL | | | | | | | ts-refclk:ptp | Not Impacted | B | NORMAL | | | | | | | ts-refclk:gps | Not Impacted | B | NORMAL | | | | | | | ts-refclk:gal | Not Impacted | B | NORMAL | | | | | | | ts-refclk:glonass | Not Impacted | B | NORMAL | | | | | | | ts-refclk:local | Not Impacted | B | NORMAL | | | | | | | ts-refclk:private | Not Impacted | B | NORMAL | | | | | | | mediaclk:sender | Not Impacted | B | NORMAL | | | | | | | mediaclk:direct | Not Impacted | B | NORMAL | | | | | | | mediaclk:IEEE1722 | Not Impacted | B | NORMAL | | | | | | +--------------------+---------------+-------+--------------+ 5.16 RFC7273 Attribute Analysis 5.17. RFC6236: Image Attributes in SDP [RFC6236] proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. Nandakumar Expires June 22, 2017 [Page 23] Internet-Draft SDP Attribute Multiplexing December 2016 +------------+--------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +------------+--------------------------+-------+-------------------+ | imageattr | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given | | | | | codec configuration | | | | | | | | +------------+--------------------------+-------+-------------------+ 5.17 RFC6236 Attribute Analysis 5.18. RFC7197: Duplication Delay Attribute in SDP [RFC7197] defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in SDP. +--------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------------------+---------------+-------+--------------+ | duplication-delay | Not Impacted | B | NORMAL | | | | | | +--------------------+---------------+-------+--------------+ 5.18 RFC7197 Attribute Analysis 5.19. RFC7266: RTCP XR Blocks for MOS Metric Reporting [RFC7266] defines an RTCP Extended Report (XR) Block including two new segment types and associated SDP parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications. +-------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------+---------------+-------+--------------+ | calgextmap | Not Impacted | B | NORMAL | | | | | | +-------------+---------------+-------+--------------+ 5.19 RFC7266 Attribute Analysis 5.20. RFC6285: Rapid Acquisition of Multicast RTP Sessions [RFC6285] describes a method using the existing RTP and RTCP machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate Nandakumar Expires June 22, 2017 [Page 24] Internet-Draft SDP Attribute Multiplexing December 2016 to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. +---------------+-------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------------+-------------------+-------+--------------+ | rams-updates | Not recommended | M | CAUTION | | | | | | +---------------+-------------------+-------+--------------+ 5.20 RFC6285 Attribute Analysis 5.21. RFC6230: Media Control Channel Framework [RFC6230] describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses SIP to establish an application-level control mechanism between application servers and associated external servers such as media servers. +---------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------+---------------+-------+--------------+ | cfw-id | Not Impacted | M | NORMAL | | | | | | +---------+---------------+-------+--------------+ 5.21 RFC6230 Attribute Analysis 5.22. RFC6364: SDP Elements for FEC Framework [RFC6364] specifies the use of SDP to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. Nandakumar Expires June 22, 2017 [Page 25] Internet-Draft SDP Attribute Multiplexing December 2016 +------------------+-----------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------------------+-----------------------------+-------+----------+ | fec-source-flow | Refer to the document | M | SPECIAL | | | defining specific FEC | | | | | Scheme | | | | | | | | | fec-repair-flow | Refer to the document | M | SPECIAL | | | defining specific FEC | | | | | Scheme | | | | | | | | | repair-window | Refer to the document | M | SPECIAL | | | defining specific FEC | | | | | Scheme | | | | | | | | +------------------+-----------------------------+-------+----------+ 5.22 RFC6364 Attribute Analysis 5.23. RFC4796: Content Attribute [RFC4796] defines a new SDP media-level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. +----------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+---------------+-------+--------------+ | content | Not Impacted | M | NORMAL | | | | | | +----------+---------------+-------+--------------+ 5.23 RFC4796 Attribute Analysis 5.24. RFC3407: SDP Simple Capability Declaration [RFC3407] defines a set of SDP attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Nandakumar Expires June 22, 2017 [Page 26] Internet-Draft SDP Attribute Multiplexing December 2016 +----------+------------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+------------------------+-------+--------------+ | sqn | Not Impacted | B | NORMAL | | | | | | | cdsc | Not Impacted. | B | NORMAL | | | | | | | cpar | Refer to Section 14 | B | INHERIT | | | | | | | cparmin | Refer to notes below | B | SPECIAL | | | | | | | cparmax | Refer to notes below | B | SPECIAL | | | | | | +----------+------------------------+-------+--------------+ 5.24 RFC3407 Attribute Analysis NOTE: The attributes (a=cparmin and a=cparmax) define minimum and maximum numerical values associated with the attributes described in a=cpar. Since the cpar attribute can either define a 'b=' attribute or any 'a=' attribute, the multiplexing category depends on actual attribute being encapsulated and the implications of the numerical values assigned. Hence it is recommended to consult the specification defining attributes (cparmin/cparmax) to further analyze their behavior under multiplexing. 5.25. RFC6284: Port Mapping between Unicast and Multicast RTP Sessions [RFC6284] presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. +------------------+-----------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------------------+-----------------------------+-------+----------+ | portmapping-req | Not recommended, if port | M | CAUTION | | | mapping is required by the | | | | | application | | | | | | | | +------------------+-----------------------------+-------+----------+ 5.25 RFC6284 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 27] Internet-Draft SDP Attribute Multiplexing December 2016 5.26. RFC6714: MSRP-CEMA [RFC6714] defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is optional. The extension allows middle boxes to anchor the MSRP connection, without the need for middle boxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middle boxes are deployed. This document also defines a SDP attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. +------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+-----------------------+-------+--------------+ | msrp-cema | Refer to notes below | M | TBD | | | | | | +------------+-----------------------+-------+--------------+ 5.26 RFC6714 Attribute Analysis NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing MRSP flows over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for the attributes in this section could be revisited. 5.27. RFC4583: SDP Format for BFCP Streams [RFC4583] document specifies how to describe Binary Floor Control Protocol (BFCP) streams in SDP descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. +------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+-----------------------+-------+--------------+ | floorctrl | Refer to notes below | M | TBD | | | | | | | confid | Not Impacted | M | NORMAL | | | | | | | userid | Not Impacted | M | NORMAL | | | | | | | floorid | Not Impacted | M | NORMAL | | | | | | +------------+-----------------------+-------+--------------+ 5.27 RFC4583 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 28] Internet-Draft SDP Attribute Multiplexing December 2016 NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing BFCP streams over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for the attributes in this section could be revisited. 5.28. RFC5547: SDP Offer/Answer for File Transfer [RFC5547] provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the SDP offer/answer model specified in [RFC3264]. +-------------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------------+-----------------------+-------+--------------+ | file-selector | Refer to notes below | M | TBD | | | | | | | file-transfer-id | Refer to notes below | M | TBD | | | | | | | file-disposition | Refer to notes below | M | TBD | | | | | | | file-date | Refer to notes below | M | TBD | | | | | | | file-icon | Refer to notes below | M | TBD | | | | | | | file-range | Refer to notes below | M | TBD | | | | | | +-------------------+-----------------------+-------+--------------+ 5.28 RFC5547 Attribute Analysis NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing MRSP flows over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for attributes in this section could be revisited. 5.29. RFC6849: SDP and RTP Media Loopback Extension [RFC6849] adds new SDP media types and 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 Voice over IP (VoIP), Real-time Text, and Video over IP performance metrics. Nandakumar Expires June 22, 2017 [Page 29] Internet-Draft SDP Attribute Multiplexing December 2016 +---------------------+-----------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +---------------------+-----------------+-------+-------------------+ | loopback rtp-pkt- | The attribute | M | IDENTICAL-PER-PT | | loopback | value MUST be | | | | | same for a | | | | | given codec | | | | | configuration | | | | | | | | | loopback rtp-media- | The attribute | M | IDENTICAL-PER-PT | | loopback | value MUST be | | | | | same for a | | | | | given codec | | | | | configuration | | | | | | | | | loopback-source | Not Impacted | M | NORMAL | | | | | | | loopback-mirror | Not Impacted | M | NORMAL | | | | | | +---------------------+-----------------+-------+-------------------+ 5.29 RFC6849 Analysis 5.30. RFC5760: RTCP with Unicast Feedback [RFC5760] specifies an extension to RTCP to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. +---------------+------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +---------------+------------------------------+-------+------------+ | rtcp-unicast | The attribute MUST be | M | IDENTICAL | | | reported across all "m=" | | | | | lines multiplexed | | | | | | | | +---------------+------------------------------+-------+------------+ 5.30 RFC5760 Attribute Analysis 5.31. RFC3611: RTCP XR [RFC3611] defines the Extended Report (XR) packet type for RTCP, and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). Nandakumar Expires June 22, 2017 [Page 30] Internet-Draft SDP Attribute Multiplexing December 2016 +----------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+---------------+-------+--------------+ | rtcp-xr | Not Impacted | B | NORMAL | | | | | | +----------+---------------+-------+--------------+ 5.31 RFC3611 Attribute Analysis 5.32. RFC5939: SDP Capability Negotiation [RFC5939] defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. +---------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------+-----------------------+-------+--------------+ | pcfg | Refer to Section 14 | M | SPECIAL | | | | | | | acfg | Refer to Section 14 | M | SPECIAL | | | | | | | csup | Not Impacted | B | NORMAL | | | | | | | creq | Not Impacted | B | NORMAL | | | | | | | acap | Refer to Section 14 | B | INHERIT | | | | | | | tcap | Refer to Section 14 | B | INHERIT | | | | | | | cap-v0 | Not Impacted | B | NORMAL | | | | | | +---------+-----------------------+-------+--------------+ 5.32 RFC5939 Attribute Analysis 5.33. RFC6871: SDP Media Capabilities Negotiation 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. [RFC6871] extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. Nandakumar Expires June 22, 2017 [Page 31] Internet-Draft SDP Attribute Multiplexing December 2016 +---------+-----------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +---------+-----------------------+-------+-------------------+ | rmcap | Refer to Section 14 | B | IDENTICAL-PER-PT | | | | | | | omcap | Not Impacted | B | NORMAL | | | | | | | mfcap | Refer to Section 14 | B | IDENTICAL-PER-PT | | | | | | | mscap | Refer to Section 14 | B | INHERIT | | | | | | | lcfg | Refer to Section 14 | B | SPECIAL | | | | | | | sescap | Refer to notes below | S | CAUTION | | | | | | | med-v0 | Not Impacted | S | NORMAL | | | | | | +---------+-----------------------+-------+-------------------+ 5.33 RFC6871 - Attribute Analysis NOTE: The "sescap" attribute is not recommended for use with multiplexing. The reason is that it requires the use of unique configuration numbers across the entire SDP (per [RFC6871]) as opposed to within a media description only (per [RFC5939]). As described in Section 14, the use of identical configuration numbers between multiplexed (bundled) media descriptions is the default way of indicating compatible configurations in a bundle. 5.34. RFC7006: Miscellaneous Capabilities Negotiation SDP [RFC7006] 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 session or media titles ("i=" line for each session or media). Nandakumar Expires June 22, 2017 [Page 32] Internet-Draft SDP Attribute Multiplexing December 2016 +----------+-----------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +----------+-----------------------------------+-------+------------+ | bcap | Inherit the category SUM as | B | INHERIT | | | applicable to b= attribute | | | | | | | | | bcap-v0 | Not Impacted | B | NORMAL | | | | | | | ccap | The connection address type MUST | B | IDENTICAL | | | be identical across all the | | | | | multiplexed "m=" lines | | | | | | | | | ccap-v0 | Not Impacted | B | NORMAL | | | | | | | icap | Not Impacted | B | NORMAL | | | | | | | icap-v0 | Not Impacted | B | NORMAL | | | | | | +----------+-----------------------------------+-------+------------+ 5.34 RFC7006 - Attribute Analysis 5.35. RFC4567: Key Management Extensions for SDP and RTSP [RFC4567] defines general extensions for SDP and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. +-----------+----------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-----------+----------------------------------+-------+------------+ | key-mgmt | Key management protocol MUST be | B | IDENTICAL | | | identical across all the "m=" | | | | | lines | | | | | | | | | mikey | Key management protocol MUST be | B | IDENTICAL | | | identical across all the "m=" | | | | | lines | | | | | | | | +-----------+----------------------------------+-------+------------+ 5.35 RFC4567 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 33] Internet-Draft SDP Attribute Multiplexing December 2016 5.36. RFC4572: Comedia over TLS in SDP [RFC4572] specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using SDP. It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. +--------------+-------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +--------------+-------------------------------+-------+------------+ | fingerprint | fingerprint value MUST be the | B | TRANSPORT | | | one that corresponds to the | | | | | "m=" line chosen for setting | | | | | up the underlying transport | | | | | flow | | | | | | | | +--------------+-------------------------------+-------+------------+ 5.36 RFC4572 Attribute Analysis 5.37. RFC4570: SDP Source Filters [RFC4570] describes how to adapt SDP to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source- filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. +----------------+-----------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +----------------+-----------------------------+-------+------------+ | source-filter | The attribute MUST be | B | IDENTICAL | | | repeated across all "m=" | | | | | lines multiplexed | | | | | | | | +----------------+-----------------------------+-------+------------+ 5.37 RFC4570 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 34] Internet-Draft SDP Attribute Multiplexing December 2016 5.38. RFC6128: RTCP Port for Multicast Sessions SDP has an attribute that allows RTP applications to specify an address and a port associated with the RTCP traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. [RFC6128] removes this restriction by introducing a new SDP attribute. +-----------------+----------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+----------------------------+-------+------------+ | multicast-rtcp | Multicast RTCP port MUST | B | IDENTICAL | | | be identical across all | | | | | the "m=" lines | | | | | | | | +-----------------+----------------------------+-------+------------+ 5.38 RFC6128 Attribute Analysis 5.39. RFC6189: ZRTP [RFC6189] defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast SRTP sessions for (VoIP applications. +------------+---------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +------------+---------------------------------+-------+------------+ | zrtp-hash | zrtp-hash attribute MUST be the | M | TRANSPORT | | | one that corresponds to the | | | | | "m=" line chosen for setting up | | | | | the underlying transport flow | | | | | | | | +------------+---------------------------------+-------+------------+ 5.39 RFC6189 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 35] Internet-Draft SDP Attribute Multiplexing December 2016 5.40. RFC4145: Connection-Oriented Media [RFC4145] describes how to express media transport over TCP using SDP. It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. +-------------+--------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-------------+--------------------------------+-------+------------+ | setup | The setup attribute MUST be | B | TRANSPORT | | | the one that corresponds to | | | | | the "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow. | | | | | | | | | connection | The connection attribute MUST | B | TRANSPORT | | | be the one that corresponds to | | | | | the "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow. | | | | | | | | +-------------+--------------------------------+-------+------------+ 5.40 RFC4145 Attribute Analysis 5.41. RFC6947: The SDP altc Attribute [RFC6947] proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax. +-------+--------------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-------+--------------------------------------+-------+------------+ | altc | The IP Address and port MUST be the | M | TRANSPORT | | | one that corresponds to the "m=" | | | | | line chosen for setting up the | | | | | underlying transport flow | | | | | | | | +-------+--------------------------------------+-------+------------+ 5.41 RFC6947 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 36] Internet-Draft SDP Attribute Multiplexing December 2016 5.42. RFC7195: SDP Extension for Circuit Switched Bearers in PSTN [RFC7195] describes use cases, requirements, and protocol extensions for using SDP offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). +--------------------------+-------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +--------------------------+-------------------+-------+------------+ | cs-correlation:callerid | Refer to notes | M | TBD | | | below | | | | | | | | | cs-correlation:uuie | Refer to notes | M | TBD | | | below | | | | | | | | | cs-correlation:dtmf | Refer to notes | M | TBD | | | below | | | | | | | | | cs-correlation:external | Refer to notes | M | TBD | | | below | | | | | | | | +--------------------------+-------------------+-------+------------+ 5.42 RFC7195 Attribute Analysis NOTE: [RFC7195] defines SDP attributes for establishing audio and video media streams over circuit-switched bearers by defining a new nettype value "PSTN". However, section 7.2 of [I-D.ietf-mmusic-sdp-bundle-negotiation] requires the "c=" line nettype value of "IN". If in future there exists a specification that defines procedures to multiplex media streams over nettype "PSTN", the multiplexing categories for attributes in this section could be revisited. 5.43. RFC7272: IDMS Using the RTP Control Protocol (RTCP) [RFC7272] defines a new RTCP Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). Nandakumar Expires June 22, 2017 [Page 37] Internet-Draft SDP Attribute Multiplexing December 2016 +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | rtcp-idms | Not Impacted | M | NORMAL | | | | | | +------------+---------------+-------+--------------+ 5.43 RFC7272 Attribute Analysis 5.44. RFC5159: Open Mobile Alliance (OMA) Broadcast (BCAST) SDP Attributes [RFC5159] provides descriptions of SDP attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. +---------------------+-----------------------+-------+-------------+ | Name | Notes | Level | Mux | | | | | Category | +---------------------+-----------------------+-------+-------------+ | bcastversion | Not Impacted | S | NORMAL | | | | | | | stkmstream | Not Impacted | B | NORMAL | | | | | | | SRTPAuthentication | Needs further | M | TBD | | | analysis | | | | | | | | | SRTPROCTxRate | Needs further | M | TBD | | | analysis | | | | | | | | +---------------------+-----------------------+-------+-------------+ 5.44 RFC5159 Attribute Analysis 5.45. RFC6193: Media Description for IKE in SDP [RFC6193] specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of SDP so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. Nandakumar Expires June 22, 2017 [Page 38] Internet-Draft SDP Attribute Multiplexing December 2016 +-------------------+----------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-------------------+----------------------------+-------+----------+ | ike-setup | Unlikely to use IKE in the | B | CAUTION | | | context of multiplexing | | | | | | | | | psk-fingerprint | Unlikely to use IKE in the | B | CAUTION | | | context of multiplexing | | | | | | | | | ike-esp | Unlikely to use IKE in the | B | CAUTION | | | context of multiplexing | | | | | | | | | ike-esp-udpencap | Unlikely to use IKE in the | B | CAUTION | | | context of multiplexing | | | | | | | | +-------------------+----------------------------+-------+----------+ 5.45 RFC6193 Attribute Analysis 5.46. RFC2326: Real Time Streaming Protocol The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over 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. +----------+------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +----------+------------------------------------+-------+-----------+ | etag | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | | range | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | | control | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | | mtag | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | +----------+------------------------------------+-------+-----------+ 5.46 RFC2326 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 39] Internet-Draft SDP Attribute Multiplexing December 2016 NOTE: [RFC2326] defines SDP attributes that are applicable in the declarative usage of SDP alone. For purposes of this document, only the Offer/Answer usage of SDP is considered as mandated by [I-D.ietf-mmusic-sdp-bundle-negotiation]. 5.47. RFC6064: SDP and RTSP Extensions for 3GPP The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. [RFC6064] provides information about these extensions and registers the RTSP and SDP extensions with IANA. +--------------------------------+---------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +--------------------------------+---------------+-------+----------+ | X-predecbufsize | Refer to | M | CAUTION | | | notes below | | | | | | | | | X-initpredecbufperiod | Refer to | M | CAUTION | | | notes below | | | | | | | | | X-initpostdecbufperiod | Refer to | M | CAUTION | | | notes below | | | | | | | | | X-decbyterate | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3gpp-videopostdecbufsize | Refer to | M | CAUTION | | | notes below | | | | | | | | | framesize | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3GPP-Integrity-Key | Refer to | S | CAUTION | | | notes below | | | | | | | | | 3GPP-SDP-Auth | Refer to | S | CAUTION | | | notes below | | | | | | | | | 3GPP-SRTP-Config | Refer to | M | CAUTION | | | notes below | | | | | | | | | alt | Refer to | M | CAUTION | | | notes below | | | | | | | | | alt-default-id | Refer to | M | CAUTION | | | notes below | | | Nandakumar Expires June 22, 2017 [Page 40] Internet-Draft SDP Attribute Multiplexing December 2016 | | | | | | alt-group | Refer to | S | CAUTION | | | notes below | | | | | | | | | 3GPP-Adaptation-Support | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3GPP-Asset-Information | Refer to | B | CAUTION | | | notes below | | | | | | | | | mbms-mode | Refer to | B | CAUTION | | | notes below | | | | | | | | | mbms-flowid | Refer to | M | CAUTION | | | notes below | | | | | | | | | mbms-repair | Refer to | B | CAUTION | | | notes below | | | | | | | | | 3GPP-QoE-Metrics | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3GPP-QoE-Metrics:Corruption | Refer to | M | CAUTION | | duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Rebuffering | Refer to | M | CAUTION | | duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Initial | Refer to | M | CAUTION | | buffering duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Successive | Refer to | M | CAUTION | | loss of RTP packets | notes below | | | | | | | | | 3GPP-QoE-Metrics:Frame rate | Refer to | M | CAUTION | | deviation | notes below | | | | | | | | | 3GPP-QoE-Metrics:Jitter | Refer to | M | CAUTION | | duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Content | Refer to | B | CAUTION | | Switch Time | notes below | | | | | | | | | 3GPP-QoE-Metrics:Average Codec | Refer to | M | CAUTION | | Bitrate | notes below | | | | | | | | | 3GPP-QoE-Metrics:Codec | Refer to | M | CAUTION | | Information | notes below | | | Nandakumar Expires June 22, 2017 [Page 41] Internet-Draft SDP Attribute Multiplexing December 2016 | | | | | | 3GPP-QoE-Metrics:Buffer Status | Refer to | M | CAUTION | | | notes below | | | | | | | | +--------------------------------+---------------+-------+----------+ 5.47 RFC6064 Attribute Analysis NOTE: [RFC6064] defines SDP attributes that are applicable in the declarative usage of SDP alone. For purposes of this document, only the Offer/Answer usage of SDP is considered as mandated by [I-D.ietf-mmusic-sdp-bundle-negotiation]. 5.48. RFC3108: ATM SDP [RFC3108] describes conventions for using SDP described for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). +------------------------+--------------------+-------+-------------+ | Name | Notes | Level | Mux | | | | | Category | +------------------------+--------------------+-------+-------------+ | aalType | Refer to notes | B | CAUTION | | | below | | | | eecid | Refer to notes | B | CAUTION | | | below | | | | capability | Refer to notes | B | CAUTION | | | below | | | | qosClass | Refer to notes | B | CAUTION | | | below | | | | bcob | Refer to notes | B | CAUTION | | | below | | | | stc | Refer to notes | B | CAUTION | | | below | | | | upcc | Refer to notes | B | CAUTION | | | below | | | | atmQOSparms | Refer to notes | B | CAUTION | | | below | | | | atmTrfcDesc | Refer to notes | B | CAUTION | | | below | | | | abrParms | Refer to notes | B | CAUTION | | | below | | | | abrSetup | Refer to notes | B | CAUTION | | | below | | | | bearerType | Refer to notes | B | CAUTION | | | below | | | | lij | Refer to notes | B | CAUTION | Nandakumar Expires June 22, 2017 [Page 42] Internet-Draft SDP Attribute Multiplexing December 2016 | | below | | | | anycast | Refer to notes | B | CAUTION | | | below | | | | cache | Refer to notes | B | CAUTION | | | below | | | | bearerSigIE | Refer to notes | B | CAUTION | | | below | | | | aalApp | Refer to notes | B | CAUTION | | | below | | | | cbrRate | Refer to notes | B | CAUTION | | | below | | | | sbc | Refer to notes | B | CAUTION | | | below | | | | clkrec | Refer to notes | B | CAUTION | | | below | | | | fec | Refer to notes | B | CAUTION | | | below | | | | prtfl | Refer to notes | B | CAUTION | | | below | | | | structure | Refer to notes | B | CAUTION | | | below | | | | cpsSDUsize | Refer to notes | B | CAUTION | | | below | | | | aal2CPS | Refer to notes | B | CAUTION | | | below | | | | aal2CPSSDUrate | Refer to notes | B | CAUTION | | | below | | | | aal2sscs3661unassured | Refer to notes | B | CAUTION | | | below | | | | aal2sscs3661assured | Refer to notes | B | CAUTION | | | below | | | | aal2sscs3662 | Refer to notes | B | CAUTION | | | below | | | | aal5sscop | Refer to notes | B | CAUTION | | | below | | | | atmmap | Refer to notes | B | CAUTION | | | below | | | | silenceSupp | Refer to notes | B | CAUTION | | | below | | | | ecan | Refer to notes | B | CAUTION | | | below | | | | gc | Refer to notes | B | CAUTION | | | below | | | | profileDesc | Refer to notes | B | CAUTION | | | below | | | | vsel | Refer to notes | B | CAUTION | | | below | | | | dsel | Refer to notes | B | CAUTION | Nandakumar Expires June 22, 2017 [Page 43] Internet-Draft SDP Attribute Multiplexing December 2016 | | below | | | | fsel | Refer to notes | B | CAUTION | | | below | | | | onewaySel | Refer to notes | B | CAUTION | | | below | | | | codecconfig | Refer to notes | B | CAUTION | | | below | | | | isup_usi | Refer to notes | B | CAUTION | | | below | | | | uiLayer1_Prot | Refer to notes | B | CAUTION | | | below | | | | chain | Refer to notes | B | CAUTION | | | below | | | | | | | | +------------------------+--------------------+-------+-------------+ 5.48 RFC3108 Attribute Analysis NOTE: RFC3108 describes conventions for using SDP for characterizing ATM bearer connections using an AAL1, AAL2 or AAL5 adaptation layers. For AAL1, AAL2 and AAL5, bearer connections can be used to transport single media streams. In addition, for AAL1 and AAL2, multiple media streams can be multiplexed into a bearer connection. For all adaptation types (AAL1, AAL2 and AAL5), bearer connections can be bundled into a single media group. In all cases addressed by RFC3108, a real-time media stream (voice, video, voiceband data, pseudo-wire, and others) or a multiplex of media streams is mapped directly into an ATM connection. RFC3108 does not address cases where ATM serves as a low-level transport pipe for IP packets which in turn can carry one or more real-time (e.g. VoIP) media sessions with a life-cycle different from that of the underlying ATM transport. 5.49. 3GPP TS 26.114 [R3GPPTS26.114] specifies IP multimedia subsystem: Media handling and interaction Nandakumar Expires June 22, 2017 [Page 44] Internet-Draft SDP Attribute Multiplexing December 2016 +----------------------+-------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +----------------------+-------------------------+-------+----------+ | 3gpp_sync_info | Usage defined for the | M | NORMAL | | | IP Multimedia Subsystem | | | | | | | | | 3gpp_MaxRecvSDUSize | Usage defined for the | M | NORMAL | | | IP Multimedia Subsystem | | | | | | | | +----------------------+-------------------------+-------+----------+ 5.49 3GPP TS 26.114 Attribute Analysis 5.50. 3GPP TS 183.063 [R3GPPTS183.063] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); +---------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------------------+---------------+-------+--------------+ | PSCid | Not Impacted | S | NORMAL | | | | | | | bc_service | Not Impacted | S | NORMAL | | | | | | | bc_program | Not Impacted | S | NORMAL | | | | | | | bc_service_package | Not Impacted | S | NORMAL | | | | | | +---------------------+---------------+-------+--------------+ 5.50 3GPP TS 183.063 Attribute Analysis 5.51. 3GPP TS 24.182 [R3GPPTS24.182] specifies IP multimedia subsystem Custom Alerting tones Nandakumar Expires June 22, 2017 [Page 45] Internet-Draft SDP Attribute Multiplexing December 2016 +-------------+---------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-------------+---------------------------------+-------+-----------+ | g.3gpp.cat | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem | | | | | | | | +-------------+---------------------------------+-------+-----------+ 5.51 3GPP TS 24.182 Attribute Analysis 5.52. 3GPP TS 24.183 [R3GPPTS24.183] specifies IP multimedia subsystem Custom Ringing Signal +-------------+---------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-------------+---------------------------------+-------+-----------+ | g.3gpp.crs | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem | | | | | | | | +-------------+---------------------------------+-------+-----------+ 5.52 3GPP TS 24.183 Attribute Analysis 5.53. 3GPP TS 24.229 [R3GPPTS24.229] specifies IP multimedia call control protocol based on Session Initial protocol and Session Description Protocol. Nandakumar Expires June 22, 2017 [Page 46] Internet-Draft SDP Attribute Multiplexing December 2016 +------------------+---------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +------------------+---------------------------+-------+------------+ | secondary-realm | secondary-realm MUST be | M | TRANSPORT | | | the one that corresponds | | | | | to the "m=" line chosen | | | | | for setting up the | | | | | underlying transport flow | | | | | | | | | visited-realm | visited-realm MUST be the | M | TRANSPORT | | | one that corresponds to | | | | | the "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | omr-m-cksum | Not Impacted | M | NORMAL | | | | | | | omr-s-cksum | Not Impacted | M | NORMAL | | | | | | | omr-m-att | Not Impacted | M | NORMAL | | | | | | | omr-s-att | Not Impacted | M | NORMAL | | | | | | | omr-m-bw | Not Impacted | M | NORMAL | | | | | | | omr-s-bw | Not Impacted | M | NORMAL | | | | | | | omr-codecs | Not Impacted | M | NORMAL | | | | | | +------------------+---------------------------+-------+------------+ 5.53 3GPP TS 24.229 Attribute Analysis 5.54. ITU T.38 [T.38] defines procedures for real-time Group 3 facsimile communications over IP networks. +------------------------+--------------------+-------+-------------+ | Name | Notes | Level | Mux | | | | | Category | +------------------------+--------------------+-------+-------------+ | T38FaxVersion | Refer to notes | M | TBD | | | below | | | | | | | | | T38MaxBitRate | Refer to notes | M | TBD | | | below | | | Nandakumar Expires June 22, 2017 [Page 47] Internet-Draft SDP Attribute Multiplexing December 2016 | | | | | | T38FaxFillBitRemoval | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxTranscodingMMR | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxTranscodingJBIG | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxRateManagement | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxMaxBuffer | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxMaxDatagram | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxUdpEC | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxMaxIFP | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxUdpECDepth | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxUdpFECMaxSpan | Refer to notes | M | TBD | | | below | | | | | | | | | T38ModemType | Refer to notes | M | TBD | | | below | | | | | | | | | T38VendorInfo | Refer to notes | M | TBD | | | below | | | | | | | | +------------------------+--------------------+-------+-------------+ 5.54 ITU T.38 Attribute Analysis NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing fax protocols flows over a single 5-tuple. Once such a specification is available, the multiplexing category assignments for the attributes in this section could be revisited. Nandakumar Expires June 22, 2017 [Page 48] Internet-Draft SDP Attribute Multiplexing December 2016 5.55. ITU-T Q.1970 [Q.1970] defines Bearer Independent Call Control (BICC) IP bearer control protocol. +--------+---------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +--------+---------------------------------------+-------+----------+ | ipbcp | ipbcp version identifies type of IP | S | SPECIAL | | | bearer control protocol (IPBCP) | | | | | message used in BICC (ITU-T Q.1901) | | | | | environment which are limited to | | | | | single media payload. Refer to the | | | | | pertinent ITU-T specifications while | | | | | multiplexing | | | | | | | | +--------+---------------------------------------+-------+----------+ 5.55 ITU-T Q.1970 Attribute Analysis 5.56. ITU-T H.248.15 ITU-T H.248.15 [H.248.15] defines Gateway Control Protocol SDP H.248 package attribute Nandakumar Expires June 22, 2017 [Page 49] Internet-Draft SDP Attribute Multiplexing December 2016 +-----------+------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------+------------------------------------+-------+----------+ | h248item | It is only applicable for | B | SPECIAL | | | signaling the inclusion of H.248 | | | | | extension packages to a gateway | | | | | via the local and remote | | | | | descriptors. The attribute itself | | | | | is unaffected by multiplexing, but | | | | | the packaged referenced in a | | | | | specific use of the attribute can | | | | | be impacted. Further analysis of | | | | | each package is needed to | | | | | determine if there is an issue. | | | | | This is only a concern in | | | | | environments using a decomposed | | | | | server/gateway with H.248 signaled | | | | | between them. The ITU-T will need | | | | | to do further analysis of various | | | | | packages when they specify how to | | | | | signal the use of multiplexing to | | | | | a gateway | | | | | | | | +-----------+------------------------------------+-------+----------+ 5.56 ITU-T H.248.15 Attribute Analysis 5.57. RFC4975: The Message Session Relay Protocol [RFC4975] the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. Nandakumar Expires June 22, 2017 [Page 50] Internet-Draft SDP Attribute Multiplexing December 2016 +-----------------------+---------------------+-------+-------------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------------+---------------------+-------+-------------+ | accept-types | Refer to notes | M | TBD | | | below | | | | | | | | | accept-wrapped-types | Refer to notes | M | TBD | | | below | | | | | | | | | max-size | Refer to notes | M | TBD | | | below | | | | | | | | | path | Refer to notes | M | TBD | | | below | | | | | | | | +-----------------------+---------------------+-------+-------------+ 5.57 RFC4975 Attribute Analysis NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing MRSP flows over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for the attributes in this section could be revisited. 5.58. Historical Attributes This section specifies analysis for the attributes that are included for historic usage alone by the [IANA]. +----------+----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+----------------------+-------+--------------+ | rtpred1 | Historic attributes | M | CAUTION | | | | | | | rtpred2 | Historic attributes | M | CAUTION | | | | | | +----------+----------------------+-------+--------------+ 5.58 Historical Attribute Analysis 6. bwtype Attribute Analysis This section specifies handling of specific bandwidth attributes when used in multiplexing scenarios. Nandakumar Expires June 22, 2017 [Page 51] Internet-Draft SDP Attribute Multiplexing December 2016 6.1. RFC4566: SDP [RFC4566] defines SDP that is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. +------------+-----------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------------+-----------------------------------+-------+----------+ | bwtype:CT | Not Impacted | S | NORMAL | | | | | | | bwtype:AS | For the media level usage, the | B | SUM | | | aggregate of individual bandwidth | | | | | values is considered | | | | | | | | +------------+-----------------------------------+-------+----------+ 6.1 RFC4566 bwtype Analysis 6.2. RFC3556: SDP Bandwidth Modifiers for RTCP Bandwidth [RFC3556] defines an extension to SDP to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTCP packets in a RTP session. +------------+-----------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------------+-----------------------------------+-------+----------+ | bwtype:RS | Session level usage represents | B | SUM | | | session aggregate and media level | | | | | usage indicates SUM of the | | | | | individual values while | | | | | multiplexing | | | | | | | | | bwtype:RR | Session level usage represents | B | SUM | | | session aggregate and media level | | | | | usage indicates SUM of the | | | | | individual values while | | | | | multiplexing | | | | | | | | +------------+-----------------------------------+-------+----------+ 6.2 RFC3556 bwtype Analysis Nandakumar Expires June 22, 2017 [Page 52] Internet-Draft SDP Attribute Multiplexing December 2016 6.3. RFC3890: Bandwidth Modifier for SDP [RFC3890] defines SDP Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. +--------------+---------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +--------------+---------------------------------+-------+----------+ | bwtype:TIAS | The usage of TIAS is not | B | SPECIAL | | | defined under Offer/Answer | | | | | usage. | | | | | | | | | maxprate | The usage of TIAS and maxprate | B | SPECIAL | | | is not well defined under | | | | | multiplexing | | | | | | | | +--------------+---------------------------------+-------+----------+ 6.3 RFC3890 bwtype Analysis NOTE: The intention of TIAS is that the media level bit-rate is multiplied with the known per-packet overhead for the selected transport and the maxprate value to determine the worst case bit-rate from the transport to more accurately capture the required usage. Summing TIAS values independently across "m=" lines and multiplying the computed sum with maxprate and the per-packet overhead would inflate the value significantly. Instead performing multiplication and adding the individual values is a more appropriate usage. 7. rtcp-fb Attribute Analysis This section analyzes rtcp-fb SDP attributes. 7.1. RFC4585: RTP/AVPF [RFC4585] defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. Nandakumar Expires June 22, 2017 [Page 53] Internet-Draft SDP Attribute Multiplexing December 2016 +----------+----------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +----------+----------------------------+-------+-------------------+ | ack rpsi | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given codec | | | | | configuration | | | | | | | | | ack app | Feedback parameters MUST | M | SPECIAL | | | be handled in the app | | | | | specific way when | | | | | multiplexed | | | | | | | | | nack | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given codec | | | | | configuration | | | | | | | | | nack pli | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given codec | | | | | configuration | | | | | | | | | nack sli | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given codec | | | | | configuration | | | | | | | | | nack | The attribute value MUST | M | IDENTICAL-PER-PT | | rpsi | be same for a given codec | | | | | configuration | | | | | | | | | nack app | Feedback parameters MUST | M | SPECIAL | | | be handled in the app | | | | | specific way when | | | | | multiplexed | | | | | | | | | trr-int | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given codec | | | | | configuration | | | | | | | | +----------+----------------------------+-------+-------------------+ 7.1 RFC4585 Attribute Analysis 7.2. RFC5104: Codec Control Messages in AVPF [RFC5104] specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. Nandakumar Expires June 22, 2017 [Page 54] Internet-Draft SDP Attribute Multiplexing December 2016 +------+--------------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +------+--------------------------------+-------+-------------------+ | ccm | The attribute value MUST be | M | IDENTICAL-PER-PT | | | same for a given codec | | | | | configuration | | | | | | | | +------+--------------------------------+-------+-------------------+ 7.2 RFC5104 Attribute Analysis 7.3. RFC6285: Unicast-Based Rapid Acquisition of Multicast RTP Sessions (RAMS) [RFC6285] describes a method using the existing RTP and RTCP machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. +-------+-------------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +-------+-------------------------------+-------+-------------------+ | nack | The attribute value MUST be | M | IDENTICAL-PER-PT | | rai | same for a given codec | | | | | configuration | | | | | | | | +-------+-------------------------------+-------+-------------------+ 7.3 RFC6285 Attribute Analysis 7.4. RFC6679: ECN for RTP over UDP/IP [RFC6679] specifies how Explicit Congestion Notification (ECN) can be used with the RTP running over UDP, using the 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 STUN extension used in the optional initialization method using ICE. Nandakumar Expires June 22, 2017 [Page 55] Internet-Draft SDP Attribute Multiplexing December 2016 +------------------+---------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +------------------+---------------------------+-------+------------+ | ecn-capable-rtp | ECN markup are enabled at | M | IDENTICAL | | | the RTP session level | | | | | | | | | nack ecn | This attribute enables | M | IDENTICAL | | | ECN at the RTP session | | | | | level | | | | | | | | +------------------+---------------------------+-------+------------+ 7.4 RFC6679 Attribute Analysis 7.5. RFC6642: Third-Party Loss Report In a large RTP session using the RTCP feedback mechanism defined in [RFC4585], 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. [RFC6642] 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. +--------+------------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +--------+------------------------------+-------+-------------------+ | nack | The attribute value MUST be | M | IDENTICAL-PER-PT | | tllei | same for a given codec | | | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER-PT | | pslei | same for a given codec | | | | | configuration | | | | | | | | +--------+------------------------------+-------+-------------------+ 7.5 RFC6642 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 56] Internet-Draft SDP Attribute Multiplexing December 2016 7.6. RFC5104: Codec Control Messages in AVPF [RFC5104] specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. +--------+------------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +--------+------------------------------+-------+-------------------+ | ccm | The attribute value MUST be | M | IDENTICAL-PER-PT | | fir | same for a given codec | | | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER-PT | | tmmbr | same for a given codec | | | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER-PT | | tstr | same for a given codec | | | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER-PT | | vbcm | same for a given codec | | | | | configuration | | | | | | | | +--------+------------------------------+-------+-------------------+ 7.6 RFC5104 Attribute Analysis 8. group Attribute Analysis This section analyzes SDP "group" attribute semantics [RFC5888]. 8.1. RFC5888: SDP Grouping Framework [RFC5888] defines a framework to group "m" lines in SDP for different purposes. Nandakumar Expires June 22, 2017 [Page 57] Internet-Draft SDP Attribute Multiplexing December 2016 +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | group:LS | Not Impacted | S | NORMAL | | | | | | | group:FID | Not Impacted | S | NORMAL | | | | | | +------------+---------------+-------+--------------+ 8.1 RFC5888 Attribute Analysis 8.2. RFC3524: Mapping Media Streams to Resource Reservation Flows [RFC3524] defines an extension to the SDP grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | group:SRF | Not Impacted | S | NORMAL | | | | | | +------------+---------------+-------+--------------+ 8.2 RFC3524 Attribute Analysis 8.3. RFC4091: ANAT Semantics [RFC4091] defines ANAT semantics for the SDP grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. +-------------+------------------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------+------------------------------+-------+--------------+ | group:ANAT | ANAT semantics is obsoleted | S | CAUTION | | | | | | +-------------+------------------------------+-------+--------------+ 8.3 RFC4091 Attribute Analysis 8.4. RFC5956: FEC Grouping Semantics in SDP [RFC5956] defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in SDP. The semantics defined in the document are to be used with the SDP Grouping Framework [RFC5888]. These semantics allow the description Nandakumar Expires June 22, 2017 [Page 58] Internet-Draft SDP Attribute Multiplexing December 2016 of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC- level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. +---------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------------+---------------+-------+--------------+ | group:FEC-FR | Not Impacted | S | NORMAL | | | | | | +---------------+---------------+-------+--------------+ 8.4 RFC5956 Attribute Analysis 8.5. RFC5583: Signaling Media Decoding Dependency in SDP [RFC5583] defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in SDP. This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. +------------+--------------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +------------+--------------------------+-------+-------------------+ | group:DDP | Not Impacted | S | NORMAL | | | | | | | depend lay | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given | | | | | codec configuration | | | | | | | | | depend mdc | The attribute value MUST | M | IDENTICAL-PER-PT | | | be same for a given | | | | | codec configuration | | | | | | | | +------------+--------------------------+-------+-------------------+ 8.5 RFC5583 Attribute Analysis 8.6. RFC7104: Duplication Grouping Semantics in the SDP [RFC7104] defines the semantics for grouping redundant streams in SDP, The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the SSRC)level are also defined in this document for RTP streams using SSRC multiplexing. Nandakumar Expires June 22, 2017 [Page 59] Internet-Draft SDP Attribute Multiplexing December 2016 +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | group:DUP | Not Impacted | S | NORMAL | | | | | | +------------+---------------+-------+--------------+ 8.6 RFC7104 Attribute Analysis 9. ssrc-group Attribute Analysis This section analyzes "ssrc-group" semantics. 9.1. RFC5576: Source-Specific SDP Attributes [RFC5576] defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. +--------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------------------+---------------+-------+--------------+ | ssrc-group:FID | Not Impacted | SR | NORMAL | | | | | | | ssrc-group:FEC | Not Impacted | SR | NORMAL | | | | | | | ssrc-group:FEC-FR | Not Impacted | SR | NORMAL | | | | | | +--------------------+---------------+-------+--------------+ 9.1 RFC5576 Attribute Analysis 9.2. RFC7104: Duplication Grouping Semantics in the SDP [RFC7104] defines the semantics for grouping redundant streams in SDP. The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing. Nandakumar Expires June 22, 2017 [Page 60] Internet-Draft SDP Attribute Multiplexing December 2016 +-----------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-----------------+---------------+-------+--------------+ | ssrc-group:DUP | Not Impacted | SR | NORMAL | | | | | | +-----------------+---------------+-------+--------------+ 9.2 RFC7104 Attribute Analysis 10. QoS Mechanism Token Analysis This section analyzes QoS tokes specified with SDP. 10.1. RFC5432: QoS Mechanism Selection in SDP [RFC5432] defines procedures to negotiate QOS mechanisms using the SDP offer/answer model. +-------+--------------------------------------+-------+------------+ | Name | Notes | Level | Mux | | | | | Category | +-------+--------------------------------------+-------+------------+ | rsvp | rsvp attribute MUST be the one that | B | TRANSPORT | | | corresponds to the "m=" line chosen | | | | | for setting up the underlying | | | | | transport flow | | | | | | | | | nsis | rsvp attribute MUST be the one that | B | TRANSPORT | | | corresponds to the "m=" line chosen | | | | | for setting up the underlying | | | | | transport | | | | | | | | +-------+--------------------------------------+-------+------------+ 10.1 RFC5432 Attribute Analysis NOTE: A single Differentiated Services Code Point (DSCP) code point per flow being multiplexed doesn't impact multiplexing since QOS mechanisms are signaled/scoped per flow. For scenarios that involve having different DSCP code points for packets being transmitted over the same 5-tuple, issues as discussed in [RFC7657] need to be taken into consideration. 11. k= Attribute Analysis Nandakumar Expires June 22, 2017 [Page 61] Internet-Draft SDP Attribute Multiplexing December 2016 11.1. RFC4566: SDP [RFC4566] defines SDP that is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. +------+-----------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------+-----------------------------------------+-------+----------+ | k= | It is not recommended to use this | S | CAUTION | | | attribute under multiplexing | | | | | | | | +------+-----------------------------------------+-------+----------+ 11.1 RFC4566 Attribute Analysis 12. content Attribute Analysis 12.1. RFC4796 [RFC4796] defines a new SDP media-level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. +------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------------+---------------+-------+--------------+ | content:slides | Not Impacted | M | NORMAL | | | | | | | content:speaker | Not Impacted | M | NORMAL | | | | | | | content:main | Not Impacted | M | NORMAL | | | | | | | content:sl | Not Impacted | M | NORMAL | | | | | | | content:alt | Not Impacted | M | NORMAL | | | | | | +------------------+---------------+-------+--------------+ 12.1 RFC4796 Attribute Analysis Nandakumar Expires June 22, 2017 [Page 62] Internet-Draft SDP Attribute Multiplexing December 2016 13. Payload Formats 13.1. RFC5109: RTP Payload Format for Generic FEC [RFC5109] describes a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. +---------------------+--------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +---------------------+--------------------------+-------+----------+ | audio/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to | | | | | reuse of SSRCs | | | | | | | | | video/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to | | | | | reuse of SSRCs | | | | | | | | | text/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to | | | | | reuse of SSRCs | | | | | | | | | application/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to | | | | | reuse of SSRCs | | | | | | | | +---------------------+--------------------------+-------+----------+ 13.1 RFC5109 Payload Format Analysis 14. Multiplexing Considerations for Encapsulating Attributes This sections deals with recommendations for defining the multiplexing characteristics of the SDP attributes that encapsulate other SDP attributes/parameters. Such attributes as of today, for example, are defined in [RFC3407], [RFC5939] and [RFC6871] as part of a generic framework for indicating and negotiating transport, media, and media format related capabilities in the SDP. The behavior of such attributes under multiplexing is in turn defined by the multiplexing behavior of the attributes they encapsulate which Nandakumar Expires June 22, 2017 [Page 63] Internet-Draft SDP Attribute Multiplexing December 2016 are made known once the Offer/Answer negotiation process is completed. 14.1. RFC3407: cpar Attribute Analysis [RFC3407] capability parameter attribute (a=cpar) encapsulates b= (bandwidth) or an a= attribute. For bandwidth attribute encapsulation, the category SUM is inherited. For the case of a= attribute, the category corresponding to the SDP attribute being encapsulated is inherited. v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=video 3456 RTP/AVP 100 a=rtpmap:100 VP8/90000 a=sqn: 0 a=cdsc: 1 video RTP/AVP 100 a=cpar: a=rtcp-mux m=video 3456 RTP/AVP 101 a=rtpmap:101 VP8/90000 a=fmtp:100 max-fr=15;max-fs=1200 a=cdsc: 2 video RTP/AVP 101 a=cpar: a=rtcp-mux In the above example,the category IDENTICAL is inherited for the cpar encapsulated rtcp-mux attribute. 14.2. RFC5939 Analysis [RFC5939] defines a general SDP capability negotiation framework. It also specifies how to provide transport protocols and SDP attributes as capabilities and negotiate them using the framework. For this purpose, [RFC5939] defines the following o A set of capabilities for the session and its associated media stream components, supported by each side. The attribute ("a=acap") defines how to list an attribute name and its associated value (if any) as a capability. The attribute ("a=tcap") defines how to list transport protocols (e.g., "RTP/ AVP") as capabilities. o A set of potential configurations ("a=pcfg") provided by the offerer to indicate which combinations of those capabilities can be used for the session and its associated media stream Nandakumar Expires June 22, 2017 [Page 64] Internet-Draft SDP Attribute Multiplexing December 2016 components. Potential configurations are not ready for use until fully negotiated. They provide an alternative that MAY be used, subject to SDP capability negotiation procedures. In particular the answerer MAY choose one of the potential configurations for use as part of the current Offer/Answer exchange. o An actual configuration ("a=acfg") for the session and its associated media stream components. The actual configuration identifies the potential configuration that was negotiated for use. Use of an actual configuration does not require any further negotiation. o A negotiation process that takes the current actual and the set of potential configurations (combinations of capabilities) as input and provides the negotiated actual configurations as output. In [RFC5939] the negotiation process is done independently for each media description. 14.2.1. Recommendation: Procedures for Potential Configuration Pairing This section provides recommendations for entities generating and processing SDP under the generic capability negotiation framework as defined in [RFC5939] under the context of media stream multiplexing. These recommendations are provided for the purposes of enabling the Offerer to make sure that the generated potential configurations between the multiplexed streams can (easily) be negotiated to be consistent between those streams. In particular, the procedures aim to simplify Answerer's procedure to choose potential configurations that are consistent across all the multiplexed media descriptions. A potential configuration selects a set of attributes and parameters that become part of the media description when negotiated. When multiplexing media descriptions with potential configurations specified, there MAY be a need for coordinating this selection between multiplexed media descriptions to ensure the right multiplexing behavior. Although it is possible to analyze the various potential configurations in multiplexed media descriptions to find combinations that satisfy such constraints, it can quickly become complicated to do so. The procedures defined in [RFC5939] state that each potential configuration in the SDP has a unique configuration number, however the scope of uniqueness is limited to each media description. To make it simple for the answerer to chose valid combinations of potential configurations across media descriptions in a given bundle Nandakumar Expires June 22, 2017 [Page 65] Internet-Draft SDP Attribute Multiplexing December 2016 group, we provide a simple rule for constructing potential configurations o Let m-bundle be the set of media descriptions that form a given bundle . o Let m-bundle-pcfg be the set of media descriptions in m-bundle that include one or more potential configurations. o Each media description in m-bundle-pcfg MUST have at least one potential configuration with the same configuration number (e.g. "1"). o For each potential configuration with configuration number x in m- bundle-pcfg, the offerer MUST ensure that if the answerer chooses configuration number x in each of the media descriptions in m- bundle-pcfg, then the resulting SDP will have all multiplexing constraints satisfied for those media descriptions. o Since it is nearly impossible to define a generic mechanism for various capability extensions, this document does't provide procedures for dealing with the capability extension attributes. However, Section 14.3 provide analysis of media capability extension attributes as defined in [RFC6871]. The above allows the answerer to easily find multiplexing compatible combinations of potential configurations: The answerer simply choses a potential configuration (number) that is present in all of the media descriptions with potential configurations in the bundle. Note that it is still possible for the offerer to provide additional potential configurations with independent configuration numbers. The answerer will have to perform more complicated analysis to determine valid multiplexed combinations of those. 14.2.1.1. Example: Transport Capability Multiplexing Nandakumar Expires June 22, 2017 [Page 66] Internet-Draft SDP Attribute Multiplexing December 2016 v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=tcap:1 RTP/SAVPF a=tcap:2 RTP/SAVP a=group:BUNDLE audio video m=audio a=mid:audio a=pcfg:1 t=1 a=pcfg:2 m=video a=mid:video a=pcfg:1 t=1 a=pcfg:2 t=2 In the example above, the potential configurations that offer transport protocol capability of RTP/SAVPF has the same configuration number "1" in both the audio and video media descriptions. 14.2.1.2. Example: Attribute Capability Multiplexing v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=acap:1 a=rtcp-mux a=acap:2 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:EcGZiNWpFJhQXdspcl1ekcmVCNWpVLcfHAwJSoj|2^20|1:32 a=group:BUNDLE audio video m=audio 49172 RTP/AVP 99 a=mid:audio a=pcfg:1 a=1 a=pcfg:2 m=video 560024 RTP/AVP 100 a=mid:video a=pcfg:1 a=1 a=pcfg:2 a=2 In the example above, the potential configuration number "1" is repeated while referring to attribute capability a=rtcp-mux, since the behavior is IDENTICAL for the attribute a=rtcp-mux under multiplexing. Nandakumar Expires June 22, 2017 [Page 67] Internet-Draft SDP Attribute Multiplexing December 2016 14.3. RFC6871 Analysis [RFC6871] extends the capability negotiation framework described in [RFC5939] by defining media capabilities that can be used to indicate and negotiate media types and their associated format parameters. It also allows indication of latent configurations and session capabilities. 14.3.1. Recommendation: Dealing with Payload Type Numbers [RFC6871] defines a new payload type ("pt") parameter to be used with the potential, actual, and latent configuration parameters. The parameter associates RTP payload type numbers with the referenced RTP-based media format capabilities ("a=rmcap") defined in [RFC6871] and is appropriate only when the transport protocol uses RTP. This means that the same payload type number can be assigned as part of potential or actual configurations in different media descriptions in a bundle. There are rules for the usage of identical Payload Type values across multiplexed "m=" lines as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], which must be followed here as well. As described in Section 14.2.1, the use of identical configuration numbers for compatible configurations in different media descriptions that are part of the bundle provides a way to ensure that the answerer can easily pick compatible configurations here as well. 14.3.1.1. Example: Attribute Capability Under Shared Payload Type The attributes (a=rmcap, a=mfcap) follow the above recommendations under multiplexing. Nandakumar Expires June 22, 2017 [Page 68] Internet-Draft SDP Attribute Multiplexing December 2016 v=0 o=- 25678 753849 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 a=creq:med-v0 m=audio 54322 RTP/AVP 96 a=rtpmap:96 AMR-WB/16000/1 a=fmtp:96 mode-change-capability=1; max-red=220; mode-set=0,2,4,7 a=rmcap:1,3 audio AMR-WB/16000/1 a=rmcap:2 audio AMR/8000/1 a=mfcap:1,2 mode-change-capability=1 a=mfcap:3 mode-change-capability=2 a=pcfg:1 m=1 pt=1:96 a=pcfg:2 m=2 pt=2:97 a=pcfg:3 m=3 pt=3:98 m=audio 54322 RTP/AVP 96 a=rtpmap:96 AMR-WB/16000/1 a=fmtp:96 mode-change-capability=1; max-red=220; mode-set=0,2,4,7 a=rmcap:4 audio AMR/8000/1 a=rmcap:5 audio OPUS/48000/2 a=mfcap:5 minptime=40 a=mfcap:4 mode-change-capability=1 a=pcfg:1 m=4 pt=4:97 a=pcfg:4 m=5 pt=5:101 In the example above, the potential configuration number "1" is repeated when referring to media and media format capability used for the Payload Type 96. This implies that both the media capability 2 and 4 along with their media format capabilities MUST refer to the same codec configuration, as per the definition of IDENTICAL-PER-PT. 14.3.2. Recommendation: Dealing with Latent Configurations [RFC6871] adds the notion of a latent configurations, which provides configuration information that may be used to guide a subsequent offer/exchange, e.g. by adding another media stream or use alternative codec combinations not currently offered. Latent configurations have configuration numbers which cannot overlap with the potential configuration numbers [RFC6871]. Supported combinations of potential and latent configurations are indicated by use of the "a=sescap" attribute, however use of this attribute is not recommended with multiplexed media, since it requires the use of unique configuration numbers across the SDP. Taken together, this means there is no well-defined way to indicate supported combinations Nandakumar Expires June 22, 2017 [Page 69] Internet-Draft SDP Attribute Multiplexing December 2016 of latent configurations, or combinations of latent and potential configurations with multiplexed media. It is still allowed to use the latent configuration attribute, however the limitations above will apply. To determine valid combinations, actual negotiation will have to be attempted subsequently instead. 15. IANA Considerations [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] Section 15.1 defines a new subregistry to be added by the IANA for identifying the initial registrations for various multiplexing categories applicable, as proposed in this document. IANA is also requested to add a new column named "Mux Category" to several of the subregistries in the "Session Description Protocol (SDP) Parameters" registry. The tables in Section 15.2 identify name of an entry in the existing subregistry and specify the value to be put in the new "Mux Category" column of the associated IANA registry. 15.1. New 'Multiplexing Categories' subregistry A new sub-registry needs to be defined called the "Multiplexing Categories", with the following registrations created initially: "NORMAL", "CAUTION", "IDENTICAL", "TRANSPORT", "SUM", "INHERIT", "IDENTICAL-PER-PT", "SPECIAL" and "TBD" as defined in this document. Initial value registration for "Multiplexing Categories". +-------------------------+-----------+ | Multiplexing Categories | Reference | +-------------------------+-----------+ | NORMAL | RFCXXXX | | CAUTION | RFCXXXX | | IDENTICAL | RFCXXXX | | TRANSPORT | RFCXXXX | | SUM | RFCXXXX | | INHERIT | RFCXXXX | | IDENTICAL-PER-PT | RFCXXXX | | SPECIAL | RFCXXXX | | TBD | RFCXXXX | +-------------------------+-----------+ Further entries can be registered using Standard Actions policies outlined in [RFC5226], which requires IESG review and approval and standards-track IETF RFC publication. Nandakumar Expires June 22, 2017 [Page 70] Internet-Draft SDP Attribute Multiplexing December 2016 Each registration needs to indicate the multiplexing category value to be added to the "Multiplexing Categories" subregistry as defined in this section. Such a registration MUST also indicate the applicability of the newly defined multiplexing category value to various subregistries defined at the "Session Description Protocol (SDP) Parameters" registry. 15.2. 'Mux Category' column for subregistries Each sub-section identifies a subregistry in the "Session Description Protocol (SDP) Parameters" registry. The tables list the column that identifies the SDP attribute name/Token/Value from the corresponding subregistries and the values to be used for the new "Mux Category" column to be added. For the entries in the existing subregistries, under the "Session Description Protocol (SDP) Parameters" registry, that lack a value for the "Mux Category" in this specification will get a value of "TBD". The registration policy for updates to the 'Mux Category' column values for existing parameters, or when registering new parameters, are beyond the scope of this document. The registration policy for the affected table is defined in [I-D.ietf-mmusic-rfc4566bis]. 15.2.1. Table: SDP bwtype The following values are to be added to the 'SDP bwtype' subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +----------+--------------+ | SDP Name | Mux Category | +----------+--------------+ | CT | NORMAL | | AS | SUM | | RS | SUM | | RR | SUM | | TIAS | SPECIAL | +----------+--------------+ 15.2.2. Table: att-field (session level) The following values are to be added to the "att-field (session level)" subregistry in the "Session Description Protocol (SDP) Nandakumar Expires June 22, 2017 [Page 71] Internet-Draft SDP Attribute Multiplexing December 2016 Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------------------+--------------+ | SDP Name | Mux Category | +---------------------+--------------+ | cat | NORMAL | | keywds | NORMAL | | type | NORMAL | | type:broadcast | NORMAL | | type:H332 | NORMAL | | type:meeting | NORMAL | | type:moderated | NORMAL | | type:test | NORMAL | | charset | NORMAL | | charset:iso8895-1 | NORMAL | | tool | NORMAL | | ipbcp | SPECIAL | | group | NORMAL | | ice-lite | NORMAL | | ice-options | NORMAL | | bcastversion | NORMAL | | 3GPP-Integrity-Key | CAUTION | | 3GPP-SDP-Auth | CAUTION | | alt-group | CAUTION | | PSCid | NORMAL | | bc_service | NORMAL | | bc_program | NORMAL | | bc_service_package | NORMAL | | sescap | CAUTION | | rtsp-ice-d-m | TBD | +---------------------+--------------+ 15.2.3. Table: att-field (both session and media level) The following values are to be added to the "att-field (both session and media level)" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. NOTE: The attributes from draft-ietf-rmt-flute-sdp ('flute-tsi', 'flute-ch', 'FEC-declaration', 'FEC-OTI-extension', 'content-desc') were not analyzed for their multiplexing behavior due to the expired status of the draft. For purposes of this specification, the multiplexing category of 'TBD' is assigned. +-------------------------+-------------------+ | SDP Name | Mux Category | Nandakumar Expires June 22, 2017 [Page 72] Internet-Draft SDP Attribute Multiplexing December 2016 +-------------------------+-------------------+ | recvonly | NORMAL | | sendrecv | NORMAL | | sendonly | NORMAL | | sdplang | NORMAL | | lang | NORMAL | | h248item | SPECIAL | | sqn | NORMAL | | cdsc | NORMAL | | cpar | INHERIT | | cparmin | SPECIAL | | cparmax | SPECIAL | | rtcp-xr | NORMAL | | maxprate | SPECIAL | | setup | TRANSPORT | | connection | TRANSPORT | | key-mgmt | IDENTICAL | | source-filter | IDENTICAL | | inactive | NORMAL | | fingerprint | TRANSPORT | | flute-tsi | TBD | | flute-ch | TBD | | FEC-declaration | TBD | | FEC-OTI-extension | TBD | | content-desc | TBD | | ice-pwd | TRANSPORT | | ice-ufrag | TRANSPORT | | stkmstream | NORMAL | | extmap | SPECIAL | | qos-mech-send | TRANSPORT | | qos-mech-recv | TRANSPORT | | csup | NORMAL | | creq | NORMAL | | acap | INHERIT | | tcap | INHERIT | | 3GPP-QoE-Metrics | CAUTION | | 3GPP-Asset-Information | CAUTION | | mbms-mode | CAUTION | | mbms-repair | CAUTION | | ike-setup | IDENTICAL | | psk-fingerprint | IDENTICAL | | multicast-rtcp | IDENTICAL | | rmcap | IDENTICAL-PER-PT | | omcap | NORMAL | | mfcap | IDENTICAL-PER-PT | | mscap | INHERIT | | 3gpp.iut.replication | TBD | | bcap | INHERIT | Nandakumar Expires June 22, 2017 [Page 73] Internet-Draft SDP Attribute Multiplexing December 2016 | ccap | IDENTICAL | | icap | NORMAL | | 3gpp_sync_info | NORMAL | | 3gpp_MaxRecvSDUSize | NORMAL | | etag | CAUTION | | duplication-delay | NORMAL | | range | CAUTION | | control | CAUTION | | mtag | CAUTION | | ts-refclk | NORMAL | | mediaclk | NORMAL | | calgextmap | NORMAL | +-------------------------+-------------------+ 15.2.4. Table: att-field (media level only) The following values are to be added to the "att-field (media level only)" registry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------------------------+-------------------+ | SDP Name | Mux Category | +---------------------------+-------------------+ | ptime | IDENTICAL-PER-PT | | orient | NORMAL | | orient:portrait | NORMAL | | orient:landscape | NORMAL | | orient:seascape | NORMAL | | framerate | IDENTICAL-PER-PT | | quality | NORMAL | | rtpmap | IDENTICAL-PER-PT | | fmtp | IDENTICAL-PER-PT | | rtpred1 | CAUTION | | rtpred2 | CAUTION | | T38FaxVersion | TBD | | T38MaxBitRate | TBD | | T38FaxFillBitRemoval | TBD | | T38FaxTranscodingMMR | TBD | | T38FaxTranscodingJBIG | TBD | | T38FaxRateManagement | TBD | | T38FaxMaxBuffer | TBD | | T38FaxMaxDatagram | TBD | | T38FaxUdpEC | TBD | | maxptime | IDENTICAL-PER-PT | | des | CAUTION | | curr | CAUTION | | conf | CAUTION | Nandakumar Expires June 22, 2017 [Page 74] Internet-Draft SDP Attribute Multiplexing December 2016 | mid | NORMAL | | rtcp | TRANSPORT | | rtcp-fb | IDENTICAL-PER-PT | | label | NORMAL | | T38VendorInfo | TBD | | crypto | TRANSPORT | | eecid | CAUTION | | aalType | CAUTION | | capability | CAUTION | | qosClass | CAUTION | | bcob | CAUTION | | stc | CAUTION | | upcc | CAUTION | | atmQOSparms | CAUTION | | atmTrfcDesc | CAUTION | | abrParms | CAUTION | | abrSetup | CAUTION | | bearerType | CAUTION | | lij | CAUTION | | anycast | CAUTION | | cache | CAUTION | | bearerSigIE | CAUTION | | aalApp | CAUTION | | cbrRate | CAUTION | | sbc | CAUTION | | clkrec | CAUTION | | fec | CAUTION | | prtfl | CAUTION | | structure | CAUTION | | cpsSDUsize | CAUTION | | all2CPS | CAUTION | | all2CPSSDUrate | CAUTION | | aal2sscs3661unassured | CAUTION | | aal2sscs3661assured | CAUTION | | aal2sscs3662 | CAUTION | | aal5sscop | CAUTION | | atmmap | CAUTION | | silenceSupp | CAUTION | | ecan | CAUTION | | gc | CAUTION | | profileDesc | CAUTION | | vsel | CAUTION | | dsel | CAUTION | | fsel | CAUTION | | onewaySel | CAUTION | | codecconfig | CAUTION | | isup_usi | CAUTION | | uiLayer1_Prot | CAUTION | Nandakumar Expires June 22, 2017 [Page 75] Internet-Draft SDP Attribute Multiplexing December 2016 | chain | CAUTION | | floorctrl | TBD | | confid | NORMAL | | userid | NORMAL | | floorid | NORMAL | | FEC | NORMAL | | accept-types | TBD | | accept-wrapped-types | TBD | | max-size | TBD | | path | TBD | | dccp-service-code | CAUTION | | rtcp-mux | IDENTICAL | | candidate | TRANSPORT | | ice-mismatch | NORMAL | | remote-candidates | TRANSPORT | | SRTPAuthentication | TBD | | SRTPROCTxRate | TBD | | rtcp-rsize | IDENTICAL | | file-selector | TBD | | file-transfer-id | TBD | | file-disposition | TBD | | file-date | TBD | | file-icon | TBD | | file-range | TBD | | depend | IDENTICAL-PER-PT | | ssrc | NORMAL | | ssrc-group | NORMAL | | rtcp-unicast | IDENTICAL | | pcfg | SPECIAL | | acfg | SPECIAL | | zrtp-hash | TRANSPORT | | X-predecbufsize | CAUTION | | X-initpredecbufperiod | CAUTION | | X-initpostdecbufperiod | CAUTION | | X-decbyterate | CAUTION | | 3gpp-videopostdecbufsize | CAUTION | | framesize | CAUTION | | 3GPP-SRTP-Config | CAUTION | | alt | CAUTION | | alt-default-id | CAUTION | | 3GPP-Adaption-Support | CAUTION | | mbms-flowid | CAUTION | | fec-source-flow | SPECIAL | | fec-repair-flow | SPECIAL | | repair-window | SPECIAL | | rams-updates | CAUTION | | imageattr | IDENTICAL-PER-PT | | cfw-id | NORMAL | Nandakumar Expires June 22, 2017 [Page 76] Internet-Draft SDP Attribute Multiplexing December 2016 | portmapping-req | CAUTION | | g.3gpp.cat | NORMAL | | g.3gpp.crs | NORMAL | | ecn-capable-rtp | IDENTICAL | | visited-realm | TRANSPORT | | secondary-realm | TRANSPORT | | omr-s-cksum | NORMAL | | omr-m-cksum | NORMAL | | omr-codecs | NORMAL | | omr-m-att | NORMAL | | omr-s-att | NORMAL | | omr-m-bw | NORMAL | | omr-s-bw | NORMAL | | msrp-cema | TBD | | dccp-port | CAUTION | | resource | NORMAL | | channel | NORMAL | | cmid | NORMAL | | content | NORMAL | | lcfg | SPECIAL | | loopback | NORMAL | | loopback-source | NORMAL | | loopback-mirror | NORMAL | | chatroom | TBD | | altc | TRANSPORT | | T38FaxMaxIFP | TBD | | T38FaxUdpECDepth | TBD | | T38FaxUdpFECMaxSpan | TBD | | T38ModemType | TBD | | cs-correlation | TBD | | rtcp-idms | NORMAL | +---------------------------+-------------------+ 15.2.5. Table: att-field (source level) The following values are to be added to the "att-field (source level)" registry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. Nandakumar Expires June 22, 2017 [Page 77] Internet-Draft SDP Attribute Multiplexing December 2016 +----------------+-------------------+ | SDP Name | Mux Category | +----------------+-------------------+ | cname | NORMAL | | previous-ssrc | NORMAL | | fmtp | IDENTICAL-PER-PT | | ts-refclk | NORMAL | | mediaclk | NORMAL | +----------------+-------------------+ 15.2.6. Table: content SDP Parameters The following values are to be added to the "content SDP Parameters" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +----------+--------------+ | SDP Name | Mux Category | +----------+--------------+ | slides | NORMAL | | speaker | NORMAL | | sl | NORMAL | | main | NORMAL | | alt | NORMAL | +----------+--------------+ 15.2.7. Table: Semantics for the 'group' SDP Attribute The following values are to be added to the "Semantics for the "group" SDP Attribute" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------+--------------+ | Token | Mux Category | +---------+--------------+ | LS | NORMAL | | FID | NORMAL | | SRF | NORMAL | | ANAT | CAUTION | | FEC | NORMAL | | FEC-FR | NORMAL | | CS | NORMAL | | DDP | NORMAL | | DUP | NORMAL | +---------+--------------+ Nandakumar Expires June 22, 2017 [Page 78] Internet-Draft SDP Attribute Multiplexing December 2016 15.2.8. Table: 'rtcp-fb' Attribute Values The following values are to be added to the " 'rtcp-fb' Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +------------+-------------------+ | Value Name | Mux Category | +------------+-------------------+ | ack | IDENTICAL-PER-PT | | app | SPECIAL | | ccm | IDENTICAL-PER-PT | | nack | IDENTICAL-PER-PT | | trr-int | IDENTICAL-PER-PT | +------------+-------------------+ 15.2.9. Table: 'ack' and 'nack' Attribute Values The following values are to be added to the " 'ack' and 'nack' Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +------------+-------------------+ | Value Name | Mux Category | +------------+-------------------+ | sli | IDENTICAL-PER-PT | | pli | IDENTICAL-PER-PT | | rpsi | IDENTICAL-PER-PT | | app | SPECIAL | | rai | IDENTICAL-PER-PT | | tllei | IDENTICAL-PER-PT | | pslei | IDENTICAL-PER-PT | | ecn | IDENTICAL | +------------+-------------------+ 15.2.10. Table: 'depend' SDP Attribute Values The following values are to be added to the " 'depend' SDP Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. Nandakumar Expires June 22, 2017 [Page 79] Internet-Draft SDP Attribute Multiplexing December 2016 +-------+-------------------+ | Token | Mux Category | +-------+-------------------+ | lay | IDENTICAL-PER-PT | | mdc | IDENTICAL-PER-PT | +-------+-------------------+ 15.2.11. Table: 'cs-correlation' Attribute Values The following values are to be added to the " "cs-correlation" Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +-----------+--------------+ | Value | Mux Category | +-----------+--------------+ | callerid | TBD | | uuie | TBD | | dtmf | TBD | | external | TBD | +-----------+--------------+ 15.2.12. Table: Semantics for the 'ssrc-group' SDP Attribute The following values are to be added to the Semantics for the "Semantics for the "ssrc-group" SDP Attribute" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------+--------------+ | Token | Mux Category | +---------+--------------+ | FID | NORMAL | | FEC | NORMAL | | FEC-FR | NORMAL | | DUP | NORMAL | +---------+--------------+ 15.2.13. Table: SDP/RTSP key management protocol identifiers The following values are to be added to the "SDP/RTSP key management protocol identifiers" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. Nandakumar Expires June 22, 2017 [Page 80] Internet-Draft SDP Attribute Multiplexing December 2016 +------------+--------------+ | Value Name | Mux Category | +------------+--------------+ | mikey | IDENTICAL | +------------+--------------+ 15.2.14. Table: Codec Control Messages The following values are to be added to the "Codec Control Messages" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +------------+-------------------+ | Value Name | Mux Category | +------------+-------------------+ | fir | IDENTICAL-PER-PT | | tmmbr | IDENTICAL-PER-PT | | tstr | IDENTICAL-PER-PT | | vbcm | IDENTICAL-PER-PT | +------------+-------------------+ 15.2.15. Table: QoS Mechanism Tokens The following values are to be added to the "QoS Mechanism Tokens" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------------+--------------+ | QoS Mechanism | Mux Category | +---------------+--------------+ | rsvp | TRANSPORT | | nsis | TRANSPORT | +---------------+--------------+ 15.2.16. Table: SDP Capability Negotiation Option Tags The following values are to be added to the "SDP Capability Negotiation Option Tags" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. Nandakumar Expires June 22, 2017 [Page 81] Internet-Draft SDP Attribute Multiplexing December 2016 +------------+--------------+ | Option Tag | Mux Category | +------------+--------------+ | cap-v0 | NORMAL | | med-v0 | NORMAL | | bcap-v0 | NORMAL | | ccap-v0 | NORMAL | | icap-v0 | NORMAL | +------------+--------------+ 15.2.17. Table: Timestamp Reference Clock Source Parameters The following values are to be added to the "Timestamp Reference Clock Source Parameters" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +----------+--------------+ | Name | Mux Category | +----------+--------------+ | ntp | NORMAL | | ptp | NORMAL | | gps | NORMAL | | gal | NORMAL | | glonass | NORMAL | | local | NORMAL | | private | NORMAL | +----------+--------------+ 15.2.18. Table: Media Clock Source Parameters The following values are to be added to the "Media Clock Source Parameters" subegistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +-----------+--------------+ | Name | Mux Category | +-----------+--------------+ | sender | NORMAL | | direct | NORMAL | | IEEE1722 | NORMAL | +-----------+--------------+ Nandakumar Expires June 22, 2017 [Page 82] Internet-Draft SDP Attribute Multiplexing December 2016 16. Security Considerations The primary security for RTP including the way it is used here is described in [RFC3550] and [RFC3711]. When multiplexing SDP attributes with the category "CAUTION", the implementations should be aware of possible issues as described in this specification. 17. Acknowledgments I would like to thank Cullen Jennings, Flemming Andreasen for suggesting the categories, contributing text and reviewing the draft. I would also link to thank Magnus Westerlund, Christer Holmberg, Jonathan Lennox, Bo Burman, Ari Keranen, and Dan Wing on suggesting structural changes helping improve the document readability. I would like also to thank following experts on their inputs and reviews as listed - Flemming Andreasen(5.24,5.32,5.33,14), Rohan Mahy(5.57), Eric Burger(5.26),Christian Huitema(5.14), Christer Holmberg(5.21,5.26,5.51,5.52), Richard Ejzak (5.44,5.53,5.54), Colin Perkins(5.7,5.8,5.9,5.58), Magnus Westerlund(5.2,5.3,5.9,5.27,5.47,6.1,6.2,6.3,8.3,7), Roni Evens(5.12,5.27,8.4), Subha Dhesikan(5.6,10), Dan Wing(5.7,5.12,5.35,5.39,5.45), Cullen Jennings (5.40), Ali C Begen(5.1,5.20,5.22,5.25,5.38,7.3,8.2,8.4,8.6,9.2,13.1), Bo Burman (7.2,7.6), Charles Eckel(5.15,5.27,5.28,9.1,8.5), Paul Kyzivat(5.24), Ian Johansson(5.15), Saravanan Shanmugham(5.11), Paul E Jones(5.30), Rajesh Kumar(5.48), Jonathan Lennox(5.36,5,15,9.1,11.1), Mo Zanaty(5.4,5.5,5.23,8.1,8.3,8.5,12.1), Christian Huitema (5.14), Qin Wu (5.47 PM-Dir review), Hans Stokking(5.43,5.16), Christian Groves (5.48,5.55), Thomas Stach. I would like to thank Chris Lonvick for the SECDIR review, Dan Romascanu for th Gen-ART review and Sabrina Tanamal for the IANA review. Thanks to Ben Campbell for AD review suggestions. Thanks to Spencer Dawkins, Stephen Farrel, Alissa Cooper, Mirja Kuehlewind and the entire IESG experts for their reviews. 18. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes draft-ietf-mmusic-sdp-mux-attributes-15 o Updated Mux category for floorctrl to TBD Nandakumar Expires June 22, 2017 [Page 83] Internet-Draft SDP Attribute Multiplexing December 2016 Changes draft-ietf-mmusic-sdp-mux-attributes-14 o Incorporated Comments from IESG review : * Updated security considerations section to fix the incositencies (Spencer's review) * Updated section 5.36 to align the text with 5.39 (Stephen's review) * Updated IANA registration section to make RFC4566bis a informative dependency (IETF 98 followup) * Updated Section 5 to expand 'B' level SDP attributes (Dan's review) Changes from draft-ietf-mmusic-sdp-mux-attributes-10 - draft-ietf- mmusic-sdp-mux-attributes-13 o Incorporated Comments from WGLC review and AD Evaluation Changes from draft-ietf-mmusic-sdp-mux-attributes-10 o Incorporated Comments from Bo Burman for publication request Changes from draft-ietf-mmusic-sdp-mux-attributes-08 to draft-ietf- mmusic-sdp-mux-attributes-10 o Minor nits and version update to advert expiration Changes from draft-ietf-mmusic-sdp-mux-attributes-06 to draft-ietf- mmusic-sdp-mux-attributes-08 o Assigned TBD category to all the attributes for whom there exists no specification on multiplexing behavior over the underlying transport protocol today. o Incorporated comments from Flemming and Ari (post last call) Changes from draft-ietf-mmusic-sdp-mux-attributes-06 o Incorporated last call review comments from Thomas Stach and Ari Keranen. o Fixed more nits to prep for the LastCall. Changes from draft-ietf-mmusic-sdp-mux-attributes-05 Nandakumar Expires June 22, 2017 [Page 84] Internet-Draft SDP Attribute Multiplexing December 2016 o Incorporated review comments from Christian Grooves and Ari Keranen. o Fixed more nits to prep for the LastCall. Changes from draft-ietf-mmusic-sdp-mux-attributes-04 o Fixed minor nits overall. o Updated Acknowledgement Sections o Last Call Version. Changes from draft-ietf-mmusic-sdp-mux-attributes-03 o More re-work on the IANA section. o Clean ups preparing for the last call. Changes from draft-ietf-mmusic-sdp-mux-attributes-02 o Incorporated suggestions from Flemming on Capability Negotiation. o Closed open issues from IETF90 o Added IANA section to list the categories for all the SDP attributes anlayzed o Lots of cleanup o Reformatted Refernces section to use short-form notation Changes from draft-ietf-mmusic-sdp-mux-attributes-01 o Updated section 15 to provide detailed recommendation on dealing with encapsulating attributes. Also updated sections 5.20, 5.28, 5.29 to refer to Section 15. o Added new categories IDENTICAL-PER-PT and INHERIT o Updated Sections 16 to add the new categories. o Updated Sections 5.1, 5.14, 5.15, 5.38, 8.5 to reflect the category IDENTICAL-PER-PT. o Reformatted section 4 to add individual categories to their own sections. Nandakumar Expires June 22, 2017 [Page 85] Internet-Draft SDP Attribute Multiplexing December 2016 Changes from draft-ietf-mmusic-sdp-mux-attributes-00 o Added Section 15 to provide recommendations on multiplexing SDP encapsulating attributes. Also updated sections 5.20, 5.28, 5.29 to refer to Section 15. o Updated Section 5.38 to incorporate PM-dir review inputs from Qin Wu o Updated Sections 5.2,5.14,8.5 to refer to BUNDLE draft for more clarity. o Fixed few nits regarding sentence clarity and fill-in the NOTES section where information was lacking. Changes from draft-nandakumar-mmusic-mux-attributes-05 o Renamed the document to be a WG document. o Added Section 14. o Updated Open Issues based on IETF88 discussions. Changes from draft-nandakumar-mmusic-mux-attributes-04 o Added few OPEN ISSUES that needs to be discussed. o Updated sections 5.10,5.23,5,24,5,25,7.2,9.1,5.12,5.27,8.4, 5.44,5.11,5.4,5.19,10.1,10.5,5.21,10.4,15.1 o Updated Table Column name Current to Level and improved TRANSPORT category explanation on suggestions form Dan Wing. o Grouped all the rtcp-fb attribute analysis under a single section as suggested by Magnus/ Changes from draft-nandakumar-mmusic-mux-attributes-03 o Maintenance change to clean up grammatical nits and wordings. Changes from draft-nandakumar-mmusic-mux-attributes-02 o Updated Sections 5.3,5.5,5.6,5.7,5.9,5.8,5.11,5.13,5.22,5.34, 5.37,5.40,5.41,5.42,5.43,5.44,5.45,6.1,6.2,6.3,8,3,12.1 based on the inputs from the respective RFC Authors. Changes from draft-nandakumar-mmusic-mux-attributes-01 Nandakumar Expires June 22, 2017 [Page 86] Internet-Draft SDP Attribute Multiplexing December 2016 o Replaced Category BAD with NOT-RECOMMENDED. o Added Category TBD. o Updated IANA Consideration Section. Changes from draft-nandakumar-mmusic-mux-attributes-00 o Added new section for dealing with FEC payload types. 19. References 19.1. Normative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-24 (work in progress), January 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . 19.2. Informative References [H.248.15] "Gateway control protocol: SDP H.248 package attribute", . [I-D.ietf-mmusic-rfc4566bis] Handley, M., Jacobson, V., Perkins, C., and A. Begen, "SDP: Session Description Protocol", draft-ietf-mmusic- rfc4566bis-17 (work in progress), June 2016. [IANA] "Session Description Protocol (SDP) Parameters", . Nandakumar Expires June 22, 2017 [Page 87] Internet-Draft SDP Attribute Multiplexing December 2016 [Q.1970] "Q.1970 : BICC IP bearer control protocol", . [R3GPPTS183.063] "TISPAN - IMS based ITPV Stage 3 specification.", . [R3GPPTS24.182] "IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT); Protocol specification", . [R3GPPTS24.183] "IP Multimedia Subsystem (IMS) Customized Ringing Signal (CRS); Protocol specification", . [R3GPPTS24.229] "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);", . [R3GPPTS26.114] "IP multimedia Subsystem : Media Handling and interaction", . [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/ RFC2326, April 1998, . [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, DOI 10.17487/RFC3108, May 2001, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, DOI 10.17487/RFC3312, October 2002, . Nandakumar Expires June 22, 2017 [Page 88] Internet-Draft SDP Attribute Multiplexing December 2016 [RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, DOI 10.17487/RFC3407, October 2002, . [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, DOI 10.17487/ RFC3524, April 2003, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, . [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, DOI 10.17487/RFC4091, June 2005, . Nandakumar Expires June 22, 2017 [Page 89] Internet-Draft SDP Attribute Multiplexing December 2016 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July 2006, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, DOI 10.17487/RFC4570, July 2006, . [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, DOI 10.17487/ RFC4572, July 2006, . [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/ RFC4574, August 2006, . [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, DOI 10.17487/RFC4583, November 2006, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, DOI 10.17487/ RFC4796, February 2007, . Nandakumar Expires June 22, 2017 [Page 90] Internet-Draft SDP Attribute Multiplexing December 2016 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5159] Dondeti, L., Ed. and A. Jerichow, "Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection", RFC 5159, DOI 10.17487/RFC5159, March 2008, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", RFC 5432, DOI 10.17487/ RFC5432, March 2009, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, DOI 10.17487/RFC5547, May 2009, . Nandakumar Expires June 22, 2017 [Page 91] Internet-Draft SDP Attribute Multiplexing December 2016 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, . [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/ RFC5760, February 2010, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/ RFC5761, April 2010, . [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 2010, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, September 2010, . [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/ RFC5956, September 2010, . Nandakumar Expires June 22, 2017 [Page 92] Internet-Draft SDP Attribute Multiplexing December 2016 [RFC6064] Westerlund, M. and P. Frojdh, "SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service", RFC 6064, DOI 10.17487/RFC6064, January 2011, . [RFC6128] Begen, A., "RTP Control Protocol (RTCP) Port for Source- Specific Multicast (SSM) Sessions", RFC 6128, DOI 10.17487/RFC6128, February 2011, . [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, . [RFC6193] Saito, M., Wing, D., and M. Toyama, "Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)", RFC 6193, DOI 10.17487/ RFC6193, April 2011, . [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, DOI 10.17487/ RFC6230, May 2011, . [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, . [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, June 2011, . [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011, . [RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, DOI 10.17487/RFC6364, October 2011, . Nandakumar Expires June 22, 2017 [Page 93] Internet-Draft SDP Attribute Multiplexing December 2016 [RFC6642] Wu, Q., Ed., Xia, F., and R. Even, "RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report", RFC 6642, DOI 10.17487/RFC6642, June 2012, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, DOI 10.17487/ RFC6714, August 2012, . [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, . [RFC6787] Burnett, D. and S. Shanmugham, "Media Resource Control Protocol Version 2 (MRCPv2)", RFC 6787, DOI 10.17487/ RFC6787, November 2012, . [RFC6849] Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and N. Stratton, "An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback", RFC 6849, DOI 10.17487/RFC6849, February 2013, . [RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session Description Protocol (SDP) Media Capabilities Negotiation", RFC 6871, DOI 10.17487/RFC6871, February 2013, . [RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. Veikkolainen, "The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute", RFC 6947, DOI 10.17487/RFC6947, May 2013, . [RFC7006] Garcia-Martin, M., Veikkolainen, S., and R. Gilman, "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)", RFC 7006, DOI 10.17487/ RFC7006, September 2013, . Nandakumar Expires June 22, 2017 [Page 94] Internet-Draft SDP Attribute Multiplexing December 2016 [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, DOI 10.17487/RFC7104, January 2014, . [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)", RFC 7195, DOI 10.17487/RFC7195, May 2014, . [RFC7197] Begen, A., Cai, Y., and H. Ou, "Duplication Delay Attribute in the Session Description Protocol", RFC 7197, DOI 10.17487/RFC7197, April 2014, . [RFC7266] Clark, A., Wu, Q., Schott, R., and G. Zorn, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting", RFC 7266, DOI 10.17487/RFC7266, June 2014, . [RFC7272] van Brandenburg, R., Stokking, H., van Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter- Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, DOI 10.17487/RFC7272, June 2014, . [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, DOI 10.17487/RFC7273, June 2014, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [T.38] "Procedures for real-time Group 3 facsimile communication over IP networks", . Author's Address Nandakumar Expires June 22, 2017 [Page 95] Internet-Draft SDP Attribute Multiplexing December 2016 Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: snandaku@cisco.com Nandakumar Expires June 22, 2017 [Page 96] ./draft-ietf-httpauth-extension-09.txt0000664000764400076440000017737712767202023017265 0ustar iustyiusty HTTPAUTH Working Group Y. Oiwa Internet-Draft H. Watanabe Intended status: Experimental H. Takagi Expires: March 21, 2017 ITRI, AIST K. Maeda T. Hayashi Lepidum Y. Ioku Individual September 17, 2016 HTTP Authentication Extensions for Interactive Clients draft-ietf-httpauth-extension-09 Abstract This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means like HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user-agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2017. Copyright Notice Oiwa, et al. Expires March 21, 2017 [Page 1] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terms for describing authentication protocol flow . . . . 4 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8 3.1. Note on Optional-WWW-Authenticate and use of WWW-Authenticate header with non-401 status . . . . . . . 10 4. Authentication-Control header . . . . . . . . . . . . . . . . 11 4.1. Non-ASCII extended header parameters . . . . . . . . . . . 12 4.2. Auth-style parameter . . . . . . . . . . . . . . . . . . . 13 4.3. Location-when-unauthenticated parameter . . . . . . . . . 14 4.4. No-auth parameter . . . . . . . . . . . . . . . . . . . . 15 4.5. Location-when-logout parameter . . . . . . . . . . . . . . 15 4.6. Logout-timeout parameter . . . . . . . . . . . . . . . . . 16 4.7. Username parameter . . . . . . . . . . . . . . . . . . . . 17 5. Usage examples . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 18 5.1.1. Case 1: a simple application . . . . . . . . . . . . . 19 5.1.2. Case 2: specific action required on log-out . . . . . 19 5.1.3. Case 3: specific page displayed before log-in . . . . 19 5.2. Example 2: authenticated user-only sites . . . . . . . . . 20 5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 20 5.4. Parallel deployment with Form/Cookie authentication . . . 21 6. Methods to extend this protocol . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8.1. Security implication of the username parameter . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. (Informative) Applicability of features for each Oiwa, et al. Expires March 21, 2017 [Page 2] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 messages . . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 26 B.1. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 26 B.2. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 26 B.3. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 26 B.4. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 26 B.5. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 26 B.6. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 27 B.7. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 27 B.8. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 27 B.9. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 27 B.10. Changes in Httpauth revision 00 and HttpBis revision 00 . 27 B.11. Changes in revision 02 . . . . . . . . . . . . . . . . . . 27 B.12. Changes in revision 01 . . . . . . . . . . . . . . . . . . 27 B.13. Changes in revision 00 . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Oiwa, et al. Expires March 21, 2017 [Page 3] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 1. Introduction This document defines several extensions to the current HTTP authentication framework, to provide functionality comparable with current widely-used form-based Web authentication. A majority of the recent websites on the Internet use custom application-layer authentication implementations using Web forms. The reasons for these may vary, but many people believe that the current HTTP Basic and Digest authentication methods do not have enough functionality (including good user interfaces) to support most realistic Web-based applications. However, such use of form-based Web authentication has several weakness against attacks like phishing, because all behavior of the authentication is controlled from the server-side application. This makes it really hard to implement any cryptographically strong authentication mechanisms into Web systems. To overcome this problem, we need to "modernize" the HTTP authentication framework so that better client-controlled secure methods can be used with Web applications. The extensions proposed in this document include: o optional authentication on HTTP (Section 3), o log out from both server and client side (Section 4), and o finer control for redirection depending on authentication status (Section 4). 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document distinguishes the terms "client" and "user" in the following way: A "client" is an entity understanding and talking HTTP and the specified authentication protocol, usually computer software; a "user" is a (usually natural) person who wants to access data resources using "a client". 2. Definitions 2.1. Terms for describing authentication protocol flow HTTP Authentication defined in [RFC7235] can involve several pairs of HTTP requests/responses. Throughout this document, the following terms are used to categorize those messages: for requests, Oiwa, et al. Expires March 21, 2017 [Page 4] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 1) A non-authenticating request is a request not attempting any authentication: a request without any Authorization header field. 2) An authenticating request is the opposite: a request with an Authorization header field. For responses, 1) A non-authenticated response is a response which does not involve any HTTP authentication. It does not contain any WWW-Authenticate ([RFC7235]) or Authentication-Info header field ([RFC7615]). Servers send this response when the requested resource is not protected by an HTTP authentication mechanism. In context of this specification, non-authentication-related negative responses (e.g. 403 and 404) are also considered non-authenticated responses. (See note on successfully-authenticated responses below for some ambiguous cases.) 2) An authentication-initializing response is a response which requires or allows clients to start authentication attempts. Servers send this response when the requested resource is protected by HTTP authentication mechanism, and the request meets one of the following cases: * The request is a non-authenticating request, or * The request contained an authentication trial directed to a protection space (realm) other than the one the server expected. The server will specify the protection space for authentication in this response. Upon receiving this response, the client's behavior is further divided to two possible cases. * If the client has no prior knowledge on authentication credentials (e.g. a user-name and a password) related to the requested protection space, the protocol flow terminates and the client will ask the user to provide authentication credentials, * On the other hand, if client already has enough authentication credentials to the requested protection space, the client will automatically send an authenticating request. Such cases often occur when the client did not know beforehand that the current Oiwa, et al. Expires March 21, 2017 [Page 5] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 request-URL requires authentication. 3) A successfully-authenticated response is a response for an authenticating request meaning that the authentication attempt was granted. (Note: if the authentication scheme used does not use an Authentication-Info header field, it can't be distinguished from a non-authenticated response.) 4) An intermediate authenticating response is a response for an authenticating request which requires more reaction by the client software without involving users. Such a response is required when an authentication scheme requires two or more round-trip messages to perform authentication, or when an authentication scheme uses some speculative short-cut method (such as uses of cached shared secrets) and it failed. 5) A negatively-authenticated response is a response for an authenticating request which means that the authentication attempt was declined and can not continue without a different set of authentication credentials. Clients typically erase memory of the active credentials and ask the user for other ones. Usually the format of these responses are as same as the one for authentication-initializing responses. Clients can distinguish negatively-authenticated responses from authentication- initializing responses by comparing the protection spaces contained in the request and in the response. Figure 1 shows a state diagram of generic HTTP authentication with the above message categorization. Note that many authentication schemes use only a subset of the transitions described on the diagram. Labels in the figure show the abbreviated names of response types. Oiwa, et al. Expires March 21, 2017 [Page 6] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 =========== ----------------- NEW REQUEST ( UNAUTHENTICATED ) =========== ----------------- | ^ non-auth. v | response +----------------------+ NO +-------------+ | The requested URI |--------------------------->| send normal | | known to be auth'ed? | ---------------->| request | +----------------------+ / +-------------+ YES | / initializing| v / | +------------------+ NO / | | Can auth-req.(*1)|--------- | | be constructed? | | +------------------+ | YES | initializing | | ---------------------------------------. | | / v v | | ---------------- NO +-----------+ | | ( AUTH-REQUESTED )<------| passwords | | | ---------------- |etc. known?| v | +-----------+ +-----------+ negative ------------- negative |YES | send |---------->( AUTH-FAILED )<---------, | /| auth-req | ------------- | | / +-----------+\ | v | \ \ intermediate +-----------+ | \ -------------------------------->| send | | \ | auth-req | | non-auth. \successful successful +-----------+ | response (*2) \ / | ^ v \ / | | ----------------- \ -------------- / `----' ( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate ----------------- -------------- Figure 1: Generic state diagram for HTTP authentication Note: (*1) For example, "Digest" scheme requires server-provided nonce to construct client-side challenges. (*2) In "Basic" and some others, this cannot be distinguished from a successfully-authenticated response. 2.2. Syntax Notation This specification uses an extended ABNF syntax defined in [RFC7230] and [RFC5234]. The following syntax definitions are quoted from Oiwa, et al. Expires March 21, 2017 [Page 7] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 [RFC7230] and [RFC7235]: auth-scheme, quoted-string, auth-param, SP, BWS, header-field, and challenge. It also uses the convention of using header field names for specifying the syntax of values for the header field. Additionally, this specification uses the following syntax definitions as a refinement for token and the right-hand-side of auth-param in [RFC7235]. bare-token = bare-token-lead-char *bare-token-char bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_" extension-token = "-" bare-token 1*("." bare-token) extensive-token = bare-token / extension-token integer = "0" / (%x31-39 *%x30-39) ; no leading zeros Figure 2: the BNF syntax for common notations Extensive-tokens are used in this protocol where the set of acceptable tokens includes private extensions. Any extensions of this protocol MAY use either bare-tokens allocated by IANA (under the procedure described in Section 7), or extension-tokens with the format "-.", where is a valid (sub-)domain name on the Internet owned by the party who defines the extension. 3. Optional Authentication The Optional-WWW-Authenticate header enables a non-mandatory authentication, which is not possible under the current HTTP authentication mechanism. In several Web applications, users can access the same contents as both a guest user and an authenticated user. In most Web applications, this functionality is implemented using HTTP cookies [RFC6265] and custom form-based authentication. The new authentication method using this message will provide a replacement for these authentication systems. Servers MAY send HTTP non-interim responses containing the Optional-WWW-Authenticate header as a replacement of a 401 response when it is authentication-initializing. The Optional-WWW-Authenticate header MUST NOT be sent on 401 responses (i.e. a usual WWW-Authenticate header MUST be used on 401 responses). Optional-WWW-Authenticate = 1#challenge Oiwa, et al. Expires March 21, 2017 [Page 8] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 Figure 3: BNF syntax for Optional-WWW-Authenticate header Example: HTTP/1.1 200 OK Optional-WWW-Authenticate: Basic realm="xxxx" The challenges contained in the Optional-WWW-Authenticate header are the same as those for a 401 responses corresponding to the same request. For authentication-related matters, an optional authentication request will have the same meaning as a 401 message with a corresponding WWW-Authenticate header (as an authentication- initializing response). (The behavior for other matters MAY be different between the optional authentication and 401 messages. For example, clients MAY choose to cache the 200 messages with Optional-WWW-Authenticate header field but not the 401 messages by default.) A response with an Optional-WWW-Authenticate header SHOULD be returned from the server only when the request is either non- authenticated or authenticating to a wrong (not the server's expected) protection space. If a response is either an intermediate or a negative response to a client's authentication attempt, the server MUST respond with a 401 status response with a WWW-Authenticate header instead. Failure to comply with this rule will render clients unable to distinguish authentication successes and failures. The server is NOT RECOMMENDED to include an Optional-WWW-Authenticate header in a positive response when a client's authentication attempt succeeds. Whenever an authentication scheme supports servers sending some parameter which gives a hint of the URL space for the corresponding protection space for the same realm (e.g. "path" or "domain"), servers requesting non-mandatory authentication SHOULD send such parameter with the response. Clients supporting non-mandatory authentication MUST recognize the parameter, and MUST send a request with an appropriate authentication credential in an Authorization header for any URI inside the specified paths. Implementations are not required to support this header for all of their supported authentication schemes (i.e., they may choose to implement it only for a subset of their supported schemes). New authentication schemes can require support of the optional authentication as a prerequisite, though. Oiwa, et al. Expires March 21, 2017 [Page 9] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 3.1. Note on Optional-WWW-Authenticate and use of WWW-Authenticate header with non-401 status In the current specification of HTTP/1.1, it is clarified that the WWW-Authenticate header can be used with messages with status codes other than 401 (Authentication Required). Especially, the use of WWW-Authenticate header with the 200 status messages implies a very similar meaning to the above-defined Optional-WWW-Authenticate header. The design of Optional-WWW-Authenticate header expects that the use of a new header guarantees that clients which are unaware of this extension will ignore the header, and that Web developers can rely on that behavior to implement a secondary fallback method of authentication. Several behavioral requirements written in the above section also assumes this property, and defines a necessary functionality to implement an HTTP optional authentication reliably and consistently. On the other hand, some experiments and discussions on the IETF mailing list revealed that most of (but not necessarily all of) the existing HTTP clients, at the time of writing, just ignore the WWW- Authenticate headers in non-401 messages, giving the similar behavior with the Optional-WWW-Authenticate. However, every corner case of behavior was not fully tested, nor well-defined in the existing specifications. Considering these situations, the authors of this document chose to use a new header for a new feature "experiment". This is to avoid defining every corner-case behavior for the existing standard WWW- Authentication header in this experimental document, which could be considered by some implementers as an "incompatible changes to existing specification". Experimentally, the authors propose implementers of the standard HTTP/1.1 specification (especially implementers of this extension) to implement undefined (implementation-dependant) detailed handling of WWW-Authenticate header with non-401 status messages as similar as those defined above for the Optional-WWW-Authenticate header. For example, we propose for servers to return 401 status for failed authentication attempts, even when the unauthenticated request to the same resource will result in the 200 status. This can realize how (whether) we can implement non-mandatory authentication using the standard header fields and status codes. If this experiment is successful, the future revision of this experimental document may "bless" and recommend the use of standard WWW-Authenticate header, with some "standard-level" requirements on some corner case behavior. Oiwa, et al. Expires March 21, 2017 [Page 10] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 4. Authentication-Control header Authentication-Control = 1#auth-control-entry auth-control-entry = auth-scheme 1*SP 1#auth-control-param auth-control-param = extensive-token BWS "=" BWS token / extensive-token "*" BWS "=" BWS ext-value ext-value = Figure 4: the BNF syntax for the Authentication-Control header The Authentication-Control header provides a more precise control of the client behavior for Web applications using an HTTP authentication protocol. This header is supposed to be generated in the application layer, as opposed to WWW-Authenticate headers which will usually be generated by the Web servers. Clients MAY freely choose any subset of these parameters to be supported. Also, these are not required to support any of these parameters for all of their supported authentication schemes. However, authentication schemes can require/recommend support for some of these parameters as a prerequisite. The Authentication-Control header contains one or more "authentication control entries" each of which corresponds to a single realm for a specific authentication scheme. If the auth-scheme specified for an entry supports the HTTP "realm" feature, that entry MUST contain the "realm" parameter. If not, the entry MUST NOT contain the "realm" parameter. Among the multiple entries in the header, the relevant entries in the header are those corresponding to an auth-scheme and a realm (if any), for which "the authentication process is being performed, or going to be performed". In more detail, (1) If the response is either an authentication-initializing response or a negatively-authenticated response, there can be multiple challenges in the WWW-Authenticate header (or the Optional-WWW-Authenticate header defined in this extension), each of which corresponds to a different scheme and realm. In this case, the client has a choice on the scheme and realm they will use to authenticate. Only the entry in the Authentication-Control header corresponding to that scheme and realm are relevant. (2) If the response is either an intermediate authenticating response or a successfully-authenticated response, the scheme and realm given in the Authorization header of the HTTP request will determine the currently-ongoing authentication process. Oiwa, et al. Expires March 21, 2017 [Page 11] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 Only the entry corresponding to that scheme and realm are relevant. The server MAY send an Authentication-Control header containing non- relevant entries. The client MUST ignore all non-relevant entries it received. Each entry contains one or more parameters, each of which is a name- value pair. The name of each parameter MUST be an extensive-token. Clients MUST ignore any unknown parameters contained in this header. The entries for the same auth-scheme and the realm MUST NOT contain duplicated parameters for the same name. Clients MAY either take any one of those duplicated entries or ignore all of them. The type of parameter value depends on the parameter name as defined in the following subsections. Regardless of the type, however, the recipients MUST accept both quoted and unquoted representations of values as defined in HTTP. If the parameter is defined to have a string value, implementations MUST send any value outside of the "token" ABNF syntax in either a quoted form or an an ext-value form (see Section 4.1). If the parameter is defined as a token (or similar) or an integer, the value SHOULD follow the corresponding ABNF syntax after possible unquoting of the quoted-string value (as defined in HTTP), and MUST be sent in a plain (not an ext-value) form. (Note: the rest of this document will show all string-value parameters in quoted forms, and others in unquoted forms.) Any parameters contained in this header MAY be ignored by clients. Also, even when a client accepts this header, users are able to circumvent the semantics of this header. Therefore, if this header is used for security purposes, its use MUST be limited to providing some non-fundamental additional security measures valuable for end- users (such as client-side log-out for protecting against console takeover). Server-side applications MUST NOT rely on the use of this header for protecting server-side resources. Note: The header syntax allows servers to specify Authentication- Control for multiple authentication schemes, either as multiple occurrences of this header or as a combined single header (see Section 3.2.2 of [RFC7230] for rationale). The same care as for parsing multiple authentication challenges needs to be taken. 4.1. Non-ASCII extended header parameters Parameters contained in the Authentication-Control header MAY be extended to non-ASCII values using the framework described in [RFC5987]. All servers and clients MUST be capable of receiving and sending values encoded in [RFC5987] syntax. Oiwa, et al. Expires March 21, 2017 [Page 12] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 If a value to be sent contains only ASCII characters, the field MUST be sent using plain RFC 7235 syntax. The syntax as extended by ext- value MUST NOT be used in this case. If a value (except the "realm" header) contains one or more non-ASCII characters, the parameter SHOULD be sent using the ext-value syntax defined in Section 3.2 of [RFC5987]. Such a parameter MUST have a charset value of "UTF-8", and the language value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the used syntax. For example, a parameter "username" with value "Renee of France" SHOULD be sent as < username="Renee of France" >. If the value is "Rene of France", it SHOULD be sent as < username*=UTF-8''Ren%C3%89e%20of%20France > instead. Interoperability note: [RFC7235], Section 2.2, defines the "realm" authentication parameter which cannot be replaced by the "realm*" extend parameter. It means that the use of non-ASCII values for an authentication realm is not the defined behavior in HTTP. Unfortunately, some people currently use a non-ASCII realm parameter in reality, but even its encoding scheme is not well-defined. Given this background, this document does not specify how to handle a non-ASCII "realm" parameter in the extended header fields. If needed, the authors propose to use a non-extended "realm" parameter form, with a wish for maximum interoperability. 4.2. Auth-style parameter Example: Authentication-Control: Digest realm="protected space", auth-style=modal The parameter "auth-style" specifies the server's preference for user interface behavior for user authentication. This parameter can be included in any kind of response, however, it is only meaningful for either authentication-initializing or negatively-authenticated responses. The value of this parameter MUST be one of the bare- tokens "modal" or "non-modal". When the Optional-WWW-Authenticate header is used, the value of this parameter MUST be disregarded and the value "non-modal" is implied. The value "modal" means that the server thinks the content of the response (body and other content-related headers) is valuable only for users refusing the authentication request. The clients are expected to ask the user for a password before processing the content. This behavior is common for most of the current implementations of Basic and Digest authentication schemes. Oiwa, et al. Expires March 21, 2017 [Page 13] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 The value "non-modal" means that the server thinks the content of the response (body and other content-related headers) is valuable for users before processing an authentication request. The clients are expected to first process the content and then provide users the opportunity to perform authentication. The default behavior for clients is implementation-dependent, and it may also depend on authentication schemes. The proposed default behavior is "modal" for all authentication schemes unless otherwise specified. The above two different methods of authentication possibly introduce a observable difference of semantics when the response contains state-changing side effects; for example, it can affect how Cookie headers [RFC6265] in 401 responses are processed. However, the server applications SHOULD NOT depend on existence of such side effects. 4.3. Location-when-unauthenticated parameter Example: Authentication-Control: Mutual realm="auth-space-1", location-when-unauthenticated="http://www.example.com/login.html" The parameter "location-when-unauthenticated" specifies a location where any unauthenticated clients should be redirected to. This header can be used, for example, when there is a central login page for the entire Web application. The value of this parameter is a string that contains an URL location. If a received URL is not absolute, the clients SHOULD consider it a relative URL from the current location. This parameter MAY be used with a 401 response for an authentication- initializing response. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully-authenticated or intermediately-authenticated. When a client receives an authentication-initiating response with this parameter, and if the client has to ask users for authentication credentials, the client will treat the entire response as if it were a 303 "See Other" response with a Location header that contains the value of this parameter (i.e., client will be redirected to the specified location with a GET request). Unlike a normal 303 response, if the client can process authentication without the user's interaction, this parameter MUST be ignored. Oiwa, et al. Expires March 21, 2017 [Page 14] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 4.4. No-auth parameter Example: Authentication-Control: Basic realm="entrance", no-auth=true The parameter "no-auth" is a variant of the location-when-unauthenticated parameter; it specifies that new authentication attempts are not to be performed on this location in order to improve the user experience, without specifying the redirection on the HTTP level. This header can be used, for example, when there is a central login page for the entire Web application, and when an explicit user interaction with the Web content is desired before authentication. The value of this parameter MUST be a token "true". If the value is incorrect, client MAY ignore this parameter. This parameter MAY be used with authentication-initiating responses. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully-authenticated or intermediately-authenticated. When a client receives an authentication-initiating response with this parameter, if the client has to ask users for authentication credentials, the client will ignore the WWW-Authenticate header contained in the response and treat the whole response as a normal negative 4xx-class response instead of giving the user an opportunity to start authentication. If the client can process authentication without the user's interaction, this parameter MUST be ignored. Using this parameter along with location-when-unauthenticated parameter is meaningless. If both were supplied, clients SHOULD ignore the location-when-unauthenticated parameter. This parameter SHOULD NOT be used as a security measure to prevent authentication attempts, as it is easily circumvented by users. This parameter SHOULD be used solely for improving user experience of Web applications. 4.5. Location-when-logout parameter Example: Authentication-Control: Digest realm="protected space", location-when-logout="http://www.example.com/byebye.html" The parameter "location-when-logout" specifies a location where the client is to be redirected when the user explicitly requests a logout. The value of this parameter MUST be a string that contains an URL location. If a given URL is not absolute, the clients MUST Oiwa, et al. Expires March 21, 2017 [Page 15] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 consider it a relative URL from the current location. This parameter MAY be used with successfully-authenticated responses. If this parameter is contained in other kinds of responses, the clients MUST ignore this parameter. When the user tells the client to terminate the current authentication period, if the client currently displays a page supplied by a response with this parameter, the client will automatically change current location to the location specified in this parameter, using a new GET request, as if it has received a 303 response. Any operations related to logging-out (e.g. erasing memories of user name, authentication credential and all related one- time credentials such as nonce or keys) SHOULD occur before processing a page transition. When the user requests the client for the termination of an authentication period, if the client supports this parameter but the server response does not contain this parameter, the client's RECOMMENDED behavior is as follows: if the request corresponding to the current content was GET method, reload the page without the authentication credential. Otherwise, keep the current content as-is and simply forget the authentication status. The client SHOULD NOT replay a non-idempotent request without the user's explicit approval. Web applications are encouraged to send this parameter with an appropriate value for any responses (except those with redirection (3XX) statuses) for non-GET requests. See Section 5 for some examples for possible deployment of this parameter. 4.6. Logout-timeout parameter Example: Authentication-Control: Basic realm="entrance", logout-timeout=300 The parameter "logout-timeout", when contained in a successfully- authenticated response, means that any authentication credentials and state related to the current protection space are to be discarded if a time specified in this header (in seconds) has passed since the time this header was received. The value MUST be an integer. As a special case, the value 0 means that the server is logging the client out immediately from the current authentication space and that the client is now returns to unauthenticated state. This does not, however, mean that the long-term memories for the passwords and passwords-related details (such as password reminders and auto fill- ins) should be removed. If a new timeout value is received for the Oiwa, et al. Expires March 21, 2017 [Page 16] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 same authentication space, it cancels the previous timeout and sets a new timeout. 4.7. Username parameter Example: Authentication-Control: Basic realm="configuration", username="admin" The parameter "username" tells that the only "user name" to be accepted by the server is the value given in this parameter. This parameter is particularly useful, for example, for routers and other network appliances with a Web configuration interface. Many of those use a HTTP Basic authentication with one predefined user name, with many varieties such as "admin", "root", "user" etc. In current situation, users have almost no hint about the valid user name upon the authentication request. Some shows the valid value in a "realm" string, some in the 401-status response page, shown _after_ the user giving up the authentication and cancelled the authentication dialog. If this parameter is given, the client Web browser can auto-fill the user-name field in the authentication dialog before the users attempt to authenticate themselves. This parameter MAY be used with authentication-initiating responses or negatively-authenticated responses requiring another attempt of authentication. The clients MUST ignore this parameter when a response is either successfully-authenticated or intermediately- authenticated. If the authentication scheme to be used has a syntax limitation on the allowed user names (e.g. Basic and Digest do not allow colons in user names), the specified value MUST follow that limitation. Clients SHOULD ignore any values which do not conform to such limitations. Also, if the used authentication scheme requires a specific style of text preparation for the user name (e.g., PRECIS [RFC7564] string preparation or Unicode normalization), the server SHOULD send the values satisfying such requirements (so that clients can use the given user name as is). Clients MAY still send any authentication requests with other user names, possibly in vain. Clients are not required (also not forbidden) to give users opportunities for supplying a user name different from the server-specified one. Servers are also not strictly required to reject user names other than specified, but doing so will usually give bad user experiences and may confuse users and clients. Oiwa, et al. Expires March 21, 2017 [Page 17] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 Although this parameter is useful in a specific class of use cases, using it in a general use cases has many security implications and possible pit-falls. Please consult Section 8.1 before deciding to use this parameter. 5. Usage examples This section shows some examples for applying this extension to typical websites which are using Forms and cookies for managing authentication and authorization. The content of this section is not normative and for illustrative purposes only. In these examples, we assume that there are two kinds of clients (Web browsers). One kind of these implements all features described in the previous sections. We also assume that browsers will have a user interface which allows users to deactivate (log-out from) current authentication sessions. The other kind are the "existing" implementations which do not support any of these features. When not explicitly specified, all settings described below are to be applied with Authentication-Control headers, and these can be sent to clients regardless of the authentication status (these will be silently ignored whenever not effective). 5.1. Example 1: a portal site This subsection provides an example application for a site whose structure is somewhat similar to conventional portal sites. In particular, most web pages are available for guest (unauthenticated) users, and if authentication is performed, the content of these pages is customized for each user. We assume the site has the following kinds of pages currently: o Content pages. o Pages/mechanism for performing authentication: * There is one page which asks a user name and a password using a HTML POST form. * After the authentication attempt, the user will be redirected to either the page which is previously displayed before the authentication, or some specific page. o A de-authentication (log-out) page. Oiwa, et al. Expires March 21, 2017 [Page 18] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 5.1.1. Case 1: a simple application When such a site does not require specific actions upon log-in and log-out, the following simple settings can be used. o Set up an optional authentication to all pages available to guests. Set up an Authentication-Control header with "auth- style=non-modal" setting. o If there are pages only available to authenticated users, set up a mandatory authentication with "auth-style=non-modal" setting. o No specific pages for authentication are needed. It will be performed automatically, directed by the above setting. o A de-authentication page is also not needed. If the site has one, put "logout-timeout=0" there. o For all pages for POST requests, it is advisable to have "location-when-logout=". 5.1.2. Case 2: specific action required on log-out If the site requires specific actions upon log-out, the following settings can be used. o All settings in the Case 1 are applied. o For all pages, set up the Authentication-Control header "location- when-logout=". o In the de-authentication page, no specific set-up is needed. If there are any direct links to the de-authentication page, put "logout-timeout=0". 5.1.3. Case 3: specific page displayed before log-in If the site needs to display a specific page before log-in actions (some announcements, user notices, or even advertisements), the following settings can be applied. o Set up an optional authentication to all pages available to guests. Set up an Authentication-Control header with "no- auth=true". Put a link to a specific log-in page in contents. o If there are pages only available to authenticated users, set up a mandatory authentication with "location-when-unauthenticated=". Oiwa, et al. Expires March 21, 2017 [Page 19] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 o For the specific log-in page, set up a mandatory authentication. o For all pages for POST requests, it is advisable to have "location-when-logout=", too. o De-authentication pages are not needed. If the site has one, put "logout-timeout=0". 5.2. Example 2: authenticated user-only sites If almost all pages in the target site require authentication (e.g., an Internet banking site), or if there are no needs to support both unauthenticated and authenticated users on the same resource, the settings will become simpler. The following are an example for such a site: o Set up a mandatory authentication to all pages available to authenticated users. Set up an Authentication-Control header with "auth-style=non-modal" setting. o Set up a handler for the 401-status which requests users to authenticate. o For all pages for POST requests, it is advisable to have "location-when-logout=", too. o De-authentication pages are not needed. If the site will have one, put "logout-timeout=0" there. 5.3. When to use Cookies In current Web sites using form-based authentication, Cookies [RFC6265] are used for managing both authorization and application sessions. Using the extensions in this document, the former features will be provided by using (extended) HTTP authentication/ authorization mechanisms. In some cases, there will be ambiguity on whether some functions are for authorization management or for session management. The following hints will be helpful for deciding which features to use. o If there is a need to serve multiple sessions for a single user using multiple browsers concurrently, use a Cookie for distinguishing between sessions for the same user. (C.f. if there is a need to distinguish sessions in the same browser, HTML5 Web Storage [W3C.REC-webstorage-20130730] features can be used instead of Cookies.) Oiwa, et al. Expires March 21, 2017 [Page 20] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 o If a web site is currently deploying a session time-out feature, consider who benefits from the feature. In most cases, the main requirement for such a feature is to protect users from having their consoles and browsers hijacked (i.e. benefits are on the users' side). In such cases, the time-out features provided in this extension can be used. On the other hand, the requirement is to protect server's privilege (e.g. when some regulations require to limit the time difference between user's two-factor authentication and financial transaction commitment; the requirement is strictly on the servers' side), that should be managed on the server side using Cookies or other session management mechanisms. 5.4. Parallel deployment with Form/Cookie authentication In some transition periods, sites can need to support both HTTP-layer and form-based authentication. The following example shows one way to achieve that. o If Cookies are used even for HTTP-authenticated users, each session determined by Cookies SHOULD identify which authentication has been used for the session. o First, set up any of the above settings for enabling HTTP-layer authentication. o For unauthenticated users, add the following things to the Web pages, unless the client supports this extension and HTTP-level authentication. * For non-mandatory authenticated pages, put a link to Form-based authenticated pages. * For mandatory authenticated pages, either put a link to Form- based authenticated pages, or put a HTML-level redirection (using element) to such pages. o In Form-based authenticated pages, if users are not authenticated, the page can provide a redirection for HTTP-level authentication by "location-when-unauthenticated" setting. o Users are identified to authorization and content customization by the following logic. * First, check the result of the HTTP-level authentication. If there is a Cookie session tied to a specific user, both should match. Oiwa, et al. Expires March 21, 2017 [Page 21] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 * If the user is not authenticated on the HTTP-level, use the conventional Form-based method to determine the user. * If there is a Cookie tied to HTTP authentication, but there is no corresponding HTTP authentication result, that session will be discarded (because it means that authentication is deactivated by the corresponding user). 6. Methods to extend this protocol If a private extension to this protocol is implemented, it MUST use the extension-param to avoid conflicts with this protocol and any other extensions. (Standardized or being-standardized extensions MAY use either bare-tokens or extension-tokens.) When bare-tokens are used in this protocol, these MUST be allocated by IANA. Any tokens used for non-private, non-experimental parameters are RECOMMENDED to be registered to IANA, regardless of the kind of tokens used. Extension-tokens MAY be freely used for any non-standard, private, and/or experimental uses. An extension-tokens MUST use the format "-.", where is a validly registered (sub-)domain name on the Internet owned by the party who defines the extensions. Any unknown parameter name is to be ignored regardless of whether it is an extension-token or a bare-token. 7. IANA Considerations This document defines two new entries for the "Permanent Message Header Field Names" registry. +-------------+---------------------------+-------------------------+ | | Entry 1: | Entry 2: | +-------------+---------------------------+-------------------------+ | Header | Optional-WWW-Authenticate | Authentication-Control | | Field Name | | | | Protocol | http | http | | Status | experimental | experimental | | Change | IETF | IETF | | Control | | | | Spec. | Section 3 of this | Section 4 of this | | Document | document | document | +-------------+---------------------------+-------------------------+ This document also establishes a registry for HTTP authentication Oiwa, et al. Expires March 21, 2017 [Page 22] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 control parameters. The registry manages case-insensitive ASCII strings. The string MUST follow the extensive-token syntax defined in Section 2.2. To acquire registered tokens, a specification for the use of such tokens MUST be available as a publicly-accessible document, as outlined as "Specification Required" level in [RFC5226]. Registrations for authentication control parameters are required to include a description of the control extension. New registrations are advised to provide the following information: o Token: a token used in HTTP headers for identifying the algorithm. o Specification: A reference for a specification defining the algorithm. The initial content of this registry is as follows: +-------------------------------+------------------------------+ | Token | Specification | +-------------------------------+------------------------------+ | auth-style | Section 4.2 of this document | | location-when-unauthenticated | Section 4.3 of this document | | no-auth | Section 4.4 of this document | | location-when-logout | Section 4.5 of this document | | logout-timeout | Section 4.6 of this document | | username | Section 4.7 of this document | +-------------------------------+------------------------------+ 8. Security Considerations The purpose of the log-out timeout feature in the Authentication- control header is to protect users of clients from impersonation caused by an attacker having access to the same console. The server application implementers SHOULD be aware that the directive may always be ignored by either malicious clients or clients not supporting this extension. If the purpose of introducing a timeout for an authentication period is to protect server-side resources, this protection MUST be implemented by other means such as HTTP Cookies [RFC6265]. All parameters in the Authentication-Control header SHOULD NOT be used for any security-enforcement purposes. Server-side applications MUST NOT assume that the header will be honored by clients and users. Oiwa, et al. Expires March 21, 2017 [Page 23] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 8.1. Security implication of the username parameter The "username" parameter sometimes reveals sensitive information about the HTTP server and its configurations, useful for security attacks. In general, security common practice suggests that any kind of information on the existence/non-existence of specific user-name shall not be disclosed before the successful authentication. Obviously, the "username" parameter contradicts with this practice. Given this background, the use of the "username" parameter SHOULD be strictly limited to cases where the all of the following conditions are met: (1) the valid user name is pre-configured and not modifiable (such as root, admin or similar ones); (2) the valid user name for such an appliance is publicly known (for example, written in a manual document); and (3) either the valid user name for the server is easily guessable by other means (for example, from the model number shown in an unauthenticated page), or the server is accessible only from limited networks. Most importantly, the "username" parameter SHOULD NOT be used in any case when the valid user names can be changed/configured by users or administrators. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . Oiwa, et al. Expires March 21, 2017 [Page 24] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 [RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . 9.2. Informative References [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, . [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, . [W3C.REC-webstorage-20130730] Hickson, I., "Web Storage", World Wide Web Consortium Recommendation REC-webstorage-20130730, July 2013, . Appendix A. (Informative) Applicability of features for each messages This section provides a cross-reference table showing the applicability of the features provided in this specification to each kind of responses described in Section 2.1. The table provided in this section is for informative purposes only. Oiwa, et al. Expires March 21, 2017 [Page 25] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 +-------------------+-------+----------+-----------+------+ | | init. | success. | intermed. | neg. | +-------------------+-------+----------+-----------+------+ | Optional auth. | O | n | N | N | | auth-style | O | - | - | O | | loc.-when-unauth. | O | I | I | i | | no-auth | O | I | I | i | | loc.-when-logout | - | O | - | - | | logout-timeout | - | O | - | - | | username | O | - | - | O | +-------------------+-------+----------+-----------+------+ Legends: O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain i = SHOULD be ignored; I = MUST be ignored; - = meaningless (to be ignored) Appendix B. (Informative) Draft Change Log [To be removed on final publication] B.1. Changes in Httpauth WG Revision 09 o More comments are reflected to the text. B.2. Changes in Httpauth WG Revision 08 o Typo fixed. o Authors' addresses updated. B.3. Changes in Httpauth WG Revision 07 o WGLC comments are reflected to the text. B.4. Changes in Httpauth WG Revision 06 o Several comments from reviewers are reflected to the text. B.5. Changes in Httpauth WG Revision 05 o Authors' addresses updated. Oiwa, et al. Expires March 21, 2017 [Page 26] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 B.6. Changes in Httpauth WG revision 04 o IANA consideration section added. B.7. Changes in Httpauth WG revision 03 o Adopting RFC 5987 extended syntax for non-ASCII parameter values. B.8. Changes in Httpauth WG revision 02 o Added realm parameter. o Added username parameter. We acknowledge Michael Sweet's proposal for including this to the Basic authentication. B.9. Changes in Httpauth WG revision 01 o Clarification on peers' responsibility about handling of relative URLs. o Automatic reloading should be allowed only on safe methods, not always on idempotent methods. B.10. Changes in Httpauth revision 00 and HttpBis revision 00 None. B.11. Changes in revision 02 o Added usage examples. B.12. Changes in revision 01 o Syntax notations and parsing semantics changed to match httpbis style. B.13. Changes in revision 00 o Separated from HTTP Mutual authentication proposal (-09). o Adopting httpbis works as a referencing point to HTTP. o Generalized, now applicable for all HTTP authentication schemes. o Added "no-auth" and "auth-style" parameters. o Loosened standardization requirements for parameter-name tokens registration. Oiwa, et al. Expires March 21, 2017 [Page 27] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 Authors' Addresses Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: y.oiwa@aist.go.jp Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: h-watanabe@aist.go.jp Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: takagi.hiromitsu@aist.go.jp Kaoru Maeda Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Email: maeda@lepidum.co.jp Oiwa, et al. Expires March 21, 2017 [Page 28] Internet-Draft HTTP Auth. Ext. for Interactive Clients September 2016 Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Email: hayashi@lepidum.co.jp Yuichi Ioku Individual Email: mutual-work@ioku.org Oiwa, et al. Expires March 21, 2017 [Page 29] ./draft-ietf-mpls-rfc4379bis-09.txt0000664000764400076440000052167613005012573016150 0ustar iustyiusty Network Working Group K. Kompella Internet-Draft Juniper Networks, Inc. Obsoletes: 4379, 6424, 6829, 7537 (if G. Swallow approved) C. Pignataro, Ed. Intended status: Standards Track N. Kumar Expires: May 1, 2017 Cisco S. Aldrin Google M. Chen Huawei October 28, 2016 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures draft-ietf-mpls-rfc4379bis-09 Abstract This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. This document obsoletes RFCs 4379, 6424, 6829, and 7537. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 1, 2017. Kompella, et al. Expires May 1, 2017 [Page 1] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Structure of This Document . . . . . . . . . . . . . . . 5 1.3. Contributors . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Scope of RFC4379bis work . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 8 2.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 9 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 16 3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 17 3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 18 3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 18 3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 18 3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 19 3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 20 3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 20 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 21 Kompella, et al. Expires May 1, 2017 [Page 2] Internet-Draft Detecting MPLS Data Plane Failures October 2016 3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 21 3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 22 3.2.11. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 23 3.2.12. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 24 3.2.13. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 25 3.2.14. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 25 3.2.15. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 25 3.2.16. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 26 3.2.17. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 27 3.4. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 27 3.4.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 30 3.4.2. Downstream Router and Interface . . . . . . . . . . . 37 3.5. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.6. Vendor Enterprise Number . . . . . . . . . . . . . . . . 38 3.7. Interface and Label Stack . . . . . . . . . . . . . . . . 38 3.8. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 40 3.9. Reply TOS Octet TLV . . . . . . . . . . . . . . . . . . . 40 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 41 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . . 41 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 42 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 42 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 43 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 49 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 50 4.5.1. Addition of a New Tunnel . . . . . . . . . . . . . . 51 4.5.2. Transition between Tunnels . . . . . . . . . . . . . 52 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 53 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 55 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 6.1. TCP and UDP Port Number . . . . . . . . . . . . . . . . . 58 6.2. MPLS LSP Ping Parameters . . . . . . . . . . . . . . . . 58 6.2.1. Message Types, Reply Modes, Return Codes . . . . . . 58 6.2.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 59 6.2.3. Global Flags . . . . . . . . . . . . . . . . . . . . 60 6.2.4. Downstream Detailed Mapping Address Type . . . . . . 61 6.2.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . 61 6.2.6. Multipath Types . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2.7. Pad Type . . . . . . . . . . . . . . . . . . . . . . 62 6.2.8. Interface and Label Stack Address Type . . . . . . . 63 6.3. IPv4 Special-Purpose Address Registry . . . . . . . . . . 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 64 8.2. Informative References . . . . . . . . . . . . . . . . . 65 Kompella, et al. Expires May 1, 2017 [Page 3] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Appendix A. Deprecated TLVs and sub-TLVs (Non-normative) . . . . 68 A.1. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 68 A.1.1. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 68 A.2. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 1. Introduction This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply", and mechanisms for transporting the echo reply. The first part aims at providing enough information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The second part suggests two methods of providing reliable reply channels for the echo request message for more robust fault isolation. An important consideration in this design is that MPLS echo requests follow the same data path that normal MPLS packets would traverse. MPLS echo requests are meant primarily to validate the data plane, and secondarily to verify the data plane against the control plane. Mechanisms to check the control plane are valuable, but are not covered in this document. This document makes special use of the address range 127/8. This is an exception to the behavior defined in RFC 1122 [RFC1122] and updates that RFC. The motivation for this change and the details of this exceptional use are discussed in Section 2.1 below. This document obsoletes RFC 4379 [RFC4379], RFC 6424 [RFC6424], RFC 6829 [RFC6829], and RFC 7537 [RFC7537]. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The term "Must Be Zero" (MBZ) is used in object descriptions for reserved fields. These fields MUST be set to zero when sent and ignored on receipt. Terminology pertaining to L2 and L3 Virtual Private Networks (VPNs) is defined in [RFC4026]. Kompella, et al. Expires May 1, 2017 [Page 4] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Since this document refers to the MPLS Time to Live (TTL) far more frequently than the IP TTL, the authors have chosen the convention of using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for the TTL value in the IP header. 1.2. Structure of This Document The body of this memo contains four main parts: motivation, MPLS echo request/reply packet format, LSP ping operation, and a reliable return path. It is suggested that first-time readers skip the actual packet formats and read the Theory of Operation first; the document is structured the way it is to avoid forward references. 1.3. Contributors A mechanism used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) was originally published as RFC 4379 in February 2006. It was produced by the MPLS Working Group of the IETF and was jointly authored by Kireeti Kompella and George Swallow. The following made vital contributions to all aspects of the original RFC 4379, and much of the material came out of debate and discussion among this group. Ronald P. Bonica, Juniper Networks, Inc. Dave Cooper, Global Crossing Ping Pan, Hammerhead Systems Nischal Sheth, Juniper Networks, Inc. Sanjay Wadhwa, Juniper Networks, Inc. 1.4. Scope of RFC4379bis work The primary goal of this document is to provide a clean and updated LSP Ping specification. [RFC4379] defines the basic mechanism for MPLS LSP validation that can be used for fault detection and isolation. The scope of this document also is to address various updates to MPLS LSP Ping, including: o Update all references and citations. * Obsoleted RFCs 2434, 2030, and 3036 are respectively replaced with RFCs 5226, 5905, and 5036. * Additionally, these three documents published as RFCs: RFCs 4447, 4761, and 5085. Kompella, et al. Expires May 1, 2017 [Page 5] Internet-Draft Detecting MPLS Data Plane Failures October 2016 o Incorporate all outstanding Errata. * Erratum with IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978. o Replace EXP with Traffic Class (TC), based on the update from RFC 5462. o Incorporate the updates from RFC 6829, by adding the pseudowire (PW) Forwarding Equivalence Classes (FECs) advertised over IPv6, and obsoleting RFC 6829. o Incorporate the updates from RFC 7506, by adding IPv6 Router Alert Option for MPLS OAM. o Incorporate newly defined bits on the Global Flags field, from RFC 6425 and RFC 6426. o Update the IPv4 addresses used in examples to utilize the documentation prefix. Add examples with IPv6 addresses. o Incorporate the updates from RFC 6424, by deprecating the Downstream Mapping TLV (DSMAP) and adding the Downstream Detailed Mapping TLV (DDMAP), updating two new return codes, adding the motivations of tunneled or stitched LSP, updating the procedures, IANA Considerations Section, Security Considerations, and obsoleting RFC 6424. o Incorporate the updates from RFC 7537, by updating the IANA Considerations Section, and obsoleting RFC 7537. o Finally, obsolete RFC 4379. 2. Motivation When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time, and a mechanism to isolate faults. In this document, we describe a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [RFC0792]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. This document specifies a "ping" mode and a "traceroute" mode for testing MPLS LSPs. Kompella, et al. Expires May 1, 2017 [Page 6] Internet-Draft Detecting MPLS Data Plane Failures October 2016 The basic idea is to verify that packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on a Label Switching Router (LSR) that is an egress for that FEC. This document proposes that this test be carried out by sending a packet (called an "MPLS echo request") along the same data path as other packets belonging to this FEC. An MPLS echo request also carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies whether it is indeed an egress for the FEC. In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for this path; this LSR also returns further information that helps check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path. An LSP traceroute may cross a tunneled or stitched LSP en route to the destination. While performing end-to-end LSP validation in such scenarios, the FEC information included in the packet by Initiator may be different from the one assigned by transit node in different segment of a stitched LSP or tunnel. Let us consider a simple case. A B C D E o -------- o -------- o --------- o --------- o \_____/ | \______/ \______/ | \______/ LDP | RSVP RSVP | LDP | | \____________________/ LDP When an LSP traceroute is initiated from Router A to Router E, the FEC information included in the packet will be LDP while Router C along the path is a pure RSVP node and does not run LDP. Consequently, node C will be unable to perform FEC validation. The MPLS echo request should contain sufficient information to allow any transit node within stitched or tunneled LSP to perform FEC validations to detect any misrouted echo request. One way these tools can be used is to periodically ping an FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and thus should be used with caution. Kompella, et al. Expires May 1, 2017 [Page 7] Internet-Draft Detecting MPLS Data Plane Failures October 2016 2.1. Use of Address Range 127/8 As described above, LSP ping is intended as a diagnostic tool. It is intended to enable providers of an MPLS-based service to isolate network faults. In particular, LSP ping needs to diagnose situations where the control and data planes are out of sync. It performs this by routing an MPLS echo request packet based solely on its label stack. That is, the IP destination address is never used in a forwarding decision. In fact, the sender of an MPLS echo request packet may not know, a priori, the address of the router at the end of the LSP. Providers of MPLS-based services also need the ability to trace all of the possible paths that an LSP may take. Since most MPLS services are based on IP unicast forwarding, these paths are subject to equal- cost multi-path (ECMP) load sharing. This leads to the following requirements: 1. Although the LSP in question may be broken in unknown ways, the likelihood of a diagnostic packet being delivered to a user of an MPLS service MUST be held to an absolute minimum. 2. If an LSP is broken in such a way that it prematurely terminates, the diagnostic packet MUST NOT be IP forwarded. 3. A means of varying the diagnostic packets such that they exercise all ECMP paths is thus REQUIRED. Clearly, using general unicast addresses satisfies neither of the first two requirements. A number of other options for addresses were considered, including a portion of the private address space (as determined by the network operator) and the IPv4 link local addresses. Use of the private address space was deemed ineffective since the leading MPLS-based service is an IPv4 Virtual Private Network (VPN). VPNs often use private addresses. The IPv4 link local addresses are more attractive in that the scope over which they can be forwarded is limited. However, if one were to use an address from this range, it would still be possible for the first recipient of a diagnostic packet that "escaped" from a broken LSP to have that address assigned to the interface on which it arrived and thus could mistakenly receive such a packet. Older deployed routers may not (correctly) implement IPv4 link local addresses and would forward a packet with an address from that range toward the default route. Kompella, et al. Expires May 1, 2017 [Page 8] Internet-Draft Detecting MPLS Data Plane Failures October 2016 The 127/8 range for IPv4 and that same range embedded in an IPv4-mapped IPv6 addresses for IPv6 was chosen for a number of reasons. RFC 1122 allocates the 127/8 as "Internal host loopback address" and states: "Addresses of this form MUST NOT appear outside a host." Thus, the default behavior of hosts is to discard such packets. This helps to ensure that if a diagnostic packet is misdirected to a host, it will be silently discarded. RFC 1812 [RFC1812] states: A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks. This helps to ensure that diagnostic packets are never IP forwarded. The 127/8 address range provides 16M addresses allowing wide flexibility in varying addresses to exercise ECMP paths. Finally, as an implementation optimization, the 127/8 provides an easy means of identifying possible LSP packets. 2.2. Router Alert Option This document requires the use of the Router Alert Option (RAO) set in IP header in order to have the transit node process the MPLS OAM payload. [RFC2113] defines a generic Option Value 0x0 for IPv4 RAO that alerts transit router to examine the IPv4 packet. [RFC7506] defines MPLS OAM Option Value 69 for IPv6 RAO to alert transit routers to examine the IPv6 packet more closely for MPLS OAM purposes. The use of the Router Alert IP Option in this document is as follows: In case of an IPv4 header, the generic IPv4 RAO value 0x0 [RFC2113] SHOULD be used. In case of an IPv6 header, the IPv6 RAO value (69) for MPLS OAM [RFC7506] MUST be used. 3. Packet Format An MPLS echo request/reply is a (possibly labeled) IPv4 or IPv6 UDP packet; the contents of the UDP packet have the following format: Kompella, et al. Expires May 1, 2017 [Page 9] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Global Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Reply mode | Return Code | Return Subcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent (seconds fraction) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Received (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Received (seconds fraction) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Version Number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of an implementation to correctly parse or process an MPLS echo request/ reply. These changes include any syntactic or semantic changes made to any of the fixed fields, or to any Type-Length-Value (TLV) or sub- TLV assignment or format that is defined at a certain version number. The version number may not need to be changed if an optional TLV or sub-TLV is added.) The Global Flags field is a bit vector with the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |R|T|V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ At the time of writing three flags are defined, the R, T, and V bits; the rest MUST be set to zero when sending and ignored on receipt. Kompella, et al. Expires May 1, 2017 [Page 10] Internet-Draft Detecting MPLS Data Plane Failures October 2016 The V (Validate FEC Stack) flag is set to 1 if the sender wants the receiver to perform FEC Stack validation; if V is 0, the choice is left to the receiver. The T (Respond Only If TTL Expired) flag MUST be set only in the echo request packet by the sender. If the T flag is set to 1 in an incoming echo request, and the TTL of the incoming MPLS label is more than 1, then the receiving node MUST drop the incoming echo request and MUST NOT send any echo reply to the sender. This flag MUST NOT be set in the echo reply packet. If this flag is set in an echo reply packet, then it MUST be ignored. The T flag is defined in Section 3.4 of [RFC6425]. The R (Validate Reverse Path) flag is defined in [RFC6426]. When this flag is set in the echo request, the Responder SHOULD return reverse-path FEC information, as described in Section 3.4.2 of [RFC6426]. The Message Type is one of the following: Value Meaning ----- ------- 1 MPLS echo request 2 MPLS echo reply The Reply Mode can take one of the following values: Value Meaning ----- ------- 1 Do not reply 2 Reply via an IPv4/IPv6 UDP packet 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 4 Reply via application level control channel An MPLS echo request with 1 (Do not reply) in the Reply Mode field may be used for one-way connectivity tests; the receiving router may log gaps in the Sequence Numbers and/or maintain delay/jitter statistics. An MPLS echo request would normally have 2 (Reply via an IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP return path is deemed unreliable, one may use 3 (Reply via an IPv4/ IPv6 UDP packet with Router Alert). Note that this requires that all intermediate routers understand and know how to forward MPLS echo replies. The echo reply uses the same IP version number as the received echo request, i.e., an IPv4 encapsulated echo reply is sent in response to an IPv4 encapsulated echo request. Some applications support an IP control channel. One such example is the associated control channel defined in Virtual Circuit Kompella, et al. Expires May 1, 2017 [Page 11] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Connectivity Verification (VCCV) [RFC5085]. Any application that supports an IP control channel between its control entities may set the Reply Mode to 4 (Reply via application level control channel) to ensure that replies use that same channel. Further definition of this codepoint is application specific and thus beyond the scope of this document. Return Codes and Subcodes are described in Section 3.1. The Sender's Handle is filled in by the sender, and returned unchanged by the receiver in the echo reply (if any). There are no semantics associated with this handle, although a sender may find this useful for matching up requests with replies. The Sequence Number is assigned by the sender of the MPLS echo request and can be (for example) used to detect missed replies. The TimeStamp Sent is the time-of-day (according to the sender's clock) in 64-bit NTP Timestamp format [RFC5905] when the MPLS echo request is sent. The TimeStamp Received in an echo reply is the time-of-day (according to the receiver's clock) in 64-bit NTP Timestamp format that the corresponding echo request was received. TLVs (Type-Length-Value tuples) have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a 4-octet boundary. TLVs may be nested within other TLVs, in which case the nested TLVs are called sub-TLVs. Sub-TLVs have independent types and MUST also be 4-octet aligned. Two examples of how TLV and sub-TLV length are computed, and of how sub-TLVs are padded to be 4-octet aligned as follows: Kompella, et al. Expires May 1, 2017 [Page 12] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 (LDP IPv4 FEC) | Length = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length for this TLV is 5. A Target FEC Stack TLV that contains an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 (FEC TLV) | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type = 6 (VPN IPv4 prefix)| Length = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A description of the Types and Values of the top-level TLVs for LSP ping are given below: Kompella, et al. Expires May 1, 2017 [Page 13] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Type # Value Field ------ ----------- 1 Target FEC Stack 2 Downstream Mapping (Deprecated) 3 Pad 4 Unassigned 5 Vendor Enterprise Number 6 Unassigned 7 Interface and Label Stack 8 Unassigned 9 Errored TLVs 10 Reply TOS Byte 20 Downstream Detailed Mapping Types less than 32768 (i.e., with the high-order bit equal to 0) are mandatory TLVs that MUST either be supported by an implementation or result in the return code of 2 ("One or more of the TLVs was not understood") being sent in the echo response. Types greater than or equal to 32768 (i.e., with the high-order bit equal to 1) are optional TLVs that SHOULD be ignored if the implementation does not understand or support them. In Section 3.2 through Section 3.9 and their various subsections, only the Value field of the TLV is included. 3.1. Return Codes The Return Code is set to zero by the sender of an Echo Request. The receiver of said Echo Request can set it to one of the values listed below in the corresponding Echo Reply that it generates. The notation refers to the Return Subcode. This field is filled in with the stack-depth for those codes that specify that. For all other codes, the Return Subcode MUST be set to zero. Kompella, et al. Expires May 1, 2017 [Page 14] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Value Meaning ----- ------- 0 No return code 1 Malformed echo request received 2 One or more of the TLVs was not understood 3 Replying router is an egress for the FEC at stack- depth 4 Replying router has no mapping for the FEC at stack- depth 5 Downstream Mapping Mismatch (See Note 1) 6 Upstream Interface Index Unknown (See Note 1) 7 Reserved 8 Label switched at stack-depth 9 Label switched but no MPLS forwarding at stack-depth 10 Mapping for this FEC is not the given label at stack- depth 11 No label entry at stack-depth 12 Protocol not associated with interface at FEC stack- depth 13 Premature termination of ping due to label stack shrinking to a single label 14 See DDMAP TLV for Return Code and Return Subcode (See Note 2) 15 Label switched with FEC change Note 1 The Return Subcode contains the point in the label stack where processing was terminated. If the RSC is 0, no labels were processed. Otherwise the packet would have been label switched at depth RSC. Note 2 The Return Code is per Downstream Detailed Mapping TLV (Section 3.4). This Return Code MUST be used only in the message header and MUST be set only in the MPLS echo reply message. If the Return Code is set in the MPLS echo request message, then it MUST be ignored. When this Return Code is set, each Downstream Detailed Mapping TLV MUST have an appropriate Return Code and Return Subcode. This Return Code MUST be used when there are multiple downstreams for a given node (such as Point to Multipoint (P2MP) or Equal Cost Multi-Path (ECMP)), and the node needs to return a Return Code/Return Subcode for each downstream. This Return Code MAY be used even when there is only one downstream for a given node. Kompella, et al. Expires May 1, 2017 [Page 15] Internet-Draft Detecting MPLS Data Plane Failures October 2016 3.2. Target FEC Stack A Target FEC Stack is a list of sub-TLVs. The number of elements is determined by looking at the sub-TLV length fields. Sub-Type Length Value Field -------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix 3 20 RSVP IPv4 LSP 4 56 RSVP IPv6 LSP 5 Unassigned 6 13 VPN IPv4 prefix 7 25 VPN IPv6 prefix 8 14 L2 VPN endpoint 9 10 "FEC 128" Pseudowire - IPv4 (deprecated) 10 14 "FEC 128" Pseudowire - IPv4 11 16+ "FEC 129" Pseudowire - IPv4 12 5 BGP labeled IPv4 prefix 13 17 BGP labeled IPv6 prefix 14 5 Generic IPv4 prefix 15 17 Generic IPv6 prefix 16 4 Nil FEC 24 38 "FEC 128" Pseudowire - IPv6 25 40+ "FEC 129" Pseudowire - IPv6 Other FEC Types will be defined as needed. Note that this TLV defines a stack of FECs, the first FEC element corresponding to the top of the label stack, etc. An MPLS echo request MUST have a Target FEC Stack that describes the FEC Stack being tested. For example, if an LSR X has an LDP mapping [RFC5036] for 192.0.2.1 (say, label 1001), then to verify that label 1001 does indeed reach an egress LSR that announced this prefix via LDP, X can send an MPLS echo request with an FEC Stack TLV with one FEC in it, namely, of type LDP IPv4 prefix, with prefix 192.0.2.1/32, and send the echo request with a label of 1001. Say LSR X wanted to verify that a label stack of <1001, 23456> is the right label stack to use to reach a VPN IPv4 prefix [see Section 3.2.5] of 203.0.113.0/24 in VPN foo. Say further that LSR Y with loopback address 192.0.2.1 announced prefix 203.0.113.0/24 with Route Distinguisher RD-foo-Y (which may in general be different from the Route Distinguisher that LSR X uses in its own advertisements for VPN foo), label 23456 and BGP next hop 192.0.2.1 [RFC4271]. Finally, suppose that LSR X receives a label binding of 1001 for 192.0.2.1 via LDP. X has two choices in sending an MPLS echo request: X can send Kompella, et al. Expires May 1, 2017 [Page 16] Internet-Draft Detecting MPLS Data Plane Failures October 2016 an MPLS echo request with an FEC Stack TLV with a single FEC of type VPN IPv4 prefix with a prefix of 203.0.113.0/24 and a Route Distinguisher of RD-foo-Y. Alternatively, X can send an FEC Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 192.0.2.1/32 and the second of type of IP VPN with a prefix 203.0.113.0/24 with Route Distinguisher of RD-foo-Y. In either case, the MPLS echo request would have a label stack of <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 23456 is the "inner" label.) If, for example, an LSR Y has an LDP mapping for the IPv6 address 2001:db8::1 (say, label 2001), then to verify that label 2001 does reach an egress LSR that announced this prefix via LDP, LSR Y can send an MPLS echo request with an FEC Stack TLV with one LDP IPv6 prefix FEC, with prefix 2001:db8::1/128, and with a label of 2001. If an end-to-end path comprises of one or more tunneled or stitched LSPs, each transit node that is the originating point of a new tunnel or segment SHOULD reply back notifying the FEC stack change along with the new FEC details. For example, if LSR X has an LDP mapping for IPv4 prefix 192.0.2.10 on LSR Z (say, label 3001). Say further that LSR A and LSR B are transit nodes along the path which also have an RSVP tunnel over which LDP is enabled. While replying back, A SHOULD notify that the FEC changes from LDP to . If the new tunnel is a transparent pipe, i.e., the data-plane trace will not expire in the middle of the tunnel, then the transit node SHOULD NOT reply back notifying the FEC stack change or the new FEC details. If the transit node wishes to hide the nature of the tunnel from the ingress of the echo request, then the transit node MAY notify the FEC stack change and include Nil FEC as the new FEC. 3.2.1. LDP IPv4 Prefix The IPv4 Prefix FEC is defined in [RFC5036]. When an LDP IPv4 prefix is encoded in a label stack, the following format is used. The value consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv4 prefix is in network byte order; if the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero. See [RFC5036] for an example of a Mapping for an IPv4 FEC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kompella, et al. Expires May 1, 2017 [Page 17] Internet-Draft Detecting MPLS Data Plane Failures October 2016 3.2.2. LDP IPv6 Prefix The IPv6 Prefix FEC is defined in [RFC5036]. When an LDP IPv6 prefix is encoded in a label stack, the following format is used. The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero. See [RFC5036] for an example of a Mapping for an IPv6 FEC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.3. RSVP IPv4 LSP The value has the format below. The value fields are taken from RFC 3209, Sections 4.6.1.1 and 4.6.2.1. See [RFC3209]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.4. RSVP IPv6 LSP The value has the format below. The value fields are taken from RFC 3209, Sections 4.6.1.2 and 4.6.2.2. See [RFC3209]. Kompella, et al. Expires May 1, 2017 [Page 18] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 tunnel end point address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 tunnel sender address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.5. VPN IPv4 Prefix VPN-IPv4 Network Layer Routing Information (NLRI) is defined in [RFC4365]. This document uses the term VPN IPv4 prefix for a VPN- IPv4 NLRI that has been advertised with an MPLS label in BGP. See [RFC3107]. When a VPN IPv4 prefix is encoded in a label stack, the following format is used. The value field consists of the Route Distinguisher advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 bits to make 32 bits in all), and a prefix length, as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Route Distinguisher (RD) is an 8-octet identifier; it does not contain any inherent information. The purpose of the RD is solely to Kompella, et al. Expires May 1, 2017 [Page 19] Internet-Draft Detecting MPLS Data Plane Failures October 2016 allow one to create distinct routes to a common IPv4 address prefix. The encoding of the RD is not important here. When matching this field to the local FEC information, it is treated as an opaque value. 3.2.6. VPN IPv6 Prefix VPN-IPv6 Network Layer Routing Information (NLRI) is defined in [RFC4365]. This document uses the term VPN IPv6 prefix for a VPN- IPv6 NLRI that has been advertised with an MPLS label in BGP. See [RFC3107]. When a VPN IPv6 prefix is encoded in a label stack, the following format is used. The value field consists of the Route Distinguisher advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 bits to make 128 bits in all), and a prefix length, as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Route Distinguisher is identical to the VPN IPv4 Prefix RD, except that it functions here to allow the creation of distinct routes to IPv6 prefixes. See Section 3.2.5. When matching this field to local FEC information, it is treated as an opaque value. 3.2.7. L2 VPN Endpoint VPLS stands for Virtual Private LAN Service. The terms VPLS BGP NLRI and VE ID (VPLS Edge Identifier) are defined in [RFC4761]. This document uses the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI. The Route Distinguisher is an 8-octet identifier used to distinguish information about various L2 VPNs advertised by a node. The VE ID is a 2-octet identifier used to identify a particular node that serves as the service attachment point within a VPLS. The structure of these two identifiers is unimportant here; when matching these fields to local FEC information, they are treated as opaque values. The encapsulation type is identical to the PW Type in Section 3.2.9. Kompella, et al. Expires May 1, 2017 [Page 20] Internet-Draft Detecting MPLS Data Plane Failures October 2016 When an L2 VPN endpoint is encoded in a label stack, the following format is used. The value field consists of a Route Distinguisher (8 octets), the sender (of the ping)'s VE ID (2 octets), the receiver's VE ID (2 octets), and an encapsulation type (2 octets), formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's VE ID | Receiver's VE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulation Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) See Appendix A.1.1 for details 3.2.9. FEC 128 Pseudowire - IPv4 (Current) FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed encapsulation type with the high-order bit set to zero. Both of these fields are treated in this protocol as opaque values. When matching these field to the local FEC information, the match MUST be exact. When an FEC 128 is encoded in a label stack, the following format is used. The value field consists of the Sender's Provider Edge (PE) IPv4 Address (the source address of the targeted LDP session), the Remote PE IPv4 Address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows: Kompella, et al. Expires May 1, 2017 [Page 21] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.10. FEC 129 Pseudowire - IPv4 FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier (AGI), Attachment Group Identifier Type (AGI Type), Attachment Individual Identifier Type (AII Type), Source Attachment Individual Identifier (SAII), and Target Attachment Individual Identifier (TAII) are defined in [RFC4447]. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below PW Type with the high-order bit set to zero. All the other fields are treated as opaque values and copied directly from the FEC 129 format. All of these values together uniquely define the FEC within the scope of the LDP session identified by the source and remote PE IPv4 addresses. When an FEC 129 is encoded in a label stack, the following format is used. The Length of this TLV is 16 + AGI length + SAII length + TAII length. Padding is used to make the total length a multiple of 4; the length of the padding is not included in the Length field. Kompella, et al. Expires May 1, 2017 [Page 22] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | AGI Type | AGI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | SAII Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (continued) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | TAII Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (continued) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII (cont.) | 0-3 octets of zero padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.11. FEC 128 Pseudowire - IPv6 The FEC 128 Pseudowire IPv6 sub-TLV has a structure consistent with the FEC 128 Pseudowire IPv4 sub-TLV as described in Section 3.2.9. The value field consists of the Sender's PE IPv6 Address (the source address of the targeted LDP session), the Remote PE IPv6 Address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sender's PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Remote PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender's PE IPv6 Address: The source IP address of the target IPv6 LDP session. 16 octets. Kompella, et al. Expires May 1, 2017 [Page 23] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Remote PE IPv6 Address: The destination IP address of the target IPv6 LDP session. 16 octets. PW ID: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9. PW Type: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9. 3.2.12. FEC 129 Pseudowire - IPv6 The FEC 129 Pseudowire IPv6 sub-TLV has a structure consistent with the FEC 129 Pseudowire IPv4 sub-TLV as described in Section 3.2.10. When an FEC 129 is encoded in a label stack, the following format is used. The length of this TLV is 40 + AGI (Attachment Group Identifier) length + SAII (Source Attachment Individual Identifier) length + TAII (Target Attachment Individual Identifier) length. Padding is used to make the total length a multiple of 4; the length of the padding is not included in the Length field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sender's PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Remote PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | AGI Type | AGI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | SAII Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (continued) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | TAII Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (continued) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII (cont.) | 0-3 octets of zero padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender's PE IPv6 Address: The source IP address of the target IPv6 LDP session. 16 octets. Remote PE IPv6 Address: The destination IP address of the target IPv6 LDP session. 16 octets. The other fields are the same as FEC 129 Pseudowire IPv4 in Section 3.2.10. Kompella, et al. Expires May 1, 2017 [Page 24] Internet-Draft Detecting MPLS Data Plane Failures October 2016 3.2.13. BGP Labeled IPv4 Prefix BGP labeled IPv4 prefixes are defined in [RFC3107]. When a BGP labeled IPv4 prefix is encoded in a label stack, the following format is used. The value field consists the IPv4 prefix (with trailing 0 bits to make 32 bits in all), and the prefix length, as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.14. BGP Labeled IPv6 Prefix BGP labeled IPv6 prefixes are defined in [RFC3107]. When a BGP labeled IPv6 prefix is encoded in a label stack, the following format is used. The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.15. Generic IPv4 Prefix The value consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv4 prefix is in network byte order; if the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero. This FEC is used if the protocol advertising the label is unknown or may change during the course of the LSP. An example is an inter-AS LSP that may be signaled by LDP in one Autonomous System (AS), by RSVP-TE [RFC3209] in another AS, and by BGP between the ASes, such as is common for inter-AS VPNs. Kompella, et al. Expires May 1, 2017 [Page 25] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.16. Generic IPv6 Prefix The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.17. Nil FEC At times, labels from the reserved range, e.g., Router Alert and Explicit-null, may be added to the label stack for various diagnostic purposes such as influencing load-balancing. These labels may have no explicit FEC associated with them. The Nil FEC Stack is defined to allow a Target FEC Stack sub-TLV to be added to the Target FEC Stack to account for such labels so that proper validation can still be performed. The Length is 4. Labels are 20-bit values treated as numbers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label is the actual label value inserted in the label stack; the MBZ fields MUST be zero when sent and ignored on receipt. Kompella, et al. Expires May 1, 2017 [Page 26] Internet-Draft Detecting MPLS Data Plane Failures October 2016 3.3. Downstream Mapping (Deprecated) See Appendix A.2 for more details. 3.4. Downstream Detailed Mapping TLV The Downstream Detailed Mapping object is a TLV that MAY be included in an MPLS echo request message. Only one Downstream Detailed Mapping object may appear in an echo request. The presence of a Downstream Detailed Mapping object is a request that Downstream Detailed Mapping objects be included in the MPLS echo reply. If the replying router is the destination (Label Edge Router) of the FEC, then a Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS echo reply. Otherwise, the replying router SHOULD include a Downstream Detailed Mapping object for each interface over which this FEC could be forwarded. For a more precise definition of the notion of "downstream", see Section 3.4.2, "Downstream Router and Interface". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | DS Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Interface Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Code | Return Subcode| Sub-tlv Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . List of Sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Downstream Detailed Mapping TLV format is derived from the deprecated Downstream Mapping TLV format (see Appendix A.2.) The key change is that variable length and optional fields have been converted into sub-TLVs. Maximum Transmission Unit (MTU) The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the Downstream Label Switching Router (LSR). Address Type Kompella, et al. Expires May 1, 2017 [Page 27] Internet-Draft Detecting MPLS Data Plane Failures October 2016 The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the Downstream IP Address and Downstream Interface fields. The Address Type is set to one of the following values: Type # Address Type ------ ------------ 1 IPv4 Numbered 2 IPv4 Unnumbered 3 IPv6 Numbered 4 IPv6 Unnumbered DS Flags The DS Flags field is a bit vector of various flags with the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Rsvd(MBZ) |I|N| +-+-+-+-+-+-+-+-+ Two flags are defined currently, I and N. The remaining flags MUST be set to zero when sending and ignored on receipt. Flag Name and Meaning ---- ---------------- I Interface and Label Stack Object Request When this flag is set, it indicates that the replying router SHOULD include an Interface and Label Stack Object in the echo reply message. N Treat as a Non-IP Packet Echo request messages will be used to diagnose non-IP flows. However, these messages are carried in IP packets. For a router that alters its ECMP algorithm based on the FEC or deep packet examination, this flag requests that the router treat this as it would if the determination of an IP payload had failed. Downstream Address and Downstream Interface Address IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets. Kompella, et al. Expires May 1, 2017 [Page 28] Internet-Draft Detecting MPLS Data Plane Failures October 2016 If the interface to the downstream LSR is numbered, then the Address Type MUST be set to IPv4 or IPv6, the Downstream Address MUST be set to either the downstream LSR's Router ID or the interface address of the downstream LSR, and the Downstream Interface Address MUST be set to the downstream LSR's interface address. If the interface to the downstream LSR is unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream Address MUST be the downstream LSR's Router ID, and the Downstream Interface Address MUST be set to the index assigned by the upstream LSR to the interface. If an LSR does not know the IP address of its neighbor, then it MUST set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it must set the Downstream Address to 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with either of these addresses in the Downstream Address field, this indicates that it MUST bypass interface verification but continue with label validation. If the originator of an Echo Request packet wishes to obtain Downstream Detailed Mapping information but does not know the expected label stack, then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream Address to 224.0.0.2; for IPv6 the address MUST be set to FF02::2. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation, but return Downstream Mapping TLVs using the information provided. Return Code The Return Code is set to zero by the sender of an Echo Request. The receiver of said Echo Request can set it in the corresponding Echo Reply that it generates to one of the values specified in Section 3.1 other than 14. If the receiver sets a non-zero value of the Return Code field in the Downstream Detailed Mapping TLV, then the receiver MUST also set the Return Code field in the echo reply header to "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1.) An exception to this is if the receiver is a bud node [RFC4461] and is replying as both an egress and a transit node with a Return Code of 3 ("Replying router is an egress for the FEC at stack- depth ") in the echo reply header. Kompella, et al. Expires May 1, 2017 [Page 29] Internet-Draft Detecting MPLS Data Plane Failures October 2016 If the Return Code of the echo reply message is not set to either "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1) or "Replying router is an egress for the FEC at stack-depth ", then the Return Code specified in the Downstream Detailed Mapping TLV MUST be ignored. Return Subcode The Return Subcode is set to zero by the sender. The receiver can set this field to an appropriate value as specified in Section 3.1: The Return Subcode is filled in with the stack-depth for those codes that specify the stack-depth. For all other codes, the Return Subcode MUST be set to zero. If the Return Code of the echo reply message is not set to either "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1) or "Replying router is an egress for the FEC at stack-depth ", then the Return Subcode specified in the Downstream Detailed Mapping TLV MUST be ignored. Sub-tlv Length Total length in octets of the sub-TLVs associated with this TLV. 3.4.1. Sub-TLVs This section defines the sub-TLVs that MAY be included as part of the Downstream Detailed Mapping TLV. Sub-Type Value Field --------- ------------ 1 Multipath data 2 Label stack 3 FEC stack change 3.4.1.1. Multipath Data Sub-TLV Kompella, et al. Expires May 1, 2017 [Page 30] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Multipath Type | Multipath Length |Reserved (MBZ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | (Multipath Information) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The multipath data sub-TLV includes Multipath Information. Multipath Type The type of the encoding for the Multipath Information. The following Multipath Types are defined: Key Type Multipath Information --- ---------------- --------------------- 0 no multipath Empty (Multipath Length = 0) 2 IP address IP addresses 4 IP address range low/high address pairs 8 Bit-masked IP IP address prefix and bit mask address set 9 Bit-masked label set Label prefix and bit mask Type 0 indicates that all packets will be forwarded out this one interface. Types 2, 4, 8, and 9 specify that the supplied Multipath Information will serve to exercise this path. Multipath Length The length in octets of the Multipath Information. MBZ MUST be set to zero when sending; MUST be ignored on receipt. Multipath Information Encoded multipath data (e.g., encoded address or label values), according to the Multipath Type. See Section 3.4.1.1.1 for encoding details. Kompella, et al. Expires May 1, 2017 [Page 31] Internet-Draft Detecting MPLS Data Plane Failures October 2016 3.4.1.1.1. Multipath Information Encoding The Multipath Information encodes labels or addresses that will exercise this path. The Multipath Information depends on the Multipath Type. The contents of the field are shown in the table above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses are drawn from the range 0:0:0:0:0:FFFF:7F00:0/104. Labels are treated as numbers, i.e., they are right justified in the field. For Type 4, ranges indicated by Address pairs MUST NOT overlap and MUST be in ascending sequence. Type 8 allows a more dense encoding of IP addresses. The IP prefix is formatted as a base IP address with the non-prefix low-order bits set to zero. The maximum prefix length is 27. Following the prefix is a mask of length 2^(32-prefix length) bits for IPv4 and 2^(128-prefix length) bits for IPv6. Each bit set to 1 represents a valid address. The address is the base IPv4 address plus the position of the bit in the mask where the bits are numbered left to right beginning with zero. For example, the IPv4 addresses 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Those same addresses embedded in IPv6 would be encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 allows a more dense encoding of labels. The label prefix is formatted as a base label value with the non-prefix low-order bits Kompella, et al. Expires May 1, 2017 [Page 32] Internet-Draft Detecting MPLS Data Plane Failures October 2016 set to zero. The maximum prefix (including leading zeros due to encoding) length is 27. Following the prefix is a mask of length 2^(32-prefix length) bits. Each bit set to one represents a valid label. The label is the base label plus the position of the bit in the mask where the bits are numbered left to right beginning with zero. Label values of all the odd numbers between 1152 and 1279 would be encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the received Multipath Information is non-null, the labels and IP addresses MUST be picked from the set provided. If none of these labels or addresses map to a particular downstream interface, then for that interface, the type MUST be set to 0. If the received Multipath Information is null (i.e., Multipath Length = 0, or for Types 8 and 9, a mask of all zeros), the type MUST be set to 0. For example, suppose LSR X at hop 10 has two downstream LSRs, Y and Z, for the FEC in question. The received X could return Multipath Type 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for downstream LSR Y and 127.2.1.1->127.2.1.255 for downstream LSR Z. The head end reflects this information to LSR Y. Y, which has three downstream LSRs, U, V, and W, computes that 127.1.1.1->127.1.1.127 would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would then respond with 3 Downstream Detailed Mapping TLVs: to U, with Multipath Type 4 (127.1.1.1->127.1.1.127); to V, with Multipath Type 4 (127.1.1.127->127.1.1.255); and to W, with Multipath Type 0. Note that computing Multipath Information may impose a significant processing burden on the receiver. A receiver MAY thus choose to process a subset of the received prefixes. The sender, on receiving a reply to a Downstream Detailed Mapping with partial information, SHOULD assume that the prefixes missing in the reply were skipped by the receiver, and MAY re-request information about them in a new echo request. Kompella, et al. Expires May 1, 2017 [Page 33] Internet-Draft Detecting MPLS Data Plane Failures October 2016 The encoding of Multipath information in scenarios where few LSRs apply Entropy label based load balancing while other LSRs are non-EL (IP based) load balancing will be defined in a different document. The encoding of multipath information in scenarios where LSR have Layer 2 ECMP over Link Aggregation Group (LAG) interfaces will be defined in different document. 3.4.1.2. Label Stack Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Label stack sub-TLV contains the set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. The number of label/protocol pairs present in the sub-TLV is determined based on the sub-TLV data length. When the Downstream Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be included. Downstream Label A Downstream label is 24 bits, in the same format as an MPLS label minus the Time to Live (TTL) field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the Traffic Class (TC) field [RFC5462] is bits 20-22, and S is bit 23. The replying router SHOULD fill in the TC field and S bit; the LSR receiving the echo reply MAY choose to ignore these. Protocol This specifies the label distribution protocol for the Downstream label. Protocol values are taken from the following table: Kompella, et al. Expires May 1, 2017 [Page 34] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Protocol # Signaling Protocol ---------- ------------------ 0 Unknown 1 Static 2 BGP 3 LDP 4 RSVP-TE 3.4.1.3. FEC Stack Change Sub-TLV A router MUST include the FEC stack change sub-TLV when the downstream node in the echo reply has a different FEC Stack than the FEC Stack received in the echo request. One or more FEC stack change sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The format is as below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Operation Type | Address Type | FEC-tlv length| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Peer Address (0, 4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . FEC TLV . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Operation Type The operation type specifies the action associated with the FEC stack change. The following operation types are defined: Type # Operation ------ --------- 1 Push 2 Pop Address Type The Address Type indicates the remote peer's address type. The Address Type is set to one of the following values. The length of the peer address is determined based on the address type. The address type MAY be different from the address type included in the Downstream Detailed Mapping TLV. This can happen when the LSP goes over a tunnel of a different address family. The address type MAY be set to Unspecified if the peer address is either Kompella, et al. Expires May 1, 2017 [Page 35] Internet-Draft Detecting MPLS Data Plane Failures October 2016 unavailable or the transit router does not wish to provide it for security or administrative reasons. Type # Address Type Address length ------ ------------ -------------- 0 Unspecified 0 1 IPv4 4 2 IPv6 16 FEC TLV Length Length in octets of the FEC TLV. Reserved This field is reserved for future use and MUST be set to zero. Remote Peer Address The remote peer address specifies the remote peer that is the next-hop for the FEC being currently traced. If the operation type is PUSH, the remote peer address is the address of the peer from which the FEC being pushed was learned. If the operation type is POP, the remote peer address MAY be set to Unspecified. For upstream-assigned labels [RFC5331], an operation type of POP will have a remote peer address (the upstream node that assigned the label) and this SHOULD be included in the FEC stack change sub-TLV. The remote peer address MAY be set to Unspecified if the address needs to be hidden. FEC TLV The FEC TLV is present only when the FEC-tlv length field is non- zero. The FEC TLV specifies the FEC associated with the FEC stack change operation. This TLV MAY be included when the operation type is POP. It MUST be included when the operation type is PUSH. The FEC TLV contains exactly one FEC from the list of FECs specified in Section 3.2. A Nil FEC MAY be associated with a PUSH operation if the responding router wishes to hide the details of the FEC being pushed. FEC stack change sub-TLV operation rules are as follows: Kompella, et al. Expires May 1, 2017 [Page 36] Internet-Draft Detecting MPLS Data Plane Failures October 2016 a. A FEC stack change sub-TLV containing a PUSH operation MUST NOT be followed by a FEC stack change sub-TLV containing a POP operation. b. One or more POP operations MAY be followed by one or more PUSH operations. c. One FEC stack change sub-TLV MUST be included per FEC stack change. For example, if 2 labels are going to be pushed, then one FEC stack change sub-TLV MUST be included for each FEC. d. A FEC splice operation (an operation where one FEC ends and another FEC starts, MUST be performed by including a POP type FEC stack change sub-TLV followed by a PUSH type FEC stack change sub-TLV. e. A Downstream Detailed Mapping TLV containing only one FEC stack change sub-TLV with Pop operation is equivalent to IS_EGRESS (Return Code 3, Section 3.1) for the outermost FEC in the FEC stack. The ingress router performing the MPLS traceroute MUST treat such a case as an IS_EGRESS for the outermost FEC. 3.4.2. Downstream Router and Interface The notion of "downstream router" and "downstream interface" should be explained. Consider an LSR X. If a packet that was originated with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X must be able to compute which LSRs could receive the packet if it was originated with TTL=n+1, over which interface the request would arrive and what label stack those LSRs would see. (It is outside the scope of this document to specify how this computation is done.) The set of these LSRs/interfaces consists of the downstream routers/ interfaces (and their corresponding labels) for X with respect to L. Each pair of downstream router and interface requires a separate Downstream Detailed Mapping to be added to the reply. The case where X is the LSR originating the echo request is a special case. X needs to figure out what LSRs would receive the MPLS echo request for a given FEC Stack that X originates with TTL=1. The set of downstream routers at X may be alternative paths (see the discussion below on ECMP) or simultaneous paths (e.g., for MPLS multicast). In the former case, the Multipath Information is used as a hint to the sender as to how it may influence the choice of these alternatives. Kompella, et al. Expires May 1, 2017 [Page 37] Internet-Draft Detecting MPLS Data Plane Failures October 2016 3.5. Pad TLV The value part of the Pad TLV contains a variable number (>= 1) of octets. The first octet takes values from the following table; all the other octets (if any) are ignored. The receiver SHOULD verify that the TLV is received in its entirety, but otherwise ignores the contents of this TLV, apart from the first octet. Value Meaning ----- ------- 0 Reserved 1 Drop Pad TLV from reply 2 Copy Pad TLV to reply 3-250 Unassigned 251-254 Experimental Use 255 Reserved The Pad TLV can be added to an Echo Request to create a message of a specific length in cases where messages of various sizes are needed for troubleshooting. The first octet allows for controlling the inclusion of this additional padding in the respective Echo Reply. 3.6. Vendor Enterprise Number "Private Enterprise Numbers" [IANA-ENT] are maintained by IANA. The Length of this TLV is always 4; the value is the SMI Private Enterprise Code, in network octet order, of the vendor with a Vendor Private extension to any of the fields in the fixed part of the message, in which case this TLV MUST be present. If none of the fields in the fixed part of the message have Vendor Private extensions, inclusion of this TLV is OPTIONAL. Vendor Private ranges for Message Types, Reply Modes, and Return Codes have been defined. When any of these are used, the Vendor Enterprise Number TLV MUST be included in the message. 3.7. Interface and Label Stack The Interface and Label Stack TLV MAY be included in a reply message to report the interface on which the request message was received and the label stack that was on the packet when it was received. Only one such object may appear. The purpose of the object is to allow the upstream router to obtain the exact interface and label stack information as it appears at the replying LSR. The Length is K + 4*N octets; N is the number of labels in the label stack. Values for K are found in the description of Address Type below. The Value field of this TLV has the following format: Kompella, et al. Expires May 1, 2017 [Page 38] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . Label Stack . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Type The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the IP Address and Interface fields. The resulting total for the initial part of the TLV is listed in the table below as "K Octets". The Address Type is set to one of the following values: Type # Address Type K Octets ------ ------------ -------- 0 Reserved 4 1 IPv4 Numbered 12 2 IPv4 Unnumbered 12 3 IPv6 Numbered 36 4 IPv6 Unnumbered 24 5-250 Unassigned 251-254 Experimental Use 255 Reserved IP Address and Interface IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets. If the interface upon which the echo request message was received is numbered, then the Address Type MUST be set to IPv4 or IPv6, the IP Address MUST be set to either the LSR's Router ID or the interface address, and the Interface MUST be set to the interface address. Kompella, et al. Expires May 1, 2017 [Page 39] Internet-Draft Detecting MPLS Data Plane Failures October 2016 If the interface is unnumbered, the Address Type MUST be either IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the LSR's Router ID, and the Interface MUST be set to the index assigned to the interface. Label Stack The label stack of the received echo request message. If any TTL values have been changed by this router, they SHOULD be restored. 3.8. Errored TLVs The following TLV is a TLV that MAY be included in an echo reply to inform the sender of an echo request of mandatory TLVs either not supported by an implementation or parsed and found to be in error. The Value field contains the TLVs that were not understood, encoded as sub-TLVs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.9. Reply TOS Octet TLV This TLV MAY be used by the originator of the echo request to request that an echo reply be sent with the IP header TOS octet set to the value specified in the TLV. This TLV has a length of 4 with the following value field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply-TOS Byte| Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kompella, et al. Expires May 1, 2017 [Page 40] Internet-Draft Detecting MPLS Data Plane Failures October 2016 4. Theory of Operation An MPLS echo request is used to test a particular LSP. The LSP to be tested is identified by the "FEC Stack"; for example, if the LSP was set up via LDP, and is to an egress IP address of 198.51.100.1, the FEC Stack contains a single element, namely, an LDP IPv4 prefix sub- TLV with value 198.51.100.1/32. If the LSP being tested is an RSVP LSP, the FEC Stack consists of a single element that captures the RSVP Session and Sender Template that uniquely identifies the LSP. FEC Stacks can be more complex. For example, one may wish to test a VPN IPv4 prefix of 203.0.113.0/24 that is tunneled over an LDP LSP with egress 192.0.2.1. The FEC Stack would then contain two sub- TLVs, the bottom being a VPN IPv4 prefix, and the top being an LDP IPv4 prefix. If the underlying (LDP) tunnel were not known, or was considered irrelevant, the FEC Stack could be a single element with just the VPN IPv4 sub-TLV. When an MPLS echo request is received, the receiver is expected to verify that the control plane and data plane are both healthy (for the FEC Stack being pinged) and that the two planes are in sync. The procedures for this are in Section 4.4. 4.1. Dealing with Equal-Cost Multi-Path (ECMP) LSPs need not be simple point-to-point tunnels. Frequently, a single LSP may originate at several ingresses, and terminate at several egresses; this is very common with LDP LSPs. LSPs for a given FEC may also have multiple "next hops" at transit LSRs. At an ingress, there may also be several different LSPs to choose from to get to the desired endpoint. Finally, LSPs may have backup paths, detour paths, and other alternative paths to take should the primary LSP go down. To deal with the last two first: it is assumed that the LSR sourcing MPLS echo requests can force the echo request into any desired LSP, so choosing among multiple LSPs at the ingress is not an issue. The problem of probing the various flavors of backup paths that will typically not be used for forwarding data unless the primary LSP is down will not be addressed here. Since the actual LSP and path that a given packet may take may not be known a priori, it is useful if MPLS echo requests can exercise all possible paths. This, although desirable, may not be practical, because the algorithms that a given LSR uses to distribute packets over alternative paths may be proprietary. To achieve some degree of coverage of alternate paths, there is a certain latitude in choosing the destination IP address and source Kompella, et al. Expires May 1, 2017 [Page 41] Internet-Draft Detecting MPLS Data Plane Failures October 2016 UDP port for an MPLS echo request. This is clearly not sufficient; in the case of traceroute, more latitude is offered by means of the Multipath Information of the Downstream Detailed Mapping TLV. This is used as follows. An ingress LSR periodically sends an MPLS traceroute message to determine whether there are multipaths for a given LSP. If so, each hop will provide some information as to how each of its downstream paths can be exercised. The ingress can then send MPLS echo requests that exercise these paths. If several transit LSRs have ECMP, the ingress may attempt to compose these to exercise all possible paths. However, full coverage may not be possible. 4.2. Testing LSPs That Are Used to Carry MPLS Payloads To detect certain LSP breakages, it may be necessary to encapsulate an MPLS echo request packet with at least one additional label when testing LSPs that are used to carry MPLS payloads (such as LSPs used to carry L2VPN and L3VPN traffic. For example, when testing LDP or RSVP-TE LSPs, just sending an MPLS echo request packet may not detect instances where the router immediately upstream of the destination of the LSP ping may forward the MPLS echo request successfully over an interface not configured to carry MPLS payloads because of the use of penultimate hop popping. Since the receiving router has no means to ascertain whether the IP packet was sent unlabeled or implicitly labeled, the addition of labels shimmed above the MPLS echo request (using the Nil FEC) will prevent a router from forwarding such a packet out unlabeled interfaces. 4.3. Sending an MPLS Echo Request An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:7F00:0/104. The IP TTL is set to 1. The source UDP port is chosen by the sender; the destination UDP port is set to 3503 (assigned by IANA for MPLS echo requests). The Router Alert IP option of value 0x0 [RFC2113] for IPv4 or value 69 [RFC7506] for IPv6 MUST be set in the IP header. An MPLS echo request is sent with a label stack corresponding to the FEC Stack being tested. Note that further labels could be applied if, for example, the normal route to the topmost FEC in the stack is via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the stack correspond to Implicit Null labels, the MPLS echo request is considered unlabeled even if further labels will be applied in sending the packet. Kompella, et al. Expires May 1, 2017 [Page 42] Internet-Draft Detecting MPLS Data Plane Failures October 2016 If the echo request is labeled, one MAY (depending on what is being pinged) set the TTL of the innermost label to 1, to prevent the ping request going farther than it should. Examples of where this SHOULD be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN endpoint or a pseudowire. Preventing the ping request from going too far can also be accomplished by inserting a Router Alert label above this label; however, this may lead to the undesired side effect that MPLS echo requests take a different data path than actual data. For more information on how these mechanisms can be used for pseudowire connectivity verification, see [RFC5085]. In "ping" mode (end-to-end connectivity check), the TTL in the outermost label is set to 255. In "traceroute" mode (fault isolation mode), the TTL is set successively to 1, 2, and so on. The sender chooses a Sender's Handle and a Sequence Number. When sending subsequent MPLS echo requests, the sender SHOULD increment the Sequence Number by 1. However, a sender MAY choose to send a group of echo requests with the same Sequence Number to improve the chance of arrival of at least one packet with that Sequence Number. The TimeStamp Sent is set to the time-of-day in NTP format that the echo request is sent. The TimeStamp Received is set to zero. An MPLS echo request MUST have an FEC Stack TLV. Also, the Reply Mode must be set to the desired reply mode; the Return Code and Subcode are set to zero. In the "traceroute" mode, the echo request SHOULD include a Downstream Detailed Mapping TLV. 4.4. Receiving an MPLS Echo Request Sending an MPLS echo request to the control plane is triggered by one of the following packet processing exceptions: Router Alert option, IP TTL expiration, MPLS TTL expiration, MPLS Router Alert label, or the destination address in the 127/8 address range. The control plane further identifies it by UDP destination port 3503. For reporting purposes the bottom of stack is considered to be stack- depth of 1. This is to establish an absolute reference for the case where the actual stack may have more labels than there are FECs in the Target FEC Stack. Furthermore, in all the error codes listed in this document, a stack- depth of 0 means "no value specified". This allows compatibility with existing implementations that do not use the Return Subcode field. Kompella, et al. Expires May 1, 2017 [Page 43] Internet-Draft Detecting MPLS Data Plane Failures October 2016 An LSR X that receives an MPLS echo request then processes it as follows. 1. General packet sanity is verified. If the packet is not well- formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set to "Malformed echo request received" and the Subcode to zero. If there are any TLVs not marked as "Ignore" (i.e., if the TLV type is less than 32768, see Section 3) that LSR X does not understand, LSR X SHOULD send an MPLS "TLV not understood" (as appropriate), and the Subcode set to zero. In the latter case, the misunderstood TLVs (only) are included as sub-TLVs in an Errored TLVs TLV in the reply. The header fields Sender's Handle, Sequence Number, and Timestamp Sent are not examined, but are included in the MPLS echo reply message. The algorithm uses the following variables and identifiers: Interface-I: the interface on which the MPLS echo request was received. Stack-R: the label stack on the packet as it was received. Stack-D: the label stack carried in the "Label Stack sub- TLV" in Downstream Detailed Mapping TLV (not always present) Label-L: the label from the actual stack currently being examined. Requires no initialization. Label-stack-depth: the depth of label being verified. Initialized to the number of labels in the received label stack S. FEC-stack-depth: depth of the FEC in the Target FEC Stack that should be used to verify the current actual label. Requires no initialization. Best-return-code: contains the return code for the echo reply packet as currently best known. As the algorithm progresses, this code may change depending on the results of further checks that it performs. Best-rtn-subcode: similar to Best-return-code, but for the Echo Reply Subcode. FEC-status: result value returned by the FEC Checking algorithm described in Section 4.4.1. Kompella, et al. Expires May 1, 2017 [Page 44] Internet-Draft Detecting MPLS Data Plane Failures October 2016 /* Save receive context information */ 2. If the echo request is good, LSR X stores the interface over which the echo was received in Interface-I, and the label stack with which it came in Stack-R. /* The rest of the algorithm iterates over the labels in Stack-R, verifies validity of label values, reports associated label switching operations (for traceroute), verifies correspondence between the Stack-R and the Target FEC Stack description in the body of the echo request, and reports any errors. */ /* The algorithm iterates as follows. */ 3. Label Validation: If Label-stack-depth is 0 { /* The LSR needs to report its being a tail-end for the LSP */ Set FEC-stack-depth to 1, set Label-L to 3 (Implicit Null). Set Best-return-code to 3 ("Replying router is an egress for the FEC at stack depth"), set Best-rtn-subcode to the value of FEC-stack-depth (1) and go to step 5 (Egress Processing). } /* This step assumes there is always an entry for well-known label values */ Set Label-L to the value extracted from Stack-R at depth Label- stack-depth. Look up Label-L in the Incoming Label Map (ILM) to determine if the label has been allocated and an operation is associated with it. If there is no entry for Label-L { /* Indicates a temporary or permanent label synchronization problem the LSR needs to report an error */ Set Best-return-code to 11 ("No label entry at stack-depth") and Best-rtn-subcode to Label-stack-depth. Go to step 7 (Send Reply Packet). } Else { Kompella, et al. Expires May 1, 2017 [Page 45] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Retrieve the associated label operation from the corresponding NHLFE and proceed to step 4 (Label Operation check). } 4. Label Operation Check If the label operation is "Pop and Continue Processing" { /* Includes Explicit Null and Router Alert label cases */ Iterate to the next label by decrementing Label-stack-depth and loop back to step 3 (Label Validation). } If the label operation is "Swap or Pop and Switch based on Popped Label" { Set Best-return-code to 8 ("Label switched at stack-depth") and Best-rtn-subcode to Label-stack-depth to report transit switching. If a Downstream Detailed Mapping TLV is present in the received echo request { If the IP address in the TLV is 127.0.0.1 or 0::1 { Set Best-return-code to 6 ("Upstream Interface Index Unknown"). An Interface and Label Stack TLV SHOULD be included in the reply and filled with Interface-I and Stack-R. } Else { Verify that the IP address, interface address, and label stack in the Downstream Detailed Mapping TLV match Interface-I and Stack-R. If there is a mismatch, set Best-return-code to 5, "Downstream Mapping Mismatch". An Interface and Label Stack TLV SHOULD be included in the reply and filled in based on Interface-I and Stack-R. Go to step 7 (Send Reply Packet). } } Kompella, et al. Expires May 1, 2017 [Page 46] Internet-Draft Detecting MPLS Data Plane Failures October 2016 For each available downstream ECMP path { Retrieve output interface from the NHLFE entry. /* Note: this return code is set even if Label-stack-depth is one */ If the output interface is not MPLS enabled { Set Best-return-code to Return Code 9, "Label switched but no MPLS forwarding at stack-depth" and set Best-rtn- subcode to Label-stack-depth and go to step 7 (Send Reply Packet). } If a Downstream Detailed Mapping TLV is present { A Downstream Detailed Mapping TLV SHOULD be included in the echo reply (see Section 3.4) filled in with information about the current ECMP path. } } If no Downstream Detailed Mapping TLV is present, or the Downstream IP Address is set to the ALLROUTERS multicast address, go to step 7 (Send Reply Packet). If the "Validate FEC Stack" flag is not set and the LSR is not configured to perform FEC checking by default, go to step 7 (Send Reply Packet). /* Validate the Target FEC Stack in the received echo request. First determine FEC-stack-depth from the Downstream Detailed Mapping TLV. This is done by walking through Stack-D (the Downstream labels) from the bottom, decrementing the number of labels for each non-Implicit Null label, while incrementing FEC-stack-depth for each label. If the Downstream Detailed Mapping TLV contains one or more Implicit Null labels, FEC- stack-depth may be greater than Label-stack-depth. To be consistent with the above stack-depths, the bottom is considered to be entry 1. */ Set FEC-stack-depth to 0. Set i to Label-stack-depth. Kompella, et al. Expires May 1, 2017 [Page 47] Internet-Draft Detecting MPLS Data Plane Failures October 2016 While (i > 0) do { ++FEC-stack-depth. if Stack-D [ FEC-stack-depth ] != 3 (Implicit Null) --i. } If the number of FECs in the FEC stack is greater than or equal to FEC-stack-depth { Perform the FEC Checking procedure (see Section 4.4.1). If FEC-status is 2, set Best-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"). If the return code is 1, set Best-return-code to FEC-return- code and Best-rtn-subcode to FEC-stack-depth. } Go to step 7 (Send Reply Packet). } 5. Egress Processing: /* These steps are performed by the LSR that identified itself as the tail-end LSR for an LSP. */ If received echo request contains no Downstream Detailed Mapping TLV, or the Downstream IP Address is set to 127.0.0.1 or 0::1 go to step 6 (Egress FEC Validation). Verify that the IP address, interface address, and label stack in the Downstream Detailed Mapping TLV match Interface-I and Stack-R. If not, set Best-return-code to 5, "Downstream Mapping Mis-match". A Received Interface and Label Stack TLV SHOULD be created for the echo response packet. Go to step 7 (Send Reply Packet). 6. Egress FEC Validation: /* This is a loop for all entries in the Target FEC Stack starting with FEC-stack-depth. */ Perform FEC checking by following the algorithm described in Section 4.4.1 for Label-L and the FEC at FEC-stack-depth. Set Best-return-code to FEC-code and Best-rtn-subcode to the value in FEC-stack-depth. Kompella, et al. Expires May 1, 2017 [Page 48] Internet-Draft Detecting MPLS Data Plane Failures October 2016 If FEC-status (the result of the check) is 1, go to step 7 (Send Reply Packet). /* Iterate to the next FEC entry */ ++FEC-stack-depth. If FEC-stack-depth > the number of FECs in the FEC-stack, go to step 7 (Send Reply Packet). If FEC-status is 0 { ++Label-stack-depth. If Label-stack-depth > the number of labels in Stack-R, Go to step 7 (Send Reply Packet). Label-L = extracted label from Stack-R at depth Label-stack-depth. Loop back to step 6 (Egress FEC Validation). } 7. Send Reply Packet: Send an MPLS echo reply with a Return Code of Best-return-code, and a Return Subcode of Best-rtn-subcode. Include any TLVs created during the above process. The procedures for sending the echo reply are found in Section 4.5. 4.4.1. FEC Validation /* This section describes validation of an FEC entry within the Target FEC Stack and accepts an FEC, Label-L, and Interface-I. If the outermost FEC of the target FEC stack is the Nil FEC, then the node MUST skip the target FEC validation completely. This is to support FEC hiding, in which the outer hidden FEC can be the Nil FEC. Else, the algorithm performs the following steps. */ 1. Two return values, FEC-status and FEC-return-code, are initialized to 0. 2. If the FEC is the Nil FEC { If Label-L is either Explicit_Null or Router_Alert, return. Else { Kompella, et al. Expires May 1, 2017 [Page 49] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Set FEC-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"). Set FEC-status to 1 Return. } } 3. Check the FEC label mapping that describes how traffic received on the LSP is further switched or which application it is associated with. If no mapping exists, set FEC-return-code to Return 4, "Replying router has no mapping for the FEC at stack- depth". Set FEC-status to 1. Return. 4. If the label mapping for FEC is Implicit Null, set FEC-status to 2 and proceed to step 5. Otherwise, if the label mapping for FEC is Label-L, proceed to step 5. Otherwise, set FEC-return-code to 10 ("Mapping for this FEC is not the given label at stack- depth"), set FEC-status to 1, and return. 5. This is a protocol check. Check what protocol would be used to advertise the FEC. If it can be determined that no protocol associated with Interface-I would have advertised an FEC of that FEC-Type, set FEC-return-code to 12 ("Protocol not associated with interface at FEC stack-depth"). Set FEC-status to 1. 6. Return. 4.5. Sending an MPLS Echo Reply An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response to an MPLS echo request. The source IP address is a routable address of the replier; the source port is the well-known UDP port for LSP ping. The destination IP address and UDP port are copied from the source IP address and UDP port of the echo request. The IP TTL is set to 255. If the Reply Mode in the echo request is "Reply via an IPv4 UDP packet with Router Alert", then the IP header MUST contain the Router Alert IP option of value 0x0 [RFC2113] for IPv4 or 69 [RFC7506] for IPv6. If the reply is sent over an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [RFC3032]). The format of the echo reply is the same as the echo request. The Sender's Handle, the Sequence Number, and TimeStamp Sent are copied from the echo request; the TimeStamp Received is set to the time-of- day that the echo request is received (note that this information is most useful if the time-of-day clocks on the requester and the Kompella, et al. Expires May 1, 2017 [Page 50] Internet-Draft Detecting MPLS Data Plane Failures October 2016 replier are synchronized). The FEC Stack TLV from the echo request MAY be copied to the reply. The replier MUST fill in the Return Code and Subcode, as determined in the previous section. If the echo request contains a Pad TLV, the replier MUST interpret the first octet for instructions regarding how to reply. If the replying router is the destination of the FEC, then Downstream Detailed Mapping TLVs SHOULD NOT be included in the echo reply. If the echo request contains a Downstream Detailed Mapping TLV, and the replying router is not the destination of the FEC, the replier SHOULD compute its downstream routers and corresponding labels for the incoming label, and add Downstream Detailed Mapping TLVs for each one to the echo reply it sends back. A replying node should follow the procedures defined in Section 4.5.1 if there is an FEC stack change due to tunneled LSP. If the FEC stack change is due to stitched LSP, it should follow the procedures defined in Section 4.5.2. If the Downstream Detailed Mapping TLV contains Multipath Information requiring more processing than the receiving router is willing to perform, the responding router MAY choose to respond with only a subset of multipaths contained in the echo request Downstream Detailed Mapping. (Note: The originator of the echo request MAY send another echo request with the Multipath Information that was not included in the reply.) Except in the case of Reply Mode 4, "Reply via application level control channel", echo replies are always sent in the context of the IP/MPLS network. 4.5.1. Addition of a New Tunnel A transit node knows when the FEC being traced is going to enter a tunnel at that node. Thus, it knows about the new outer FEC. All transit nodes that are the origination point of a new tunnel SHOULD add the FEC stack change sub-TLV (Section 3.4.1.3) to the Downstream Detailed Mapping TLV in the echo reply. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node. A transit node that sends a Downstream FEC stack change sub-TLV in the echo reply SHOULD fill the address of the remote peer; which is the peer of the current LSP being traced. If the transit node does Kompella, et al. Expires May 1, 2017 [Page 51] Internet-Draft Detecting MPLS Data Plane Failures October 2016 not know the address of the remote peer, it MUST set the address type to Unspecified. The Label stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label MUST be encoded as defined in Section 3.4.1.2. The label value MUST be the value used to switch the data traffic. If the tunnel is a transparent pipe to the node, i.e., the data-plane trace will not expire in the middle of the new tunnel, then a FEC stack change sub-TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT contain a label corresponding to the hidden tunnel. If the transit node wishes to hide the nature of the tunnel from the ingress of the echo request, then it MAY not want to send details about the new tunnel FEC to the ingress. In such a case, the transit node SHOULD use the Nil FEC. The echo reply would then contain a FEC stack change sub-TLV with operation type PUSH and a Nil FEC. The value of the label in the Nil FEC MUST be set to zero. The remote peer address type MUST be set to Unspecified. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node. The Label stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label value MUST be the value used to switch the data traffic. 4.5.2. Transition between Tunnels A transit node stitching two LSPs SHOULD include two FEC stack change sub-TLVs. One with a POP operation for the old FEC (ingress) and one with the PUSH operation for the new FEC (egress). The replying node SHOULD set the Return Code to "Label switched with FEC change" to indicate change in FEC being traced. If the replying node wishes to perform FEC hiding, it SHOULD respond back with two FEC stack change sub-TLVs, one POP followed by one PUSH. The POP operation MAY either exclude the FEC TLV (by setting the FEC TLV length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation SHOULD have the FEC TLV containing the Nil FEC. The Return Code SHOULD be set to "Label switched with FEC change". If the replying node wishes to perform FEC hiding, it MAY choose to not send any FEC stack change sub-TLVs in the echo reply if the number of labels does not change for the downstream node and the FEC type also does not change (Nil FEC). In such case, the replying node MUST NOT set the Return Code to "Label switched with FEC change". Kompella, et al. Expires May 1, 2017 [Page 52] Internet-Draft Detecting MPLS Data Plane Failures October 2016 4.6. Receiving an MPLS Echo Reply An LSR X should only receive an MPLS echo reply in response to an MPLS echo request that it sent. Thus, on receipt of an MPLS echo reply, X should parse the packet to ensure that it is well-formed, then attempt to match up the echo reply with an echo request that it had previously sent, using the destination UDP port and the Sender's Handle. If no match is found, then X jettisons the echo reply; otherwise, it checks the Sequence Number to see if it matches. If the echo reply contains Downstream Detailed Mappings, and X wishes to traceroute further, it SHOULD copy the Downstream Detailed Mapping(s) into its next echo request(s) (with TTL incremented by one). If one or more FEC stack change sub-TLVs are received in the MPLS echo reply, the ingress node SHOULD process them and perform some validation. The FEC stack changes are associated with a downstream neighbor and along a particular path of the LSP. Consequently, the ingress will need to maintain a FEC stack per path being traced (in case of multipath). All changes to the FEC stack resulting from the processing of FEC stack change sub-TLV(s) should be applied only for the path along a given downstream neighbor. The following algorithm should be followed for processing FEC stack change sub-TLVs. Kompella, et al. Expires May 1, 2017 [Page 53] Internet-Draft Detecting MPLS Data Plane Failures October 2016 push_seen = FALSE fec_stack_depth = current-depth-of-fec-stack-being-traced saved_fec_stack = current_fec_stack while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) if (sub-tlv == NULL) break if (sub-tlv.type == FEC-Stack-Change) { if (sub-tlv.operation == POP) { if (push_seen) { Drop the echo reply current_fec_stack = saved_fec_stack return } if (fec_stack_depth == 0) { Drop the echo reply current_fec_stack = saved_fec_stack return } Pop FEC from FEC stack being traced fec_stack_depth--; } if (sub-tlv.operation == PUSH) { push_seen = 1 Push FEC on FEC stack being traced fec_stack_depth++; } } } if (fec_stack_depth == 0) { Drop the echo reply current_fec_stack = saved_fec_stack return } The next MPLS echo request along the same path should use the modified FEC stack obtained after processing the FEC stack change sub-TLVs. A non-Nil FEC guarantees that the next echo request along the same path will have the Downstream Detailed Mapping TLV validated for IP address, Interface address, and label stack mismatches. Kompella, et al. Expires May 1, 2017 [Page 54] Internet-Draft Detecting MPLS Data Plane Failures October 2016 If the top of the FEC stack is a Nil FEC and the MPLS echo reply does not contain any FEC stack change sub-TLVs, then it does not necessarily mean that the LSP has not started traversing a different tunnel. It could be that the LSP associated with the Nil FEC terminated at a transit node and at the same time a new LSP started at the same transit node. The Nil FEC would now be associated with the new LSP (and the ingress has no way of knowing this). Thus, it is not possible to build an accurate hierarchical LSP topology if a traceroute contains Nil FECs. A reply from a downstream node with Return Code 3, may not necessarily be for the FEC being traced. It could be for one of the new FECs that was added. On receipt of an IS_EGRESS reply, the LSP ingress should check if the depth of Target FEC sent to the node that just responded, was the same as the depth of the FEC that was being traced. If it was not, then it should pop an entry from the Target FEC stack and resend the request with the same TTL (as previously sent). The process of popping a FEC is to be repeated until either the LSP ingress receives a non-IS_EGRESS reply or until all the additional FECs added to the FEC stack have already been popped. Using an IS_EGRESS reply, an ingress can build a map of the hierarchical LSP structure traversed by a given FEC. When the MPLS echo reply Return Code is "Label switched with FEC change", the ingress node SHOULD manipulate the FEC stack as per the FEC stack change sub-TLVs contained in the Downstream Detailed Mapping TLV. A transit node can use this Return Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP, there could be multiple paths and Downstream Detailed Mapping TLVs with different Return Codes (see Section 3.1, Note 2). The ingress node should build the topology based on the Return Code per ECMP path/P2MP branch. 4.7. Issue with VPN IPv4 and IPv6 Prefixes Typically, an LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is sent with a label stack of depth greater than 1, with the innermost label having a TTL of 1. This is to terminate the ping at the egress PE, before it gets sent to the customer device. However, under certain circumstances, the label stack can shrink to a single label before the ping hits the egress PE; this will result in the ping terminating prematurely. One such scenario is a multi-AS Carrier's Carrier VPN. To get around this problem, one approach is for the LSR that receives such a ping to realize that the ping terminated prematurely, and send back error code 13. In that case, the initiating LSR can retry the ping after incrementing the TTL on the VPN label. In this fashion, Kompella, et al. Expires May 1, 2017 [Page 55] Internet-Draft Detecting MPLS Data Plane Failures October 2016 the ingress LSR will sequentially try TTL values until it finds one that allows the VPN ping to reach the egress PE. 4.8. Non-compliant Routers If the egress for the FEC Stack being pinged does not support MPLS ping, then no reply will be sent, resulting in possible "false negatives". If in "traceroute" mode, a transit LSR does not support LSP ping, then no reply will be forthcoming from that LSR for some TTL, say, n. The LSR originating the echo request SHOULD try sending the echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further down the path. In such a case, the echo request for TTL > n SHOULD be sent with Downstream Detailed Mapping TLV "Downstream IP Address" field set to the ALLROUTERs multicast address until a reply is received with a Downstream Detailed Mapping TLV. The label stack TLV MAY be omitted from the Downstream Detailed Mapping TLV. Furthermore, the "Validate FEC Stack" flag SHOULD NOT be set until an echo reply packet with a Downstream Detailed Mapping TLV is received. 5. Security Considerations Overall, the security needs for LSP ping are similar to those of ICMP ping. There are at least three approaches to attacking LSRs using the mechanisms defined here. One is a Denial-of-Service attack, by sending MPLS echo requests/replies to LSRs and thereby increasing their workload. The second is obfuscating the state of the MPLS data plane liveness by spoofing, hijacking, replaying, or otherwise tampering with MPLS echo requests and replies. The third is an unauthorized source using an LSP ping to obtain information about the network. To avoid potential Denial-of-Service attacks, it is RECOMMENDED that implementations regulate the LSP ping traffic going to the control plane. A rate limiter SHOULD be applied to the well-known UDP port defined in Section 6.1. Unsophisticated replay and spoofing attacks involving faking or replaying MPLS echo reply messages are unlikely to be effective. These replies would have to match the Sender's Handle and Sequence Number of an outstanding MPLS echo request message. A non-matching replay would be discarded as the sequence has moved on, thus a spoof has only a small window of opportunity. However, to provide a stronger defense, an implementation MAY also validate the TimeStamp Sent by requiring an exact match on this field. Kompella, et al. Expires May 1, 2017 [Page 56] Internet-Draft Detecting MPLS Data Plane Failures October 2016 To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message. It is not clear how to prevent hijacking (non-delivery) of echo requests or replies; however, if these messages are indeed hijacked, LSP ping will report that the data plane is not working as it should. It does not seem vital (at this point) to secure the data carried in MPLS echo requests and replies, although knowledge of the state of the MPLS data plane may be considered confidential by some. Implementations SHOULD, however, provide a means of filtering the addresses to which echo reply messages may be sent. The value part of the Pad TLV contains a variable number of octets. With the exception of the first octet, these contents, if any, are ignored on receipt, and can therefore serve as a clandestine channel. When MPLS LSP Ping is used within an administrative domain, a deployment can increase security by using border filtering of incoming LSP Ping packets as well as outgoing LSP Ping packets. Although this document makes special use of 127/8 address, these are used only in conjunction with the UDP port 3503. Furthermore, these packets are only processed by routers. All other hosts MUST treat all packets with a destination address in the range 127/8 in accordance to RFC 1122. Any packet received by a router with a destination address in the range 127/8 without a destination UDP port of 3503 MUST be treated in accordance to RFC 1812. In particular, the default behavior is to treat packets destined to a 127/8 address as "martians". If a network operator wants to prevent tracing inside a tunnel, one can use the Pipe Model [RFC3443], i.e., hide the outer MPLS tunnel by not propagating the MPLS TTL into the outer tunnel (at the start of the outer tunnel). By doing this, MPLS traceroute packets will not expire in the outer tunnel and the outer tunnel will not get traced. If one doesn't wish to expose the details of the new outer LSP, then the Nil FEC can be used to hide those details. Using the Nil FEC ensures that the trace progresses without false negatives and all transit nodes (of the new outer tunnel) perform some minimal validations on the received MPLS echo requests. Kompella, et al. Expires May 1, 2017 [Page 57] Internet-Draft Detecting MPLS Data Plane Failures October 2016 6. IANA Considerations 6.1. TCP and UDP Port Number The TCP and UDP port number 3503 has been allocated by IANA for LSP echo requests and replies. 6.2. MPLS LSP Ping Parameters IANA maintains all the registries within the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" at [IANA-MPLS-LSP-PING]. The following subsections detail the name spaces managed by IANA. For some of these name spaces, the space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values: "Standards Action" (as defined in [RFC5226]), "Specification Required", and "Vendor Private Use". Values from "Specification Required" ranges MUST be registered with IANA. The request MUST be made via an Experimental RFC that describes the format and procedures for using the code point; the actual assignment is made during the IANA actions for the RFC. Values from "Vendor Private" ranges MUST NOT be registered with IANA; however, the message MUST contain an enterprise code as registered with the IANA SMI Private Network Management Private Enterprise Numbers. For each name space that has a Vendor Private range, it must be specified where exactly the SMI Private Enterprise Number resides; see below for examples. In this way, several enterprises (vendors) can use the same code point without fear of collision. 6.2.1. Message Types, Reply Modes, Return Codes The IANA has created and will maintain registries for Message Types, Reply Modes, and Return Codes. Each of these can take values in the range 0-255. Assignments in the range 0-191 are via Standards Action; assignments in the range 192-251 are made via "Specification Required"; values in the range 252-255 are for Vendor Private Use, and MUST NOT be allocated. If any of these fields fall in the Vendor Private range, a top-level Vendor Enterprise Number TLV MUST be present in the message. Message Types defined in this document are the following: Kompella, et al. Expires May 1, 2017 [Page 58] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Value Meaning ----- ------- 1 MPLS echo request 2 MPLS echo reply Reply Modes defined in this document are the following: Value Meaning ----- ------- 1 Do not reply 2 Reply via an IPv4/IPv6 UDP packet 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 4 Reply via application level control channel Return Codes defined in this document are listed in Section 3.1. IANA is requested to update the Reference to all these values to point to this document. 6.2.2. TLVs The IANA has created and maintains a registry for the Type field of top-level TLVs as well as for any associated sub-TLVs. Note the meaning of a sub-TLV is scoped by the TLV. The number spaces for the sub-TLVs of various TLVs are independent. The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in [RFC5226]; assignments in the range 16384-31743 and 49162-64511 are made via "Specification Required" as defined above; values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. If a TLV or sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Private Enterprise Number, in network octet order. The rest of the Value field is private to the vendor. TLVs and sub-TLVs defined in this document are the following: Kompella, et al. Expires May 1, 2017 [Page 59] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Type Sub-Type Value Field ---- -------- ----------- 1 Target FEC Stack 1 LDP IPv4 prefix 2 LDP IPv6 prefix 3 RSVP IPv4 LSP 4 RSVP IPv6 LSP 5 Unassigned 6 VPN IPv4 prefix 7 VPN IPv6 prefix 8 L2 VPN endpoint 9 "FEC 128" Pseudowire - IPv4 (Deprecated) 10 "FEC 128" Pseudowire - IPv4 11 "FEC 129" Pseudowire - IPv4 12 BGP labeled IPv4 prefix 13 BGP labeled IPv6 prefix 14 Generic IPv4 prefix 15 Generic IPv6 prefix 16 Nil FEC 24 "FEC 128" Pseudowire - IPv6 25 "FEC 129" Pseudowire - IPv6 2 Downstream Mapping (Deprecated) 3 Pad 4 Unassigned 5 Vendor Enterprise Number 6 Unassigned 7 Interface and Label Stack 8 Unassigned 9 Errored TLVs Any value The TLV not understood 10 Reply TOS Byte 20 Downstream Detailed Mapping IANA is requested to update the Reference to all these values to point to this document. 6.2.3. Global Flags IANA has created a sub-registry of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. The sub-registry is called the "Global Flags" registry. This registry tracks the assignment of 16 flags in the Global Flags field of the MPLS LSP ping echo request message. The flags are numbered from 0 (most significant bit, transmitted first) to 15. New entries are assigned by Standards Action. Kompella, et al. Expires May 1, 2017 [Page 60] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Initial entries in the registry are as follows: Bit number | Name | Reference ------------+----------------------------+-------------- 15 | V Flag | This Document 14 | T Flag | [RFC6425] 13 | R Flag | [RFC6426] 12-0 | Unassigned | This Document 6.2.4. Downstream Detailed Mapping Address Type This document extends RFC 4379 by defining a new address type for use with the Downstream Mapping and Downstream Detailed Mapping TLVs. IANA has established a registry to assign address types for use with the Downstream Mapping and Downstream Detailed Mapping TLVs, initially allocates the following assignments: Type # Address Type K Octets Reference ------ ------------ -------- ------------------------- 1 IPv4 Numbered 16 This document 2 IPv4 Unnumbered 16 This document 3 IPv6 Numbered 40 This document 4 IPv6 Unnumbered 28 This document 5 Non IP 12 RFC 6426 Downstream Mapping Address Type Registry Because the field in this case is an 8-bit field, the allocation policy for this registry is "Standards Action." 6.2.5. DS Flags This document defines the Downstream Mapping (DSMAP) TLV and the Downstream Detailed Mapping (DDMAP) TLV, which have Type 2 and Type 20 respectively assigned from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry. DSMAP has been deprecated by DDMAP, but both TLVs share a field: DS Flags. IANA has created and now maintains a registry entitled "DS Flags". The registration policy for this registry is Standards Action [RFC5226]. IANA has made the following initial assignments: Kompella, et al. Expires May 1, 2017 [Page 61] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Registry Name: DS Flags Bit number Name Reference ---------- ---------------------------------------- --------- 7 N: Treat as a Non-IP Packet This RFC 6 I: Interface and Label Stack Object Request This RFC 5-0 Unassigned 6.2.6. Multipath Types IANA has created and now maintains a registry entitled "Multipath Types". The registration policies [RFC5226] for this registry are as follows: 0-250 Standards Action 251-254 Experimental Use 255 Standards Action IANA has made the following initial assignments: Registry Name: Multipath Types Value Meaning Reference ---------- ---------------------------------------- --------- 0 no multipath This document 1 Unassigned 2 IP address This document 3 Unassigned 4 IP address range This document 5-7 Unassigned 8 Bit-masked IP address set This document 9 Bit-masked label set This document 10-250 Unassigned 251-254 Experimental Use This document 255 Reserved This document 6.2.7. Pad Type IANA has created and now maintain a registry entitled "Pad Types". The registration policies [RFC5226] for this registry are: Kompella, et al. Expires May 1, 2017 [Page 62] Internet-Draft Detecting MPLS Data Plane Failures October 2016 0-250 Standards Action 251-254 Experimental Use 255 Standards Action IANA has made the following initial assignments: Registry Name: Pad Types Value Meaning Reference ---------- ---------------------------------------- --------- 0 Reserved This document 1 Drop Pad TLV from reply This document 2 Copy Pad TLV to reply This document 3-250 Unassigned 251-254 Experimental Use This document 255 Reserved This document 6.2.8. Interface and Label Stack Address Type IANA has created and now maintains a registry entitled "Interface and Label Stack Address Types". The registration policies [RFC5226] for this registry are: 0-250 Standards Action 251-254 Experimental Use 255 Standards Action IANA has made the following initial assignments: Registry Name: Interface and Label Stack Address Types Value Meaning Reference ---------- ---------------------------------------- --------- 0 Reserved This document 1 IPv4 Numbered This document 2 IPv4 Unnumbered This document 3 IPv6 Numbered This document 4 IPv6 Unnumbered This document 5-250 Unassigned 251-254 Experimental Use This document 255 Reserved This document Kompella, et al. Expires May 1, 2017 [Page 63] Internet-Draft Detecting MPLS Data Plane Failures October 2016 6.3. IPv4 Special-Purpose Address Registry IANA is requested to update the reference in Note 1 of the IANA IPv4 Special-Purpose Address Registry [IANA-SPECIAL-IPv4] to point to this document. 7. Acknowledgements The original acknowledgements from RFC 4379 state the following: This document is the outcome of many discussions among many people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal, and Vanson Lim. The description of the Multipath Information sub-field of the Downstream Mapping TLV was adapted from text suggested by Curtis Villamizar. We would like to thank Loa Andersson for motivating the advancement of this bis specification. We also would like to thank Alexander Vainshtein, Yimin Shen, Curtis Villamizar, David Allan, Vincent Roca, Mirja Kuhlewind, and Elwyn Davies for their review and useful comments. 8. References 8.1. Normative References [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Kompella, et al. Expires May 1, 2017 [Page 64] Internet-Draft Detecting MPLS Data Plane Failures October 2016 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, . [RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April 2015, . 8.2. Informative References [IANA-ENT] Internet Assigned Numbers Authority (IANA), "PRIVATE ENTERPRISE NUMBERS", . [IANA-MPLS-LSP-PING] Internet Assigned Numbers Authority (IANA), "Multi- Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", . Kompella, et al. Expires May 1, 2017 [Page 65] Internet-Draft Detecting MPLS Data Plane Failures October 2016 [IANA-SPECIAL-IPv4] Internet Assigned Numbers Authority (IANA), "IANA IPv4 Special-Purpose Address Registry", . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/RFC4365, February 2006, . [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, DOI 10.17487/RFC4447, April 2006, . [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, . Kompella, et al. Expires May 1, 2017 [Page 66] Internet-Draft Detecting MPLS Data Plane Failures October 2016 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, . [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, . [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, . [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, . [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, DOI 10.17487/RFC6426, November 2011, . [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, DOI 10.17487/RFC6829, January 2013, . [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and S. Aldrin, "IANA Registries for LSP Ping Code Points", RFC 7537, DOI 10.17487/RFC7537, May 2015, . Kompella, et al. Expires May 1, 2017 [Page 67] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Appendix A. Deprecated TLVs and sub-TLVs (Non-normative) This appendix describes deprecated elements, which are non-normative for an implementation. They are included in this document for historical and informational purposes. A.1. Target FEC Stack A.1.1. FEC 128 Pseudowire - IPv4 (Deprecated) FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed encapsulation type with the high-order bit set to zero. Both of these fields are treated in this protocol as opaque values. When an FEC 128 is encoded in a label stack, the following format is used. The value field consists of the Remote PE IPv4 Address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This FEC is deprecated and is retained only for backward compatibility. Implementations of LSP ping SHOULD accept and process this TLV, but SHOULD send LSP ping echo requests with the new TLV (see Section 3.2.9), unless explicitly configured to use the old TLV. An LSR receiving this TLV SHOULD use the source IP address of the LSP echo request to infer the sender's PE address. A.2. Downstream Mapping (Deprecated) The Downstream Mapping object is a TLV that MAY be included in an echo request message. Only one Downstream Mapping object may appear in an echo request. The presence of a Downstream Mapping object is a request that Downstream Mapping objects be included in the echo reply. If the replying router is the destination of the FEC, then a Downstream Mapping TLV SHOULD NOT be included in the echo reply. Kompella, et al. Expires May 1, 2017 [Page 68] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Otherwise the replying router SHOULD include a Downstream Mapping object for each interface over which this FEC could be forwarded. For a more precise definition of the notion of "downstream", see Section 3.4.2, "Downstream Router and Interface". The Length is K + M + 4*N octets, where M is the Multipath Length, and N is the number of Downstream Labels. Values for K are found in the description of Address Type below. The Value field of a Downstream Mapping has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | DS Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Interface Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multipath Type| Depth Limit | Multipath Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (Multipath Information) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Transmission Unit (MTU) The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the Downstream LSR. Address Type The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the Downstream IP Address and Downstream Interface fields. The resulting total for the initial part of the TLV is listed in the table below as "K Octets". The Address Type is set to one of the following values: Kompella, et al. Expires May 1, 2017 [Page 69] Internet-Draft Detecting MPLS Data Plane Failures October 2016 Type # Address Type K Octets ------ ------------ -------- 1 IPv4 Numbered 16 2 IPv4 Unnumbered 16 3 IPv6 Numbered 40 4 IPv6 Unnumbered 28 DS Flags The DS Flags field is a bit vector with the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Rsvd(MBZ) |I|N| +-+-+-+-+-+-+-+-+ Two flags are defined currently, I and N. The remaining flags MUST be set to zero when sending and ignored on receipt. Flag Name and Meaning ---- ---------------- I Interface and Label Stack Object Request When this flag is set, it indicates that the replying router SHOULD include an Interface and Label Stack Object in the echo reply message. N Treat as a Non-IP Packet Echo request messages will be used to diagnose non-IP flows. However, these messages are carried in IP packets. For a router that alters its ECMP algorithm based on the FEC or deep packet examination, this flag requests that the router treat this as it would if the determination of an IP payload had failed. Downstream IP Address and Downstream Interface Address IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets. If the interface to the downstream LSR is numbered, then the Address Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be set to either the downstream LSR's Router ID or the interface address of the downstream LSR, and the Downstream Interface Address MUST be set to the downstream LSR's interface address. Kompella, et al. Expires May 1, 2017 [Page 70] Internet-Draft Detecting MPLS Data Plane Failures October 2016 If the interface to the downstream LSR is unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP Address MUST be the downstream LSR's Router ID, and the Downstream Interface Address MUST be set to the index assigned by the upstream LSR to the interface. If an LSR does not know the IP address of its neighbor, then it MUST set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it must set the Downstream IP Address to 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with either of these addresses in the Downstream IP Address field, this indicates that it MUST bypass interface verification but continue with label validation. If the originator of an Echo Request packet wishes to obtain Downstream Mapping information but does not know the expected label stack, then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be set to FF02::2. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation, but return Downstream Mapping TLVs using the information provided. Multipath Type The following Multipath Types are defined: Key Type Multipath Information --- ---------------- --------------------- 0 no multipath Empty (Multipath Length = 0) 2 IP address IP addresses 4 IP address range low/high address pairs 8 Bit-masked IP IP address prefix and bit mask address set 9 Bit-masked label set Label prefix and bit mask Type 0 indicates that all packets will be forwarded out this one interface. Types 2, 4, 8, and 9 specify that the supplied Multipath Information will serve to exercise this path. Depth Limit Kompella, et al. Expires May 1, 2017 [Page 71] Internet-Draft Detecting MPLS Data Plane Failures October 2016 The Depth Limit is applicable only to a label stack and is the maximum number of labels considered in the hash; this SHOULD be set to zero if unspecified or unlimited. Multipath Length The length in octets of the Multipath Information. Multipath Information Address or label values encoded according to the Multipath Type. See Section 3.4.1.1.1 for encoding details. Downstream Label(s) The set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. Labels are treated as numbers, i.e., they are right justified in the field. A Downstream Label is 24 bits, in the same format as an MPLS label minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the Traffic Class (TC) bits are bits 20-22, and bit 23 is the S bit. The replying router SHOULD fill in the TC and S bits; the LSR receiving the echo reply MAY choose to ignore these bits. Protocol The Protocol is taken from the following table: Protocol # Signaling Protocol ---------- ------------------ 0 Unknown 1 Static 2 BGP 3 LDP 4 RSVP-TE Authors' Addresses Kireeti Kompella Juniper Networks, Inc. Email: kireeti.kompella@gmail.com Kompella, et al. Expires May 1, 2017 [Page 72] Internet-Draft Detecting MPLS Data Plane Failures October 2016 George Swallow Cisco Systems, Inc. Email: swallow.ietf@gmail.com Carlos Pignataro (editor) Cisco Systems, Inc. Email: cpignata@cisco.com Nagendra Kumar Cisco Systems, Inc. Email: naikumar@cisco.com Sam Aldrin Google Email: aldrin.ietf@gmail.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Kompella, et al. Expires May 1, 2017 [Page 73] ./draft-ietf-httpauth-mutual-11.txt0000664000764400076440000037723613012206233016534 0ustar iustyiusty HTTPAUTH Working Group Y. Oiwa Internet-Draft H. Watanabe Intended status: Experimental H. Takagi Expires: May 18, 2017 ITRI, AIST K. Maeda T. Hayashi Lepidum Y. Ioku Individual November 14, 2016 Mutual Authentication Protocol for HTTP draft-ietf-httpauth-mutual-11 Abstract This document specifies a mutual authentication scheme for the Hypertext Transfer Protocol (HTTP). This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 18, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Oiwa, et al. Expires May 18, 2017 [Page 1] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Document Structure and Related Documents . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Messages Overview . . . . . . . . . . . . . . . . . . . . 7 2.2. Typical Flows of the Protocol . . . . . . . . . . . . . . 8 2.3. Alternative Flows . . . . . . . . . . . . . . . . . . . . 10 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Non-ASCII extended header parameters . . . . . . . . . . . 12 3.2. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . 14 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. 401-INIT and 401-STALE . . . . . . . . . . . . . . . . . . 16 4.2. req-KEX-C1 . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. 401-KEX-S1 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 21 5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 22 6. Session Management . . . . . . . . . . . . . . . . . . . . . . 23 7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 25 7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 26 7.2. Notes on tls-unique . . . . . . . . . . . . . . . . . . . 27 8. Authentication Extensions . . . . . . . . . . . . . . . . . . 27 9. String Preparation . . . . . . . . . . . . . . . . . . . . . . 28 10. Decision Procedure for Clients . . . . . . . . . . . . . . . . 28 10.1. General Principles and Requirements . . . . . . . . . . . 28 10.2. State machine for the client (informative) . . . . . . . . 30 11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 35 12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 37 12.1. Support Functions and Notations . . . . . . . . . . . . . 38 12.2. Default Functions for Algorithms . . . . . . . . . . . . . 39 13. Application Channel Binding . . . . . . . . . . . . . . . . . 40 14. Application for Proxy Authentication . . . . . . . . . . . . . 41 Oiwa, et al. Expires May 18, 2017 [Page 2] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 42 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 16.1. Registry for Authentication Algorithms . . . . . . . . . . 42 16.2. Registry for Validation Methods . . . . . . . . . . . . . 43 17. Security Considerations . . . . . . . . . . . . . . . . . . . 44 17.1. Security Properties . . . . . . . . . . . . . . . . . . . 44 17.2. Secrecy of Credentials . . . . . . . . . . . . . . . . . . 44 17.3. Denial-of-service Attacks to Servers . . . . . . . . . . . 45 17.3.1. On-line Active Password Attacks . . . . . . . . . . . 45 17.4. Communicating the status of mutual authentication with users . . . . . . . . . . . . . . . . . . . . . . . . . . 45 17.5. Implementation Considerations . . . . . . . . . . . . . . 46 17.6. Usage Considerations . . . . . . . . . . . . . . . . . . . 47 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 18.1. Normative References . . . . . . . . . . . . . . . . . . . 47 18.2. Informative References . . . . . . . . . . . . . . . . . . 48 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50 A.1. Changes in Httpauth WG Revision 11 . . . . . . . . . . . . 50 A.2. Changes in Httpauth WG Revision 10 . . . . . . . . . . . . 50 A.3. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50 A.4. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50 A.5. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 51 A.6. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 51 A.7. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 51 A.8. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51 A.9. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51 A.10. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51 A.11. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 52 A.12. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52 A.13. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52 A.14. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52 A.15. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52 A.16. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 53 A.17. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 54 A.18. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54 A.19. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54 A.20. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 55 A.21. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 55 A.22. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55 A.23. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55 A.24. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 56 A.25. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Oiwa, et al. Expires May 18, 2017 [Page 3] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 1. Introduction This document specifies a mutual authentication scheme for Hypertext Transfer Protocol (HTTP). The scheme, called "Mutual Authentication Protocol" in this document, provides true mutual authentication between an HTTP client and an HTTP server, using just a simple password as a credential. Password-stealing attacks are one of most critical threats for Web systems. For a long time, plain-text password authentications (Basic and Web form-based) are widely used (and are in use now). When these are used with plain HTTP protocols, it is trivially easy for attackers to sniff the password credentials on the wire. Digest authentication scheme [RFC7616] uses a SHA-2 (formerly SHA-1 and MD5) hash algorithms to hide the raw user password from the sniffing. However, if the number of possible candidates of users' password is not enough, recent powerful computers can compute possible hash values for billions of password candidates, and compare these with the sniffed values to find out the correct password. This kind of attack is called "offline password dictionary attacks"; recently, the size of possible search space by computers is quite competing with possibility of user's memorable passwords, threatening the effectiveness of such hash-based password protections. TLS [RFC5246] provides a strong cryptographic protection against the network-based sniffing of passwords and other communication contents. If TLS is correctly used by both server operators and client users, passwords and other credentials will not be available for any outside attackers. However, there is a pit-hole in the TLS deployment on the Web systems; if the users are forged into a "wrong website" by some kind of social attacks and tridked to perform authentication on that site, the credentials will be sent to the attacker's server and trivially leaked. Such attacks are called "Phishing", and becoming a real threats in these days. In the curent Web system deployment, TLS certificates will be issued to almost any users of Internet (including malicious attackers). Although those certificate includes several levels of the "validation results" (such as corporate names) of the issued entities, task of "checking" those validation results are left to the users of Web browsers, still leaving the possibility of such social attacks. Another direction to avoid such threats is to avoid password-based authentication and use some kind of pre-deployed strong secret keys (either on client side or on server-side) for authentications. Several federated authentication framework as well as HOBA [RFC7486] are proposed and deployed on the real Web systems to satisfy those needs. However, a kind of authentication based on "human-memorable Oiwa, et al. Expires May 18, 2017 [Page 4] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 secret" (i.e. passwords) is still required on several situations within those systems, such is initialization, key deployment to new clients, or recovery of secret accounts with lost cryptographic keys. The Mutual authentication protocol proposed in this document is a strong cryptographic solution for password authentications. It mainly provides the two key features: o No password information, at all, is exchanged in the communications. When the server and the user fails to authenticate with each other, the protocol will not reveal the tiniest bit of information about the user's password. This prevents any kind of off-line password dictionary attacks, even with the existence of Phishing attacks. o To successfully authenticate, the server must own the valid registered credentials (authentication secret), as well as client users. (Non-intuitively, this is not true for Basic and Digest authentication. For example, servers for Basic authentications can answer "YES" to any clients, without actually checking authentication at all.) This means that phishing attackers cannot forge users that they are the "authentic" servers. Client users can assert whether the communicating peer is "the server" who have registered their account beforehand. In other words, it provides "true" mutual authentication between servers and clients. Given these, the proposed protocol can serve as a strong alternative to the Basic, Digest, and web-form-based authentications, and also as a strong companion to the non-password-based authentication frameworks. The proposed protocol will serve in the same way as existing Basic/ Digest authentication: it meets the requirement for new authentication scheme for HTTP as described in Section 5.1.2 of [RFC7235]. Additionally, to communiate authentication results more reliably between the server and the client user, it suggests for Web browsers to have some "secure" way of displaying the authentication results. Having such an user interface in future browser will greatly reduce the risk of impersonation by kinds of social attacks, similarly in the manner of the "green padlock" for extended verification TLS certificates. Technically, the authentication scheme proposed in this document is a general framework for using password-based authenticated key exchange (PAKE) and similar stronger cryptographic primitives with HTTP. The two key features shown above are corresponding to the nature of PAKE. Oiwa, et al. Expires May 18, 2017 [Page 5] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document distinguishes the terms "client" and "user" in the following way: A "client" is an entity understanding and talking HTTP and the specified authentication protocol, usually computer software; a "user" is a (usually natural) person who wants to access data resources using a "client". The term "natural numbers" refers to the non-negative integers (including zero) throughout this document. This document treats both the input (domain) and the output (codomain) of hash functions to be octet strings. When a natural number output for a hash function is required, it will be written as INT(H(s)). 1.2. Document Structure and Related Documents The entire document is organized as follows: o Section 2 presents an overview of the protocol design. o Sections 3 to 11 define a general framework of the Mutual authentication protocol. This framework is independent of specific cryptographic primitives. o Section 12 describes properties needed for cryptographic algorithms used with this protocol framework, and defines a few functions which will be shared among such cryptographic algorithms. o The sections after that contain general normative and informative information about the protocol. In addition, there are two companion documents which are referred from/related to this specification: o [I-D.ietf-httpauth-mutual-algo]: defines cryptographic primitives which can be used with this protocol framework. o [I-D.ietf-httpauth-extension]: defines small but useful extensions to the current HTTP authentication framework so that it can support application-level semantics of existing Web systems. Oiwa, et al. Expires May 18, 2017 [Page 6] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 2. Protocol Overview The protocol, as a whole, is designed as a natural extension to the HTTP protocol [RFC7230] using a framework defined in [RFC7235]. Internally, the server and the client will first perform a cryptographic key exchange, using the secret password as a "tweak" to the exchange. The key exchange will only succeed when the secrets used by the both peers are correctly related (i.e., generated from the same password). Then, both peers will verify the authentication results by confirming the sharing of the exchanged key. This section provides a brief outline of the protocol and the exchanged messages. 2.1. Messages Overview The authentication protocol uses seven kinds of messages to perform mutual authentication. These messages have specific names within this specification. o Authentication request messages: used by the servers to request clients to start mutual authentication. * 401-INIT message: a general message to start the authentication protocol. It is also used as a message indicating an authentication failure. * 401-STALE message: a message indicating that client has to start a new key exchange. o Authenticated key exchange messages: used by both peers to perform authentication and the sharing of a cryptographic secret. * req-KEX-C1 message: a message sent from the client. * 401-KEX-S1 message: an intermediate response to a req-KEX-C1 message from the server. o Authentication verification messages: used by both peers to verify the authentication results. * req-VFY-C message: a message used by the client, requesting the server authenticate and authorize the client. * 200-VFY-S message: a response used by the server to indicate the successful client-authentication. It also contains information necessary for the client to check the authenticity of the server. In addition to the above, either a request or a response without any Oiwa, et al. Expires May 18, 2017 [Page 7] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 HTTP headers related to this specification will be hereafter called a "normal request" or a "normal response", respectively. 2.2. Typical Flows of the Protocol In typical cases, the client access to a resource protected by the Mutual authentication scheme will use the following protocol sequence. Client Server | | | ---- (1) normal request ---------> | GET / HTTP/1.1 | | | | <---------------- (2) 401-INIT --- | | 401 Authentication Required | WWW-Authenticate: Mutual realm="a realm" | | [user, | | pass]-->| | | ---- (3) req-KEX-C1 -------------> | GET / HTTP/1.1 | Authorization: Mutual user="john", |--> [user DB] kc1="...", ... |<-- [user info] | | | <-------------- (4) 401-KEX-S1 --- | | 401 Authentication Required | WWW-Authenticate: Mutual sid=..., ks1="...", ... | | [compute] (5) compute session secret [compute] | | | | | ---- (6) req-VFY-C --------------> | GET / HTTP/1.1 |--> [verify (6)] Authorization: Mutual sid=..., |<-- OK vkc="...", ... | | | | <--------------- (7) 200-VFY-S --- | [verify | 200 OK | (7)]<--| Authentication-Info: Mutual vks="..." | | v v Figure 1: Typical communication flow for first access to resource o As usual in general HTTP protocol designs, a client will at first request a resource without any authentication attempt (1). If the requested resource is protected by the Mutual authentication, the Oiwa, et al. Expires May 18, 2017 [Page 8] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 server will respond with a message requesting authentication (401-INIT) (2). o The client processes the body of the message and waits for the user to input the user name and a password. If the user name and the password are available, the client will send a message with the authenticated key exchange (req-KEX-C1) to start the authentication (3). o If the server has received a req-KEX-C1 message, the server looks up the user's authentication information within its user database. Then the server creates a new session identifier (sid) that will be used to identify sets of the messages that follow it and responds back with a message containing a server-side authenticated key exchange value (401-KEX-S1) (4). o At this point (5), both peers calculate a shared "session secret" using the exchanged values in the key exchange messages. Only when both the server and the client have used secret credentials generated from the same password will the session secret values match. This session secret will be used for access authentication of every individual request/response pair after this point. o The client will send a request with a client-side authentication verification value (req-VFY-C) (6), calculated from the client- generated session secret. The server will check the validity of the verification value using its own version of the session secret. o If the authentication verification value from the client was correct, it means that the client definitely owns the credential based on the expected password (i.e., the client authentication succeeded). The server will respond with a successful message (200-VFY-S) (7). Contrary to the usual one-way authentication (e.g., HTTP Basic authentication or POP APOP authentication [RFC1939]), this message also contains a server-side authentication verification value. When the client's verification value is incorrect (e.g., because the user-supplied password was incorrect), the server will respond with the 401-INIT message (the same one as used in (2)) instead. o The client MUST first check the validity of the server-side authentication verification value contained in the message (7). If the value was equal to the expected one, server authentication succeeded. If it is not the value expected, or if the message does not Oiwa, et al. Expires May 18, 2017 [Page 9] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 contain the authentication verification value, it means that the mutual authentication has been broken for some unexpected reason. The client MUST NOT process any body or header values contained in the HTTP response in this case. (Note: This case should not happen between a correctly implemented server and client without any active attacks. The possible cause of such a case might be either a man-in-the-middle attack or an incorrect implementation.) 2.3. Alternative Flows As shown above, the typical flow for a first authentication request requires three request-response pairs. To reduce the protocol overhead, the protocol enables several short-cut flows which require fewer messages. o (case A) If the client knows that the resource is likely to require authentication, the client MAY omit the first unauthenticated request (1) and immediately send a key exchange (req-KEX-C1 message). This will reduce one round-trip of messages. o (case B) If both the client and the server previously shared a session secret associated with a valid session identifier (sid), the client MAY directly send a req-VFY-C message using the existing session identifier and corresponding session secret. This will further reduce one round-trip of messages. The server MAY have thrown out the corresponding session from the session table. If so, the server will respond with a 401-STALE message, indicating a new key exchange is required. The client SHOULD retry constructing a req-KEX-C1 message in this case. Figure 2 depicts the shortcut flows described above. Under the appropriate settings and implementations, most of the requests to resources are expected to meet both criteria, and thus only one round-trip of request/response will be required. Oiwa, et al. Expires May 18, 2017 [Page 10] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 (A) omit first request (2 round trips) Client Server | | | --- req-KEX-C1 ----> | | | | <---- 401-KEX-S1 --- | | | | ---- req-VFY-C ----> | | | | <----- 200-VFY-S --- | | | (B) reusing session secret (re-authentication) (B-1) key available (B-2) key expired (1 round trip) (3 round trips) Client Server Client Server | | | | | ---- req-VFY-C ----> | | --- req-VFY-C -------> | | | | | | <----- 200-VFY-S --- | | <------- 401-STALE --- | | | | | | --- req-KEX-C1 ------> | | | | <------ 401-KEX-S1 --- | | | | --- req-VFY-C -------> | | | | <------- 200-VFY-S --- | | | Figure 2: Several alternative protocol flows For more details, see Sections 10 and 11. 3. Message Syntax Throughout this specification, the syntax is denoted in the extended augmented BNF syntax defined in [RFC7230], and [RFC5234]. The following elements are quoted from [RFC5234], [RFC7230] and [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, header-field, token, challenge, and credential. Oiwa, et al. Expires May 18, 2017 [Page 11] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 The Mutual authentication protocol uses three headers: WWW-Authenticate (usually in responses with status code 401), Authorization (in requests), and Authentication-Info (in responses other than 401 status). These headers follow a common framework described in [RFC7235] and [RFC7615]. The detailed meanings for these headers are contained in Section 4. The framework in [RFC7235] defines the syntax for the headers WWW-Authenticate and Authorization as the syntax elements "challenge" and "credentials", respectively. The "auth-scheme" contained in those headers MUST be "Mutual" throughout this protocol specification. The syntax for "challenge" and "credentials" to be used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth- param), not the "b64token" defined in [RFC7235]. The Authentication-Info: header used in this protocol SHALL follow the syntax defined in [RFC7615]. In HTTP, the WWW-Authenticate header may contain two or more challenges. Client implementations SHOULD be aware of and be capable of handling those cases correctly. 3.1. Non-ASCII extended header parameters All of parameters contained in the above three headers, except the "realm" field, MAY be extended to ISO 10646-1 values using the framework described in [RFC5987]. All servers and clients MUST be capable of receiving and sending values encoded in [RFC5987] syntax. If a value to be sent contains only ASCII characters, the field MUST be sent using plain RFC 7235 syntax. The syntax as extended by RFC 5987 MUST NOT be used in this case. If a value (except the "realm" header) contains one or more non-ASCII characters, the parameter SHOULD be sent using the syntax defined in Section 3.2 of [RFC5987] as "ext-parameter". Such a parameter MUST have a charset value of "UTF-8", and the language value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the used syntax. For example, a parameter "user" with value "Renee of France" SHOULD be sent as < user="Renee of France" >. If the value is "Rene of France", it SHOULD be sent as < user*=UTF- 8''Ren%C3%89e%20of%20France > instead. [RFC7235] requires the realm parameter to be in its plain form (not as an extended "realm*" parameter), so RFC 5987 syntax MUST NOT be used for this parameter. Oiwa, et al. Expires May 18, 2017 [Page 12] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 3.2. Values The parameter values contained in challenge/credentials MUST be parsed strictly conforming to the HTTP semantics (especially un- quoting of the string parameter values). In this protocol, those values are further categorized into the following value types: tokens (bare-token and extensive-token), string, integer, hex-fixed-number, and base64-fixed-number. For clarity, implementations are RECOMMENDED to use the canonical representations specified in the following subsections for sending values. However, recipients MUST accept both quoted and unquoted representations interchangeably as specified in HTTP. 3.2.1. Tokens For sustaining both security and extensibility at the same time, this protocol defines a stricter sub-syntax for the "token" to be used. Extensive-token values SHOULD use the following syntax (after HTTP value parsing): bare-token = bare-token-lead-char *bare-token-char bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_" extension-token = "-" bare-token 1*("." bare-token) extensive-token = bare-token / extension-token Figure 3: BNF syntax for token values The tokens (bare-token and extension-token) are case insensitive; Senders SHOULD send these in lower case, and receivers MUST accept both upper and lower cases. When tokens are used as (partial) inputs to any hash or other mathematical functions, they MUST always be used in lower case. Extensive-tokens are used in this protocol where the set of acceptable tokens may include non-standard extensions. Any extension of this protocol MAY use either the bare-tokens allocated by IANA (under the procedure described in Section 16), or extension-tokens with the format "-.", where is a valid (sub-)domain name on the Internet owned by the party who defines the extension. Bare-tokens and extensive-tokens are also used for parameter names, in the unquoted form. Requirements for using the extension-token for the parameter names are the same as the previous paragraph. The canonical format for bare-tokens and extensive-tokens is the Oiwa, et al. Expires May 18, 2017 [Page 13] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 unquoted representation. 3.2.2. Strings All character strings MUST be encoded to octet strings using the UTF-8 encoding [RFC3629] for the Unicode character set [Unicode]. Such strings MUST NOT contain any leading BOM markers (also known as ZERO WIDTH NO-BREAK SPACE, U+FEFF or EF BB BF). Both peers are RECOMMENDED to reject any invalid UTF-8 sequences that might cause decoding ambiguities (e.g., containing <"> in the second or later bytes of the UTF-8 encoded characters). If strings are representing a domain name or URI that contains non- ASCII characters, the host parts SHOULD be encoded as it is used in the HTTP protocol layer (e.g., in a Host: header); under current standards it will be the one defined in [RFC5890]. It SHOULD use lower-case ASCII characters. The canonical format for strings is quoted-string (as it may contain equal signs, plus signs and slashes), unless the parameter containing the string value will use extended syntax defined in [RFC5987]. (An [RFC5987] extended parameter will have an unquoted encoded value, as defined therein.) 3.2.3. Numbers The following syntax definitions give a syntax for numeric values: integer = "0" / (%x31-39 *DIGIT) ; no leading zeros hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66)) base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"=" Figure 4: BNF syntax for numbers The syntax definition of the integers only allows representations that do not contain leading zeros. A number represented as a hex-fixed-number MUST include an even number of hexadecimal digits (i.e., multiples of eight bits). Those values are case-insensitive, and SHOULD be sent in lower case. When these values are generated from any cryptographic values, they MUST have their "natural length"; if these values are generated from a hash function, these lengths correspond to the hash size; if these are representing elements of a mathematical set (or group), these lengths SHALL be the shortest for representing all the elements in the set. For example, the results of the SHA-256 hash function will be represented by 64 digits, and any elements in a 2048-bit prime field (modulo a 2048-bit integer) will be represented by 512 digits, Oiwa, et al. Expires May 18, 2017 [Page 14] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 regardless of how much zeros appear in front of such representations. Session-identifiers and other non-cryptographically generated values are represented in any (even) length determined by the side that generates it first, and the same length MUST be used throughout all communications by both peers. The numbers represented as base64-fixed-number SHALL be generated as follows: first, the number is converted to a big-endian radix-256 binary representation as an octet string. The length of the representation is determined in the same way as mentioned above. Then, the string is encoded using the Base 64 encoding (described in Section 4 of [RFC4648]) without any spaces and newlines. Implementations decoding base64-fixed-number SHOULD reject any input data with invalid characters, excess/insufficient padding, or non- canonical pad bits (See Sections 3.1 to 3.5 of [RFC4648]). The canonical format for integer and hex-fixed-number are unquoted tokens, and that for base64-fixed-number is quoted-string. 4. Messages In this section we define the seven kinds of messages used in the authentication protocol along with the formats and requirements of the headers for each message. To determine in what circumstances each message is expected to be sent, see Sections 10 and 11. In the descriptions below, the type of allowable values for each header parameter is shown in parenthesis after each parameter name. The "algorithm-determined" type means that the acceptable value for the parameter is one of the types defined in Section 3, and is determined by the value of the "algorithm" parameter. The parameters marked "mandatory" SHALL be contained in the message. The parameters marked "non-mandatory" MAY either be contained or omitted in the message. Each parameter SHALL appear in each header exactly once at most. All credentials and challenges MAY contain any parameters not explicitly specified in the following sections. Recipients that do not understand such parameters MUST silently ignore those. However, all credentials and challenges MUST meet the following criteria: o For responses, the parameters "reason", any "ks#" (where # stands for any decimal integer), and "vks" are mutually exclusive; any challenge MUST NOT contain two or more parameters among them. They MUST NOT contain any "kc#" or "vkc" parameters. Oiwa, et al. Expires May 18, 2017 [Page 15] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 o For requests, the parameters "kc#" (where # stands for any decimal integer), and "vkc" are mutually exclusive and any challenge MUST NOT contain two or more parameters among them. They MUST NOT contain any "ks#" or "vks" parameters. Every message in this section contains a "version" field, to detect future, incompatible revisions of the protocol. Implementations of the protocol described in this specification MUST always send a token "1", and recipients MUST reject messages that contain any other value as a version, unless another specification defines a behavior for that version. 4.1. 401-INIT and 401-STALE Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status (Authentication Required) message (or other 4XX status if sensible) containing one and only one (hereafter not explicitly noted) "WWW-Authenticate" header containing a "reason" parameter in the challenge. The challenge SHALL contain all of the parameters marked "mandatory" below, and MAY contain those marked "non-mandatory". version: (mandatory extensive-token) should be the token "1". algorithm: (mandatory extensive-token) specifies the authentication algorithm to be used. The value MUST be one of the tokens specified in [I-D.ietf-httpauth-mutual-algo] or another supplemental specification. validation: (mandatory extensive-token) specifies the method of host validation. The value MUST be one of the tokens described in Section 7 or the tokens specified in another supplemental specification. auth-scope: (non-mandatory string) specifies the authentication scope, the set of hosts for which the authentication credentials are valid. It MUST be one of the strings described in Section 5. If the value is omitted, it is assumed to be the "single-server" type domain in Section 5. realm: (mandatory string) is a string representing the name of the authentication realm inside the authentication scope. As specified in [RFC7235], this value MUST always be sent in the quoted-string form, and an [RFC5987] encoding MUST NOT be used. The realm value sent from the server SHOULD be an ASCII string. Clients MAY treat any non-ASCII value Oiwa, et al. Expires May 18, 2017 [Page 16] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 received in this field as a binary blob, an NFC- normalized UTF-8 string, or an error. reason: (mandatory extensive-token) SHALL be an extensive- token that describes the possible reason of the failed authentication/authorization. Both servers and clients SHALL understand and support the following three tokens: * initial: authentication was not tried because there was no Authorization header in the corresponding request. * stale-session: the provided sid in the request was either unknown to or expired in the server. * auth-failed: authentication trial was failed for some reason, possibly with a bad authentication credential. Implementations MAY support the following tokens or any extensive-tokens defined outside this specification. If clients receive any unknown tokens, they SHOULD treat these as if they were "auth-failed" or "initial". * reauth-needed: the server-side application requires a new authentication trial, regardless of the current status. * invalid-parameters: the server did not attempt authentication because some parameters were not acceptable. * internal-error: the server did not attempt authentication because there are some troubles on the server-side. * user-unknown: this is a special case of auth- failed, suggesting that the provided user name is invalid. The use of this parameter is NOT RECOMMENDED due to security implications, except for special-purpose applications where it makes sense. * invalid-credential: ditto, suggesting that the provided user name was valid but authentication still failed. The use of this parameter is Oiwa, et al. Expires May 18, 2017 [Page 17] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 NOT RECOMMENDED for security reasons. * authz-failed: authentication was successful, but access to the specified resource is not authorized to the specific authenticated user. (It might be used along with either a 401 or 403 status to indicate that the authentication result is one of the existing reasons for the failed authorization.) It is RECOMMENDED to record the reasons to a kind of diagnostic log, for an example, or shown to the client user immediately. It will be helpful to find out later that the reason of the failed authentication is either technical reasons of user errors. The algorithm specified in this header will determine the types (among those defined in Section 3) and the values for K_c1, K_s1, VK_c and VK_s. Among these messages, those with the reason parameter of value "stale-session" will be called "401-STALE" messages hereafter, because these have a special meaning in the protocol flow. Messages with any other reason parameters will be called "401-INIT" messages. 4.2. req-KEX-C1 Every req-KEX-C1 message SHALL be a valid HTTP request message containing an "Authorization" header with a credential containing a "kc1" parameter. The credential SHALL contain the parameters with the following names: version: (mandatory, extensive-token) should be the token "1". algorithm, validation, auth-scope, realm: MUST be the same values as received from the server. user: (mandatory, string) is the UTF-8 encoded name of the user. The string SHOULD be prepared according to the method presented in Section 9. kc1: (mandatory, algorithm-determined) is the client-side key exchange value K_c1, which is specified by the algorithm that is used. Oiwa, et al. Expires May 18, 2017 [Page 18] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 4.3. 401-KEX-S1 Every 401-KEX-S1 message SHALL be a valid HTTP 401-status (Authentication Required) response message containing a "WWW-Authenticate" header with a challenge containing a "ks1" parameter. The challenge SHALL contain the parameters with the following names: version: (mandatory, extensive-token) should be the token "1". algorithm, validation, auth-scope, realm: MUST be the same values as received from the client. sid: (mandatory, hex-fixed-number) MUST be a session identifier, which is a random integer. The sid SHOULD have uniqueness of at least 80 bits or the square of the maximum estimated transactions concurrently available in the session table, whichever is larger. See Section 6 for more details. ks1: (mandatory, algorithm-determined) is the server-side key exchange value K_s1, which is specified by the algorithm. nc-max: (mandatory, integer) is the maximum value of nonce numbers that the server accepts. nc-window: (mandatory, integer) the number of available nonce number slots that the server will accept. The value of the nc-window parameter is RECOMMENDED to be 128 or more. time: (mandatory, integer) represents the suggested time (in seconds) that the client can reuse the session represented by the sid. It is RECOMMENDED to be at least 60. The value of this parameter is not directly linked to the duration that the server keeps track for the session represented by the sid. path: (non-mandatory, string) specifies which path in the URI space the same authentication is expected to be applied. The value is a space-separated list of URIs, in the same format as it was specified in domain parameter [RFC7616] for Digest authentications. All path elements contained in the parameter MUST be inside the specified auth-scope; if not, clients SHOULD ignore such elements. For better performance, Oiwa, et al. Expires May 18, 2017 [Page 19] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 recognition of this parameter by clients is important. 4.4. req-VFY-C Every req-VFY-C message SHALL be a valid HTTP request message containing an "Authorization" header with a credential containing a "vkc" parameter. The parameters contained in the header are as follows: version: (mandatory, extensive-token) should be the token "1". algorithm, validation, auth-scope, realm: MUST be the same values as received from the server for the session. sid: (mandatory, hex-fixed-number) MUST be one of the sid values that was received from the server for the same authentication realm. nc: (mandatory, integer) is a nonce request number that is unique among the requests sharing the same sid. The values of the nonce numbers SHOULD satisfy the properties outlined in Section 6. vkc: (mandatory, algorithm-determined) is the client-side authentication verification value VK_c, which is specified by the algorithm. 4.5. 200-VFY-S Every 200-VFY-S message SHALL be a valid HTTP message that does not have a 401 (Authentication Required) status code and SHALL contain an "Authentication-Info" header with a "vks" parameter. The parameters contained in the header are as follows: version: (mandatory, extensive-token) should be the token "1". sid: (mandatory, hex-fixed-number) MUST be the value received from the client. vks: (mandatory, algorithm-determined) is the server-side authentication verification value VK_s, which is specified by the algorithm. The header MUST be sent before the content body: it MUST NOT be sent in the trailer of a chunked-encoded response. If a "100 Continue" response is sent from the server, the Authentication-Info header Oiwa, et al. Expires May 18, 2017 [Page 20] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 SHOULD be included in that response, instead of the final response. 5. Authentication Realms In this protocol, an "authentication realm" is defined as a set of resources (URIs) for which the same set of user names and passwords is valid. If the server requests authentication for an authentication realm that the client is already authenticated for, the client will automatically perform the authentication using the already-known credentials. However, for different authentication realms, clients MUST NOT automatically reuse user names and passwords for another realm. Just like in the Basic and Digest access authentication protocols, the Mutual authentication protocol supports multiple, separate protection spaces to be set up inside each host. Furthermore, the protocol allows a single authentication realm to span over several hosts within the same Internet domain. Each authentication realm is defined and distinguished by the triple of an "authentication algorithm", an "authentication scope", and a "realm" parameter. However, server operators are NOT RECOMMENDED to use the same pair of an authentication scope and a realm with different authentication algorithms. The realm parameter is a string as defined in Section 4. Authentication scopes are described in the remainder of this section. An authentication scope specifies the range of hosts that the authentication realm spans over. In this protocol, it MUST be one of the following kinds of strings. o Single-server type: A string in the format "://" or "://:", where , , and are the corresponding URI parts of the request URI. If the default port (i.e., 80 for http and 443 for https) is used for the underlying HTTP communications, the port part MUST be omitted, regardless of whether it was present in the request-URI. In all other cases, the port part MUST be present, and it MUST NOT contain leading zeros. Use this format when authentication is only valid for a specific protocol (such as https). This format is equivalent to the ASCII serialization of a Web Origin, presented in Section 6.2 of [RFC6454]. o Single-host type: The "host" part of the requested URI. This is the default value. Authentication realms within this kind of authentication scope will span over several protocols (e.g., http Oiwa, et al. Expires May 18, 2017 [Page 21] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 and https) and ports, but not over different hosts. o Wildcard-domain type: A string in the format "*.", where is either the host part of the requested URI or any domain in which the requested host is included (this means that the specification "*.example.com" is valid for all of hosts "www.example.com", "web.example.com", "www.sales.example.com" and "example.com"). The domain-postfix sent by the servers MUST be equal to or included in a valid Internet domain assigned to a specific organization; if clients know, by some means such as a blacklist for HTTP cookies [RFC6265], that the specified domain is not to be assigned to any specific organization (e.g., "*.com" or "*.jp"), clients are RECOMMENDED to reject the authentication request. In the above specifications, every "scheme", "host", and "domain" MUST be in lower case, and any internationalized domain names beyond the ASCII character set SHALL be represented in the way they are sent in the underlying HTTP protocol, represented in lower case characters, i.e., these domain names SHALL be in the form of LDH labels in IDNA [RFC5890]. A "port" MUST be given in the shortest, unsigned, decimal number notation. Not obeying these requirements will cause failure of valid authentication attempts. 5.1. Resolving Ambiguities In the above definitions of authentication scopes, several scopes may overlap each other. If a client has already been authenticated to several realms applicable to the same server, the client may have a multiple lists of the "path" parameters received with the "401-KEX-S1" message (see Section 4). If these path lists have any overlap, a single URI may belong to multiple possible candidate of realms to be authenticated to. In such cases, clients faces an ambiguity in deciding which credentials to send for a new request (in steps 3 and 4 of the decision procedure presented in Section 10). In such cases, a client MAY send request which belong to any of these candidate realms freely, or it MAY simply send an unauthenticated request and see for which realm the server requests an authentication. Server operators are RECOMMENDED to provide properly-configured "path" parameters (more precisely, disjoint path sets for each realms) for clients so that such ambiguities will not occur. The following procedure is one possible tactic for resolving ambiguity in such cases. Oiwa, et al. Expires May 18, 2017 [Page 22] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 o If the client has previously sent a request to the same URI, and if it remembers the authentication realm requested by the 401-INIT message at that time, use that realm. o In other cases, use one of the authentication realms representing the most-specific authentication scopes. The list of possible domain specifications shown above is given from most specific to least specific. If there are several choices with different wildcard-domain specifications, the one that has the longest domain-postfix has priority over ones with shorter domain-postfixes. o If there are realms with the same authentication scope, there is no defined priority; the client MAY choose any one of the possible choices. 6. Session Management In the Mutual authentication protocol, a session represented by an sid is set up using four messages (first request, 401-INIT, req-KEX-C1 and 401-KEX-S1), after which a "session secret" (z) associated with the session is established. After mutually establishing a session secret, this session, along with the secret, can be used for one or more requests for resources protected by the same realm on the same server. Note that session management is only an inside detail of the protocol and usually not visible to normal users. If a session expires, the client and server SHOULD automatically re-establish another session without informing the user. Sessions and session identifiers are local to each server (defined by scheme, host, and port), even if an authentication scope covers multiple servers; clients MUST establish separate sessions for each port of a host to be accessed. Furthermore, sessions and identifiers are also local to each authentication realm, even if these are provided by the same server. The same session identifiers provided either from different servers or for different realms MUST be treated as independent or each other. The server SHOULD accept at least one req-VFY-C request for each session, if the request reaches the server in a time window specified by the timeout parameter in the 401-KEX-S1 message, and there are no emergent reasons (such as flooding attacks) to forget the session. After that, the server MAY discard any session at any time and MAY send 401-STALE messages for any further req-VFY-C requests received for that session. Oiwa, et al. Expires May 18, 2017 [Page 23] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 The client MAY send two or more requests using a single session specified by the sid. However, for all such requests, each value of the nonce number (in the nc parameter) MUST satisfy the following conditions: o It is a natural number. o The same nonce number was not sent within the same session. o It is not larger than the nc-max value that was sent from the server in the session represented by the sid. o It is larger than (largest-nc - nc-window), where largest-nc is the largest value of nc which was previously sent in the session, and nc-window is the value of the nc-window parameter that was received from the server for the session. The last condition allows servers to reject any nonce numbers that are "significantly" smaller than the "current" value (defined by the value of nc-window) of the nonce number used in the session involved. In other words, servers MAY treat such nonce numbers as "already received". This restriction enables servers to implement duplicate nonce detection in a constant amount of memory for each session. Servers MUST check for duplication of the received nonce numbers, and if any duplication is detected, the server MUST discard the session and respond with a 401-STALE message, as outlined in Section 11. The server MAY also reject other invalid nonce numbers (such as ones above the nc-max limit) by sending a 401-STALE message. For example, assume the nc-window value of the current session is 128, nc-max is 400, and that the client has already used the following nonce numbers: {1-120, 122, 124, 130-238, 255-360, 363- 372}. Then the nonce number that can be used for the next request is one of the following set: {245-254, 361, 362, 373-400}. The values {0, 121, 123, 125-129, 239-244} MAY be rejected by the server because they are not above the current "window limit" (244 = 372 - 128). Typically, clients can ensure the above property by using a monotonically-increasing integer counter that counts from zero up to the value of nc-max. The values of the nonce numbers and any nonce-related values MUST always be treated as natural numbers within an infinite range. Implementations which uses fixed-width integer representations, fixed-precision floating-point numbers, or similar representations SHOULD NOT reject any larger values which overflow such representative limits, and MUST NOT silently truncate them using any Oiwa, et al. Expires May 18, 2017 [Page 24] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 modulus-like rounding operation (e.g., by mod 2^32). Instead, the whole protocol is carefully designed so that recipients MAY replace any such overflowing values (e.g. 2^80) with some reasonably-large maximum representative integer (e.g., 2^31 - 1 or others). 7. Host Validation Methods The "validation method" specifies a method to "relate" (or "bind") the mutual authentication processed by this protocol with other authentications already performed in the underlying layers and to prevent man-in-the-middle attacks. It determines the value vh that is an input to the authentication protocols. When HTTPS or other possible secure transport is used, this corresponds to the idea of "channel binding" described in [RFC5929]. Even when HTTP is used, similar, but somewhat limited, "binding" is performed to prevent a malicious server from trying to authenticate itself to another server as a valid user by forwarding the received credentials. The valid tokens for the validation parameter and corresponding values of vh are as follows: host: host-name validation: The value vh will be the ASCII string in the following format: "://:", where , , and are the URI components corresponding to the server-side resource currently being accessed. The scheme and host are in lower case, and the port is in a shortest decimal representation. Even if the request-URI does not have a port part, v will include the default port number. tls-server-end-point: TLS endpoint (certificate) validation: The value vh will be the octet string of the hash value of the server's public key certificate used in the underlying TLS [RFC5246] connection, processed as specified in Section 4.1 of [RFC5929]. tls-unique: TLS shared-key validation: The value vh will be the channel binding material derived from the Finished messages, as defined in Section 3.1 of [RFC5929]. (Note: see Section 7.2 for some security notices when using this validation method.) If HTTP is used on a non-encrypted channel (TCP and SCTP, for Oiwa, et al. Expires May 18, 2017 [Page 25] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 example), the validation type MUST be "host". If HTTP/TLS [RFC2818] (HTTPS) is used with a server certificate, the validation type MUST be "tls-server-end-point". If HTTP/TLS is used with an anonymous Diffie-Hellman key exchange, the validation type MUST be "tls-unique" (see the note below). If the validation type "tls-server-end-point" is used, the server certificate provided in the TLS connection MUST be verified at least to make sure that the server actually owns the corresponding private key. (Note: this verification is automatic in some RSA-based key exchanges but NOT automatic in Diffie-Hellman-based key exchanges with separate exchange for server verification.) Clients MUST validate this parameter upon receipt of 401-INIT messages. Note: The protocol defines two variants of validation on the TLS connections. The "tls-unique" method is technically more secure. However, there are some situations where tls-server-end-point is more preferable. o When TLS accelerating proxies are used, it is difficult for the authenticating server to acquire the TLS key information that is used between the client and the proxy. This is not the case for client-side "tunneling" proxies using the HTTP CONNECT method. o When a black-box implementation of the TLS protocol is used on either peer. 7.1. Applicability notes When the client is a Web browser with any scripting capabilities (dynamic contents support), the underlying TLS channel used with HTTP/TLS MUST provide server identity verification. This means (1) anonymous Diffie-Hellman key exchange cipher suites MUST NOT be used, and (2) verification of the server certificate provided by the server MUST be performed. This is to prevent loading identity- unauthenticated scripts or dynamic contents, which are referenced from the authenticated page. For other systems, when the underlying TLS channel used with HTTP/TLS does not perform server identity verification, the client SHOULD ensure that all responses are validated using the Mutual authentication protocol, regardless of the existence of 401-INIT responses. Oiwa, et al. Expires May 18, 2017 [Page 26] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 7.2. Notes on tls-unique As described in the interoperability note in the above channel binding specification, the tls-unique verification value will be changed by possible TLS renegotiation, causing an interoperability problem. TLS re-negotiations are used in several HTTPS server implementations for enforcing some security properties (such as cryptographic strength) for some specific responses. If an implementation supports the "tls-unique" verification method, the following caution SHOULD be taken: o Both peers must be aware that the vh values used for vkc (in req-VFY-C) and for vks (in 200-VFY-S) may be different. These values MUST be retrieved from underlying TLS libraries each time they are used. o After calculating the values vh and vkc to send a req-VFY-C request, Clients SHOULD NOT initiate TLS renegotiation until the end of the corresponding response header is received. An exception is that clients can and SHOULD perform TLS re- negotiation as a response to the server's request for TLS renegotiation, before receipt of the beginning of the response header. Also, implementers MUST take care of session resumption attacks regarding tls-unique channel binding mechanisms and master secrets. As a mitigation, a TLS extension defined in [RFC7627] SHOULD be used when tls-unique host verification is to be used. 8. Authentication Extensions Interactive clients (e.g., Web browsers) supporting this protocol are RECOMMENDED to support non-mandatory authentication and the Authentication-Control header defined in [I-D.ietf-httpauth-extension], except for the "auth-style" parameter. This specification also proposes (however, does not mandate) the default "auth-style" be "non-modal". Web applications SHOULD however consider the security impacts of the behaviors of clients that do not support these headers. Authentication-initializing messages with the Optional-WWW-Authenticate header are used only where the 401-INIT response is valid. It will not replace other 401-type messages such as 401-STALE and 401-KEX-S1. That is, the reason field of such a message MUST be "initial" (or any extensive-tokens NOT defined in Section 4.1). Oiwa, et al. Expires May 18, 2017 [Page 27] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 9. String Preparation It is important for interoperability that user names and passwords used in this protocol are binary-comparable regardless of the user's input methods and/or environments. To ensure this, the following preparation SHOULD be performed: o User names received from users SHOULD be prepared using the "UsernameCasePreserved" profile defined in Section 3.3 of [RFC7613]. o Passwords received from users SHOULD be prepared using the "OpaqueString" profile defined in Section 4.2 of [RFC7613]. In both cases, it is the sender's duty to correctly prepare the character strings. If any non-prepared character string is received from the other peer of the communication, the behavior of its recipient is not defined; the recipient MAY either accept or reject such input. Server applications SHOULD also prepare user names and passwords accordingly upon registration of user credentials. In addition, binary-based "interfaces" of implementations MAY require and assume that the string is already prepared accordingly; when a string is already stored as a binary Unicode string form, implementations MAY omit preparation and Unicode normalization (performing UTF-8 encoding only) before using it. When a string is already stored as an octet blob, implementations MAY send it as is. 10. Decision Procedure for Clients 10.1. General Principles and Requirements To securely implement the protocol, the client must be careful about accepting the authenticated responses from the server. This also holds true for the reception of a "normal response" (a response which does not contain Mutual authentication-related headers) from HTTP servers. As usual in the HTTP authentication, a single user-level request may result in exchange of two-or-more HTTP requests and responses in sequence. The following normative rules MUST be followed by the clients implementing this protocol: o Any kind of a "normal response" MUST only be accepted for the very first request in the sequence. Any "normal response" returned for Oiwa, et al. Expires May 18, 2017 [Page 28] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 the second or later requests in the sequence SHALL be considered invalid. o In the same principle, if any response is related to an authentication realm which is different from that of the client's request (for example, a 401-INIT message requesting authentication on another realm), it MUST only be accepted for the very first request in the sequence. Such a response returned for a second or later request in the sequence SHALL be considered invalid. o A req-KEX-C1 message MAY be sent either as a initial request or as a response to 401-INIT or 401-STALE. However, it SHOULD NOT be sent more than once in the sequence for a single authentication realm, to avoid infinite loops of messages. A 401-KEX-S1 response MUST be accepted only when the corresponding request is req-KEX-C1. o A req-VFY-C message MAY be sent if there is a valid session secret shared between the client and the server, established by req-KEX-C1 and 401-KEX-S1. If any response with 401 status is returned for such a message, the corresponding session secret SHOULD be discarded as unusable. Especially, upon the reception of a 401-STALE response, the client SHOULD try establishing a new session by sending req-KEX-C1, but only once within the request/response sequence. o A 200-VFY-S message MUST be accepted only as a response to req-VFY-C and nothing else. The VK_s values of such response messages MUST always be checked against the correct value, and if it is incorrect, the whole response SHOULD be considered invalid. The final status of the client request following the message exchange sequence shall be determined as follows: o AUTH-SUCCEED: A 200-VFY-S message with the correct VK_s value was returned in response to the req-VFY-C request in the sequence. o AUTH-REQUIRED: Two cases exists. * A 401-INIT message was returned from the server, and the client does not know how to authenticate to the given authentication realm. * A 401-INIT response was returned for req-VFY-C (or req-KEX-C1), which means the user-supplied authentication credentials were not accepted. Oiwa, et al. Expires May 18, 2017 [Page 29] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 o UNAUTHENTICATED: a normal response is returned for an initial request of any kind in the sequence. Any kind of response (including a normal response) other than those explicitly allowed in the above rules SHOULD be interpreted as a fatal communication error. In such cases, the clients MUST NOT process any data (the response body and other content-related headers) sent from the server. However, to handle exceptional error cases, clients MAY accept a message without an Authentication-Info header, if it has a Server-Error (5xx) status code. In such cases, they SHOULD be careful about processing the body of the content (ignoring it is still RECOMMENDED, as it may possibly be forged by intermediate attackers), and the client will be in the "UNAUTHENTICATED" status then. If a request is a sub-request for a resource included in another resource (e.g., embedded images, style sheets, frames etc.), clients MAY treat an AUTH-REQUESTED status as the same as an UNAUTHENTICATED status. In other words, the client MAY ignore server's request to start authentication with new credentials via sub-requests. 10.2. State machine for the client (informative) The following state machine describes the possible request-response sequences derived from the above normative rules. If implementers are not quite sure on the security consequences of the above rules, it is strongly advised to follow the decision procedure below. In particular, clients SHOULD NOT accept "normal responses" unless explicitly allowed in the rules. The labels on the steps are for informational purposes only. Action entries within each step are checked in top-to-bottom order, and the first clause satisfied is to be followed. Step 1 (step_new_request): If the client software needs to access a new Web resource, check whether the resource is expected to be inside some authentication realm for which the user has already been authenticated by the Mutual authentication scheme. If yes, go to Step 2. Otherwise, go to Step 5. Step 2: Check whether there is an available sid for the expected authentication realm. If there is one, go to Step 3. Otherwise, go to Step 4. Oiwa, et al. Expires May 18, 2017 [Page 30] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 Step 3 (step_send_vfy_1): Send a req-VFY-C request. * If you receive a 401-INIT message with a different authentication realm than expected, go to Step 6. * If a 401-STALE message is received, go to Step 9. * If a 401-INIT message is received, go to Step 13. * If a 200-VFY-S message is received, go to Step 14. * If a normal response is received, go to Step 11. Step 4 (step_send_kex1_1): Send a req-KEX-C1 request. * If a 401-INIT message is received with a different authentication realm than expected, go to Step 6. * If a 401-KEX-S1 message is received, go to Step 10. * If a 401-INIT message is received with the same authentication realm, go to Step 13 (see Note 1). * If a normal response is received, go to Step 11. Step 5 (step_send_normal_1): Send a request without any Mutual authentication headers. * If a 401-INIT message is received, go to Step 6. * If a normal response is received, go to Step 11. Step 6 (step_rcvd_init): Check whether the user's password for the requested authentication realm is known. If yes, go to Step 7. Otherwise, go to Step 12. Step 7: Check whether there is an available sid for the expected authentication realm. If there is one, go to Step 8. Otherwise, go to Step 9. Step 8 (step_send_vfy): Send a req-VFY-C request. Oiwa, et al. Expires May 18, 2017 [Page 31] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 * If a 401-STALE message is received, go to Step 9. * If a 401-INIT message is received, go to Step 13. * If a 200-VFY-S message is received, go to Step 14. Step 9 (step_send_kex1): Send a req-KEX-C1 request. * If a 401-KEX-S1 message is received, go to Step 10. * If a 401-INIT message is received, go to Step 13 (See Note 1). Step 10 (step_rcvd_kex1): Send a req-VFY-C request. * If a 401-INIT message is received, go to Step 13. * If a 200-VFY-S message is received, go to Step 14. Step 11 (step_rcvd_normal): The requested resource is out of the authenticated area. The client will be in the "UNAUTHENTICATED" status. If the response contains a request for authentications other than Mutual, it MAY be handled normally. Step 12 (step_rcvd_init_unknown): The requested resource requires Mutual authentication, and the user is not yet authenticated. The client will be in the "AUTH- REQUESTED" status, and is RECOMMENDED to process the content sent from the server, and to ask the user for a user name and a password. When those are supplied from the user, proceed to Step 9. Step 13 (step_rcvd_init_failed): For some reason the authentication failed: possibly the password or the username is invalid for the authenticated resource. Forget the user-provided credentials for the authentication realm and go to Step 12. Step 14 (step_rcvd_vfy): The received message is the 200-VFY-S message, which always contains a vks field. Check the validity of the received VK_s value. If it is equal to the expected value, it means that the mutual authentication has succeeded. The client will be in the "AUTH-SUCCEEDED" status. If the value is unexpected, it is a fatal communication error. Oiwa, et al. Expires May 18, 2017 [Page 32] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 If a user explicitly requests to log out (via the user interface), the client MUST forget the user's password, go to step 5, and reload the current resource without an authentication header. Note 1: These transitions MAY be accepted by clients, but are NOT RECOMMENDED for servers to initiate. Figure 5 shows an informative diagram of the client state. Oiwa, et al. Expires May 18, 2017 [Page 33] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 =========== -(11)------------ NEW REQUEST ( UNAUTHENTICATED ) =========== ----------------- | ^ normal v | response +(1)-------------------+ NO +(5)----------+ | The requested URI |--------------------------->| send normal | | known to be auth'ed? | | request | +----------------------+ +-------------+ YES | 401-INIT 401-INIT| | with a different realm | | -----------------------------------. | | / v v | | -(12)------------ NO +(6)--------+ | | ( AUTH-REQUESTED )<------| user/pass | | | ----------------- | known? | | | +-----------+ | | |YES v | v +(2)--------+ | +(7)--------+ | session | | | session | NO NO /| available?| | | available?|\ / +-----------+ | +-----------+ | / |YES | |YES | | | /| | | | v / | 401- 401- v | | +(3)--------+ | INIT --(13)---------- INIT +(8)--------+ | | | send |--+----->/ AUTH-REQUESTED \<-------| send | | | /| req-VFY-C | | \forget password / | req-VFY-C | | \/ +-----------+ / ---------------- /+-----------+ | /\ \ \/ ^ 401-INIT | |401- | | ------ \/\ 401-STALE | | | STALE / | \ /\ -----------------+--------------+---. | / | | / \ | | | | / | v / | 401- | 401- | v v v | +(4)--------+ | KEX-S1 +(10)-------+ KEX-S1 | +(9)--------+ | | send |-|--------->| send |<-------+-| send | | --| req-KEX-C1| | | req-VFY-C | | | req-KEX-C1| |/ +-----------+ | +-----------+ | +-----------+ | |200-VFY-S | 200-VFY-S| ^ |normal | |200-VFY-S / | |response | v / ================== v \ -(14)--------- / USER/PASS INPUTTED -(11)------------ ------->( AUTH-SUCCEED )<-- ================== ( UNAUTHENTICATED ) -------------- ----------------- Figure 5: State diagram for clients Oiwa, et al. Expires May 18, 2017 [Page 34] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 11. Decision Procedure for Servers Each server SHOULD have a table of session states. This table need not be persistent over the long term; it MAY be cleared upon server restart, reboot, or for other reasons. Each entry in the table SHOULD contain at least the following information: o The session identifier, which is the value of the sid parameter. o The algorithm used. o The authentication realm. o The state of the protocol: one of "key exchanging", "authenticated", "rejected", or "inactive". o The user name received from the client. o A boolean flag representing whether or not the session is fake. o When the state is "key exchanging", the values of K_c1 and S_s1. o When the state is "authenticated", the following information: * The value of the session secret, z * The largest nc received from the client (largest-nc) * For each possible nc values between (largest-nc - nc- window + 1) and max_nc, a boolean flag whether or not a request with the corresponding nc has been received. The table MAY contain other information. Servers SHOULD respond to the client requests according to the following procedure: (See Note 1 below for 401-INIT message with a plus sign) o When the server receives a normal request: * If the requested resource is not protected by the Mutual authentication, send a normal response. * If the resource is protected by the Mutual authentication, send a 401-INIT response. Oiwa, et al. Expires May 18, 2017 [Page 35] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 o When the server receives a req-KEX-C1 request: * If the requested resource is not protected by the Mutual authentication, send a normal response. * If the authentication realm specified in the req-KEX-C1 request is not the expected one, send a 401-INIT response. * If the server cannot validate the parameter kc1, send a 401-INIT (+) response. * If the received user name is either invalid, unknown or unacceptable, create a new session, mark it a "fake" session, compute a random value as K_s1, and send a fake 401-KEX-S1 response. (See Note 2.) * Otherwise, create a new session, compute K_s1 and send a 401-KEX-S1 response. The created session is marked as not fake, and its largest-nc is initialized to zero. The created session has the "key exchanging" state. o When the server receives a req-VFY-C request: * If the requested resource is not protected by the Mutual authentication, send a normal response. * If the authentication realm specified in the req-VFY-C request is not the expected one, send a 401-INIT response. If none of above holds true, the server will look up the session corresponding to the received sid and the authentication realm. * If the session corresponding to the received sid could not be found, or it is in the "inactive" state, send a 401-STALE response. * If the session is in the "rejected" state, send either a 401-INIT (+) or a 401-STALE message. * If the nc value in the request is larger than the nc-max parameter sent from the server, or if it is not larger then (largest-nc - nc-window) (when in "authenticated" status), the server MAY (but is not REQUIRED to; See Note 3) send a 401-STALE message. The session is changed to the "inactive" state if so did. Oiwa, et al. Expires May 18, 2017 [Page 36] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 * If the session is in the "authenticated" state, and the request has an nc value that was previously received from the client, send a 401-STALE message. The session it changed to the "inactive" state. * If the session is a "fake" session, or if the received vkc is incorrect, then send a 401-INIT (+) response. If the session is in the "key exchanging" state, it MUST be changed to the "rejected" state; otherwise, it MAY either be changed to the "rejected" state or kept in the previous state. * Otherwise, send a 200-VFY-S response. If the session was in the "key exchanging" state, the session SHOULD be changed to an "authenticated" state. The maximum nc and nc flags of the state MUST be updated appropriately. At any time, the server MAY change any state entries with both the "rejected" and "authenticated" states to the "inactive" status, and MAY discard any "inactive" states from the table. Entries with the "key exchanging" state SHOULD be kept unless there is an emergency situation such as a server reboot or a table capacity overflow. Note 1: In relation with and following the specification of the optional authentication defined in [I-D.ietf-httpauth-extension], the 401-INIT messages marked with the pluses cannot be replaced with a successful responses with an Optional-WWW-Authenticate header. Every other 401-INIT can be a response with an Optional-WWW-Authenticate. Note 2: the server SHOULD NOT send a 401-INIT response in this case, because it will leak the information to the client that the specified user name will not be accepted. Instead, postpone it to the response for the next req-VFY-C request. Note 3: The next case implies that, when the request is not rejected in this clause, the server must be able to determine whether the same nc value was previously received from the client. If the server does not remember a whole history of the nc values received from the client, the server MUST send a 401-STALE message on this clause. 12. Authentication Algorithms Cryptographic authentication algorithms which are used with this protocol will be defined separately. The algorithm definition MUST at least provide definitions for the following functions: o The server-side authentication credential J, derived from client- side authentication credential pi. Oiwa, et al. Expires May 18, 2017 [Page 37] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 o Key exchange values K_c1, K_s1 (exchanged on wire) and S_c1, S_s1 (kept secret in each peer). o Shared session secret z, to be computed by both server and client. o A hash function H to be used with the protocol, along with its output size hSize. o The number of iterations for password hashing nIterPi, if it uses the default password hashing function defined below. Specifications for cryptographic algorithms used with this framework MUST specify whether these will use the default functions defined below for values pi, VK_c, and VK_s; or, these will define their own versions for these. All algorithm used with this protocol SHOULD provide secure mutual authentication between client and servers, and generate a cryptographically strong shared secret value z, equivalently strong to or stronger than the hash function H. If any passwords (or pass- phrases or any equivalents, i.e., weak secrets) are involved, these SHOULD NOT be guessable from any data transmitted in the protocol, even if an attacker (either an eavesdropper or an active server) knows the possible thoroughly-searchable candidate list of the passwords. Furthermore, if possible, the function J for deriving server-side authentication credential J(pi) is RECOMMENDED to be one- way so that pi should not be easily computed from J(pi). 12.1. Support Functions and Notations In this section we define several support functions and notations to be shared by several algorithm definitions. The integers in the specification are in decimal, or in hexadecimal when prefixed with "0x". The function octet(i) generates an octet string containing a single octet of value i. The operator |, when applied to octet strings, denotes the concatenation of two operands. The function VI encodes natural numbers into octet strings in the following manner: numbers are represented as big-endian radix-128 strings, where each digit is represented by an octet within the range 0x80-0xff except the last digit, which is represented by a octet within the range 0x00-0x7f. The first octet MUST NOT be 0x80. For example, VI(i) = octet(i) for i < 128, and VI(i) = octet(0x80 + (i >> 7)) | octet(i & 127) for 128 <= i < 16384. This encoding is the same as the one used for the sub-components of object identifiers in the Oiwa, et al. Expires May 18, 2017 [Page 38] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 ASN.1 encoding [ITU.X690.1994], and available as a "w" conversion in the "pack" function of several scripting languages. The function VS encodes a variable-length octet string into a uniquely-decoded, self-delimited octet string, as in the following manner: VS(s) = VI(length(s)) | s where length(s) is a number of octets (not characters) in s. Some examples: VI(0) = "\000" (in C string notation) VI(100) = "d" VI(10000) = "\316\020" VI(1000000) = "\275\204@" VS("") = "\000" VS("Tea") = "\003Tea" VS("Caf" [in UTF-8]) = "\005Caf\303\251" VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets) (Note: Unlike the colon-separated notion used in the Basic/Digest HTTP authentication scheme, the string generated by a concatenation of the VS-encoded strings will be unique, regardless of the characters included in the strings to be encoded.) The function OCTETS converts an integer into the corresponding radix- 256 big-endian octet string having its natural length. See Section 3.2.3 for the definition of "natural length". The function INT converts an octet string into a natural number, where the input string is treated as being in radix-256 big-endian notation. The identity INT(OCTETS(n)) = n always holds for any natural number n. 12.2. Default Functions for Algorithms The functions defined in this section are common default functions among authentication algorithms. Oiwa, et al. Expires May 18, 2017 [Page 39] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 The client-side password-based (credential) pi used by this authentication is a natural number derived in the following manner: pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) | VS(realm) | VS(username), nIterPi, hSize / 8)), where o PBKDF2 is the password-based key derivation function defined in [RFC2898], o HMAC_H is the HMAC function, defined in [RFC2104], composed from the hash function H, and o hSize is the output size of hash H in bits. The values of algorithm, realm, and auth-scope are taken from the values contained in the 401-INIT message. If the password comes from user input, it SHOULD first be prepared according to the method presented in Section 9. Then, the password SHALL be encoded as a UTF-8 string. The values VK_c and VK_s are derived by the following equation. VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) | VS(vh))) VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) | VS(vh))) 13. Application Channel Binding Applications and upper-layer communication protocols may need authentication binding to the HTTP-layer authenticated user. Such applications MAY use the following values as a standard shared secret. These values are parameterized with an optional octet string (t) which may be arbitrarily chosen by each application or protocol. If there is no appropriate value to be specified, use an empty string for t. For applications requiring binding to either an authenticated user or a shared-key session (to ensure that the requesting client is certainly authenticated), the following value b_1 MAY be used. b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(0) Oiwa, et al. Expires May 18, 2017 [Page 40] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 | VS(vh)) | VS(t)). For applications requiring binding to a specific request (to ensure that the payload data is generated for the exact HTTP request), the following value b_2 MAY be used. b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) | VS(vh)) | VS(t)). Note: Channel bindings to lower-layer transports (TCP and TLS) are defined in Section 7. 14. Application for Proxy Authentication The authentication scheme defined by the previous sections can be applied (with modifications) for proxy authentication. In such cases, the following alterations MUST be applied: o The 407 status is to be sent and recognized in places where the 401 status is used, o Proxy-Authenticate header is to be used in places where WWW- Authenticate is used, o Proxy-Authorization header is to be used in places where Authorization is used, o Proxy-Authentication-Info header is to be used in places where Authentication-Info is used, o The auth-scope parameter is fixed to the host-name of the proxy, which means it covers all requests processed through the specific proxy, o The limitation for the paths contained in the path parameter of 401-KEX-S1 messages is disregarded, o The omission of the path parameter of 401-KEX-S1 messages means that the authentication realm will potentially cover all requests processed by the proxy, o The scheme, host name, and the port of the proxy is used for host validation tokens, and o Authentication extensions in [I-D.ietf-httpauth-extension] are not applicable. Oiwa, et al. Expires May 18, 2017 [Page 41] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 15. Methods to Extend This Protocol If a private extension to this protocol is implemented, it MUST use the extension-tokens defined in Section 3 to avoid conflicts with this protocol and other extensions. (Standardized or being- standardized extensions MAY use either bare-tokens or extension- tokens.) Specifications defining authentication algorithms MAY use other representations for the parameters "kc1", "ks1", "vkc", and "vks", replace those parameter names, and/or add parameters to the messages containing those parameters in supplemental specifications, provided that syntactic and semantic requirements in Section 3, [RFC7230] and [RFC7235] are satisfied. Any parameters starting with "kc", "ks", "vkc" or "vks" and followed by decimal natural numbers (e.g. kc2, ks0, vkc1, vks3 etc.) are reserved for this purpose. If those specifications use names other than those mentioned above, it is RECOMMENDED to use extension-tokens to avoid any parameter name conflict with future extensions to this protocol. Extension-tokens MAY be freely used for any non-standard, private, and/or experimental uses for those parameters provided that the domain part in the token is used in the manner defined in Section 3. 16. IANA Considerations This document requires an additional entry to the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" as follows: o Authentication Scheme Name: "Mutual" o Pointer to specification text: (this document) When bare-tokens are used for the authentication-algorithm and validation parameters, these MUST be allocated by IANA. To acquire registered tokens, the usage of such tokens MUST be reviewed by a designated expert, as outlined in [RFC5226]. 16.1. Registry for Authentication Algorithms This document establishes a registry for HTTP Mutual authentication algorithms. The registry manages case-insensitive ASCII strings. The strings MUST follow the extensive-token syntax defined in Section 3. Registrations for an authentication algorithm are required to include a description of the authentication algorithms. Reviewers assigned Oiwa, et al. Expires May 18, 2017 [Page 42] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 by IESG are advised to examine minimum security requirements and consistency of the key exchange algorithm descriptions. New registrations are advised to provide the following information: o Token: a token used in HTTP headers for identifying the algorithm. o Description: A brief description of the algorithm. o Specification: A reference for a specification defining the algorithm. The initial content of this registry is empty. [[Editorial Note: A separate document [I-D.ietf-httpauth-mutual-algo] will effectively define the initial content of the registry.]] 16.2. Registry for Validation Methods This document establishes a registry for HTTP Mutual authentication host validation methods. The registry manages case-insensitive ASCII strings. The strings MUST follow the extensive-token syntax defined in Section 3. Registrations for a validation method are required to include a description of the validation method. Reviewers assigned by IESG are advised to examine its use-case requirements and security consequence of its introduction. New registrations are advised to provide the following information: o Token: a token used in HTTP headers for identifying the method. o Description: A brief description of the method. o Specification: A reference for a specification defining the method. The initial content of this registry is as follows: +----------------------+----------------------------+---------------+ | Token | Description | Specification | +----------------------+----------------------------+---------------+ | host | Host name verification | Section 7 | | | only | | | tls-server-end-point | TLS certificate-based | Section 7 | | tls-unique | TLS unique key-based | Section 7 | +----------------------+----------------------------+---------------+ Oiwa, et al. Expires May 18, 2017 [Page 43] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 17. Security Considerations 17.1. Security Properties o The protocol is secure against passive eavesdropping and replay attacks. However, the protocol relies on transport security including DNS integrity for data secrecy and integrity. HTTP/TLS SHOULD be used where transport security is not assured and/or data confidentiality is important. o When used with HTTP/TLS, if TLS server certificates are reliably verified, the protocol provides true protection against active man-in-the-middle attacks. o Even if the server certificate is not used or is unreliable, the protocol provides protection against active man-in-the-middle attacks for each HTTP request/response pair. However, in such cases, JavaScript or similar scripting facilities can be used to affect the Mutually-authenticated contents from other contents not protected by this authentication mechanism. This is the reason why this protocol requires that valid TLS server certificates MUST be presented (Section 7). 17.2. Secrecy of Credentials The client-side password credential MUST be kept secret all the time, and SHOULD NOT be used with any other (possibly insecure) authentication purpose. Loss of control of the credential will directly affect the control of corresponding server-side account. Use of client-side credential with THIS authentication scheme is always safe, even if the connected server peer is not trustful (condition of Phishing). However, if it is used with other authentication schemes (such as Web forms), and if the recipient is rogue, the result will be obvious. The server-side password credential (J) is also important to be kept secret. If it is stolen, and if the client's choice of password is not strong, the person aware of server-side password credential can employ a off-line dictionary attack to search for the client password. However, if the client has chosen a strong password, so that the attacker cannot guess the client's password from dictionary candidate, the client is still well protected from any attacks. The shared session secret (z) MUST be kept secret inside the server/ client software; if it is lost, and if the session is still active, it will lead to session hijacking. After the session is expired, the key is valueless for attackers. Oiwa, et al. Expires May 18, 2017 [Page 44] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 17.3. Denial-of-service Attacks to Servers The protocol requires a server-side table of active sessions, which may become a critical point for server resource consumption. For proper operation, the protocol requires that at least one key verification request is processed for each session identifier. After that, servers MAY discard sessions internally at any time, without causing any operational problems to clients. Clients will silently reestablish a new session then. However, if a malicious client sends too many requests for key exchanges (req-KEX-C1 messages) only, resource starvation might occur. In such critical situations, servers MAY discard any kind of existing sessions regardless of their statuses. One way to mitigate such attacks is that servers MAY have a number and a time limit for unverified, pending key exchange requests (in the "key exchanging" state). This is a common weakness of authentication protocols with almost any kind of negotiations or states, including Digest authentication scheme and most Cookie-based authentication implementations. However, regarding the resource consumption, the situation for the mutual authentication scheme is a slightly better than for Digest, because HTTP requests without any kind of authentication requests will not generate any kind of sessions. Session identifiers are only generated after a client starts a key negotiation. It means that simple clients such as Web crawlers will not accidentally consume server-side resources for session managements. 17.3.1. On-line Active Password Attacks Although the protocol provides very strong protection against off- line dictionary attacks from eavesdropped traffic, the protocol, by its nature, cannot prevent active password attacks in which the attackers sends so many authentication trial requests for every possible password. Possible countermeasures for preventing such attacks may be rate- limiting of password authentication trials, statistics-based intrusion detection measures, or similar protection schemes. If the server operators assume that the passwords of users are not strong enough, it may be desirable to introduce such ad-hoc countermeasures. 17.4. Communicating the status of mutual authentication with users This protocol is designed for two goals. The first goal is just providing a secure alternative for existing Basic and Digest authentication. The second goal is to provide users a way to detect Oiwa, et al. Expires May 18, 2017 [Page 45] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 forged rogue servers imitating a user's registered account on a server, commonly known as (a part or kind of) Phishing attacks. For this protocol to effectively work as some countermeasure to such attacks, it is very important that end users of clients be notified of the result of the mutual authentication performed by this protocol, especially the three states "AUTH-SUCCEED", "UNAUTHENTICATED", and "AUTH-REQUIRED" defined in Section 10. The design of secure user interfaces of the HTTP interactive clients is out of the scope of this document, but if possible, having some kind of UI indication for the three states above will be desirable for the user's security benefit. Of course, in such cases, the user interfaces for asking passwords for this authentication shall be clearly identifiable against imitation by other insecure password input fields (such as forms). If the passwords are known to malicious attackers outside of the protocol, the protocol cannot work as an effective security measures. 17.5. Implementation Considerations o To securely implement the protocol, the Authentication-Info headers in the 200-VFY-S messages MUST always be validated by the client. If the validation fails, the client MUST NOT process any content sent with the message, including other headers and the body part. Non-compliance to this requirement will allow phishing attacks. o For HTTP/TLS communications, when a web form is submitted from Mutually-authenticated pages with the "tls-server-end-point" validation method to a URI that is protected by the same realm (so indicated by the path parameter), if the server certificate has been changed since the pages were received, the peer is RECOMMENDED to be re-validated using a req-KEX-C1 message with an "Expect: 100-continue" header. The same applies when the page is received with the "tls-unique" validation method, and when the TLS session has expired. o For better protection against possible password database stealing, server-side storage of user passwords should contain the values encrypted by the one-way function J(pi), instead of the real passwords or those hashed by pi. o If the TLS 1.2 is used for underlying HTTP/TLS communications, follow best practices in [RFC7525]. Oiwa, et al. Expires May 18, 2017 [Page 46] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 17.6. Usage Considerations o The user names inputted by a user may be sent automatically to any servers sharing the same auth-scope. This means that when a host- type auth-scope is used for authentication on an HTTPS site, and when an HTTP server on the same host requests Mutual authentication within the same realm, the client will send the user name in clear text. If user names have to be kept secret against eavesdropping, the server must use the full-scheme-type auth-scope parameter and HTTPS. Contrarily, passwords are not exposed to eavesdroppers even on HTTP requests. o If the server provides several ways for storing server-side password secrets in the password database, it is desirable for better security to store the values encrypted by using the one-way function J(pi), instead of the real passwords or those hashed by pi. 18. References 18.1. Normative References [I-D.ietf-httpauth-extension] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "HTTP Authentication Extensions for Interactive Clients", draft-ietf-httpauth-extension-09 (work in progress), August 2016. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/ RFC2898, September 2000, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . Oiwa, et al. Expires May 18, 2017 [Page 47] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . [RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, . [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, . [Unicode] The Unicode Consortium, "The Unicode Standard", . 18.2. Informative References [I-D.ietf-httpauth-mutual-algo] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: Oiwa, et al. Expires May 18, 2017 [Page 48] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 KAM3-based Cryptographic Algorithms", draft-ietf-httpauth-mutual-algo-07 (work in progress), November 2016. [ITU.X690.1994] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ RFC2818, May 2000, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/ RFC7486, March 2015, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Oiwa, et al. Expires May 18, 2017 [Page 49] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, . [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/ RFC7616, September 2015, . [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, . Appendix A. (Informative) Draft Change Log [To be removed on final publication] A.1. Changes in Httpauth WG Revision 11 o Reflecting IESG comments. A.2. Changes in Httpauth WG Revision 10 o Small rephrasing and a typo fix. A.3. Changes in Httpauth WG Revision 09 o Reflected AD review comments. o Authors' addresses updated. A.4. Changes in Httpauth WG Revision 08 o Minor text update, in sync with httpauth-extension. o The version token is raised to "1". Oiwa, et al. Expires May 18, 2017 [Page 50] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 A.5. Changes in Httpauth WG Revision 07 o Several comments from reviewers are reflected to the text. o The password-hash has been completely dropped. o The version token is raised to "1". A.6. Changes in Httpauth WG Revision 06 o The auth-domain parameter has been renamed to auth-scope, following suggestions on the mailing list. o The digest-md5 password-hash has been dropped, as Digest with MD5 hash is now obsoleted. A.7. Changes in Httpauth WG Revision 05 o Minimum nonce number window has increased to 128. (HTTP 2.0 recommends at least 100 concurrent sessions to exist) o Reference to TLS session hash extension added for tls-unique security issues. o Comments in the previous F2F meeting has been reflected to the text. A.8. Changes in Httpauth WG Revision 04 o Merged httpauthprep proposal into general PRECIS Username/Password profile. o Adopting RFC 5987 extended syntax for non-ASCII parameter values. o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. This results in a different syntax for that header. A.9. Changes in Httpauth WG Revision 03 o Incompatible change: Single-port type authentication realm label has been changed to harmonize with Web Origin. (That is, the default ports (80 and 443) are to be omitted.) A.10. Changes in Httpauth WG Revision 02 o Major change: introduction of password-strengthening function PBKDF2. Oiwa, et al. Expires May 18, 2017 [Page 51] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 o Changed Section 10 to adopt "list of requirements" style. Strict definition of state machine is now a derived, informational definition. A.11. Changes in Httpauth WG Revision 01 o Changed "tls-key" verification to "tls-unique" verification, and "tls-cert" to "tls-server-end-point", adopting RFC 5929. o Adopted PRECIS framework [RFC7564]. o Reverted reservation of "rekey-sid" and "rekey-method" parameters. o Degraded secure UI requirement to application note level, non- normative. o Adjusted levels of several requirements. o Added warning text for handling of exceptional 5XX responses. o Dropped several references for optional authentications, except one "Note". o Several textual fixes, improvements and revisions. A.12. Changes in Httpauth Revision 00 o Changed the version token. o Renamed "verification tokens" to "Host verification tokens" and variables "v" to "vh" for clarification. (Back-ported from draft-oiwa-httpauth-multihop-template-00) A.13. Changes in HttpBis Revision 00 None. A.14. Changes in Revision 12 o Added a reason "authz-failed". A.15. Changes in Revision 11 o Message syntax definition reverted to pre-07 style as httpbis-p1 and p7 now defines a precise rule for parameter value parsing. o Replaced "stale" parameter with more informative/extensive "reason" parameter in 401-INIT and 401-STALE. Oiwa, et al. Expires May 18, 2017 [Page 52] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 o Reserved "rekey-sid" and "rekey-method" parameters for future extensions. o Added descriptions for replacing/non-replacing existing technologies. A.16. Changes in Revision 10 o The authentication extension parts (non-mandatory authentication and authentication controls) are separated to yet another draft. o The default auth-domain parameter is changed to the full scheme- host-port syntax, which is consistent with usual HTTP authentication framework behavior. o Provision for application channel binding is added. o Provision for proxy access authentication is added. o Bug fix: syntax specification of sid parameter was wrong: it was inconsistent with the type specified in the main text (the bug introduced in -07 draft). o Terminologies for headers are changed to be in harmony with httpbis drafts (e.g. field to parameter). o Syntax definitions are changed to use HTTP-extended ABNF syntax, and only the header values are shown for header syntax, in harmony with httpbis drafts. o Names of parameters and corresponding mathematical values are now renamed to more informative ones. The following list shows correspondence between the new and the old names. +------------+----------+-------------------------------------------+ | new name | old name | description | +------------+----------+-------------------------------------------+ | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | | | | components | | kc1, ks1 | wa, wb | parameter names for those | | VK_c, VK_s | o_a, o_b | client/server-side key verifiers | | vkc, vks | oa, ob | parameter names for those | | z | z | session secrets | +------------+----------+-------------------------------------------+ Oiwa, et al. Expires May 18, 2017 [Page 53] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 A.17. Changes in Revision 09 o The (default) cryptographic algorithms are separated to another draft. o Names of the messages are changed to more informative ones than before. The following is the correspondence table of those names: +-------------------+-----------------+-----------------------------+ | new name | old name | description | +-------------------+-----------------+-----------------------------+ | 401-INIT | 401-B0 | initial response | | 401-STALE | 401-B0-stale | session shared secret | | | | expired | | req-KEX-C1 | req-A1 | client->server key exchange | | 401-KEX-S1 | 401-B1 | server->client key exchange | | req-VFY-C | req-A3 | client->server auth. | | | | verification | | 200-VFY-S | 200-B4 | server->client auth. | | | | verification | | 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory | | | | authentication | +-------------------+-----------------+-----------------------------+ A.18. Changes in Revision 08 o The English text has been revised. A.19. Changes in Revision 07 o Adapt to httpbis HTTP/1.1 drafts: * Changed definition of extensive-token. * LWSP continuation-line (%0D.0A.20) deprecated. o To simplify the whole spec, the type of nonce-counter related parameters are change from hex-integer to integer. o Algorithm tokens are renamed to include names of hash algorithms. o Clarified the session management, added details of server-side protocol decisions. o The whole draft was reorganized; introduction and overview has been rewritten. Oiwa, et al. Expires May 18, 2017 [Page 54] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 A.20. Changes in Revision 06 o Integrated Optional Mutual Authentication to the main part. o Clarified the decision procedure for message recognitions. o Clarified that a new authentication request for any sub-requests in interactive clients may be silently discarded. o Typos and confusing phrases are fixed. o Several "future considerations" are added. A.21. Changes in Revision 05 o A new parameter called "version" is added for supporting future incompatible changes with a single implementation. In the (first) final specification its value will be changed to 1. o A new header "Authentication-Control" is added for precise control of application-level authentication behavior. A.22. Changes in Revision 04 o Changed text of patent licenses: the phrase "once the protocol is accepted as an Internet standard" is removed so that the sentence also covers the draft versions of this protocol. o The "tls-key" verification is now OPTIONAL. o Several description fixes and clarifications. A.23. Changes in Revision 03 o Wildcard domain specifications (e.g. "*.example.com") are allowed for auth-domain parameters (Section 4.1). o Specification of the tls-cert verification is updated (incompatible change). o State transitions fixed. o Requirements for servers concerning w_a values are clarified. o RFC references are updated. Oiwa, et al. Expires May 18, 2017 [Page 55] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 A.24. Changes in Revision 02 o Auth-realm is extended to allow full-scheme type. o A decision diagram for clients and decision procedures for servers are added. o 401-B1 and req-A3 messages are changed to contain authentication realm information. o Bugs on equations for o_A and o_B are fixed. o Detailed equations for the entire algorithm are included. o Elliptic-curve algorithms are updated. o Several clarifications and other minor updates. A.25. Changes in Revision 01 o Several texts are rewritten for clarification. o Added several security consideration clauses. Authors' Addresses Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: y.oiwa@aist.go.jp Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: h-watanabe@aist.go.jp Oiwa, et al. Expires May 18, 2017 [Page 56] Internet-Draft Mutual Authentication Protocol for HTTP November 2016 Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: takagi.hiromitsu@aist.go.jp Kaoru Maeda Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Email: maeda@lepidum.co.jp Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Email: hayashi@lepidum.co.jp Yuichi Ioku Individual Email: mutual-work@ioku.org Oiwa, et al. Expires May 18, 2017 [Page 57] ./draft-ietf-justfont-toplevel-06.txt0000664000764400076440000010606313024047252017071 0ustar iustyiusty Network Working Group C. Lilley Internet-Draft W3C Intended status: Standards Track December 13, 2016 Expires: June 16, 2017 The font Top Level Type draft-ietf-justfont-toplevel-06 Abstract This memo serves to register and document the "font" Top Level Type, under which the Internet Media subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 16, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Lilley Expires June 16, 2017 [Page 1] Internet-Draft The font Top Level Type December 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Specification Development [Note to the RFC Editor: Please remove this section upon publication.] This section is non-normative. The source for this specification is maintained on GitHub [1]. The issues list [2] is also on GitHub. Discussion should be on the mailing list justfont@ietf.org [3]. 2. Introduction The process of setting type in computer systems and other forms of text presentation systems uses fonts in order to provide visual representations of the glyphs. Just as with images, for example, there are a number of ways to represent the visual information of the glyphs. Early font formats often used bitmaps, as these could have been carefully tuned for maximum readability at a given size on low- resolution displays. More recently, scalable vector outline fonts have come into widespread use: in these fonts, the outlines of the glyphs are described, and the presentation system renders the outline in the desired position and size. Over time, a number of standard formats for recording font descriptions have evolved. This document defines a new top-level Internet Media Type "font" according to Section 4.2.7 of [RFC6838]. This top-level type indicates that the content specifies font data. Under this top-level type, different representation formats of fonts may be registered. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Background and Justification Historically there has not been a registration of formats for fonts. More recently, there have been several representation formats registered as media subtypes under the "application" top-level type (for example, application/font-woff). However, with the rapid adoption of web fonts (based on the data from HTTP Archive [HTTP-Archive-Trends] showing a huge increase in web font usage from 1% in the end of 2010 to 50% across all sites in the beginning of 2015) custom fonts on the web have become a core web resource. As the in-depth analysis [Font-Media-Type-Analysis] shows, the lack of the intuitive top-level font type is causing significant confusion Lilley Expires June 16, 2017 [Page 2] Internet-Draft The font Top Level Type December 2016 among developers - while currently defined font subtypes are severely under-utilized there are many more sites that already use non- existent (but highly intuitive) media types such as "font/woff", "font/ttf" and "font/truetype". At the same time, the majority of sites resort to using generic types such as "application/octet- stream", "text/plain" and "text/html"; or use unregistrable types such as "application/x-font-ttf". Contrary to the expectations of the W3C WebFonts Working Group which developed WOFF, the officially defined media types such as "application/font-woff" and "application/font-sfnt" see a very limited use - their adoption rates trail far behind as the actual use of web fonts continues to increase. The members of the W3C WebFonts WG concluded that the use of "application" top-level type is not ideal. First, the "application" sub-tree is treated (correctly) with great caution with respect to viruses and other active code. Secondly, the lack of a top-level type means that there is no opportunity to have a common set of optional parameters, such as are specified here. Third, fonts have a unique set of licensing and usage restrictions, which makes it worthwhile to identify this general category with a unique top-level type. The W3C WebFonts WG decided [WG-tlt] that the situation can be significantly improved if a set of font media types is registered using "font" as a dedicated top-level type. Based on the data analysis presented above, we conclude that it is the presence of simple and highly intuitive media types for images that caused their widespread adoption, where the correct usage of existing media types reaches over 97% for all subtypes in the "image" tree. The WG considers that, considering a rapid adoption of fonts on the web, the registration of the top-level media type for fonts along with the intuitive set of subtypes that reflect popular and widely used data formats would further stimulate the adoption of web fonts, significantly simplify web server configuration process and facilitate the proper use of media types for fonts. 4. Security Considerations Fonts are interpreted data structures that represent collections of different tables containing data that represent different types of information, including glyph outlines in various formats, hinting instructions, metrics and layout information for multiple languages and writing systems, rules for glyph substitution and positioning, etc. In particular, the hinting instructions for TrueType glyphs represent executable code which has the potential to be maliciously constructed (for example, intended to hang the interpreter). There are many existing, already standardized font table tags and formats that allow an unspecified number of entries containing predefined Lilley Expires June 16, 2017 [Page 3] Internet-Draft The font Top Level Type December 2016 data fields for storage of variable length binary data. Many existing font formats (TrueType [truetype-wiki], OpenType and OFF [opentype-wiki], SIL Graphite, WOFF, etc.) are based on the table- based SFNT (scalable font) format which is extremely flexible, highly extensible and offers an opportunity to introduce additional table structures when needed, in an upward-compatible way that would not affect existing font rendering engines and text layout implementations. However, this very extensibility may present specific security concerns - the flexibility and ease of adding new data structures makes it easy for any arbitrary data to be hidden inside a font file. There is a significant risk that the flexibility of font data structures may be exploited to hide malicious binary content disguised as a font data component. Fonts may contain 'hints', which are programmatic instructions that are executed by the font engine for the alignment of graphical elements of glyph outlines with the target display pixel grid. Depending on the font technology utilized in the creation of a font these hints may represent active code interpreted and executed by the font rasterizer. Even though hints operate within the confines of the glyph outline conversion system and have no access outside the font rendering engine, hint instructions can be, however, quite complex, and a maliciously designed complex font could cause undue resource consumption (e.g. memory or CPU cycles) on a machine interpreting it. Indeed, fonts are sufficiently complex that most (if not all) interpreters cannot be completely protected from malicious fonts without undue performance penalties. Widespread use of fonts as necessary components of visual content presentation warrants that careful attention should be given to security considerations whenever a font is either embedded into an electronic document or transmitted alongside media content as a linked resource. While many existing font formats provide certain levels of protection of data integrity (such mechanisms include e.g. checksums and digital signatures), font data formats provide neither privacy nor confidentiality protection internally; if needed, such protection should be provided externally. 5. IANA Considerations This specification registers a new top-level type, "font", in the standards tree; adds it as an alternative value of "Type Name" in the media types registration form [Media-Type-Registration]; and registers several subtypes for it. Lilley Expires June 16, 2017 [Page 4] Internet-Draft The font Top Level Type December 2016 5.1. Definition and Encoding The "font" as the primary media content type indicates that the content identified by it requires certain graphic subsystem such as font rendering engine (and, in some cases, text layout and shaping engine) to process it as font data, which in turn may require certain level of hardware capabilities such as certain levels of CPU performance and available memory. The "font" media type does not provide any specific information about the underlying data format and how the font information should be interpreted - the subtypes defined within a "font" tree name the specific font formats. Unrecognized sub-types of "font" should be treated as "application/octet-stream". Implementations may pass unrecognized subtypes to a common font- handling system, if such a system is available. 5.2. Fragment Identifiers for Font Collections Fragment identifiers for font collections identify one font in the collection by the PostScript name (name ID=6) [ISO.14496-22.2015]. This is a string, no longer than 63 characters and restricted to the printable ASCII subset, codes 33 - 126, except for the 10 characters '[', ']', '(', ')', '{', '}', '<', '>', '/', '%' which are forbidden by [ISO.14496-22.2015]. In addition, the following 6 characters could occur in the PostScript name but are forbidden in fragments by [RFC3986] and thus must be escaped: '"', '#', '\', '^', '`', '|'. If (following un-escaping) this string matches one of the PostScript names in the name table, that font is selected. For example, "#Foo- Bold" refers to the font with PostScript name "Foo-Bold" and "#Caret%5Estick" refers to the font with PostScript name "Caret^stick". If the name does not match, or if a fragment is not specified, the first font in the collection is matched. Note that the order of fonts in collections may change as the font is revised, so relying on a particular font in a collection always being first is unwise. 5.3. Registration Procedure New font formats should be registered using the online form [Media-Type-Registration]. RFC 6838 [RFC6838] should be consulted on registration procedures. In particular the font specification should preferably be freely available. If the font format can contain multiple fonts, a fragment identifier syntax should also be defined. Note that new parameter sub-values may be defined in the future. If an implementation does not recognize a sub-value in the comma- Lilley Expires June 16, 2017 [Page 5] Internet-Draft The font Top Level Type December 2016 separated list, it should ignore the sub-value and continue processing the other sub-values in the list. 5.4. Subtype Registrations In this section the initial entries under the top-level 'font' media type are specified. They also serve as examples for future registrations. For each subtype, an @font-face format identifer is listed. This is for use with the @font-face src descriptor, defined by the CSS3 Fonts specification [W3C.CR-css-fonts-3-20131003]. That specification is normative; the identifiers here are informative. 5.4.1. Generic SFNT Font Type Type name: font Subtype name: sfnt Required parameters: None. Optional parameters: 1) Name: outlines Values: a comma-separated subset of: TTF, CFF, SVG This parameter can be used to specify the type of outlines provided by the font. Value "TTF" shall be used when a font resource contains glyph outlines in TrueType format, value "CFF" shall be used to identify fonts containing PostScript/CFF outlines [cff-wiki], and value SVG [svg-wiki]shall be used to identify fonts that include SVG outlines. TTF, CFF or SVG outlines can be present in various combinations in the same font file, therefore, this optional parameter is a list containing one or more items, separated by commas. Order in the list is not significant. 2) Name: layout Values: a comma-separated subset of: OTL, AAT, SIL This parameter identifies the type of implemented support for advanced text layout features. The predefined values "OTL", "AAT" and "SIL" respectively indicate support for OpenType text layout, Apple Advanced Typography or Graphite SIL. More than one shaping and layout mechanism may be provided by the same font file, therefore, this optional parameter is a list Lilley Expires June 16, 2017 [Page 6] Internet-Draft The font Top Level Type December 2016 containing one or more items, separated by commas. Order in the list is not significant. Encoding considerations: Binary. Interoperability considerations: As it was noted in the first paragraph of the "Security considerations" section, a single font file can contain encoding of the same glyphs using several different representations, e.g., both TrueType and PostScript (CFF) outlines. Existing font rendering engines may not be able to process some of the particular outline formats, and downloading a font resource that contains only unsupported glyph data format would be futile. Therefore, it is useful to clearly identify the format of the glyph outline data within a font using an optional parameter, and allow applications to make decisions about downloading a particular font resource sooner. Similarly, another optional parameter identifies the type of text shaping and layout mechanism that is provided by a font. Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ WG11. Applications that use this media type: All applications that are able to create, edit or display textual media content. Note that font/sfnt is an abstract type, from which the (widely used in practice) font/ttf and font/otf types are conceptually derived. Use of font/sfnt is likely to be rare in practice, and might be confined to uncommon combinations such as font/sfnt; outlines=sil which do not have a shorter type cases where a new parameter value is registered test cases, experimentation, etc Additional information: Magic number(s): The TrueType fonts and OFF / OpenType fonts containing TrueType outlines should use 0x00010000 as the 'sfnt' version number. The OFF / OpenType fonts containing CFF data should use the tag 'OTTO' as 'sfnt' version number. Lilley Expires June 16, 2017 [Page 7] Internet-Draft The font Top Level Type December 2016 File extension(s): Font file extensions used for OFF / OpenType fonts: .ttf, .otf Typically, .ttf extension is only used for fonts containing TrueType outlines, while .otf extension can be used for any OpenType/OFF font, either with TrueType or CFF outlines. Macintosh file type code(s): (no code specified) Macintosh Universal Type Identifier code: "public.font" @font-face Format: none. Fragment Identifiers none. Deprecated Alias: The existing registration "application/font- sfnt" is deprecated in favor of "font/sfnt". Person & email address to contact for further information: Vladimir Levantovsky (vladimir.levantovsky@monotype.com). Intended usage: COMMON Restrictions on usage: None Author: The ISO/IEC 14496-22 "Open Font Format" specification is a product of the ISO/IEC JTC1 SC29/WG11. Change controller: The ISO/IEC has change control over this specification. 5.4.2. TTF Font Type Type name: font Subtype name: ttf Required parameters: None. Optional parameters: Name: layout Values: a comma-separated subset of: OTL, AAT, SIL This parameter identifies the type of support mechanism for advanced text layout features. The predefined values "OTL", "AAT" and "SIL" respectively indicate support for OpenType text layout, Apple Advanced Typography or Graphite SIL. More than one shaping and layout mechanism may be provided by the same Lilley Expires June 16, 2017 [Page 8] Internet-Draft The font Top Level Type December 2016 font file, therefore, this optional parameter is a list containing one or more items, separated by commas. Order in the list is not significant. Encoding considerations: Binary. Interoperability considerations: As it was noted in the first paragraph of the "Security considerations" section, a single font file can contain encoding of the same glyphs using several different representations, e.g., both TrueType and PostScript (CFF) outlines. Existing font rendering engines may not be able to process some of the particular outline formats, and downloading a font resource that contains only unsupported glyph data format would be futile. Therefore, it is useful to clearly identify the format of the glyph outline data within a font using an optional parameter, and allow applications to make decisions about downloading a particular font resource sooner. Similarly, another optional parameter identifies the type of text shaping and layout mechanism that is provided by a font. Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ WG11. Applications that use this media type: All applications that are able to create, edit or display textual media content. Additional information: Magic number(s): The TrueType fonts and OFF / OpenType fonts containing TrueType outlines should use 0x00010000 as the 'sfnt' version number. File extension(s): Font file extensions used for TrueType / OFF / OpenType fonts: .ttf, .otf Typically, .ttf extension is only used for fonts containing TrueType outlines, while .otf extension may be used for any OpenType/OFF font, either with TrueType or CFF outlines. Macintosh file type code(s): (no code specified) Macintosh Universal Type Identifier code: "public.truetype-font" @font-face Format: truetype Fragment Identifiers none. Lilley Expires June 16, 2017 [Page 9] Internet-Draft The font Top Level Type December 2016 Person & email address to contact for further information: Vladimir Levantovsky (vladimir.levantovsky@monotype.com). Intended usage: COMMON Restrictions on usage: None Author: The ISO/IEC 14496-22 "Open Font Format" specification is a product of the ISO/IEC JTC1 SC29/WG11. Change controller: The ISO/IEC has change control over this specification. 5.4.3. OTF Font Type Type name: font Subtype name: otf Required parameters: None. Optional parameters Name: outlines Values: a comma-separated subset of: TTF, CFF, SVG This parameter can be used to specify the type of outlines provided by the font. Value "TTF" shall be used when a font resource contains glyph outlines in TrueType format, value "CFF" shall be used to identify fonts containing PostScript/CFF outlines, and value SVG shall be used to identify fonts that include SVG outlines. TTF, CFF or SVG outlines can be present in various combinations in the same font file, therefore, this optional parameter is a list containing one or more items, separated by commas. Order in the list is not significant. Encoding considerations: Binary. Interoperability considerations: As it was noted in the first paragraph of the "Security considerations" section, a single font file can contain encoding of the same glyphs using several different representations, e.g., both TrueType and PostScript (CFF) outlines. Existing font rendering engines may not be able to process some of the particular outline formats, and downloading a font resource that contains only unsupported glyph data format would be futile. Therefore, it is useful to clearly identify the format of the glyph outline data within a font using an optional parameter, and allow applications to make decisions about downloading a particular font resource sooner. Similarly, another Lilley Expires June 16, 2017 [Page 10] Internet-Draft The font Top Level Type December 2016 optional parameter identifies the type of text shaping and layout mechanism that is provided by a font. Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ WG11. Applications that use this media type: All applications that are able to create, edit or display textual media content. Additional information: Magic number(s): The TrueType fonts and OFF / OpenType fonts containing TrueType outlines should use 0x00010000 as the 'sfnt' version number. The OFF / OpenType fonts containing CFF outlines should use the tag 'OTTO' as 'sfnt' version number. There is no magic number for SVG outlines; these are always accompanied by either TrueType or CFF outlines and thus use the corresponding magic number. File extension(s): Font file extensions used for OFF / OpenType fonts: .ttf, .otf Typically, .ttf extension is only used for fonts containing TrueType outlines, while .otf extension can be used for any OpenType/OFF font, either with TrueType, CFF or SVG outlines. Macintosh file type code(s): (no code specified) Macintosh Universal Type Identifier code: "public.opentype-font" @font-face Format: opentype Fragment Identifiers none. Person & email address to contact for further information: Vladimir Levantovsky (vladimir.levantovsky@monotype.com). Intended usage: COMMON Restrictions on usage: None Author: The ISO/IEC 14496-22 "Open Font Format" specification is a product of the ISO/IEC JTC1 SC29/WG11. Lilley Expires June 16, 2017 [Page 11] Internet-Draft The font Top Level Type December 2016 Change controller: The ISO/IEC has change control over this specification. 5.4.4. Collection Font Type Type name: font Subtype name: collection Required parameters: None. Optional parameters Name: outlines Values: a comma-separated subset of: TTF, CFF, SVG This parameter can be used to specify the type of outlines provided by the font. Value "TTF" shall be used when a font resource contains glyph outlines in TrueType format, value "CFF" shall be used to identify fonts containing PostScript/CFF outlines, and value SVG shall be used to identify fonts that include SVG outlines. TTF, CFF or SVG outlines can be present in various combinations in the same font file, therefore, this optional parameter is a list containing one or more items, separated by commas. Order in the list is not significant. Encoding considerations: Binary. Interoperability considerations: As it was noted in the first paragraph of the "Security considerations" section, a single font file can contain encoding of the same glyphs using several different representations, e.g., both TrueType and PostScript (CFF) outlines. Existing font rendering engines may not be able to process some of the particular outline formats, and downloading a font resource that contains only unsupported glyph data format would be futile. Therefore, it is useful to clearly identify the format of the glyph outline data within a font using an optional parameter, and allow applications to make decisions about downloading a particular font resource sooner. Similarly, another optional parameter identifies the type of text shaping and layout mechanism that is provided by a font. Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ WG11. Applications that use this media type: All applications that are able to create, edit or display textual media content. Lilley Expires June 16, 2017 [Page 12] Internet-Draft The font Top Level Type December 2016 Additional information: Magic number(s): The TrueType fonts and OFF / OpenType fonts containing TrueType outlines should use 0x00010000 as the 'sfnt' version number. The OFF / OpenType fonts containing CFF outlines should use the tag 'OTTO' as 'sfnt' version number. There is no magic number for SVG outlines; these are always accompanied by either TrueType or CFF outlines and thus use the corresponding magic number. File extension(s): Font file extensions used for OFF / TrueType and OpenType fonts: .ttc Macintosh file type code(s): (no code specified) Macintosh Universal Type Identifier code: "public.truetype- collection-font" @font-face Format: collection Fragment Identifiers: See Section 5.2. Person & email address to contact for further information: Vladimir Levantovsky (vladimir.levantovsky@monotype.com). Intended usage: COMMON Restrictions on usage: None Author: The ISO/IEC 14496-22 "Open Font Format" specification is a product of the ISO/IEC JTC1 SC29/WG11. Change controller: The ISO/IEC has change control over this specification. 5.4.5. WOFF 1.0 Type name: font Subtype name: woff Required parameters: None. Optional parameters: None. Encoding considerations: Binary. Lilley Expires June 16, 2017 [Page 13] Internet-Draft The font Top Level Type December 2016 Interoperability considerations: None. Published specification: This media type registration updates the WOFF specification [W3C.REC-WOFF-20121213] at W3C. Applications that use this media type: WOFF is used by Web browsers, often in conjunction with HTML and CSS. Additional information: Magic number(s): The signature field in the WOFF header MUST contain the "magic number" 0x774F4646 ('wOFF') File extension(s): woff Macintosh file type code(s): (no code specified) Macintosh Universal Type Identifier code: "org.w3.woff" @font-face Format: woff Fragment Identifiers: none. Deprecated Alias: The existing registration "application/font- woff" is deprecated in favor of "font/woff". Person & email address to contact for further information: Chris Lilley (www-font@w3.org). Intended usage: COMMON Restrictions on usage: None Author: The WOFF specification is a work product of the World Wide Web Consortium's WebFonts Working Group. Change controller: The W3C has change control over this specification. 5.4.6. WOFF 2.0 Type name: font Subtype name: woff2 Required parameters: None. Optional parameters: None. Lilley Expires June 16, 2017 [Page 14] Internet-Draft The font Top Level Type December 2016 Encoding considerations: Binary. Interoperability considerations: WOFF 2.0 is an improvement on WOFF 1.0. The two formats have different Internet Media Types, different @font-face formats, and may be used in parallel. Published specification: This media type registration is extracted from the WOFF 2.0 specification [W3C.CR-WOFF2-20150414] at W3C. Applications that use this media type: WOFF 2.0 is used by Web browsers, often in conjunction with HTML and CSS. Additional information: Magic number(s): The signature field in the WOFF header MUST contain the "magic number" 0x774F4632 ('wOF2') File extension(s): woff2 Macintosh file type code(s): (no code specified) Macintosh Universal Type Identifier code: "org.w3.woff2" @font-face Format: woff2 Fragment Identifiers: See Section 5.2. Person & email address to contact for further information: Chris Lilley (www-font@w3.org). Intended usage: COMMON Restrictions on usage: None Author: The WOFF2 specification is a work product of the World Wide Web Consortium's WebFonts Working Group. Change controller: The W3C has change control over this specification. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Lilley Expires June 16, 2017 [Page 15] Internet-Draft The font Top Level Type December 2016 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [W3C.CR-css-fonts-3-20131003] Daggett, J., "CSS Fonts Module Level 3", World Wide Web Consortium CR CR-css-fonts-3-20131003, October 2013, . [ISO.14496-22.2015] International Organization for Standardization, "Coding of audio-visual objects Part 22: Open Font Format", ISO Standard 14496-22, 10 2015, . [W3C.REC-WOFF-20121213] Kew, J., Leming, T., and E. Blokland, "WOFF File Format 1.0", World Wide Web Consortium Recommendation REC-WOFF- 20121213, December 2012, . [W3C.CR-WOFF2-20150414] Levantovsky, V. and R. Levien, "WOFF File Format 2.0", World Wide Web Consortium WD CR-WOFF2-20150414, March 2016, . 6.2. Informative References [cff-wiki] "CFF", . [opentype-wiki] "OpenType", . [truetype-wiki] "TrueType", . [svg-wiki] "SVG", . Lilley Expires June 16, 2017 [Page 16] Internet-Draft The font Top Level Type December 2016 [HTTP-Archive-Trends] Kuetell, D., "HTTP Archive trend analysis", March 2015, . [Font-Media-Type-Analysis] Kuetell, D., "Web Font Media Type (mime type) Analysis 2015", 2015, . [WG-tlt] W3C, "ACTION-164: Bring widely used top-level-type to w3c- ietf liaison", 2015, . [Media-Type-Registration] IANA, "Application for a Media Type", . 6.3. URIs [1] https://github.com/svgeesus/ietf-justfont [2] https://github.com/svgeesus/ietf-justfont/issues [3] mailto:justfont@ietf.org Author's Address Chris Lilley W3C 2004 Route des Lucioles Sophia Antipolis 06902 France Email: chris@w3.org Lilley Expires June 16, 2017 [Page 17] ./draft-ietf-i2rs-ephemeral-state-23.txt0000664000764400076440000006066413013135027017323 0ustar iustyiusty I2RS working group J. Haas Internet-Draft Juniper Intended status: Informational S. Hares Expires: May 20, 2017 Huawei November 16, 2016 I2RS Ephemeral State Requirements draft-ietf-i2rs-ephemeral-state-23.txt Abstract The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 20, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Haas & Hares Expires May 20, 2017 [Page 1] Internet-Draft I2RS Ephemeral State Requirements November 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Architectural Requirements for Ephemeral State . . . . . . . 3 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 4 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Ephemeral Configuration overlapping Local Configuration . 6 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 6 5. NETCONF Features for Ephemeral State . . . . . . . . . . . . 6 6. RESTCONF Features for Ephemeral State . . . . . . . . . . . . 6 7. Requirements regarding Supporting Multi-Head Control via client Priority . . . . . . . . . . . . . . . . . . . . . . . 6 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 8 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13.1. Normative References: . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Interface to the Routing System (I2RS) Working Group is chartered with providing architecture and mechanisms to inject into and retrieve information from the routing system. The I2RS Architecture document [RFC7921] abstractly documents a number of requirements for implementing the I2RS, and defines ephemeral state as "state which does not survive the reboot of a routing device or the reboot of the software handling the I2RS software on a routing device" (see section 1.1 of [RFC7921]). Section 2 describes the specific requirements which the I2RS working group has identified based on the I2RS architecture's abstract requirements. The I2RS Working Group has chosen to use the YANG data modeling language [RFC7950] as the basis to implement its mechanisms. Additionally, the I2RS Working group has chosen to re-use two existing protocols, NETCONF [RFC6241] and its similar but lighter- weight relative RESTCONF [I-D.ietf-netconf-restconf], as the protocols for carrying I2RS. Haas & Hares Expires May 20, 2017 [Page 2] Internet-Draft I2RS Ephemeral State Requirements November 2016 What does re-use of a protocol mean? Re-use means that while the combination of the YANG modeling language, and the NETCONF and RESTCONF protocols is a good starting basis for the I2RS data modeling language and protocol, the creation of I2RS protocol implementations requires that the I2RS requirements: 1. select features from the YANG modeling language, and the NETCONF and RESTCONF protocols per version of the I2RS protocol (See sections 4, 5, and 6) 2. propose additions to YANG, NETCONF, and RESTCONF per version of the I2RS protocol for key functions (ephemeral state, protocol security, publication/subscription service, traceability), The purpose of these requirements is to ensure clarity during I2RS protocol creation. Support for ephemeral state is an I2RS protocol requirement that requires datastore changes (see section 3), YANG additions (see section 4), NETCONF additions (see section 5), and RESTCONF additions (see section 6). Sections 7-9 provide details that expand upon the changes in sections 3-6 to clarify requirements discussed by the I2RS and NETCONF working groups. Section 7 provides additional requirements that detail how write-conflicts should be resolved if two I2RS client write the same data. Section 8 describes I2RS requirements for support of multiple message transactions. Section 9 highlights two requirements in the I2RS publication/subscription requirements [RFC7923] that must be expanded for ephemeral state. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Architectural Requirements for Ephemeral State The I2RS architecture [RFC7921] and the I2RS problem statement [RFC7920] define the important high-level requirements for the I2RS protocol in abstract terms. This section distills this high level abstract guidance into specific requirements for the I2RS protocol. To aid the reader, there are references back to the abstract descriptions in the I2RS architecture document and the I2RS problem statement, but the reader should note the requirements below are not explicitly stated in the I2RS architecture document [RFC7921] or in the I2RS problem statement [RFC7920]/ Haas & Hares Expires May 20, 2017 [Page 3] Internet-Draft I2RS Ephemeral State Requirements November 2016 Requirements: 1. The I2RS protocol SHOULD support an asynchronous programmatic interface with properties of described in section 5 of [RFC7920] (e.g. high throughput) with support for target information streams, filtered events, and thresholded events (real-time events) sent by an I2RS agent to an I2RS client (from section 1.1 of [RFC7921]). 2. I2RS agent MUST record the client identity when a node is created or modified. The I2RS agent SHOULD to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded. (from section 4 of [RFC7921].) 3. An I2RS client identity MUST have only one priority for the client's identifier. A collision on writes is considered an error, but the priority associated with each client identifier is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use. (from section 7.8 of [RFC7921].) 4. I2RS client's secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written. Just like the primary client identity, the secondary identity SHOULD only be recorded when the data node is written. (from sections 7.4 of [RFC7921].) 5. I2RS agent MAY have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS agent. (See section 7.8 of [RFC7921] augmented by the resource limitation language in section 8 [RFC7921].) 3. Ephemeral State Requirements In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state is defined as potentially including in a data model ephemeral configuration and operational state which is flagged as ephemeral. Haas & Hares Expires May 20, 2017 [Page 4] Internet-Draft I2RS Ephemeral State Requirements November 2016 3.1. Persistence Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. While at first glance this may seem equivalent to the writable- running data store in NETCONF, running-config can be copied to a persistent data store, like startup config. I2RS ephemeral state MUST NOT be persisted. 3.2. Constraints Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral state for constraint purposes; it SHALL be considered a validation error if it does. Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, such as MPLS LSP-ID (label switched path ID) or a BGP Adj-RIB-IN (Adjacent RIB Inboud). Ephemeral state constraints should be assessed when the ephemeral state is written, and if any of the constraints change to make the constraints invalid after that time the I2RS agent SHOULD notify the I2RS client. Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state. Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing [RFC7922], RPC or other mechanisms may lead to undesirable or unsustainable resource consumption on a system implementing an I2RS agent. It is RECOMMENDED that mechanisms be made available to permit prioritization of I2RS operations, when appropriate, to permit implementations to shed work load when operating under constrained resources. An example of such a work shedding mechanism is rate- limiting. 3.3. Hierarchy Ephemeral-REQ-06: YANG MUST have the ability to do the following: 1. to define a YANG module or submodule schema that only contains data nodes with the property of being ephemeral, and Haas & Hares Expires May 20, 2017 [Page 5] Internet-Draft I2RS Ephemeral State Requirements November 2016 2. to augment a YANG model with additional YANG schema nodes that have the property of being ephemeral. 3.4. Ephemeral Configuration overlapping Local Configuration Ephemeral-REQ-07: Local configuration MUST have a priority that is comparable with individual I2RS client priorities for making changes. This priority will determine whether local configuration changes or individual ephemeral configuration changes take precedence as described in RFC7921. The I2RS protocol MUST support this mechanism. 4. YANG Features for Ephemeral State Ephemeral-REQ-08:In addition to config true/false, there MUST be a way to indicate that YANG schema nodes represent ephemeral state. It is desirable to allow for, and have a way to indicate, config false YANG schema nodes that are writable operational state. 5. NETCONF Features for Ephemeral State Ephemeral-REQ-09: The changes to NETCONF must include: 1. Support for communication mechanisms to enable an I2RS client to determine that an I2RS agent supports the mechanisms needed for I2RS operation. 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 6. RESTCONF Features for Ephemeral State Ephemeral-REQ-10: The conceptual changes to RESTCONF are: 1. Support for communication mechanisms to enable an I2RS client to determine that an I2RS agent supports the mechanisms needed for I2RS operation. 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 7. Requirements regarding Supporting Multi-Head Control via client Priority To support multi-headed control, I2RS requires that there be a decidable means of arbitrating the correct state of data when multiple clients attempt to manipulate the same piece of data. This Haas & Hares Expires May 20, 2017 [Page 6] Internet-Draft I2RS Ephemeral State Requirements November 2016 is done via a priority mechanism with the highest priority winning. This priority is per-client. Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol in order to support I2RS client identity and priority: o the data nodes MUST store I2RS client identity and MAY store the effective priority at the time the data node is stored. o Per SEC-REQ-07 in section 4.3 of [I-D.ietf-i2rs-protocol-security-requirements], an I2RS Identifier MUST have just one priority. The I2RS protocol MUST support the ability to have data nodes store I2RS client identity and not the effective priority of the I2RS client at the time the data node is stored. o The priority MAY be dynamically changed by AAA, but the exact actions are part of the protocol definition as long as collisions are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. Ephemeral-REQ-12: When a collision occurs as two I2RS clients are trying to write the same data node, this collision is considered an error. The I2RS priorities are used to provide a deterministic resolution to the conflict. When there is a collision, and the data node is changed, a notification (which includes indicating data node the collision occurred on) MUST be sent to the original client to give the original client a chance to deal with the issues surrounding the collision. The original client may need to fix their state. Explanation: RESTCONF and NETCONF updates can come in concurrently from alternative sources. Therefore the collision detection and comparison of priority needs to occur for any type of update. For example, RESTCONF tracks the source of configuration change via the entity-Tag (section 3.5.2 of [I-D.ietf-netconf-restconf]) which the server returns to the client along with the value in GET or HEAD methods. RESTCONF requires that this resource entity-tag be updated whenever a resource or configuration resource within the resource is altered. In the RESTCONF processing, when the resource or a configuration resource within the resource is altered, then the processing of the configuration change for two I2RS clients must detect an I2RS collision and resolve the collision using the priority mechanism. Ephemeral-REQ-13: Multi-headed control is required for collisions and the priority resolution of collisions. Multi-headed control is not tied to ephemeral state. I2RS protocol MUST NOT mandate the internal Haas & Hares Expires May 20, 2017 [Page 7] Internet-Draft I2RS Ephemeral State Requirements November 2016 mechanism for how AAA protocols (E.g. Radius or Diameter) or mechanisms distribute priority per identity except that any AAA protocols MUST operate over a secure transport layer (See Radius [RFC6614] and Diameter [RFC6733]. Mechanisms that prevent collisions of two clients trying to modify the same node of data are the focus. Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST be provided to handle the error scenario that two clients, with the same priority, update the same configuration data node. The I2RS architecture gives one way that this could be achieved, by specifying that the first update wins. Other solutions, that prevent oscillation of the config data node, are also acceptable. 8. Multiple Message Transactions Ephemeral-REQ-15: Section 7.9 of the [RFC7921] states the I2RS architecture does not include multi-message atomicity and roll-back mechanisms. The I2RS protocol implementation MUST NOT require the support of these features. As part of this requirement, the I2RS protocol should support: multiple operations in one messge; an error in one operation MUST NOT stop additional operations from being carried out nor can it cause previous operations to be rolled back. multiple operations in multiple messages, but multiple message commands error handling MUST NOT insert errors into the I2RS ephemeral state. 9. Pub/Sub Requirements Expanded for Ephemeral State I2RS clients require the ability to monitor changes to ephemeral state. While subscriptions are well defined for receiving notifications, the need to create a notification set for all ephemeral configuration state may be overly burdensome to the user. There is thus a need for a general subscription mechanism that can provide notification of changed state, with sufficient information to permit the client to retrieve the impacted nodes. This should be doable without requiring the notifications to be created as part of every single I2RS module. The publication/subscription requirements for I2RS are in [RFC7923], and the following general requirements SHOULD be understood to be expanded to include ephemeral state: Haas & Hares Expires May 20, 2017 [Page 8] Internet-Draft I2RS Ephemeral State Requirements November 2016 o Pub-Sub-REQ-01: The Subscription Service MUST support subscriptions against ephemeral state in operational data stores, configuration data stores or both. o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so that subscribed updates under a target node might publish only ephemeral state in operational data or configuration data, or publish both ephemeral and operational data. o Pub-Sub-REQ-03: The subscription service MUST support subscriptions which are ephemeral. (E.g. An ephemeral data model which has ephemeral subscriptions.) 10. IANA Considerations There are no IANA requirements for this document. 11. Security Considerations The security requirements for the I2RS protocol are covered in [I-D.ietf-i2rs-protocol-security-requirements] document. The security requirements for the I2RS protocol environment are in [I-D.ietf-i2rs-security-environment-reqs]. 12. Acknowledgements This document is an attempt to distill lengthy conversations on the I2RS mailing list for an architecture that was for a long period of time a moving target. Some individuals in particular warrant specific mention for their extensive help in providing the basis for this document: o Alia Atlas, o Andy Bierman, o Martin Bjorklund, o Dean Bogdanavich, o Rex Fernando, o Joel Halpern, o Thomas Nadeau, o Juergen Schoenwaelder, Haas & Hares Expires May 20, 2017 [Page 9] Internet-Draft I2RS Ephemeral State Requirements November 2016 o Kent Watsen, o Robert Wilton, and o Joe Clarke, 13. References 13.1. Normative References: [I-D.ietf-i2rs-protocol-security-requirements] Hares, S., Migault, D., and J. Halpern, "I2RS Security Related Requirements", draft-ietf-i2rs-protocol-security- requirements-17 (work in progress), September 2016. [I-D.ietf-i2rs-security-environment-reqs] Migault, D., Halpern, J., and S. Hares, "I2RS Environment Security Requirements", draft-ietf-i2rs-security- environment-reqs-02 (work in progress), November 2016. [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem Statement for the Interface to the Routing System", RFC 7920, DOI 10.17487/RFC7920, June 2016, . Haas & Hares Expires May 20, 2017 [Page 10] Internet-Draft I2RS Ephemeral State Requirements November 2016 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, . [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, . [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . 13.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Jeff Haas Juniper Email: jhaas@juniper.net Susan Hares Huawei Saline US Email: shares@ndzh.com Haas & Hares Expires May 20, 2017 [Page 11] ./draft-ietf-i2rs-protocol-security-requirements-17.txt0000664000764400076440000013157312773215611022505 0ustar iustyiusty I2RS working group S. Hares Internet-Draft Huawei Intended status: Informational D. Migault Expires: April 2, 2017 J. Halpern Ericsson September 29, 2016 I2RS Security Related Requirements draft-ietf-i2rs-protocol-security-requirements-17 Abstract This presents security-related requirements for the I2RS protocol which provides a new interface to the routing system described in the I2RS architecture document (RFC7921). The I2RS protocol is a re-use protocol implemented by re-using portions of existing IETF protocols and adding new features to these protocols. The I2RS protocol re- uses security features of a secure transport (E.g. TLS, SSH, DTLS) such as encryption, message integrity, mutual peer authentication, and replay protection. The new I2RS features to consider from a security perspective are: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier which identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport. This document provides the detailed requirements for these security features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 2, 2017. Hares, et al. Expires April 2, 2017 [Page 1] Internet-Draft I2RS Security Requirements September 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Security Definitions . . . . . . . . . . . . . . . . . . 4 2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5 3. Security Features and Protocols: Re-used and New . . . . . . 7 3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7 3.2. New Features Related to Security . . . . . . . . . . . . 8 3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security-Related Requirements . . . . . . . . . . . . . . . . 10 4.1. I2RS Peers(agent and client) Identity Authentication . . 10 4.2. Identity Validation Before Role-Based Message Actions . . 11 4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12 4.4. Multi-Channel Transport: Secure Transport and Insecure Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Management Protocol Security . . . . . . . . . . . . . . 15 4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16 4.7. Security of the environment . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Hares, et al. Expires April 2, 2017 [Page 2] Internet-Draft I2RS Security Requirements September 2016 1. Introduction The Interface to the Routing System (I2RS) provides read and write access to information and state within the routing system. An I2RS client interacts with one or more I2RS agents to collect information from network routing systems. [RFC7921] describes the architecture of this interface, and this documents assumes the reader is familiar with this architecture and its definitions. Section 2 highlights some of the references the reader is required to be familiar with. The I2RS interface is instantiated by the I2RS protocol connecting an I2RS client and an I2RS agent associated with a routing system. The I2RS protocol is a re-use protocol implemented by re-using portions of existing IETF protocols, and adding new features to these protocols. As a re-use protocol, it can be considered a higher-level protocol since it can be instantiated in multiple management protocols (e.g. NETCONF [RFC6241] or RESTCONF [I-D.ietf-netconf-restconf]) operating over a secure transport. The security for the I2RS protocol comes from the management protocols operating over a a secure transport. This document is part of the requirements for I2RS protocol which also include: o I2RS architecture [RFC7921], o I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state], o publication/subscription requirements [RFC7922], and o traceability [RFC7923]. Since the I2RS "higher-level" protocol changes the interface to the routing systems, it is important that implementers understand the new security requirements for the environment the I2RS protocol operates in. These security requirements for the I2RS environment are specified in [I-D.ietf-i2rs-security-environment-reqs]; and the summary of the I2RS protocol security environment is found in the I2RS Architecture [RFC7920]. I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which support encryption, message integrity, peer authentication, and key distribution protocols. Optionally, implementers may utilize AAA protocols (Radius over TLS or Diameter over TLS) to securely distribute identity information. Section 3 provides an overview of security features and protocols being re-used (section 3.1) and the new security features being Hares, et al. Expires April 2, 2017 [Page 3] Internet-Draft I2RS Security Requirements September 2016 required (section 3.2). Section 3 also explores how existing and new security features and protocols would be paired with existing IETF management protocols (section 3.3). The new features I2RS extends to these protocols are a priority mechanism to handle multi-headed writes, an opaque secondary identifier to allow traceability of an application utilizing a specific I2RS client to communicate with an I2RS agent, and insecure transport constrained to be utilized only for read-only data, which may include publically available data (e.g. public BGP Events, public telemetry information, web service availability) and some legacy data. Section 4 provides the I2RS protocol security requirements by the following security features: o peer identity authentication (section 4.1), o peer identity validation before role-based message actions (section 4.2) o peer identity and client redundancy (section 4.3), o multi-channel transport requirements: Secure transport and insecure Transport (section 4.4), o management protocol security requirements (section 4.5), o role-based security (section 4.6), o security environment (section 4.7) Protocols designed to be I2RS higher-layer protocols need to fulfill these security requirements. 2. Definitions 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Security Definitions This document utilizes the definitions found in the following documents: [RFC4949] and [RFC7921] Hares, et al. Expires April 2, 2017 [Page 4] Internet-Draft I2RS Security Requirements September 2016 Specifically, this document utilizes the following definitions from [RFC4949]: o access control, o authentication, o data confidentiality, o data integrity, o data privacy, o identity, o identifier, o mutual authentication, o role, o role-based access control, o security audit trail, and o trust. [RFC7922] describes traceability for I2RS interface and the I2RS protocol. Traceability is not equivalent to a security audit trail or simple logging of information. A security audit trail may utilize traceability information. This document also requires that the user is familiar with the pervasive security requirements in [RFC7258]. 2.3. I2RS Specific Definitions The document utilizes the following concepts from the I2RS architecture: [RFC7921]: o I2RS client, I2RS agent, and I2RS protocol (section 2), o I2RS higher-layer protocol (section 7.2) o scope: read scope, notification scope, and write scope (section 2), o identity and scope of the identity (section 2), Hares, et al. Expires April 2, 2017 [Page 5] Internet-Draft I2RS Security Requirements September 2016 o roles or security rules (section 2), o identity and scope, and secondary identity (section 2), o routing system/subsytem (section 2), o I2RS assumed security environment (section 4), o I2RS identity and authorization (section 4.1), o I2RS authorization, scope of Authorization in I2RS client and agent (section 4.2), o client redundancy with a single client identity (section 4.3), o restrictions on I2RS in personal devices (section 4.4), o communication channels and I2RS high-layer protocol (section 7.2), o active communication versus connectivity (section 7.5), o multi-headed control (section 7.8), and o transaction, message, multi-message atomicity (section 7.9). This document assumes the reader is familar with these terms. This document discusses the security of the multiple I2RS communication channels which operate over the higher-layer I2RS protocol. The higher-layer I2RS protocol combines a secure transport and I2RS contextual information, and re-uses IETF protocols and data models to create the secure transport and the I2RS data-model driven contextual information. To describe how the I2RS high-layer protocol combines other protocols into the I2RS higher-layer protocol, the following terms are used: I2RS component protocols Protocols which are re-used and combined to create the I2RS protocol. I2RS secure-transport component protocols The I2RS secure transport protocols that support the I2RS higher- layer protocol. I2RS management component protocols Hares, et al. Expires April 2, 2017 [Page 6] Internet-Draft I2RS Security Requirements September 2016 The I2RS management protocol which provide the management information context. I2RS AAA component protocols The I2RS AAA protocols supporting the I2RS higher-layer protocol. The I2RS higher-layer protocol requires implementation of a I2RS secure-transport component protocol and the I2RS management component protocol. The I2RS AAA component protocol is optional. 3. Security Features and Protocols: Re-used and New 3.1. Security Protocols Re-Used by the I2RS Protocol I2RS requires a secure transport protocol and key distribution protocols. The secure transport features required by I2RS are peer authentication, confidentiality, data integrity, and replay protection for I2RS messages. According to [I-D.ietf-taps-transports], the secure transport protocols which support peer authentication, confidentiality, data integrity, and replay protection are the following: 1. TLS [RFC5246] over TCP or SCTP, 2. DTLS over UDP with replay detection and anti-DoS stateless cookie mechanism required for the I2RS protocol, and the I2RS protocol allow DTLS options of record size negotiation and and conveyance of "don't" fragment bits to be optional in deployments. 3. HTTP over TLS (over TCP or SCTP), and 4. HTTP over DTLS (with the requirements and optional features specified above in item 2). The following protocols would need to be extended to provide confidentiality, data integrity, peer authentication, and key distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML layer (over SCTP). These protocols will need extensions to run over a secure transport (TLS or DTLS) (see section 3.3 for details). The specific type of key management protocols an I2RS secure transport uses depends on the transport. Key management protocols utilized for the I2RS protocols SHOULD support automatic rotation. An I2RS implementer may use AAA protocols over secure transport to distribute the identities for I2RS client and I2RS agent and role authorization information. Two AAA protocols are: Diameter [RFC6733] Hares, et al. Expires April 2, 2017 [Page 7] Internet-Draft I2RS Security Requirements September 2016 and Radius [RFC2865]. To provide the best security I2RS peer identities, the AAA protocols MUST be run over a secure transport (Diameter over secure transport (TLS over TCP) [RFC6733]), Radius over a secure transport (TLS) [RFC6614]). 3.2. New Features Related to Security The new features are priority, an opaque secondary identifier, and an insecure protocol for read-only data constrained to specific standard usages. The I2RS protocol allows multi-headed control by several I2RS clients. This multi-headed control is based on the assumption that the operator deploying the I2RS clients, I2RS agents, and the I2rs protocol will coordinate the read, write, and notification scope so the I2RS clients will not contend for the same write scope. However, just in case there is an unforseen overlap of I2RS clients attempting to write a particular piece of data, the I2RS architecture [RFC7921] provides the concept of each I2RS client having a priority. The I2RS client with the highest priority will have its write succeed. This document specifies requirements for this new concept of priority. The opaque secondary identifier identifies an application which is using the I2RS client to I2RS agent communication to manage the routing system. The secondary identifier is opaque to the I2RS protocol. In order to protect personal privacy, the secondary identifier should not contain personal identifiable information. The last new feature related to I2RS security is the ability to allow non-confidential data to be transferred over a non-secure transport. It is expected that most I2RS data models will describe information that will be transferred with confidentiality. Therefore, any model which transfers data over a non-secure transport is marked. The use of a non-secure transport is optional, and an implementer SHOULD create knobs that allow data marked as non-confidential to be sent over a secure transport. Non-confidential data can only be read or notification scope transmission of events. Non-confidential data cannot be write scope or notification scope configuration. An example of non-confidential data is the telemetry information that is publically known (e.g. BGP route-views data or web site status data) or some legacy data (e.g. interface) which cannot be transported in secure transport. The IETF I2RS Data models MUST indicate in the data model the specific data which is non-confidential. Most I2RS data models will expect that the information described in the model will be transferred with confidentiality. Hares, et al. Expires April 2, 2017 [Page 8] Internet-Draft I2RS Security Requirements September 2016 3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols Table 1 below provides a partial list of the candidate management protocols and the secure transports each one of the support. One column in the table indicates the transport protocol will need I2RS security extensions. Mangement Protocol Transport Protocol I2RS Extensions ========= ===================== ================= NETCONF TLS over TCP (*1) None required (*2) RESTCONF HTTP over TLS with None required (*2) X.509v3 certificates, certificate validation, mutual authentication: 1) authenticated server identity, 2) authenticated client identity (*1) FORCES TML over SCTP Needs extension to (*1) TML to run TML over TLS over SCTP, or DTLS with options for replay protection and anti-DoS stateless cookie mechanism. (DTLS record size negotiation and conveyance of "don't" fragment bits are optional). The IPSEC mechanism is not sufficient for I2RS traveling over multiple hops (router + link) (*2) IPFIX SCTP, TCP, UDP Needs to extension TLS or DTLS for to support TLS or secure client (*1) DTLS with options for replay protection and anti-DoS stateless cookie mechanism. (DTLS record size negotiation and conveyance of "don't" fragment Hares, et al. Expires April 2, 2017 [Page 9] Internet-Draft I2RS Security Requirements September 2016 bits are optional). *1 - Key management protocols MUST support appropriate key rotation. *2 - Identity and Role authorization distributed by Diameter or Radius MUST use Diameter over TLS or Radius over TLS. 4. Security-Related Requirements This section discusses security requirements based on the following security functions: o peer identity authentication (section 4.1), o Peer Identity validation before Role-based Message Actions (section 4.2) o peer identity and client redundancy (section 4.3), o multi-channel transport requirements: Secure transport and insecure Transport (section 4.4), o management protocol security requirements (section 4.5), o role-based security (section 4.6), o security environment (section 4.7) The I2RS Protocol depends upon a secure transport layer for peer authentication, data integrity, confidentiality, and replay protection. The optional insecure transport can only be used restricted set of publically data available (events or information) or a select set of legacy data. Data passed over the insecure transport channel MUST NOT contain any data which identifies a person. 4.1. I2RS Peers(agent and client) Identity Authentication The following requirements specify the security requirements for Peer Identity Authentication for the I2RS protocol: o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an identity, and at least one unique identifier that uniquely identifies each party in the I2RS protocol context. Hares, et al. Expires April 2, 2017 [Page 10] Internet-Draft I2RS Security Requirements September 2016 o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of the I2RS client and I2RS agent. o SEC-REQ-03: Identifier distribution and the loading of these identifiers into I2RS agent and I2RS client SHOULD occur outside the I2RS protocol prior to the I2RS protocol establishing a connection between I2RS client and I2RS agent. AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used. Explanation: These requirements specify the requirements for I2RS peer (I2RS agent and I2RS client) authentication. A secure transport (E.g. TLS) will authenticate based on these identities, but these identities are identities for the I2RS management layer. An AAA protocol distributing I2RS identity information SHOULD transport its information over a secure transport. 4.2. Identity Validation Before Role-Based Message Actions The requirements for I2RS clients with Secure Connections are the following: SEC-REQ-04: An I2RS agent receiving a request from an I2RS client MUST confirm that the I2RS client has a valid identity. SEC-REQ-05: An I2RS client receiving an I2RS message over a secure transport MUST confirm that the I2RS agent has a valid identifier. SEC-REQ-06: An I2RS agent receiving an I2RS message over an insecure transport MUST confirm that the content is suitable for transfer over such a transport. Explanation: Each I2RS client has a scope based on its identity and the security roles (read, write, or events) associated with that identity, and that scope must be considered in processing an I2RS messages sent on a communication channel. An I2RS communication channel may utilize multiple transport sessions, or establish a transport session and then close the transport session. Therefore, it is important that the I2RS peers are operating utilizing valid peer identities when a message is processed rather than checking if a transport session exists. During the time period when a secure transport session is active, the I2RS agent SHOULD assume that the I2RS client's identity remains Hares, et al. Expires April 2, 2017 [Page 11] Internet-Draft I2RS Security Requirements September 2016 valid. Similarly, while a secure connection exists that included validating the I2RS agent's identity and a message is received via that connection, the I2RS client SHOULD assume that the I2RS agent's identity remains valid. The definition of what constitutes a valid identity or a valid identifier MUST be defined by the I2RS protocol. 4.3. Peer Identity, Priority, and Client Redundancy Requirements: SEC-REQ-07: Each I2RS Identifier MUST be associated with just one priority. SEC-REQ-08: Each Identifier is associated with one secondary identifier during a particular I2RS transaction (e.g. read/write sequence), but the secondary identifier may vary during the time a connection between the I2RS client and I2RS agent is active. Explanation: The I2RS architecture also allows multiple I2RS clients with unique identities to connect to an I2RS agent (section 7.8). The I2RS deployment using multiple clients SHOULD coordinate this multi-headed control of I2RS agents by I2RS clients so no conflict occurs in the write scope. However, in the case of conflict on a write scope variable, the error resolution mechanisms defined by the I2RS architecture multi-headed control ([RFC7921], section 7.8) allow the I2RS agent to deterministically choose one I2RS client. The I2RS client with highest priority is given permission to write the variable, and the second client receives an error message. A single I2RS client may be associated with multiple applications with different tasks (e.g. weekly configurations or emergency configurations). The secondary identity is an opaque value that the I2RS client passes to the I2RS agent so that this opaque value can be placed in the tracing file or event stream to identify the application using the I2RS client to I2RS agent communication. The I2RS client is trusted to simply assert the secondary identifier. One example of the use of the secondary identity is the situation where an operator of a network has two applications that use an I2RS client. The first application is a weekly configuration application that uses the I2RS protocol to change configurations. The second application is an application that allows operators to makes emergency changes to routers in the network. Both of these applications use the same I2RS client to write to an I2RS agent. In Hares, et al. Expires April 2, 2017 [Page 12] Internet-Draft I2RS Security Requirements September 2016 order for traceability to determine which application (weekly configuration or emergency) wrote some configuration changes to a router, the I2RS client sends a different opaque value for each of the applications. The weekly configuration secondary opaque value could be "xzzy-splot" and the emergency secondary opaque value could be "splish-splash". A second example is if the I2RS client is used for monitoring of critical infrastructure. The operator of a network using the I2RS client may desire I2RS client redundancy where the monitoring application wth the I2RS client is deployed on two different boxes with the same I2RS client identity (see [RFC7921] section 4.3) These two monitoring applications pass to the I2RS client whether the application is the primary or back up application, and the I2RS client passes this information in the I2RS secondary identitifier as the figure below shows. The primary applications secondary identifier is "primary-monitoring", and the backup application secondary identifier is "backup-monitoring". The I2RS tracing information will include the secondary identifier information along with the transport information in the tracing file in the agent. Example 2: Primary and Backup Application for Monitoring Identification sent to agent Application A--I2RS client--Secure transport(#1) [I2RS identity 1, secondary identifier: "primary-monitoring"]--> Application B--I2RS client--Secure transport(#2) [I2RS identity 1, secondary identifier: "backup-monitoring"]--> Figure 1 4.4. Multi-Channel Transport: Secure Transport and Insecure Transport Requirements: SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. The default transport is a secure transport, and this secure transport is mandatory to implement (MTI) in all I2RS agents, and in any I2RS client which: a) performs a Write scope transaction which is sent to the I2RS agent or b): configures an Event Scope transaction. This secure transport is mandatory to use (MTU) on any I2RS client's Write transaction or the configuration of an Event Scope transaction. Hares, et al. Expires April 2, 2017 [Page 13] Internet-Draft I2RS Security Requirements September 2016 SEC-REQ-10: The secure transport MUST provide data confidentiality, data integrity, and practical replay prevention. SEC-REQ-11: The I2RS client and I2RS agent protocol SHOULD implement mechanisms that mitigate DoS attacks. For the secure transport, this means the secure transport must support DoS prevention. For the insecure transport protocol, the I2RS higher- layer protocol MUST contain a transport management layer that considers the detection of DoS attacks and provides a warning over a secure-transport channel. SEC-REQ-12: A secure transport MUST be associated with a key management solution that can guarantee that only the entities having sufficient privileges can get the keys to encrypt/decrypt the sensitive data. SEC-REQ-13: A machine-readable mechanism to indicate that a data- model contains non-confidential data MUST be provided. A non- secure transport MAY be used to publish only read scope or notification scope data if the associated data model indicates that that data is non-confidential. SEC-REQ-14: The I2RS protocol MUST be able to support multiple secure transport sessions providing protocol and data communication between an I2RS agent and an I2RS client. However, a single I2RS agent to I2RS client connection MAY elect to use a single secure transport session or a single non-secure transport session conforming the requirements above. SEC-REQ-15: Deployment configuration knobs SHOULD be created to allow operators to send "non-confidential" Read scope (data or Event streams) over a secure transport. SEC-REQ-16: The I2RS protocol makes use of both secure and insecure transports, but this use MUST NOT be done in any way that weakens the secure transport protocol used in the I2RS protocol or other contexts that do not have this requirement for mixing secure and insecure modes of operation. Explanation: The I2RS architecture defines three scopes: read, write, and notification scope. Insecure data can only be used for read scope and notification scope of "non-confidential data". The configuration of ephemeral data in the I2RS agent uses either write scope for data or write scope for configuration of event notification streams. The requirement to use secure transport for configuration prevents Hares, et al. Expires April 2, 2017 [Page 14] Internet-Draft I2RS Security Requirements September 2016 accidental or malevolent entities from altering the I2RS routing system through the I2RS agent. It is anticipated that the passing of most I2RS ephemeral state operational status SHOULD be done over a secure transport. In most circumstances the secure transport protocol will be associated with a key management system. Most deployments of the I2RS protocol will allow for automatic key management systems. Since the data models for the I2RS protocol will control key routing functions, it is important that deployments of I2RS use automatic key management systems. Per BCP107 [RFC4107] while key management system SHOULD be automatic, the systems MAY be manual in the following scenarios: a) The environment has limited bandwidth or high round-trip times. b) The information being protected has low value. c) The total volume of traffic over the entire lifetime of the long-term session key will be very low. d) The scale of the deployment is limited. Operators deploying the I2RS protocol selecting manual key management SHOULD consider both short and medium term plans. Deploying automatic systems initially may save effort over the long-term. 4.5. Management Protocol Security Requirements: SEC-REQ-17: In a critical infrastructure, certain data within routing elements is sensitive and read/write operations on such data SHOULD be controlled in order to protect its confidentiality. To achieve this, higher-layer protocols MUST utilize a secure transport, and SHOULD provide access control functions to protect confidentiality of the data. SEC-REQ-18: An integrity protection mechanism for I2RS MUST be provided that will be able to ensure the following: 1) the data being protected is not modified without detection during its transportation, 2) the data is actually from where it is expected to come from, and Hares, et al. Expires April 2, 2017 [Page 15] Internet-Draft I2RS Security Requirements September 2016 3) the data is not repeated from some earlier interaction the higher layer protocol (best effort). The I2RS higher-layer protocol operating over a secure transport provides this integrity. The I2RS higher-layer protocol operating over an insecure transport SHOULD provide some way for the client receiving non-confidential read-scoped or event-scoped data over the insecure connection to detect when the data integrity is questionable; and in the event of a questionable data integrity the I2RS client should disconnect the insecure transport connection. SEC-REQ-19: The I2RS higher-layer protocol MUST provide a mechanism for message traceability (requirements in [RFC7922]) that supports the tracking higher-layer functions run across secure connection or a non-secure transport. Explanation: Most carriers do not want a router's configuration and data flow statistics known by hackers or their competitors. While carriers may share peering information, most carriers do not share configuration and traffic statistics. To achieve this, the I2RS higher-layer protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for sensitive data needs to be provided; and the confidentiality protection on such data during transportation needs to be enforced. Integrity of data is important even if the I2RS protocol is sending non-confidential data over an insecure connection. The ability to trace I2RS protocol messages that enact I2RS transactions provides a minimal aid to helping operators check how messages enact transactions on a secure or insecure transport. Contextual checks on specific non-confidential data sent over a insecure connection may indicate the data has been modified. 4.6. Role-Based Data Model Security The I2RS Architecture [RFC7921] specifies access control by "role" where role is a method of making access control more manageable by creating a grouping of users so that access control can be specified for a role rather than for each of the individuals. Therefore, I2RS role specifies the access control for a group as being read, write, or notification. SEC-REQ-20: The rules around what I2RS security role is permitted to access and manipulate what information over a secure transport (which protects the data in transit) SHOULD ensure that data of any level of sensitivity is reasonably protected from being Hares, et al. Expires April 2, 2017 [Page 16] Internet-Draft I2RS Security Requirements September 2016 observed by those without permission to view it, so that privacy requirements are met. SEC-REQ-21: Role security MUST work when multiple transport connections are being used between the I2RS client and I2RS agent as the I2RS architecture [RFC7921] describes. Sec-REQ-22: If an I2RS agents or an I2RS client is tightly correlated with a person, then the I2RS protocol and data models SHOULD provide additional security that protects the person's privacy. Explanation: I2RS higher-layer uses management protocol E.g. NETCONF, RESTCONF) to pass messages in order to enact I2RS transactions. Role Security must secure data (sensitivity and normal data) in a router even when it is operating over multiple connections at the same time. NETCONF can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP over a secure transport (TLS). SCTP [RFC4960] provides security for multiple streams plus end-to-end transport of data. Some I2RS functions may wish to operate over DTLS which runs over UDP ([RFC6347]), DDCP ([RFC6238]), and SCTP ([RFC5764]). Please note the security of the application to I2RS client connection is outside of the I2RS protocol or I2RS interface. While I2RS clients are expected to be related to network devices and not individual people, if an I2RS client ran on a person's phone, then privacy protection to anonymize any data relating to a person's identity or location would be needed. A variety of forms of managemen may set policy on roles: "operator- applied knobs", roles that restrict personal access, data-models with specific "privacy roles", and access filters. 4.7. Security of the environment The security for the implementation of a protocol also considers the protocol environment. The environmental security requirements are found in: [I-D.ietf-i2rs-security-environment-reqs]. 5. Security Considerations This is a document about security requirements for the I2RS protocol and data modules. Security considerations for the I2RS protocol include both the protocol and the security environment. Hares, et al. Expires April 2, 2017 [Page 17] Internet-Draft I2RS Security Requirements September 2016 6. IANA Considerations This draft is requirements, and does not request anything of IANA. 7. Acknowledgement The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia Atlas, and Jeff Haas for their contributions to the I2RS security requirements discussion and this document. The authors would like to thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their review of these requirements. 8. References 8.1. Normative References [I-D.ietf-i2rs-security-environment-reqs] Migault, D., Halpern, J., and S. Hares, "I2RS Environment Security Requirements", draft-ietf-i2rs-security- environment-reqs-01 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, . Hares, et al. Expires April 2, 2017 [Page 18] Internet-Draft I2RS Security Requirements September 2016 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, . [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, . 8.2. Informative References [I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", draft-ietf-i2rs-ephemeral-state-18 (work in progress), September 2016. [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-17 (work in progress), September 2016. [I-D.ietf-taps-transports] Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services provided by IETF transport protocols and congestion control mechanisms", draft-ietf-taps-transports-11 (work in progress), July 2016. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . Hares, et al. Expires April 2, 2017 [Page 19] Internet-Draft I2RS Security Requirements September 2016 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem Statement for the Interface to the Routing System", RFC 7920, DOI 10.17487/RFC7920, June 2016, . Authors' Addresses Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Hares, et al. Expires April 2, 2017 [Page 20] Internet-Draft I2RS Security Requirements September 2016 Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC HAP 2N2 Canada Email: daniel.migault@ericsson.com Joel Halpern Ericsson US Email: joel.halpern@ericsson.com Hares, et al. Expires April 2, 2017 [Page 21] ./draft-ietf-p2psip-share-10.txt0000664000764400076440000013145713012226305015675 0ustar iustyiusty P2PSIP Working Group A. Knauf Internet-Draft T. Schmidt, Ed. Intended status: Standards Track HAW Hamburg Expires: May 17, 2017 G. Hege daviko GmbH M. Waehlisch link-lab & FU Berlin November 13, 2016 A Usage for Shared Resources in RELOAD (ShaRe) draft-ietf-p2psip-share-10 Abstract This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 17, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Knauf, et al. Expires May 17, 2017 [Page 1] Internet-Draft ShaRe November 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4 3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5 4. Access Control List Definition . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8 5. Extension for Variable Resource Names . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 10 5.3. Overlay Configuration Document Extension . . . . . . . . 11 6. Access Control to Shared Resources . . . . . . . . . . . . . 12 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 12 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 13 6.3. Validating Write Access through an ACL . . . . . . . . . 13 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 14 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 15 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 16 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16 8.3. Trust Delegation to a Malicious or Misbehaving Peer . . . 17 8.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 17 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Knauf, et al. Expires May 17, 2017 [Page 2] Internet-Draft ShaRe November 2016 1. Introduction [RFC6940] defines the base protocol for REsource LOcation And Discovery (RELOAD), which allows for application-specific extensions by Usages. The present document defines such a RELOAD Usage for managing shared write access to RELOAD Resources and a mechanism to store Resources with variable names. The Usage for Shared Resources in RELOAD (ShaRe) enables overlay users to share their exclusive write access to specific Resource/Kind pairs with others. Shared Resources form a basic primitive for enabling various coordination and notification schemes among distributed peers. Write permission is controlled by an Access Control List (ACL) Kind that maintains a chain of Authorized Peers for a particular Shared Resource. A newly defined USER-CHAIN-ACL access control policy enables shared write access in RELOAD. The Usage for Shared Resources in RELOAD is designed for jointly coordinated group applications among distributed peers (e.g., third party registration, see [RFC7904], or distributed conferencing). Of particular interest are rendezvous processes, where a single identifier is linked to multiple, dynamic instances of a distributed cooperative service. Shared write access is based on a trust delegation mechanism that transfers the authorization to write a specific Kind data by storing logical Access Control Lists. An ACL contains the ID of the Kind to be shared and contains trust delegations from one authorized to another (previously unauthorized) user. Shared write access augments the RELOAD security model, which is based on the restriction that peers are only allowed to write resources at a small set of well defined locations (Resource-IDs) in the overlay. Using the standard access control rules in RELOAD, these locations are bound to the username or Node-ID in the peer's certificate. This document extends the base policies to enable a controlled write access for multiple users to a common Resource-ID. Additionally, this specification defines an optional mechanism to store Resources with a variable Resource Name. It enables the storage of Resources whose name complies to a specific pattern. Definition of the pattern is arbitrary, but must contain the user name of the Resource creator. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Knauf, et al. Expires May 17, 2017 [Page 3] Internet-Draft ShaRe November 2016 This document uses the terminology and definitions from the RELOAD base [RFC6940] and [RFC7890], in particular the RELOAD Usage, Resource and Kind. Additionally, the following terms are used: Shared Resource: The term Shared Resource in this document defines a RELOAD Resource with its associated Kinds, that can be written or overwritten by multiple RELOAD users following the specifications in this document. Access Control List: The term Access Control List in this document defines a logical list of RELOAD users allowed to write a specific RELOAD Resource/Kind pair by following the specifications in this document. The list items are stored as Access Control List Kinds that map trust delegations from user A to user B, where A is allowed to write a Shared Resource and the Access Control List, while B is a user that obtains write access to specified Kinds from A. Resource Owner: The term Resource Owner in this document defines a RELOAD peer that initially stored a Resource to be shared. The Resource Owner possesses the RELOAD certificate that grants write access to a specific Resource/Kind pair using the RELOAD certificate-based access control policies. Authorized Peer: The term Authorized Peer in this document defines a RELOAD peer that was granted write access to a Shared Resource by permission of the Resource Owner or another Authorized Peer. 3. Shared Resources in RELOAD A RELOAD user that owns a certificate for writing at a specific overlay location can maintain one or more RELOAD Kinds that are designated for a non-exclusive write access shared with other RELOAD users. The mechanism to share those Resource/Kind pairs with a group of users consists of two basic steps. 1. Storage of the Resource/Kind pairs to be shared. 2. Storage of an Access Control List (ACL) associated with those Kinds. ACLs are created by the Resource Owner and contain ACL items, each delegating the permission of writing the shared Kind to a specific user called the Authorized Peer. For each shared Kind data, its Resource owner stores a root item that initiates an Access Control List. Trust delegation to the Authorized Peer can include the right to further delegate the write permission, enabling a tree of trust delegations with the Resource Owner as trust anchor at its root. Knauf, et al. Expires May 17, 2017 [Page 4] Internet-Draft ShaRe November 2016 The Resource/Kind pair to be shared can be any RELOAD Kind that complies to the following specifications: Isolated Data Storage: To prevent concurrent writing from race conditions, each data item stored within a Shared Resource SHALL be exclusively maintained by the RELOAD user who created it. Hence, Usages that allow the storage of Shared Resources are REQUIRED to use either the array or dictionary data model and apply additional mechanisms for isolating data as described in Section 3.1. Access Control Policy: To ensure write access to Shared Resource by Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access policy as described in Section 6.6. Resource Name Extension: To enable Shared Resources to be stored using a variable resource name, this document defines an optional ResourceNameExtension structure. It contains the Resource Name of the Kind data to be stored and allows any receiver of a shared data to validate whether the Resource Name hashes to the Resource- ID. The ResourceNameExtension is made optional by configuration. The ResourceNameExtension field is only present in the Kind data structure when configured in the corresponding kind-block of the overlay configuration document (for more details see Section 5.3). If the configuration allows variable resource names, a Kind using the USER-CHAIN-ACL policy MUST use the ResourceNameExtension as initial field within the Kind data structure definition. Otherwise the Kind data structure does not contain the ResourceNameExtension structure. 3.1. Mechanisms for Isolating Stored Data This section defines mechanisms to avoid race conditions while concurrently writing an array or dictionary of a Shared Resource. If a dictionary is used in the Shared Resource, the dictionary key MUST be the Node-ID of the certificate that will be used to sign the stored data. Thus data access is bound to the unique ID holder, and write concurrency does not occur. If the data model of the Shared Resource is an array, each Authorized Peer that chooses to write data SHALL obtain its exclusive range of the array indices. The following algorithm will generate an array indexing scheme that avoids collisions. 1. Obtain the Node-ID of the certificate that will be used to sign the stored data Knauf, et al. Expires May 17, 2017 [Page 5] Internet-Draft ShaRe November 2016 2. Take the least significant 24 bits of that Node-ID to prefix the array index 3. Append an 8 bit individual index value to those 24 bit of the Node-ID The resulting 32 bits long integer MUST be used as the index for storing an array entry in a Shared Resource. The 24 bits of the Node-ID serve as a collision-resistant identifier. The 8 bit individual index remain under the control of a single Peer and can be incremented individually for further array entries. In total, each Peer can generate 256 distinct entries for application-specific use. The mechanism to create the array index inherits collision-resistance from the overlay hash function in use (e.g., SHA-1). It is designed to work reliably for small sizes of groups as applicable to resource sharing. In the rare event of a collision, the Storing Peer will refuse to (over-)write the requested array index and protect indexing integrity as defined in Section 6.1. A Peer could rejoin the overlay with different Node-ID in such a case. 4. Access Control List Definition 4.1. Overview An Access Control List (ACL) is a (self-managed) shared resource that contains a list of AccessControlListItem structures as defined in Section 4.2. Each entry delegates write access for a specific Kind data to a single RELOAD user. An ACL enables the RELOAD user who is authorized to write a specific Resource-ID to delegate his exclusive write access to a specific Kind to further users of the same RELOAD overlay. Each Access Control List data structure therefore carries the information about who obtains write access, the Kind-ID of the Resource to be shared, and whether delegation includes write access to the ACL itself. The latter condition grants the right to delegate write access further for the Authorized Peer. Access Control Lists are stored at the same overlay location as the Shared Resource and use the RELOAD array data model. They are initially created by the Resource Owner. Figure 1 shows an example of an Access Control List. We omit the res_name_ext field to simplify illustration. The array entry at index 0x123abc01 displays the initial creation of an ACL for a Shared Resource of Kind-ID 1234 at the same Resource-ID. It represents the root item of the trust delegation tree for this shared RELOAD Kind. The root entry MUST contain the user name of the Resource owner in the "to_user" field and can only be written by the owner of the public key certificate associated with this Resource-ID. The Knauf, et al. Expires May 17, 2017 [Page 6] Internet-Draft ShaRe November 2016 allow_delegation (ad) flag for a root ACL item is set to 1 by default. The array index is generated by using the mechanism for isolating stored data as described in Section 3.1. Hence, the most significant 24 bits of the array index (0x123abc) are the least significant 24 bits of the Node-ID of the Resource Owner. The array item at index 0x123abc02 represents the first trust delegation to an Authorized Peer that is thus permitted to write to the Shared Resource of Kind-ID 1234. Additionally, the Authorized peer Alice is also granted write access to the ACL as indicated by the allow_delegation flag (ad) set to 1. This configuration authorizes Alice to store further trust delegations to the Shared Resource, i.e., add items to the ACL. On the contrary, index 0x456def01 illustrates trust delegation for Kind-ID 1234, in which the Authorized Peer Bob is not allowed to grant access to further peers (ad = 0). Each Authorized Peer signs its ACL items by using its own signer identity along with its own private key. This allows other peers to validate the origin of an ACL item and makes ownership transparent. To manage Shared Resource access of multiple Kinds at a single location, the Resource Owner can create new ACL entries that refer to another Kind-ID as shown in array entry index 0x123abc03. Note that overwriting existing items in an Access Control List with a change in the Kind-ID revokes all trust delegations in the corresponding subtree (see Section 6.2). Authorized Peers are only enabled to overwrite existing ACL item they own. The Resource Owner is allowed to overwrite any existing ACL item, but should be aware of its consequences on the trust delegation chain. Knauf, et al. Expires May 17, 2017 [Page 7] Internet-Draft ShaRe November 2016 +------------------------------------------------------+ | Access Control List | +-----------+------------------------------+-----------+ | #Index | Array Entries | signed by | +-----------+------------------------------+-----------+ | 123abc01 | to_user:Owner Kind:1234 ad:1 | Owner | +-----------+------------------------------+-----------+ | 123abc02 | to_user:Alice Kind:1234 ad:1 | Owner | +-----------+------------------------------+-----------+ | 123abc03 | to_user:Owner Kind:4321 ad:1 | Owner | +-----------+------------------------------+-----------+ | 123abc04 | to_user:Carol Kind:4321 ad:0 | Owner | +-----------+------------------------------+-----------+ | ... | ... | ... | +-----------+------------------------------+-----------+ | 456def01 | to_user:Bob Kind:1234 ad:0 | Alice | +-----------+------------------------------+-----------+ | ... | ... | ... | +-----------+------------------------------+-----------+ Figure 1: Simplified example of an Access Control List including entries for two different Kind-IDs and varying delegation (ad) configurations Implementors of ShaRe should be aware that the trust delegation in an Access Control List need not be loop free. Self-contained circular trust delegation from A to B and B to A are syntactically possible, even though not very meaningful. 4.2. Data Structure The Kind data structure for the Access Control List is defined as follows: struct { /* res_name_ext is optional, see documentation */ ResourceNameExtension res_name_ext; opaque to_user<0..2^16-1>; KindId kind; Boolean allow_delegation; } AccessControlListItem; The AccessControlListItem structure is composed of: res_name_ext: This optional field contains the Resource Name of a ResourceNameExtension (see Section 5.2) to be used by a Shared Resource with variable resource name. This name is used by the Knauf, et al. Expires May 17, 2017 [Page 8] Internet-Draft ShaRe November 2016 storing peer for validating, whether a variable resources name matches one of the predefined naming pattern from the configuration document for this Kind. The presence of this field is bound to a variable resource name element in the corresponding kind-block of the configuration document whose "enable" attribute is set to true (see Section 5.3). Otherwise, if the "enable" attribute is false, the res_name_ext field SHALL NOT be present in the Kind data structure. to_user: This field contains the user name of the RELOAD peer that obtains write permission to the Shared Resource. kind: This field contains the Kind-ID of the Shared Resource. allow_delegation: If true, this Boolean flag indicates that the Authorized Peer in the 'to_user' field is allowed to add additional entries to the ACL for the specified Kind-ID. 5. Extension for Variable Resource Names 5.1. Overview In certain use cases, such as conferencing, it is desirable to increase the flexibility of a peer in using Resource Names beyond those defined by the user name or Node-ID fields in its certificate. For this purpose, this document presents the concept for variable Resources Names that enables providers of RELOAD instances to define relaxed naming schemes for overlay Resources. Each RELOAD node uses a certificate to identify itself using its user name (or Node-ID) while storing data under a specific Resource-ID (see Section 7.3 in [RFC6940]). The specifications in this document scheme adhere to this paradigm, but enable a RELOAD peer to store values of Resource Names that are derived from the user name in its certificate. This is done by using a Resource Name with a variable substring that still matches the user name in the certificate using a pattern defined in the overlay configuration document. Thus despite being variable, an allowable Resource Name remains tied to the Owner's certificate. A sample pattern might be formed as follows. Example Pattern: .*-conf-$USER@$DOMAIN When defining the pattern, care must be taken to avoid conflicts arising from two user names of which one is a substring of the other. In such cases, the holder of the shorter name could threaten to block the resources of the longer-named peer by choosing the variable part of a Resource Name to contain the entire longer user name. For Knauf, et al. Expires May 17, 2017 [Page 9] Internet-Draft ShaRe November 2016 example, a "*$USER" pattern would allow user EVE to define a resource with name "STEVE" and to block the resource name for user STEVE through this. This problem can easily be mitigated by delimiting the variable part of the pattern from the user name part by some fixed string, that by convention is not part of a user name (e.g., the "-conf-" in the above Example). 5.2. Data Structure This section defines the optional ResourceNameExtension structure for every Kind that uses the USER-CHAIN-ACL access control policy. enum { pattern(1), (255)} ResourceNameType; struct { ResourceNameType type; uint16 length; select(type) { case pattern: opaque resource_name<0..2^16-1>; /* Types can be extended */ }; } ResourceNameExtension; The content of the ResourceNameExtension consist of length: This field contains the length of the remaining data structure. It is only used to allow for further extensions to this data structure. The content of the rest of the data structure depends of the ResourceNameType. Currently, the only defined type is "pattern". If the type is "pattern", then the following data structure contains an opaque <0..2^16-1> field containing the Resource Name of the Kind being stored. The type "pattern" further indicates that the Resource Name MUST match to one of the variable resource name pattern defined for this Kind in the configuration document. The ResourceNameType enum and the ResourceNameExtension structure can be extended by further Usages to define other naming schemes. Knauf, et al. Expires May 17, 2017 [Page 10] Internet-Draft ShaRe November 2016 5.3. Overlay Configuration Document Extension This section extends the overlay configuration document by defining new elements for patterns relating resource names to user names. It is noteworthy that additional constraints on the syntax and semantic of names can apply according to specific Usages. For example, Address of Record (AOR) syntax restrictions apply when using P2PSIP [RFC7904], while a more general naming is feasible in plain RELOAD. The element serves as a container for one or multiple sub-elements. It is an additional parameter within the kind-block and has a boolean "enable" attribute that indicates, if true, that the overlay provider allows variable resource names for this Kind. The default value of the "enable" attribute is "false". In the absence of a element for a Kind using the USER-CHAIN-ACL access policy (see Section 6.6), implementors MUST assume this default value. A element MUST be present if the "enabled" attribute of its parent element is set to true. Each element defines a pattern for constructing extended resource names for a single Kind. It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). In this regular expression, $USER and $DOMAIN are used as variables for the corresponding parts of the string in the certificate user name field (with $USER preceding and $DOMAIN succeeding the '@'). Both variables MUST be present in any given pattern definition. Furthermore, variable parts in elements defined in the overlay configuration document MUST remain syntactically separated from the user name part (e.g., by a dedicated delimiter) to prevent collisions with other names of other users. If no pattern is defined for a Kind, if the "enable" attribute is false, or if the regular expression does not meet the requirements specified in this section, the allowable Resource Names are restricted to the user name of the signer for Shared Resource. The Relax NG Grammar for the Variable Resource Names Extension reads: Knauf, et al. Expires May 17, 2017 [Page 11] Internet-Draft ShaRe November 2016 # VARIABLE RESOURCE URN SUB-NAMESPACE namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" # VARIABLE RESOURCE NAMES ELEMENT kind-parameter &= element share:variable-resource-names { attribute enable { xsd:boolean }, # PATTERN ELEMENT element share:pattern { xsd:string }* }? 6. Access Control to Shared Resources 6.1. Granting Write Access Write access to a Kind that is intended to be shared with other RELOAD users can solely be initiated by the Resource Owner. A Resource Owner can share RELOAD Kinds by using the following procedure. o The Resource Owner stores an ACL root item at the Resource-ID of the Shared Resource. The root item contains the resource name extension field (see Section 5.2), the user name of the Resource Owner and Kind-ID of the Shared Resource. The allow_delegation flag is set to 1. The index of array data structure MUST be generated as described in Section 3.1 o Further ACL items for this Kind-ID stored by the Resource Owner MAY delegate write access to Authorized Peers. These ACL items contain the same resource name extension field, the user name of the Authorized Peer and the Kind-Id of the Shared Resource. Optionally, the Resource Owner sets the "ad" to 1 (the default equals 0) to enable the Authorized Peer to further delegate write access. For each succeeding ACL item, the Resource Owner increments its individual index value by one (see Section 3.1) so that items can be stored in the numerical order of the array index starting with the index of the root item. An Authorized Peer with delegation allowance ("ad"=1) can extend the access to an existing Shared Resource as follows. o An Authorized Peer can store additional ACL items at the Resource- ID of the Shared Resource. These ACL items contain the resource name extension field, the user name of the newly Authorized Peer, Knauf, et al. Expires May 17, 2017 [Page 12] Internet-Draft ShaRe November 2016 and the Kind-Id of the Shared Resource. Optionally, the "ad" flag is set to 1 for allowing the newly Authorized Peer to further delegate write access. The array index MUST be generated as described in Section 3.1. Each succeeding ACL item can be stored in the numerical order of the array index. A store request by an Authorized Peer that attempts to overwrite any ACL item signed by another Peer is unauthorized and causes an Error_Forbidden response from the Storing Peer. Such access conflicts could be caused by an array index collision. However, the probability of a collision of two or more identical array indices will be negligibly low using the mechanism for isolating stored data (see Section 3.1) 6.2. Revoking Write Access Write permissions are revoked by storing a non-existent value (see [RFC6940] Section 7.2.1) at the corresponding item of the Access Control List. Revoking a permission automatically invalidates all delegations performed by that user including all subsequent delegations. This allows the invalidation of entire subtrees of the delegations tree with only a single operation. Overwriting the root item with a non-existent value of an Access List invalidates the entire delegations tree. An existing ACL item MUST only be overwritten by the user who initially stored the corresponding entry, or by the Resource Owner that is allowed to overwrite all ACL items for revoking write access. To protect the privacy of the users, the Resource Owner SHOULD overwrite all subtrees that have been invalidated. 6.3. Validating Write Access through an ACL Access Control Lists are used to transparently validate authorization of peers for writing a data value at a Shared Resource. Thereby it is assumed that the validating peer is in possession of the complete and most recent ACL for a specific Resource/Kind pair. The corresponding procedure consists of recursively traversing the trust delegation tree with strings compared as binary objects. It proceeds as follows. 1. Obtain the user name of the certificate used for signing the data stored at the Shared Resource. This is the user who requested the write operation. 2. Validate that an item of the corresponding ACL (i.e., for this Resource/Kind pair) contains a "to_user" field whose value equals Knauf, et al. Expires May 17, 2017 [Page 13] Internet-Draft ShaRe November 2016 the user name obtained in step 1. If the Shared Resource under examination is an Access Control List Kind, further validate if the "ad" flag is set to 1. 3. Select the user name of the certificate that was used to sign the ACL item obtained in the previous step. 4. Validate that an item of the corresponding ACL contains a "to_user" field whose value equals the user name obtained in step 3. Additionally validate that the "ad" flag is set to 1. 5. Repeat steps 3 and 4 until the "to_user" value is equal to the user name of the signer of the ACL in the selected item. This final ACL item is expected to be the root item of this ACL which MUST be further validated by verifying that the root item was signed by the owner of the ACL Resource. The trust delegation chain is valid if and only if all verification steps succeed. In this case, the creator of the data value of the Shared Resource is an Authorized Peer. Note that the ACL validation procedure can be omitted whenever the creator of data at a Shared Resource is the Resource Owner itself. The latter can be verified by its public key certificate as defined in Section 6.6. 6.4. Operations of Storing Peers Storing peers, at which Shared Resource and ACL are physically stored, are responsible for controlling storage attempts to a Shared Resource and its corresponding Access Control List. To assert the USER-CHAIN-ACL access policy (see Section 6.6), a storing peer MUST perform the access validation procedure described in Section 6.3 on any incoming store request using the most recent Access Control List for every Kind that uses the USER-CHAIN-ACL policy. It SHALL further ensure that only the Resource Owner stores new ACL root items for Shared Resources. 6.5. Operations of Accessing Peers Accessing peers, i.e., peers that fetch a Shared Resource, can validate that the originator of a Shared Resource was authorized to store data at this Resource-ID by processing the corresponding ACL. To enable an accessing peer to perform the access validation procedure described in Section 6.3, it first needs to obtain the most recent Access Control List in the following way. Knauf, et al. Expires May 17, 2017 [Page 14] Internet-Draft ShaRe November 2016 1. Send a Stat request to the Resource-ID of the Shared Resource to obtain all array indexes of stored ACL Kinds (as per [RFC6940], Section 7.4.3.) 2. Fetch all indexes of existing ACL items at this Resource-ID by using the array ranges retrieved in the Stat request answer Peers can cache previously fetched Access Control Lists up to the maximum lifetime of an individual item. Since stored values could have been modified or invalidated prior to their expiration, an accessing peer SHOULD use a Stat request to check for updates prior to using the data cache. 6.6. USER-CHAIN-ACL Access Policy This document specifies an additional access control policy to the RELOAD base document [RFC6940]. The USER-CHAIN-ACL policy allows Authorized Peers to write a Shared Resource, even though they do not own the corresponding certificate. Additionally, the USER-CHAIN-ACL allows the storage of Kinds with a variable resource name that are following one of the specified naming pattern. Hence, on an inbound store request on a Kind that uses the USER-CHAIN-ACL access policy, the following rules MUST be applied: In the USER-CHAIN-ACL policy, a given value MUST NOT be written or overwritten, if neither one of USER-MATCH or USER-NODE-MATCH (mandatory if the data model is dictionary) access policies of the base document [RFC6940] applies. Additionally, the store request MUST be denied if the certificate of the signer does not contain a user name that matches to the user and domain portion in one of the variable resource name patterns (c.f. Section 5) specified in the configuration document or if the hashed Resource Name does not match the Resource-ID. The Resource Name of the Kind to be stored MUST be taken from the mandatory ResourceNameExtension field in the corresponding Kind data structure. The store request MUST also be denied, if the access rights cannot be verified according to the ACL validation procedure described in Section 6.3. Otherwise, the store request can be processed further. 7. ACCESS-CONTROL-LIST Kind Definition This section defines the ACCESS-CONTROL-LIST Kind previously described in this document. Knauf, et al. Expires May 17, 2017 [Page 15] Internet-Draft ShaRe November 2016 Name: ACCESS-CONTROL-LIST Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the Resource Name of the Kind that will be shared by using the ACCESS- CONTROL-LIST Kind. Data Model: The data model for the ACCESS-CONTROL-LIST Kind-ID is array. The array indexes are formed by using the mechanism for isolated stored data as described in Section 3.1 Access Control: USER-CHAIN-ACL (see Section 6.6) 8. Security Considerations In this section we discuss security issues that are relevant to the usage of shared resources in RELOAD [RFC6940]. 8.1. Resource Exhaustion Joining a RELOAD overlay inherently poses a certain resource load on a peer, because it has to store and forward data for other peers. In common RELOAD semantics, each Resource-ID and thus position in the overlay may only be written by a limited set of peers - often even only a single peer, which limits this burden. In the case of Shared Resources, a single resource may be written by multiple peers, who may even write an arbitrary number of entries (e.g., delegations in the ACL). This leads to an enhanced use of resources at individual overlay nodes. The problem of resource exhaustion can easily be mitigated for Usages based on the ShaRe-Usage by imposing restrictions on size, i.e., element for a certain Kind in the configuration document. 8.2. Malicious or Misbehaving Storing Peer The RELOAD overlay is designed to operate despite the presence of a small set of misbehaving peers. This is not different for Shared Resources since a small set of malicious peers does not disrupt the functionality of the overlay in general, but may have implications for the peers needing to store or access information at the specific locations in the ID space controlled by a malicious peer. A storing peer could withhold stored data which results in a denial of service to the group using the specific resource. But it could not return forged data, since the validity of any stored data can be independently verified using the attached signatures. Knauf, et al. Expires May 17, 2017 [Page 16] Internet-Draft ShaRe November 2016 8.3. Trust Delegation to a Malicious or Misbehaving Peer A Resource Owner that erroneously delegated write access to a Shared Resource for a misbehaving peer enables this malicious member of the overlay to interfere with the corresponding group application in several unwanted ways. Examples of destructive interferences range from exhausting shared storage to dedicated application-specific misuse. Additionally, a bogus peer that was granted delegation rights may authorize further malicious collaborators to writing the Shared Resource. It is the obligation of the Resource Owner to bind trust delegation to apparent trustworthiness. Additional measures to monitor proper behavior may be applied. In any case, the Resource Owner will be able to revoke trust delegation of an entire tree in a single overwrite operation. It further holds the right to overwrite any malicious contributions to the shared resource under misuse. 8.4. Privacy Issues All data stored in the Shared Resource is readable by any node in the overlay, thus applications requiring privacy need to encrypt the data. The ACL needs to be stored unencrypted, thus the list members of a group using a Shared Resource will always be publicly visible. 9. IANA Considerations 9.1. Access Control Policy IANA shall register the following entry in the "RELOAD Access Control Policies" Registry (cf., [RFC6940]) to represent the USER-CHAIN-ACL Access Control Policy, as described in Section 6.6. [NOTE TO IANA/ RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this specification in the following list.] +-------------------+----------+ | Kind | RFC | +-------------------+----------+ | USER-CHAIN-ACL | RFC-AAAA | +-------------------+----------+ 9.2. Data Kind-ID IANA shall register the following code point in the "RELOAD Data Kind-ID" Registry (cf., [RFC6940]) to represent the ShaRe ACCESS- CONTROL-LIST kind, as described in Section 7. [NOTE TO IANA/RFC- EDITOR: Please replace RFC-AAAA with the RFC number for this specification in the following list.] Knauf, et al. Expires May 17, 2017 [Page 17] Internet-Draft ShaRe November 2016 +----------------------+------------+----------+ | Kind | Kind-ID | RFC | +----------------------+------------+----------+ | ACCESS-CONTROL-LIST | TBD | RFC-AAAA | +----------------------+------------+----------+ 9.3. XML Name Space Registration This document registers the following URI for the config XML name space in the IETF XML registry defined in [RFC3688] URI: urn:ietf:params:xml:ns:p2p:config-base:share Registrant Contact: The IESG XML: N/A, the requested URI is an XML name space 10. References 10.1. Normative References [IEEE-Posix] "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937-255-9, January 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, . 10.2. Informative References [RFC7890] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)", RFC 7890, DOI 10.17487/RFC7890, June 2016, . Knauf, et al. Expires May 17, 2017 [Page 18] Internet-Draft ShaRe November 2016 [RFC7904] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, Ed., "A SIP Usage for REsource LOcation And Discovery (RELOAD)", RFC 7904, DOI 10.17487/RFC7904, October 2016, . Acknowledgments This work was stimulated by fruitful discussions in the P2PSIP working group and the SAM research group. We would like to thank all active members for constructive thoughts and feedback. In particular, the authors would like to thank (in alphabetical order) Emmanuel Baccelli, Ben Campbell, Alissa Cooper, Lothar Grimm, Russ Housley, Cullen Jennings, Matt Miller, Peter Musgrave, Joerg Ott, Marc Petit-Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly funded by the German Federal Ministry of Education and Research, projects HAMcast, Mindstone, and SAFEST. Authors' Addresses Alexander Knauf HAW Hamburg Berliner Tor 7 Hamburg D-20099 Germany Phone: +4940428758067 Email: alexanderknauf@gmail.com Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg D-20099 Germany Email: t.schmidt@haw-hamburg.de URI: http://inet.haw-hamburg.de/members/schmidt Gabriel Hege daviko GmbH Schillerstr. 107 Berlin D-10625 Germany Phone: +493043004344 Email: hege@daviko.com Knauf, et al. Expires May 17, 2017 [Page 19] Internet-Draft ShaRe November 2016 Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin D-10318 Germany Email: mw@link-lab.net URI: http://www.inf.fu-berlin.de/~waehl Knauf, et al. Expires May 17, 2017 [Page 20] ./draft-ietf-pals-rfc4447bis-05.txt0000664000764400076440000022574112736753230016132 0ustar iustyiusty Internet Engineering Task Force Luca Martini Ed. Internet Draft Giles Heron Ed. Intended status: Internet Standard Expires: January 5, 2017 Cisco Obsoletes: 6723, 4447 July 5, 2016 Pseudowire Setup and Maintenance using the Label Distribution Protocol draft-ietf-pals-rfc4447bis-05.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 5, 2016 Abstract Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and then transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and Martini & Heron [Page 1] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. This document has been written to address errata in a previous version of this standard. Martini & Heron [Page 2] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 Table of Contents 1 Introduction ......................................... 4 2 Changes from RFC4447 ................................. 6 3 Specification of Requirements ........................ 7 4 The Pseudowire Label ................................. 7 5 Details Specific to Particular Emulated Services ..... 9 5.1 IP Layer 2 Transport ................................. 9 6 LDP .................................................. 9 6.1 The PWid FEC Element ................................. 10 6.2 The Generalized PWid FEC Element ..................... 11 6.2.1 Attachment Identifiers ............................... 12 6.2.2 Encoding the Generalized PWid FEC Element ............ 13 6.2.2.1 Interface Parameters TLV ............................. 15 6.2.2.2 PW Group ID TLV ...................................... 15 6.2.3 Signaling Procedures ................................. 16 6.3 Signaling of Pseudowire Status ....................... 17 6.3.1 Use of Label Mapping Messages ........................ 17 6.3.2 Signaling PW Status .................................. 17 6.3.3 Pseudowire Status Negotiation Procedures ............. 19 6.4 Interface Parameters Sub-TLV ......................... 21 6.5 LDP label Withdrawal procedures ...................... 22 7 Control Word ......................................... 22 7.1 PW Types for which the Control Word is REQUIRED ...... 22 7.2 PW Types for which the Control Word is NOT mandatory . 22 7.3 Control-Word Renegotiation by Label Request Message .. 24 7.4 Sequencing Considerations ............................ 25 7.4.1 Label Advertisements ................................. 25 7.4.2 Label Release ........................................ 25 8 IANA Considerations .................................. 26 9 Security Considerations .............................. 26 9.1 Data-Plane Security .................................. 26 9.2 Control-Plane Security ............................... 27 10 Interoperability and Deployment ...................... 28 11 Acknowledgments ...................................... 29 12 Normative References ................................. 29 13 Informative References ............................... 29 14 Author Information ................................... 31 15 Additional Historical Contributing Authors ........... 31 Martini & Heron [Page 3] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 1. Introduction [RFC4619], [RFC4717], [RFC4618], and [RFC4448] explain how to encapsulate a Layer 2 Protocol Data Unit (PDU) for transmission over an MPLS-enabled network. Those documents specify that a "pseudowire header", consisting of a demultiplexor field, will be prepended to the encapsulated PDU. The pseudowire demultiplexor field is prepended before transmitting a packet on a pseudowire. When the packet arrives at the remote endpoint of the pseudowire, the demultiplexor is what enables the receiver to identify the particular pseudowire on which the packet has arrived. To transmit the packet from one pseudowire endpoint to another, the packet may need to travel through a "Packet Switched Network (PSN) tunnel"; this will require that an additional header be prepended to the packet. Accompanying documents [RFC4842], [RFC4553] specify methods for transporting time-division multiplexing (TDM) digital signals (TDM circuit emulation) over a packet-oriented MPLS-enabled network. The transmission system for circuit-oriented TDM signals is the Synchronous Optical Network [ANSI] (SONET)/Synchronous Digital Hierarchy (SDH) [ITUG]. To support TDM traffic, which includes voice, data, and private leased-line service, the pseudowires must emulate the circuit characteristics of SONET/SDH payloads. The TDM signals and payloads are encapsulated for transmission over pseudowires. A pseudowire demultiplexor and a PSN tunnel header is prepended to this encapsulation. [RFC4553] describes methods for transporting low-rate time-division multiplexing (TDM) digital signals (TDM circuit emulation) over PSNs, while [RFC4842] similarly describes transport of high-rate TDM (SONET/SDH). To support TDM traffic, the pseudowires must emulate the circuit characteristics of the original T1, E1, T3, E3, SONET, or SDH signals. [RFC4553] does this by encapsulating an arbitrary but constant amount of the TDM data in each packet, and the other methods encapsulate TDM structures. In this document, we specify the use of the MPLS Label Distribution Protocol, LDP [RFC5036], as a protocol for setting up and maintaining the pseudowires. In particular, we define new TLVs, FEC elements, parameters, and codes for LDP, which enable LDP to identify pseudowires and to signal attributes of pseudowires. We specify how a pseudowire endpoint uses these TLVs in LDP to bind a demultiplexor field value to a pseudowire, and how it informs the remote endpoint of the binding. We also specify procedures for reporting pseudowire status changes, for passing additional information about the pseudowire as needed, and for releasing the bindings. These procedures are intended to be independent of the underlying version of IP used for LDP signaling. Martini & Heron [Page 4] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 In the protocol specified herein, the pseudowire demultiplexor field is an MPLS label. Thus, the packets that are transmitted from one end of the pseudowire to the other are MPLS packets, which must be transmitted through an MPLS tunnel. However, if the pseudowire endpoints are immediately adjacent and penultimate hop popping behavior is in use, the MPLS tunnel may not be necessary. Any sort of PSN tunnel can be used, as long as it is possible to transmit MPLS packets through it. The PSN tunnel can itself be an MPLS LSP, or any other sort of tunnel that can carry MPLS packets. Procedures for setting up and maintaining the MPLS tunnels are outside the scope of this document. This document deals only with the setup and maintenance of point-to- point pseudowires. Neither point-to-multipoint nor multipoint-to- point pseudowires are discussed. QoS-related issues are not discussed in this document. The following two figures describe the reference models that are derived from [RFC3985] to support the PW emulated services. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudowire ------->| | | | | | |Attachment| |<-- PSN Tunnel -->| |Attachment| | Circuit V V V V Circuit | V (AC) +----+ +----+ (AC) V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | native service native service Figure 1: PWE3 Reference Model Martini & Heron [Page 5] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 +-----------------+ +-----------------+ |Emulated Service | |Emulated Service | |(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) | +-----------------+ +-----------------+ | Payload | | Payload | | Encapsulation |<====== Pseudowire =======>| Encapsulation | +-----------------+ +-----------------+ |PW Demultiplexer | |PW Demultiplexer | | PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, | | PSN & Physical | | PSN & Physical | | Layers | | Layers | +-------+---------+ ___________ +---------+-------+ | / | +===============/ PSN ===============+ / _____________/ Figure 2: PWE3 Protocol Stack Reference Model For the purpose of this document, PE1 will be defined as the ingress router, and PE2 as the egress router. A layer 2 PDU will be received at PE1, encapsulated at PE1, transported and decapsulated at PE2, and transmitted out of PE2. 2. Changes from RFC4447 The changes in this document are mostly minor fixes to spelling and grammar, or clarifications to the text, which were either noted as errata to [RFC4447] or found by the editors. Additionally a new section (7.3) on control-word renegotiation by label request message has been added, obsoleting [RFC6723]. The diagram of C-bit handling procedures has also been removed. A note has been added in section 6.3.2 to clarify that the C-bit is part of the FEC. A reference has also been added to [RFC7358] indicating the use of downstream unsolicited mode to distribute PW FEC label bindings, independent of the negotiated label advertisement mode of the LDP session. Martini & Heron [Page 6] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. The Pseudowire Label Suppose that it is desired to transport Layer 2 PDUs from ingress LSR PE1 to egress LSR PE2, across an intervening MPLS-enabled network. We assume that there is an MPLS tunnel from PE1 to PE2. That is, we assume that PE1 can cause a packet to be delivered to PE2 by encapsulating the packet in an "MPLS tunnel header" and sending the result to one of its adjacencies. The MPLS tunnel is an MPLS Label Switched Path (LSP); thus, putting on an MPLS tunnel encapsulation is a matter of pushing on an MPLS label. We presuppose that a large number of pseudowires can be carried through a single MPLS tunnel. Thus it is never necessary to maintain state in the network core for individual pseudowires. We do not presuppose that the MPLS tunnels are point to point; although the pseudowires are point to point, the MPLS tunnels may be multipoint to point. We do not presuppose that PE2 will even be able to determine the MPLS tunnel through which a received packet was transmitted. (For example, if the MPLS tunnel is an LSP and penultimate hop popping is used, when the packet arrives at PE2, it will contain no information identifying the tunnel.) When PE2 receives a packet over a pseudowire, it must be able to determine that the packet was in fact received over a pseudowire, and it must be able to associate that packet with a particular pseudowire. PE2 is able to do this by examining the MPLS label that serves as the pseudowire demultiplexor field shown in Figure 2. Call this label the "PW label". When PE1 sends a Layer 2 PDU to PE2, it creates an MPLS packet by adding the PW label to the packet, thus creating the first entry of the label stack. If the PSN tunnel is an MPLS LSP, the PE1 pushes another label (the tunnel label) onto the packet as the second entry of the label stack. The PW label is not visible again until the MPLS packet reaches PE2. PE2's disposition of the packet is based on the PW label. If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, the PW label will generally correspond to a particular ATM VC at PE2. That is, PE2 needs to be able to infer from the PW label the outgoing interface and the VPI/VCI value for the AAL5 PDU. If the payload is a Frame Relay PDU, then PE2 needs to be able to infer from the PW Martini & Heron [Page 7] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 label the outgoing interface and the DLCI value. If the payload is an Ethernet frame, then PE2 needs to be able to infer from the PW label the outgoing interface, and perhaps the VLAN identifier. This process is uni-directional and will be repeated independently for bi-directional operation. When using the PWid FEC Element, it is REQUIRED that the same PW ID and PW type be assigned for a given circuit in both directions. The group ID (see below) MUST NOT be required to match in both directions. The transported frame MAY be modified when it reaches the egress router. If the header of the transported Layer 2 frame is modified, this MUST be done at the egress LSR only. Note that the PW label must always be at the bottom of the packet's label stack, and labels MUST be allocated from the per-platform label space. This document does not specify a method for distributing the MPLS tunnel label or any other labels that may appear above the PW label on the stack. Any acceptable method of MPLS label distribution will do. This document specifies a protocol for assigning and distributing the PW label. This protocol is LDP, extended as specified in the remainder of this document. An LDP session must be set up between the pseudowire endpoints. LDP MUST exchange PW FEC label bindings in downstream unsolicited mode, independent of the negotiated label advertisement mode of the LDP session according to the specifications in specified in [RFC7358]. LDP's "liberal label retention" mode SHOULD be used. However all the LDP procedures that are specified in [RFC5036], and that are also applicable to this protocol specification MUST be implemented. This document requires that a receiving LSR MUST respond to a Label Request message with either a Label Mapping for the requested label or with a Notification message that indicates why it cannot satisfy the request. These procedures are specified in [RFC5036] section 3.5.7 "Label Mapping Message", and 3.5.8 "Label Request Message". Note that sending these responses is a stricter requirement than is specified in [RFC5036] but these response messages are REQUIRED to ensure correct operation of this protocol. In addition to the protocol specified herein, static assignment of PW labels may be used, and implementations of this protocol SHOULD provide support for static assignment. PW encapsulation is always symmetrical in both directions of traffic along a specific PW, whether the PW uses an LDP control plane or not. This document specifies all the procedures necessary to set up and maintain the pseudowires needed to support "unswitched" point to point services, where each endpoint of the pseudowire is provisioned with the identity of the other endpoint. There are also protocol mechanisms specified herein that can be used to support switched Martini & Heron [Page 8] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 services and other provisioning models. However, the use of the protocol mechanisms to support those other models and services is not described in this document. 5. Details Specific to Particular Emulated Services 5.1. IP Layer 2 Transport This mode carries IP packets over a pseudowire. The encapsulation used is according to [RFC3032]. The PW control word MAY be inserted between the MPLS label stack and the IP payload. The encapsulation of the IP packets for forwarding on the attachment circuit is implementation specific, is part of the native service processing (NSP) function [RFC3985], and is outside the scope of this document. 6. LDP The PW label bindings are distributed using the LDP downstream unsolicited mode described in [RFC5036]. The PEs will establish an LDP session using the Extended Discovery mechanism described in [LDP, sectionn 2.4.2 and 2.5]. An LDP Label Mapping message contains an FEC TLV, a Label TLV, and zero or more optional parameter TLVs. The FEC TLV is used to indicate the meaning of the label. In the current context, the FEC TLV would be used to identify the particular pseudowire that a particular label is bound to. In this specification, we define two new FEC TLVs to be used for identifying pseudowires. When setting up a particular pseudowire, only one of these FEC TLVs is used. The one to be used will depend on the particular service being emulated and on the particular provisioning model being supported. LDP allows each FEC TLV to consist of a set of FEC elements. For setting up and maintaining pseudowires, however, each FEC TLV MUST contain exactly one FEC element. The LDP base specification has several kinds of label TLVs, including the Generic Label TLV, as specified in [RFC5036], section 3.4.2.1. For setting up and maintaining pseudowires, the Generic Label TLV MUST be used. Martini & Heron [Page 9] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 6.1. The PWid FEC Element The PWid FEC element may be used whenever both pseudowire endpoints have been provisioned with the same 32-bit identifier for the pseudowire. For this purpose, a new type of FEC element is defined. The FEC element type is 0x80 and is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWid (0x80) |C| PW type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Parameter Sub-TLV | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - PW type A 15 bit quantity containing a value that represents the type of PW. Assigned Values are specified in "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" [RFC4446]. - Control word bit (C) The bit (C) is used to flag the presence of a control word as follows: C = 1 control word present on this PW. C = 0 no control word present on this PW. Please see the section "Control Word" for further explanation. - PW information length Length of the PW ID field and the interface parameters sub-TLV in octets. If this value is 0, then it references all PWs using the specified group ID, and there is no PW ID present, nor are there any interface parameter sub-TLVs. Martini & Heron [Page 10] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 - Group ID An arbitrary 32 bit value which represents a group of PWs that is used to create groups in the PW space. The group ID is intended to be used as a port index, or a virtual tunnel index. To simplify configuration a particular PW ID at ingress could be part of a Group ID assigned to the virtual tunnel for transport to the egress router. The Group ID is very useful for sending wild card label withdrawals, or PW wild card status notification messages to remote PEs upon physical port failure. - PW ID A non-zero 32-bit connection ID that together with the PW type identifies a particular PW. Note that the PW ID and the PW type MUST be the same at both endpoints. - Interface Parameter Sub-TLV This variable length TLV is used to provide interface specific parameters, such as attachment circuit MTU. Note that as the "interface parameter sub-TLV" is part of the FEC, the rules of LDP make it impossible to change the interface parameters once the pseudowire has been set up. Thus the interface parameters field must not be used to pass information, such as status information, that may change during the life of the pseudowire. Optional parameter TLVs should be used for that purpose. Using the PWid FEC, each of the two pseudowire endpoints independently initiates the setup of a unidirectional LSP. An outgoing LSP and an incoming LSP are bound together into a single pseudowire if they have the same PW ID and PW type. 6.2. The Generalized PWid FEC Element The PWid FEC element can be used if a unique 32-bit value has been assigned to the PW, and if each endpoint has been provisioned with that value. The Generalized PWid FEC element requires that the PW endpoints be uniquely identified; the PW itself is identified as a pair of endpoints. In addition, the endpoint identifiers are structured to support applications where the identity of the remote endpoints needs to be auto-discovered rather than statically configured. The "Generalized PWid FEC Element" is FEC type 0x81. Martini & Heron [Page 11] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 The Generalized PWid FEC Element does not contain anything corresponding to the "Group ID" of the PWid FEC element. The functionality of the "Group ID" is provided by a separate optional LDP TLV, the "PW Group ID TLV", described below. The Interface Parameters field of the PWid FEC element is also absent; its functionality is replaced by the optional Interface Parameters TLV, described below. 6.2.1. Attachment Identifiers As discussed in [RFC3985], a pseudowire can be thought of as connecting two "forwarders". The protocol used to set up a pseudowire must allow the forwarder at one end of a pseudowire to identify the forwarder at the other end. We use the term "attachment identifier", or "AI", to refer to the field that the protocol uses to identify the forwarders. In the PWid FEC, the PWid field serves as the AI. In this section, we specify a more general form of AI that is structured and of variable length. Every Forwarder in a PE must be associated with an Attachment Identifier (AI), either through configuration or through some algorithm. The Attachment Identifier must be unique in the context of the PE router in which the Forwarder resides. The combination must be globally unique. It is frequently convenient to regard a set of Forwarders as being members of a particular "group", where PWs may only be set up among members of a group. In such cases, it is convenient to identify the Forwarders relative to the group, so that an Attachment Identifier would consist of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (AII). An Attachment Group Identifier may be thought of as a VPN-id, or a VLAN identifier, some attribute that is shared by all the Attachment PWs (or pools thereof) that are allowed to be connected. The details of how to construct the AGI and AII fields identifying the pseudowire endpoints are outside the scope of this specification. Different pseudowire applications, and different provisioning models, will require different sorts of AGI and AII fields. The specification of each such application and/or model must include the rules for constructing the AGI and AII fields. As previously discussed, a (bidirectional) pseudowire consists of a pair of unidirectional LSPs, one in each direction. If a particular pseudowire connects PE1 with PE2, the PW direction from PE1 to PE2 can be identified as: Martini & Heron [Page 12] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 , PE2, >, and the PW direction from PE2 to PE1 can be identified by: , PE1, >. Note that the AGI must be the same at both endpoints, but the AII will in general be different at each endpoint. Thus, from the perspective of a particular PE, each pseudowire has a local or "Source AII", and a remote or "Target AII". The pseudowire setup protocol can carry all three of these quantities: - Attachment Group Identifier (AGI). - Source Attachment Individual Identifier (SAII) - Target Attachment Individual Identifier (TAII) If the AGI is non-null, then the Source AI (SAI) consists of the AGI together with the SAII, and the Target AI (TAI) consists of the TAII together with the AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI, respectively. The interpretation of the SAI and TAI is a local matter at the respective endpoint. The association of two unidirectional LSPs into a single bidirectional pseudowire depends on the SAI and the TAI. Each application and/or provisioning model that uses the Generalized PWid FEC element must specify the rules for performing this association. 6.2.2. Encoding the Generalized PWid FEC Element FEC element type 0x81 is used. The FEC element is encoded as follows: Martini & Heron [Page 13] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Gen PWid (0x81)|C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document does not specify the AII and AGI type field values; specification of the type field values to be used for a particular application is part of the specification of that application. IANA has assigned these values using the method defined in the [RFC4446] document. The SAII, TAII, and AGI are simply carried as octet strings. The length byte specifies the size of the Value field. The null string can be sent by setting the length byte to 0. If a particular application does not need all three of these sub-elements, it MUST send all the sub-elements but set the length to 0 for the unused sub-elements. The PW information length field contains the length of the SAII, TAII, and AGI, combined in octets. If this value is 0, then it references all PWs using the specific grouping ID (specified in the PW Group ID TLV). In this case, there are no other FEC element fields (AGI, SAII, etc.) present, nor any interface parameters TLVs. Note that the interpretation of a particular field as AGI, SAII, or TAII depends on the order of its occurrence. The type field identifies the type of the AGI, SAII, or TAII. When comparing two occurrences of an AGI (or SAII or TAII), the two occurrences are considered identical if the type, length, and value fields of one are identical, respectively, to those of the other. Martini & Heron [Page 14] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 6.2.2.1. Interface Parameters TLV This TLV MUST only be used when sending the Generalized PW FEC. It specifies interface-specific parameters. Specific parameters, when applicable, MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| PW Intf P. TLV (0x096B) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A more detailed description of this field can be found in the section "Interface Parameters Sub-TLV", below. 6.2.2.2. PW Group ID TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| PW Group ID TLV (0x096C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PW Group ID is an arbitrary 32-bit value that represents an arbitrary group of PWs. It is used to create group PWs; for example, a PW Grouping ID can be used as a port index and assigned to all PWs that lead to that port. Use of the PW Group ID enables a PE to send "wild card" label withdrawals, or "wild card" status notification messages, to remote PEs upon physical port failure. Note Well: The PW Group ID is different from and has no relation to, the Attachment Group Identifier. The PW Group ID TLV is not part of the FEC and will not be advertised except in the PW FEC advertisement. The advertising PE MAY use the wild card withdraw semantics, but the remote PEs MUST implement support for wild card messages. This TLV MUST only be used when sending the Generalized PW ID FEC. Martini & Heron [Page 15] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 To issue a wild card command (status or withdraw): - Set the PW Info Length to 0 in the Generalized PWid FEC Element. - Send only the PW Group ID TLV with the FEC (no AGI/SAII/TAII is sent). 6.2.3. Signaling Procedures In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure. The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). The Label Mapping message contains the FEC TLV, carrying the Generalized PWid FEC Element (type 0x81). The Generalized PWid FEC element contains the AGI, SAII, and TAII information. Next, when PE2 receives such a Label Mapping message, PE2 interprets the message as a request to set up a PW whose endpoint (at PE2) is the Forwarder identified by the TAI. From the perspective of the signaling protocol, exactly how PE2 maps AIs to Forwarders is a local matter. In some Virtual Private Wire Services (VPWS) provisioning models, the TAI might, for example, be a string that identifies a particular Attachment Circuit, such as "ATM3VPI4VCI5", or it might, for example, be a string, such as "Fred", that is associated by configuration with a particular Attachment Circuit. In VPLS, the AGI could be a VPN-id, identifying a particular VPLS instance. If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a Label Release message to PE1, with a Status Code of "Unassigned/Unrecognized TAI", and the processing of the Label Mapping message is complete. The FEC TLV sent in a Label Release message is the same as the FEC TLV received in the Label Mapping being released (but without the interface parameter TLV). More generally, the FEC TLV is the same in all LDP messages relating to the same PW. In a Label Release this means that the SAII is the remote peer's AII and the TAII is the sender's local AII. If the Label Mapping Message has a valid TAI, PE2 must decide whether to accept it. The procedures for so deciding will depend on the particular type of Forwarder identified by the TAI. Of course, the Label Mapping message may be rejected due to standard LDP error conditions as detailed in [RFC5036]. Martini & Heron [Page 16] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 If PE2 decides to accept the Label Mapping message, then it has to make sure that a PW LSP is set up in the opposite (PE1-->PE2) direction. If it has already signaled for the corresponding PW LSP in that direction, nothing more needs to be done. Otherwise, it must initiate such signaling by sending a Label Mapping message to PE1. This is very similar to the Label Mapping message PE2 received, but the SAI and TAI are reversed. Thus, a bidirectional PW consists of two LSPs, where the FEC of one has the SAII and TAII reversed with respect to the FEC of the other. 6.3. Signaling of Pseudowire Status 6.3.1. Use of Label Mapping Messages The PEs MUST send Label Mapping Messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the operator administratively configures the pseudowire down (or the PW configuration is deleted entirely). Using the procedures outlined in this section, a simple label withdraw method MAY also be supported as a legacy means of signaling PW status and AC status. In any case, if the label-to-PW binding is not available the PW MUST be considered in the down state. Once the PW status negotiation procedures are completed and if they result in the use of the label withdraw method for PW status communication, and this method is not supported by one of the PEs, then that PE must send a Label Release Message to its peer with the following error: "Label Withdraw PW Status Method Not Supported" If the label withdraw method for PW status communication is selected for the PW, it will result in the Label Mapping Message being advertised only if the attachment circuit is active. The PW status signaling procedures described in this section MUST be fully implemented. 6.3.2. Signaling PW Status The PE devices use an LDP TLV to indicate status to their remote peers. This PW Status TLV contains more information than the alternative simple Label Withdraw message. The format of the PW Status TLV is: Martini & Heron [Page 17] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The status code is a 4 octet bit field as specified in the PW IANA Allocations document [RFC4446]. The length specifies the length of the Status Code field in octets (equal to 4). Each bit in the status code field can be set individually to indicate more than a single failure at once. Each fault can be cleared by sending an appropriate Notification message in which the respective bit is cleared. The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply. The Status TLV is transported to the remote PW peer via the LDP Notification message as described in [RFC5036]. The format of the Notification Message for carrying the PW Status is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status (TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC TLV or Generalized ID FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Group ID TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Status TLV status code is set to 0x00000028, "PW status", to indicate that PW status follows. Since this notification does not refer to any particular message, the Message Id field is set to 0. The PW FEC TLV SHOULD NOT include the interface parameter sub-TLVs, as they are ignored in the context of this message. However the PW Martini & Heron [Page 18] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 FEC TLV MUST include the C-bit, where aplicable, as it is part of the FEC. When a PE's attachment circuit encounters an error, use of the PW Notification Message allows the PE to send a single "wild card" status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. This status message contains either the PW FEC TLV with only the group ID set, or else it contains the Generalized FEC TLV with only the PW Group ID TLV. As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized PWid FEC element, can be used to send a status notification for all arbitrary sets of PWs. This procedure is OPTIONAL, and if it is implemented, the LDP Notification message should be as follows: If the PWid FEC element is used, the PW information length field is set to 0, the PW ID field is not present, and the interface parameter sub-TLVs are not present. If the Generalized FEC element is used, the AGI, SAII, and TAII are not present, the PW information length field is set to 0, the PW Group ID TLV is included, and the Interface Parameters TLV is omitted. For the purpose of this document, this is called the "wild card PW status notification procedure", and all PEs implementing this design are REQUIRED to accept such a notification message but are not required to send it. 6.3.3. Pseudowire Status Negotiation Procedures When a PW is first set up, the PEs MUST attempt to negotiate the usage of the PW status TLV. This is accomplished as follows: A PE that supports the PW Status TLV MUST include it in the initial Label Mapping message following the PW FEC and the interface parameter sub-TLVs. The PW Status TLV will then be used for the lifetime of the pseudowire. This is shown in the following diagram: Martini & Heron [Page 19] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PWId FEC or Generalized ID FEC + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Generic Label (0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a PW Status TLV is included in the initial Label Mapping message for a PW, then if the Label Mapping message from the remote PE for that PW does not include a PW status TLV, or if the remote PE does not support the PW Status TLV, the PW will revert to the label withdraw method of signaling PW status. Note that if the PW Status TLV is not supported by the remote peer, the peer will automatically ignore it, since the I (ignore) bit is set in the TLV. The PW Status TLV, therefore, will not be present in the corresponding FEC advertisement from the remote LDP peer, which results in exactly the above behavior. If the PW Status TLV is not present following the FEC TLV in the initial PW Label Mapping message received by a PE, then the PW Status TLV will not be used, and both PEs supporting the pseudowire will revert to the label withdraw procedure for signaling status changes. If the negotiation process results in the usage of the PW status TLV, then the actual PW status is determined by the PW status TLV that was sent within the initial PW Label Mapping message. Subsequent updates of PW status are conveyed through the notification message. Martini & Heron [Page 20] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 6.4. Interface Parameters Sub-TLV This field specifies interface-specific parameters. When applicable, it MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other. The field structure is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The interface parameter sub-TLV type values are specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446]. The Length field is defined as the length of the interface parameter including the parameter id and length field itself. Processing of the interface parameters should continue when unknown interface parameters are encountered, and they MUST be silently ignored. - Interface MTU sub-TLV type A 2 octet value indicating the MTU in octets. This is the Maximum Transmission Unit, excluding encapsulation overhead, of the egress packet interface that will be transmitting the decapsulated PDU that is received from the MPLS-enabled network. This parameter is applicable only to PWs transporting packets and is REQUIRED for these PW types. If this parameter does not match in both directions of a specific PW, that PW MUST NOT be enabled. - Optional Interface Description string sub-TLV type This arbitrary, and OPTIONAL, interface description string is used to send a human-readable administrative string describing the interface to the remote. This parameter is OPTIONAL, and is applicable to all PW types. The interface description parameter string length is variable, and can be from 0 to 80 octets. Human-readable text MUST be provided in the UTF-8 charset using the Default Language [RFC2277]. Martini & Heron [Page 21] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 6.5. LDP label Withdrawal procedures As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized PWid FEC element, can be used to withdraw all PW labels associated with a particular PW group. This procedure is OPTIONAL, and if it is implemented, the LDP Label Withdraw message should be as follows: If the PWid FEC element is used, the PW information length field is set to 0, the PW ID field is not present, the interface parameter sub-TLVs are not present, and the Label TLV is not present. If the Generalized FEC element is used, the AGI, SAII, and TAII are not present, the PW information length field is set to 0, the PW Group ID TLV is included, the Interface Parameters TLV is not present, and the Label TLV is not present. For the purpose of this document, this is called the "wild card withdraw procedure", and all PEs implementing this design are REQUIRED to accept such withdrawn message but are not required to send it. Note that the PW Group ID TLV only applies to PWs using the Generalized ID FEC element, while the Group ID only applies to PWid FEC element. The interface parameter sub-TLVs, or TLV, MUST NOT be present in any LDP PW Label Withdraw or Label Release message. A wild card Label Release message MUST include only the group ID, or Grouping ID TLV. A Label Release message initiated by a PE router must always include the PW ID. 7. Control Word 7.1. PW Types for which the Control Word is REQUIRED The Label Mapping messages that are sent in order to set up these PWs MUST have C=1. When a Label Mapping message for a PW of one of these types is received and C=0, a Label Release message MUST be sent, with an "Illegal C-bit" status code. In this case, the PW will not be enabled 7.2. PW Types for which the Control Word is NOT mandatory If a system is capable of sending and receiving the control word on PW types for which the control word is not mandatory, then each such PW endpoint MUST be configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. For each PW, there MUST be a default value of this parameter. This specification does NOT state what the default value should be. If a system is NOT capable of sending and receiving the control word on PW types for which the control word is not mandatory, then it behaves exactly as if it were configured for the use of the control Martini & Heron [Page 22] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 word to be NOT PREFERRED. If a Label Mapping message for the PW has already been received but no Label Mapping message for the PW has yet been sent, then the procedure is as follows: -i. If the received Label Mapping message has C=0, send a Label Mapping message with C=0; the control word is not used. -ii. If the received Label Mapping message has C=1, and the PW is locally configured such that the use of the control word is preferred, then send a Label Mapping message with C=1; the control word is used. -iii. If the received Label Mapping message has C=1, and the PW is locally configured such that the use of the control word is not preferred or the control word is not supported, then act as if no Label Mapping message for the PW had been received (That is: proceed to the next paragraph). If a Label Mapping message for the PW has not already been received (or if the received Label Mapping message had C=1 and either local configuration says that the use of the control word is not preferred or the control word is not supported), then send a Label Mapping message in which the C-bit is set to correspond to the locally configured preference for use of the control word. (That is, set C=1 if locally configured to prefer the control word, and set C=0 if locally configured to prefer not to use the control word or if the control word is not supported). The next action depends on what control message is next received for that PW. The possibilities are as follows: -i. A Label Mapping message with the same C-bit value as specified in the Label Mapping message that was sent. PW setup is now complete, and the control word is used if C=1 but is not used if C=0. -ii. A Label Mapping message with C=1, but the Label Mapping message that was sent has C=0. In this case, ignore the received Label Mapping message and continue to wait for the next control message for the PW. -iii. A Label Mapping message with C=0, but the Label Mapping message that was sent has C=1. In this case, send a Label Withdraw message with a "Wrong C-bit" status code, followed by a Label Mapping message that has C=0. PW setup is now complete, and the control word is not used. Martini & Heron [Page 23] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 -iv. A Label Withdraw message with the "Wrong C-bit" status code. Treat as a normal Label Withdraw, but do not respond. Continue to wait for the next control message for the PW. If at any time after a Label Mapping message has been received a corresponding Label Withdraw or Release is received, the action taken is the same as for any Label Withdraw or Release that might be received at any time. If both endpoints prefer the use of the control word, this procedure will cause it to be used. If either endpoint prefers not to use the control word or does not support the control word, this procedure will cause it not to be used. If one endpoint prefers to use the control word but the other does not, the one that prefers not to use it has no extra protocol to execute; it just waits for a Label Mapping message that has C=0. 7.3. Control-Word Renegotiation by Label Request Message It is possible that after the PW C-bit negotation procedure described above is completed, the local PE is re-provisioned with a different control word preference. Therefore once the Control-Word negotation procedures are completed, the procedure can be restarted as follows: -i. If local PE has previously sent a Label Mapping message, it MUST send a Label Withdraw message to remote PE and wait until it has received a Label Release message from the remote PE. -ii. the local PE MUST send a label release message to the remote PE for the specific label associated with the FEC that was advertized for this specific PW. Note: the above-mentioned steps of the Label Release message and Label Withdraw message are not required to be excuted in any specific sequence. -iii. The local PE MUST send a Label Request message to the peer PE, and then MUST wait until it receives a Label Mapping message containing the remote PE's currently configured preference for use of the control word. Once the remote PE has successfully processed the Label Withdraw message and Label Release messages, it will reset the C-bit negotation state machine and its use of the control word with the locally configured preference. From this point on the local and remote PEs will follow the C-bit negotaiation procedures defined in the previous section. The above C-bit renegotation process SHOULD NOT be interupted until Martini & Heron [Page 24] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 it is completed, or unpredictable results might occur. 7.4. Sequencing Considerations In the case where the router considers the sequence number field in the control word, it is important to note the following details when advertising labels. 7.4.1. Label Advertisements After a label has been withdrawn by the output router and/or released by the input router, care must be taken not to advertise (re-use) the same released label until the output router can be reasonably certain that old packets containing the released label no longer persist in the MPLS-enabled network. This precaution is required to prevent the imposition router from restarting packet forwarding with a sequence number of 1 when it receives a Label Mapping message that binds the same FEC to the same label if there are still older packets in the network with a sequence number between 1 and 32768. For example, if there is a packet with a sequence number=n, where n is in the interval [1,32768] traveling through the network, it would be possible for the disposition router to receive that packet after it re-advertises the label. Since the label has been released by the imposition router, the disposition router SHOULD be expecting the next packet to arrive with a sequence number of 1. Receipt of a packet with a sequence number equal to n will result in n packets potentially being rejected by the disposition router until the imposition router imposes a sequence number of n+1 into a packet. Possible methods to avoid this are for the disposition router always to advertise a different PW label, or for the disposition router to wait for a sufficient time before attempting to re-advertise a recently released label. This is only an issue when sequence number processing is enabled at the disposition router. 7.4.2. Label Release In situations where the imposition router wants to restart forwarding of packets with sequence number 1, the router shall 1) send to the disposition router a Label Release Message, and 2) send to the disposition router a Label Request message. When sequencing is supported, advertisement of a PW label in response to a Label Request message MUST also consider the issues discussed in the section on Label Advertisements. Martini & Heron [Page 25] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 8. IANA Considerations The authors request that IANA remove this section before publication and that IANA update any references to [RFC4447] in their registries to refer to this document. 9. Security Considerations This document specifies the LDP extensions that are needed for setting up and maintaining pseudowires. The purpose of setting up pseudowires is to enable Layer 2 frames to be encapsulated in MPLS and transmitted from one end of a pseudowire to the other. Therefore we treat the security considerations for both the data plane and the control plane. 9.1. Data-Plane Security With regard to the security of the data plane, the following areas must be considered: - MPLS PDU inspection. - MPLS PDU spoofing. - MPLS PDU alteration. - MPLS PSN protocol security. - Access Circuit security. - Denial of service prevention on the PE routers. When an MPLS PSN is used to provide pseudowire service, there is a perception that security MUST be at least equal to the currently deployed Layer 2 native protocol networks that the MPLS/PW network combination is emulating. This means that the MPLS-enabled network SHOULD be isolated from outside packet insertion in such a way that it SHOULD NOT be possible to insert an MPLS packet into the network directly. To prevent unwanted packet insertion, it is also important to prevent unauthorized physical access to the PSN, as well as unauthorized administrative access to individual network elements. As mentioned above, an MPLS-enabled network should not accept MPLS packets from its external interfaces (i.e., interfaces to CE devices or to other providers' networks) unless the top label of the packet was legitimately distributed to the system from which the packet is being received. If the packet's incoming interface leads to a different SP (rather than to a customer), an appropriate trust relationship must also be present, including the trust that the other SP also provides appropriate security measures. Martini & Heron [Page 26] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 The three main security problems faced when using an MPLS-enabled network to transport PWs are spoofing, alteration, and inspection. First, there is a possibility that the PE receiving PW PDUs will get a PDU that appears to be from the PE transmitting the PW into the PSN, but that was not actually transmitted by the PE originating the PW. (That is, the specified encapsulations do not by themselves enable the decapsulator to authenticate the encapsulator.) A second problem is the possibility that the PW PDU will be altered between the time it enters the PSN and the time it leaves the PSN (i.e., the specified encapsulations do not by themselves assure the decapsulator of the packet's integrity.) A third problem is the possibility that the PDU's contents will be seen while the PDU is in transit through the PSN (i.e., the specification encapsulations do not ensure privacy.) How significant these issues are in practice depends on the security requirements of the applications whose traffic is being sent through the tunnel, and how secure the PSN itself is. 9.2. Control-Plane Security General security considerations with regard to the use of LDP are specified in section 5 of [RFC5036]. Those considerations also apply to the case where LDP is used to set up pseudowires. A pseudowire connects two attachment circuits. It is important to make sure that LDP connections are not arbitrarily accepted from anywhere, or else a local attachment circuit might get connected to an arbitrary remote attachment circuit. Therefore, an incoming LDP session request MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" LDP peer. The set of eligible peers could be pre-configured (either as a list of IP addresses, or as a list of address/mask combinations), or it could be discovered dynamically via an auto-discovery protocol that is itself trusted. (Obviously, if the auto-discovery protocol were not trusted, the set of "eligible peers" it produces could not be trusted.) Even if an LDP connection request appears to come from an eligible peer, its source address may have been spoofed. Therefore, some means of preventing source address spoofing must be in place. For example, if all the eligible peers are in the same network, source address filtering at the border routers of that network could eliminate the possibility of source address spoofing. The LDP MD5 authentication key option, as described in section 2.9 of [RFC5036], MUST be implemented, and for a greater degree of security, it must be used. This provides integrity and authentication for the LDP messages and eliminates the possibility of source address Martini & Heron [Page 27] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 spoofing. Use of the MD5 option does not provide privacy, but privacy of the LDP control messages is not usually considered important. As the MD5 option relies on the configuration of pre- shared keys, it does not provide much protection against replay attacks. In addition, its reliance on pre-shared keys may make it very difficult to deploy when the set of eligible neighbors is determined by an auto-configuration protocol. When the Generalized PWid FEC Element is used, it is possible that a particular LDP peer may be one of the eligible LDP peers but may not be the right one to connect to the particular attachment circuit identified by the particular instance of the Generalized PWid FEC element. However, given that the peer is known to be one of the eligible peers (as discussed above), this would be the result of a configuration error, rather than a security problem. Nevertheless, it may be advisable for a PE to associate each of its local attachment circuits with a set of eligible peers rather than have just a single set of eligible peers associated with the PE as a whole. 10. Interoperability and Deployment Section 2.2. of [RFC6410] specifies four requirements that an Internet Standard must meet. This section documents how this document meets those requirements. The pseudowire technology was first deployed in 2001 and has been widely deployed by many carriers. [RFC7079] documents the results of a survey of PW implementations, with specific emphasis on Control Word usage. [EANTC] documents a public multi-vendor interoperability test of MPLS and Carrier Ethernet equipment, which included testing of Ethernet, ATM and TDM pseudowires. The errata against [RFC4447] are generally editorial in nature and have been addressed in this document. All features in this specification have been implemented by multiple vendors. No IPR disloures have been made to the IETF related to this document, to RFC4447 or RFC6723, or to the Internet-Drafts that resulted in RFC4447 and RFC6723. Martini & Heron [Page 28] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 11. Acknowledgments The authors wish to acknowledge the contributions of Vach Kompella, Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds. The authors wish to also acknowledge the contribution of the authors of rfc6723, Lizhong Jin, Raymond Key, Simon Delord, Tom Nadeau, Sami Boutros, whose work has been incorporated in this revised document. 12. Normative References [RFC2119] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC5036] "LDP Specification." Andersson, L. Ed., Minei, I. Ed., Thomas, B. Ed. January 2001. RFC5036, October 2007 [RFC3032] "MPLS Label Stack Encoding", Rosen E., Rekhter Y., Tappan D., Fedorkow G., Farinacci D., Li T., Conta A.. RFC3032 [RFC4446] "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" Martini L. RFC4446, April 2006 [RFC7358] "Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)", Raza K., Boutros S., Martini L., RFC7358, October 2014 13. Informative References [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985. [RFC4842] "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", A. Malis, P. Pate, R. Cohen, Ed., D. Zelig, RFC4842, April 2007 [RFC4553] "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", Vainshtein A. Ed., Stein, YJ. Ed. RFC4553, June 2006 [RFC4619] "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", Martini L. Ed. C. Kawa Ed., A. Malis, Ed. RFC4619, September 2006 Martini & Heron [Page 29] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 [RFC4717] "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", Martini L., Jayakumar J., Bocci M., El-Aawar N., Brayley J., Koleyni G. RFC4717, December 2006 [RFC4618] "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) Frames over MPLS Networks", Martini L. Rosen E., Heron G., Malis A. RFC4618, September 2006 [RFC4448] "Encapsulation Methods for Transport of Ethernet over MPLS Networks", Martini L. Ed., Rosen E., El-Aawar N., Heron G. RFC4448, April 2006. [RFC4447] "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", Martini L. Ed., Rosen E., El-Aawar N., Smith T., Heron G. RFC4447, April 2006 [RFC6410] "Reducing the Standards Track to Two Maturity Levels", Housley R., Crocker D., Burger E. RFC6410, October 2011 [RFC6723] "Update of the Pseudowire Control-Word Negotiation Mechanism", Jin L. Ed., Key R. Ed., Delord S., Nadeau T., Boutros S. RFC5723, September 2012 [RFC6410] "Reducing the Standads Track to Two Maturity Levels", Housley R., Crocker D., Burger E. RFC6410, October 2011 [RFC7079] "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", Del Regno N., Malis A. RFC7079, November 2013 [ANSI] American National Standards Institute, "Synchronous Optical Network Formats", ANSI T1.105-1995. [ITUG] ITU Recommendation G.707, "Network Node Interface For The Synchronous Digital Hierarchy", 1996. [EANTC] The European Advanced Networking Test Center "MPLS and Carrier Ethernet: Service - Connect - Transport. Public Multi-Vendor Interoperability Test", February 2009. Martini & Heron [Page 30] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 14. Author Information Luca Martini Cisco Systems, Inc. 1899 Wynkoop Street Suite 600 Denver, CO, 80202 e-mail: lmartini@cisco.com Giles Heron Cisco Systems 10 New Square Bedfont Lakes Feltham Middlesex TW14 8HA UK e-mail: giheron@cisco.com 15. Additional Historical Contributing Authors This historical list is from the original RFC, and is not updated. It is intended for recognition of their work on RFC4447. Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 e-mail: nna@level3.net Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 e-mail: erosen@cisco.com Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 e-mail: tappan@cisco.com Martini & Heron [Page 31] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 Toby Smith Google 6425 Penn Ave. #700 Pittsburgh, PA 15206 e-mail: tob@google.com Dimitri Vlachos Riverbed Technology e-mail: dimitri@riverbed.com Jayakumar Jayakumar, Cisco Systems Inc. 3800 Zanker Road, MS-SJ02/2, San Jose, CA, 95134 e-mail: jjayakum@cisco.com Alex Hamilton, Cisco Systems Inc. 485 East Tasman Drive, MS-SJC07/3, San Jose, CA, 95134 e-mail: tahamilt@cisco.com Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 e-mail: stephen.vogelsang@ecitele.com John Shirron ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 e-mail: john.shirron@ecitele.com Andrew G. Malis Verizon 60 Sylvan Rd. Waltham, MA 02451 e-mail: andrew.g.malis@verizon.com Martini & Heron [Page 32] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 Vinai Sirkay Reliance Infocomm Dhirubai Ambani Knowledge City Navi Mumbai 400 709 e-mail: vinai@sirkay.com Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821 e-mail: vasile@nortelnetworks.com Chris Liljenstolpe 149 Santa Monica Way San Francisco, CA 94127 e-mail: ietf@cdl.asgaard.org Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 e-mail: dcooper@gblx.net Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 e-mail: kireeti@juniper.net Martini & Heron [Page 33] Internet Draft draft-ietf-pals-rfc4447bis-05.txt July 5, 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Expiration Date: January 2017 Martini & Heron [Page 34] ./draft-ietf-payload-rtp-howto-14.txt0000664000764400076440000046541212521623337016771 0ustar iustyiusty Payload Working Group M. Westerlund Internet-Draft Ericsson Updates: 2736 (if approved) May 4, 2015 Intended status: Informational Expires: November 5, 2015 How to Write an RTP Payload Format draft-ietf-payload-rtp-howto-14 Abstract This document contains information on how to best write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 5, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Westerlund Expires November 5, 2015 [Page 1] Internet-Draft HOWTO: RTP Payload Formats May 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Use of Normative Requirements Language . . . . . . . . . 6 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Read and Understand the Media Coding Spec . . . . . . . . 6 3.2. Recommended Reading . . . . . . . . . . . . . . . . . . . 6 3.2.1. IETF Process and Publication . . . . . . . . . . . . 7 3.2.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Important RTP Details . . . . . . . . . . . . . . . . . . 12 3.3.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13 3.3.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . 15 3.3.4. RTP Synchronization . . . . . . . . . . . . . . . . . 16 3.4. Signalling Aspects . . . . . . . . . . . . . . . . . . . 18 3.4.1. Media Types . . . . . . . . . . . . . . . . . . . . . 18 3.4.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . 20 3.5. Transport Characteristics . . . . . . . . . . . . . . . . 22 3.5.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . 22 3.5.2. Different Queuing Algorithms . . . . . . . . . . . . 23 3.5.3. Quality of Service . . . . . . . . . . . . . . . . . 24 4. Standardisation Process for an RTP Payload Format . . . . . . 24 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1. Steps from Idea to Publication . . . . . . . . . . . 24 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 26 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . 26 4.1.4. Writing Style . . . . . . . . . . . . . . . . . . . . 27 4.1.5. How to speed up the process . . . . . . . . . . . . . 28 4.2. Other Standards Bodies . . . . . . . . . . . . . . . . . 29 4.3. Proprietary and Vendor Specific . . . . . . . . . . . . . 29 4.4. Joint Development of Media Coding Specification and RTP Payload Format . . . . . . . . . . . . . . . . . . . . . 30 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 30 5.1. Features of RTP Payload Formats . . . . . . . . . . . . . 31 5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 31 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 32 5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 32 5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 33 5.1.5. Media Scalability . . . . . . . . . . . . . . . . . . 33 5.1.6. High Packet Rates . . . . . . . . . . . . . . . . . . 36 5.2. Selecting Timestamp Definition . . . . . . . . . . . . . 36 Westerlund Expires November 5, 2015 [Page 2] Internet-Draft HOWTO: RTP Payload Formats May 2015 6. Noteworthy Aspects in Payload Format Design . . . . . . . . . 38 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . 38 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.4. Application . . . . . . . . . . . . . . . . . . . . . . . 40 7. Important Specification Sections . . . . . . . . . . . . . . 41 7.1. Media Format Description . . . . . . . . . . . . . . . . 41 7.2. Security Considerations . . . . . . . . . . . . . . . . . 42 7.3. Congestion Control . . . . . . . . . . . . . . . . . . . 43 7.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 44 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 44 8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 44 8.2. Verification Tools . . . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 13. RFC-Editor Note . . . . . . . . . . . . . . . . . . . . . . . 46 14. Informative References . . . . . . . . . . . . . . . . . . . 46 Appendix A. RTP Payload Format Template . . . . . . . . . . . . 54 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . 54 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . 55 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . 55 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . 55 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 55 A.7. Media Format Description . . . . . . . . . . . . . . . . 55 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . 55 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . 55 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . 56 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . 56 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . 56 A.10. Congestion Control Considerations . . . . . . . . . . . . 56 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 56 A.11.1. Media Type Definition . . . . . . . . . . . . . . . 56 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . 58 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 59 A.13. Security Considerations . . . . . . . . . . . . . . . . . 59 A.14. RFC Editor Considerations . . . . . . . . . . . . . . . . 60 A.15. References . . . . . . . . . . . . . . . . . . . . . . . 60 A.15.1. Normative References . . . . . . . . . . . . . . . . 60 A.15.2. Informative References . . . . . . . . . . . . . . . 60 A.16. Author Addresses . . . . . . . . . . . . . . . . . . . . 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60 Westerlund Expires November 5, 2015 [Page 3] Internet-Draft HOWTO: RTP Payload Formats May 2015 1. Introduction RTP [RFC3550] payload formats define how a specific real-time data format is structured in the payload of an RTP packet. A real-time data format without a payload format specification cannot be transported using RTP. This creates an interest in many individuals/ organizations with media encoders or other types of real-time data to define RTP payload formats. However, the specification of a well- designed RTP payload format is non-trivial and requires knowledge of both RTP and the real-time data format. This document is intended to help any author of an RTP payload format specification make important design decisions, consider important features of RTP and RTP security, etc. The document is also intended to be a good starting point for any person with little experience in the IETF and/or RTP to learn the necessary steps. This document extends and updates the information that is available in "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736]. Since that RFC was written, further experience has been gained on the design and specification of RTP payload formats. Several new RTP profiles have been defined, and robustness tools have also been defined, and these need to be considered. This document also discusses the possible venues for defining an RTP payload format: IETF, other standards bodies and proprietary ones. Note, this document does discuss IETF, IANA and RFC Editor processes and rules as they were when this document was published. This to make clear how the work to specify an RTP payload formats depends, use and interacts with these rules and processes. However, these rules and processes are subject to change and the formal rule and process specifications always takes precedence over what is written here. 1.1. Structure This document has several different parts discussing different aspects of the creation of an RTP payload format specification. Section 3 discusses the preparations the author(s) should do before starting to write a specification. Section 4 discusses the different processes used when specifying and completing a payload format, with focus on working inside the IETF. Section 5 discusses the design of payload formats themselves in detail. Section 6 discusses current design trends and provides good examples of practices that should be followed when applicable. Following that Section 7 provides a discussion on important sections in the RTP payload format specification itself such as security and IANA considerations Westerlund Expires November 5, 2015 [Page 4] Internet-Draft HOWTO: RTP Payload Formats May 2015 sections. This document ends with an appendix containing a template that can be used when writing RTP payload formats specifications. 2. Terminology 2.1. Definitions Media Stream: A sequence of RTP packets that together carry part or all of the content of a specific media (audio, video, text, or data whose form and meaning are defined by a specific real-time application) from a specific sender source within a given RTP session. RTP Session: An association among a set of participants communicating with RTP. The distinguishing feature of an RTP session is that each session maintains a full, separate space of SSRC identifiers. See also Section 3.3.1. RTP Payload Format: The RTP payload format specifies how units of a specific encoded media are put into the RTP packet payloads and how the fields of the RTP packet header are used, thus enabling the format to be used in RTP applications. 2.2. Acronyms ABNF: Augmented Backus-Naur Form [RFC5234] ADU: Application Data Unit ALF: Application Level Framing ASM: Any-Source Multicast BCP: Best Current Practice ID: Internet Draft IESG: Internet Engineering Steering Group MTU: Maximum Transmission Unit WG: Working Group QoS: Quality of Service RFC: Request For Comments RTP: Real-time Transport Protocol Westerlund Expires November 5, 2015 [Page 5] Internet-Draft HOWTO: RTP Payload Formats May 2015 RTCP: RTP Control Protocol RTT: Round-Trip Time SSM: Source-Specific Multicast 2.3. Use of Normative Requirements Language As this document is an both in the informational category and being an instruction rather than a specification, this document does not use any RFC 2119 language and the interpretation of "may", "should", "recommended" and "must" are the ones of the English language. 3. Preparations RTP is a complex real-time media delivery framework and it has a lot of details that need to be considered when writing an RTP payload format. It is also important to have a good understanding of the media codec/format so that all of its important features and properties are considered. Only when one has sufficient understanding of both parts one can produce an RTP payload format of high quality. On top of this, one needs to understand the process within the IETF and especially the Working Group responsible for standardizing payload formats (currently the PAYLOAD WG) to go quickly from the initial idea stage to a finished RFC. This and the next sections help an author prepare himself in those regards. 3.1. Read and Understand the Media Coding Spec It may be obvious, but it is necessary for an author of an RTP payload specification to have a solid understanding of the media to be transported. Important are not only the specifically spelled out transport aspects (if any) in the media coding specification, but also core concepts of the underlying technology. For example, an RTP payload format for video coded with inter-picture prediction will perform poorly if the payload designer does not take the use of inter-picture prediction into account. On the other hand, some (mostly older) media codecs offer error-resilience tools against bit errors, which, when misapplied over RTP, in almost all cases would only introduce overhead with no measurable return. 3.2. Recommended Reading The following sub-sections list a number of documents. Not all need to be read in full detail. However, an author basically needs to be aware of everything listed below. Westerlund Expires November 5, 2015 [Page 6] Internet-Draft HOWTO: RTP Payload Formats May 2015 3.2.1. IETF Process and Publication Newcomers to the IETF are strongly recommended to read the "Tao of the IETF" [TAO] that goes through most things that one needs to know about the IETF. This contains information about history, organizational structure, how the WG and meetings work and many more details. It is very important to note and understand the IETF Intellectual Property Rights (IPR) policy that requires early disclosures based on personal knowledge from anyone contributing in IETF. The IETF policies associated with IPR are documented in BCP 78 [BCP78] (related to copyright, including software copyright for example code) and BCP 79 [BCP79] (related to patent rights). These rules may be different from other standardization organizations. For example a person that has a patent or a patent application that he or she reasonably and personally believes to cover a mechanism that gets added to the Internet draft they are contributing to (e.g. by submitting the draft, posting comments or suggestions on the mailing list or speaking at a meeting) they will need to make a timely IPR disclosure. Read the above documents for the authoritative rules. Failure to follow the IPR rules can have dire implications for the specification and the author(s) as discussed in [RFC6701]. Note: These IPR rules applies on what is specified in the RTP Payload format Internet Draft (and later RFC), IPRs that relates to a codec specification from an external body does not require IETF IPR disclosure. Informative text explaining the nature of the codec would not normally require an IETF IPR declaration. Appropriate IPR declarations for the codec itself would normally be found in files of the external body defining the codec, in accordance with that external bodies own IPR rules. The main part of the IETF process is formally defined in BCP 9 [BCP9]. BCP 25 [BCP25] describes the WG process, the relation between the IESG and the WG, and the responsibilities of WG chairs and participants. It is important to note that the RFC series contains documents of several different publication streams as defined by the The RFC Series and RFC Editor [RFC4844]. The most important stream for RTP payload formats authors are the IETF Stream. In this streams the work of IETF is published. The stream contains documents of several different categories: standards track, informational, experimental, best current practice (BCP), and historic. The standards track contains two maturity levels: Proposed Standard and Internet Standard [RFC6410]. A standards track document must start as proposed; after successful deployment and operational experience with at least two Westerlund Expires November 5, 2015 [Page 7] Internet-Draft HOWTO: RTP Payload Formats May 2015 implementations it can be moved to Internet Standard. The Independent Submission Stream could appear to be of interest as it provides a way of publishing documents of certain categories such as experimental and informational with a different review process. However, as long as IETF has a WG which is chartered to work on RTP payload formats this stream should not be used. As the content of a given RFC is not allowed to change once published, the only way to modify an RFC is to write and publish a new one that either updates or replaces the old one. Therefore, whether reading or referencing an RFC, it is important to consider both the Category field in the document header and to check if the RFC is the latest on the subject and still valid. One way of checking the current status of an RFC is to use the RFC-editor's RFC search engine, which displays the current status and which if any RFC has updated or obsoleted it. The RFC-editor search engine will also indicate if there exist any RFC-errata. Any approved Errata is issues of significant importance with the RFC and thus should be known also prior to an update and replacement publication. Before starting to write a draft one should also read the Internet Draft writing guidelines (http://www.ietf.org/ietf/1id- guidelines.txt), the ID checklist (http://www.ietf.org/ID- Checklist.html) and the RFC editorial guidelines and procedures [RFC-ED]. Another document that can be useful is the "Guide for Internet Standards Writers" [RFC2360]. There are also a number of documents to consider in the process of writing drafts intended to become RFCs. These are important when writing certain type of text. RFC 2606: When writing examples using DNS names in Internet drafts, those names shall be chosen from the example.com, example.net, and example.org domains. RFC 3849: Defines the range of IPv6 unicast addresses (2001:DB8::/32) that should be used in any examples. RFC 5737: Defines the ranges of IPv4 unicast addresses reserved for documentation and examples: 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24. RFC 5234: Augmented Backus-Naur Form (ABNF) is often used when writing text field specifications. Not that commonly used in RTP payload formats but may be useful when defining Media Type parameters of some complexity. Westerlund Expires November 5, 2015 [Page 8] Internet-Draft HOWTO: RTP Payload Formats May 2015 3.2.2. RTP The recommended reading for RTP consists of several different parts; design guidelines, the RTP protocol, profiles, robustness tools, and media specific recommendations. Any author of RTP payload formats should start by reading Guidelines for Writers of RTP Payload Format Specifications [RFC2736] which contains an introduction to the application layer framing (ALF) principle, the channel characteristics of IP channels, and design guidelines for RTP payload formats. The goal of ALF is to be able to transmit Application Data Units (ADUs) that are independently usable by the receiver in individual RTP packets, thus minimizing dependencies between RTP packets and the effects of packet loss. Then it is advisable to learn more about the RTP protocol, by studying the RTP specification RFC 3550 [RFC3550] and the existing profiles. As a complement to the standards documents there exists a book totally dedicated to RTP [CSP-RTP]. There exist several profiles for RTP today, but all are based on the "RTP Profile for Audio and Video Conferences with Minimal Control" (RFC 3551) [RFC3551] (abbreviated as RTP/AVP). The other profiles that one should know about are Secure RTP (RTP/SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] and "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)" [RFC5124]. It is important to understand RTP and the RTP/AVP profile in detail. For the other profiles it is sufficient to have an understanding of what functionality they provide and the limitations they create. A number of robustness tools have been developed for RTP. The tools are for different use cases and real-time requirements. RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198] provides functionalities to transmit redundant copies of audio or text payloads. These redundant copies are sent together with a primary format in the same RTP payload. This format relies on the RTP timestamp to determine where data belongs in a sequence and therefore is usually most suitable to be used with audio. However, the RTP Payload format for T.140 [RFC4103] text format also uses this format. The format's major property is that it only preserves the timestamp of the redundant payloads, not the original sequence number. This makes it unusable for most video formats. This format is also only suitable for media formats that produce relatively small RTP payloads. RFC 6354: The "Forward-Shifted RTP Redundancy Payload Support" [RFC6354] is a variant of RFC 2198 which allows the redundant data to be transmitted prior to the original. Westerlund Expires November 5, 2015 [Page 9] Internet-Draft HOWTO: RTP Payload Formats May 2015 RFC 5109: The "RTP Payload Format for Generic Forward Error Correction (FEC)" [RFC5109] provides an XOR-based FEC of the whole or parts of a number of RTP packets. This specification replaced the previous specification for XOR-based FEC [RFC2733]. These FEC packets are sent in a separate stream or as a redundant encoding using RFC 2198. This FEC scheme has certain restrictions in the number of packets it can protect. It is suitable for low-to- medium delay tolerant applications with limited amount of RTP packets. RFC 6015: The "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)" [RFC6015] provides a variant of the XOR- based Generic protection defined in [RFC2733]. The main difference is to use interleaving scheme on which packets gets included as source packets for a particular protection packet. The interleaving is defined by using every L packets as source data. And then produce protection data over D number of packets. Thus each block of D x L source packets will result in L number of Repair packets, each capable of repairing one loss. The goal is to provide better burst error robustness when the packet rate is higher. FEC Framework: The Forward Error Correction (FEC) Framework [RFC6363] defines how to use FEC protection for arbitrary packet flows. This framework can be applied for RTP/RTCP packet flows, including using RTP for transmission of repair symbols, an example is the RTP Payload for Raptor FEC [RFC6682]. RTP Retransmission: The RTP retransmission scheme [RFC4588] is used for semi-reliability of the most important RTP packets in a media stream. The level of reliability between semi and in practice full reliability depends on the targeted properties and situation where parameters such as round-trip time (RTT) allowed additional overhead, and allowable delay. It often requires the application to be quite delay tolerant as a minimum of one round-trip time plus processing delay is required to perform a retransmission. Thus it is mostly suitable for streaming applications but may also be usable in certain other cases when operating in networks with short round-trip times. RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP packets over connection-oriented transports like TCP. If one uses TCP, one gets reliability for all packets but loses some of the real-time behavior that RTP was designed to provide. Issues with TCP transport of real-time media include head-of-line blocking and wasting resources on retransmission of already late data. TCP is also limited to point-to-point connections which further restricts its applicability. Westerlund Expires November 5, 2015 [Page 10] Internet-Draft HOWTO: RTP Payload Formats May 2015 There has also been both discussion and design of RTP payload formats, e.g., AMR and AMR-WB [RFC4867], supporting the unequal error detection provided by UDP-Lite [RFC3828]. The idea is that by not having a checksum over part of the RTP payload one can allow bit errors from the lower layers. By allowing bit errors one can increase the efficiency of some link layers, and also avoid unnecessary discarding of data when the payload and media codec can get at least some benefit from the data. The main issue is that one has no idea of the level of bit errors present in the unprotected part of the payload. This makes it hard or impossible to determine if one can design something usable or not. Payload format designers are recommended against considering features for unequal error detection using UDP-Lite unless very clear requirements exist. There also exist some management and monitoring extensions. RFC 2959: The RTP protocol Management Information Database (MIB) [RFC2959] that is used with SNMP [RFC3410] to configure and retrieve information about RTP sessions. RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of a framework for reports sent within RTCP. It can easily be extended by defining new report formats, which has and is occurring. The XRBLOCK WG in IETF is chartered (at the time of writing) with defining new report formats. The list of specified formats are available in IANA's RTCP XR Block Type registry (http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr- block-types.xhtml). The report formats that are defined in RFC3611 provide report information on packet loss, packet duplication, packet reception times, RTCP statistics summary and VoIP Quality. [RFC3611] also defines a mechanism that allows receivers to calculate the RTT to other session participants when used. RMONMIB: The remote monitoring WG has defined a mechanism [RFC3577] based on usage of the MIB that can be an alternative to RTCP XR. A number of transport optimizations have also been developed for use in certain environments. They are all intended to be transparent and do not require special consideration by the RTP payload format writer. Thus they are primarily listed here for informational reasons. RFC 2508: Compressing IP/UDP/RTP headers for slow serial links (CRTP) [RFC2508] is the first IETF developed RTP header compression mechanism. It provides quite good compression, however, it has clear performance problems when subject to packet loss or reordering between compressor and decompressor. Westerlund Expires November 5, 2015 [Page 11] Internet-Draft HOWTO: RTP Payload Formats May 2015 RFC 3095 & RFC 5795: These are the base specifications of the robust header compression (ROHC) protocol version 1 [RFC3095] and version 2 [RFC5795]. This solution was created as a result of CRTP's lack of performance when compressed packets are subject to loss. RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed to provide extensions to CRTP that allow for better performance over links with long RTTs, packet loss and/or reordering. RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is a solution that allows header compression within a tunnel carrying multiple multiplexed RTP flows. This is primarily used in voice trunking. There exist a couple of different security mechanisms that may be used with RTP. Generic mechanisms by definition are transparent for the RTP payload format and do not need special consideration by the format designer. The main reason that different solutions exist is that different applications have different requirements thus different solutions have been developed. For more discussion on this please see Options for Securing RTP Sessions [RFC7201] and Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution [RFC7202]. The main properties for an RTP security mechanism are to provide confidentiality for the RTP payload, integrity protection to detect manipulation of payload and headers, and source authentication. Not all mechanisms provide all of these features, a point which will need to be considered when a specific mechanisms is chosen. The profile for Secure RTP - SRTP (RTP/SAVP) [RFC3711] and the derived profile (RTP/SAVPF [RFC5124]) are a solution that enables confidentiality, integrity protection, replay protection and partial source authentication. It is the solution most commonly used with RTP at time of writing this documet. There exist several key- management solutions for SRTP, as well other choices, affecting the security properties. For a more in-depth review of the options and also other solutions than SRTP consult "Options for Securing RTP Sessions" [RFC7201]. 3.3. Important RTP Details This section reviews a number of RTP features and concepts that are available in RTP independent of the payload format. The RTP payload format can make use of these when appropriate, and even affect the behaviour (RTP timestamp and marker bit), but it is important to note that not all features and concepts are relevant to every payload format. This section does not remove the necessity to read up on Westerlund Expires November 5, 2015 [Page 12] Internet-Draft HOWTO: RTP Payload Formats May 2015 RTP. However, it does point out a few important details to remember when designing a payload format. 3.3.1. The RTP Session The definition of the RTP session from RFC 3550 is: "An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the encoding itself multiplexes multiple media into a single data stream. A participant distinguishes multiple RTP sessions by reception of different sessions using different pairs of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. All participants in an RTP session may share a common destination transport address pair, as in the case of IP multicast, or the pairs may be different for each participant, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants in the session using the same pair of ports, or may use a distinct pair of ports for each." "The distinguishing feature of an RTP session is that each session maintains a full, separate space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. For example, consider a three-party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions. If each participant provides RTCP feedback about its reception of one other participant to both of the other participants, then the conference is composed of one multi- party RTP session. The latter case simulates the behavior that would occur with IP multicast communication among the three participants." "The RTP framework allows the variations defined here (RFC3550), but a particular control protocol or application design will usually impose constraints on these variations." 3.3.2. RTP Header The RTP header contains a number of fields. Two fields always require additional specification by the RTP payload format, namely the RTP Timestamp and the marker bit. Certain RTP payload formats Westerlund Expires November 5, 2015 [Page 13] Internet-Draft HOWTO: RTP Payload Formats May 2015 also use the RTP sequence number to realize certain functionalities, primarily related to the order of their application data units. The payload type is used to indicate the used payload format. The Sender Source Identifier (SSRC) is used to distinguish RTP packets from multiple senders and media streams. Finally, [RFC5285] specifies how to transport payload format independent metadata relating to the RTP packet. Marker Bit: A single bit normally used to provide important indications. In audio it is normally used to indicate the start of a talk burst. This enables jitter buffer adaptation prior to the beginning of the burst with minimal audio quality impact. In video the marker bit is normally used to indicate the last packet part of a frame. This enables a decoder to finish decoding the picture, where it otherwise may need to wait for the next packet to explicitly know that the frame is finished. Timestamp: The RTP timestamp indicates the time instant the media sample belongs to. For discrete media like video, it normally indicates when the media (frame) was sampled. For continuous media it normally indicates the first time instance the media present in the payload represents. For audio this is the sampling time of the first sample. All RTP payload formats must specify the meaning of the timestamp value and the clock rates allowed. Selecting timestamp rate is an active design choice and is further discussed in Section 5.2. Discontinuous transmissions (DTX) that is common among speech codecs, typically results in gaps or jumps in the timestamp values due to that there is no media payload to transmit and the next used timestamp value represent the actual sampling time of the data transmitted. Sequence Number: The sequence number is monotonically increasing and is set as the packet is sent. This property is used in many payload formats to recover the order of everything from the whole stream down to fragments of application data units (ADUs) and the order they need to be decoded. Discontinuous transmissions do not result in gaps in the sequence number, as it is monotonically increasing for each sent RTP packet. Payload Type: The payload type is used to indicate on a per packet basis which format is used. The binding between a payload type number and a payload format and its configuration are dynamically bound and RTP session specific. The configuration information can be bound to a payload type value by out-of-band signalling (Section 3.4). An example of this would be video decoder configuration information. Commonly the same payload type is used Westerlund Expires November 5, 2015 [Page 14] Internet-Draft HOWTO: RTP Payload Formats May 2015 for a media stream for the whole duration of a session. However, in some cases it may be necessary to change the payload format or its configuration during the session. SSRC: The Synchronisation Source Identifier (SSRC) is normally not used by a payload format other than to identify the RTP timestamp and sequence number space a packet belongs to, allowing simultaneously reception of multiple media sources. However, some of the RTP mechanisms for improving resilience to packet loss uses multiple SSRCs to separate original data and repair or redundant data. Header Extensions: RTP payload formats often need to include metadata relating to the payload data being transported. Such metadata is sent as a payload header, at the start of the payload section of the RTP packet. The RTP packet also includes space for a header extension [RFC5285]; this can be used to transport payload format independent metadata, for example a SMPTE time code for the packet [RFC5484]. The RTP header extensions are not intended to carry headers that relate to a particular payload format., and must not contain information needed in order to decode the payload. The remaining fields do not commonly influence the RTP payload format. The padding bit is worth clarifying as it indicates that one or more bytes are appended after the RTP payload. This padding must be removed by a receiver before payload format processing can occur. Thus it is completely separate from any padding that may occur within the payload format itself. 3.3.3. RTP Multiplexing RTP has three multiplexing points that are used for different purposes. A proper understanding of this is important to correctly use them. The first one is separation of media streams of different types or usages, which is accomplished using different RTP sessions. So for example in the common multimedia session with audio and video, RTP commonly multiplexes audio and video in different RTP sessions. To achieve this separation, transport-level functionalities are used, normally UDP port numbers. Different RTP sessions are also used to realize layered scalability as it allows a receiver to select one or more layers for multicast RTP sessions simply by joining the multicast groups over which the desired layers are transported. This separation also allows different Quality of Service (QoS) to be applied to different media types. Use of multiple transport flows has potential issues due to NAT and Firewall traversal. The choices Westerlund Expires November 5, 2015 [Page 15] Internet-Draft HOWTO: RTP Payload Formats May 2015 how one applies RTP sessions as well as transport flows can affect the transport properties a RTP media stream experiences. The next multiplexing point is separation of different sources within an RTP session. Here RTP uses the SSRC to identify individual sources. An example of individual sources in an audio RTP session would be different microphones, independently of whether they are connected to the same host or different hosts. For each SSRC a unique RTP sequence number and timestamp space is used. The third multiplexing point is the RTP header payload type field. The payload type identifies what format the content in the RTP payload has. This includes different payload format configurations, different codecs, and also usage of robustness mechanisms like the one described in RFC 2198 [RFC2198]. For more discussion and consideration of how and when to use the different RTP multiplexing points see [I-D.ietf-avtcore-multiplex-guidelines]. 3.3.4. RTP Synchronization There are several types of synchronization and we will here describe how RTP handles the different types: Intra media: The synchronization within a media stream from a source (SSRC) is accomplished using the RTP timestamp field. Each RTP packet carries the RTP timestamp, which specifies the position in time of the media payload contained in this packet relative to the content of other RTP packets in the same RTP media stream (i.e., a given SSRC). This is especially useful in cases of discontinuous transmissions. Discontinuities can be caused by network conditions; when extensive losses occur the RTP timestamp tells the receiver how much later than previously received media the present media should be played out. Inter media: Applications commonly have a desire to use several media sources, possibly of different media types, at the same time. Thus, there exists a need to synchronize also different media from the same end-point. This puts two requirements on RTP: the possibility to determine which media are from the same end- point and if they should be synchronized with each other; and the functionality to facilitate the synchronization itself. The first step in inter-media synchronization is to determine which SSRCs in each session should be synchronized with each other. This is accomplished by comparing the CNAME fields in the RTCP SDES Westerlund Expires November 5, 2015 [Page 16] Internet-Draft HOWTO: RTP Payload Formats May 2015 packets. SSRCs with the same CNAME sent in any of multiple RTP sessions can be synchronized. The actual RTCP mechanism for inter-media synchronization is based on the idea that each media stream provides a position on the media specific time line (measured in RTP timestamp ticks) and a common reference time line. The common reference time line is expressed in RTCP as a wall clock time in the Network Time Protocol (NTP) format. It is important to notice that the wall clock time is not required to be synchronized between hosts, for example by using NTP [RFC5905] . It can even have nothing at all to do with the actual time, for example the host system's up-time can be used for this purpose. The important factor is that all media streams from a particular source that are being synchronized use the same reference clock to derive their relative RTP timestamp time scales. The type of reference clock and its timebase can be signalled using RTP Clock Source Signalling [RFC7273]. Figure 1 illustrates how if one receives RTCP Sender Report (SR) packet P1 in one media stream and RTCP SR packet P2 in the other session, then one can calculate the corresponding RTP timestamp values for any arbitrary point in time T. However, to be able to do that it is also required to know the RTP timestamp rates for each medium currently used in the sessions. TS1 --+---------------+-------> | | P1 | | | NTP ---+-----+---------T------> | | P2 | | | TS2 ---------+---------+---X--> Figure 1: RTCP Synchronization Assume that medium 1 uses an RTP Timestamp clock rate of 16 kHz, and medium 2 uses a clock rate of 90 kHz. Then TS1 and TS2 for point T can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). This calculation is useful as it allows the implementation to generate a common synchronization point for which all time values are provided (TS1(T), TS2(T) and T). So when one wishes to calculate the NTP time that the timestamp value present in packet X corresponds to one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000. Westerlund Expires November 5, 2015 [Page 17] Internet-Draft HOWTO: RTP Payload Formats May 2015 Improved signaling for layered codecs and fast tune-in have been specified in Rapid Synchronization for RTP flows [RFC6051]. Leap Seconds are extra seconds added or seconds removed to keep our clocks in sync with earth's rotation. Adding or removing seconds can impact first of all the reference clock as discussed in "RTP and Leap Seconds" [RFC7164]. But also in cases where the RTP timestamp values are derived using the wall clock during the leap second event errors can occur. Implementations need to consider leap seconds and should consider the recommendations in [RFC7164]. 3.4. Signalling Aspects RTP payload formats are used in the context of application signalling protocols such as SIP [RFC3261] using the Session Description Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC2326] or SAP [RFC2326]. These examples all use out-of-band signalling to indicate which type of RTP media streams that are desired to be used in the session and how they are configured. To be able to declare or negotiate the media format and RTP payload packetization, the payload format must be given an identifier. In addition to the identifier many payload formats have also the need to signal further configuration information out-of-band for the RTP payloads prior to the media transport session. The above examples of session-establishing protocols all use SDP, but other session description formats may be used. For example there was discussion of a new XML-based session description format within IETF (SDP-NG). In the event, the proposal did not get beyond the initial protocol specification because of the enormous installed base of SDP implementations. However, to avoid locking the usage of RTP to SDP based out-of-band signalling, the payload formats are identified using a separate definition format for the identifier and associated parameters. That format is the Media Type. 3.4.1. Media Types Media types [RFC6838] are identifiers originally created for identifying media formats included in email. In this usage they were known as MIME types, where the expansion of the MIME acronym includes the word "mail". The term "media type" was introduced to reflect a broader usage, which includes HTTP [RFC2616], MSRP [RFC4975] and many other protocols, to identify arbitrary content carried within the protocols. Media types also provide a media hierarchy that fits RTP payload formats well. Media type names are two-part and consist of content type and sub-type separated with a slash, e.g. "audio/PCMA" or "video/h263-2000". It is important to choose the correct content- type when creating the media type identifying an RTP payload format. Westerlund Expires November 5, 2015 [Page 18] Internet-Draft HOWTO: RTP Payload Formats May 2015 However, in most cases there is little doubt what content type the format belongs to. Guidelines for choosing the correct media type and registration rules for media type names are provided in Media Type Specifications and Registration Procedures [RFC6838]. The additional rules for media types for RTP payload formats are provided in Media Type Registration of RTP Payload Formats [RFC4855]. Registration of the RTP payload name is something that is required to avoid name collision in the future. Note that "x-" names are not suitable for any documented format as they have the same problem with name collision and can't be registered. The list of already registered media types can be found at IANA Web site (http://www.iana.org). Media types are allowed any number of parameters, which may be required or optional for that media type. They are always specified on the form "name=value". There exist no restrictions on how the value is defined from media type's perspective, except that parameters must have a value. However, the usage of media types in SDP, etc. has resulted in the following restrictions that need to be followed to make media types usable for RTP identifying payload formats: 1. Arbitrary binary content in the parameters is allowed but needs to be encoded so that it can be placed within text based protocols. Base64 [RFC4648] is recommended, but for shorter content Base16 [RFC4648] may be more appropriate as it is simpler to interpret for humans. This needs to be explicitly stated when defining a media type parameter with binary values. 2. The end of the value needs to be easily found when parsing a message. Thus parameter values that are continuous and not interrupted by common text separators, such as space and semi- colon, are recommended. If that is not possible some type of escaping should be used. Usage of quote (") is recommended, and do not forget to provide a method of encoding any character used for quoting inside the quoted element. 3. A common representation form for the media type and its parameters is on a single line. In that case the media type is followed by a semicolon-separated list of the parameter value pairs, e.g.: audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2 Westerlund Expires November 5, 2015 [Page 19] Internet-Draft HOWTO: RTP Payload Formats May 2015 3.4.2. Mapping to SDP Since SDP [RFC4566] is so commonly used as an out-of-band signalling protocol, a mapping of the media type into SDP exists. The details on how to map the media type and its parameters into SDP are described in RFC 4855 [RFC4855]. However, this is not sufficient to explain how certain parameters must be interpreted for example in the context of Offer/Answer negotiation [RFC3264]. 3.4.2.1. The Offer/Answer Model The Offer/Answer (O/A) model allows SIP to negotiate which media formats and payload formats are to be used in a session and how they are to be configured. However, O/A does not define a default behavior and instead points out the need to define how parameters behave. To make things even more complex the direction of media within a session has an impact on these rules, so that some cases may require separate descriptions for media streams that are send-only, receive-only or both sent and received as identified by the SDP attributes a=sendonly, a=recvonly, and a=sendrecv. In addition the usage of multicast adds further limitations as the same media stream is delivered to all participants. If those multicast-imposed restrictions are too limiting for unicast then separate rules for unicast and multicast will be required. The simplest and most common O/A interpretation is that a parameter is defined to be declarative; i.e., the SDP offer/answer sending agent can declare a value and that has no direct impact on the other agent's values. This declared value applies to all media that are going to be sent to the declaring entity. For example most video codecs have a level parameter which tells the other participants the highest complexity the video decoder supports. The level parameter can be declared independently by two participants in a unicast session as it will be the media sender's responsibility to transmit a video stream that fulfills the limitation the other side has declared. However, in multicast it will be necessary to send a stream that follows the limitation of the weakest receiver, i.e., the one that supports the lowest level. To simplify the negotiation in these cases it is common to require any answerer to a multicast session to take a yes or no approach to parameters. A "negotiated" parameter is a different case, for which both sides need to agree on its value. Such a parameter requires the answerer to either accept it as it is offered or remove the payload type the parameter belonged to from its answer. The removal of the payload type from the answer indicates to the offerer the lack of support for the parameter values presented. An unfortunate implication of the need to use complete payload types to indicate each possible Westerlund Expires November 5, 2015 [Page 20] Internet-Draft HOWTO: RTP Payload Formats May 2015 configuration so as to maximize the chances of achieving interoperability, is that the number of necessary payload types can quickly grow large. This is one reason to limit the total number of sets of capabilities that may be implemented. The most problematic type of parameters are those that relate to the media the entity sends. They do not really fit the O/A model but can be shoe-horned in. Examples of such parameters can be found in the H.264 video codec's payload format [RFC6184], where the name of all parameters with this property starts with "sprop-". The issue with these parameters is that they declare properties for a media stream that the other party may not accept. The best one can make of the situation is to explain the assumption that the other party will accept the same parameter value for the media it will receive as the offerer of the session has proposed. If the answerer needs to change any declarative parameter relating to streams it will receive then the offerer may be required to make an new offer to update the parameter values for its outgoing media stream. Another issue to consider is the send-only media streams in offers. Parameters that relate to what the answering entity accepts to receive have no meaning other than to provide a template for the answer. It is worth pointing out in the specification that these really provide a set of parameter values that the sender recommends. Note that send-only streams in answers will need to indicate the offerer's parameters to ensure that the offerer can match the answer to the offer. A further issue with offer/answer which complicates things is that the answerer is allowed to renumber the payload types between offer and answer. This is not recommended but allowed for support of gateways to the ITU conferencing suite. This means that it must be possible to bind answers for payload types to the payload types in the offer even when the payload type number has been changed, and some of the proposed payload types have been removed. This binding must normally be done by matching the configurations originally offered against those in the answer. This may require specification in the payload format of which parameters that constitute a configuration, for example as done in Section 8.2.2 of the H.264 RTP Payload format [RFC6184]; "The parameters identifying a media format configuration for H.264 are profile-level-id and packetization-mode". 3.4.2.2. Declarative Usage in RTSP and SAP SAP (Session Announcement Protocol) [RFC2974] was experimentally used for announcing multicast sessions. Similar but better protocols are using SDP in a declarative style to configure multicast based applications. Independently of the usage of Source-specific Westerlund Expires November 5, 2015 [Page 21] Internet-Draft HOWTO: RTP Payload Formats May 2015 Multicast (SSM) [RFC3569] or Any-source Multicast (ASM), the SDP provided by these configuration delivery protocols applies to all participants. All media that is sent to the session must follow the media stream definition as specified by the SDP. This enables everyone to receive the session if they support the configuration. Here SDP provides a one way channel with no possibility to affect the configuration that the session creator has decided upon. Any RTP Payload format that requires parameters for the send direction and which needs individual values per implementation or instance will fail in a SAP session for a multicast session allowing anyone to send. Real-Time Streaming Protocol (RTSP) [RFC2326] allows the negotiation of transport parameters for media streams which are part of a streaming session between a server and client. RTSP has divided the transport parameters from the media configuration. SDP is commonly used for media configuration in RTSP and is sent to the client prior to session establishment, either through use of the DESCRIBE method or by means of an out-of-band channel like HTTP, email etc. The SDP is used to determine which media streams and what formats are being used prior to session establishment. Thus both SAP and RTSP use SDP to configure receivers and senders with a predetermined configuration for a media stream including the payload format and any of its parameters. All parameters are used in a declarative fashion. This can result in different treatment of parameters between offer/answer and declarative usage in RTSP and SAP. Any such difference will need to be spelled out by the payload format specification. 3.5. Transport Characteristics The general channel characteristics that RTP flows experience are documented in Section 3 of Guidelines for Writers of RTP Payload Format Specifications [RFC2736]. The discussion below provides additional information. 3.5.1. Path MTU At the time of writing, the most common IP Maximum Transmission Unit (MTU) in commonly deployed link layers is 1500 bytes (Ethernet data payload). However, there exist both links with smaller MTUs and links with much larger MTUs. An example for links with small MTU size is older generation cellular links. Certain parts of the Internet already support an IP MTU of 8000 bytes or more, but these are limited islands. The most likely places to find MTUs larger than 1500 bytes are within enterprise networks, university networks, data centers, storage networks as well as over high capacity (10 Gbps or Westerlund Expires November 5, 2015 [Page 22] Internet-Draft HOWTO: RTP Payload Formats May 2015 more) links. There is a slow ongoing evolution towards larger MTU sizes. However, at the same time it has become common to use tunneling protocols, often multiple ones whose overhead when added together can shrink the MTU significantly. Thus, there exists a need to consider both limited MTUs as well as enable support of larger MTUs. This should be considered in the design, especially in regards to features such as aggregation of independently decodable data units. 3.5.2. Different Queuing Algorithms Routers and switches on the network path between an IP sender and a particular receiver can exhibit different behaviors affecting the end-to-end characteristics. One of the more important aspects of this is queuing behavior. Routers and switches have some amount of queuing to handle temporary bursts of data that designated to leave the switch or router on the same egress link. A queue when not empty results in an increased path delay. The implementation of the queuing affects the delay and also how congestion signals (Explicit Congestion Marking (ECN) [RFC6679] or packet drops) are provided to the flow. The other aspects are if the flow shares the queue with other flows and how the implementation affects the flow interaction. This becomes important for example when real-time flows interact with long-lived TCP flows. TCP has a built-in behavior in its congestion control that strive to fill the buffer, thus all flows sharing the buffer experienced the delay build up. A common but quite poor queue handling mechanism is tail-drop, i.e., only drop packets when the incoming packet doesn't fit in the queue. If a bad queuing algorithm is combined with too much queue space the queuing time can grow very significant and can even become multiple seconds. This is called bufferbloat [BLOAT]. Active Queue Management (AQM) is a term covering mechanisms that try to do something smarter by actively managing the queue, for example by sending congestion signals earlier by dropping packets earlier in the queue. The behavior also affects the flow interactions. For example, Random Early Drop (RED) selects which packet(s) to drop randomly. This give flows that have more packets in the queue a higher probability to experience the packet loss (congestion signal). There is ongoing work to find suitable mechanisms to recommend for implementation and reduce the use of tail-drop. Westerlund Expires November 5, 2015 [Page 23] Internet-Draft HOWTO: RTP Payload Formats May 2015 3.5.3. Quality of Service Using best effort Internet has no guarantees for the paths properties. Quality of Service (QoS) mechanism are intended to provide the possibility to bound the path properties. Where Diffserv [RFC2475] markings effects the queuing and forwarding behaviors of routers, the mechanism provides only statistical guarantees and care in how much marked packets of different types that are entering the network. Flow-based QoS like IntServ [RFC1633] has the potential for stricter guarantees as the properties are agreed on by each hop on the path at the cost of per-flow state in the network. 4. Standardisation Process for an RTP Payload Format This section discusses the recommended process to produce an RTP payload format in the described venues. This is to document the best current practice on how to get a well-designed and specified payload format as quickly as possible. For specifications that are defined by standards bodies other than the IETF, the primary milestone is the registration of the Media Type for the RTP payload format. For proprietary media formats, the primary goal depends on whether interoperability is desired at the RTP level. However, there is also the issue of ensuring best possible quality of any specification. 4.1. IETF For all standardized media formats, it is recommended that the payload format be specified in the IETF. The main reason is to provide an openly available RTP payload format specification that has been reviewed by people experienced with RTP payload formats. At the time of writing, this work is done in the PAYLOAD Working Group (WG), but that may change in the future. 4.1.1. Steps from Idea to Publication There are a number of steps that an RTP payload format should go through from the initial idea until it is published. This also documents the process that the PAYLOAD Working Group applies when working with RTP payload formats. Idea: Determined the need for an RTP payload format as an IETF specification. Initial effort: Using this document as guideline one should be able to get started on the work. If one's media codec doesn't fit any of the common design patterns or one has problems understanding what the most suitable way forward is, then one should contact the PAYLOAD Working Group and/or the WG chairs. The goal of this Westerlund Expires November 5, 2015 [Page 24] Internet-Draft HOWTO: RTP Payload Formats May 2015 stage is to have an initial individual draft. This draft needs to focus on the introductory parts that describe the real-time media format and the basic idea on how to packetize it. Not all the details are required to be filled in. However, the security chapter is not something that one should skip even initially. It is important to consider from the start any serious security risks that need to be solved. The first step is completed when one has a draft that is sufficiently detailed for a first review by the WG. The less confident one is of the solution, the less work should be spent on details; instead concentrate on the codec properties and what is required to make the packetization work. Submission of the first version: When one has performed the above one submits the draft as an individual draft. This can be done at any time except for a period prior to an IETF meeting. See important dates related to the next IETF meeting for draft submission cut-off date. When the IETF draft announcement has been sent out on the draft announcement list, forward it to the PAYLOAD WG and request that it be reviewed. In the email outline any issues the authors currently have with the design. Iterative improvements: Taking the feedback into account one updates the draft and tries resolve issues. New revisions of the draft can be submitted at any time (again except for a short period before meetings). It is recommended to submit a new version whenever one has made major updates or has new issues that are easiest to discuss in the context of a new draft version. Becoming a WG document: Given that the definition of RTP payload formats is part of the PAYLOAD WG's charter, RTP payload formats that are going to be published as standards track RFCs need to become WG documents. Becoming a WG document means that the chairs are responsible for administrative handling, for example, issuing publication requests. However, be aware that making a document into a WG document changes the formal ownership and responsibility from the individual authors to the WG. The initial authors normally continue being the document editors, unless unusual circumstances occur. The PAYLOAD WG accepts new RTP payload formats based on their suitability and document maturity. The document maturity is a requirement to ensure that there are dedicated document editors and that there exists a good solution. Iterative improvements: The updates and review cycles continue until the draft has reached the level of maturity suitable for publication. WG Last Call: A WG Last Call of at least 2 weeks is always performed for payload formats in the PAYLOAD WG (See Section 7.4 Westerlund Expires November 5, 2015 [Page 25] Internet-Draft HOWTO: RTP Payload Formats May 2015 of [RFC2418]). The authors request WG last call for a draft when they think it is mature enough for publication. The chairs perform a review to check if they agree with the authors' assessment. If the chairs agree on the maturity, the WG Last Call is announced on the WG mailing list. If there are issues raised, these need to be addressed with an updated draft version. For any more substantial updates of the draft, a new WG last call is announced for the updated version. Minor changes, like editorial fixes, can be progressed without an additional WG last call. Publication Requested: For WG documents the chairs request publication of the draft, after it has passed WG Last Call. After this, the approval and publication process described in BCP 9 [BCP9] is performed. The status after the publication has been requested can be tracked using the IETF data tracker [TRACKER]. Documents do not expire as they normally do after publication has been requested, so authors do not have to issue keep-alive updates. In addition, any submission of document updates requires the approval of WG chair(s). The authors are commonly asked to address comments or issues raised by the IESG. The authors also do one last review of the document immediately prior to its publication as an RFC to ensure that no errors or formatting problems have been introduced during the publication process. 4.1.2. WG meetings WG meetings are for discussing issues, not presentations. This means that most RTP payload formats should never need to be discussed in a WG meeting. RTP payload formats that would be discussed are either those with controversial issues that failed to be resolved on the mailing list, or those including new design concepts worth a general discussion. There exists no requirement to present or discuss a draft at a WG meeting before it becomes published as an RFC. Thus, even authors who lack the possibility to go to WG meetings should be able to successfully specify an RTP payload format in the IETF. WG meetings may become necessary only if the draft gets stuck in a serious debate that cannot easily be resolved. 4.1.3. Draft Naming To simplify the work of the PAYLOAD WG chairs and its WG members a specific draft file naming convention shall be used for RTP payload formats. Individual submissions shall be named draft--payload-rtp--. The WG documents shall be named according to this template: draft-ietf- payload-rtp--. The inclusion of "payload" Westerlund Expires November 5, 2015 [Page 26] Internet-Draft HOWTO: RTP Payload Formats May 2015 in the draft file name ensures that the search for "payload-" will find all PAYLOAD related drafts. Inclusion of "rtp" tells us that it is an RTP payload format draft. The descriptive name should be as short as possible while still describing what the payload format is for. It is recommended to use the media format or codec acronym. Please note that the version must start at 00 and is increased by one for each submission to the IETF secretary of the draft. No version numbers may be skipped. For more details on IETF draft naming please see Section 7 of [ID-GUIDE]. 4.1.4. Writing Style When writing an IETF draft for an RTP payload format one should observe some few considerations (that may be somewhat diverging from the style other IETF documents and/or the media coding spec's author group may use): Include Motivations: In the IETF, it is common to include the motivation for why a particular design or technical choice was chosen. These are not long statements, a sentence here and there explaining why suffice. Use the defined Terminology: There exists defined terminology both in RTP and in the media codec specification for which the RTP payload format is designed. A payload format specification needs to use both to make clear the relation of features and their functions. It is unwise to introduce or, worse, use without introduction, terminology that appears to be more accessible to average readers but may miss certain nuances that the defined terms imply. An RTP payload format author can assume the reader to be reasonably familiar with the terminology in the media coding spec. Keeping It Simple: The IETF has a history of specifications that are focused on their main usage. Historically, some RTP Payload formats have a lot of modes and features, while the actually deployments have only included the most basic features that had very clear requirements. Time and effort can be saved by focusing on only the most important use cases, and keep the solution simple. An extension mechanism should be provided to enable backward-compatible extensions, if that is an organic fit. Normative Requirements: When writing specifications there is commonly a need to make it clear when something is normative and at what level. In IETF the most common method is to use "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] that defines the meaning of "MUST", "MUST NOT", "REQUIRED", Westerlund Expires November 5, 2015 [Page 27] Internet-Draft HOWTO: RTP Payload Formats May 2015 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". 4.1.5. How to speed up the process There a number of ways to lose a lot of time in the above process. This section discusses what to do and what to avoid. o Do not update the draft only for the meeting deadline. An update to each meeting automatically limits the draft to three updates per year. Instead, ignore the meeting schedule and publish new versions as soon as possible. o Try to avoid requesting reviews when people are busy, like the few weeks before a meeting. It is actually more likely that people have time for them directly after a meeting. o Perform draft updates quickly. A common mistake is that the authors let the draft slip. By performing updates to the draft text directly after getting resolution on an issue, things speed up. This minimizes the delay that the author has direct control over. The time taken for reviews, responses from area directors and chairs, etc. can be much harder to speed up. o Do not fail to take human nature into account. It happens that people forget or need to be reminded about tasks. Send a kind reminder to the people you are waiting for if things take longer than expected. Ask people to estimate when they expect to fulfill the requested task. o Ensure there is enough review. It is common that documents take a long time and many iterations because not enough review is performed in each iteration. To improve the amount of review you get on your own document, trade review time with other document authors. Make a deal with some other document author that you will review their draft if they review yours. Even inexperienced reviewers can help with language, editorial or clarity issues. Try also approaching the more experienced people in the WG and getting them to commit to a review. The WG chairs cannot, even if desirable, be expected to review all versions. Due to workload the chairs may need to concentrate on key points in a draft evolution, like initial submissions, checking if a draft is ready to become a WG document or ready for WG last call. Westerlund Expires November 5, 2015 [Page 28] Internet-Draft HOWTO: RTP Payload Formats May 2015 4.2. Other Standards Bodies Other standards bodies may define RTP payloads in their own specifications. When they do this they are strongly recommended to contact the PAYLOAD WG chairs and request review of the work. It is recommended that at least two review steps are performed. The first should be early in the process when more fundamental issues can be easily resolved without abandoning a lot of effort. Then when nearing completion, but while it is still possible to update the specification, a second review should be scheduled. In that pass the quality can be assessed and hopefully no updates will be needed. Using this procedure can avoid both conflicting definitions and serious mistakes, like breaking certain aspects of the RTP model. RTP payload Media Types may be registered in the standards tree by other standard bodies. The requirements on the organization are outlined in the media types registration document [RFC4855] and [RFC6838]). This registration requires a request to the IESG, which ensures that the filled-in registration template is acceptable. To avoid last-minute problems with these registrations the registration template must be sent for review both to the PAYLOAD WG and the media types list (ietf-types@iana.org) and is something that should be included in the IETF reviews of the payload format specification. 4.3. Proprietary and Vendor Specific Proprietary RTP payload formats are commonly specified when the real- time media format is proprietary and not intended to be part of any standardized system. However, there are reasons why also proprietary formats should be correctly documented and registered: o Usage in a standardized signalling environment such as SIP/SDP. RTP needs to be configured with the RTP profiles, payload formats and their payload types being used. To accomplish this it is desirable to have registered media type names to ensure that the names do not collide with those of other formats. o Sharing with business partners. As RTP payload formats are used for communication, situations often arise where business partners would like to support a proprietary format. Having a well written specification of the format will save time and money for both parties, as interoperability will be much easier to accomplish. o To ensure interoperability between different implementations on different platforms. To avoid name collisions there is a central registry keeping tracks of the registered Media Type names used by different RTP payload Westerlund Expires November 5, 2015 [Page 29] Internet-Draft HOWTO: RTP Payload Formats May 2015 formats. When it comes to proprietary formats they should be registered in the vendor's own tree. All vendor specific registrations use sub-type names that start with "vnd.". Names in the vendor's own tree are not required to be registered with IANA. However registration [RFC6838] is recommended if the Media Type is used at all in public environments. If interoperability at the RTP level is desired, a payload type specification should be standardized in the IETF following the process described above. The IETF does not require full disclosure of the codec when defining an RTP payload format to carry that codec, but a description must be provided that is sufficient to allow the IETF to judge whether the payload format is well designed. The Media Type identifier assigned to a standardized payload format of this sort will lie in the standards tree rather than the vendor tree. 4.4. Joint Development of Media Coding Specification and RTP Payload Format In the last decade there have been a few cases where the media codec and the associated RTP payload format have been developed concurrently and jointly. Developing the two specs not only concurrently but also jointly, in close cooperation with the group developing the media codec, allows to leverage the benefits joint source/channel coding can provide. Doing so has historically resulted in well performing payload formats and in success of both media coding spec and associated RTP payload format. Insofar, whenever the opportunity presents it, it may be useful to closely keep the media coding group in the loop (through appropriate liaison means whatever those may be) and influence the media coding spec to be RTP friendly. One example for such a media coding spec is H.264, where the RTP payload header co-serves as the H.264 NAL unit header and vice versa, and is documented in both specs. 5. Designing Payload Formats The best summary of payload format design is KISS (Keep It Simple, Stupid). A simple payload format is easier to review for correctness, easier to implement, and has low complexity. Unfortunately, contradictory requirements sometimes make it hard to do things simply. Complexity issues and problems that occur for RTP payload formats are: Too many configurations: Contradictory requirements lead to the result that one configuration is created for each conceivable case. Such contradictory requirements are often between functionality and bandwidth. This outcome has two big disadvantages; First all configurations need to be implemented. Westerlund Expires November 5, 2015 [Page 30] Internet-Draft HOWTO: RTP Payload Formats May 2015 Second, the user application must select the most suitable configuration. Selecting the best configuration can be very difficult and in negotiating applications, this can create interoperability problems. The recommendation is to try to select a very limited set of configurations (preferably one) that perform well for the most common cases and are capable of handling the other cases, but maybe not that well. Hard to implement: Certain payload formats may become difficult to implement both correctly and efficiently. This needs to be considered in the design. Interaction with general mechanisms: Special solutions may create issues with deployed tools for RTP, such as tools for more robust transport of RTP. For example, a requirement for a non-broken sequence number space creates issues for mechanisms relying on payload type switching interleaving media-independent resilience within a stream. 5.1. Features of RTP Payload Formats There are a number of common features in RTP payload formats. There is no general requirements to support these features; instead, their applicability must be considered for each payload format. It may in fact be that certain features are not even applicable. 5.1.1. Aggregation Aggregation allows for the inclusion of multiple application data units (ADUs) within the same RTP payload. This is commonly supported for codecs that produce ADUs of sizes smaller than the IP MTU. One reason for the use of aggregation is the reduction of header overhead (IP/UDP/RTP headers). When setting into relation the ADU size and the MTU size, do remember that the MTU may be significantly larger than 1500 bytes. An MTU of 9000 bytes is available today and an MTU of 64k may be available in the future. Many speech codecs have the property of ADUs of a few fixed sizes. Video encoders may generally produce ADUs of quite flexible sizes. Thus the need for aggregation may be less. But some codecs produces small ADUs mixed with large, for example H.264 SEI messages. Sending individual SEI message in separate packets are not efficient compared to combing the with other ADUs. Also, some small ADUs are, within the media domain, semantically coupled to the larger ADUs (for example in-band parameter sets in H.264 [RFC6184]). In such cases, aggregation is sensible even if not required from a payload/header overhead viewpoint. There also exist cases when the ADUs are pre-produced and can't be adopted to a specific networks MTU. Instead their packetization needs to be adopted to the network. All above factors Westerlund Expires November 5, 2015 [Page 31] Internet-Draft HOWTO: RTP Payload Formats May 2015 should be taken into account when deciding of the inclusion of aggregation, and weighting its benefits against the complexity of defining them (which can be significant especially when aggregation is performed over ADUs with different playback times). The main disadvantage of aggregation beyond implementation complexity is the extra delay introduced (due to buffering until a sufficient number of ADUs have been collected at the sender) and reduced robustness against packet loss. Aggregation also introduces buffering requirements at the receiver. 5.1.2. Fragmentation If the real-time media format has the property that it may produce ADUs that are larger than common MTU sizes then fragmentation support should be considered. An RTP Payload format may always fall back on IP fragmentation, however, as discussed in RFC 2736 this has some drawbacks. The perhaps most important reason to avoid IP fragmentation is that IP fragmented packets commonly are discarded in the network, especially by Network Address Translators or Firewalls. The usage of RTP payload format-level fragmentation allows for more efficient usage of RTP packet loss recovery mechanisms. It may also in some cases also allow better usage of partial ADUs by doing media specific fragmentation at media specific boundaries. In use cases where the ADUs are pre-produced and can't be adopted to the network's MTU size, support for fragmentation can be crucial. 5.1.3. Interleaving and Transmission Re-Scheduling Interleaving has been implemented in a number of payload formats to allow for less quality reduction when packet loss occurs. When losses are bursty and several consecutive packets are lost, the impact on quality can be quite severe. Interleaving is used to convert that burst loss to several spread-out individual packet losses. It can also be used when several ADUs are aggregated in the same packets. A loss of an RTP packet with several ADUs in the payload has the same effect as a burst loss if the ADUs would have been transmitted in individual packets. To reduce the burstiness of the loss, the data present in an aggregated payload may be interleaved, thus spread the loss over a longer time period. A requirement for doing interleaving within an RTP payload format is the aggregation of multiple ADUs. For formats that do not use aggregation there is still a possibility of implementing a transmission order re-scheduling mechanism. That has the effect that the packets transmitted consecutively originate from different points in the media stream. This can be used to mitigate burst losses, which may be useful if one transmits packets at frequent intervals. Westerlund Expires November 5, 2015 [Page 32] Internet-Draft HOWTO: RTP Payload Formats May 2015 However it may also be used to transmit more significant data earlier in combination with RTP retransmission to allow for more graceful degradation and increased possibility to receive the most important data, e.g., intra frames of video. The drawback of interleaving is the significantly increased transmission buffering delay, making it less useful for low-delay applications. It may also create significant buffering requirements on the receiver. That buffering is also problematic as it is usually difficult to indicate when a receiver may start consume data and still avoid buffer under run caused by the interleaving mechanism itself. Transmission re-scheduling is only useful in a few specific cases, as in streaming with retransmissions. The potential gains must be weighed against the complexity of these schemes. 5.1.4. Media Back Channels A few RTP payload formats have implemented back channels within the media format. Those have been for specific features, like the AMR [RFC4867] codec mode request (CMR) field. The CMR field is used in the operation of gateways to circuit-switched voice to allow an IP terminal to react to the circuit-switched network's need for a specific encoder mode. A common motivation for media back channels is the need to have signalling in direct relation to the media or the media path. If back channels are considered for an RTP payload format they should be for a specific requirements which cannot be easily satisfied by more generic mechanisms within RTP or RTCP. 5.1.5. Media Scalability Some codecs support various types of media scalability, i.e. some data of a media stream may be removed to adapt the media's properties, such as bitrate and quality. The adaptation may be applied in the following dimensions of the media: Temporal: For most video codecs it is possible to adapt the frame rate without any specific definition of a temporal scalability mode, e.g., for H.264 [RFC6184]. In these cases the sender change which frames it delivers and the RTP timestamp makes it clear the frame interval and each frames relative capture time. H.264 Scalable Video Coding (SVC) [RFC6190] has more explicit support for temporal scalability. Spatial: Video codecs supporting scalability may adapt the resolution, e.g., in SVC [RFC6190]. Westerlund Expires November 5, 2015 [Page 33] Internet-Draft HOWTO: RTP Payload Formats May 2015 Quality: The quality of the media stream may be scaled by adapting the accuracy of the coding process, as, e.g. possible with Signal to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190]. At the time of writing this document, codecs that support scalability have a bit of revival. It has been realized that getting the required functionality for supporting the features of the media stream into the RTP framework is quite challenging. One of the recent examples for layered and scalable codecs is Scalable Video Coding [RFC6190] (SVC). SVC is a good example for a payload format supporting media scalability features, which have been in its basic form already included in RTP. A layered codec supports the dropping of data parts of a media stream, i.e., RTP packets may be not transmitted or forwarded to a client in order to adapt the media stream rate as well as the media stream quality, while still providing a decodable subset of the media stream to a client. One example for using the scalability feature may be an RTP Mixer (Multipoint Control Unit) which controls the rate and quality sent out to participants in a communication based on dropping RTP packets or removing part of the payload. Another example may be a transport channel which allows for differentiation in Quality of Service (QoS) parameters based on RTP sessions in a multicast session. In such a case, the more important packets of the scalable media stream (base layer) may get better QoS parameters, then the less important packets (enhancement layer) in order to provide some kind of graceful degradation. The scalability features required for allowing an adaptive transport as described in the two examples above are based on RTP multiplexing in order to identify the packets to be dropped or transmitted/forwarded. The multiplexing features defined for Scalable Video Coding [RFC6190] are: single session transmission (SST), where all media layers of the media are transported as single source (SSRC) in a single RTP session; as well as multi session transmission (MST), which should more accurately be called multi stream transmission, where different media layers or a set of media layers are transported in different RTP streams, i.e., using multiple sources (SSRCs). In the first case (SST), additional in-band as well as out-of-band signaling is required in order to allow identification of packets belonging to a specific media layer. Furthermore, an adaptation of the media stream requires dropping of specific packets in order to provide the client with a compliant media stream. In case of using encryption, it is typically required for an adapting network device Westerlund Expires November 5, 2015 [Page 34] Internet-Draft HOWTO: RTP Payload Formats May 2015 to be in the security context to allow packet dropping and providing an intact RTP session to the client. This typically requires the network device to be an RTP mixer. In general having a media unaware network device dropping excessive packets will be more problematic than having a Media Aware Network Entity (MANE). First is the need to understand the media format and know which ADUs or payloads that belongs to the layers, that no other layer will be dependent on after the dropping. Secondly, if the MANE can work as RTP mixer or translator it can rewrite the RTP and RTCP in such a way that the receiver will not suspect non-intentional RTP packet losses needing repair actions. This as the receiver can't determine if a lost packet was an important base layer packet or one of the less important extension layers. In the second case (MST), the RTP packet streams can be sent using a single or multiple RTP sessions, and thus transport flows, e.g., on different multicast groups. Transmitting the streams in different RTP sessions, then the out-of-band signaling typically provides enough information to identify the media layers and its properties. The decision for dropping packets is based on the Network Address which identifies the RTP session to be dropped. In order to allow correct data provisioning to a decoder after reception from different sessions, data re-alignment mechanisms are required. In some cases, existing generic tools as described below can be employed to enable such re-alignment, and when those generic mechanisms are sufficient, they should be used. For example, Rapid Sync for RTP flows [RFC6051], uses existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely inter-session synchronization. Another is the signaling feature for indicating dependencies of RTP sessions in SDP, as defined in the Media Decoding Dependency Grouping in SDP [RFC5583]. Using MST within a single RTP session is also possible and allows stream level handling instead of looking deeper into the packets by a MANE. However, transport flow level properties will be the same unless packet based mechanisms like DiffServ is used. When QoS settings, e.g., DiffServ markings, are used to ensure that the extension layers are dropped prior the base layer the receiving end-point has the benefit in MST to know which layer or set of layers the missing packets belong as it will be bound to different RTP sessions or RTP packet streams (SSRCs), thus explicitly indicating the importance of the loss. Westerlund Expires November 5, 2015 [Page 35] Internet-Draft HOWTO: RTP Payload Formats May 2015 5.1.6. High Packet Rates Some media codecs require high packet rates, and in these cases the RTP sequence number wraps too quickly. As rule of thumb, it must not be possible to wrap the sequence number space within at least three RTCP reporting intervals. As the reporting interval can vary widely due to configuration and session properties, and also must take into account the randomization of the interval, one can use the TCP maximum segment lifetime (MSL), i.e. 2 minutes, in ones consideration. If earlier wrapping may occur then the payload format should specify an extended sequence number field to allow the receiver to determine where a specific payload belongs in the sequence, even in the face of extensive reordering. The RTP payload format for uncompressed video [RFC4175] can be used as an example for such a field. RTCP is also affected by high packet rates. For RTCP mechanism that do not use extended counters there is significant risk that they wrap multiple times between RTCP reporting or feedback, thus producing uncertainty about which packet(s) are referenced. The payload designer can't effect the RTCP packet formats used and their design, but can note this considerations when configuring RTCP bandwidth and reporting intervals to avoid to wrapping issues. 5.2. Selecting Timestamp Definition The RTP Timestamp is an important part and has two design choices associated with it. The first is the definition that determines what the timestamp value in a particular RTP packet will be, the second is which timestamp rate should be used. The timestamp definition needs to explicitly define what the timestamp value in the RTP packet represent for a particular payload format. Two common definitions are used; for discretely sampled media, like video frames, the sampling time of the earliest included video frame which the data represent (fully or partially) is used; for continuous media like audio, the sampling time of the earliest sample which the payload data represent. There exist cases where more elaborate or other definitions are used. RTP payload formats with a timestamp definition which results in no or little correlation between the media time instance and its transmission time cause the RTCP jitter calculation to become unusable due to the errors introduced on the sender side. A common example is a payload format for a video codec where the RTP timestamp represents the capture time of the video frame, but frames are large enough that multiple RTP packets need to be sent for each frame Westerlund Expires November 5, 2015 [Page 36] Internet-Draft HOWTO: RTP Payload Formats May 2015 spread across the framing interval. It should be noted if the payload format has this property or not. A RTP payload format also needs to define what timestamp rates, or clock rates (as it is also called), that may be used. Depending on the RTP payload format this may be a single rate or multiple ones or theoretically any rate. So what needs to be considered when selecting rate? The rate needs be selected so that one can determine where in the time line of the media a particular sample (e.g., individual audio sample, or video frame) or set of samples (e.g., audio frames) belong. To enable correct synchronization of this data with previous frames, including over periods of discontinuous transmission or irregularities. For audio it is common to require audio sample accuracy. Thus one commonly selects the input sampling rate as the timestamp rate. This can, however, be challenging for audio codecs that support multiple different sampling frequencies, either as codec input or being used internally but effecting output, for example frame duration. Depending on how one expects to use these different sampling rates one can allow multiple timestamp rates, each matching a particular codec input or sampling rate. However, due to the issues with using multiple different RTP timestamp rates for the same source (SSRC) [RFC7160] this should be avoided if one expects to need to switch between modes. An alternatives then is to find a common denominator frequency between the different modes, e.g. OPUS [I-D.ietf-payload-rtp-opus] that uses 48 KHz. If the different modes uses or can use a common input/output frequency then selecting this also needs to be considered. However, it is important to consider all aspects as the case of AMR-WB+ [RFC4352] illustrates. AMR-WB+'s RTP timestamp rate has the very unusual value of 72 kHz, despite the fact that output normally is at a sample rate of 48kHz. The design is motivated by the media codec's production of a large range of different frame lengths in time perspective. The 72 kHz timestamp rate is the smallest found value that would make all of the frames the codec could produce result in an integer frame length in RTP timestamp ticks. This way, a receiver can always correctly place the frames in relation to any other frame, even when the frame length changes. The downside is that the decoder outputs for certain frame lengths is in fact partial samples. The result is that the output in samples from the codec will vary from frame to frame, potentially making implementation more difficult. Westerlund Expires November 5, 2015 [Page 37] Internet-Draft HOWTO: RTP Payload Formats May 2015 Video codecs have commonly been using 90 kHz, the reason is this is a common denominator between the usually used frame rates such as 24, 25, 30, 50 and 60, and NTSC's odd 29.97 Hz. There does, however, exist at least one exception in the payload format for SMPTE 292M video [RFC3497] that uses a clock rate of 148.5 MHz. The reason here is that the timestamp then identify the exact start sample within a video frame. Timestamp rates below 1000 Hz are not appropriate because it will cause a too low resolution in the RTCP measurements that are expressed in RTP timestamps. This is the main reason that the text RTP payload formats, like T.140 [RFC4103] uses 1000 Hz. 6. Noteworthy Aspects in Payload Format Design This section provides a few examples of payload formats that are worth noting for good or bad design in general or specific details of their design. 6.1. Audio Payloads The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] payload formats are all quite similar. They are all for frame-based audio codecs and use a table of content structure. Each frame has a table of contents entry that indicates the type of the frame and if additional frames are present. This is quite flexible but produces unnecessary overhead if the ADU is of fixed size and if when aggregating multiple ADUs they are commonly of the same type. In that case a solution like that in AMR-WB+ [RFC4352] may be more suitable. The RTP payload format for MIDI [RFC6295] contains some interesting features. MIDI is an audio format sensitive to packet losses, as the loss of a "note off" command will result in a note being stuck in an "on" state. To counter this a recovery journal is defined that provides a summarized state that allows the receiver to recover from packet losses quickly. It also uses RTCP and the reported highest sequence number to be able to prune the state the recovery journal needs to contain. These features appear limited in applicability to media formats that are highly stateful and primarily use symbolic media representations. There exist a security concern with variable bit-rate audio and speech codecs that changes their payload length based on the input data. This can leak information, especially in structured communication like speech recognition prompt service that asks people to enter information verbally. This issue also exists to some degree for discontinuous transmission as that allows the length of phrases Westerlund Expires November 5, 2015 [Page 38] Internet-Draft HOWTO: RTP Payload Formats May 2015 to be determined. The issue is further discussed in Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [RFC6562] which needs to be read by anyone writing an RTP payload format for an audio or speech codec with these properties. 6.2. Video The definition of RTP payload formats for video has seen an evolution from the early ones such as H.261 [RFC4587] towards the latest for VP8 [I-D.ietf-payload-vp8] and H.265/HEVC [I-D.ietf-payload-rtp-h265]. The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord of functionality, some of it such as the interleaving being pretty advanced. The reason for this was to ensure that the majority of applications considered by the ITU-T and MPEG that can be supported by RTP are indeed supported. This has created a payload format that rarely is fully implemented. Despite that, no major issues with interoperability has been reported with one exception namely the offer/answer and parameter signalling, which resulted in a revised specification [RFC6184]. However, complaints about its complexity are common. The RTP payload format for uncompressed video [RFC4175] must be mentioned in this context as it contains a special feature not commonly seen in RTP payload formats. Due to the high bit-rate and thus packet rate of uncompressed video (gigabits rather than megabits per second) the payload format includes a field to extend the RTP sequence number since the normal 16-bit one can wrap in less than a second. [RFC4175] also specifies a registry of different color sub- samplings that can be re-used in other video RTP payload formats. Both, the H.264 and the uncompressed video format enable the implementer to fulfill the goals of application level framing, i.e. each individual RTP Packet's payload can be independently decoded and its content used to create a video frame (or part of) and that irrespective of whether preceding packets has been lost (See Section 4) [RFC2736]. For uncompressed this is straightforward as each pixel is independently represented from others and its location in the video frame known. H.264 is more dependent on the actual implementation, configuration of the video encoder and usage of the RTP payload format. The common challenge with video is that in most cases a single compressed video frame don't fit into a single IP packet. Thus, the compressed representation of a video frame needs to be split over multiple packets. This can be done unintelligently with a basic payload level fragmentation method or more integrated by interfacing Westerlund Expires November 5, 2015 [Page 39] Internet-Draft HOWTO: RTP Payload Formats May 2015 with the encoder's possibilities to create ADUs that are independent and fit the MTU for the RTP packet. The latter is more robust and commonly recommended unless strong packet loss mechanisms are used and sufficient delay budget for the repair exist. Commonly both payload level fragmentation as well as explaining how tailored ADUs can be created are needed in a video payload format. Also the handling of crucial meta data, like H.264 Parameter Sets needs to be considered as decoding is not possible without receiving the used parameter sets. 6.3. Text Only a single format text format has been standardized in the IETF, namely T.140 [RFC4103]. The 3GPP Timed Text format [RFC4396] should be considered to be text, even though in the end was registered as a video format. It was registered in that part of the tree because it deals with decorated text, usable for subtitles and other embellishments of video. However, it has many of the properties that text formats generally have. The RTP payload format for T.140 was designed with high reliability in mind as real-time text commonly is an extremely low bit-rate application. Thus, it recommends the use of RFC 2198 with many generations of redundancy. However, the format failed to provide a text block specific sequence number and relies instead of the RTP one to detect loss. This makes detection of missing text blocks unnecessarily difficult and hinders deployment with other robustness mechanisms that would involve switching the payload type as that may result in erroneous error marking in the T.140 text stream. 6.4. Application The application content type contains at the time of writing two media types that aren't RTP transport robustness tools such as FEC [RFC3009][RFC5109][RFC6015][RFC6682] and RTP retransmission [RFC4588]. The first one is H.224 [RFC4573] which enables far end camera control over RTP. This is not an IETF defined RTP format, only an IETF performed registration. The second one is the RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data [RFC6597] which carries generic key length value (KLV) triplets. These pairs may contain arbitrary binary meta data associated with video transmissions. It has a very basic fragmentation mechanism requiring packet loss free reception not only of the triplet itself but also one packet before and after the sequence of fragmented KLV Westerlund Expires November 5, 2015 [Page 40] Internet-Draft HOWTO: RTP Payload Formats May 2015 triplet to ensure correct reception. Specific KLV triplets themselves may have recommendation on how to handle non-complete ones allowing the use and repair of them. In general the application using such a mechanism must be robust to errors and also use some combination of application level repetition, RTP level transport robustness tools and network level requirements to achieve low levels of packet loss rates and repair of KLV triplets. The application top media type (application/) should be considered to be used when the payload format defined is not clearly matching any of the existing media types (audio, video or text) or are of a generic nature. However, existing limitations in for example SDP, has resulted in that generic mechanisms normally are registered in all media types to be possible to have associated with any existing media types in an RTP session. 7. Important Specification Sections A number of sections in the payload format draft need special consideration. These include the Security and IANA Considerations sections that are required in all drafts. Payload formats are also strongly recommended to have the media format description and congestion control considerations. The included RTP Payload format template (Appendix A) contains draft text for some of these sections. 7.1. Media Format Description The intention of this section is to enable reviewers and other readers to get an overview of the capabilities and major properties of the media format. It should be kept short and concise and is not a complete replacement for reading the media format specification. The actual specification of the RTP payload format generally uses normative references to the codec format specification to define how codec data elements are included in the payload format. This normative reference can be to anything that have sufficient stability for a normative reference. There exist no formal requirement on the codec format specification being publicly available or free to access. However, it significantly helps in the review process if that specification is made available to any reviewer. There exist RTP payload format RFCs for open source project specifications as well as an individual company's proprietary format, and a large variety of standards development organizations or industrial forums. Westerlund Expires November 5, 2015 [Page 41] Internet-Draft HOWTO: RTP Payload Formats May 2015 7.2. Security Considerations All Internet drafts require a Security Considerations section. The security considerations section in an RTP payload format needs to concentrate on the security properties this particular format has. Some payload formats have very few specific issues or properties and can fully fall back on the security considerations for RTP in general and those of the profile being used. Because those documents are always applicable, a reference to these is normally placed first in the security considerations section. There is suggested text in the template below. The security issues of confidentiality, integrity protection, replay protection and source authentication are common issue for all payload formats. These should be solved by mechanisms external to the payload and do not need any special consideration in the payload format except for an reminder on these issues. There exist exceptions, such as payload formats that includes security functionality, like ISMAcrypt [ISMACrypt2]. Reasons for this division is further documented in "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]. For a survey of available mechanisms to meet these goals, review "Options for Securing RTP Sessions" [RFC7201]. This also includes key-exchange mechanisms for the security mechanisms, which can be both integrated or separate. The choice of key-management can have significant impact on the security properties of the RTP based application. Suitable stock text to inform people about this is included in the template. Potential security issues with an RTP payload format and the media encoding that need to be considered if they are applicable: 1. The decoding of the payload format or its media results in substantial non-uniformity, either in output or in complexity to perform the decoding operation. For example a generic non- destructive compression algorithm may provide an output of almost an infinite size for a very limited input, thus consuming memory or storage space out of proportion with what the receiving application expected. Such inputs can cause some sort of disruption, i.e., a denial of service attack on the receiver side by preventing that host from performing usable work. Certain decoding operations may also vary in the amount of processing needed to perform those operations depending on the input. This may also be a security risk if it is possible to raise processing load significantly above nominal simply by designing a malicious input sequence. If such potential attacks exist, this must be made clear in the security considerations section to make Westerlund Expires November 5, 2015 [Page 42] Internet-Draft HOWTO: RTP Payload Formats May 2015 implementers aware of the need to take precautions against such behavior. 2. The inclusion of active content in the media format or its transport. "Active content" means scripts etc. that allow an attacker to perform potentially arbitrary operations on the receiver. Most active contents has limited possibility to access the system or perform operations outside a protected sandbox. RFC 4855 [RFC4855] has a requirement that it be noted in the media types registration if the payload format contains active content or not. If the payload format has active content it is strongly recommended that references to any security model applicable for such content are provided. A boilerplate text for "no active content" is included in the template. This must be changed if the format actually carries active content. 3. Some media formats allow for the carrying of "user data", or types of data which are not known at the time of the specification of the payload format. Such data may be a security risk and should be mentioned. 4. Audio or Speech codecs supporting variable bit-rate based on audio/speech input or having discontinuous transmission support must consider the issues discussed in Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [RFC6562]. Suitable stock text for the security considerations section is provided in the template in the appendix. However, authors do need to actively consider any security issues from the start. Failure to address these issues may block approval and publication. 7.3. Congestion Control RTP and its profiles do discuss congestion control. There is ongoing work in the IETF with both a basic circuit breaker mechanism [I-D.ietf-avtcore-rtp-circuit-breakers] using basic RTCP messages intended to prevent persistent congestion, but also work on more capable congestion avoidance / bit-rate adaptation mechanism in the RMCAT WG. Congestion control is an important issue in any usage in non- dedicated networks. For that reason it is recommended that all RTP payload format documents discuss the possibilities that exist to regulate the bit-rate of the transmissions using the described RTP payload format. Some formats may have limited or step wise regulation of bit-rate. Such limiting factors should be discussed. Westerlund Expires November 5, 2015 [Page 43] Internet-Draft HOWTO: RTP Payload Formats May 2015 7.4. IANA Considerations Since all RTP Payload formats contain a Media Type specification, they also need an IANA Considerations section. The Media Type name must be registered and this is done by requesting that IANA register that media name. When that registration request is written it shall also be requested that the media type is included under the "RTP Payload Format media types" list part of the RTP registry (http://www.iana.org/assignments/rtp-parameters). Parameters for the payload format needs to be included in this registration and can be specified as required or optional ones. The format of these parameter should be such that they can be included in the SDP attribute "a=fmtp" string (See Section 6 [RFC4566]) which is the common mapping. Some parameters, such as "Channel" are normally mapped to the rtpmap attribute instead, see Section 3 of [RFC4855]. In addition to the above request for media type registration, some payload formats may have parameters where in the future new parameter values need to be added. In these cases a registry for that parameter must be created. This is done by defining the registry in the IANA Considerations section. BCP 26 [RFC5226] provides guidelines to specifying such registries. Care should be taken when defining the policy for new registrations. Before specifying a new registry it is worth checking the existing ones in the IANA "MIME Media Type Sub-Parameter Registries" list. For example video formats needing a media parameter expressing color sub-sampling may be able to reuse those defined for video/raw [RFC4175]. 8. Authoring Tools This section provides information about some tools that may be used. Don't feel pressured to follow these recommendations. There exist a number of alternatives, including the ones listed at http://tools.ietf.org/. But these suggestions are worth checking out before deciding that the field is greener somewhere else. 8.1. Editing Tools There are many choices when it comes to tools to choose for authoring Internet drafts. However in the end they need to be able to produce a draft that conforms to the Internet Draft requirements. If you don't have any previous experience with authoring Internet drafts XML2RFC does have some advantages. It helps by create a lot of the necessary boiler plate in accordance with the latest rules, thus reducing the effort. It also speeds up publication after approval as Westerlund Expires November 5, 2015 [Page 44] Internet-Draft HOWTO: RTP Payload Formats May 2015 the RFC-editor can use the source XML document to produce the RFC more quickly. Another common choice is to use Microsoft Word and a suitable template, see [RFC5385] to produce the draft and print that to file using the generic text printer. It has some advantages when it comes to spell checking and change bars. However, Word may also produce some problems, like changing formatting, and inconsistent results between what one sees in the editor and in the generated text document, at least according to the authors' personal experience. 8.2. Verification Tools There are a few tools that are very good to know about when writing a draft. These help check and verify parts of one's work. These tools can be found at http://tools.ietf.org. o ID Nits checker. It checks that the boiler plate and some other things that are easily verifiable by machine are okay in your draft. Always use it before submitting a draft to avoid direct refusal in the submission step. o ABNF Parser and verification. Checks that your ABNF parses correctly and warns about loose ends, like undefined symbols. However the actual content can only be verified by humans knowing what it intends to describe. o RFC diff. A diff tool that is optimized for drafts and RFCs. For example it does not point out that the footer and header have moved in relation to the text on every page. 9. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 10. Security Considerations As this is an informational document about writing drafts that are intended to become RFCs there are no direct security considerations. However, the document does discuss the writing of security considerations sections and what should be particularly considered when specifying RTP payload formats. Westerlund Expires November 5, 2015 [Page 45] Internet-Draft HOWTO: RTP Payload Formats May 2015 11. Contributors The author would like to thank Tom Taylor for the editing pass of the whole document and contributing text regarding proprietary RTP payload formats. Thanks also goes to Thomas Schierl who contributed text regarding Media Scalability features in payload formats (Section 5.1.5). Stephan Wenger has contributed text on the need to understand the media coding (Section 3.1) as well as joint development of payload format with the media coding (Section 4.4). 12. Acknowledgements The author would like to thank the individuals who have provided input to this document. These individuals include Richard Barnes, Ali C. Begen, Bo Burman, Ross Finlayson, Russ Housley, John Lazzaro, Jonathan Lennox, Colin Perkins, Tom Taylor, Stephan Wenger, and Qin Wu. 13. RFC-Editor Note RFC-Editor, please correct the BCP references in the below section, i.e. [BCP9], [BCP25], [BCP78], and [BCP79]. Then please remove this section prior to publication as RFC. 14. Informative References [BCP25] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, October 2004. [BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008. [BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009. Housley, R., Westerlund Expires November 5, 2015 [Page 46] Internet-Draft HOWTO: RTP Payload Formats May 2015 Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011. Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, December 2013. [BLOAT] Nichols, K. and V. Jacobson, "Controlling Queue Delay", May 2012, . ACM Networks Vol. 10 No. 5 - May 2012 [CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet", June 2003. [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft-ietf-avtcore- multiplex-guidelines-03 (work in progress), October 2014. [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-10 (work in progress), March 2015. [I-D.ietf-payload-rtp-h265] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding", draft-ietf-payload-rtp-h265-09 (work in progress), April 2015. [I-D.ietf-payload-rtp-opus] Spittka, J., Vos, K., and J. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", draft-ietf-payload- rtp-opus-11 (work in progress), April 2015. [I-D.ietf-payload-vp8] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", draft-ietf- payload-vp8-15 (work in progress), March 2015. [ID-GUIDE] Housley, R., "Guidelines to Authors of Internet-Drafts", January 2014, . Westerlund Expires November 5, 2015 [Page 47] Internet-Draft HOWTO: RTP Payload Formats May 2015 [ISMACrypt2] "ISMA Encryption and Authentication, Version 2.0 release version", November 2007, . [MACOSFILETYPES] Apple Knowledge Base Article 55381, , "Mac OS: File Type and Creator Codes, and File Formats", 1993. [RFC-ED] "RFC Editorial Guidelines and Procedures", July 2008, . [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, RFC 2360, June 1998. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Westerlund Expires November 5, 2015 [Page 48] Internet-Draft HOWTO: RTP Payload Formats May 2015 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999. [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999. [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time Transport Protocol Management Information Base", RFC 2959, October 2000. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of parityfec MIME types", RFC 3009, November 2000. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video", RFC 3497, March 2003. [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003. Westerlund Expires November 5, 2015 [Page 49] Internet-Draft HOWTO: RTP Payload Formats May 2015 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003. [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, February 2005. [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, November 2005. [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for Uncompressed Video", RFC 4175, September 2005. [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, "RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006. Westerlund Expires November 5, 2015 [Page 50] Internet-Draft HOWTO: RTP Payload Formats May 2015 [RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text", RFC 4396, February 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, July 2006. [RFC4573] Even, R. and A. Lochbaum, "MIME Type Registration for RTP Payload Format for H.224", RFC 4573, July 2006. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007. Westerlund Expires November 5, 2015 [Page 51] Internet-Draft HOWTO: RTP Payload Formats May 2015 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", RFC 5385, February 2010. [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, March 2009. [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009. [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, October 2010. [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010. [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011. [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, May 2011. [RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for MIDI", RFC 6295, June 2011. Westerlund Expires November 5, 2015 [Page 52] Internet-Draft HOWTO: RTP Payload Formats May 2015 [RFC6354] Xie, Q., "Forward-Shifted RTP Redundancy Payload Support", RFC 6354, August 2011. [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011. [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011. [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012. [RFC6597] Downs, J. and J. Arbeiter, "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data", RFC 6597, April 2012. [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012. [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload Format for Raptor Forward Error Correction (FEC)", RFC 6682, August 2012. [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for Application to Violators of IETF IPR Policy", RFC 6701, August 2012. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. [RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple Clock Rates in an RTP Session", RFC 7160, April 2014. [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, March 2014. [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, April 2014. [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, April 2014. Westerlund Expires November 5, 2015 [Page 53] Internet-Draft HOWTO: RTP Payload Formats May 2015 [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, June 2014. [TAO] "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", November 2012, . [TRACKER] "Internet Engineering Task Force Data Tracker", January 2014, . Appendix A. RTP Payload Format Template This section contains a template for writing an RTP payload format in form as a Internet draft. Text within [...] are instructions and must be removed. Some text proposals that are included are conditional. "..." is used to indicate where further text should be written. A.1. Title [The title shall be descriptive but as compact as possible. RTP is allowed and recommended abbreviation in the title] RTP Payload format for ... A.2. Front page boilerplate Status of this Memo [Insert the IPR notice and copyright boiler plate from BCP 78 and 79 that applies to this draft.] [Insert the current Internet Draft document explanation. At the time of publishing it was:] Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Westerlund Expires November 5, 2015 [Page 54] Internet-Draft HOWTO: RTP Payload Formats May 2015 A.3. Abstract [A payload format abstract should mention the capabilities of the format, for which media format is used, and a little about that codec formats capabilities. Any abbreviation used in the payload format must be spelled out here except the very well known like RTP. No references are allowed, no use of RFC 2119 language either.] A.4. Table of Content [All drafts over 15 pages in length must have an Table of Content.] A.5. Introduction [The introduction should provide a background and overview of the payload formats capabilities. No normative language in this section, i.e., no MUST, SHOULDs etc.] A.6. Conventions, Definitions and Acronyms [Define conventions, definitions and acronyms used in the document in this section. The most common definition used in RTP Payload formats are the RFC 2119 definitions of the upper case normative words, e.g. MUST and SHOULD.] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. A.7. Media Format Description [The intention of this section is to enable reviewers and persons to get an overview of the capabilities and major properties of the media format. It should be kept short and concise and is not a complete replacement for reading the media format specification.] A.8. Payload format [Overview of payload structure] A.8.1. RTP Header Usage [RTP header usage needs to be defined. The fields that absolutely need to be defined are timestamp and marker bit. Further field may be specified if used. All the rest should be left to their RTP specification definition] Westerlund Expires November 5, 2015 [Page 55] Internet-Draft HOWTO: RTP Payload Formats May 2015 The remaining RTP header fields are used as specified in RTP [RFC 3550]. A.8.2. Payload Header [Define how the payload header, if it exists, is structured and used.] A.8.3. Payload Data [The payload data, i.e., what the media codec has produced. Commonly done through reference to media codec specification which defines how the data is structured. Rules for padding may need to be defined to bring data to octet alignment.] A.9. Payload Examples [One or more examples are good to help ease the understanding of the RTP payload format.] A.10. Congestion Control Considerations [This section is to describe the possibility to vary the bit-rate as a response to congestion. Below is also a proposal for an initial text that reference RTP and profiles definition of congestion control.] Congestion control for RTP SHALL be used in accordance with RFC 3550 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 [RFC3551]. An additional requirement if best-effort service is being used is: users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an update to RTP [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams. The circuit breakers is to be implemented and followed. A.11. Payload Format Parameters This RTP payload format is identified using the ... media type which is registered in accordance with RFC 4855 [RFC4855] and using the template of RFC 6838 [RFC6838]. A.11.1. Media Type Definition [Here the media type registration template from RFC 6838 is placed and filled out. This template is provided with some common RTP boilerplate.] Westerlund Expires November 5, 2015 [Page 56] Internet-Draft HOWTO: RTP Payload Formats May 2015 Type name: Subtype name: Required parameters: Optional parameters: Encoding considerations: This media type is framed and binary, see section 4.8 in RFC6838 [RFC6838]. Security considerations: Please see security consideration in RFCXXXX Interoperability considerations: Published specification: Applications that use this media type: Additional information: Deprecated alias names for this type: [Only applicable if there exists widely deployed alias for this media type; see Section 4.2.9 of [RFC6838]. Remove or use N/A otherwise.] Magic number(s): [Only applicable for media types that has file format specification. Remove or use N/A otherwise.] File extension(s): [Only applicable for media types that has file format specification. Remove or use N/A otherwise.] Macintosh file type code(s): [Only applicable for media types that has file format specification. Remove or use N/A otherwise.] Person & email address to contact for further information: Westerlund Expires November 5, 2015 [Page 57] Internet-Draft HOWTO: RTP Payload Formats May 2015 Intended usage: [One of COMMON, LIMITED USE or OBSOLETE.] Restrictions on usage: [The below text is for media types that is only defined for RTP payload formats. There exist certain media types that are defined both as RTP payload formats and file transfer. The rules for such types are documented in RFC 4855 [RFC4855].] This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time. Author: Change controller: IETF Payload working group delegated from the IESG. Provisional registration? (standards tree only): No (Any other information that the author deems interesting may be added below this line.) [From RFC 6838: Some discussion of Macintosh file type codes and their purpose can be found in [MACOSFILETYPES]. N/A", written exactly that way, can be used in any field if desired to emphasize the fact that it does not apply or that the question was not omitted by accident. Do not use 'none' or other words that could be mistaken for a response. Limited-use media types should also note in the applications list whether or not that list is exhaustive.] A.11.2. Mapping to SDP The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855 [RFC4855]. Westerlund Expires November 5, 2015 [Page 58] Internet-Draft HOWTO: RTP Payload Formats May 2015 [More specific rules only need to be included if some parameter does not match these rules.] A.11.2.1. Offer/Answer Considerations [Here write your offer/answer consideration section, please see Section 3.4.2.1 for help.] A.11.2.2. Declarative SDP Considerations [Here write your considerations for declarative SDP, please see Section 3.4.2.2 for help.] A.12. IANA Considerations This memo requests that IANA registers [insert media type name here] as specified in Appendix A.11.1. The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" (http://www.iana.org/assignments/rtp-parameters). [See Section 7.4 and consider if any of the parameter needs a registered name space.] A.13. Security Considerations [See Section 7.2] RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this security consideration section discusses the security impacting properties of the payload format itself. This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a Westerlund Expires November 5, 2015 [Page 59] Internet-Draft HOWTO: RTP Payload Formats May 2015 denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content. [The previous paragraph may need editing due to the format breaking either of the statements. Fill in here any further potential security threats created by the payload format itself.] A.14. RFC Editor Considerations Note to RFC Editor: This section may be removed after carrying out all the instructions of this section. RFCXXXX is to be replaced by the RFC number this specification receives when published. A.15. References [References must be classified as either normative or informative and added to the relevant section. References should use descriptive reference tags.] A.15.1. Normative References [Normative references are those that are required to be used to correctly implement the payload format.] A.15.2. Informative References [All other references.] A.16. Author Addresses [All Authors need to include their Name and email addresses as a minimal. Commonly also surface mail and possibly phone numbers are included.] [The Template Ends Here!] Author's Address Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Westerlund Expires November 5, 2015 [Page 60] ./draft-ietf-pce-pcep-service-aware-13.txt0000664000764400076440000017110012770720355017615 0ustar iustyiusty PCE Working Group D. Dhody Internet-Draft Q. Wu Intended status: Standards Track Huawei Expires: March 26, 2017 V. Manral Ionos Network Z. Ali Cisco Systems K. Kumaki KDDI Corporation September 22, 2016 Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). draft-ietf-pce-pcep-service-aware-13 Abstract 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 and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS respectively. 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. This document describes the extension to PCEP to carry latency, delay variation, packet loss and link bandwidth utilization as constraints for end to end path computation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Dhody, et al. Expires March 26, 2017 [Page 1] Internet-Draft SERVICE-AWARE September 2016 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 26, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Extensions to METRIC Object . . . . . . . . . . . . . . . 5 3.1.1. Path Delay Metric . . . . . . . . . . . . . . . . . . 6 3.1.1.1. Path Delay Metric Value . . . . . . . . . . . . . 7 3.1.2. Path Delay Variation Metric . . . . . . . . . . . . . 7 3.1.2.1. Path Delay Variation Metric Value . . . . . . . . 8 3.1.3. Path Loss Metric . . . . . . . . . . . . . . . . . . 8 3.1.3.1. Path Loss Metric Value . . . . . . . . . . . . . 9 3.1.4. Non-Understanding / Non-Support of Service Aware Path Computation . . . . . . . . . . . . . . . . . . . . . 9 3.1.5. Mode of Operation . . . . . . . . . . . . . . . . . . 10 3.1.5.1. Examples . . . . . . . . . . . . . . . . . . . . 10 3.1.6. Point-to-Multipoint (P2MP) . . . . . . . . . . . . . 11 3.1.6.1. P2MP Path Delay Metric . . . . . . . . . . . . . 11 3.1.6.2. P2MP Path Delay Variation Metric . . . . . . . . 11 3.1.6.3. P2MP Path Loss Metric . . . . . . . . . . . . . . 12 3.2. Bandwidth Utilization . . . . . . . . . . . . . . . . . . 12 3.2.1. Link Bandwidth Utilization (LBU) . . . . . . . . . . 12 3.2.2. Link Reserved Bandwidth Utilization (LRBU) . . . . . 12 3.2.3. Bandwidth Utilization (BU) Object . . . . . . . . . . 13 3.2.3.1. Elements of Procedure . . . . . . . . . . . . . . 14 3.3. Objective Functions . . . . . . . . . . . . . . . . . . . 15 4. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . . . 16 Dhody, et al. Expires March 26, 2017 [Page 2] Internet-Draft SERVICE-AWARE September 2016 5. PCEP Message Extension . . . . . . . . . . . . . . . . . . . 16 5.1. The PCReq message . . . . . . . . . . . . . . . . . . . . 17 5.2. The PCRep message . . . . . . . . . . . . . . . . . . . . 17 5.3. The PCRpt message . . . . . . . . . . . . . . . . . . . . 18 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 19 6.1. Inter-domain Path Computation . . . . . . . . . . . . . . 19 6.1.1. Inter-AS Links . . . . . . . . . . . . . . . . . . . 19 6.1.2. Inter-Layer Path Computation . . . . . . . . . . . . 19 6.2. Reoptimizing Paths . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.1. METRIC types . . . . . . . . . . . . . . . . . . . . . . 20 7.2. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 21 7.3. BU Object . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. OF Codes . . . . . . . . . . . . . . . . . . . . . . . . 22 7.5. New Error-Values . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Manageability Considerations . . . . . . . . . . . . . . . . 23 9.1. Control of Function and Policy . . . . . . . . . . . . . 23 9.2. Information and Data Models . . . . . . . . . . . . . . . 23 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 23 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 23 9.6. Impact On Network Operations . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. PCEP Requirements . . . . . . . . . . . . . . . . . 28 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Real time network performance information is becoming critical in the path computation in some networks. Mechanisms to measure latency, delay variation, and packet loss in an MPLS network are described in [RFC6374]. It is important that latency, delay variation, and packet loss are considered during the path selection process, even before the LSP is set up. Link bandwidth utilization based on real time traffic along the path is also becoming critical during path computation in some networks. Thus it is important that the link bandwidth utilization is factored in during the path computation. The Traffic Engineering Database (TED) is populated with network performance information like link latency, delay variation, packet loss, as well as parameters related to bandwidth (residual bandwidth, Dhody, et al. Expires March 26, 2017 [Page 3] Internet-Draft SERVICE-AWARE September 2016 available bandwidth and utilized bandwidth) via TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810] or via a management system. [RFC7823] describes how a Path Computation Element (PCE) [RFC4655], can use that information for path selection for explicitly routed LSPs. A Path Computation Client (PCC) can request a PCE to provide a path meeting end to end network performance criteria. This document extends Path Computation Element Communication Protocol (PCEP) [RFC5440] to handle network performance constraints which include any combination of latency, delay variation, packet loss and bandwidth utilization constraints. [RFC7471] and [RFC7810] describe various considerations regarding - o Announcement thresholds and filters o Announcement suppression o Announcement periodicity and network stability The first two provide configurable mechanisms to bound the number of re-advertisements in IGP. The third provides a way to throttle announcements. Section 1.2 of [RFC7823] also describes the oscillation and stability considerations while advertising and considering service aware information. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology The following terminology is used in this document. IGP: Interior Gateway Protocol; Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS). IS-IS: Intermediate System to Intermediate System LBU: Link Bandwidth Utilization (See Section 3.2.1.) LRBU: Link Reserved Bandwidth Utilization (See Section 3.2.2.) MPLP: Minimum Packet Loss Path (See Section 3.3.) Dhody, et al. Expires March 26, 2017 [Page 4] Internet-Draft SERVICE-AWARE September 2016 MRUP: Maximum Reserved Under-Utilized Path (See Section 3.3.) MUP: Maximum Under-Utilized Path (See Section 3.3.) OF: Objective Function; A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization) or for the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization, etc). (See [RFC5541].) OSPF: Open Shortest Path First PCC: Path Computation Client; any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element; An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. RSVP: Resource Reservation Protocol TE: Traffic Engineering TED: Traffic Engineering Database 3. PCEP Extensions This section defines PCEP extensions (see [RFC5440]) for requirements outlined in Appendix A. The proposed solution is used to support network performance and service aware path computation. 3.1. Extensions to METRIC Object The METRIC object is defined in section 7.8 of [RFC5440], comprising metric-value, metric-type (T field) and a flags field comprising a number of bit-flags (B bit, P bit). This document defines the following types for the METRIC object. o T=TBD1: Path Delay metric (Section 3.1.1) o T=TBD2: Path Delay Variation metric (Section 3.1.2) o T=TBD3: Path Loss metric (Section 3.1.3) o T=TBD8: P2MP Path Delay metric (Section 3.1.6.1) o T=TBD9: P2MP Path Delay Variation metric (Section 3.1.6.2) Dhody, et al. Expires March 26, 2017 [Page 5] Internet-Draft SERVICE-AWARE September 2016 o T=TBD10: P2MP Path Loss metric (Section 3.1.6.3) The following terminology is used and expanded along the way. o A network comprises of a set of N links {Li, (i=1...N)}. o A path P of a point to point (P2P) LSP is a list of K links {Lpi,(i=1...K)}. 3.1.1. Path Delay Metric The link delay metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Link Delay". The path delay metric type of the METRIC object in PCEP represents the sum of the link delay metric of all links along a P2P path. Specifically, extending on the above mentioned terminology: o A link delay metric of link L is denoted D(L). o A path delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}. This is as per the sum of means composition function (section 4.2.5 of [RFC6049]). The section 1.2 of [RFC7823] describes oscillation and stability considerations, and section 2.1 of [RFC7823] describes the calculation of end to end path delay metric. Further section 4.2.9 of [RFC6049] states when this composition function may fail. Metric Type T=TBD1: Path Delay metric A PCC MAY use the path delay metric in a PCReq message to request a path meeting the end to end latency requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the path delay metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path delay metric must be less than or equal to the value specified in the metric-value field. A PCC can also use this metric to ask PCE to optimize the path delay during path computation. In this case, the B bit MUST be cleared. A PCE MAY use the path delay metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed path delay metric to the PCC. Dhody, et al. Expires March 26, 2017 [Page 6] Internet-Draft SERVICE-AWARE September 2016 3.1.1.1. Path Delay Metric Value [RFC7471] and [RFC7810] define the "Unidirectional Link Delay Sub- TLV" to advertise the link delay in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.1985]). Consequently, the encoding for the path delay metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24 bit integer to 32 bit IEEE floating point could introduce some loss of precision. 3.1.2. Path Delay Variation Metric The link delay variation metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Delay Variation". The path delay variation metric type of the METRIC object in PCEP encodes the sum of the link delay variation metric of all links along the path. Specifically, extending on the above mentioned terminology: o A delay variation of link L is denoted DV(L) (average delay variation for link L). o A path delay variation metric for the P2P path P = Sum {DV(Lpi), (i=1...K)}. The section 1.2 of [RFC7823] describes oscillation and stability considerations, and section 2.1 of [RFC7823] describes the calculation of end to end path delay variation metric. Further section 4.2.9 of [RFC6049] states when this composition function may fail. Note that the IGP advertisement for link attributes includes the average delay variation over a period of time. An implementation, therefore, MAY use the sum of the average delay variation of links along a path to derive the delay variation of the path. An end-to- end bound on delay variation is typically used as constraint in the path computation. An implementation MAY also use some enhanced composition function for computing the delay variation of a path with better accuracy. Metric Type T=TBD2: Path Delay Variation metric A PCC MAY use the path delay variation metric in a PCReq message to request a path meeting the path delay variation requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the path delay variation metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path delay variation Dhody, et al. Expires March 26, 2017 [Page 7] Internet-Draft SERVICE-AWARE September 2016 must be less than or equal to the value specified in the metric-value field. A PCC can also use this metric to ask the PCE to optimize the path delay variation during path computation. In this case, the B flag MUST be cleared. A PCE MAY use the path delay variation metric in PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end to end path delay variation metric to the PCC. 3.1.2.1. Path Delay Variation Metric Value [RFC7471] and [RFC7810] define "Unidirectional Delay Variation Sub- TLV" to advertise the link delay variation in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.1985]). Consequently, the encoding for the path delay variation metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24 bit integer to 32 bit IEEE floating point could introduce some loss of precision. 3.1.3. Path Loss Metric [RFC7471] and [RFC7810] define "Unidirectional Link Loss". The path loss (as a packet percentage) metric type of the METRIC object in PCEP encodes a function of the unidirectional loss metrics of all links along a P2P path. The end to end packet loss for the path is represented by this metric. Specifically, extending on the above mentioned terminology: o The percentage link loss of link L is denoted PL(L). o The fractional link loss of link L is denoted FL(L) = PL(L)/100. o The percentage path loss metric for the P2P path P = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100 for a path P with links Lp1 to LpK. This is as per the composition function described in section 5.1.5 of [RFC6049]. Metric Type T=TBD3: Path Loss metric A PCC MAY use the path loss metric in a PCReq message to request a path meeting the end to end packet loss requirement. In this case, Dhody, et al. Expires March 26, 2017 [Page 8] Internet-Draft SERVICE-AWARE September 2016 the B bit MUST be set to suggest a bound (a maximum) for the path loss metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path loss metric must be less than or equal to the value specified in the metric-value field. A PCC can also use this metric to ask the PCE to optimize the path loss during path computation. In this case, the B flag MUST be cleared. A PCE MAY use the path loss metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end to end path loss metric to the PCC. 3.1.3.1. Path Loss Metric Value [RFC7471] and [RFC7810] define "Unidirectional Link Loss Sub-TLV" to advertise the link loss in percentage in a 24-bit field. [RFC5440] defines the METRIC object with 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.1985]). Consequently, the encoding for the path loss metric value is quantified as a percentage and encoded in IEEE floating point format. 3.1.4. Non-Understanding / Non-Support of Service Aware Path Computation If a PCE receives a PCReq message containing a METRIC object with a type defined in this document, and the PCE does not understand or support that metric type, and the P bit is clear in the METRIC object header then the PCE SHOULD simply ignore the METRIC object as per the processing specified in [RFC5440]. If the PCE does not understand the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter) [RFC5440][RFC5441]. If the PCE understands but does not support the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) with Error-value = TBD11 (Unsupported network performance constraint). The path computation request MUST then be cancelled. If the PCE understands the new METRIC type, but the local policy has been configured on the PCE to not allow network performance constraint, and the P bit is set in the METRIC object header, then Dhody, et al. Expires March 26, 2017 [Page 9] Internet-Draft SERVICE-AWARE September 2016 the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 5 (Policy violation) with Error-value = TBD12 (Not allowed network performance constraint). The path computation request MUST then be cancelled. 3.1.5. Mode of Operation As explained in [RFC5440], the METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert one or more METRIC objects: o To indicate the metric that MUST be optimized by the path computation algorithm (path delay, path delay variation or path loss). o To indicate a bound on the METRIC (path delay, path delay variation or path loss) that MUST NOT be exceeded for the path to be considered as acceptable by the PCC. In a PCRep message, the PCE MAY insert the METRIC object with an Explicit Route Object (ERO) so as to provide the METRIC (path delay, path delay variation or path loss) for the computed path. The PCE MAY also insert the METRIC object with a NO-PATH object to indicate that the metric constraint could not be satisfied. The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document. All the rules of processing the METRIC object as explained in [RFC5440] are applicable to the new metric types as well. 3.1.5.1. Examples If a PCC sends a path computation request to a PCE where the metric to optimize is the path delay and the path loss must not exceed the value of M, then two METRIC objects are inserted in the PCReq message: o First METRIC object with B=0, T=TBD1, C=1, metric-value=0x0000 o Second METRIC object with B=1, T=TBD3, metric-value=M As per [RFC5440], if a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, then the PCE inserts one METRIC object with B=0, T=TBD1, metric-value= computed path delay. Additionally, the PCE MAY Dhody, et al. Expires March 26, 2017 [Page 10] Internet-Draft SERVICE-AWARE September 2016 insert a second METRIC object with B=1, T=TBD3, metric-value=computed path loss. 3.1.6. Point-to-Multipoint (P2MP) This section defines the following types for the METRIC object to be used for the P2MP TE LSPs. 3.1.6.1. P2MP Path Delay Metric The P2MP path delay metric type of the METRIC object in PCEP encodes the path delay metric for the destination that observes the worst delay metric among all destinations of the P2MP tree. Specifically, extending on the above mentioned terminology: o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}. o The P2P path delay metric of the path to destination Dest_j is denoted by PDM(Dest_j). o The P2MP path delay metric for the P2MP tree T = Maximum {PDM(Dest_j), (j=1...M)}. The value for the P2MP path delay metric type (T) = TBD8. 3.1.6.2. P2MP Path Delay Variation Metric The P2MP path delay variation metric type of the METRIC object in PCEP encodes the path delay variation metric for the destination that observes the worst delay variation metric among all destinations of the P2MP tree. Specifically, extending on the above mentioned terminology: o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}. o The P2P path delay variation metric of the path to the destination Dest_j is denoted by PDVM(Dest_j). o The P2MP path delay variation metric for the P2MP tree T = Maximum {PDVM(Dest_j), (j=1...M)}. The value for the P2MP path delay variation metric type (T) = TBD9. Dhody, et al. Expires March 26, 2017 [Page 11] Internet-Draft SERVICE-AWARE September 2016 3.1.6.3. P2MP Path Loss Metric The P2MP path loss metric type of the METRIC object in PCEP encodes the path packet loss metric for the destination that observes the worst packet loss metric among all destinations of the P2MP tree. Specifically, extending on the above mentioned terminology: o A P2MP tree T comprises of a set of M destinations {Dest_j, (j=1...M)}. o The P2P path loss metric of the path to destination Dest_j is denoted by PLM(Dest_j). o The P2MP path loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}. The value for the P2MP path loss metric type (T) = TBD10. 3.2. Bandwidth Utilization 3.2.1. Link Bandwidth Utilization (LBU) The Link Bandwidth Utilization (LBU) on a link, forwarding adjacency, or bundled link is populated in the TED ("Unidirectional Utilized Bandwidth" in [RFC7471] and [RFC7810]). For a link or forwarding adjacency, the bandwidth utilization represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, the bandwidth utilization is defined to be the sum of the component link bandwidth utilization. This includes traffic for both RSVP-TE and non-RSVP-TE label switched path packets. The LBU in percentage is described as the (utilized bandwidth / maximum bandwidth) * 100. Where "maximum bandwidth" is defined in [RFC3630] and [RFC5305] and "utilized bandwidth" in [RFC7471] and [RFC7810]. 3.2.2. Link Reserved Bandwidth Utilization (LRBU) The Link Reserved Bandwidth Utilization (LRBU) on a link, forwarding adjacency, or bundled link can be calculated from the TED. The utilized bandwidth includes traffic for both RSVP-TE and non-RSVP-TE LSPs, the reserved bandwidth utilization considers only the RSVP-TE LSPs. The reserved bandwidth utilization can be calculated by using the residual bandwidth, the available bandwidth and utilized bandwidth described in [RFC7471] and [RFC7810]. The actual bandwidth by non- Dhody, et al. Expires March 26, 2017 [Page 12] Internet-Draft SERVICE-AWARE September 2016 RSVP-TE traffic can be calculated by subtracting the available bandwidth from the residual bandwidth ([RFC7471] and [RFC7810]). Which is further deducted from utilized bandwidth to get the reserved bandwidth utilization. Thus, reserved bandwidth utilization = utilized bandwidth - (residual bandwidth - available bandwidth) The LRBU in percentage is described as the (reserved bandwidth utilization / maximum reservable bandwidth) * 100. Where the "maximum reservable bandwidth" is defined in [RFC3630] and [RFC5305]. The "utilized bandwidth", "residual bandwidth", and "available bandwidth" are defined in [RFC7471] and [RFC7810]. 3.2.3. Bandwidth Utilization (BU) Object The BU object is used to indicate the upper limit of the acceptable link bandwidth utilization percentage. The BU object MAY be carried within the PCReq message and PCRep messages. BU Object-Class is TBD4. BU Object-Type is 1. The format of the BU object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Utilization | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BU Object Body Format Reserved (24 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Type (8 bits): Represents the bandwidth utilization type. Two values are currently defined. * Type 1 is Link Bandwidth Utilization (LBU) Dhody, et al. Expires March 26, 2017 [Page 13] Internet-Draft SERVICE-AWARE September 2016 * Type 2 is Link Reserved Bandwidth Utilization (LRBU) Bandwidth Utilization (32 bits): Represents the bandwidth utilization quantified as a percentage (as described in Section 3.2.1 and Section 3.2.2) and encoded in IEEE floating point format (see [IEEE.754.1985]). The BU object body has a fixed length of 8 bytes. 3.2.3.1. Elements of Procedure A PCC that wants the PCE to factor in the bandwidth utilization during path computation includes a BU object in the PCReq message. A PCE that supports this object MUST ensure that no link on the computed path has the LBU or LRBU percentage exceeding the given value. A PCReq or PCRep message MAY contain multiple BU objects so long as each is for a different bandwidth utilization type. If a message contains more than one BU object with the same bandwidth utilization type, the first MUST be processed by the receiver and subsequent instances MUST be ignored. If the BU object is unknown/unsupported, the PCE is expected to follow procedures defined in [RFC5440]. That is, if the P bit is set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request will be discarded. If the P bit is cleared, the PCE is free to ignore the object. If the PCE understands but does not support path computation requests using the BU object, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 4 (Not supported object) with Error-value = TBD11 (Unsupported network performance constraint) and the related path computation request MUST be discarded. If the PCE understands the BU object but the local policy has been configured on the PCE to not allow network performance constraint, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 5 (Policy Violation) with Error-value = TBD12 (Not allowed network performance constraint). The path computation request MUST then be cancelled. If path computation is unsuccessful, then a PCE MAY insert a BU object (along with a NO-PATH object) into a PCRep message to indicate the constraints that could not be satisfied. Dhody, et al. Expires March 26, 2017 [Page 14] Internet-Draft SERVICE-AWARE September 2016 Usage of the BU object for P2MP LSPs is outside the scope of this document. 3.3. Objective Functions [RFC5541] defines a mechanism to specify an objective function that is used by a PCE when it computes a path. The new metric types for path delay and path delay variation can continue to use the existing objective function - Minimum Cost Path (MCP) [RFC5541]. For path loss, the following new OF is defined. o A network comprises a set of N links {Li, (i=1...N)}. o A path P is a list of K links {Lpi,(i=1...K)}. o The percentage link loss of link L is denoted PL(L). o The fractional link loss of link L is denoted FL(L) = PL(L) / 100. o The percentage path loss of a path P is denoted PL(P), where PL(P) = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100. Objective Function Code: TBD5 Name: Minimum Packet Loss Path (MPLP) Description: Find a path P such that PL(P) is minimized. Two additional objective functions -- namely, MUP (the Maximum Under- Utilized Path) and MRUP (the Maximum Reserved Under-Utilized Path) are needed to optimize bandwidth utilization. These two new objective function codes are defined below. These objective functions are formulated using the following additional terminology: o The bandwidth utilization on link L is denoted u(L). o The reserved bandwidth utilization on link L is denoted ru(L). o The maximum bandwidth on link L is denoted M(L). o The maximum reservable bandwidth on link L is denoted R(L). The description of the two new objective functions is as follows. Dhody, et al. Expires March 26, 2017 [Page 15] Internet-Draft SERVICE-AWARE September 2016 Objective Function Code: TBD6 Name: Maximum Under-Utilized Path (MUP) Description: Find a path P such that (Min {(M(Lpi)- u(Lpi)) / M(Lpi), i=1...K } ) is maximized. Objective Function Code: TBD7 Name: Maximum Reserved Under-Utilized Path (MRUP) Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) / R(Lpi), i=1...K } ) is maximized. These new objective functions are used to optimize paths based on the bandwidth utilization as the optimization criteria. If the objective functions defined in this document are unknown/ unsupported by a PCE, then the procedure as defined in section 3.1.1 of [RFC5541] is followed. 4. Stateful PCE and PCE Initiated LSPs [STATEFUL-PCE] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP and maintaining of these LSPs at the stateful PCE. It further distinguishes between an active and a passive stateful PCE. A passive stateful PCE uses LSP state information learned from PCCs to optimize path computations but does not actively update LSP state. In contrast, an active stateful PCE utilizes the LSP delegation mechanism to update LSP parameters in those PCCs that delegated control over their LSPs to the PCE. [PCE-INITIATED] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. The document defines the PCInitiate message that is used by a PCE to request a PCC to set up a new LSP. The new metric type and objective functions defined in this document can also be used with the stateful PCE extensions. The format of PCEP messages described in [STATEFUL-PCE] and [PCE-INITIATED] uses (which is extended in Section 5.2) for the purpose of including the service aware parameters. The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Section 5.1 and Section 5.2 to enable the use of service aware parameters during passive stateful operations. 5. PCEP Message Extension Message formats in this document are expressed using Reduced BNF as used in [RFC5440] and defined in [RFC5511]. Dhody, et al. Expires March 26, 2017 [Page 16] Internet-Draft SERVICE-AWARE September 2016 5.1. The PCReq message The extensions to PCReq message are - o new metric types using existing METRIC object o a new optional BU object o new objective functions using existing OF object ([RFC5541]) The format of the PCReq message (with [RFC5541] and [STATEFUL-PCE] as a base) is updated as follows: ::= [] where: ::= [] [] [] ::= [] ::= [] [] [] [] [] [] [[]] [] [] and where: ::=[] ::= [] 5.2. The PCRep message The extensions to PCRep message are - o new metric types using existing METRIC object o a new optional BU object (during unsuccessful path computation, to indicate the bandwidth utilization as a reason for failure) Dhody, et al. Expires March 26, 2017 [Page 17] Internet-Draft SERVICE-AWARE September 2016 o new objective functions using existing OF object ([RFC5541]) The format of the PCRep message (with [RFC5541] and [STATEFUL-PCE] as a base) is updated as follows: ::= [] where: ::= [] [] [] ::= [] ::= [] [] [] [] ::= [] ::= and where: ::= [] [] [] [] [] [] ::=[] ::= [] 5.3. The PCRpt message A Path Computation LSP State Report message (also referred to as PCRpt message) is a PCEP message sent by a PCC to a PCE to report the current state or delegate control of an LSP. The BU object in a PCRpt message specifies the upper limit set at the PCC at the time of LSP delegation to an active stateful PCE. Dhody, et al. Expires March 26, 2017 [Page 18] Internet-Draft SERVICE-AWARE September 2016 The format of the PCRpt message is described in [STATEFUL-PCE] which uses the as defined in [RFC5440] and extended by PCEP extensions. The PCRpt message can use the updated (as extended in Section 5.2) for the purpose of including the BU object. 6. Other Considerations 6.1. Inter-domain Path Computation [RFC5441] describes the Backward Recursive PCE-Based Computation (BRPC) procedure to compute end to end optimized inter-domain path by cooperating PCEs. The new metric types defined in this document can be applied to end to end path computation, in a similar manner to the existing IGP or TE metrics. The new BU object defined in this document can be applied to end to end path computation, in a similar manner to a METRIC object with its B bit set to 1. All domains should have the same understanding of the METRIC (path delay variation etc.) and the BU object for end-to-end inter-domain path computation to make sense. Otherwise, some form of metric normalization as described in [RFC5441] MUST be applied. 6.1.1. Inter-AS Links The IGP in each neighbour domain can advertise its inter-domain TE link capabilities. This has been described in [RFC5316] (IS-IS) and [RFC5392] (OSPF). The network performance link properties are described in [RFC7471] and [RFC7810]. The same properties must be advertised using the mechanism described in [RFC5392] (OSPF) and [RFC5316] (IS-IS). 6.1.2. Inter-Layer Path Computation [RFC5623] provides a framework for PCE-Based inter-layer MPLS and GMPLS Traffic Engineering. Lower-layer LSPs that are advertised as TE links into the higher-layer network form a Virtual Network Topology (VNT). The advertisement into the higher-layer network should include network performance link properties based on the end to end metric of the lower-layer LSP. Note that the new metrics defined in this document are applied to end to end path computation, even though the path may cross multiple layers. Dhody, et al. Expires March 26, 2017 [Page 19] Internet-Draft SERVICE-AWARE September 2016 6.2. Reoptimizing Paths [RFC6374] defines the measurement of loss, delay, and related metrics over LSPs. A PCC can utilize these measurement techniques. In case it detects a degradation of network performance parameters relative to the value of the constraint it gave when the path was set up, or relative to an implementation-specific threshold, it MAY ask the PCE to reoptimize the path by sending a PCReq with the R bit set in the RP object, as per [RFC5440]. A PCC may also detect the degradation of an LSP without making any direct measurements, by monitoring the TED (as populated by the IGP) for changes in the network performance parameters of the links that carry its LSPs. The PCC can issue a reoptimization request for any impacted LSPs. For example, a PCC can monitor the link bandwidth utilization along the path by monitoring changes in the bandwidth utilization parameters of one or more links on the path in the TED. If the bandwidth utilization percentage of any of the links in the path changes to a value less than that required when the path was set up, or otherwise less than an implementation-specific threshold, then the PCC can issue an reoptimization request to a PCE. A stateful PCE can also determine which LSPs should be re-optimized based on network events or triggers from external monitoring systems. For example, when a particular link deteriorates and its loss increases, this can trigger the stateful PCE to automatically determine which LSP are impacted and should be reoptimized. 7. IANA Considerations 7.1. METRIC types IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" at . Within this registry IANA maintains one sub-registry for "METRIC object T field". Six new metric types are defined in this document for the METRIC object (specified in [RFC5440]). IANA is requested to make the following allocations: Dhody, et al. Expires March 26, 2017 [Page 20] Internet-Draft SERVICE-AWARE September 2016 Value Description Reference ---------------------------------------------------------- TBD1 Path Delay metric [This I.D.] TBD2 Path Delay Variation metric [This I.D.] TBD3 Path Loss metric [This I.D.] TBD8 P2MP Path Delay metric [This I.D.] TBD9 P2MP Path Delay variation metric [This I.D.] TBD10 P2MP Path Loss metric [This I.D.] 7.2. New PCEP Object IANA maintains object class in the registry of PCEP Objects at the sub-registry "PCEP Objects". One new allocation is requested as follows. Object Object Name Reference Class Type --------------------------------------------------- TBD4 1 BU [This I.D.] 7.3. BU Object This document requests that a new sub-registry, named "BU Object Type Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Type field of the BU object. New values are to be assigned by Standards Action [RFC5226]. Each value should be tracked with the following qualities: o Type o Name o Defining RFC The following values are defined in this document: Type Name Reference -------------------------------------------------- 1 LBU (Link Bandwidth [This I.D.] Utilization 2 LRBU (Link Residual [This I.D.] Bandwidth Utilization Dhody, et al. Expires March 26, 2017 [Page 21] Internet-Draft SERVICE-AWARE September 2016 7.4. OF Codes IANA maintains registry of Objective Function (described in [RFC5541]) at the sub-registry "Objective Function". Three new Objective Functions have been defined in this document. IANA is requested to make the following allocations: Code Name Reference Point -------------------------------------------------- TBD5 Minimum Packet Loss Path [This I.D.] (MPLP) TBD6 Maximum Under-Utilized [This I.D.] Path (MUP) TBD7 Maximum Reserved [This I.D.] Under-Utilized Path (MRUP) 7.5. New Error-Values IANA maintains a registry of Error-Types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA is requested to make the following allocations - Two new Error-values are defined for the Error-Type "Not supported object" (type 4) and "Policy violation" (type 5). Error-Type Meaning and error values Reference 4 Not supported object Error-value=TBD11 Unsupported [This I.D.] network performance constraint 5 Policy violation Error-value=TBD12 Not allowed [This I.D.] network performance constraint 8. Security Considerations This document defines new METRIC types, a new BU object, and new OF codes which does not add any new security concerns beyond those discussed in [RFC5440] and [RFC5541] in itself. Some deployments may find the service aware information like delay and packet loss to be Dhody, et al. Expires March 26, 2017 [Page 22] Internet-Draft SERVICE-AWARE September 2016 extra sensitive and could be used to influence path computation and setup with adverse effect. Additionally snooping of PCEP messages with such data or using PCEP messages for network reconnaissance, may give an attacker sensitive information about the operations of the network. Thus, such deployment should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or [PCEPS]. The Transport Layer Security (TLS) based procedure in [PCEPS] is considered as a security enhancement and thus much better suited for the sensitive service aware information. 9. Manageability Considerations 9.1. Control of Function and Policy The only configurable item is the support of the new constraints on a PCE which MAY be controlled by a policy module on individual basis. If the new constraint is not supported/allowed on a PCE, it MUST send a PCErr message accordingly. 9.2. Information and Data Models [RFC7420] describes the PCEP MIB. There are no new MIB Objects for this document. 9.3. Liveness Detection and Monitoring The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 9.4. Verify Correct Operations The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440]. 9.5. Requirements On Other Protocols The PCE requires the TED to be populated with network performance information like link latency, delay variation, packet loss, and utilized bandwidth. This mechanism is described in [RFC7471] and [RFC7810]. 9.6. Impact On Network Operations The mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440]. Dhody, et al. Expires March 26, 2017 [Page 23] Internet-Draft SERVICE-AWARE September 2016 10. Acknowledgments We would like to thank Alia Atlas, John E Drake, David Ward, Young Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu, Quintin Zhao, Chen Huaimo, Avantika, and Adrian Farrel for their useful comments and suggestions. Also the authors gratefully acknowledge reviews and feedback provided by Qin Wu, Alfred Morton and Paul Aitken during performance directorate review. Thanks to Jonathan Hardwick for shepherding this document and providing valuable comments. His help in fixing the editorial and grammatical issues is also appreciated. Thanks to Christian Hopps for the routing directorate review. Thanks to Jouni Korhonen and Alfred Morton for the operational directorate review. Thanks to Christian Huitema for the security directorate review. Thanks to Deborah Brungard for being the responsible AD. Thanks to Ben Campbell, Joel Jaeggli, Stephen Farrell, Kathleen Moriarty, Spencer Dawkins, Mirja Kuehlewind, Jari Arkko and Alia Atlas for the IESG reviews. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . Dhody, et al. Expires March 26, 2017 [Page 24] Internet-Draft SERVICE-AWARE September 2016 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, . [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, . [STATEFUL-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- pce-16 (work in progress), September 2016. 11.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, . Dhody, et al. Expires March 26, 2017 [Page 25] Internet-Draft SERVICE-AWARE September 2016 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, . [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, . [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, . [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, "Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions", RFC 7823, DOI 10.17487/RFC7823, May 2016, . [PCE-INITIATED] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-07 (work in progress), July 2016. Dhody, et al. Expires March 26, 2017 [Page 26] Internet-Draft SERVICE-AWARE September 2016 [PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Transport for PCEP", draft-ietf-pce-pceps-10 (work in progress), July 2016. [IEEE.754.1985] IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE 754, August 1985. Dhody, et al. Expires March 26, 2017 [Page 27] Internet-Draft SERVICE-AWARE September 2016 Appendix A. PCEP Requirements End-to-end service optimization based on latency, delay variation, packet loss, and link bandwidth utilization are key requirements for service providers. The following associated key requirements are identified for PCEP: 1. A PCE supporting this draft MUST have the capability to compute end-to-end (E2E) paths with latency, delay variation, packet loss, and bandwidth utilization constraints. It MUST also support the combination of network performance constraints (latency, delay variation, loss...) with existing constraints (cost, hop-limit...). 2. A PCC MUST be able to specify any network performance constraint in a Path Computation Request (PCReq) message to be applied during the path computation. 3. A PCC MUST be able to request that a PCE optimizes a path using any network performance criteria. 4. A PCE that supports this specification is not required to provide service aware path computation to any PCC at any time. Therefore, it MUST be possible for a PCE to reject a PCReq message with a reason code that indicates service-aware path computation is not supported. Furthermore, a PCE that does not support this specification will either ignore or reject such requests using pre-existing mechanisms, therefore the requests MUST be identifiable to legacy PCEs and rejections by legacy PCEs MUST be acceptable within this specification. 5. A PCE SHOULD be able to return end to end network performance information of the computed path in a Path Computation Reply (PCRep) message. 6. A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) service aware paths. Such constraints are only meaningful if used consistently: for instance, if the delay of a computed path segment is exchanged between two PCEs residing in different domains, a consistent way of defining the delay must be used. Appendix B. Contributor Addresses Dhody, et al. Expires March 26, 2017 [Page 28] Internet-Draft SERVICE-AWARE September 2016 Clarence Filsfils Cisco Systems Email: cfilsfil@cisco.com Siva Sivabalan Cisco Systems Email: msiva@cisco.com George Swallow Cisco Systems Email: swallow@cisco.com Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Rome 00191 Italy Email: sprevidi@cisco.com Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: udayasree.palle@huawei.com Avantika Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: avantika.sushilkumar@huawei.com Xian Zhang Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China Email: zhang.xian@huawei.com Authors' Addresses Dhody, et al. Expires March 26, 2017 [Page 29] Internet-Draft SERVICE-AWARE September 2016 Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Qin Wu Huawei Technologies 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China EMail: bill.wu@huawei.com Vishwas Manral Ionos Network 4100 Moorpark Av San Jose, CA USA EMail: vishwas.ietf@gmail.com Zafar Ali Cisco Systems EMail: zali@cisco.com Kenji Kumaki KDDI Corporation EMail: ke-kumaki@kddi.com Dhody, et al. Expires March 26, 2017 [Page 30] ./draft-ietf-radext-datatypes-08.txt0000664000764400076440000021714013001502110016631 0ustar iustyiusty Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Updates: 2865,3162,6158,6572 Category: Standards Track 18 October 2016 Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Abstract RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFC 2865, 3162, 6158, and 6572. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 18, 2017. DeKok, Alan Standards Track [Page 1] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. DeKok, Alan Standards Track [Page 2] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Table of Contents 1. Introduction ............................................. 4 1.1. Specification Problems with Data Types .............. 4 1.2. Implementation Problems with Data Types ............. 5 1.3. No Mandated Changes ................................. 5 1.4. Requirements Language ............................... 5 2. Use of Data Types ........................................ 6 2.1. Specification Use of Data Types ..................... 6 2.1.1. Field Names for Attribute Values ............... 6 2.1.2. Attribute Definitions using Data Types ......... 7 2.1.3. Format of Attribute Definitions ................ 7 2.1.4. Defining a New Data Type ....................... 8 2.2. Implementation Use of Data Types .................... 9 3. Data Type Definitions .................................... 11 3.1. integer ............................................. 12 3.2. enum ................................................ 12 3.3. time ................................................ 13 3.4. text ................................................ 13 3.5. string .............................................. 14 3.6. concat .............................................. 16 3.7. ifid ................................................ 16 3.8. ipv4addr ............................................ 17 3.9. ipv6addr ............................................ 18 3.10. ipv6prefix ......................................... 18 3.11. ipv4prefix ......................................... 20 3.12. integer64 .......................................... 21 3.13. tlv ................................................ 22 3.14. vsa ................................................ 23 3.15. extended ........................................... 24 3.16. long-extended ...................................... 26 3.17. evs ................................................ 29 4. Updated Registries ....................................... 30 4.1. Create a Data Type Registry ......................... 30 4.2. Updates to the Attribute Type Registry .............. 31 5. Security Considerations .................................. 36 6. IANA Considerations ...................................... 37 7. References ............................................... 37 7.1. Normative References ................................ 37 7.2. Informative References .............................. 38 DeKok, Alan Standards Track [Page 3] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 1. Introduction RADIUS specifications have historically defined attributes in terms of name, value, and data type. Of these three pieces of information, the name is recorded by IANA in the RADIUS Attribute Type registry, but not otherwise managed or restricted, as discussed in [RFC6929] Section 2.7.1. The value is managed by IANA, and recorded in that registry. The data type is not managed or recorded in the RADIUS Attribute Type registry. Experience has shown that there is a need to create well known data types, and have them managed by IANA. This document defines an IANA RADIUS Data Type registry, and updates the RADIUS Attribute Type registry to use those newly defined data types. It recommends how both specifications and implementations should use the data types. It extends the RADIUS Attribute Type registry to have a data type for each assigned attribute. In this section, we review the use of data types in specifications and implementations. Whe highlight ambiguities and inconsistencies. The rest of this document is devoted to resolving those problems. 1.1. Specification Problems with Data Types When attributes are defined in the specifications, the terms "Value" and "String" are used to refer to the contents of an attribute. However, these names are used recursively and inconsistently. We suggest that defining a field to recursively contain itself is problematic. A number of data type names and definitions are given in [RFC2865] Section 5, at the bottom of page 25. These data types are named and clearly defined. However, this practice was not continued in later specifications. Specifically, [RFC2865] defines attributes of data type "address" to carry IPv4 addresses. Despite this definition, [RFC3162] defines attributes of data type "Address" to carry IPv6 addresses. We suggest that the use of the word "address" to refer to disparate data types is problematic. Other failures are that [RFC3162] does not give a data type name and definition for the data types IPv6 address, Interface-Id, or IPv6 prefix. [RFC2869] defines Event-Timestamp to carry a time, but does not re-use the "time" data type defined in [RFC2865]. Instead, it just repeats the "time" definition. [RFC6572] defines multiple attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data type is not named, defined as a data type, or called out as an addition to RADIUS. Further, [RFC6572] does not follow the DeKok, Alan Standards Track [Page 4] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 recommendations of [RFC6158], and does not explain why it fails to follow those recommendations. These ambiguities and inconsistencies need to be resolved. 1.2. Implementation Problems with Data Types RADIUS implementations often use "dictionaries" to map attribute names to type values, and to define data types for each attribute. The data types in the dictionaries are defined by each implementation, but correspond to the "ad hoc" data types used in the specifications. In effect, implementations have seen the need for well-defined data types, and have created them. It is time for RADIUS specifications to follow this practice. 1.3. No Mandated Changes This document mandates no changes to any RADIUS implementation, past, present, or future. It instead documents existing practice, in order to simplify the process of writing RADIUS specifications, to clarify the interpretation of RADIUS standards, and to improve the communication between specification authors and IANA. This document suggests that implementations SHOULD use the data types defined here, in preference to any "ad hoc" data types currently in use. This suggestion should have minimal effect on implementations, as most "ad hoc" data types are compatible with the ones defined here. Any difference will typically be limited to the name of the data type. This document updates [RFC6158] to permit the data types defined in the "Data Type registry" as "basic data types", as per Section 2.1 of that document. The recommendations of [RFC6158] are otherwise unchanged. 1.4. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. DeKok, Alan Standards Track [Page 5] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 2. Use of Data Types The Data Types can be used in two places: specifications, and implementations. This section discusses both uses, and gives guidance on using the data types. 2.1. Specification Use of Data Types In this section, we give recommendations for how specifications should be written using data types. We first describe how attribute field names can be consistently named. We then describe how attribute definitions should use the data types, and deprecate the use of "ASCII art" for attribute definitions. We suggest a format for new attribute definitions. This format includes recommended fields, and suggestions for how those fields should be described. Finally, we make recommendations for how new data types should be defined. 2.1.1. Field Names for Attribute Values Previous specifications used inconsistent and conflicting names for the contents of RADIUS attributes. For example, the term "Value" is used in [RFC2865] Section 5 to define a field which carries the contents of attribute. It is then used in later sections as the sub- field of attribute contents. The result is that the field is defined as recursively containing itself. Similarly, "String" is used both as a data type, and as a sub-field of other data types. We correct this ambiguity by using context-specific names for various fields of attributes and data types. It then becomes clear that, for example, that a field called "VSA-Data" must contain different data than a field called "EVS-Data". Each new name is defined where it is used. We also define the following term: Attr-Data The "Value" field of an Attribute as defined in [RFC2865] Section 5. The contents of this field MUST be of a valid data type as defined in the RADIUS Data Type registry. We consistently use "Attr-Data" to refer to the contents of an attribute, instead of the more ambiguous name "Value". It is RECOMMENDED that new specifications follow this practice. We consistently use "Value" to refer to the contents of a data type, DeKok, Alan Standards Track [Page 6] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 where that data type is simple. For example, an "integer" can have a "Value". In contrast, a Vendor-Specific attribute carries complex information, and thus cannot have a "Value". For data types which carry complex information, we name the fields based on the data type. For example, a Vendor-Specific attribute is defined to carry a "vsa" data type, and the contents of that data type are described herein as "VSA-Data". These terms are used in preference to the term "String", which was previously used in ambiguous ways. It is RECOMMENDED that future specifications use type-specific names, and the same naming scheme for new types. This use will maintain consistent definitions, and help to avoid ambiguities. 2.1.2. Attribute Definitions using Data Types New RADIUS specifications MUST define attributes using data types from the RADIUS Data Type registry. The specification may, of course, define a new data type update the "Data Types" registry, and use the new data type, all in the same document. The guidelines given in [RFC6929] MUST be followed when defining a new data type. Attributes can usually be completely described via the Attribute Type value, name, and data type. The use of "ASCII art" is then limited only to the definition of new data types, and for complex data types. Use of the new extended attributes [RFC6929] makes ASCII art even more problematic. An attribute can be allocated from any of the extended spaces, with more than one option for attribute header format. This allocation decision is made after the specification has been accepted for publication. As the allocation affects the format of the attribute header, it is essentially impossible to create the correct ASCII art prior to final publication. Allocation from the different spaces also changes the value of the Length field, also making it difficult to define it correctly prior to final publication of the document. It is therefore RECOMMENDED that "ASCII art" diagrams not be used for new RADIUS attribute specifications. 2.1.3. Format of Attribute Definitions When defining a new attribute, the following fields SHOULD be given: Description DeKok, Alan Standards Track [Page 7] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 A description of the meaning and interpretation of the attribute. Type The Attribute Type value, given in the "dotted number" notation from [RFC6929]. Specifications can often leave this as "TBD", and request that IANA fill in the allocated values. Length A description of the length of the attribute. For attributes of variable length, a maximum length SHOULD be given. Since the Length may depend on the Type, the definition of Length may be affected by IANA allocations. Data Type One of the named data types from the RADIUS Data Type registry. Value A description of any attribute-specific limitations on the values carried by the specified data type. If there are no attribute-specific limitations, then the description of this field can be omitted, so long as the Description field is sufficiently explanatory. Where the values are limited to a subset of the possible range, valid range(s) MUST be defined. For attributes of data type "enum", a list of enumerated values and names MUST be given, as with [RFC2865] Section 5.6. Using a consistent format for attribute definitions helps to make the definitions clearer. 2.1.4. Defining a New Data Type When a specification needs to define a new data type, it SHOULD follow the format used by the definitions in Section 3 of this document. The text at the start of the data type definition MUST describe the data type, including the expected use, and why a new data type is required. That text SHOULD include limits on expected values, and why those limits exist. The field's "Name", "Value", "Length", and "Format", MUST be given, along with values. The "Name" field SHOULD be a single name, all lower-case. DeKok, Alan Standards Track [Page 8] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Contractions such as "ipv4addr" are RECOMMENDED where they add clarity. We note that the use of "Value" in the RADIUS Data Type registry can be confusing. That name is also used in attribute definitions, but with a different meaning. We trust that the meaning here is clear from the context. The "Value" field SHOULD be given as to be determined or "TBD" in specifications. That number is assigned by IANA. The "Format" field SHOULD be defined with "ASCII art" in order to have a precise definition. Machine-readable formats are also RECOMMENDED. The definition of a new data type should be done only when absolutely necessary. We do not expect a need for a large number of new data types. When defining a new data type, the guideliness of [RFC6929] with respect to data types MUST be followed. It is RECOMMENDED that vendors not define "vendor specific" data types. As discussed in [RFC6929], those data types are rarely necessary, and can cause interoperability problems. Any new data type MUST have unique name in the RADIUS Data Type registry. The number of the data type will be assigned by IANA. 2.2. Implementation Use of Data Types Implementations not supporting a particular data type MUST treat attributes of that data type as being of data type "string", as defined in Section 3.6. It is RECOMMENDED that such attributes be treated as "invalid attributes", as defined in [RFC6929] Section 2.8. Where the contents of a data type do not match the definition, implementations MUST treat the the enclosing attribute as being an "invalid attribute". This requirement includes, but is not limited to, the following situations: * Attributes with values outside of the allowed range(s) for the data type, e.g. as given in the data types "integer", "ipv4addr", "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". * "text" attributes where the contents do not match the required format, * Attributes where the length is shorter or longer than the allowed length(s) for the given data type, DeKok, Alan Standards Track [Page 9] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 The requirements for "reserved" fields are more difficult to quantify. Implementations SHOULD be able to receive and process attributes where "reserved" fields are non-zero. We do not, however, define any "correct" processing of such attributes. Instead, specifications which define new meaning for "reserved" fields SHOULD describe how the new meaning is compatible with older implementations. We expect that such descriptions are derived from practice. Implementations MUST set "reserved" fields to zero when creating attributes. DeKok, Alan Standards Track [Page 10] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 3. Data Type Definitions This section defines the new data types. For each data type, it gives a definition, a name, a number, a length, and an encoding format. Where relevant, it describes subfields contained within the data type. These definitions have no impact on existing RADIUS implementations. There is no requirement that implementations use these names. Where possible, the name of each data type has been taken from previous specifications. In some cases, a different name has been chosen. The change of name is sometimes required to avoid ambiguity (i.e. "address" versus "Address"). Otherwise, the new name has been chosen to be compatible with [RFC2865], or with use in common implementations. In some cases, new names are chosen to clarify the interpretation of the data type. The numbers assigned herein for the data types have no meaning other than to permit them to be tracked by IANA. As RADIUS does not encode information about data types in a packet, the numbers assigned to a data type will never occur in a packet. It is RECOMMENDED that new implementations use the names defined in this document, in order to avoid confusion. Existing implementations may choose to use the names defined here, but that is not required. The encoding of each data type is taken from previous specifications. The fields are transmitted from left to right. Where the data types have inter-dependencies, the simplest data type is given first, and dependent ones are given later. We do not create specific data types for the "tagged" attributes defined in [RFC2868]. That specification defines the "tagged" attributes as being backwards compatible with pre-existing data types. In addition, [RFC6158] Section 2.1 says that "tagged" attributes should not be used. There is therefore no benefit to defining additional data types for these attributes. We trust that implementors will be aware that tagged attributes must be treated differently from non-tagged attributes of the same data type. Similarly, we do not create data types for some attributes having complex structure, such as CHAP-Password, ARAP-Features, or Location- Information. We need to strike a balance between correcting earlier mistakes, and making this document more complex. In some cases, it is better to treat complex attributes as being of type "string", even though they need to be interpreted by RADIUS implementations. The guidelines given in Section 6.3 of [RFC6929] were used to make this determination. DeKok, Alan Standards Track [Page 11] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 3.1. integer The "integer" data type encodes a 32-bit unsigned integer in network byte order. Where the range of values for a particular attribute is limited to a sub-set of the values, specifications MUST define the valid range. Attributes with Values outside of the allowed ranges SHOULD be treated as "invalid attributes". Name integer Value 1 Length Four octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. enum The "enum" data type encodes a 32-bit unsigned integer in network byte order. It differs from the "integer" data type only in that it is used to define enumerated types, such as Service-Type (Section 5.6 of [RFC2865]). Specifications MUST define a valid set of enumerated values, along with a unique name for each value. Attributes with Values outside of the allowed enumerations SHOULD be treated as "invalid attributes". Name enum Value 2 Length DeKok, Alan Standards Track [Page 12] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Four octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3. time The "time" data type encodes time as a 32-bit unsigned value in network byte order and in seconds since 00:00:00 UTC, January 1, 1970. We note that dates before the year 2016 are likely to indicate configuration errors, or lack of access to the correct time. Note that the "time" attribute is defined to be unsigned, which means it is not subject to a signed integer overflow in the year 2038. Name time Value 3 Length Four octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.4. text The "text" data type encodes UTF-8 text [RFC3629]. The maximum length of the text is given by the encapsulating attribute. Where the range of lengths for a particular attribute is limited to a sub- set of possible lengths, specifications MUST define the valid DeKok, Alan Standards Track [Page 13] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 range(s). Attributes with length outside of the allowed values SHOULD be treated as "invalid attributes". Attributes of type "text" which are allocated in the standard space (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of data. Attributes of type "text" which are allocated in the extended space can be longer. In both cases, these limits are reduced when the data is encapsulated inside of an another attribute. Where the text is intended to carry data in a particular format, (e.g. Framed-Route), the format MUST be given. The specification SHOULD describe the format in a machine-readable way, such as via Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with values not matching the defined format SHOULD be treated as "invalid attributes". Note that the "text" data type does not terminate with a NUL octet (hex 00). The Attribute has a Length field and does not use a terminator. Texts of length zero (0) MUST NOT be sent; omit the entire attribute instead. Name text Value 4 Length One or more octets. Format 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+- | Value ... +-+-+-+-+-+-+-+- 3.5. string The "string" data type encodes binary data, as a sequence of undistinguished octets. Where the range of lengths for a particular attribute is limited to a sub-set of possible lengths, specifications MUST define the valid range(s). Attributes with length outside of DeKok, Alan Standards Track [Page 14] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 the allowed values SHOULD be treated as "invalid attributes". Attributes of type "string" which are allocated in the standard space (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of data. Attributes of type "string" which are allocated in the extended space can be longer. In both cases, these limits are reduced when the data is encapsulated inside of an another attribute. Note that the "string" data type does not terminate with a NUL octet (hex 00). The Attribute has a Length field and does not use a terminator. Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. a Where there is a need to encapsulate complex data structures, and TLVs cannot be used, the "string" data type MUST be used. This requirement includes encapsulation of data structures defined outside of RADIUS, which are opaque to the RADIUS infrastucture. It also includes encapsulation of some data structures which are not opaque to RADIUS, such as the contents of CHAP-Password. There is little reason to define a new RADIUS data type for only one attribute. However, where the complex data type cannot be represented as TLVs, and is expected to be used in many attributes, a new data type SHOULD be defined. These requirements are stronger than [RFC6158], which makes the above encapsulation a "SHOULD". This document defines data types for use in RADIUS, so there are few reasons to avoid using them. Name string Value 5 Length One or more octets. Format 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+- | Octets ... +-+-+-+-+-+-+-+- DeKok, Alan Standards Track [Page 15] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 3.6. concat The "concat" data type permits the transport of more than 253 octets of data in a "standard space" [RFC6929] attribute. It is otherwise identical to the "string" data type. If multiple attributes of this data type are contained in a packet, all attributes of the same type code MUST be in order and they MUST be consecutive attributes in the packet. The amount of data transported in a "concat" data type can be no more than the RADIUS packet size. In practice, the requirement to transport multiple attributes means that the limit may be substantially smaller than one RADIUS packet. As a rough guide, is RECOMMENDED that this data type transport no more than 2048 octets of data. The "concat" data type MAY be used for "standard space" attributes. It MUST NOT be used for attributes in the "short extended space" or the "long extended space". It MUST NOT be used in any field or subfields of the following data types: "tlv", "vsa", "extended", "long-extended", or "evs". Name concat Value 6 Length One or more octets. Format 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+- | Octets ... +-+-+-+-+-+-+-+- 3.7. ifid The "ifid" data type encodes an Interface-Id as an 8 octet IPv6 Interface Identifier network byte order. DeKok, Alan Standards Track [Page 16] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Name ifid Value 7 Length Eight octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface-ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Interface-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.8. ipv4addr The "ipv4addr" data type encodes an IPv4 address in network byte order. Where the range of address for a particular attribute is limited to a sub-set of possible addresses, specifications MUST define the valid range(s). Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". Name ipv4addr Value 8 Length Four octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DeKok, Alan Standards Track [Page 17] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.9. ipv6addr The "ipv6addr" data type encodes an IPv6 address in network byte order. Where the range of address for a particular attribute is limited to a sub-set of possible addresses, specifications MUST define the valid range(s). Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". Name ipv6addr Value 9 Length Sixteen octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.10. ipv6prefix The "ipv6prefix" data type encodes an IPv6 prefix, using both a prefix length and an IPv6 address in network byte order. Where the range of prefixes for a particular attribute is limited to a sub-set of possible prefixes, specifications MUST define the valid range(s). Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". DeKok, Alan Standards Track [Page 18] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Attributes with a Prefix-Length field having value greater than 128 MUST be treated as "invalid attributes". Name ipv6prefix Value 10 Length At least two, and no more than eighteen octets. Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Prefix-Length | Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Reserved This field, which is reserved and MUST be present, is always set to zero. This field is one octet in length. Prefix-Length The length of the prefix, in bits. At least 0 and no larger than 128. This field is one octet in length. Prefix The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, MUST be zero. The Prefix field SHOULD NOT contain more octets than necessary to encode the Prefix. DeKok, Alan Standards Track [Page 19] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 3.11. ipv4prefix The "ipv4prefix" data type encodes an IPv4 prefix, using both a prefix length and an IPv4 address in network byte order. Where the range of prefixes for a particular attribute is limited to a sub-set of possible prefixes, specifications MUST define the valid range(s). Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". Attributes with a Prefix-Length field having value greater than 32 MUST be treated as "invalid attributes". Name ipv4prefix Value 11 Length six octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Prefix-Length | Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Reserved This field, which is reserved and MUST be present, is always set to zero. This field is one octet in length. Note that this definition differs from that given in [RFC6572]. See Prefix-Length, below, for an explanation. Prefix-Length The length of the prefix, in bits. The values MUST be no larger than 32. This field is one octet in length. DeKok, Alan Standards Track [Page 20] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Note that this definition differs from that given in [RFC6572]. As compared to [RFC6572], the Prefix-Length field has increased in size by two bits, both of which must be zero. The Reserved field has decreased in size by two bits. The result is that both fields are aligned on octet boundaries, which removes the need for bit masking of the fields. Since [RFC6572] required the Reserved field to be zero, the definition here is compatible with the definition in the original specification. Prefix The Prefix field is 4 octets in length. Bits outside of the Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, this field is fixed length. If the address is all zeros (i.e. "0.0.0.0", then the Prefix-Length MUST be set to 32. 3.12. integer64 The "integer64" data type encodes a 64-bit unsigned integer in network byte order. Where the range of values for a particular attribute is limited to a sub-set of the values, specifications MUST define the valid range(s). Attributes with Values outside of the allowed range(s) SHOULD be treated as "invalid attributes". Name integer64 Value 12 Length Eight octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Value | DeKok, Alan Standards Track [Page 21] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.13. tlv The "tlv" data type encodes a type-length-value, as defined in [RFC6929] Section 2.3. Name tlv Value 13 Length Three or more octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | TLV-Length | TLV-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields TLV-Type This field is one octet. Up-to-date values of this field are specified according to the policies and rules described in [RFC6929] Section 10. Values of 254-255 are "Reserved" for use by future extensions to RADIUS. The value 26 has no special meaning, and MUST NOT be treated as a Vendor Specific attribute. The TLV-Type is meaningful only within the context defined by "Type" fields of the encapsulating Attributes, using the dotted-number notation introduced in [RFC6929]. A RADIUS server MAY ignore Attributes with an unknown "TLV- Type". A RADIUS client MAY ignore Attributes with an unknown "TLV- Type". DeKok, Alan Standards Track [Page 22] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- Type" verbatim. TLV-Length The TLV-Length field is one octet, and indicates the length of this TLV including the TLV-Type, TLV-Length and TLV-Value fields. It MUST have a value between 3 and 255. If a client or server receives a TLV with an invalid TLV-Length, then the attribute which encapsulates that TLV MUST be considered to be an "invalid attribute", and handled as per [RFC6929] Section 2.8. TLVs having TLV-Length of two (2) MUST NOT be sent; omit the entire TLV instead. TLV-Data The TLV-Data field is one or more octets and contains information specific to the Attribute. The format and length of the TLV-Data field is determined by the TLV-Type and TLV- Length fields. The TLV-Data field MUST contain only known RADIUS data types. The TLV-Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs". 3.14. vsa The "vsa" data type encodes Vendor-Specific data, as given in [RFC2865] Section 5.26. It is used only in the Attr-Data field of a Vendor-Specific Attribute. It MUST NOT appear in the contents of any other data type. Where an implementation determines that an attribute of data type "vsa" contains data which does not match the expected format, it SHOULD treat that attribute as being an "invalid attribute". Name vsa Value 14 Length DeKok, Alan Standards Track [Page 23] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Five or more octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VSA-Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Vendor-Id The 4 octets are the Network Management Private Enterprise Code [PEN] of the Vendor in network byte order. VSA-Data The VSA-Data field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. The codification of the range of allowed usage of this field is outside the scope of this specification. The "vsa" data type SHOULD contain as a sequence of "tlv" data types. The interpretation of the TLV-Type and TLV-Data fields are dependent on the vendor's definition of that attribute. The "vsa" data type MUST be used as contents of the Attr-Data field of the Vendor-Specific attribute. The "vsa" data type MUST NOT appear in the contents of any other data type. 3.15. extended The "extended" data type encodes the "Extended Type" format, as given in [RFC6929] Section 2.1. It is used only in the Attr-Data field of an Attribute allocated from the "standard space". It MUST NOT appear in the contents of any other data type. Name extended DeKok, Alan Standards Track [Page 24] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Value 15 Length Two or more octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended-Type | Ext-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Extended-Type The Extended-Type field is one octet. Up-to-date values of this field are specified according to the policies and rules described in [RFC6929] Section 10. Unlike the Type field defined in [RFC2865] Section 5, no values are allocated for experimental or implementation-specific use. Values 241-255 are reserved and MUST NOT be used. The Extended-Type is meaningful only within a context defined by the Type field. That is, this field may be thought of as defining a new type space of the form "Type.Extended-Type". See [RFC6929] Section 2.5 for additional discussion. A RADIUS server MAY ignore Attributes with an unknown "Type.Extended-Type". A RADIUS client MAY ignore Attributes with an unknown "Type.Extended-Type". Ext-Data The contents of this field MUST be a valid data type as defined in the RADIUS Data Type registry. The Ext-Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs". The Ext-Data field is one or more octets. Implementations supporting this specification MUST use the DeKok, Alan Standards Track [Page 25] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Identifier of "Type.Extended-Type" to determine the interpretation of the Ext-Data field. 3.16. long-extended The "long-extended" data type encodes the "Long Extended Type" format, as given in [RFC6929] Section 2.2. It is used only in the Attr-Data field of an Attribute. It MUST NOT appear in the contents of any other data type. Name long-extended Value 16 Length Three or more octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended-Type |M|T| Reserved | Ext-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Extended-Type This field is identical to the Extended-Type field defined above in Section 3.15. M (More) The More field is one (1) bit in length, and indicates whether or not the current attribute contains "more" than 251 octets of data. The More field MUST be clear (0) if the Length field has value less than 255. The More field MAY be set (1) if the Length field has value of 255. If the More field is set (1), it indicates that the Ext-Data field has been fragmented across multiple RADIUS attributes. DeKok, Alan Standards Track [Page 26] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 When the More field is set (1), the attribute MUST have a Length field of value 255; there MUST be an attribute following this one; and the next attribute MUST have both the same Type and Extended Type. That is, multiple fragments of the same value MUST be in order and MUST be consecutive attributes in the packet, and the last attribute in a packet MUST NOT have the More field set (1). That is, a packet containing a fragmented attribute needs to contain all fragments of the attribute, and those fragments need to be contiguous in the packet. RADIUS does not support inter-packet fragmentation, which means that fragmenting an attribute across multiple packets is impossible. If a client or server receives an attribute fragment with the "More" field set (1), but for which no subsequent fragment can be found, then the fragmented attribute is considered to be an "invalid attribute", and handled as per [RFC6929] Section 2.8. T (Truncation) This field is one bit in size and is called "T" for Truncation. It indicates that the attribute is intentionally truncated in this chunk and is to be continued in the next chunk of the sequence. The combination of the M flag and the T flag indicates that the attribute is fragmented (M flag) but that all the fragments are not available in this chunk (T flag). Proxies implementing [RFC6929] will see these attributes as invalid (they will not be able to reconstruct them), but they will still forward them, as Section 5.2 of [RFC6929] indicates that they SHOULD forward unknown attributes anyway. Please see [RFC7499] for further discussion of the uses of this flag. Reserved This field is 6 bits long, and is reserved for future use. Implementations MUST set it to zero DeKok, Alan Standards Track [Page 27] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception. Future specifications may define additional meaning for this field. Implementations therefore MUST NOT treat this field as invalid if it is non-zero. Ext-Data The contents of this field MUST be a valid data type as defined in the RADIUS Data Type registry. The Ext- Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs". The Ext-Data field is one or more octets. Implementations supporting this specification MUST use the Identifier of "Type.Extended-Type" to determine the interpretation of the Ext-Data field. The length of the data MUST be taken as the sum of the lengths of the fragments (i.e. Ext-Data fields) from which it is constructed. Any interpretation of the resulting data MUST occur after the fragments have been reassembled. If the reassembled data does not match the expected format, each fragment MUST be treated as an "invalid attribute", and the reassembled data MUST be discarded. We note that the maximum size of a fragmented attribute is limited only by the RADIUS packet length limitation. Implementations MUST be able to handle the case where one fragmented attribute completely DeKok, Alan Standards Track [Page 28] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 fills the packet. 3.17. evs The "evs" data type encodes an "Extended Vendor-Specific" attribute, as given in [RFC6929] Section 2.4. The "evs" data type is used solely to extend the Vendor Specific space. It MAY appear inside of an "extended" or a "long-extended" data type. It MUST NOT appear in the contents of any other data type. Where an implementation determines that an attribute of data type "evs" contains data which does not match the expected format, it SHOULD treat that attribute as being an "invalid attribute". Name evs Value 17 Length Six or more octets Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | EVS-Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Vendor-Id The 4 octets are the Network Management Private Enterprise Code [PEN] of the Vendor in network byte order. Vendor-Type The Vendor-Type field is one octet. Values are assigned at the sole discretion of the Vendor. DeKok, Alan Standards Track [Page 29] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 EVS-Data The EVS-Data field is one or more octets. It SHOULD encapsulate a previously defined RADIUS data type. Non- standard data types SHOULD NOT be used. We note that the EVS- Data field may be of data type "tlv". The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. We recognise that Vendors have complete control over the contents and format of the Ext-Data field, while at the same time recommending that good practices be followed. Further codification of the range of allowed usage of this field is outside the scope of this specification. 4. Updated Registries This section defines a new IANA registry for RADIUS data types, and then updates the existing RADIUS Attribute Type registry to use the data types from the new registry. 4.1. Create a Data Type Registry This section defines a new registry located under "RADIUS Types", called "Data Type". The "Registration Procedures" for the Data Type registry are "Standards Action". The Data Type registry contains three columns of data, as follows. Value The number of the data type. The value field is an artifact of the registry, and has no on-the-wire meaning. Name The name of the data type. The name field is used only for the registry, and has no on-the-wire meaning. Reference The specification where the data type was defined. The initial contents of the registry are as follows. DeKok, Alan Standards Track [Page 30] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Value Description Reference ----- ----------- ---------------- 1 integer [RFC2865], TBD 2 enum [RFC2865], TBD 3 time [RFC2865], TBD 4 text [RFC2865], TBD 5 string [RFC2865], TBD 6 concat TBD 7 ifid [RFC3162], TBD 8 ipv4addr [RFC2865], TBD 9 ipv6addr [RFC3162], TBD 10 ipv6prefix [RFC3162], TBD 11 ipv4prefix [RFC6572], TBD 12 integer64 [RFC6929], TBD 13 tlv [RFC6929], TBD 14 evs [RFC6929], TBD 15 extended [RFC6929], TBD 16 long-extended [RFC6929], TBD 4.2. Updates to the Attribute Type Registry This section updates the RADIUS Attribute Type registry to have a new column, which is inserted in between the existing "Description" and "Reference" columns. The new column is named "Data Type". The contents of that column are the name of a data type, corresponding to the attribute in that row, or blank if the attribute type is unassigned. The name of the data type is taken from the RADIUS Data Type registry, as defined above. The existing registration requirements for the RADIUS Attribute Type registry are otherwise unchanged. NOTE TO RFC EDITOR: Before the document is published, please remove this note, and the following text in this section. The updated registry follows in CSV format. Value,Description,Data Type,Reference 1,User-Name,text,[RFC2865] 2,User-Password,string,[RFC2865] 3,CHAP-Password,string,[RFC2865] 4,NAS-IP-Address,ipv4addr,[RFC2865] 5,NAS-Port,integer,[RFC2865] 6,Service-Type,enum,[RFC2865] 7,Framed-Protocol,enum,[RFC2865] 8,Framed-IP-Address,ipv4addr,[RFC2865] 9,Framed-IP-Netmask,ipv4addr,[RFC2865] 10,Framed-Routing,enum,[RFC2865] DeKok, Alan Standards Track [Page 31] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 11,Filter-Id,text,[RFC2865] 12,Framed-MTU,integer,[RFC2865] 13,Framed-Compression,enum,[RFC2865] 14,Login-IP-Host,ipv4addr,[RFC2865] 15,Login-Service,enum,[RFC2865] 16,Login-TCP-Port,integer,[RFC2865] 17,Unassigned,, 18,Reply-Message,text,[RFC2865] 19,Callback-Number,text,[RFC2865] 20,Callback-Id,text,[RFC2865] 21,Unassigned,, 22,Framed-Route,text,[RFC2865] 23,Framed-IPX-Network,ipv4addr,[RFC2865] 24,State,string,[RFC2865] 25,Class,string,[RFC2865] 26,Vendor-Specific,vsa,[RFC2865] 27,Session-Timeout,integer,[RFC2865] 28,Idle-Timeout,integer,[RFC2865] 29,Termination-Action,enum,[RFC2865] 30,Called-Station-Id,text,[RFC2865] 31,Calling-Station-Id,text,[RFC2865] 32,NAS-Identifier,text,[RFC2865] 33,Proxy-State,string,[RFC2865] 34,Login-LAT-Service,text,[RFC2865] 35,Login-LAT-Node,text,[RFC2865] 36,Login-LAT-Group,string,[RFC2865] 37,Framed-AppleTalk-Link,integer,[RFC2865] 38,Framed-AppleTalk-Network,integer,[RFC2865] 39,Framed-AppleTalk-Zone,text,[RFC2865] 40,Acct-Status-Type,enum,[RFC2866] 41,Acct-Delay-Time,integer,[RFC2866] 42,Acct-Input-Octets,integer,[RFC2866] 43,Acct-Output-Octets,integer,[RFC2866] 44,Acct-Session-Id,text,[RFC2866] 45,Acct-Authentic,enum,[RFC2866] 46,Acct-Session-Time,integer,[RFC2866] 47,Acct-Input-Packets,integer,[RFC2866] 48,Acct-Output-Packets,integer,[RFC2866] 49,Acct-Terminate-Cause,enum,[RFC2866] 50,Acct-Multi-Session-Id,text,[RFC2866] 51,Acct-Link-Count,integer,[RFC2866] 52,Acct-Input-Gigawords,integer,[RFC2869] 53,Acct-Output-Gigawords,integer,[RFC2869] 54,Unassigned,, 55,Event-Timestamp,time,[RFC2869] 56,Egress-VLANID,integer,[RFC4675] 57,Ingress-Filters,enum,[RFC4675] 58,Egress-VLAN-Name,text,[RFC4675] DeKok, Alan Standards Track [Page 32] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 59,User-Priority-Table,string,[RFC4675] 60,CHAP-Challenge,string,[RFC2865] 61,NAS-Port-Type,enum,[RFC2865] 62,Port-Limit,integer,[RFC2865] 63,Login-LAT-Port,text,[RFC2865] 64,Tunnel-Type,enum,[RFC2868] 65,Tunnel-Medium-Type,enum,[RFC2868] 66,Tunnel-Client-Endpoint,text,[RFC2868] 67,Tunnel-Server-Endpoint,text,[RFC2868] 68,Acct-Tunnel-Connection,text,[RFC2867] 69,Tunnel-Password,string,[RFC2868] 70,ARAP-Password,string,[RFC2869] 71,ARAP-Features,string,[RFC2869] 72,ARAP-Zone-Access,enum,[RFC2869] 73,ARAP-Security,integer,[RFC2869] 74,ARAP-Security-Data,text,[RFC2869] 75,Password-Retry,integer,[RFC2869] 76,Prompt,enum,[RFC2869] 77,Connect-Info,text,[RFC2869] 78,Configuration-Token,text,[RFC2869] 79,EAP-Message,concat,[RFC2869] 80,Message-Authenticator,string,[RFC2869] 81,Tunnel-Private-Group-ID,text,[RFC2868] 82,Tunnel-Assignment-ID,text,[RFC2868] 83,Tunnel-Preference,integer,[RFC2868] 84,ARAP-Challenge-Response,string,[RFC2869] 85,Acct-Interim-Interval,integer,[RFC2869] 86,Acct-Tunnel-Packets-Lost,integer,[RFC2867] 87,NAS-Port-Id,text,[RFC2869] 88,Framed-Pool,text,[RFC2869] 89,CUI,string,[RFC4372] 90,Tunnel-Client-Auth-ID,text,[RFC2868] 91,Tunnel-Server-Auth-ID,text,[RFC2868] 92,NAS-Filter-Rule,text,[RFC4849] 93,Unassigned,, 94,Originating-Line-Info,string,[RFC7155] 95,NAS-IPv6-Address,ipv6addr,[RFC3162] 96,Framed-Interface-Id,ifid,[RFC3162] 97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162] 98,Login-IPv6-Host,ipv6addr,[RFC3162] 99,Framed-IPv6-Route,text,[RFC3162] 100,Framed-IPv6-Pool,text,[RFC3162] 101,Error-Cause Attribute,enum,[RFC3576] 102,EAP-Key-Name,string,[RFC4072][RFC7268] 103,Digest-Response,text,[RFC5090] 104,Digest-Realm,text,[RFC5090] 105,Digest-Nonce,text,[RFC5090] 106,Digest-Response-Auth,text,[RFC5090] DeKok, Alan Standards Track [Page 33] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 107,Digest-Nextnonce,text,[RFC5090] 108,Digest-Method,text,[RFC5090] 109,Digest-URI,text,[RFC5090] 110,Digest-Qop,text,[RFC5090] 111,Digest-Algorithm,text,[RFC5090] 112,Digest-Entity-Body-Hash,text,[RFC5090] 113,Digest-CNonce,text,[RFC5090] 114,Digest-Nonce-Count,text,[RFC5090] 115,Digest-Username,text,[RFC5090] 116,Digest-Opaque,text,[RFC5090] 117,Digest-Auth-Param,text,[RFC5090] 118,Digest-AKA-Auts,text,[RFC5090] 119,Digest-Domain,text,[RFC5090] 120,Digest-Stale,text,[RFC5090] 121,Digest-HA1,text,[RFC5090] 122,SIP-AOR,text,[RFC5090] 123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818] 124,MIP6-Feature-Vector,string,[RFC5447] 125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447] 126,Operator-Name,text,[RFC5580] 127,Location-Information,string,[RFC5580] 128,Location-Data,string,[RFC5580] 129,Basic-Location-Policy-Rules,string,[RFC5580] 130,Extended-Location-Policy-Rules,string,[RFC5580] 131,Location-Capable,enum,[RFC5580] 132,Requested-Location-Info,enum,[RFC5580] 133,Framed-Management-Protocol,enum,[RFC5607] 134,Management-Transport-Protection,enum,[RFC5607] 135,Management-Policy-Id,text,[RFC5607] 136,Management-Privilege-Level,integer,[RFC5607] 137,PKM-SS-Cert,concat,[RFC5904] 138,PKM-CA-Cert,concat,[RFC5904] 139,PKM-Config-Settings,string,[RFC5904] 140,PKM-Cryptosuite-List,string,[RFC5904] 141,PKM-SAID,text,[RFC5904] 142,PKM-SA-Descriptor,string,[RFC5904] 143,PKM-Auth-Key,string,[RFC5904] 144,DS-Lite-Tunnel-Name,text,[RFC6519] 145,Mobile-Node-Identifier,string,[RFC6572] 146,Service-Selection,text,[RFC6572] 147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572] 148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572] 149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572] 150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572] 151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572] 152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572] 153,PMIP6-Home-Interface-ID,ifid,[RFC6572] 154,PMIP6-Visited-Interface-ID,ifid,[RFC6572] DeKok, Alan Standards Track [Page 34] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572] 156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572] 157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572] 158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572] 159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572] 160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572] 161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572] 162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572] 163,EAP-Lower-Layer,enum,[RFC6677] 164,GSS-Acceptor-Service-Name,text,[RFC7055] 165,GSS-Acceptor-Host-Name,text,[RFC7055] 166,GSS-Acceptor-Service-Specifics,text,[RFC7055] 167,GSS-Acceptor-Realm-Name,text,[RFC7055] 168,Framed-IPv6-Address,ipv6addr,[RFC6911] 169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911] 170,Route-IPv6-Information,ipv6prefix,[RFC6911] 171,Delegated-IPv6-Prefix-Pool,text,[RFC6911] 172,Stateful-IPv6-Address-Pool,text,[RFC6911] 173,IPv6-6rd-Configuration,tlv,[RFC6930] 174,Allowed-Called-Station-Id,text,[RFC7268] 175,EAP-Peer-Id,string,[RFC7268] 176,EAP-Server-Id,string,[RFC7268] 177,Mobility-Domain-Id,integer,[RFC7268] 178,Preauth-Timeout,integer,[RFC7268] 179,Network-Id-Name,string,[RFC7268] 180,EAPoL-Announcement,concat,[RFC7268] 181,WLAN-HESSID,text,[RFC7268] 182,WLAN-Venue-Info,integer,[RFC7268] 183,WLAN-Venue-Language,string,[RFC7268] 184,WLAN-Venue-Name,text,[RFC7268] 185,WLAN-Reason-Code,integer,[RFC7268] 186,WLAN-Pairwise-Cipher,integer,[RFC7268] 187,WLAN-Group-Cipher,integer,[RFC7268] 188,WLAN-AKM-Suite,integer,[RFC7268] 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 190,WLAN-RF-Band,integer,[RFC7268] 191,Unassigned,, 192-223,Experimental Use,,[RFC3575] 224-240,Implementation Specific,,[RFC3575] 241,Extended-Attribute-1,extended,[RFC6929] 241.1,Frag-Status,integer,[RFC7499] 241.2,Proxy-State-Length,integer,[RFC7499] 241.3,Response-Length,integer,[RFC7930] 241.4,Original-Packet-Code,integer,[RFC7930] 241.{5-25},Unassigned,, 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 241.{27-240},Unassigned,, 241.{241-255},Reserved,,[RFC6929] DeKok, Alan Standards Track [Page 35] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 242,Extended-Attribute-2,extended,[RFC6929] 242.{1-25},Unassigned,, 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 242.{27-240},Unassigned,, 242.{241-255},Reserved,,[RFC6929] 243,Extended-Attribute-3,extended,[RFC6929] 243.{1-25},Unassigned,, 243.26,Extended-Vendor-Specific-3,evs,[RFC6929] 243.{27-240},Unassigned,, 243.{241-255},Reserved,,[RFC6929] 244,Extended-Attribute-4,extended,[RFC6929] 244.{1-25},Unassigned,, 244.26,Extended-Vendor-Specific-4,evs,[RFC6929] 244.{27-240},Unassigned,, 244.{241-255},Reserved,,[RFC6929] 245,Extended-Attribute-5,long-extended,[RFC6929] 245.{1-25},Unassigned,, 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 245.{27-240},Unassigned,, 245.{241-255},Reserved,,[RFC6929] 246,Extended-Attribute-6,long-extended,[RFC6929] 246.{1-25},Unassigned,, 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 246.{27-240},Unassigned,, 246.{241-255},Reserved,,[RFC6929] 247-255,Reserved,,[RFC3575] 5. Security Considerations This specification is concerned solely with updates to IANA registries. As such, there are no security considerations with the document itself. However, the use of inconsistent names and poorly-defined entities in a protocol is problematic. Inconsistencies in specifications can lead to security and interoperability problems in implementations. Further, having one canonical source for the definition of data types means an implementor has fewer specifications to read. The implementation work is therefore simpler, and is more likely to be correct. The goal of this specification is to reduce ambiguities in the RADIUS protocol, which we believe will lead to more robust and more secure implementations. DeKok, Alan Standards Track [Page 36] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 6. IANA Considerations IANA is instructed to create one new registry as described above in Section 4.1. The "TBD" text in that section should be replaced with the RFC number of this document when it is published. IANA is instructed to update the RADIUS Attribute Type registry, as described above in Section 4.2. IANA is instructed to require that all allocation requests in the RADIUS Attribute Type registry contain a "Data Type" field. That field is required to contain one of the "Data Type" names contained in the RADIUS Data Type registry. IANA is instructed to require that updates to the RADIUS Data Type registry contain the following fields, with the associated instructions: * Value. IANA is instructed to assign the next unused integer in sequence to new data type definitions. * Name. IANA is instructed to require that this name be unique in the registry. * Reference. IANA is instructed to update this field with a reference to the document which defines the data type. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. DeKok, Alan Standards Track [Page 37] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 [RFC4072] Eronen, P., et al, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, February 2013. [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, March 2011. [RFC6572] Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, June 2012. [RFC7499] Perez-Mendez, A. Ed., et al, "Support of Fragmentation of RADIUS Packets", RFC 7499, April 2015. 7.2. Informative References [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [RFC6929] DeKok, A., and Lior, A., "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. [RFC7268] Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC 7268, July 2015. [RFC7499] Perez-Mendez A., et al, "Support of Fragmentation of RADIUS Packets", RFC 7499, April 2015. [PEN] http://www.iana.org/assignments/enterprise-numbers Acknowledgments Thanks to the RADEXT WG for patience and reviews of this document. DeKok, Alan Standards Track [Page 38] INTERNET-DRAFT Data Types in RADIUS 18 October 2016 Authors' Addresses Alan DeKok The FreeRADIUS Server Project Email: aland@freeradius.org DeKok, Alan Standards Track [Page 39] ./draft-ietf-radext-ip-port-radius-ext-17.txt0000664000764400076440000024217313012501273020327 0ustar iustyiusty Network Working Group D. Cheng Internet-Draft Huawei Intended status: Standards Track J. Korhonen Expires: May 18, 2017 Broadcom Corporation M. Boucadair Orange S. Sivakumar Cisco Systems November 14, 2016 RADIUS Extensions for IP Port Configuration and Reporting draft-ietf-radext-ip-port-radius-ext-17 Abstract This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. This document defines a mapping between some RADIUS attributes and IPFIX Information Element Identifiers. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 18, 2017. Cheng, et al. Expires May 18, 2017 [Page 1] Internet-Draft RADIUS Extensions for IP Port November 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extensions of RADIUS Attributes and TLVs . . . . . . . . . . 5 3.1. Extended Attributes for IP Ports . . . . . . . . . . . . 6 3.1.1. IP-Port-Limit-Info Attribute . . . . . . . . . . . . 6 3.1.2. IP-Port-Range Attribute . . . . . . . . . . . . . . . 8 3.1.3. IP-Port-Forwarding-Map Attribute . . . . . . . . . . 11 3.2. RADIUS TLVs for IP Ports . . . . . . . . . . . . . . . . 13 3.2.1. IP-Port-Type TLV . . . . . . . . . . . . . . . . . . 14 3.2.2. IP-Port-Limit TLV . . . . . . . . . . . . . . . . . . 15 3.2.3. IP-Port-Ext-IPv4-Addr TLV . . . . . . . . . . . . . . 16 3.2.4. IP-Port-Int-IPv4-Addr TLV . . . . . . . . . . . . . . 16 3.2.5. IP-Port-Int-IPv6-Addr TLV . . . . . . . . . . . . . . 17 3.2.6. IP-Port-Int-Port TLV . . . . . . . . . . . . . . . . 18 3.2.7. IP-Port-Ext-Port TLV . . . . . . . . . . . . . . . . 19 3.2.8. IP-Port-Alloc TLV . . . . . . . . . . . . . . . . . . 20 3.2.9. IP-Port-Range-Start TLV . . . . . . . . . . . . . . . 21 3.2.10. IP-Port-Range-End TLV . . . . . . . . . . . . . . . . 22 3.2.11. IP-Port-Local-Id TLV . . . . . . . . . . . . . . . . 22 4. Applications, Use Cases and Examples . . . . . . . . . . . . 24 4.1. Managing CGN Port Behavior using RADIUS . . . . . . . . . 24 4.1.1. Configure IP Port Limit for a User . . . . . . . . . 24 4.1.2. Report IP Port Allocation/Deallocation . . . . . . . 26 4.1.3. Configure Forwarding Port Mapping . . . . . . . . . . 28 4.1.4. An Example . . . . . . . . . . . . . . . . . . . . . 30 4.2. Report Assigned Port Set for a Visiting UE . . . . . . . 31 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7.1. IANA Considerations on New IPFIX Information Elements . . . . . . . . . . . . . . . . . . . . . . . . 34 Cheng, et al. Expires May 18, 2017 [Page 2] Internet-Draft RADIUS Extensions for IP Port November 2016 7.2. IANA Considerations on New RADIUS Attributes . . . . . . 34 7.3. IANA Considerations on New RADIUS TLVs . . . . . . . . . 35 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction In a broadband network, customer information is usually stored on a RADIUS server [RFC2865]. At the time when a user initiates an IP connection request, if this request is authorized, the RADIUS server will populate the user's configuration information to the Network Access Server (NAS), which is often referred to as a Broadband Network Gateway (BNG) in broadband access networks. The Carrier- Grade NAT (CGN) function may also be implemented on the BNG. Within this document, the CGN may perform NAT44 [RFC3022], NAT64 [RFC6146], or Dual-Stack Lite AFTR [RFC6333] function. In such case, the CGN IP transport port (e.g., TCP/UDP port) mapping(s) behavior(s) can be part of the configuration information sent from the RADIUS server to the NAS/BNG. The NAS/BNG may also report to the RADIUS Server the IP port mapping behavior applied by the CGN to a user session to the RADIUS server, as part of the accounting information sent from the NAS/BNG to a RADIUS server. When IP packets traverse the CGN, it performs mapping on the IP transport (e.g., TCP/UDP) source port as required. An IP transport source port, along with source IP address, destination IP address, destination port and protocol identifier if applicable, uniquely identify a mapping. Since the number space of IP transport ports in CGN's external realm is shared among multiple users assigned with the same IPv4 address, the total number of a user's simultaneous IP mappings is likely to be subject to port quota (see Section 5 of [RFC6269]). The attributes defined in this document may also be used to report the assigned port range in some deployments such as Provider WLAN [I-D.gundavelli-v6ops-community-wifi-svcs]. For example, a visiting host can be managed by a CPE (Customer Premises Equipment ) which will need to report the assigned port range to the service platform. This is required for identification purposes (see TR-146 [TR-146] for more details). This document proposes three new attributes as RADIUS protocol's extensions, and they are used for separate purposes as follows: Cheng, et al. Expires May 18, 2017 [Page 3] Internet-Draft RADIUS Extensions for IP Port November 2016 1. IP-Port-Limit-Info: This attribute may be carried in a RADIUS Access-Accept, Access-Request, Accounting-Request or CoA-Request packet. The purpose of this attribute is to limit the total number of IP source transport ports allocated to a user, associated with one or more IPv4 or IPv6 addresses. 2. IP-Port-Range: This attribute may be carried in a RADIUS Accounting-Request packet. The purpose of this attribute is for an address sharing device (e.g., a CGN) to report to the RADIUS server the range of IP source transport ports that have been allocated or deallocated for a user. The port range is bound to an external IPv4 address. 3. IP-Port-Forwarding-Map: This attribute may be carried in RADIUS Access-Accept, Access-Request, Accounting-Request or CoA-Request packet. The purpose of this attribute is to specify how an IP internal source transport port together with its internal IPv4 or IPv6 address are mapped to an external source transport port along with the external IPv4 address. IPFIX Information Elements [RFC7012] can be used for IP flow identification and representation over RADIUS. This document provides a mapping between some RADIUS TLVs and IPFIX Information Element Identifiers. A new IPFIX Information Element is defined by this document (see Section 3.2.2). IP protocol numbers (refer to [ProtocolNumbers]) can be used for identification of IP transport protocols (e.g., TCP [RFC0793], UDP [RFC0768], DCCP [RFC4340], and SCTP [RFC4960]) that are associated with some RADIUS attributes. This document focuses on IPv4 address sharing. IPv6 prefix sharing mechanisms (e.g., NPTv6) are out of scope. 2. Terminology This document makes use of the following terms: o IP Port: refers to IP transport port (e.g., TCP port number, UDP port number). o IP Port Type: refers to the IP transport protocol as indicated by the IP transport protocol number, refer to (refer to [ProtocolNumbers]) o IP Port Limit: denotes the maximum number of IP ports for a specific (or all) IP transport protocol(s), that a device supporting port ranges can use when performing port number Cheng, et al. Expires May 18, 2017 [Page 4] Internet-Draft RADIUS Extensions for IP Port November 2016 mappings for a specific user/host. Note, this limit is usually associated with one or more IPv4/IPv6 addresses. o IP Port Range: specifies a set of contiguous IP ports, indicated by the lowest numerical number and the highest numerical number, inclusively. o Internal IP Address: refers to the IP address that is used by a host as a source IP address in an outbound IP packet sent towards a device supporting port ranges in the internal realm. The internal IP address may be IPv4 or IPv6. o External IP Address: refers to the IP address that is used as a source IP address in an outbound IP packet after traversing a device supporting port ranges in the external realm. This document assumes that the external IP address is an IPv4 address. o Internal Port: is an IP transport port, which is allocated by a host or application behind an address sharing device for an outbound IP packet in the internal realm. o External Port: is an IP transport port, which is allocated by an address sharing device upon receiving an outbound IP packet in the internal realm, and is used to replace the internal port that is allocated by a user or application. o External realm: refers to the networking segment where external IP addresses are used as source addresses of outbound packets forwarded by an address sharing device. o Internal realm: refers to the networking segment that is behind an address sharing device and where internal IP addresses are used. o Mapping: denotes a relationship between an internal IP address, internal port and the protocol, and an external IP address, external port, and the protocol. o Address sharing device: a device that is capable of sharing an IPv4 address among multiple users. A typical example of this device is a CGN, CPE, Provider WLAN Gateway, etc. 3. Extensions of RADIUS Attributes and TLVs These three new attributes are defined in the following sub-sections: 1. IP-Port-Limit-Info Attribute 2. IP-Port-Range Attribute Cheng, et al. Expires May 18, 2017 [Page 5] Internet-Draft RADIUS Extensions for IP Port November 2016 3. IP-Port-Forwarding-Map Attribute All these attributes are allocated from the RADIUS "Extended Type" code space per [RFC6929]. These attributes and their embedded TLVs (refer to Section 3.2) are defined with globally unique names and follow the guideline in Section 2.7.1 of [RFC6929]. In all the figures describing the RADIUS attributes and TLV formats in the following sub-sections, the fields are transmitted from left to right. 3.1. Extended Attributes for IP Ports 3.1.1. IP-Port-Limit-Info Attribute This attribute is of type "TLV" as defined in the RADIUS Protocol Extensions [RFC6929]. It contains some sub-attributes and the requirement is as follows: o The IP-Port-Limit-Info Attribute MAY contain the IP-Port-Type TLV (see Section 3.2.1). o The IP-Port-Limit-Info Attribute MUST contain the IP-Port-Limit TLV (see Section 3.2.2). o The IP-Port-Limit-Info Attribute MAY contain the IP-Port-Ext- IPv4-Addr TLV (see Section 3.2.3). The IP-Port-Limit-Info Attribute specifies the maximum number of IP ports as indicated in IP-Port-Limit TLV, of a specific IP transport protocol as indicated in IP-Port-Type TLV, and associated with a given IPv4 address as indicated in IP-Port-Ext-IPv4-Addr TLV for an end user. Note that when IP-Port-Type TLV is not included as part of the IP- Port-Limit-Info Attribute, the port limit applies to all IP transport protocols. Note also that when IP-Port-Ext-IPv4-Addr TLV is not included as part of the IP-Port-Limit-Info Attribute, the port limit applies to all the IPv4 addresses managed by the address sharing device, e.g., a CGN or NAT64 device. The IP-Port-Limit-Info Attribute MAY appear in an Access-Accept packet. It MAY also appear in an Access-Request packet as a Cheng, et al. Expires May 18, 2017 [Page 6] Internet-Draft RADIUS Extensions for IP Port November 2016 preferred maximum number of IP ports indicated by the device supporting port ranges co-located with the NAS, e.g., a CGN or NAT64. The IP-Port-Limit-Info Attribute MAY appear in a CoA-Request packet. The IP-Port-Limit-Info Attribute MAY appear in an Accounting-Request packet. The IP-Port-Limit-Info Attribute MUST NOT appear in any other RADIUS packet. The format of the IP-Port-Limit-Info Attribute is shown in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Type 241 Length This field indicates the total length in bytes of all fields of this attribute, including the Type, Length, Extended-Type, and the entire length of the embedded TLVs. Extended-Type 5 Value This field contains a set of TLVs as follows: IP-Port-Type TLV This TLV contains a value that indicates the IP port type. Refer to Section 3.2.1. IP-Port-Limit TLV This TLV contains the maximum number of IP ports of a specific IP port type and associated with a given IPv4 address for an Cheng, et al. Expires May 18, 2017 [Page 7] Internet-Draft RADIUS Extensions for IP Port November 2016 end user. This TLV MUST be included in the IP-Port-Limit-Info Attribute. Refer to Section 3.2.2. This limit applies to all mappings that can be instantiated by an underlying address sharing device without soliciting any external entity. In particular, this limit does not include the ports that are instructed by an AAA server. IP-Port-Ext-IPv4-Addr TLV This TLV contains the IPv4 address that is associated with the IP port limit contained in the IP-Port-Limit TLV. This TLV is optionally included as part of the IP-Port-Limit-Info Attribute. Refer to Section 3.2.3. IP-Port-Limit-Info Attribute is associated with the following identifier: 241.5. 3.1.2. IP-Port-Range Attribute This attribute is of type "TLV" as defined in the RADIUS Protocol Extensions [RFC6929]. It contains some sub-attributes and the requirement is as follows: o The IP-Port-Range Attribute MAY contain the IP-Port-Type TLV (see Section 3.2.1). o The IP-Port-Range Attribute MUST contain the IP-Port-Alloc TLV (see Section 3.2.8). o For port allocation, the IP-Port-Range Attribute MUST contain both the IP-Port-Range-Start TLV (see Section 3.2.9) and the IP-Port- Range-END TLV (see Section 3.2.10). For port deallocation, the IP-Port-Range Attribute MAY contain both of these two TLVs; if the two TLVs are not included, it implies that all ports that were previously allocated are now all deallocated. o The IP-Port-Range Attribute MAY contain the IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). o The IP-Port-Range Attribute MAY contain the IP-Port-Local-Id TLV (see Section 3.2.11). The IP-Port-Range Attribute contains a range of contiguous IP ports. These ports are either to be allocated or deallocated depending on the Value carried by the IP-Port-Alloc TLV. If the IP-Port-Type TLV is included as part of the IP-Port-Range Attribute, the port range is associated with the specific IP Cheng, et al. Expires May 18, 2017 [Page 8] Internet-Draft RADIUS Extensions for IP Port November 2016 transport protocol as specified in the IP-Port-Type TLV, but otherwise is for all IP transport protocols. If the IP-Port-Ext-IPv4-Addr TLV is included as part of the IP-Port- Range Attribute, the port range as specified is associated with IPv4 address as indicated, but otherwise is for all IPv4 addresses by the address sharing device (e.g., a CGN device) for the end user. This attribute can be used to convey a single IP transport port number; in such case the Value of the IP-Port-Range-Start TLV and the IP-Port-Range-End TLV, respectively, contain the same port number. The information contained in the IP-Port-Range Attribute is sent to RADIUS server. The IP-Port-Range Attribute MAY appear in an Accounting-Request packet. The IP-Port-Range Attribute MUST NOT appear in any other RADIUS packet. The format of the IP-Port-Range Attribute is shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Type 241 Length This field indicates the total length in bytes of all fields of this attribute, including the Type, Length, Extended-Type, and the entire length of the embedded TLVs. Extended-Type 6 Value Cheng, et al. Expires May 18, 2017 [Page 9] Internet-Draft RADIUS Extensions for IP Port November 2016 This field contains a set of TLVs as follows: IP-Port-Type TLV This TLV contains a value that indicates the IP port type. Refer to Section 3.2.1. IP-Port-Alloc TLV This TLV contains a flag to indicate that the range of the specified IP ports for either allocation or deallocation. This TLV MUST be included as part of the IP-Port-Range Attribute. Refer to Section 3.2.8. IP-Port-Range-Start TLV This TLV contains the smallest port number of a range of contiguous IP ports. To report the port allocation, this TLV MUST be included together with IP-Port-Range-End TLV as part of the IP-Port-Range Attribute. Refer to Section 3.2.9. IP-Port-Range-End TLV This TLV contains the largest port number of a range of contiguous IP ports. To report the port allocation, this TLV MUST be included together with IP-Port-Range-Start TLV as part of the IP-Port-Range Attribute. Refer to Section 3.2.10. IP-Port-Ext-IPv4-Addr TLV This TLV contains the IPv4 address that is associated with the IP port range, as collectively indicated in the IP-Port-Range- Start TLV and the IP-Port-Range-End TLV. This TLV is optionally included as part of the IP-Port-Range Attribute. Refer to Section 3.2.3. IP-Port-Local-Id TLV This TLV contains a local session identifier at the customer premise, such as MAC address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP address/prefix, etc. This TLV is optionally included as part of the IP-Port-Range Attribute. Refer to Section 3.2.11. The IP-Port-Range attribute is associated with the following identifier: 241.6. Cheng, et al. Expires May 18, 2017 [Page 10] Internet-Draft RADIUS Extensions for IP Port November 2016 3.1.3. IP-Port-Forwarding-Map Attribute This attribute is of type "TLV" as defined in the RADIUS Protocol Extensions [RFC6929]. It contains some sub-attributes and the requirement is as follows: o The IP-Port-Forwarding-Map Attribute MAY contain the IP-Port-Type TLV (see Section 3.2.1). o The IP-Port-Forwarding-Map Attribute MUST contain both IP-Port- Int-Port TLV (see Section 3.2.6) and the IP-Port-Ext-Port TLV (see Section 3.2.7). o If the internal realm is with IPv4 address family, the IP-Port- Forwarding-Map Attribute MUST contain the IP-Port-Int-IPv4-Addr TLV (see Section 3.2.4); if the internal realm is with IPv6 address family, the IP-Port-Forwarding-Map Attribute MUST contain the IP-Port-Int-IPv6-Addr TLV (see Section 3.2.5). o The IP-Port-Forwarding-Map Attribute MAY contain the IP-Port-Ext- IPv4-Addr TLV (see Section 3.2.3). o The IP-Port-Forwarding-Map Attribute MAY contain the IP-Port- Local-Id TLV (see Section 3.2.11). The attribute contains a 2-byte IP internal port number and a 2-byte IP external port number. The internal port number is associated with an internal IPv4 or IPv6 address that MUST always be included. The external port number is associated with a specific external IPv4 address if included, but otherwise with all external IPv4 addresses for the end user. If the IP-Port-Type TLV is included as part of the IP-Port- Forwarding-Map Attribute, the port mapping is associated with the specific IP transport protocol as specified in the IP-Port-Type TLV, but otherwise is for all IP transport protocols. The IP-Port-Forwarding-Map Attribute MAY appear in an Access-Accept packet. It MAY also appear in an Access-Request packet to indicate a preferred port mapping by the device co-located with NAS. However the server is not required to honor such a preference. The IP-Port-Forwarding-Map Attribute MAY appear in a CoA-Request packet. The IP-Port-Forwarding-Map Attribute MAY also appear in an Accounting-Request packet. Cheng, et al. Expires May 18, 2017 [Page 11] Internet-Draft RADIUS Extensions for IP Port November 2016 The IP-Port-Forwarding-Map Attribute MUST NOT appear in any other RADIUS packet. The format of the IP-Port-Forwarding-Map Attribute is shown in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Type 241 Length This field indicates the total length in bytes of all fields of this attribute, including the Type, Length, Extended-Type, and the entire length of the embedded TLVs. Extended-Type 7 Value This field contains a set of TLVs as follows: IP-Port-Type TLV This TLV contains a value that indicates the IP port type. Refer to Section 3.2.1. IP-Port-Int-Port TLV This TLV contains an internal IP port number associated with an internal IPv4 or IPv6 address. This TLV MUST be included together with IP-Port-Ext-Port TLV as part of the IP-Port- Forwarding-Map attribute. Refer to Section 3.2.6. IP-Port-Ext-Port TLV Cheng, et al. Expires May 18, 2017 [Page 12] Internet-Draft RADIUS Extensions for IP Port November 2016 This TLV contains an external IP port number associated with an external IPv4 address. This TLV MUST be included together with IP-Port-Int-Port TLV as part of the IP-Port-Forwarding-Map attribute. Refer to Section 3.2.7. IP-Port-Int-IPv4-Addr TLV This TLV contains an IPv4 address that is associated with the internal IP port number contained in the IP-Port-Int-Port TLV. For internal realm with IPv4 address family, this TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute. Refer to Section 3.2.4. IP-Port-Int-IPv6-Addr TLV This TLV contains an IPv6 address that is associated with the internal IP port number contained in the IP-Port-Int-Port TLV. For internal realm with IPv6 address family, this TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute. Refer to Section 3.2.5. IP-Port-Ext-IPv4-Addr TLV This TLV contains an IPv4 address that is associated with the external IP port number contained in the IP-Port-Ext-Port TLV. This TLV MAY be included as part of the IP-Port-Forwarding-Map Attribute. Refer to Section 3.2.3. IP-Port-Local-Id TLV This TLV contains a local session identifier at the customer premise, such as MAC address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP address/prefix, etc. This TLV is optionally included as part of the IP-Port-Forwarding-Map Attribute. Refer to Section 3.2.11. The IP-Port-Forwarding-Map Attribute is associated with the following identifier: 241.7. 3.2. RADIUS TLVs for IP Ports The TLVs that are included in the three attributes (see Section 3.1) are defined in the following sub-sections. These TLVs use the format defined in [RFC6929]. As the three attributes carry similar data, we have defined a common set of TLVs which are used for all three attributes. That is, the TLVs have the same name and number, when encapsulated in any one of the three parent attributes. See Cheng, et al. Expires May 18, 2017 [Page 13] Internet-Draft RADIUS Extensions for IP Port November 2016 Section 3.1.1, Section 3.1.2, and Section 3.1.3 for a list of which TLV is permitted within which parent attribute. The encoding of the Value field of these TLVs follows the recommendation of [RFC6158]. In particular, IP-Port-Type, IP-Port- Limit, IP-Port-Int-Port, IP-Port-Ext-Port, IP-Port-Alloc, IP-Port- Range-Start, and IP-Port-Range-End TLVs are encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158]. 3.2.1. IP-Port-Type TLV The format of IP-Port-Type TLV is shown in Figure 4. This attribute carries the IP transport protocol number defined by IANA (refer to [ProtocolNumbers]) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | Protocol-Number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 TLV-Type 1 Length 6 Protocol-Number Integer. This field contains the data (unsigned8) of the protocol number defined in [ProtocolNumbers], right justified, and the unused bits in this field MUST be set to zero. Protocols that do not use a port number (e.g., Resource Reservation Protocol (RSVP), IP Encapsulating Security Payload (ESP)) MUST NOT be included in the IP-Port-Type TLV. IP-Port-Type TLV MAY be included in the following Attributes: o IP-Port-Limit-Info Attribute, identified as 241.5.1 (see Section 3.1.1). Cheng, et al. Expires May 18, 2017 [Page 14] Internet-Draft RADIUS Extensions for IP Port November 2016 o IP-Port-Range Attribute, identified as 241.6.1 (see Section 3.1.2). o IP-Port-Forwarding-Map Attribute, identified as 241.7.1 (see Section 3.1.3). When the IP-Port-Type TLV is included within a RADIUS Attribute, the associated attribute is applied to the IP transport protocol as indicated by the Protocol-Number only, such as TCP, UDP, SCTP, DCCP, etc. 3.2.2. IP-Port-Limit TLV The format of IP-Port-Limit TLV is shown in Figure 5. This attribute carries IPFIX Information Element "sourceTransportPortsLimit (458), which indicates the maximum number of IP transport ports as a limit for an end user to use that is associated with one or more IPv4 or IPv6 addresses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | sourceTransportPortsLimit +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceTransportPortsLimit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 TLV-Type 2 Length 6 sourceTransportPortsLimit Integer. This field contains the data (unsigned16) of sourceTransportPortsLimit (458) defined in IPFIX, right justified, and the unused bits in this field MUST be set to zero. IP-Port-Limit TLV MUST be included as part of the IP-Port-Limit-Info Attribute (refer to Section 3.1.1), identified as 241.5.2. Cheng, et al. Expires May 18, 2017 [Page 15] Internet-Draft RADIUS Extensions for IP Port November 2016 3.2.3. IP-Port-Ext-IPv4-Addr TLV The format of IP-Port-Ext-IPv4-Addr TLV is shown in Figure 6. This attribute carries IPFIX Information Element 225, "postNATSourceIPv4Address", which is the IPv4 source address after NAT operation (refer to [IPFIX]). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | postNATSourceIPv4Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ postNATSourceIPv4Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 TLV-Type 3 Length 6 postNATSourceIPv4Address Integer. This field contains the data (ipv4Address) of postNATSourceIPv4Address (225) defined in IPFIX. IP-Port-Ext-IPv4-Addr TLV MAY be included in the following Attributes: o IP-Port-Limit-Info Attribute, identified as 241.5.3 (see Section 3.1.1). o IP-Port-Range Attribute, identified as 241.6.3 (see Section 3.1.2). o IP-Port-Forwarding-Mapping Attribute, identified as 241.7.3 (see Section 3.1.3). 3.2.4. IP-Port-Int-IPv4-Addr TLV The format of IP-Port-Int-IPv4 TLV is shown in Figure 7. This attribute carries IPFIX Information Element 8, "sourceIPv4Address", which is the IPv4 source address before NAT operation (refer to [IPFIX]). Cheng, et al. Expires May 18, 2017 [Page 16] Internet-Draft RADIUS Extensions for IP Port November 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | sourceIPv4Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv4Address | +-+--+-+-+-+-+-+-++-+-+-+-+-+-+-+ Figure 7 TLV-Type 4 Length 6 sourceIPv4Address Integer. This field contains the data (ipv4Address) of sourceIPv4Address (8) defined in IPFIX. If the internal realm is with IPv4 address family, the IP-Port-Int- IPv4-Addr TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute (refer to Section 3.1.3), identified as 241.7.4. 3.2.5. IP-Port-Int-IPv6-Addr TLV The format of IP-Port-Int-IPv6-Addr TLV is shown in Figure 8. This attribute carries IPFIX Information Element 27, "sourceIPv6Address", which is the IPv6 source address before NAT operation (refer to [IPFIX]). Cheng, et al. Expires May 18, 2017 [Page 17] Internet-Draft RADIUS Extensions for IP Port November 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 TLV-Type 5 Length 18 sourceIPv6Address IPv6 address (128 bits). This field contains the data (ipv6Address) of sourceIPv6Address (27) defined in IPFIX. If the internal realm is with IPv6 address family, the IP-Port-Int- IPv6-Addr TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute (refer to Section 3.1.3), identified as 241.7.5. 3.2.6. IP-Port-Int-Port TLV The format of IP-Port-Int-Port TLV is shown in Figure 9. This attribute carries IPFIX Information Element 7, "sourceTransportPort", which is the source transport number associated with an internal IPv4 or IPv6 address (refer to [IPFIX]). Cheng, et al. Expires May 18, 2017 [Page 18] Internet-Draft RADIUS Extensions for IP Port November 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | sourceTransportPort +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceTransportPort | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 TLV-Type 6 Length 6 sourceTransportPort Integer. This field contains the data (unsigned16) of sourceTrasnportPort (7) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Int-Port TLV MUST be included as part of the IP-Port- Forwarding-Map Attribute (refer to Section 3.1.3), identified as 241.7.6. 3.2.7. IP-Port-Ext-Port TLV The format of IP-Port-Ext-Port TLV is shown in Figure 10. This attribute carries IPFIX Information Element 227, "postNAPTSourceTransportPort", which is the transport number associated with an external IPv4 address(refer to [IPFIX]). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | postNAPTSourceTransportPort +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ postNAPTSourceTransportPort | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 TLV-Type Cheng, et al. Expires May 18, 2017 [Page 19] Internet-Draft RADIUS Extensions for IP Port November 2016 7 Length 6 postNAPTSourceTransportPort Integer. This field contains the data (unsigned16) of postNAPTSourceTrasnportPort (227) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Ext-Port TLV MUST be included as part of the IP-Port- Forwarding-Map Attribute (refer to Section 3.1.3), identified as 241.7.7. 3.2.8. IP-Port-Alloc TLV The format of IP-Port-Alloc TLV is shown in Figure 11. This attribute carries IPFIX Information Element 230, "natEvent", which is a flag to indicate an action of NAT operation (refer to [IPFIX]). When the value of natEvent is "1" (Create event), it means to allocate a range of transport ports; when the value is "2", it means to deallocate a range of transports ports. For the purpose of this TLV, no other value is used. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | natEvent +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ natEvent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 TLV-Type 8 Length 6 natEvent Cheng, et al. Expires May 18, 2017 [Page 20] Internet-Draft RADIUS Extensions for IP Port November 2016 Integer. This field contains the data (unsigned8) of natEvent (230) defined in IPFIX, right justified, and unused bits MUST be set to zero. It indicates the allocation or deallocation of a range of IP ports as follows: 1: Allocation 2: Deallocation Reserved: 0. IP-Port-Alloc TLV MUST be included as part of the IP-Port-Range Attribute (refer to Section 3.1.2), identified as 241.6.8. 3.2.9. IP-Port-Range-Start TLV The format of IP-Port-Range-Start TLV is shown in Figure 12. This attribute carries IPFIX Information Element 361, "portRangeStart", which is the smallest port number of a range of contiguous transport ports (refer to [IPFIX]). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | portRangeStart +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ portRangeStart | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 TLV-Type 9 Length 6 portRangeStart Cheng, et al. Expires May 18, 2017 [Page 21] Internet-Draft RADIUS Extensions for IP Port November 2016 Integer. This field contains the data (unsigned16) of (361) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Range-Start TLV is included as part of the IP-Port-Range Attribute (refer to Section 3.1.2), identified as 241.6.9. 3.2.10. IP-Port-Range-End TLV The format of IP-Port-Range-End TLV is shown in Figure 13. This attribute carries IPFIX Information Element 362, "portRangeEnd", which is the largest port number of a range of contiguous transport ports (refer to [IPFIX]). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | portRangeEnd +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ portRangeEnd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 TLV-Type 10 Length 6 portRangeEnd Integer. This field contains the data (unsigned16) of (362) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Range-End TLV is included as part of the IP-Port-Range Attribute (refer to Section 3.1.2), identified as 241.6.10. 3.2.11. IP-Port-Local-Id TLV The format of IP-Port-Local-Id TLV is shown in Figure 14. This attribute carries a string called "localID", which is a local significant identifier as explained below. Cheng, et al. Expires May 18, 2017 [Page 22] Internet-Draft RADIUS Extensions for IP Port November 2016 The primary issue addressed by this TLV is that there are CGN deployments that do not distinguish internal hosts by their internal IP address alone, but use further identifiers for unique subscriber identification. For example, this is the case if a CGN supports overlapping private or shared IP address spaces (refer to [RFC1918] and [RFC6598]) for internal hosts of different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and/or another identifier, for example, the identifier of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address is not sufficient to demultiplex connections from internal hosts. An additional identifier needs to be present in the IP-Port-Range Attribute and IP-Port-Forwarding-Mapping Attribute in order to uniquely identify an internal host. The IP-Port-Local-Id TLV is used to carry this identifier. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | Length | localID .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 TLV-Type 11 Length Variable number of bytes. localID string. The data type of this field is string (refer to [I-D.ietf-radext-datatypes]). This field contains the data that is a local session identifier at the customer premise, such as MAC address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP address/prefix, or another local session identifier. IP-Port-Local-Id TLV MAY be included in the following Attributes if it is necessary to identify the subscriber: o IP-Port-Range Attribute, identified as 241.6.11 (see Section 3.1.2). Cheng, et al. Expires May 18, 2017 [Page 23] Internet-Draft RADIUS Extensions for IP Port November 2016 o IP-Port-Forwarding-Mapping Attribute, identified as 241.7.11 (see Section 3.1.3). 4. Applications, Use Cases and Examples This section describes some applications and use cases to illustrate the use of the attributes proposed in this document. 4.1. Managing CGN Port Behavior using RADIUS In a broadband network, customer information is usually stored on a RADIUS server, and the BNG acts as a NAS. The communication between the NAS and the RADIUS server is triggered by a user when it signs in to the Internet service, where either PPP or DHCP/DHCPv6 is used. When a user signs in, the NAS sends a RADIUS Access-Request message to the RADIUS server. The RADIUS server validates the request, and if the validation succeeds, it in turn sends back a RADIUS Access- Accept message. The Access-Accept message carries configuration information specific to that user, back to the NAS, where some of the information would pass on to the requesting user via PPP or DHCP/ DHCPv6. A CGN function in a broadband network is most likely be co-located on a BNG. In that case, parameters for CGN port mapping behavior for users can be configured on the RADIUS server. When a user signs in to the Internet service, the associated parameters can be conveyed to the NAS, and proper configuration is accomplished on the CGN device for that user. Also, CGN operation status such as CGN port allocation and deallocation for a specific user on the BNG can also be transmitted back to the RADIUS server for accounting purpose using the RADIUS protocol. RADIUS protocol has already been widely deployed in broadband networks to manage BNG, thus the functionality described in this specification introduces little overhead to the existing network operation. In the following sub-sections, we describe how to manage CGN behavior using RADIUS protocol, with required RADIUS extensions proposed in Section 3. 4.1.1. Configure IP Port Limit for a User In the face of IPv4 address shortage, there are currently proposals to multiplex multiple users' connections over a number of shared IPv4 addresses, such as Carrier Grade NAT [RFC6888], Dual-Stack Lite Cheng, et al. Expires May 18, 2017 [Page 24] Internet-Draft RADIUS Extensions for IP Port November 2016 [RFC6333], NAT64 [RFC6146], etc. As a result, a single IPv4 public address may be shared by hundreds or even thousands of users. As indicated in [RFC6269], it is therefore necessary to impose limits on the total number of ports available to an individual user to ensure that the shared resource, i.e., the IPv4 address, remains available in some capacity to all the users using it. The support of IP port limit is also documented in [RFC6888] as a requirement for CGN. The IP port limit imposed to an end user may be on the total number of IP source transport ports, or a specific IP transport protocol as defined in Section 3.1.1. The per-user based IP port limit is configured on a RADIUS server, along with other user information such as credentials. When a user signs in to the Internet service successfully, the IP port limit for the subscriber is passed by the RADIUS server to the BNG, acting as a NAS and co-located with the CGN, using the IP-Port- Limit-Info RADIUS attribute (defined in Section 3.1.1), along with other configuration parameters. While some parameters are passed to the user, the IP port limit is recorded on the CGN device for imposing the usage of IP transport ports for that user. Figure 15 illustrates how RADIUS protocol is used to configure the maximum number of TCP/UDP ports for a given user on a CGN device. User CGN/NAS AAA | BNG Server | | | | | | |----Service Request------>| | | | | | |-----Access-Request -------->| | | | | |<----Access-Accept-----------| | | (IP-Port-Limit-Info) | | | (for TCP/UDP ports) | |<---Service Granted ------| | | (other parameters) | | | | | | (CGN external port | | allocation and | | IPv4 address assignment) | | | | Figure 15: RADIUS Message Flow for Configuring CGN Port Limit Cheng, et al. Expires May 18, 2017 [Page 25] Internet-Draft RADIUS Extensions for IP Port November 2016 The IP port limit created on a CGN device for a specific user using RADIUS extension may be changed using RADIUS CoA message [RFC5176] that carries the same RADIUS attribute. The CoA message may be sent from the RADIUS server directly to the NAS, which once accepts and sends back a RADIUS CoA ACK message, the new IP port limit replaces the previous one. Figure 16 illustrates how RADIUS protocol is used to increase the TCP/UDP port limit from 1024 to 2048 on a CGN device for a specific user. User CGN/NAS AAA | BNG Server | | | | TCP/UDP Port Limit (1024) | | | | | |<---------CoA Request----------| | | (IP-Port-Limit-Info) | | | (for TCP/UDP ports) | | | | | TCP/UDP Port Limit (2048) | | | | | |---------CoA Response--------->| | | | Figure 16: RADIUS Message Flow for changing a user's CGN port limit 4.1.2. Report IP Port Allocation/Deallocation Upon obtaining the IP port limit for a user, the CGN device needs to allocate an IP transport port for the user when receiving a new IP flow sent from that user. As one practice, a CGN may allocate a block of IP ports for a specific user, instead of one port at a time, and within each port block, the ports may be randomly distributed or in consecutive fashion. When a CGN device allocates a block of transport ports, the information can be easily conveyed to the RADIUS server by a new RADIUS attribute called the IP-Port-Range (defined in Section 3.1.2). The CGN device may allocate one or more IP port ranges, where each range contains a set of numbers representing IP transport ports, and the total number of ports MUST be less or equal to the associated IP port limit imposed for that user. A CGN device may choose to allocate a small port range, and allocate more at a later time as needed; such practice is good because its randomization in nature. Cheng, et al. Expires May 18, 2017 [Page 26] Internet-Draft RADIUS Extensions for IP Port November 2016 At the same time, the CGN device also needs to decide the shared IPv4 address for that user. The shared IPv4 address and the pre-allocated IP port range are both passed to the RADIUS server. When a user initiates an IP flow, the CGN device randomly selects a transport port number from the associated and pre-allocated IP port range for that user to replace the original source port number, along with the replacement of the source IP address by the shared IPv4 address. A CGN device may decide to "free" a previously assigned set of IP ports that have been allocated for a specific user but not currently in use, and with that, the CGN device must send the information of the deallocated IP port range along with the shared IPv4 address to the RADIUS server. Figure 17 illustrates how RADIUS protocol is used to report a set of ports allocated and deallocated, respectively, by a NAT64 device for a specific user to the RADIUS server. 2001:db8:100:200::/56 is the IPv6 prefix allocated to this user. In order to limit the usage of the NAT64 resources on a per-user basis for fairness of resource usage (see REQ-4 of [RFC6888]), port range allocations are bound to the /56 prefix, not to the source IPv6 address of the request. The NAT64 devices is configured with the per-user port limit policy by some means (e.g., subscriber-mask [RFC7785]). Cheng, et al. Expires May 18, 2017 [Page 27] Internet-Draft RADIUS Extensions for IP Port November 2016 Host NAT64/NAS AAA | BNG Server | | | | | | |----Service Request------>| | | | | | |-----Access-Request -------->| | | | | |<----Access-Accept-----------| |<---Service Granted ------| | | (other parameters) | | ... ... ... | | | | | | | (NAT64 decides to allocate | | a TCP/UDP port range for the user) | | | | | |-----Accounting-Request----->| | | (IP-Port-Range | | | for allocation) | ... ... ... | | | | (NAT64 decides to deallocate | | a TCP/UDP port range for the user) | | | | | |-----Accounting-Request----->| | | (IP-Port-Range | | | for deallocation) | | | | Figure 17: RADIUS Message Flow for reporting NAT64 allocation/ deallocation of a port set 4.1.3. Configure Forwarding Port Mapping In most scenarios, the port mapping on a NAT device is dynamically created when the IP packets of an IP connection initiated by a user arrives. For some applications, the port mapping needs to be pre- defined allowing IP packets of applications from outside a CGN device to pass through and "port forwarded" to the correct user located behind the CGN device. Port Control Protocol [RFC6887], provides a mechanism to create a mapping from an external IP address and port to an internal IP address and port on a CGN device just to achieve the "port forwarding" purpose. PCP is a server-client protocol capable of creating or deleting a mapping along with a rich set of features on a CGN device in dynamic fashion. In some deployment, all users need is Cheng, et al. Expires May 18, 2017 [Page 28] Internet-Draft RADIUS Extensions for IP Port November 2016 a few, typically just one pre-configured port mapping for applications such as web cam at home, and the lifetime of such a port mapping remains valid throughout the duration of the customer's Internet service connection time. In such an environment, it is possible to statically configure a port mapping on the RADIUS server for a user and let the RADIUS protocol to propagate the information to the associated CGN device. Note that this document targets deployments where a AAA server is responsible de instructing NAT mappings for a given subscriber and does not make any assumption about the host's capabilities with regards to port forwarding control. This deployment is complementary to PCP given that PCP targets a different deployment model where an application (on the host) controls its mappings in an upstream CPE, CGN, firewall, etc. Figure 18 illustrates how RADIUS protocol is used to configure a forwarding port mapping on a NAT44 device by using RADIUS protocol. Host CGN/NAS AAA | BNG Server | | | |----Service Request------>| | | | | | |---------Access-Request------->| | | | | |<--------Access-Accept---------| | | (IP-Port-Forwarding-Map) | |<---Service Granted ------| | | (other parameters) | | | | | | (Create a port mapping | | for the user, and | | associate it with the | | internal IP address | | and external IP address) | | | | | | | | |------Accounting-Request------>| | | (IP-Port-Forwarding-Map) | Figure 18: RADIUS Message Flow for configuring a forwarding port mapping A port forwarding mapping that is created on a CGN device using RADIUS extension as described above may also be changed using RADIUS CoA message [RFC5176] that carries the same RADIUS association. The CoA message may be sent from the RADIUS server directly to the NAS, Cheng, et al. Expires May 18, 2017 [Page 29] Internet-Draft RADIUS Extensions for IP Port November 2016 which once accepts and sends back a RADIUS CoA ACK message, the new port forwarding mapping then replaces the previous one. Figure 19 illustrates how RADIUS protocol is used to change an existing port mapping from (a:X) to (a:Y), where "a" is an internal port, and "X" and "Y" are external ports, respectively, for a specific user with a specific IP address Host CGN/NAS AAA | BNG Server | | | | Internal IP Address | | Port Map (a:X) | | | | | |<---------CoA Request----------| | | (IP-Port-Forwarding-Map) | | | | | Internal IP Address | | Port Map (a:Y) | | | | | |---------CoA Response--------->| | | (IP-Port-Forwarding-Map) | Figure 19: RADIUS Message Flow for changing a user's forwarding port mapping 4.1.4. An Example An Internet Service Provider (ISP) assigns TCP/UDP 500 ports for the user Joe. This number is the limit that can be used for TCP/UDP ports on a CGN device for Joe, and is configured on a RADIUS server. Also, Joe asks for a pre-defined port forwarding mapping on the CGN device for his web cam applications (external port 5000 maps to internal port 1234). When Joe successfully connects to the Internet service, the RADIUS server conveys the TCP/UDP port limit (500) and the forwarding port mapping (external port 5000 to internal port 1234) to the CGN device, using IP-Port-Limit-Info Attribute and IP-Port-Forwarding-Map attribute, respectively, carried by an Access-Accept message to the BNG where NAS and CGN co-located. Upon receiving the first outbound IP packet sent from Joe's laptop, the CGN device decides to allocate a small port pool that contains 40 consecutive ports, from 3500 to 3540, inclusively, and also assign a shared IPv4 address 192.0.2.15, for Joe. The CGN device also randomly selects one port from the allocated range (say 3519) and use that port to replace the original source port in outbound IP packets. Cheng, et al. Expires May 18, 2017 [Page 30] Internet-Draft RADIUS Extensions for IP Port November 2016 For accounting purpose, the CGN device passes this port range (3500-3540) and the shared IPv4 address 192.0.2.15 together to the RADIUS server using IP-Port-Range attribute carried by an Accounting- Request message. When Joe works on more applications with more outbound IP mappings and the port pool (3500-3540) is close to exhaust, the CGN device allocates a second port pool (8500-8800) in a similar fashion, and also passes the new port range (8500-8800) and IPv4 address 192.0.2.15 together to the RADIUS server using IP-Port-Range attribute carried by an Accounting-Request message. Note when the CGN allocates more ports, it needs to assure that the total number of ports allocated for Joe is within the limit. Joe decides to upgrade his service agreement with more TCP/UDP ports allowed (up to 1000 ports). The ISP updates the information in Joe's profile on the RADIUS server, which then sends a CoA-Request message that carries the IP-Port-Limit-Info Attribute with 1000 ports to the CGN device; the CGN device in turn sends back a CoA-ACK message. With that, Joe enjoys more available TCP/UDP ports for his applications. When Joe is not using his service, most of the IP mappings are closed with their associated TCP/UDP ports released on the CGN device, which then sends the relevant information back to the RADIUS server using IP-Port-Range attribute carried by Accounting-Request message. Throughout Joe's connection with his ISP Internet service, applications can communicate with his web cam at home from external realm directly traversing the pre-configured mapping on the CGN device. When Joe disconnects from his Internet service, the CGN device will deallocate all TCP/UDP ports as well as the port-forwarding mapping, and send the relevant information to the RADIUS server. 4.2. Report Assigned Port Set for a Visiting UE Figure 20 illustrates an example of the flow exchange which occurs when a visiting User Equipment (UE) connects to a CPE offering WLAN service. For identification purposes (see [RFC6967]), once the CPE assigns a port set, it issues a RADIUS message to report the assigned port set. Cheng, et al. Expires May 18, 2017 [Page 31] Internet-Draft RADIUS Extensions for IP Port November 2016 UE CPE CGN AAA | BNG Server | | | | | | |----Service Request------>| | | | | | |-----Access-Request -------->| | | | | |<----Access-Accept-----------| |<---Service Granted ------| | | (other parameters) | | ... | ... ... |<---IP@----| | | | | | | | (CPE assigns a TCP/UDP port | | range for this visiting UE) | | | | | |--Accounting-Request-...------------------->| | | (IP-Port-Range | | | for allocation) | ... | ... ... | | | | | | | | | (CPE withdraws a TCP/UDP port | | range for a visiting UE) | | | | | |--Accounting-Request-...------------------->| | | (IP-Port-Range | | | for deallocation) | | | | Figure 20: RADIUS Message Flow for reporting CPE allocation/ deallocation of a port set to a visiting UE 5. Table of Attributes This document proposes three new RADIUS attributes and their formats are as follows: o IP-Port-Limit-Info: 241.5. o IP-Port-Range: 241.6. o IP-Port-Forwarding-Map: 241.7. The following table provides a guide as what type of RADIUS packets that may contain these attributes, and in what quantity. Cheng, et al. Expires May 18, 2017 [Page 32] Internet-Draft RADIUS Extensions for IP Port November 2016 Request Accept Reject Challenge Acct. # Attribute Request 0+ 0+ 0 0 0+ 241.5 IP-Port-Limit-Info 0 0 0 0 0+ 241.6 IP-Port-Range 0+ 0+ 0 0 0+ 241.7 IP-Port-Forwarding-Map The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 6. Security Considerations This document does not introduce any security issue other than the ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA messages. Known RADIUS vulnerabilities apply to this specification. For example, if RADIUS packets are sent in the clear, an attacker in the communication path between the RADIUS client and server may glean information that it will use to prevent a legitimate user to access the service by appropriately setting the maximum number of IP ports conveyed in an IP-Port-Limit-Info Attribute, exhaust the port quota of a user by installing many mapping entries (IP-Port-Forwarding-Map Attribute), prevent incoming traffic to be delivered to its legitimate destination by manipulating the mapping entries installed by means of an IP-Port-Forwarding-Map Attribute, discover the IP address and port range assigned to a given user and which is reported in an IP-Port-Range Attribute, etc. The root cause of these attack vectors is the communication between the RADIUS client and server. The IP-Port-Local-Id TLV includes an identifier of which the type and length is deployment and implementation dependent. This identifier might carry privacy sensitive information. It is therefore RECOMMENDED to utilize identifiers that do not have such privacy concerns. If there is any error in a Radius Accounting-Request packet sent from a RADIUS client to the server, the RADIUS server MUST NOT send response to the client (refer to [RFC2866]). Examples of the errors include the erroneous port range in IP-Port-Range Attribute, inconsistent port mapping in IP-Port-Forwarding-Map Attribute, etc. This document targets deployments where a trusted relationship is in place between the RADIUS client and server with communication optionally secured by IPsec or Transport Layer Security (TLS) [RFC6614]. Cheng, et al. Expires May 18, 2017 [Page 33] Internet-Draft RADIUS Extensions for IP Port November 2016 7. IANA Considerations This document requires new code point assignments for both IPFIX Information Elements and RADIUS attributes as explained in the following sub-sections. 7.1. IANA Considerations on New IPFIX Information Elements The following is a new IPFIX Information Element as requested by this document (refer to Section 3.2.2) : o sourceTransportPortsLimit: * Name: sourceTransportPortsLimit. * Element ID: 458. * Description: This Information Element contains the maximum number of IP source transport ports that can be used by an end user when sending IP packets; each user is associated with one or more (source) IPv4 or IPv6 addresses. This IE is particularly useful in address sharing deployments that adhere to REQ-4 of [RFC6888]. Limiting the number of ports assigned to each user ensures fairness among users and mitigates the denial-of-service attack that a user could launch against other users through the address sharing device in order to grab more ports. * Data type: unsigned16. * Data type semantics: totalCounter. * Data type unit: ports. * Data value range: from 1 to 65535. 7.2. IANA Considerations on New RADIUS Attributes The authors request that Attribute Types and Attribute Values defined in this document be registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS namespaces as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes and registries created by this document IANA is requested to place them at http://www.iana.org/assignments/radius-types. In particular, this document defines three new RADIUS attributes, entitled "IP-Port-Limit-Info" (see Section 3.1.1), "IP-Port-Range" Cheng, et al. Expires May 18, 2017 [Page 34] Internet-Draft RADIUS Extensions for IP Port November 2016 (see Section 3.1.2) and "IP-Port-Forwarding-Map" (see Section 3.1.3), with assigned values of 241.5, 241.6 and 241.7 from the Short Extended Space of [RFC6929]: Type Name Meaning ---- ---- ------- 241.5 IP-Port-Limit-Info see Section 3.1.1 241.6 IP-Port-Range see Section 3.1.2 241.7 IP-Port-Forwarding-Map see Section 3.1.3 7.3. IANA Considerations on New RADIUS TLVs IANA has created a new registry called "RADIUS IP Port Configuraion and Reporting TLVs". All TLVs in this registry have one or more parent Radius attributes in nesting (refer to [RFC6929]. This registray contains the following TLVs: Value Name Definition ----- ----- ---------- 0 Reserved 1 IP-Port-Type see Section 3.2.1 2 IP-Port-Limit see Section 3.2.2 3 IP-Port-Ext-IPv4-Addr see Section 3.2.3 4 IP-Port-Int-IPv4-Addr see Section 3.2.4 5 IP-Port-Int-IPv6-Addr see Section 3.2.5 6 IP-Port-Int-Port see Section 3.2.6 7 IP-Port-Ext-Port see Section 3.2.7 8 IP-Port-Alloc see Section 3.2.8 9 IP-Port-Range-Start see Section 3.2.9 10 IP-Port-Range-End see Section 3.2.10 11 IP-Port-Local-Id see Section 3.2.11 12-255 Unsigned The registration procedure for this registry is Standards Action as defined in [RFC5226]. 8. Acknowledgements Many thanks to Dan Wing, Roberta Maglione, Daniel Derksen, David Thaler, Alan Dekok, Lionel Morand, and Peter Deacon for their useful comments and suggestions. Special thanks to Lionel Morand for the Shepherd review and to Kathleen Moriarty for the AD review. Thanks to Carl Wallace, Tim Chown, and Ben Campbell for the detailed review. Cheng, et al. Expires May 18, 2017 [Page 35] Internet-Draft RADIUS Extensions for IP Port November 2016 9. References 9.1. Normative References [I-D.ietf-radext-datatypes] DeKok, A., "Data Types in the Remote Authentication Dial- In User Service Protocol (RADIUS)", draft-ietf-radext- datatypes-08 (work in progress), October 2016. [IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", . [ProtocolNumbers] IANA, "Protocol Numbers", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, DOI 10.17487/RFC3575, July 2003, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . Cheng, et al. Expires May 18, 2017 [Page 36] Internet-Draft RADIUS Extensions for IP Port November 2016 9.2. Informative References [I-D.gundavelli-v6ops-community-wifi-svcs] Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, "Service Provider Wi-Fi Services Over Residential Architectures", draft-gundavelli-v6ops-community-wifi- svcs-06 (work in progress), April 2013. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008, . Cheng, et al. Expires May 18, 2017 [Page 37] Internet-Draft RADIUS Extensions for IP Port November 2016 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, . [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, . [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, . [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, . [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, . [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, DOI 10.17487/RFC6967, June 2013, . Cheng, et al. Expires May 18, 2017 [Page 38] Internet-Draft RADIUS Extensions for IP Port November 2016 [RFC7785] Vinapamula, S. and M. Boucadair, "Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016, . [TR-146] Broadband Forum, "TR-146: Subscriber Sessions", . Authors' Addresses Dean Cheng Huawei 2330 Central Expressway Santa Clara, California 95050 USA Email: dean.cheng@huawei.com Jouni Korhonen Broadcom Corporation 3151 Zanker Road San Jose 95134 USA Email: jouni.nospam@gmail.com Mohamed Boucadair Orange Rennes France Email: mohamed.boucadair@orange.com Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, North Carolina USA Email: ssenthil@cisco.com Cheng, et al. Expires May 18, 2017 [Page 39] ./draft-ietf-rmcat-cc-requirements-09.txt0000664000764400076440000007113312442534420017602 0ustar iustyiusty Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Informational Z. Sarker, Ed. Expires: June 15, 2015 Ericsson December 12, 2014 Congestion Control Requirements for Interactive Real-Time Media draft-ietf-rmcat-cc-requirements-09 Abstract 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 low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for real-time media congestion avoidance technique. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terms are presented in many cases using lowercase for readability. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Jesup & Sarker Expires June 15, 2015 [Page 1] Internet-Draft RTP Media Congestion Control Requirements December 2014 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 15, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deficiencies of existing mechanisms . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Most of today's TCP congestion control schemes were developed with a focus on an use of the Internet for reliable bulk transfer of non- time-critical data, such as transfer of large files. They have also been used successfully to govern the reliable transfer of smaller chunks of data in as short a time as possible, such as when fetching Web pages. These algorithms have also been used for transfer of media streams that are viewed in a non-interactive manner, such as "streaming" video, where having the data ready when the viewer wants it is important, but the exact timing of the delivery is not. Jesup & Sarker Expires June 15, 2015 [Page 2] Internet-Draft RTP Media Congestion Control Requirements December 2014 When doing real-time interactive media, the requirements are different; one needs to provide the data continuously, within a very limited time window (no more than 100s of milliseconds end-to-end delay), the sources of data may be able to adapt the amount of data that needs sending within fairly wide margins but can be rate limited by the application- even not always have data to send, and may tolerate some amount of packet loss, but since the data is generated in real-time, sending "future" data is impossible, and since it's consumed in real-time, data delivered late is commonly useless. While the requirements for real-time interactive media differ from the requirements for the other flow types, these other flow types will be present in the network. The congestion control algorithm for real-time interactive media must work properly when these other flow types are present as cross traffic on the network. One particular protocol portfolio being developed for this use case is WebRTC [I-D.ietf-rtcweb-overview], where one envisions sending multiple flows using the Real-time Transport Protocol (RTP) [RFC3550] between two peers, in conjunction with data flows, all at the same time, without having special arrangements with the intervening service providers. As RTP does not provide any congestion control mechanism; a set of circuit breakers, such as [I-D.ietf-avtcore-rtp-circuit-breakers], are required to protect the network from excessive congestion caused by the non-congestion controlled flows. When the real-time interactive media is congestion controlled, it is recommended that the congestion control mechanism operates within the constraints defined by these circuit breakers when circuit breaker is present and that it should not cause congestion collapse when circuit breaker is not implemented. Given that this use case is the focus of this document, use cases involving non-interactive media such as video streaming, and use cases using multicast/broadcast-type technologies, are out of scope. The terminology defined in [I-D.ietf-rtcweb-overview] is used in this memo. 2. Requirements 1. The congestion control algorithm must attempt to provide as-low- as-possible-delay transit for interactive real-time traffic while still providing a useful amount of bandwidth. There may be lower limits on the amount of bandwidth that is useful, but this is largely application-specific and the application may be able to modify or remove flows in order allow some useful flows to get enough bandwidth. (Example: not enough bandwidth for low-latency video+audio, but enough for audio-only.) Jesup & Sarker Expires June 15, 2015 [Page 3] Internet-Draft RTP Media Congestion Control Requirements December 2014 A. Jitter (variation in the bitrate over short time scales) also is relevant, though moderate amounts of jitter will be absorbed by jitter buffers. Transit delay should be considered to track the short-term maximums of delay including jitter. B. It should provide this as-low-as-possible-delay transit and minimize self-induced latency even when faced with intermediate bottlenecks and competing flows. Competing flows may limit what's possible to achieve. C. It should be resilience to the effects of the events, such as routing changes, which may alter or remove bottlenecks or change the bandwidth available especially if there is a reduction in available bandwidth or increase in observed delay. It is expected that the mechanism reacts quickly to the such events to avoid delay buildup. In the context of this memo, a 'quick' reaction is on the order of a few RTTs, subject to the constraints of the media codec, but is likely within a second. Reaction on the next RTT is explicitly not required, since many codecs cannot adapt their sending rate that quickly, but equally response cannot be arbitrarily delayed. D. It should react quickly to handle both local and remote interface changes (WLAN to 3G data, etc) which may radically change the bandwidth available or bottlenecks, especially if there is a reduction in available bandwidth or increase in bottleneck delay. It is assumed that an interface change can generate a notification to the algorithm. E. The real-time interactive media applications can be rate limited. This means the offered loads can be less than the available bandwidth at any given moment, and may vary dramatically over time, including dropping to no load and then resuming a high load, such as in a mute/unmute operation. Hence, the algorithm must be designed to handle such behavior from media source or application. Note that the reaction time between a change in the bandwidth available from the algorithm and a change in the offered load is variable, and may be different when increasing versus decreasing. F. The algorithm requires to avoid building up queues when competing with short-term bursts of traffic (for example, traffic generated by web-browsing) which can quickly saturate a local-bottleneck router or link, but also clear quickly. The algorithm should also react quickly to regain Jesup & Sarker Expires June 15, 2015 [Page 4] Internet-Draft RTP Media Congestion Control Requirements December 2014 its previous share of the bandwidth when the local- bottleneck or link is cleared. G. Similarly periodic bursty flows such as MPEG DASH [MPEG_DASH] or proprietary media streaming algorithms may compete in bursts with the algorithm, and may not be adaptive within a burst. They are often layered on top of TCP but use TCP in a bursty manner that can interact poorly with competing flows during the bursts. The algorithm must not increase the already existing delay buildup during those bursts. Note that this competing traffic may be on a shared access link, or the traffic burst may cause a shift in the location of the bottleneck for the duration of the burst. 2. The algorithm must be fair to other flows, both real-time flows (such as other instances of itself), and TCP flows, both long- lived and bursts such as the traffic generated by a typical web browsing session. Note that 'fair' is a rather hard-to-define term. It should be fair with itself, giving fair share of the bandwidth to multiple flows with similar RTTs, and if possible to multiple flows with different RTTs. A. Existing flows at a bottleneck must also be fair to new flows to that bottleneck, and must allow new flows to ramp up to a useful share of the bottleneck bandwidth as quickly as possible. A useful share will depend on the media types involved, total bandwidth available and the user experience requirements of a particular service. Note that relative RTTs may affect the rate new flows can ramp up to a reasonable share. 3. The algorithm should not starve competing TCP flows, and should as best as possible avoid starvation by TCP flows. A. The congestion control should prioritise achieving a useful share of the bandwidth depending on the media types and total available bandwidth over achieving as low as possible transit delay, when these two requirements are in conflict. 4. The algorithm should as quickly as possible adapt to initial network conditions at the start of a flow. This should occur both if the initial bandwidth is above or below the bottleneck bandwidth. A. The algorithm should allow different modes of adaptation for example,the startup adaptation may be faster than adaptation later in a flow. It should allow for both slow-start operation (adapt up) and history-based startup (start at a Jesup & Sarker Expires June 15, 2015 [Page 5] Internet-Draft RTP Media Congestion Control Requirements December 2014 point expected to be at or below channel bandwidth from historical information, which may need to adapt down quickly if the initial guess is wrong). Starting too low and/or adapting up too slowly can cause a critical point in a personal communication to be poor ("Hello!"). Starting over-bandwidth causes other problems for user experience, so there's a tension here. Alternative methods to help startup like probing during setup with dummy data may be useful in some applications; in some cases there will be a considerable gap in time between flow creation and the initial flow of data. Again, A flow may need to change adaptation rates due to network conditions or changes in the provided flows (such as un-muting or sending data after a gap). 5. The algorithm should be stable if the RTP streams are halted or discontinuous (for example - Voice Activity Detection). A. After stream resumption, the algorithm should attempt to rapidly regain its previous share of the bandwidth; the aggressiveness with which this is done will decay with the length of the pause. 6. The algorithm should where possible merge information across multiple RTP streams sent between two endpoints, when those RTP streams share a common bottleneck, whether or not those streams are multiplexed onto the same ports, in order to allow congestion control of the set of streams together instead of as multiple independent streams. This allows better overall bandwidth management, faster response to changing conditions, and fairer sharing of bandwidth with other network users. A. The algorithm should also share information and adaptation with other non-RTP flows between the same endpoints, such as a WebRTC DataChannel [I-D.ietf-rtcweb-data-channel], when possible. B. When there are multiple streams across the same 5-tuple coordinating their bandwidth use and congestion control, the algorithm should allow the application to control the relative split of available bandwidth. The most correlated bandwidth usage would be with other flows on the same 5-tuple, but there may be use in coordinating measurement and control of the local link(s). Use of information about previous flows, especially on the same 5-tuple, may be useful input to the algorithm, especially to startup performance of a new flow. Jesup & Sarker Expires June 15, 2015 [Page 6] Internet-Draft RTP Media Congestion Control Requirements December 2014 7. The algorithm should not require any special support from network elements to convey congestion related information to be functional. As much as possible, it should leverage available information about the incoming flow to provide feedback to the sender. Examples of this information are the packet arrival times, acknowledgements and feedback, packet timestamps, and packet losses, Explicit Congestion Notification (ECN) [RFC3168]; all of these can provide information about the state of the path and any bottlenecks. However, the use of available information is algorithm dependent. A. Extra information could be added to the packets to provide more detailed information on actual send times (as opposed to sampling times), but should not be required. 8. Since the assumption here is a set of RTP streams, the backchannel typically should be done via RTCP[RFC3550]; one alternative would be to include it instead in a reverse RTP channel using header extensions. A. In order to react sufficiently quickly when using RTCP for a backchannel, an RTP profile such as RTP/AVPF [RFC4585] or RTP/SAVPF [RFC5124] that allows sufficiently frequent feedback must be used. Note that in some cases, backchannel messages may be delayed until the RTCP channel can be allocated enough bandwidth, even under AVPF rules. This may also imply negotiating a higher maximum percentage for RTCP data or allowing solutions to violate or modify the rules specified for AVPF. B. Bandwidth for the feedback messages should be minimized (such as via RFC 5506 [RFC5506]to allow RTCP without Sender Reports/Receiver Reports) C. Backchannel data should be minimized to avoid taking too much reverse-channel bandwidth (since this will often be used in a bidirectional set of flows). In areas of stability, backchannel data may be sent more infrequently so long as algorithm stability and fairness are maintained. When the channel is unstable or has not yet reached equilibrium after a change, backchannel feedback may be more frequent and use more reverse-channel bandwidth. This is an area with considerable flexibility of design, and different approaches to backchannel messages and frequency are expected to be evaluated. 9. Flows managed by this algorithm and flows competing against at a bottleneck may have different DSCP[RFC5865] markings depending Jesup & Sarker Expires June 15, 2015 [Page 7] Internet-Draft RTP Media Congestion Control Requirements December 2014 on the type of traffic, or may be subject to flow-based QoS. A particular bottleneck or section of the network path may or may not honor DSCP markings. The algorithm should attempt to leverage DSCP markings when they're available. A. In WebRTC, a division of packets into 4 classes is envisioned in order of priority: faster-than-audio, audio, video, best-effort, and bulk-transfer. Typically the flows managed by this algorithm would be audio or video in that hierarchy, and feedback flows would be faster-than-audio. 10. The algorithm should sense the unexpected lack of backchannel information as a possible indication of a channel overuse problem and react accordingly to avoid burst events causing a congestion collapse. 11. The algorithm should be stable and maintain low-delay when faced with Active Queue Management (AQM) algorithms. Also note that these algorithms may apply across multiple queues in the bottleneck, or to a single queue 3. Deficiencies of existing mechanisms Among the existing congestion control mechanisms TCP Friendly Rate Control (TFRC) [RFC5348] is the one which claims to be suitable for real-time interactive media. TFRC is, an equation based, congestion control mechanism which provides reasonably fair share of the bandwidth when competing with TCP flows and offers much lower throughput variations than TCP. This is achieved by a slower response to the available bandwidth change than TCP. TFRC is designed to perform best with applications which has fixed packet size and does not have fixed period between sending packets. TFRC operates on detecting loss events and reacts to loss caused by congestion by reducing its sending rate. It allows applications to increase the sending rate until loss is observed in the flows. As it is noted in IAB/IRTF report [RFC7295] large buffers are available in the network elements which introduces additional delay in the communication, it becomes important to take all possible congestion indications into considerations. Looking at the current Internet deployment, TFRC's only consideration of loss events as congestion indication can be considered as biggest lacking. A typical real-time interactive communication includes live encoded audio and video flow(s). In such a communication scenario an audio source typically needs fixed interval between packets, needs to vary their segment size instead of their packet rate in response to congestion and sends smaller packets, a variant of TFRC , Small- Jesup & Sarker Expires June 15, 2015 [Page 8] Internet-Draft RTP Media Congestion Control Requirements December 2014 Packet TFRC (TFRC-SP) [RFC4828] addresses the issues related to such kind of sources ; a video source generally varies video frame sizes, can produce large frames which need to be further fragmented to fit into path Maximum Transmission Unit (MTU) size, and have almost fixed interval between producing frames under a certain frame rate, TFRC is known to be less optimal when using with such video sources. There are also some mismatches between TFRC's design assumptions and how the media sources in a typical real-time interactive application works. TFRC is design to maintain smooth sending rate however media sources can change rates in steps for both rate increase and rate decrease. TFRC can operate in two modes - i) Bytes per second and ii) packets per second, where typical real-time interactive media sources operates on bit per second. There are also limitations on how quickly the media sources can adapt to specific sending rates. The modern video encoders can operate on a mode where they can vary the output bitrate a lot depending on the way there are configured, the current scene it is encoding and more. Therefore, it is possible that the video source does not always output at a bitrate they are allowed to. TFRC tries to raise its sending rate when transmitting at maximum allowed rate and increases only twice the current transmission rate hence it may create issues when the video source vary their bitrates. Moreover, there are number of studies on TFRC which shows it's limitations which includes TFRC's unfairness on low statistically multiplexed links, oscillatory behavior, performance issue in highly dynamic loss rates conditions and more [CH09]. Looking at all these deficiencies it can be concluded that the requirements of congestion control mechanism for real-time interactive media cannot be met by TFRC as defined in the standard. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations An attacker with the ability to delete, delay or insert messages in the flow can fake congestion signals, unless they are passed on a tamper-proof path. Since some possible algorithms depend on the timing of packet arrival, even a traditional protected channel does not fully mitigate such attacks. Jesup & Sarker Expires June 15, 2015 [Page 9] Internet-Draft RTP Media Congestion Control Requirements December 2014 An attack that reduces bandwidth is not necessarily significant, since an on-path attacker could break the connection by discarding all packets. Attacks that increase the perceived available bandwidth are conceivable, and need to be evaluated. Such attacks could result in starvation of competing flows and permit amplification attacks. Algorithm designers should consider the possibility of malicious on- path attackers. 6. Acknowledgements This document is the result of discussions in various fora of the WebRTC effort, in particular on the rtp-congestion@alvestrand.no mailing list. Many people contributed their thoughts to this. 7. References 7.1. Normative References [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-13 (work in progress), November 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. 7.2. Informative References [CH09] Choi, S. and M. Handley, "Designing TCP-Friendly Window- based Congestion Control for Real-time Multimedia Applications", PFLDNeT 2009 Workshop , May 2009. Jesup & Sarker Expires June 15, 2015 [Page 10] Internet-Draft RTP Media Congestion Control Requirements December 2014 [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-08 (work in progress), December 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-12 (work in progress), September 2014. [MPEG_DASH] "Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", April 2012. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010. [RFC7295] Tschofenig, H., Eggert, L., and Z. Sarker, "Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication", RFC 7295, July 2014. Authors' Addresses Randell Jesup Mozilla USA Email: randell-ietf@jesup.org Jesup & Sarker Expires June 15, 2015 [Page 11] Internet-Draft RTP Media Congestion Control Requirements December 2014 Zaheduzzaman Sarker (editor) Ericsson Sweden Email: zaheduzzaman.sarker@ericsson.com Jesup & Sarker Expires June 15, 2015 [Page 12] ./draft-ietf-rtcweb-alpn-04.txt0000664000764400076440000003577312712725447015626 0ustar iustyiusty RTCWEB M. Thomson Internet-Draft Mozilla Intended status: Standards Track May 5, 2016 Expires: November 6, 2016 Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) draft-ietf-rtcweb-alpn-04 Abstract This document specifies two Application Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communications (WebRTC). The "webrtc" label identifies regular WebRTC communications: a DTLS session that is used establish keys for Secure Real-time Transport Protocol (SRTP) or to establish data channels using SCTP over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 6, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Thomson Expires November 6, 2016 [Page 1] Internet-Draft ALPN for WebRTC May 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2 3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses Datagram Transport Layer Security (DTLS) [RFC6347] to secure all peer-to-peer communications. Identifying WebRTC protocol usage with Application Layer Protocol Negotiation (ALPN) [RFC7301] enables an endpoint to positively identify WebRTC uses and distinguish them from other DTLS uses. Different WebRTC uses can be advertised and behavior can be constrained to what is appropriate to a given use. In particular, this allows for the identification of sessions that require confidentiality protection from the application that manages the signaling for the session. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. ALPN Labels for WebRTC The following identifiers are defined for use in ALPN: webrtc: The DTLS session is used to establish keys for Secure Real- time Transport Protocol (SRTP) - known as DTLS-SRTP - as described Thomson Expires November 6, 2016 [Page 2] Internet-Draft ALPN for WebRTC May 2016 in [RFC5764]. The DTLS record layer is used for WebRTC data channels [I-D.ietf-rtcweb-data-channel]. c-webrtc: The DTLS session is used for confidential WebRTC communications, where peers agree to maintain the confidentiality of the media, as described in Section 3. The confidentiality protections ensure that media is protected from other applications, but the confidentiality protections do not extend to messages on data channels. Both identifiers describe the same basic protocol: a DTLS session that is used to provide keys for an SRTP session in combination with WebRTC data channels. Either SRTP or data channels could be absent. The data channels send Stream Control Transmission Protocol (SCTP) [RFC4960] over the DTLS record layer, which can be multiplexed with SRTP on the same UDP flow. WebRTC requires the use of Interactive Communication Establishment (ICE) [RFC5245] to establish the UDP flow, but this is not covered by the identifier. A more thorough definition of what WebRTC communications entail is included in [I-D.ietf-rtcweb-transports]. There is no functional difference between the identifiers except that an endpoint negotiating "c-webrtc" makes a promise to preserve the confidentiality of the media it receives. A peer that is not aware of whether it needs to request confidentiality can use either identifier. A peer in the client role MUST offer both identifiers if it is not aware of a need for confidentiality. A peer in the server role SHOULD select "webrtc" if it does not prefer either. An endpoint that requires media confidentiality might negotiate a session with a peer that does not support this specification. Endpoint MUST abort a session if it requires confidentiality but does not successfully negotiate "c-webrtc". A peer that is willing to accept "webrtc" SHOULD assume that a peer that does not support this specification has negotiated "webrtc" unless signaling provides other information; however, a peer MUST NOT assume that "c-webrtc" has been negotiated unless explicitly negotiated. 3. Media Confidentiality Private communications in WebRTC depend on separating control (i.e., signaling) capabilities and access to media [I-D.ietf-rtcweb-security-arch]. In this way, an application can establish a session that is end-to-end confidential, where the ends in question are user agents (or browsers) and not the signaling Thomson Expires November 6, 2016 [Page 3] Internet-Draft ALPN for WebRTC May 2016 application. This allows an application to manage signaling for a session, without having access to the media that is exchanged in the session. Without some form of indication that is securely bound to the session, a WebRTC endpoint is unable to properly distinguish between a session that requires this confidentiality protection and one that does not. The ALPN identifier provides that signal. A browser is required to enforce this confidentiality protection using isolation controls similar to those used in content cross- origin protections (see Section 5.3 [1] of [HTML5]). These protections ensure that media is protected from applications. Applications are not able to read or modify the contents of a protected flow of media. Media that is produced from a session using the "c-webrtc" identifier MUST only be displayed to users. The promise to apply confidentiality protections do not apply to data that is sent using data channels. Confidential data depends on having both data sources and consumers that are exclusively browser- or user-based. No mechanisms currently exist to take advantage of data confidentiality, though some use cases suggest that this could be useful, for example, confidential peer-to-peer file transfer. Alternative labels might be provided in future to support these use cases. This mechanism explicitly does not define a specific authentication method; a WebRTC endpoint that accepts a session with this ALPN identifier MUST respect confidentiality no matter what identity is attributed to a peer. RTP middleboxes and entities that forward media or data cannot promise to maintain confidentiality. Any entity that forwards content, or records content for later access by entities other than the authenticated peer, MUST NOT offer or accept a session with the "c-webrtc" identifier. 4. Security Considerations Confidential communications depends on more than just an agreement from browsers. Information is not confidential if it is displayed to those other than to whom it is intended. Peer authentication [I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is only sent to the intended peer. Thomson Expires November 6, 2016 [Page 4] Internet-Draft ALPN for WebRTC May 2016 This is not a digital rights management mechanism. A user is not prevented from using other mechanisms to record or forward media. This means that (for example) screen recording devices, tape recorders, portable cameras, or a cunning arrangement of mirrors could variously be used to record or redistribute media once delivered. Similarly, if media is visible or audible (or otherwise accessible) to others in the vicinity, there are no technical measures that protect the confidentiality of that media. The only guarantee provided by this mechanism and the browser that implements it is that the media was delivered to the user that was authenticated. Individual users will still need to make a judgment about how their peer intends to respect the confidentiality of any information provided. On a shared computing platform like a browser, other entities with access to that platform (i.e., web applications), might be able to access information that would compromise the confidentiality of communications. Implementations MAY choose to limit concurrent access to input devices during confidential communications sessions. For instance, another application that is able to access a microphone might be able to sample confidential audio that is playing through speakers. This is true even if acoustic echo cancellation, which attempts to prevent this from happening, is used. Similarly, an application with access to a video camera might be able to use reflections to obtain all or part of a confidential video stream. 5. IANA Considerations The following two entries are added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]: webrtc: The "webrtc" label identifies mixed media and data communications using SRTP and data channels: Protocol: WebRTC Media and Data Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") Specification: This document (RFCXXXX) c-webrtc: Thomson Expires November 6, 2016 [Page 5] Internet-Draft ALPN for WebRTC May 2016 The "c-webrtc" label identifies WebRTC communications with a promise to protect media confidentiality: Protocol: Confidential WebRTC Media and Data Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 ("c-webrtc") Specification: This document (RFCXXXX) 6. References 6.1. Normative References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-11 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . 6.2. Informative References [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August 2010, . Thomson Expires November 6, 2016 [Page 6] Internet-Draft ALPN for WebRTC May 2016 [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-15 (work in progress), January 2016. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-12 (work in progress), March 2016. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . 6.3. URIs [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin Author's Address Martin Thomson Mozilla 331 E Evelyn Street Mountain View, CA 94041 US Email: martin.thomson@gmail.com Thomson Expires November 6, 2016 [Page 7] ./draft-ietf-rtcweb-data-channel-13.txt0000664000764400076440000010730512452275625017201 0ustar iustyiusty Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto Expires: July 8, 2015 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences January 4, 2015 WebRTC Data Channels draft-ietf-rtcweb-data-channel-13.txt Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies 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-browsers to exchange generic data from peer to peer. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 8, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Jesup, et al. Expires July 8, 2015 [Page 1] Internet-Draft WebRTC Data Channels January 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 4 3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 6 6. The Usage of SCTP for Data Channels . . . . . . . . . . . . . 8 6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8 6.2. SCTP Association Management . . . . . . . . . . . . . . . 9 6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Data Channel Definition . . . . . . . . . . . . . . . . . 10 6.5. Opening a Data Channel . . . . . . . . . . . . . . . . . 10 6.6. Transferring User Data on a Data Channel . . . . . . . . 11 6.7. Closing a Data Channel . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction In the WebRTC framework, communication between the parties consists of media (for example audio and video) and non-media data. Media is sent using SRTP, and is not specified further here. Non-media data is handled by using SCTP [RFC4960] encapsulated in DTLS. DTLS 1.0 is defined in [RFC4347] and the present latest version, DTLS 1.2, is defined in [RFC6347]. Jesup, et al. Expires July 8, 2015 [Page 2] Internet-Draft WebRTC Data Channels January 2015 +----------+ | SCTP | +----------+ | DTLS | +----------+ | ICE/UDP | +----------+ Figure 1: Basic stack diagram The encapsulation of SCTP over DTLS (see [I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245]) provides a NAT traversal solution together with confidentiality, source authentication, and integrity protected transfers. This data transport service operates in parallel to the SRTP media transports, and all of them can eventually share a single UDP port number. SCTP as specified in [RFC4960] with the partial reliability extension defined in [RFC3758] and the additional policies defined in [I-D.ietf-tsvwg-sctp-prpolicies] provides multiple streams natively with reliable, and the relevant partially-reliable delivery modes for user messages. Using the reconfiguration extension defined in [RFC6525] allows to increase the number of streams during the lifetime of an SCTP association and to reset individual SCTP streams. Using [I-D.ietf-tsvwg-sctp-ndata] allows to interleave large messages to avoid the monopolization and adds the support of prioritizing of SCTP streams. The remainder of this document is organized as follows: Section 3 and Section 4 provide use cases and requirements for both unreliable and reliable peer to peer data channels; Section 5 discusses SCTP over DTLS over UDP; Section 6 provides the specification of how SCTP should be used by the WebRTC protocol framework for transporting non- media data between WEB-browsers. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Use Cases This section defines use cases specific to data channels. Please note that this section is informational only. Jesup, et al. Expires July 8, 2015 [Page 3] Internet-Draft WebRTC Data Channels January 2015 3.1. Use Cases for Unreliable Data Channels U-C 1: A real-time game where position and object state information is sent via one or more unreliable data channels. Note that at any time there may be no SRTP media channels, or all SRTP media channels may be inactive, and that there may also be reliable data channels in use. U-C 2: Providing non-critical information to a user about the reason for a state update in a video chat or conference, such as mute state. 3.2. Use Cases for Reliable Data Channels U-C 3: A real-time game where critical state information needs to be transferred, such as control information. Such a game may have no SRTP media channels, or they may be inactive at any given time, or may only be added due to in-game actions. U-C 4: Non-realtime file transfers between people chatting. Note that this may involve a large number of files to transfer sequentially or in parallel, such as when sharing a folder of images or a directory of files. U-C 5: Realtime text chat during an audio and/or video call with an individual or with multiple people in a conference. U-C 6: Renegotiation of the configuration of the PeerConnection. U-C 7: Proxy browsing, where a browser uses data channels of a PeerConnection to send and receive HTTP/HTTPS requests and data, for example to avoid local Internet filtering or monitoring. 4. Requirements This section lists the requirements for P2P data channels between two browsers. Please note that this section is informational only. Req. 1: Multiple simultaneous data channels must be supported. Note that there may be 0 or more SRTP media streams in parallel with the data channels in the same PeerConnection, and the number and state (active/inactive) of these SRTP media streams may change at any time. Req. 2: Both reliable and unreliable data channels must be supported. Jesup, et al. Expires July 8, 2015 [Page 4] Internet-Draft WebRTC Data Channels January 2015 Req. 3: Data channels of a PeerConnection must be congestion controlled; either individually, as a class, or in conjunction with the SRTP media streams of the PeerConnection, to ensure that data channels don't cause congestion problems for these SRTP media streams, and that the WebRTC PeerConnection does not cause excessive problems when run in parallel with TCP connections. Req. 4: The application should be able to provide guidance as to the relative priority of each data channel relative to each other, and relative to the SRTP media streams. This will interact with the congestion control algorithms. Req. 5: Data channels must be secured; allowing for confidentiality, integrity and source authentication. See [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch] for detailed info. Req. 6: Data channels must provide message fragmentation support such that IP-layer fragmentation can be avoided no matter how large a message the JavaScript application passes to be sent. It also must ensure that large data channel transfers don't unduly delay traffic on other data channels. Req. 7: The data channel transport protocol must not encode local IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon. Req. 8: The data channel transport protocol should support unbounded-length "messages" (i.e., a virtual socket stream) at the application layer, for such things as image-file- transfer; Implementations might enforce a reasonable message size limit. Req. 9: The data channel transport protocol should avoid IP fragmentation. It must support PMTU (Path MTU) discovery and must not rely on ICMP or ICMPv6 being generated or being passed back, especially for PMTU discovery. Req. 10: It must be possible to implement the protocol stack in the user application space. Jesup, et al. Expires July 8, 2015 [Page 5] Internet-Draft WebRTC Data Channels January 2015 5. SCTP over DTLS over UDP Considerations The important features of SCTP in the WebRTC context are: o Usage of a TCP-friendly congestion control. o The congestion control is modifiable for integration with the SRTP media stream congestion control. o Support of multiple unidirectional streams, each providing its own notion of ordered message delivery. o Support of ordered and out-of-order message delivery. o Supporting arbitrary large user messages by providing fragmentation and reassembly. o Support of PMTU-discovery. o Support of reliable or partially reliable message transport. The WebRTC Data Channel mechanism does not support SCTP multihoming. The SCTP layer will simply act as if it were running on a single- homed host, since that is the abstraction that the DTLS layer (a connection oriented, unreliable datagram service) exposes. The encapsulation of SCTP over DTLS defined in [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source authenticated, and integrity protected transfers. Using DTLS over UDP in combination with ICE enables middlebox traversal in IPv4 and IPv6 based networks. SCTP as specified in [RFC4960] MUST be used in combination with the extension defined in [RFC3758] and provides the following features for transporting non-media data between browsers: o Support of multiple unidirectional streams. o Ordered and unordered delivery of user messages. o Reliable and partial-reliable transport of user messages. Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side. The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association. In the WebRTC context, the PPID is used to distinguish between UTF-8 encoded user data, binary encoded userdata and the Data Channel Establishment Protocol defined in Jesup, et al. Expires July 8, 2015 [Page 6] Internet-Draft WebRTC Data Channels January 2015 [I-D.ietf-rtcweb-data-protocol]. Please note that the PPID is not accessible via the Javascript API. The encapsulation of SCTP over DTLS, together with the SCTP features listed above satisfies all the requirements listed in Section 4. The layering of protocols for WebRTC is shown in the following Figure 2. +------+------+------+ | DCEP | UTF-8|Binary| | | data | data | +------+------+------+ | SCTP | +----------------------------------+ | STUN | SRTP | DTLS | +----------------------------------+ | ICE | +----------------------------------+ | UDP1 | UDP2 | UDP3 | ... | +----------------------------------+ Figure 2: WebRTC protocol layers This stack (especially in contrast to DTLS over SCTP [RFC6083] in combination with SCTP over UDP [RFC6951]) has been chosen because it o supports the transmission of arbitrary large user messages. o shares the DTLS connection with the SRTP media channels of the PeerConnection. o provides privacy for the SCTP control information. Considering the protocol stack of Figure 2 the usage of DTLS 1.0 over UDP is specified in [RFC4347] and the usage of DTLS 1.2 over UDP in specified in [RFC6347], while the usage of SCTP on top of DTLS is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. Please note that the demultiplexing STUN vs. SRTP vs. DTLS is done as described in Section 5.1.2 of [RFC5764] and SCTP is the only payload of DTLS. Since DTLS is typically implemented in user application space, the SCTP stack also needs to be a user application space stack. The ICE/UDP layer can handle IP address changes during a session without needing interaction with the DTLS and SCTP layers. However, SCTP SHOULD be notified when an address changes has happened. In this case SCTP SHOULD retest the Path MTU and reset the congestion Jesup, et al. Expires July 8, 2015 [Page 7] Internet-Draft WebRTC Data Channels January 2015 state to the initial state. In case of a window based congestion control like the one specified in [RFC4960], this means setting the congestion window and slow start threshold to its initial values. Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] using probing messages specified in [RFC4820]. The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for IPv6. In general, the lower layer interface of an SCTP implementation should be adapted to address the differences between IPv4 and IPv6 (being connection-less) or DTLS (being connection-oriented). When the protocol stack of Figure 2 is used, DTLS protects the complete SCTP packet, so it provides confidentiality, integrity and source authentication of the complete SCTP packet. SCTP provides congestion control on a per-association base. This means that all SCTP streams within a single SCTP association share the same congestion window. Traffic not being sent over SCTP is not covered by the SCTP congestion control. Using a congestion control different from than the standard one might improve the impact on the parallel SRTP media streams. SCTP uses the same port number concept as TCP and UDP do. Therefore an SCTP association uses two port numbers, one at each SCTP end- point. 6. The Usage of SCTP for Data Channels 6.1. SCTP Protocol Considerations The DTLS encapsulation of SCTP packets as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. This SCTP stack and its upper layer MUST support the usage of multiple SCTP streams. A user message can be sent ordered or unordered and with partial or full reliability. The following SCTP protocol extensions are required: o The stream reconfiguration extension defined in [RFC6525] MUST be supported. It is used for closing channels. Jesup, et al. Expires July 8, 2015 [Page 8] Internet-Draft WebRTC Data Channels January 2015 o The dynamic address reconfiguration extension defined in [RFC5061] MUST be used to signal the support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL. o The partial reliability extension defined in [RFC3758] MUST be supported. In addition to the timed reliability PR-SCTP policy defined in [RFC3758], the limited retransmission policy defined in [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. Limiting the number of retransmissions to zero combined with unordered delivery provides a UDP-like service where each user message is sent exactly once and delivered in the order received. The support for message interleaving as defined in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used. 6.2. SCTP Association Management In the WebRTC context, the SCTP association will be set up when the two endpoints of the WebRTC PeerConnection agree on opening it, as negotiated by JSEP (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. It will use the DTLS connection selected via ICE; typically this will be shared via BUNDLE or equivalent with DTLS connections used to key the SRTP media streams. The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during the association setup. SCTP supports two ways of terminating an SCTP association. A graceful one, using a procedure which ensures that no messages are lost during the shutdown of the association. The second method is a non-graceful one, where one side can just abort the association. Each SCTP end-point supervises continuously the reachability of its peer by monitoring the number of retransmissions of user messages and test messages. In case of excessive retransmissions, the association is terminated in a non-graceful way. If an SCTP association is closed in a graceful way, all of its data channels are closed. In case of a non-graceful teardown, all data channels are also closed, but an error indication SHOULD be provided if possible. 6.3. SCTP Streams SCTP defines a stream as a unidirectional logical channel existing within an SCTP association to another SCTP endpoint. The streams are used to provide the notion of in-sequence delivery and for Jesup, et al. Expires July 8, 2015 [Page 9] Internet-Draft WebRTC Data Channels January 2015 multiplexing. Each user message is sent on a particular stream, either ordered or unordered. Ordering is preserved only for ordered messages sent on the same stream. 6.4. Data Channel Definition Data channels are defined such that their accompanying application- level API can closely mirror the API for WebSockets, which implies bidirectional streams of data and a textual field called 'label' used to identify the meaning of the data channel. The realization of a data channel is a pair of one incoming stream and one outgoing SCTP stream having the same SCTP stream identifier. How these SCTP stream identifiers are selected is protocol and implementation dependent. This allows a bidirectional communication. Additionally, each data channel has the following properties in each direction: o reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream. o in-order or out-of-order message delivery for message sent. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream. o A priority, which is a 2 byte unsigned integer. These priorities MUST be interpreted as weighted-fair-queuing scheduling priorities per the definition of the corresponding stream scheduler supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high") or 1024 ("extra high"). o an optional label. o an optional protocol. Please note that for a data channel being negotiated with the protocol specified in [I-D.ietf-rtcweb-data-protocol] all of the above properties are the same in both directions. 6.5. Opening a Data Channel Data channels can be opened by using negotiation within the SCTP association, called in-band negotiation, or out-of-band negotiation. Out-of-band negotiation is defined as any method which results in an Jesup, et al. Expires July 8, 2015 [Page 10] Internet-Draft WebRTC Data Channels January 2015 agreement as to the parameters of a channel and the creation thereof. The details are out of scope of this document. Applications using data channels need to use the negotiation methods consistently on both end-points. A simple protocol for in-band negotiation is specified in [I-D.ietf-rtcweb-data-protocol]. When one side wants to open a channel using out-of-band negotiation, it picks a stream. Unless otherwise defined or negotiated, the streams are picked based on the DTLS role (the client picks even stream identifiers, the server odd stream identifiers). However, the application is responsible for avoiding collisions with existing streams. If it attempts to re-use a stream which is part of an existing data channel, the addition MUST fail. In addition to choosing a stream, the application SHOULD also determine the options to use for sending messages. The application MUST ensure in an application-specific manner that the application at the peer will also know the selected stream to be used, and the options for sending data from that side. 6.6. Transferring User Data on a Data Channel All data sent on a data channel in both directions MUST be sent over the underlying stream using the reliability defined when the data channel was opened unless the options are changed, or per-message options are specified by a higher level. The message-orientation of SCTP is used to preserve the message boundaries of user messages. Therefore, senders MUST NOT put more than one application message into an SCTP user message. Unless the deprecated PPID-based fragmentation and reassembly is used, the sender MUST include exactly one application message in each SCTP user message. The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the interpretation of the "Payload data". The following PPIDs MUST be used (see Section 8): WebRTC String: to identify a non-empty JavaScript string encoded in UTF-8. WebRTC String Empty: to identify an empty JavaScript string encoded in UTF-8. WebRTC Binary: to identify a non-empty JavaScript binary data (ArrayBuffer, ArrayBufferView or Blob). Jesup, et al. Expires July 8, 2015 [Page 11] Internet-Draft WebRTC Data Channels January 2015 WebRTC Binary Empty: to identify an empty JavaScript binary data (ArrayBuffer, ArrayBufferView or Blob). SCTP does not support the sending of empty user messages. Therefore, if an empty message has to be sent, the appropriate PPID (WebRTC String Empty or WebRTC Binary Empty) is used and the SCTP user message of one zero byte is sent. When receiving an SCTP user message with one of these PPIDs, the receiver MUST ignore the SCTP user message and process it as an empty message. The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is deprecated. They were used for a PPID-based fragmentation and reassembly of user messages belonging to reliable and ordered data channels. If a message with an unsupported PPID is received or some error condition related to the received message is detected by the receiver (for example, illegal ordering), the receiver SHOULD close the corresponding data channel. This implies in particular that extensions using additional PPIDs can't be used without prior negotiation. The SCTP base protocol specified in [RFC4960] does not support the interleaving of user messages. Therefore sending a large user message can monopolize the SCTP association. To overcome this limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to support message interleaving, which SHOULD be used. As long as message interleaving is not supported, the sender SHOULD limit the maximum message size to 16 KB to avoid monopolization. It is recommended that the message size be kept within certain size bounds as applications will not be able to support arbitrarily-large single messages. This limit has to be negotiated, for example by using [I-D.ietf-mmusic-sctp-sdp]. The sender SHOULD disable the Nagle algorithm (see [RFC1122]) to minimize the latency. 6.7. Closing a Data Channel Closing of a data channel MUST be signaled by resetting the corresponding outgoing streams [RFC6525]. This means that if one side decides to close the data channel, it resets the corresponding outgoing stream. When the peer sees that an incoming stream was reset, it also resets its corresponding outgoing stream. Once this is completed, the data channel is closed. Resetting a stream sets the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with a corresponding notification to the application layer that the reset Jesup, et al. Expires July 8, 2015 [Page 12] Internet-Draft WebRTC Data Channels January 2015 has been performed. Streams are available for reuse after a reset has been performed. [RFC6525] also guarantees that all the messages are delivered (or abandoned) before the stream is reset. 7. Security Considerations This document does not add any additional considerations to the ones given in [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. It should be noted that a receiver must be prepared that the sender tries to send arbitrary large messages. 8. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] This document uses six already registered SCTP Payload Protocol Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary Data Last", "DOMString Partial", "WebRTC String Empty", and "WebRTC Binary Empty". [RFC4960] creates the registry "SCTP Payload Protocol Identifiers" from which these identifiers were assigned. IANA is requested to update the reference of these six assignments to point to this document and change the names of the first four PPIDs. The corresponding dates should be kept. Therefore these six assignments should be updated to read: +-------------------------------+----------+-----------+------------+ | Value | SCTP | Reference | Date | | | PPID | | | +-------------------------------+----------+-----------+------------+ | WebRTC String | 51 | [RFCXXXX] | 2013-09-20 | | WebRTC Binary Partial | 52 | [RFCXXXX] | 2013-09-20 | | (Deprecated) | | | | | WebRTC Binary | 53 | [RFCXXXX] | 2013-09-20 | | WebRTC String Partial | 54 | [RFCXXXX] | 2013-09-20 | | (Deprecated) | | | | | WebRTC String Empty | 56 | [RFCXXXX] | 2014-08-22 | | WebRTC Binary Empty | 57 | [RFCXXXX] | 2014-08-22 | +-------------------------------+----------+-----------+------------+ Jesup, et al. Expires July 8, 2015 [Page 13] Internet-Draft WebRTC Data Channels January 2015 9. Acknowledgments Many thanks for comments, ideas, and text from Harald Alvestrand, Richard Barnes, Adam Bergkvist, Alissa Cooper, Benoit Claise, Spencer Dawkins, Gunnar Hellstrom, Christer Holmberg, Cullen Jennings, Paul Kyzivat, Eric Rescorla, Adam Roach, Irene Ruengeler, Randall Stewart, Martin Stiemerling, Justin Uberti, and Magnus Westerlund. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012. Jesup, et al. Expires July 8, 2015 [Page 14] Internet-Draft WebRTC Data Channels January 2015 [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and a New Data Chunk for the Stream Control Transmission Protocol", draft-ietf-tsvwg-sctp- ndata-01 (work in progress), July 2014. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-08 (work in progress), September 2014. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-07 (work in progress), December 2014. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-07 (work in progress), July 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-10 (work in progress), July 2014. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 (work in progress), October 2014. [I-D.ietf-tsvwg-sctp-prpolicies] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol", draft-ietf- tsvwg-sctp-prpolicies-06 (work in progress), December 2014. [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Loreto, S., and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf- mmusic-sctp-sdp-11 (work in progress), December 2014. 10.2. Informative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. Jesup, et al. Expires July 8, 2015 [Page 15] Internet-Draft WebRTC Data Channels January 2015 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011. [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, May 2013. Authors' Addresses Randell Jesup Mozilla US Email: randell-ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 FI Email: salvatore.loreto@ericsson.com Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 DE Email: tuexen@fh-muenster.de Jesup, et al. Expires July 8, 2015 [Page 16] ./draft-ietf-rtcweb-data-protocol-09.txt0000664000764400076440000006737312452275542017447 0ustar iustyiusty Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto Expires: July 8, 2015 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences January 4, 2015 WebRTC Data Channel Establishment Protocol draft-ietf-rtcweb-data-protocol-09.txt Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric Data Channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 8, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Jesup, et al. Expires July 8, 2015 [Page 1] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 8.2. New Standalone Registry for the DCEP . . . . . . . . . . 9 8.2.1. New Message Type Registry . . . . . . . . . . . . . . 9 8.2.2. New Channel Type Registry . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informational References . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Data Channel Establishment Protocol (DCEP) is designed to provide, in the WebRTC Data Channel context [I-D.ietf-rtcweb-data-channel], a simple in-band method to open symmetric Data Channels. As discussed in [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transport Layer Security (DTLS) as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already standardized transport and security features. DTLS 1.0 is defined in [RFC4347] and the present latest version, DTLS 1.2, is defined in [RFC6347]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Jesup, et al. Expires July 8, 2015 [Page 2] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 3. Terminology This document uses the following terms: Association: An SCTP association. Stream: A unidirectional stream of an SCTP association. It is uniquely identified by an SCTP stream identifier (0-65534). Note: the SCTP stream identifier 65535 is reserved due to SCTP INIT and INIT-ACK chunks only allowing a maximum of 65535 Streams to be negotiated (0-65534). Stream Identifier: The SCTP stream identifier uniquely identifying a Stream. Data Channel: Two Streams with the same Stream Identifier, one in each direction, which are managed together. 4. Protocol Overview The Data Channel Establishment Protocol is a simple, low-overhead way to establish bidirectional Data Channels over an SCTP association with a consistent set of properties. The set of consistent properties includes: o reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used. o in-order or out-of-order message delivery. o the priority of the Data Channel. o an optional label for the Data Channel. o an optional protocol for the Data Channel. o the Streams. This protocol uses a two way handshake to open a Data Channel. The handshake pairs one incoming and one outgoing Stream, both having the same Stream Identifier, into a single bidirectional Data Channel. The peer that initiates opening a Data Channel selects a Stream Identifier for which the corresponding incoming and outgoing Streams are unused and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The peer responds with a DATA_CHANNEL_ACK message on its corresponding outgoing Stream. Then the Data Channel is open. Data Channel Establishment Protocol messages are sent on the same Stream Jesup, et al. Expires July 8, 2015 [Page 3] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 as the user messages belonging to the Data Channel. The demultiplexing is based on the SCTP payload protocol identifier (PPID), since the Data Channel Establishment Protocol uses a specific PPID. Note: The opening side MAY send user messages before the DATA_CHANNEL_ACK is received. To avoid collisions where both sides try to open a Data Channel with the same Stream Identifiers, each side MUST use Streams with either even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN message. When using SCTP over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which side uses odd or even is based on the underlying DTLS connection role: the side acting as the DTLS client MUST use Streams with even Stream Identifiers, the side acting as the DTLS server MUST use Streams with odd Stream Identifiers. Note: There is no attempt to ensure uniqueness for the label; if both sides open a Data Channel labeled "x" at the same time, there will be two Data Channels labeled "x" - one on an even Stream pair, one on an odd pair. The protocol field is to ease cross-application interoperation ("federation") by identifying the user data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in [RFC6455]), and may be useful for homogeneous applications which may create more than one type of Data Channel. Please note that there is also no attempt to ensure uniqueness for the protocol field. 5. Message Formats Every Data Channel Establishment Protocol message starts with a one byte field called "Message Type" which indicates the type of the message. The corresponding values are managed by IANA (see Section 8.2.1). 5.1. DATA_CHANNEL_OPEN Message This message is sent initially on the Stream used for user messages using the Data Channel. Jesup, et al. Expires July 8, 2015 [Page 4] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Channel Type | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliability Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Length | Protocol Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Label | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Protocol | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the DATA_CHANNEL_OPEN message. The value of this field is 0x03 as specified in Section 8.2.1. Channel Type: 1 byte (unsigned integer) This field specifies the type of the Data Channel to be opened and the values are managed by IANA (see Section 8.2.2): DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a reliable in-order bi-directional communication. DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides a reliable unordered bi-directional communication. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel provides a partially-reliable in-order bi-directional communication. User messages will not be retransmitted more times than specified in the Reliability Parameter. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The Data Channel provides a partial reliable unordered bi-directional communication. User messages will not be retransmitted more times than specified in the Reliability Parameter. DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The Data Channel provides a partial reliable in-order bi-directional communication. User messages might not be transmitted or retransmitted after a specified life-time given in milli- Jesup, et al. Expires July 8, 2015 [Page 5] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 seconds in the Reliability Parameter. This life-time starts when providing the user message to the protocol stack. DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The Data Channel provides a partial reliable unordered bi-directional communication. User messages might not be transmitted or retransmitted after a specified life-time given in milli- seconds in the Reliability Parameter. This life-time starts when providing the user message to the protocol stack. Priority: 2 bytes (unsigned integer) The priority of the Data Channel as described in [I-D.ietf-rtcweb-data-channel]. Reliability Parameter: 4 bytes (unsigned integer) For reliable Data Channels this field MUST be set to 0 on the sending side and MUST be ignored on the receiving side. If a partial reliable Data Channel with limited number of retransmissions is used, this field specifies the number of retransmissions. If a partial reliable Data Channel with limited lifetime is used, this field specifies the maximum lifetime in milliseconds. The following table summarizes this: +------------------------------------------------+------------------+ | Channel Type | Reliability | | | Parameter | +------------------------------------------------+------------------+ | DATA_CHANNEL_RELIABLE | Ignored | | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms | +------------------------------------------------+------------------+ Label Length: 2 bytes (unsigned integer) The length of the label field in bytes. Protocol Length: 2 bytes (unsigned integer) The length of the protocol field in bytes. Label: Variable Length (sequence of characters) The name of the Data Channel as a UTF-8 encoded string as specified in [RFC3629]. This may be an empty string. Protocol: Variable Length (sequence of characters) If this is an empty string the protocol is unspecified. If it is a non-empty string, it specifies a protocol registered in the Jesup, et al. Expires July 8, 2015 [Page 6] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 'WebSocket Subprotocol Name Registry' created in [RFC6455]. This string is UTF-8 encoded as specified in [RFC3629]. 5.2. DATA_CHANNEL_ACK Message This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE message on the stream used for user messages using the Data Channel. Reception of this message tells the opener that the Data Channel setup handshake is complete. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the DATA_CHANNEL_ACK message. The value of this field is 0x02 as specified in Section 8.2.1. 6. Procedures All Data Channel Establishment Protocol messages MUST be sent using ordered delivery and reliable transmission. They MUST be sent on the same outgoing Stream as the user messages belonging to the corresponding Data Channel. Multiplexing and demultiplexing is done by using the SCTP payload protocol identifier (PPID). Therefore Data Channel Establishment Protocol message MUST be sent with the assigned PPID for the Data Channel Establishment Protocol (see Section 8.1). Other messages MUST NOT be sent using this PPID. The peer that initiates opening a Data Channel selects a Stream Identifier for which the corresponding incoming and outgoing Streams are unused. If the side is the DTLS client, it MUST choose an even Stream Identifier, if the side is the DTLS server, it MUST choose an odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on the chosen Stream. If a DATA_CHANNEL_OPEN message is received on an unused Stream, the Stream Identifier corresponds to the role of the peer and all parameters in the DATA_CHANNEL_OPEN message are valid, then a corresponding DATA_CHANNEL_ACK message is sent on the Stream with the same Stream Identifier as the one the DATA_CHANNEL_OPEN message was received on. If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for instance if a DATA_CHANNEL_OPEN message is received on an Jesup, et al. Expires July 8, 2015 [Page 7] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 already used Stream or there are any problems with parameters within the DATA_CHANNEL_OPEN message, the odd/even rule is violated or the DATA_CHANNEL_OPEN message itself is not well-formed, the receiver MUST close the corresponding Data Channel using the procedure described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a DATA_CHANNEL_ACK message in response to the received message. Therefore, receiving an SCTP stream reset request for a Stream on which no DATA_CHANNEL_ACK message has been received indicates to the sender of the corresponding DATA_CHANNEL_OPEN message the failure of the Data Channel setup procedure. After also successfully resetting the corresponding outgoing Stream, which concludes the Data Channel closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be sent on the Stream. After the DATA_CHANNEL_OPEN message has been sent, the sender of the DATA_CHANNEL_OPEN MAY start sending messages containing user data without waiting for the reception of the corresponding DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK message or any other message has been received on a Data Channel, all other messages containing user data and belonging to this Data Channel MUST be sent ordered, no matter whether the Data Channel is ordered or not. After the DATA_CHANNEL_ACK or any other message has been received on the Data Channel, messages containing user data MUST be sent ordered on ordered Data Channels and MUST be sent unordered on unordered Data Channels. Therefore receiving a message containing user data on an unused Stream indicates an error. The corresponding Data Channel MUST be closed as described in [I-D.ietf-rtcweb-data-channel]. 7. Security Considerations The DATA_CHANNEL_OPEN messages contains two variable length fields: the protocol and the label. A receiver must be prepared to receive DATA_CHANNEL_OPEN messages where these field have the maximum length of 65535 bytes. Error cases like the use of inconsistent lengths fields, unknown parameter values or violation the odd/even rule must also be handled by closing the corresponding Data Channel. An end- point must also be prepared that the peer open the maximum number of Data Channels. This protocol does not provide privacy, integrity or authentication. It needs to be used as part of a protocol suite that contains all these things. Such a protocol suite is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. For general considerations see [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. Jesup, et al. Expires July 8, 2015 [Page 8] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 8. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] IANA is asked to update the reference of an already existing SCTP PPID assignment (Section 8.1) and to create a new standalone registry with its own URL for the DCEP (Section 8.2) containing two new registration tables (Section 8.2.1 and Section 8.2.2). 8.1. SCTP Payload Protocol Identifier This document uses one already registered SCTP Payload Protocol Identifier (PPID) named "WebRTC Control". [RFC4960] creates the registry "SCTP Payload Protocol Identifiers" from which this identifier was assigned. IANA is requested to update the reference of this assignment to point to this document and to update the name. The corresponding date should be kept. Therefore this assignment should be updated to read: +-------------+-----------+-----------+------------+ | Value | SCTP PPID | Reference | Date | +-------------+-----------+-----------+------------+ | WebRTC DCEP | 50 | [RFCXXXX] | 2013-09-20 | +-------------+-----------+-----------+------------+ 8.2. New Standalone Registry for the DCEP IANA is requested to create a new standalone registry (aka a webpage) with its own URL for the Data Channel Establishment Protocol (DCEP). The title should be "Data Channel Establishment Protocol (DCEP) Parameters". It will contain the two tables as described in Section 8.2.1 and Section 8.2.2. 8.2.1. New Message Type Registry IANA is requested to create a new registration table "Message Type Registry" for the Data Channel Establishment Protocol (DCEP) to manage the one byte "Message Type" field in DCEP messages (see Section 5). This registration table should be part of the registry described in Section 8.2. Jesup, et al. Expires July 8, 2015 [Page 9] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new message type MUST contain the following information: 1. A name for the new message type; 2. A detailed procedural description of the use of messages with the new type within the operation of the Data Channel Establishment Protocol. Initially the following values need to be registered: +-------------------+-----------+-----------+ | Name | Type | Reference | +-------------------+-----------+-----------+ | Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] | | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | | Unassigned | 0x04-0xfe | | | Reserved | 0xff | [RFCXXXX] | +-------------------+-----------+-----------+ Please note that the values 0x00 and 0x01 are reserved to avoid interoperability problems, since they have been used in earlier versions of the document. The value 0xff has been reserved for future extensibility. The range of possible values is from 0x00 to 0xff. 8.2.2. New Channel Type Registry IANA is requested to create a new registration table "Channel Type Registry" for the Data Channel Establishment Protocol to manage the one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). This registration table should be part of the registry described in Section 8.2. The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new Channel Type MUST contain the following information: 1. A name for the new Channel Type; 2. A detailed procedural description of the user message handling for Data Channels using this new Channel Type. Jesup, et al. Expires July 8, 2015 [Page 10] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 Please note that if new Channel Types support ordered and unordered message delivery, the high order bit MUST be used to indicate whether the message delivery is unordered or not. Initially the following values need to be registered: +------------------------------------------------+------+-----------+ | Name | Type | Reference | +------------------------------------------------+------+-----------+ | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | | Reserved | 0x7f | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] | | Unassigned | rest | | +------------------------------------------------+------+-----------+ Please note that the values 0x7f and 0xff have been reserved for future extensibility. The range of possible values is from 0x00 to 0xff. 9. Acknowledgments The authors wish to thank Harald Alvestrand, Richard Barnes, Adam Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick, Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson, Justin Uberti, and many others for their invaluable comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. Jesup, et al. Expires July 8, 2015 [Page 11] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-07 (work in progress), December 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-12 (work in progress), September 2014. 10.2. Informational References [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-07 (work in progress), July 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-10 (work in progress), July 2014. Authors' Addresses Randell Jesup Mozilla US Email: randell-ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 FI Email: salvatore.loreto@ericsson.com Jesup, et al. Expires July 8, 2015 [Page 12] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 DE Email: tuexen@fh-muenster.de Jesup, et al. Expires July 8, 2015 [Page 13] ./draft-ietf-rtcweb-rtp-usage-26.txt0000664000764400076440000036701212672545755016610 0ustar iustyiusty RTCWEB Working Group C. Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: September 18, 2016 Ericsson J. Ott Aalto University March 17, 2016 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP draft-ietf-rtcweb-rtp-usage-26 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 18, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Perkins, et al. Expires September 18, 2016 [Page 1] Internet-Draft RTP for WebRTC March 2016 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 10 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 12 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12 4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13 5.1. Conferencing Extensions and Topologies . . . . . . . . . 14 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 16 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18 5.2.4. Media Stream Identification . . . . . . . . . . . . . 18 5.2.5. Coordination of Video Orientation . . . . . . . . . . 18 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 19 6.1. Negative Acknowledgements and RTP Retransmission . . . . 19 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21 7.2. Congestion Control Interoperability and Legacy Systems . 22 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25 12. RTP Implementation Considerations . . . . . . . . . . . . . . 27 Perkins, et al. Expires September 18, 2016 [Page 2] Internet-Draft RTP for WebRTC March 2016 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27 12.1.1. Use of Multiple Media Sources Within an RTP Session 27 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28 12.1.3. Differentiated Treatment of RTP Streams . . . . . . 33 12.2. Media Source, RTP Streams, and Participant Identification . . . . . . . . . . . . . . . . . . . . . 35 12.2.1. Media Source Identification . . . . . . . . . . . . 35 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36 12.2.3. Media Synchronisation Context . . . . . . . . . . . 37 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.2. Informative References . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] provides a framework for delivery of audio and video teleconferencing data and other real- time media applications. Previous work has defined the RTP protocol, along with numerous profiles, payload formats, and other extensions. When combined with appropriate signalling, these form the basis for many teleconferencing systems. The Web Real-Time communication (WebRTC) framework provides the protocol building blocks to support direct, interactive, real-time communication using audio, video, collaboration, games, etc., between two peers' web-browsers. This memo describes how the RTP framework is to be used in the WebRTC context. It proposes a baseline set of RTP features that are to be implemented by all WebRTC Endpoints, along with suggested extensions for enhanced functionality. This memo specifies a protocol intended for use within the WebRTC framework, but is not restricted to that context. An overview of the WebRTC framework is given in [I-D.ietf-rtcweb-overview]. The structure of this memo is as follows. Section 2 outlines our rationale in preparing this memo and choosing these RTP features. Section 3 defines terminology. Requirements for core RTP protocols are described in Section 4 and suggested RTP extensions are described in Section 5. Section 6 outlines mechanisms that can increase robustness to network problems, while Section 7 describes congestion control and rate adaptation mechanisms. The discussion of mandated RTP mechanisms concludes in Section 8 with a review of performance monitoring and network management tools. Section 9 gives some guidelines for future incorporation of other RTP and RTP Control Perkins, et al. Expires September 18, 2016 [Page 3] Internet-Draft RTP for WebRTC March 2016 Protocol (RTCP) extensions into this framework. Section 10 describes requirements placed on the signalling channel. Section 11 discusses the relationship between features of the RTP framework and the WebRTC application programming interface (API), and Section 12 discusses RTP implementation considerations. The memo concludes with security considerations (Section 13) and IANA considerations (Section 14). 2. Rationale The RTP framework comprises the RTP data transfer protocol, the RTP control protocol, and numerous RTP payload formats, profiles, and extensions. This range of add-ons has allowed RTP to meet various needs that were not envisaged by the original protocol designers, and to support many new media encodings, but raises the question of what extensions are to be supported by new implementations. The development of the WebRTC framework provides an opportunity to review the available RTP features and extensions, and to define a common baseline RTP feature set for all WebRTC Endpoints. This builds on the past 20 years of RTP development to mandate the use of extensions that have shown widespread utility, while still remaining compatible with the wide installed base of RTP implementations where possible. RTP and RTCP extensions that are not discussed in this document can be implemented by WebRTC Endpoints if they are beneficial for new use cases. However, they are not necessary to address the WebRTC use cases and requirements identified in [RFC7478]. While the baseline set of RTP features and extensions defined in this memo is targeted at the requirements of the WebRTC framework, it is expected to be broadly useful for other conferencing-related uses of RTP. In particular, it is likely that this set of RTP features and extensions will be appropriate for other desktop or mobile video conferencing systems, or for room-based high-quality telepresence applications. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The RFC 2119 interpretation of these key words applies only when written in ALL CAPS. Lower- or mixed-case uses of these key words are not to be interpreted as carrying special significance in this memo. We define the following additional terms: Perkins, et al. Expires September 18, 2016 [Page 4] Internet-Draft RTP for WebRTC March 2016 WebRTC MediaStream: The MediaStream concept defined by the W3C in the WebRTC API [W3C.WD-mediacapture-streams-20130903]. A MediaStream consists of zero or more MediaStreamTracks. MediaStreamTrack: Part of the MediaStream concept defined by the W3C in the WebRTC API [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is an individual stream of media from any type of media source like a microphone or a camera, but also conceptual sources, like a audio mix or a video composition, are possible. Transport-layer Flow: A uni-directional flow of transport packets that are identified by having a particular 5-tuple of source IP address, source port, destination IP address, destination port, and transport protocol used. Bi-directional Transport-layer Flow: A bi-directional transport- layer flow is a transport-layer flow that is symmetric. That is, the transport-layer flow in the reverse direction has a 5-tuple where the source and destination address and ports are swapped compared to the forward path transport-layer flow, and the transport protocol is the same. This document uses the terminology from [I-D.ietf-avtext-rtp-grouping-taxonomy] and [I-D.ietf-rtcweb-overview]. Other terms are used according to their definitions from the RTP Specification [RFC3550]. Especially note the following frequently used terms: RTP Stream, RTP Session, and Endpoint. 4. WebRTC Use of RTP: Core Protocols The following sections describe the core features of RTP and RTCP that need to be implemented, along with the mandated RTP profiles. Also described are the core extensions providing essential features that all WebRTC Endpoints need to implement to function effectively on today's networks. 4.1. RTP and RTCP The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be implemented as the media transport protocol for WebRTC. RTP itself comprises two parts: the RTP data transfer protocol, and the RTP control protocol (RTCP). RTCP is a fundamental and integral part of RTP, and MUST be implemented and used in all WebRTC Endpoints. The following RTP and RTCP features are sometimes omitted in limited functionality implementations of RTP, but are REQUIRED in all WebRTC Endpoints: Perkins, et al. Expires September 18, 2016 [Page 5] Internet-Draft RTP for WebRTC March 2016 o Support for use of multiple simultaneous SSRC values in a single RTP session, including support for RTP endpoints that send many SSRC values simultaneously, following [RFC3550] and [I-D.ietf-avtcore-rtp-multi-stream]. The RTCP optimisations for multi-SSRC sessions defined in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] MAY be supported; if supported the usage MUST be signalled. o Random choice of SSRC on joining a session; collision detection and resolution for SSRC values (see also Section 4.8). o Support for reception of RTP data packets containing CSRC lists, as generated by RTP mixers, and RTCP packets relating to CSRCs. o Sending correct synchronisation information in the RTCP Sender Reports, to allow receivers to implement lip-synchronisation; see Section 5.2.1 regarding support for the rapid RTP synchronisation extensions. o Support for multiple synchronisation contexts. Participants that send multiple simultaneous RTP packet streams SHOULD do so as part of a single synchronisation context, using a single RTCP CNAME for all streams and allowing receivers to play the streams out in a synchronised manner. For compatibility with potential future versions of this specification, or for interoperability with non- WebRTC devices through a gateway, receivers MUST support multiple synchronisation contexts, indicated by the use of multiple RTCP CNAMEs in an RTP session. This specification mandates the usage of a single CNAME when sending RTP Streams in some circumstances, see Section 4.9. o Support for sending and receiving RTCP SR, RR, SDES, and BYE packet types. Note that support for other RTCP packet types is OPTIONAL, unless mandated by other parts of this specification. Note that additional RTCP Packet types are used by the RTP/SAVPF Profile (Section 4.2) and the other RTCP extensions (Section 5). WebRTC endpoints that implement the SDP bundle negotiation extension will use the SDP grouping framework 'mid' attribute to identify media streams. Such endpoints MUST implement the RTCP SDES MID item described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. o Support for multiple endpoints in a single RTP session, and for scaling the RTCP transmission interval according to the number of participants in the session; support for randomised RTCP transmission intervals to avoid synchronisation of RTCP reports; support for RTCP timer reconsideration (Section 6.3.6 of Perkins, et al. Expires September 18, 2016 [Page 6] Internet-Draft RTP for WebRTC March 2016 [RFC3550]) and reverse reconsideration (Section 6.3.4 of [RFC3550]). o Support for configuring the RTCP bandwidth as a fraction of the media bandwidth, and for configuring the fraction of the RTCP bandwidth allocated to senders, e.g., using the SDP "b=" line [RFC4566][RFC3556]. o Support for the reduced minimum RTCP reporting interval described in Section 6.2 of [RFC3550]. When using the reduced minimum RTCP reporting interval, the fixed (non-reduced) minimum interval MUST be used when calculating the participant timeout interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay before sending the initial compound RTCP packet can be set to zero (see Section 6.2 of [RFC3550] as updated by [I-D.ietf-avtcore-rtp-multi-stream]). o Support for discontinuous transmission. RTP allows endpoints to pause and resume transmission at any time. When resuming, the RTP sequence number will increase by one, as usual, while the increase in the RTP timestamp value will depend on the duration of the pause. Discontinuous transmission is most commonly used with some audio payload formats, but is not audio specific, and can be used with any RTP payload format. o Ignore unknown RTCP packet types and RTP header extensions. This is to ensure robust handling of future extensions, middlebox behaviours, etc., that can result in not signalled RTCP packet types or RTP header extensions being received. If a compound RTCP packet is received that contains a mixture of known and unknown RTCP packet types, the known packets types need to be processed as usual, with only the unknown packet types being discarded. It is known that a significant number of legacy RTP implementations, especially those targeted at VoIP-only systems, do not support all of the above features, and in some cases do not support RTCP at all. Implementers are advised to consider the requirements for graceful degradation when interoperating with legacy implementations. Other implementation considerations are discussed in Section 12. 4.2. Choice of the RTP Profile The complete specification of RTP for a particular application domain requires the choice of an RTP Profile. For WebRTC use, the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF) [RFC5124], as extended by [RFC7007], MUST be implemented. The RTP/SAVPF profile is the combination of basic RTP/AVP profile [RFC3551], the RTP profile Perkins, et al. Expires September 18, 2016 [Page 7] Internet-Draft RTP for WebRTC March 2016 for RTCP-based feedback (RTP/AVPF) [RFC4585], and the secure RTP profile (RTP/SAVP) [RFC3711]. The RTCP-based feedback extensions [RFC4585] are needed for the improved RTCP timer model. This allows more flexible transmission of RTCP packets in response to events, rather than strictly according to bandwidth, and is vital for being able to report congestion signals as well as media events. These extensions also allow saving RTCP bandwidth, and an endpoint will commonly only use the full RTCP bandwidth allocation if there are many events that require feedback. The timer rules are also needed to make use of the RTP conferencing extensions discussed in Section 5.1. Note: The enhanced RTCP timer model defined in the RTP/AVPF profile is backwards compatible with legacy systems that implement only the RTP/AVP or RTP/SAVP profile, given some constraints on parameter configuration such as the RTCP bandwidth value and "trr- int" (the most important factor for interworking with RTP/(S)AVP endpoints via a gateway is to set the trr-int parameter to a value representing 4 seconds, see Section 6.1 in [I-D.ietf-avtcore-rtp-multi-stream]). The secure RTP (SRTP) profile extensions [RFC3711] are needed to provide media encryption, integrity protection, replay protection and a limited form of source authentication. WebRTC Endpoints MUST NOT send packets using the basic RTP/AVP profile or the RTP/AVPF profile; they MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP packets that are generated (i.e., implementations MUST use SRTP and SRTCP). The RTP/SAVPF profile MUST be configured using the cipher suites, DTLS-SRTP protection profiles, keying mechanisms, and other parameters described in [I-D.ietf-rtcweb-security-arch]. 4.3. Choice of RTP Payload Formats Mandatory to implement audio codecs and RTP payload formats for WebRTC endpoints are defined in [I-D.ietf-rtcweb-audio]. Mandatory to implement video codecs and RTP payload formats for WebRTC endpoints are defined in [I-D.ietf-rtcweb-video]. WebRTC endpoints MAY additionally implement any other codec for which an RTP payload format and associated signalling has been defined. WebRTC Endpoints cannot assume that the other participants in an RTP session understand any RTP payload format, no matter how common. The mapping between RTP payload type numbers and specific configurations of particular RTP payload formats MUST be agreed before those payload types/formats can be used. In an SDP context, this can be done using the "a=rtpmap:" and "a=fmtp:" attributes associated with an "m=" Perkins, et al. Expires September 18, 2016 [Page 8] Internet-Draft RTP for WebRTC March 2016 line, along with any other SDP attributes needed to configure the RTP payload format. Endpoints can signal support for multiple RTP payload formats, or multiple configurations of a single RTP payload format, as long as each unique RTP payload format configuration uses a different RTP payload type number. As outlined in Section 4.8, the RTP payload type number is sometimes used to associate an RTP packet stream with a signalling context. This association is possible provided unique RTP payload type numbers are used in each context. For example, an RTP packet stream can be associated with an SDP "m=" line by comparing the RTP payload type numbers used by the RTP packet stream with payload types signalled in the "a=rtpmap:" lines in the media sections of the SDP. This leads to the following considerations: If RTP packet streams are being associated with signalling contexts based on the RTP payload type, then the assignment of RTP payload type numbers MUST be unique across signalling contexts. If the same RTP payload format configuration is used in multiple contexts, then a different RTP payload type number has to be assigned in each context to ensure uniqueness. If the RTP payload type number is not being used to associate RTP packet streams with a signalling context, then the same RTP payload type number can be used to indicate the exact same RTP payload format configuration in multiple contexts. A single RTP payload type number MUST NOT be assigned to different RTP payload formats, or different configurations of the same RTP payload format, within a single RTP session (note that the "m=" lines in an SDP bundle group [I-D.ietf-mmusic-sdp-bundle-negotiation] form a single RTP session). An endpoint that has signalled support for multiple RTP payload formats MUST be able to accept data in any of those payload formats at any time, unless it has previously signalled limitations on its decoding capability. This requirement is constrained if several types of media (e.g., audio and video) are sent in the same RTP session. In such a case, a source (SSRC) is restricted to switching only between the RTP payload formats signalled for the type of media that is being sent by that source; see Section 4.4. To support rapid rate adaptation by changing codec, RTP does not require advance signalling for changes between RTP payload formats used by a single SSRC that were signalled during session set-up. If performing changes between two RTP payload types that use different RTP clock rates, an RTP sender MUST follow the Perkins, et al. Expires September 18, 2016 [Page 9] Internet-Draft RTP for WebRTC March 2016 recommendations in Section 4.1 of [RFC7160]. RTP receivers MUST follow the recommendations in Section 4.3 of [RFC7160] in order to support sources that switch between clock rates in an RTP session (these recommendations for receivers are backwards compatible with the case where senders use only a single clock rate). 4.4. Use of RTP Sessions An association amongst a set of endpoints communicating using RTP is known as an RTP session [RFC3550]. An endpoint can be involved in several RTP sessions at the same time. In a multimedia session, each type of media has typically been carried in a separate RTP session (e.g., using one RTP session for the audio, and a separate RTP session using a different transport-layer flow for the video). WebRTC Endpoints are REQUIRED to implement support for multimedia sessions in this way, separating each RTP session using different transport-layer flows for compatibility with legacy systems (this is sometimes called session multiplexing). In modern day networks, however, with the widespread use of network address/port translators (NAT/NAPT) and firewalls, it is desirable to reduce the number of transport-layer flows used by RTP applications. This can be done by sending all the RTP packet streams in a single RTP session, which will comprise a single transport-layer flow (this will prevent the use of some quality-of-service mechanisms, as discussed in Section 12.1.3). Implementations are therefore also REQUIRED to support transport of all RTP packet streams, independent of media type, in a single RTP session using a single transport layer flow, according to [I-D.ietf-avtcore-multi-media-rtp-session] (this is sometimes called SSRC multiplexing). If multiple types of media are to be used in a single RTP session, all participants in that RTP session MUST agree to this usage. In an SDP context, [I-D.ietf-mmusic-sdp-bundle-negotiation] can be used to signal such a bundle of RTP packet streams forming a single RTP session. Further discussion about the suitability of different RTP session structures and multiplexing methods to different scenarios can be found in [I-D.ietf-avtcore-multiplex-guidelines]. 4.5. RTP and RTCP Multiplexing Historically, RTP and RTCP have been run on separate transport layer flows (e.g., two UDP ports for each RTP session, one port for RTP and one port for RTCP). With the increased use of Network Address/Port Translation (NAT/NAPT) this has become problematic, since maintaining multiple NAT bindings can be costly. It also complicates firewall administration, since multiple ports need to be opened to allow RTP traffic. To reduce these costs and session set-up times, Perkins, et al. Expires September 18, 2016 [Page 10] Internet-Draft RTP for WebRTC March 2016 implementations are REQUIRED to support multiplexing RTP data packets and RTCP control packets on a single transport-layer flow [RFC5761]. Such RTP and RTCP multiplexing MUST be negotiated in the signalling channel before it is used. If SDP is used for signalling, this negotiation MUST use the mechanism defined in [RFC5761]. Implementations can also support sending RTP and RTCP on separate transport-layer flows, but this is OPTIONAL to implement. If an implementation does not support RTP and RTCP sent on separate transport-layer flows, it MUST indicate that using the mechanism defined in [I-D.ietf-mmusic-mux-exclusive]. Note that the use of RTP and RTCP multiplexed onto a single transport-layer flow ensures that there is occasional traffic sent on that port, even if there is no active media traffic. This can be useful to keep NAT bindings alive [RFC6263]. 4.6. Reduced Size RTCP RTCP packets are usually sent as compound RTCP packets, and [RFC3550] requires that those compound packets start with an Sender Report (SR) or Receiver Report (RR) packet. When using frequent RTCP feedback messages under the RTP/AVPF Profile [RFC4585] these statistics are not needed in every packet, and unnecessarily increase the mean RTCP packet size. This can limit the frequency at which RTCP packets can be sent within the RTCP bandwidth share. To avoid this problem, [RFC5506] specifies how to reduce the mean RTCP message size and allow for more frequent feedback. Frequent feedback, in turn, is essential to make real-time applications quickly aware of changing network conditions, and to allow them to adapt their transmission and encoding behaviour. Implementations MUST support sending and receiving non-compound RTCP feedback packets [RFC5506]. Use of non-compound RTCP packets MUST be negotiated using the signalling channel. If SDP is used for signalling, this negotiation MUST use the attributes defined in [RFC5506]. For backwards compatibility, implementations are also REQUIRED to support the use of compound RTCP feedback packets if the remote endpoint does not agree to the use of non-compound RTCP in the signalling exchange. 4.7. Symmetric RTP/RTCP To ease traversal of NAT and firewall devices, implementations are REQUIRED to implement and use Symmetric RTP [RFC4961]. The reason for using symmetric RTP is primarily to avoid issues with NATs and Firewalls by ensuring that the send and receive RTP packet streams, as well as RTCP, are actually bi-directional transport-layer flows. This will keep alive the NAT and firewall pinholes, and help indicate consent that the receive direction is a transport-layer flow the Perkins, et al. Expires September 18, 2016 [Page 11] Internet-Draft RTP for WebRTC March 2016 intended recipient actually wants. In addition, it saves resources, specifically ports at the endpoints, but also in the network as NAT mappings or firewall state is not unnecessary bloated. The amount of per flow QoS state kept in the network is also reduced. 4.8. Choice of RTP Synchronisation Source (SSRC) Implementations are REQUIRED to support signalled RTP synchronisation source (SSRC) identifiers. If SDP is used, this MUST be done using the "a=ssrc:" SDP attribute defined in Section 4.1 and Section 5 of [RFC5576] and the "previous-ssrc" source attribute defined in Section 6.2 of [RFC5576]; other per-SSRC attributes defined in [RFC5576] MAY be supported. While support for signalled SSRC identifiers is mandated, their use in an RTP session is OPTIONAL. Implementations MUST be prepared to accept RTP and RTCP packets using SSRCs that have not been explicitly signalled ahead of time. Implementations MUST support random SSRC assignment, and MUST support SSRC collision detection and resolution, according to [RFC3550]. When using signalled SSRC values, collision detection MUST be performed as described in Section 5 of [RFC5576]. It is often desirable to associate an RTP packet stream with a non- RTP context. For users of the WebRTC API a mapping between SSRCs and MediaStreamTracks are provided per Section 11. For gateways or other usages it is possible to associate an RTP packet stream with an "m=" line in a session description formatted using SDP. If SSRCs are signalled this is straightforward (in SDP the "a=ssrc:" line will be at the media level, allowing a direct association with an "m=" line). If SSRCs are not signalled, the RTP payload type numbers used in an RTP packet stream are often sufficient to associate that packet stream with a signalling context (e.g., if RTP payload type numbers are assigned as described in Section 4.3 of this memo, the RTP payload types used by an RTP packet stream can be compared with values in SDP "a=rtpmap:" lines, which are at the media level in SDP, and so map to an "m=" line). 4.9. Generation of the RTCP Canonical Name (CNAME) The RTCP Canonical Name (CNAME) provides a persistent transport-level identifier for an RTP endpoint. While the Synchronisation Source (SSRC) identifier for an RTP endpoint can change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged for the duration of a RTCPeerConnection [W3C.WD-webrtc-20130910], so that RTP endpoints can be uniquely identified and associated with their RTP packet streams within a set of related RTP sessions. Perkins, et al. Expires September 18, 2016 [Page 12] Internet-Draft RTP for WebRTC March 2016 Each RTP endpoint MUST have at least one RTCP CNAME, and that RTCP CNAME MUST be unique within the RTCPeerConnection. RTCP CNAMEs identify a particular synchronisation context, i.e., all SSRCs associated with a single RTCP CNAME share a common reference clock. If an endpoint has SSRCs that are associated with several unsynchronised reference clocks, and hence different synchronisation contexts, it will need to use multiple RTCP CNAMEs, one for each synchronisation context. Taking the discussion in Section 11 into account, a WebRTC Endpoint MUST NOT use more than one RTCP CNAME in the RTP sessions belonging to single RTCPeerConnection (that is, an RTCPeerConnection forms a synchronisation context). RTP middleboxes MAY generate RTP packet streams associated with more than one RTCP CNAME, to allow them to avoid having to resynchronize media from multiple different endpoints part of a multi-party RTP session. The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint (Section 13). Accordingly, a WebRTC Endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a single exception; if explicitly requested at creation an RTCPeerConnection MAY use the same CNAME as as an existing RTCPeerConnection within their common same-origin context. An WebRTC Endpoint MUST support reception of any CNAME that matches the syntax limitations specified by the RTP specification [RFC3550] and cannot assume that any CNAME will be chosen according to the form suggested above. 4.10. Handling of Leap Seconds The guidelines regarding handling of leap seconds to limit their impact on RTP media play-out and synchronization given in [RFC7164] SHOULD be followed. 5. WebRTC Use of RTP: Extensions There are a number of RTP extensions that are either needed to obtain full functionality, or extremely useful to improve on the baseline performance, in the WebRTC context. One set of these extensions is related to conferencing, while others are more generic in nature. The following subsections describe the various RTP extensions mandated or suggested for use within WebRTC. Perkins, et al. Expires September 18, 2016 [Page 13] Internet-Draft RTP for WebRTC March 2016 5.1. Conferencing Extensions and Topologies RTP is a protocol that inherently supports group communication. Groups can be implemented by having each endpoint send its RTP packet streams to an RTP middlebox that redistributes the traffic, by using a mesh of unicast RTP packet streams between endpoints, or by using an IP multicast group to distribute the RTP packet streams. These topologies can be implemented in a number of ways as discussed in [I-D.ietf-avtcore-rtp-topologies-update]. While the use of IP multicast groups is popular in IPTV systems, the topologies based on RTP middleboxes are dominant in interactive video conferencing environments. Topologies based on a mesh of unicast transport-layer flows to create a common RTP session have not seen widespread deployment to date. Accordingly, WebRTC Endpoints are not expected to support topologies based on IP multicast groups or to support mesh-based topologies, such as a point-to-multipoint mesh configured as a single RTP session (Topo-Mesh in the terminology of [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- multipoint mesh constructed using several RTP sessions, implemented in WebRTC using independent RTCPeerConnections [W3C.WD-webrtc-20130910], can be expected to be used in WebRTC, and needs to be supported. WebRTC Endpoints implemented according to this memo are expected to support all the topologies described in [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send and receive unicast RTP packet streams to and from some peer device, provided that peer can participate in performing congestion control on the RTP packet streams. The peer device could be another RTP endpoint, or it could be an RTP middlebox that redistributes the RTP packet streams to other RTP endpoints. This limitation means that some of the RTP middlebox-based topologies are not suitable for use in WebRTC. Specifically: o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, since they make the use of RTCP for congestion control and quality of service reports problematic (see Section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology SHOULD NOT be used because its safe use requires a congestion control algorithm or RTP circuit breaker that handles point to multipoint, which has not yet been standardised. The following topology can be used, however it has some issues worth noting: Perkins, et al. Expires September 18, 2016 [Page 14] Internet-Draft RTP for WebRTC March 2016 o Content modifying MCUs with RTCP termination (Topo-RTCP- terminating-MCU) MAY be used. Note that in this RTP Topology, RTP loop detection and identification of active senders is the responsibility of the WebRTC application; since the clients are isolated from each other at the RTP layer, RTP cannot assist with these functions (see section 3.9 of [I-D.ietf-avtcore-rtp-topologies-update]). The RTP extensions described in Section 5.1.1 to Section 5.1.6 are designed to be used with centralised conferencing, where an RTP middlebox (e.g., a conference bridge) receives a participant's RTP packet streams and distributes them to the other participants. These extensions are not necessary for interoperability; an RTP endpoint that does not implement these extensions will work correctly, but might offer poor performance. Support for the listed extensions will greatly improve the quality of experience and, to provide a reasonable baseline quality, some of these extensions are mandatory to be supported by WebRTC Endpoints. The RTCP conferencing extensions are defined in Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF) [RFC4585] and the memo on Codec Control Messages (CCM) in RTP/ AVPF [RFC5104]; they are fully usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. 5.1.1. Full Intra Request (FIR) The Full Intra Request message is defined in Sections 3.5.1 and 4.3.1 of the Codec Control Messages [RFC5104]. It is used to make the mixer request a new Intra picture from a participant in the session. This is used when switching between sources to ensure that the receivers can decode the video or other predictive media encoding with long prediction chains. WebRTC Endpoints that are sending media MUST understand and react to FIR feedback messages they receive, since this greatly improves the user experience when using centralised mixer-based conferencing. Support for sending FIR messages is OPTIONAL. 5.1.2. Picture Loss Indication (PLI) The Picture Loss Indication message is defined in Section 6.3.1 of the RTP/AVPF profile [RFC4585]. It is used by a receiver to tell the sending encoder that it lost the decoder context and would like to have it repaired somehow. This is semantically different from the Full Intra Request above as there could be multiple ways to fulfil the request. WebRTC Endpoints that are sending media MUST understand and react to PLI feedback messages as a loss tolerance mechanism. Receivers MAY send PLI messages. Perkins, et al. Expires September 18, 2016 [Page 15] Internet-Draft RTP for WebRTC March 2016 5.1.3. Slice Loss Indication (SLI) The Slice Loss Indication message is defined in Section 6.3.2 of the RTP/AVPF profile [RFC4585]. It is used by a receiver to tell the encoder that it has detected the loss or corruption of one or more consecutive macro blocks, and would like to have these repaired somehow. It is RECOMMENDED that receivers generate SLI feedback messages if slices are lost when using a codec that supports the concept of macro blocks. A sender that receives an SLI feedback message SHOULD attempt to repair the lost slice(s). 5.1.4. Reference Picture Selection Indication (RPSI) Reference Picture Selection Indication (RPSI) messages are defined in Section 6.3.3 of the RTP/AVPF profile [RFC4585]. Some video encoding standards allow the use of older reference pictures than the most recent one for predictive coding. If such a codec is in use, and if the encoder has learnt that encoder-decoder synchronisation has been lost, then a known as correct reference picture can be used as a base for future coding. The RPSI message allows this to be signalled. Receivers that detect that encoder-decoder synchronisation has been lost SHOULD generate an RPSI feedback message if codec being used supports reference picture selection. A RTP packet stream sender that receives such an RPSI message SHOULD act on that messages to change the reference picture, if it is possible to do so within the available bandwidth constraints, and with the codec being used. 5.1.5. Temporal-Spatial Trade-off Request (TSTR) The temporal-spatial trade-off request and notification are defined in Sections 3.5.2 and 4.3.2 of [RFC5104]. This request can be used to ask the video encoder to change the trade-off it makes between temporal and spatial resolution, for example to prefer high spatial image quality but low frame rate. Support for TSTR requests and notifications is OPTIONAL. 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 of the Codec Control Messages [RFC5104]. This request and its notification message are used by a media receiver to inform the sending party that there is a current limitation on the amount of bandwidth available to this receiver. There can be various reasons for this: for example, an RTP mixer can use this message to limit the media rate of the sender being forwarded by the mixer (without doing media transcoding) to fit the bottlenecks existing towards the other session participants. WebRTC Endpoints that are sending media are REQUIRED to implement support for TMMBR messages, and MUST follow Perkins, et al. Expires September 18, 2016 [Page 16] Internet-Draft RTP for WebRTC March 2016 bandwidth limitations set by a TMMBR message received for their SSRC. The sending of TMMBR requests is OPTIONAL. 5.2. Header Extensions The RTP specification [RFC3550] provides the capability to include RTP header extensions containing in-band data, but the format and semantics of the extensions are poorly specified. The use of header extensions is OPTIONAL in WebRTC, but if they are used, they MUST be formatted and signalled following the general mechanism for RTP header extensions defined in [RFC5285], since this gives well-defined semantics to RTP header extensions. As noted in [RFC5285], the requirement from the RTP specification that header extensions are "designed so that the header extension may be ignored" [RFC3550] stands. To be specific, header extensions MUST only be used for data that can safely be ignored by the recipient without affecting interoperability, and MUST NOT be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that is not compatible with the way the stream is signalled (e.g., as defined by the payload type). Valid examples of RTP header extensions might include metadata that is additional to the usual RTP information, but that can safely be ignored without compromising interoperability. 5.2.1. Rapid Synchronisation Many RTP sessions require synchronisation between audio, video, and other content. This synchronisation is performed by receivers, using information contained in RTCP SR packets, as described in the RTP specification [RFC3550]. This basic mechanism can be slow, however, so it is RECOMMENDED that the rapid RTP synchronisation extensions described in [RFC6051] be implemented in addition to RTCP SR-based synchronisation. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.2. Client-to-Mixer Audio Level The Client to Mixer Audio Level extension [RFC6464] is an RTP header extension used by an endpoint to inform a mixer about the level of audio activity in the packet to which the header is attached. This enables an RTP middlebox to make mixing or selection decisions without decoding or detailed inspection of the payload, reducing the complexity in some types of mixers. It can also save decoding resources in receivers, which can choose to decode only the most relevant RTP packet streams based on audio activity levels. Perkins, et al. Expires September 18, 2016 [Page 17] Internet-Draft RTP for WebRTC March 2016 The Client-to-Mixer Audio Level [RFC6464] header extension MUST be implemented. It is REQUIRED that implementations are capable of encrypting the header extension according to [RFC6904] since the information contained in these header extensions can be considered sensitive. The use of this encryption is RECOMMENDED, however usage of the encryption can be explicitly disabled through API or signalling. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.3. Mixer-to-Client Audio Level The Mixer to Client Audio Level header extension [RFC6465] provides an endpoint with the audio level of the different sources mixed into a common source stream by a RTP mixer. This enables a user interface to indicate the relative activity level of each session participant, rather than just being included or not based on the CSRC field. This is a pure optimisation of non critical functions, and is hence OPTIONAL to implement. If this header extension is implemented, it is REQUIRED that implementations are capable of encrypting the header extension according to [RFC6904] since the information contained in these header extensions can be considered sensitive. It is further RECOMMENDED that this encryption is used, unless the encryption has been explicitly disabled through API or signalling. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.4. Media Stream Identification WebRTC endpoints that implement the SDP bundle negotiation extension will use the SDP grouping framework 'mid' attribute to identify media streams. Such endpoints MUST implement the RTP MID header extension described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.5. Coordination of Video Orientation WebRTC endpoints that send or receive video MUST implement the coordination of video orientation (CVO) RTP header extension as described in Section 4 of [I-D.ietf-rtcweb-video]. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. Perkins, et al. Expires September 18, 2016 [Page 18] Internet-Draft RTP for WebRTC March 2016 6. WebRTC Use of RTP: Improving Transport Robustness There are tools that can make RTP packet streams robust against packet loss and reduce the impact of loss on media quality. However, they generally add some overhead compared to a non-robust stream. The overhead needs to be considered, and the aggregate bit-rate MUST be rate controlled to avoid causing network congestion (see Section 7). As a result, improving robustness might require a lower base encoding quality, but has the potential to deliver that quality with fewer errors. The mechanisms described in the following sub- sections can be used to improve tolerance to packet loss. 6.1. Negative Acknowledgements and RTP Retransmission As a consequence of supporting the RTP/SAVPF profile, implementations can send negative acknowledgements (NACKs) for RTP data packets [RFC4585]. This feedback can be used to inform a sender of the loss of particular RTP packets, subject to the capacity limitations of the RTCP feedback channel. A sender can use this information to optimise the user experience by adapting the media encoding to compensate for known lost packets. RTP packet stream senders are REQUIRED to understand the Generic NACK message defined in Section 6.2.1 of [RFC4585], but MAY choose to ignore some or all of this feedback (following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for missing RTP packets. Guidelines on when to send NACKs are provided in [RFC4585]. It is not expected that a receiver will send a NACK for every lost RTP packet, rather it needs to consider the cost of sending NACK feedback, and the importance of the lost packet, to make an informed decision on whether it is worth telling the sender about a packet loss event. The RTP Retransmission Payload Format [RFC4588] offers the ability to retransmit lost packets based on NACK feedback. Retransmission needs to be used with care in interactive real-time applications to ensure that the retransmitted packet arrives in time to be useful, but can be effective in environments with relatively low network RTT (an RTP sender can estimate the RTT to the receivers using the information in RTCP SR and RR packets, as described at the end of Section 6.4.1 of [RFC3550]). The use of retransmissions can also increase the forward RTP bandwidth, and can potentially caused increased packet loss if the original packet loss was caused by network congestion. Note, however, that retransmission of an important lost packet to repair decoder state can have lower cost than sending a full intra frame. It is not appropriate to blindly retransmit RTP packets in response to a NACK. The importance of lost packets and the likelihood of them Perkins, et al. Expires September 18, 2016 [Page 19] Internet-Draft RTP for WebRTC March 2016 arriving in time to be useful needs to be considered before RTP retransmission is used. Receivers are REQUIRED to implement support for RTP retransmission packets [RFC4588] sent using SSRC multiplexing, and MAY also support RTP retransmission packets sent using session multiplexing. Senders MAY send RTP retransmission packets in response to NACKs if support for the RTP retransmission payload format has been negotiated, and if the sender believes it is useful to send a retransmission of the packet(s) referenced in the NACK. Senders do not need to retransmit every NACKed packet. 6.2. Forward Error Correction (FEC) The use of Forward Error Correction (FEC) can provide an effective protection against some degree of packet loss, at the cost of steady bandwidth overhead. There are several FEC schemes that are defined for use with RTP. Some of these schemes are specific to a particular RTP payload format, others operate across RTP packets and can be used with any payload format. It needs to be noted that using redundant encoding or FEC will lead to increased play out delay, which needs to be considered when choosing FEC schemes and their parameters. WebRTC endpoints MUST follow the recommendations for FEC use given in [I-D.ietf-rtcweb-fec]. WebRTC endpoints MAY support other types of FEC, but these MUST be negotiated before they are used. 7. WebRTC Use of RTP: Rate Control and Media Adaptation WebRTC will be used in heterogeneous network environments using a variety of link technologies, including both wired and wireless links, to interconnect potentially large groups of users around the world. As a result, the network paths between users can have widely varying one-way delays, available bit-rates, load levels, and traffic mixtures. Individual endpoints can send one or more RTP packet streams to each participant, and there can be several participants. Each of these RTP packet streams can contain different types of media, and the type of media, bit rate, and number of RTP packet streams as well as transport-layer flows can be highly asymmetric. Non-RTP traffic can share the network paths with RTP transport-layer flows. Since the network environment is not predictable or stable, WebRTC Endpoints MUST ensure that the RTP traffic they generate can adapt to match changes in the available network capacity. The quality of experience for users of WebRTC is very dependent on effective adaptation of the media to the limitations of the network. Endpoints have to be designed so they do not transmit significantly more data than the network path can support, except for very short Perkins, et al. Expires September 18, 2016 [Page 20] Internet-Draft RTP for WebRTC March 2016 time periods, otherwise high levels of network packet loss or delay spikes will occur, causing media quality degradation. The limiting factor on the capacity of the network path might be the link bandwidth, or it might be competition with other traffic on the link (this can be non-WebRTC traffic, traffic due to other WebRTC flows, or even competition with other WebRTC flows in the same session). An effective media congestion control algorithm is therefore an essential part of the WebRTC framework. However, at the time of this writing, there is no standard congestion control algorithm that can be used for interactive media applications such as WebRTC's flows. Some requirements for congestion control algorithms for RTCPeerConnections are discussed in [I-D.ietf-rmcat-cc-requirements]. If a standardized congestion control algorithm that satisfies these requirements is developed in the future, this memo will need to be be updated to mandate its use. 7.1. Boundary Conditions and Circuit Breakers WebRTC Endpoints MUST implement the RTP circuit breaker algorithm that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP circuit breaker is designed to enable applications to recognise and react to situations of extreme network congestion. However, since the RTP circuit breaker might not be triggered until congestion becomes extreme, it cannot be considered a substitute for congestion control, and applications MUST also implement congestion control to allow them to adapt to changes in network capacity. The congestion control algorithm will have to be proprietary until a standardized congestion control algorithm is available. Any future RTP congestion control algorithms are expected to operate within the envelope allowed by the circuit breaker. The session establishment signalling will also necessarily establish boundaries to which the media bit-rate will conform. The choice of media codecs provides upper- and lower-bounds on the supported bit- rates that the application can utilise to provide useful quality, and the packetisation choices that exist. In addition, the signalling channel can establish maximum media bit-rate boundaries using, for example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF Temporary Maximum Media Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo). Signalled bandwidth limitations, such as SDP "b=AS:" or "b=CT:" lines received from the peer, MUST be followed when sending RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal its bandwidth limitations. These limitations have to be based on known bandwidth limitations, for example the capacity of the edge links. Perkins, et al. Expires September 18, 2016 [Page 21] Internet-Draft RTP for WebRTC March 2016 7.2. Congestion Control Interoperability and Legacy Systems All endpoints that wish to interwork with WebRTC MUST implement RTCP and provide congestion feedback via the defined RTCP reporting mechanisms. When interworking with legacy implementations that support RTCP using the RTP/AVP profile [RFC3551], congestion feedback is provided in RTCP RR packets every few seconds. Implementations that have to interwork with such endpoints MUST ensure that they keep within the RTP circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers] constraints to limit the congestion they can cause. If a legacy endpoint supports RTP/AVPF, this enables negotiation of important parameters for frequent reporting, such as the "trr-int" parameter, and the possibility that the endpoint supports some useful feedback format for congestion control purpose such as TMMBR [RFC5104]. Implementations that have to interwork with such endpoints MUST ensure that they stay within the RTP circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers] constraints to limit the congestion they can cause, but might find that they can achieve better congestion response depending on the amount of feedback that is available. With proprietary congestion control algorithms issues can arise when different algorithms and implementations interact in a communication session. If the different implementations have made different choices in regards to the type of adaptation, for example one sender based, and one receiver based, then one could end up in situation where one direction is dual controlled, when the other direction is not controlled. This memo cannot mandate behaviour for proprietary congestion control algorithms, but implementations that use such algorithms ought to be aware of this issue, and try to ensure that effective congestion control is negotiated for media flowing in both directions. If the IETF were to standardise both sender- and receiver-based congestion control algorithms for WebRTC traffic in the future, the issues of interoperability, control, and ensuring that both directions of media flow are congestion controlled would also need to be considered. 8. WebRTC Use of RTP: Performance Monitoring As described in Section 4.1, implementations are REQUIRED to generate RTCP Sender Report (SR) and Reception Report (RR) packets relating to the RTP packet streams they send and receive. These RTCP reports can be used for performance monitoring purposes, since they include basic packet loss and jitter statistics. Perkins, et al. Expires September 18, 2016 [Page 22] Internet-Draft RTP for WebRTC March 2016 A large number of additional performance metrics are supported by the RTCP Extended Reports (XR) framework, see [RFC3611][RFC6792]. At the time of this writing, it is not clear what extended metrics are suitable for use in WebRTC, so there is no requirement that implementations generate RTCP XR packets. However, implementations that can use detailed performance monitoring data MAY generate RTCP XR packets as appropriate. The use of RTCP XR packets SHOULD be signalled; implementations MUST ignore RTCP XR packets that are unexpected or not understood. 9. WebRTC Use of RTP: Future Extensions It is possible that the core set of RTP protocols and RTP extensions specified in this memo will prove insufficient for the future needs of WebRTC. In this case, future updates to this memo have to be made following the Guidelines for Writers of RTP Payload Format Specifications [RFC2736], How to Write an RTP Payload Format [I-D.ietf-payload-rtp-howto] and Guidelines for Extending the RTP Control Protocol [RFC5968], and SHOULD take into account any future guidelines for extending RTP and related protocols that have been developed. Authors of future extensions are urged to consider the wide range of environments in which RTP is used when recommending extensions, since extensions that are applicable in some scenarios can be problematic in others. Where possible, the WebRTC framework will adopt RTP extensions that are of general utility, to enable easy implementation of a gateway to other applications using RTP, rather than adopt mechanisms that are narrowly targeted at specific WebRTC use cases. 10. Signalling Considerations RTP is built with the assumption that an external signalling channel exists, and can be used to configure RTP sessions and their features. The basic configuration of an RTP session consists of the following parameters: RTP Profile: The name of the RTP profile to be used in session. The RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate on basic level, as can their secure variants RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. The secure variants of the profiles do not directly interoperate with the non-secure variants, due to the presence of additional header fields for authentication in SRTP packets and cryptographic transformation of the payload. WebRTC requires the use of the RTP/SAVPF profile, and this MUST be signalled. Interworking functions might transform this into the RTP/SAVP profile for a legacy use case, by indicating to the Perkins, et al. Expires September 18, 2016 [Page 23] Internet-Draft RTP for WebRTC March 2016 WebRTC Endpoint that the RTP/SAVPF is used and configuring a trr- int value of 4 seconds. Transport Information: Source and destination IP address(s) and ports for RTP and RTCP MUST be signalled for each RTP session. In WebRTC these transport addresses will be provided by ICE [RFC5245] that signals candidates and arrives at nominated candidate address pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such that a single port, i.e. transport-layer flow, is used for RTP and RTCP flows, this MUST be signalled (see Section 4.5). RTP Payload Types, media formats, and format parameters: The mapping between media type names (and hence the RTP payload formats to be used), and the RTP payload type numbers MUST be signalled. Each media type MAY also have a number of media type parameters that MUST also be signalled to configure the codec and RTP payload format (the "a=fmtp:" line from SDP). Section 4.3 of this memo discusses requirements for uniqueness of payload types. RTP Extensions: The use of any additional RTP header extensions and RTCP packet types, including any necessary parameters, MUST be signalled. This signalling is to ensure that a WebRTC Endpoint's behaviour, especially when sending, of any extensions is predictable and consistent. For robustness, and for compatibility with non-WebRTC systems that might be connected to a WebRTC session via a gateway, implementations are REQUIRED to ignore unknown RTCP packets and RTP header extensions (see also Section 4.1). RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the endpoints will be necessary. This SHALL be done as described in "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or something semantically equivalent. This also ensures that the endpoints have a common view of the RTCP bandwidth. A common view of the RTCP bandwidth among different endpoints is important, to prevent differences in RTCP packet timing and timeout intervals causing interoperability problems. These parameters are often expressed in SDP messages conveyed within an offer/answer exchange. RTP does not depend on SDP or on the offer/answer model, but does require all the necessary parameters to be agreed upon, and provided to the RTP implementation. Note that in WebRTC it will depend on the signalling model and API how these parameters need to be configured but they will be need to either be set in the API or explicitly signalled between the peers. Perkins, et al. Expires September 18, 2016 [Page 24] Internet-Draft RTP for WebRTC March 2016 11. WebRTC API Considerations The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses the concept of a MediaStream that consists of zero or more MediaStreamTracks. A MediaStreamTrack is an individual stream of media from any type of media source like a microphone or a camera, but also conceptual sources, like a audio mix or a video composition, are possible. The MediaStreamTracks within a MediaStream might need to be synchronized during play back. A MediaStreamTrack's realisation in RTP in the context of an RTCPeerConnection consists of a source packet stream identified with an SSRC within an RTP session part of the RTCPeerConnection. The MediaStreamTrack can also result in additional packet streams, and thus SSRCs, in the same RTP session. These can be dependent packet streams from scalable encoding of the source stream associated with the MediaStreamTrack, if such a media encoder is used. They can also be redundancy packet streams, these are created when applying Forward Error Correction (Section 6.2) or RTP retransmission (Section 6.1) to the source packet stream. It is important to note that the same media source can be feeding multiple MediaStreamTracks. As different sets of constraints or other parameters can be applied to the MediaStreamTrack, each MediaStreamTrack instance added to a RTCPeerConnection SHALL result in an independent source packet stream, with its own set of associated packet streams, and thus different SSRC(s). It will depend on applied constraints and parameters if the source stream and the encoding configuration will be identical between different MediaStreamTracks sharing the same media source. If the encoding parameters and constraints are the same, an implementation could choose to use only one encoded stream to create the different RTP packet streams. Note that such optimisations would need to take into account that the constraints for one of the MediaStreamTracks can at any moment change, meaning that the encoding configurations might no longer be identical and two different encoder instances would then be needed. The same MediaStreamTrack can also be included in multiple MediaStreams, thus multiple sets of MediaStreams can implicitly need to use the same synchronisation base. To ensure that this works in all cases, and does not force an endpoint to disrupt the media by changing synchronisation base and CNAME during delivery of any ongoing packet streams, all MediaStreamTracks and their associated SSRCs originating from the same endpoint need to be sent using the same CNAME within one RTCPeerConnection. This is motivating the use of a single CNAME in Section 4.9. Perkins, et al. Expires September 18, 2016 [Page 25] Internet-Draft RTP for WebRTC March 2016 The requirement on using the same CNAME for all SSRCs that originate from the same endpoint, does not require a middlebox that forwards traffic from multiple endpoints to only use a single CNAME. Different CNAMEs normally need to be used for different RTCPeerConnection instances, as specified in Section 4.9. Having two communication sessions with the same CNAME could enable tracking of a user or device across different services (see Section 4.4.1 of [I-D.ietf-rtcweb-security] for details). A web application can request that the CNAMEs used in different RTCPeerConnections (within a same-orign context) be the same, this allows for synchronization of the endpoint's RTP packet streams across the different RTCPeerConnections. Note: this doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking within a single origin. The above will currently force a WebRTC Endpoint that receives a MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on any RTCPeerConnection to perform resynchronisation of the stream. Since the sending party needs to change the CNAME to the one it uses, this implies it has to use a local system clock as timebase for the synchronisation. Thus, the relative relation between the timebase of the incoming stream and the system sending out needs to be defined. This relation also needs monitoring for clock drift and likely adjustments of the synchronisation. The sending entity is also responsible for congestion control for its sent streams. In cases of packet loss the loss of incoming data also needs to be handled. This leads to the observation that the method that is least likely to cause issues or interruptions in the outgoing source packet stream is a model of full decoding, including repair etc., followed by encoding of the media again into the outgoing packet stream. Optimisations of this method are clearly possible and implementation specific. A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks, where each of the different MediaStreamTracks (and their sets of associated packet streams) uses different CNAMEs. However, MediaStreamTracks that are received with different CNAMEs have no defined synchronisation. Note: The motivation for supporting reception of multiple CNAMEs is to allow for forward compatibility with any future changes that enable more efficient stream handling when endpoints relay/forward streams. It also ensures that endpoints can interoperate with certain types of multi-stream middleboxes or endpoints that are not WebRTC. Perkins, et al. Expires September 18, 2016 [Page 26] Internet-Draft RTP for WebRTC March 2016 Javascript Session Establishment Protocol [I-D.ietf-rtcweb-jsep] specifies that the binding between the WebRTC MediaStreams, MediaStreamTracks and the SSRC is done as specified in "Cross Session Stream Identification in the Session Description Protocol" [I-D.ietf-mmusic-msid]. The MSID document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to map unknown source packet stream SSRCs to MediaStreamTracks and MediaStreams. This later is relevant to handle some cases of legacy interoperability. Commonly the RTP Payload Type of any incoming packets will reveal if the packet stream is a source stream or a redundancy or dependent packet stream. The association to the correct source packet stream depends on the payload format in use for the packet stream. Finally this specification puts a requirement on the WebRTC API to realize a method for determining the CSRC list (Section 4.1) as well as the Mixer-to-Client audio levels (Section 5.2.3) (when supported) and the basic requirements for this is further discussed in Section 12.2.1. 12. RTP Implementation Considerations The following discussion provides some guidance on the implementation of the RTP features described in this memo. The focus is on a WebRTC Endpoint implementation perspective, and while some mention is made of the behaviour of middleboxes, that is not the focus of this memo. 12.1. Configuration and Use of RTP Sessions A WebRTC Endpoint will be a simultaneous participant in one or more RTP sessions. Each RTP session can convey multiple media sources, and can include media data from multiple endpoints. In the following, some ways in which WebRTC Endpoints can configure and use RTP sessions are outlined. 12.1.1. Use of Multiple Media Sources Within an RTP Session RTP is a group communication protocol, and every RTP session can potentially contain multiple RTP packet streams. There are several reasons why this might be desirable: Multiple media types: Outside of WebRTC, it is common to use one RTP session for each type of media source (e.g., one RTP session for audio sources and one for video sources, each sent over different transport layer flows). However, to reduce the number of UDP ports used, the default in WebRTC is to send all types of media in a single RTP session, as described in Section 4.4, using RTP and RTCP multiplexing (Section 4.5) to further reduce the number of UDP ports needed. This RTP session then uses only one bi- Perkins, et al. Expires September 18, 2016 [Page 27] Internet-Draft RTP for WebRTC March 2016 directional transport-layer flow, but will contain multiple RTP packet streams, each containing a different type of media. A common example might be an endpoint with a camera and microphone that sends two RTP packet streams, one video and one audio, into a single RTP session. Multiple Capture Devices: A WebRTC Endpoint might have multiple cameras, microphones, or other media capture devices, and so might want to generate several RTP packet streams of the same media type. Alternatively, it might want to send media from a single capture device in several different formats or quality settings at once. Both can result in a single endpoint sending multiple RTP packet streams of the same media type into a single RTP session at the same time. Associated Repair Data: An endpoint might send a RTP packet stream that is somehow associated with another stream. For example, it might send an RTP packet stream that contains FEC or retransmission data relating to another stream. Some RTP payload formats send this sort of associated repair data as part of the source packet stream, while others send it as a separate packet stream. Layered or Multiple Description Coding: An endpoint can use a layered media codec, for example H.264 SVC, or a multiple description codec, that generates multiple RTP packet streams, each with a distinct RTP SSRC, within a single RTP session. RTP Mixers, Translators, and Other Middleboxes: An RTP session, in the WebRTC context, is a point-to-point association between an endpoint and some other peer device, where those devices share a common SSRC space. The peer device might be another WebRTC Endpoint, or it might be an RTP mixer, translator, or some other form of media processing middlebox. In the latter cases, the middlebox might send mixed or relayed RTP streams from several participants, that the WebRTC Endpoint will need to render. Thus, even though a WebRTC Endpoint might only be a member of a single RTP session, the peer device might be extending that RTP session to incorporate other endpoints. WebRTC is a group communication environment and endpoints need to be capable of receiving, decoding, and playing out multiple RTP packet streams at once, even in a single RTP session. 12.1.2. Use of Multiple RTP Sessions In addition to sending and receiving multiple RTP packet streams within a single RTP session, a WebRTC Endpoint might participate in Perkins, et al. Expires September 18, 2016 [Page 28] Internet-Draft RTP for WebRTC March 2016 multiple RTP sessions. There are several reasons why a WebRTC Endpoint might choose to do this: To interoperate with legacy devices: The common practice in the non- WebRTC world is to send different types of media in separate RTP sessions, for example using one RTP session for audio and another RTP session, on a separate transport layer flow, for video. All WebRTC Endpoints need to support the option of sending different types of media on different RTP sessions, so they can interwork with such legacy devices. This is discussed further in Section 4.4. To provide enhanced quality of service: Some network-based quality of service mechanisms operate on the granularity of transport layer flows. If it is desired to use these mechanisms to provide differentiated quality of service for some RTP packet streams, then those RTP packet streams need to be sent in a separate RTP session using a different transport-layer flow, and with appropriate quality of service marking. This is discussed further in Section 12.1.3. To separate media with different purposes: An endpoint might want to send RTP packet streams that have different purposes on different RTP sessions, to make it easy for the peer device to distinguish them. For example, some centralised multiparty conferencing systems display the active speaker in high resolution, but show low resolution "thumbnails" of other participants. Such systems might configure the endpoints to send simulcast high- and low- resolution versions of their video using separate RTP sessions, to simplify the operation of the RTP middlebox. In the WebRTC context this is currently possible by establishing multiple WebRTC MediaStreamTracks that have the same media source in one (or more) RTCPeerConnection. Each MediaStreamTrack is then configured to deliver a particular media quality and thus media bit-rate, and will produce an independently encoded version with the codec parameters agreed specifically in the context of that RTCPeerConnection. The RTP middlebox can distinguish packets corresponding to the low- and high-resolution streams by inspecting their SSRC, RTP payload type, or some other information contained in RTP payload, RTP header extension or RTCP packets, but it can be easier to distinguish the RTP packet streams if they arrive on separate RTP sessions on separate transport-layer flows. To directly connect with multiple peers: A multi-party conference does not need to use an RTP middlebox. Rather, a multi-unicast mesh can be created, comprising several distinct RTP sessions, with each participant sending RTP traffic over a separate RTP session (that is, using an independent RTCPeerConnection object) Perkins, et al. Expires September 18, 2016 [Page 29] Internet-Draft RTP for WebRTC March 2016 to every other participant, as shown in Figure 1. This topology has the benefit of not requiring an RTP middlebox node that is trusted to access and manipulate the media data. The downside is that it increases the used bandwidth at each sender by requiring one copy of the RTP packet streams for each participant that are part of the same session beyond the sender itself. +---+ +---+ | A |<--->| B | +---+ +---+ ^ ^ \ / \ / v v +---+ | C | +---+ Figure 1: Multi-unicast using several RTP sessions The multi-unicast topology could also be implemented as a single RTP session, spanning multiple peer-to-peer transport layer connections, or as several pairwise RTP sessions, one between each pair of peers. To maintain a coherent mapping of the relationship between RTP sessions and RTCPeerConnection objects it is recommend that this is implemented as several individual RTP sessions. The only downside is that endpoint A will not learn of the quality of any transmission happening between B and C, since it will not see RTCP reports for the RTP session between B and C, whereas it would if all three participants were part of a single RTP session. Experience with the Mbone tools (experimental RTP-based multicast conferencing tools from the late 1990s) has showed that RTCP reception quality reports for third parties can be presented to users in a way that helps them understand asymmetric network problems, and the approach of using separate RTP sessions prevents this. However, an advantage of using separate RTP sessions is that it enables using different media bit-rates and RTP session configurations between the different peers, thus not forcing B to endure the same quality reductions if there are limitations in the transport from A to C as C will. It is believed that these advantages outweigh the limitations in debugging power. To indirectly connect with multiple peers: A common scenario in multi-party conferencing is to create indirect connections to multiple peers, using an RTP mixer, translator, or some other type of RTP middlebox. Figure 2 outlines a simple topology that might be used in a four-person centralised conference. The middlebox Perkins, et al. Expires September 18, 2016 [Page 30] Internet-Draft RTP for WebRTC March 2016 acts to optimise the transmission of RTP packet streams from certain perspectives, either by only sending some of the received RTP packet stream to any given receiver, or by providing a combined RTP packet stream out of a set of contributing streams. +---+ +-------------+ +---+ | A |<---->| |<---->| B | +---+ | RTP mixer, | +---+ | translator, | | or other | +---+ | middlebox | +---+ | C |<---->| |<---->| D | +---+ +-------------+ +---+ Figure 2: RTP mixer with only unicast paths There are various methods of implementation for the middlebox. If implemented as a standard RTP mixer or translator, a single RTP session will extend across the middlebox and encompass all the endpoints in one multi-party session. Other types of middlebox might use separate RTP sessions between each endpoint and the middlebox. A common aspect is that these RTP middleboxes can use a number of tools to control the media encoding provided by a WebRTC Endpoint. This includes functions like requesting the breaking of the encoding chain and have the encoder produce a so called Intra frame. Another is limiting the bit-rate of a given stream to better suit the mixer view of the multiple down-streams. Others are controlling the most suitable frame-rate, picture resolution, the trade-off between frame-rate and spatial quality. The middlebox has the responsibility to correctly perform congestion control, source identification, manage synchronisation while providing the application with suitable media optimisations. The middlebox also has to be a trusted node when it comes to security, since it manipulates either the RTP header or the media itself (or both) received from one endpoint, before sending it on towards the endpoint(s), thus they need to be able to decrypt and then re-encrypt the RTP packet stream before sending it out. RTP Mixers can create a situation where an endpoint experiences a situation in-between a session with only two endpoints and multiple RTP sessions. Mixers are expected to not forward RTCP reports regarding RTP packet streams across themselves. This is due to the difference in the RTP packet streams provided to the different endpoints. The original media source lacks information about a mixer's manipulations prior to sending it the different receivers. This scenario also results in that an endpoint's Perkins, et al. Expires September 18, 2016 [Page 31] Internet-Draft RTP for WebRTC March 2016 feedback or requests go to the mixer. When the mixer can't act on this by itself, it is forced to go to the original media source to fulfil the receivers request. This will not necessarily be explicitly visible to any RTP and RTCP traffic, but the interactions and the time to complete them will indicate such dependencies. Providing source authentication in multi-party scenarios is a challenge. In the mixer-based topologies, endpoints source authentication is based on, firstly, verifying that media comes from the mixer by cryptographic verification and, secondly, trust in the mixer to correctly identify any source towards the endpoint. In RTP sessions where multiple endpoints are directly visible to an endpoint, all endpoints will have knowledge about each others' master keys, and can thus inject packets claimed to come from another endpoint in the session. Any node performing relay can perform non-cryptographic mitigation by preventing forwarding of packets that have SSRC fields that came from other endpoints before. For cryptographic verification of the source, SRTP would require additional security mechanisms, for example TESLA for SRTP [RFC4383], that are not part of the base WebRTC standards. To forward media between multiple peers: It is sometimes desirable for an endpoint that receives an RTP packet stream to be able to forward that RTP packet stream to a third party. The are some obvious security and privacy implications in supporting this, but also potential uses. This is supported in the W3C API by taking the received and decoded media and using it as media source that is re-encoding and transmitted as a new stream. At the RTP layer, media forwarding acts as a back-to-back RTP receiver and RTP sender. The receiving side terminates the RTP session and decodes the media, while the sender side re-encodes and transmits the media using an entirely separate RTP session. The original sender will only see a single receiver of the media, and will not be able to tell that forwarding is happening based on RTP-layer information since the RTP session that is used to send the forwarded media is not connected to the RTP session on which the media was received by the node doing the forwarding. The endpoint that is performing the forwarding is responsible for producing an RTP packet stream suitable for onwards transmission. The outgoing RTP session that is used to send the forwarded media is entirely separate to the RTP session on which the media was received. This will require media transcoding for congestion control purpose to produce a suitable bit-rate for the outgoing RTP session, reducing media quality and forcing the forwarding Perkins, et al. Expires September 18, 2016 [Page 32] Internet-Draft RTP for WebRTC March 2016 endpoint to spend the resource on the transcoding. The media transcoding does result in a separation of the two different legs removing almost all dependencies, and allowing the forwarding endpoint to optimise its media transcoding operation. The cost is greatly increased computational complexity on the forwarding node. Receivers of the forwarded stream will see the forwarding device as the sender of the stream, and will not be able to tell from the RTP layer that they are receiving a forwarded stream rather than an entirely new RTP packet stream generated by the forwarding device. 12.1.3. Differentiated Treatment of RTP Streams There are use cases for differentiated treatment of RTP packet streams. Such differentiation can happen at several places in the system. First of all is the prioritization within the endpoint sending the media, which controls, both which RTP packet streams that will be sent, and their allocation of bit-rate out of the current available aggregate as determined by the congestion control. It is expected that the WebRTC API [W3C.WD-webrtc-20130910] will allow the application to indicate relative priorities for different MediaStreamTracks. These priorities can then be used to influence the local RTP processing, especially when it comes to congestion control response in how to divide the available bandwidth between the RTP packet streams. Any changes in relative priority will also need to be considered for RTP packet streams that are associated with the main RTP packet streams, such as redundant streams for RTP retransmission and FEC. The importance of such redundant RTP packet streams is dependent on the media type and codec used, in regards to how robust that codec is to packet loss. However, a default policy might to be to use the same priority for redundant RTP packet stream as for the source RTP packet stream. Secondly, the network can prioritize transport-layer flows and sub- flows, including RTP packet streams. Typically, differential treatment includes two steps, the first being identifying whether an IP packet belongs to a class that has to be treated differently, the second consisting of the actual mechanism to prioritize packets. Three common methods for classifying IP packets are: DiffServ: The endpoint marks a packet with a DiffServ code point to indicate to the network that the packet belongs to a particular class. Flow based: Packets that need to be given a particular treatment are identified using a combination of IP and port address. Perkins, et al. Expires September 18, 2016 [Page 33] Internet-Draft RTP for WebRTC March 2016 Deep Packet Inspection: A network classifier (DPI) inspects the packet and tries to determine if the packet represents a particular application and type that is to be prioritized. Flow-based differentiation will provide the same treatment to all packets within a transport-layer flow, i.e., relative prioritization is not possible. Moreover, if the resources are limited it might not be possible to provide differential treatment compared to best-effort for all the RTP packet streams used in a WebRTC session. The use of flow-based differentiation needs to be coordinated between the WebRTC system and the network(s). The WebRTC endpoint needs to know that flow-based differentiation might be used to provide the separation of the RTP packet streams onto different UDP flows to enable a more granular usage of flow based differentiation. The used flows, their 5-tuples and prioritization will need to be communicated to the network so that it can identify the flows correctly to enable prioritization. No specific protocol support for this is specified. DiffServ assumes that either the endpoint or a classifier can mark the packets with an appropriate DSCP so that the packets are treated according to that marking. If the endpoint is to mark the traffic two requirements arise in the WebRTC context: 1) The WebRTC Endpoint has to know which DSCP to use and that it can use them on some set of RTP packet streams. 2) The information needs to be propagated to the operating system when transmitting the packet. Details of this process are outside the scope of this memo and are further discussed in "DSCP and other packet markings for RTCWeb QoS" [I-D.ietf-tsvwg-rtcweb-qos]. Deep Packet Inspectors will, despite the SRTP media encryption, still be fairly capable at classifying the RTP streams. The reason is that SRTP leaves the first 12 bytes of the RTP header unencrypted. This enables easy RTP stream identification using the SSRC and provides the classifier with useful information that can be correlated to determine for example the stream's media type. Using packet sizes, reception times, packet inter-spacing, RTP timestamp increments and sequence numbers, fairly reliable classifications are achieved. For packet based marking schemes it might be possible to mark individual RTP packets differently based on the relative priority of the RTP payload. For example video codecs that have I, P, and B pictures could prioritise any payloads carrying only B frames less, as these are less damaging to loose. However, depending on the QoS mechanism and what markings that are applied, this can result in not only different packet drop probabilities but also packet reordering, see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for further discussion. As a default policy all RTP packets related to a RTP packet stream ought to be provided with the same prioritization; Perkins, et al. Expires September 18, 2016 [Page 34] Internet-Draft RTP for WebRTC March 2016 per-packet prioritization is outside the scope of this memo, but might be specified elsewhere in future. It is also important to consider how RTCP packets associated with a particular RTP packet stream need to be marked. RTCP compound packets with Sender Reports (SR), ought to be marked with the same priority as the RTP packet stream itself, so the RTCP-based round- trip time (RTT) measurements are done using the same transport-layer flow priority as the RTP packet stream experiences. RTCP compound packets containing RR packet ought to be sent with the priority used by the majority of the RTP packet streams reported on. RTCP packets containing time-critical feedback packets can use higher priority to improve the timeliness and likelihood of delivery of such feedback. 12.2. Media Source, RTP Streams, and Participant Identification 12.2.1. Media Source Identification Each RTP packet stream is identified by a unique synchronisation source (SSRC) identifier. The SSRC identifier is carried in each of the RTP packets comprising a RTP packet stream, and is also used to identify that stream in the corresponding RTCP reports. The SSRC is chosen as discussed in Section 4.8. The first stage in demultiplexing RTP and RTCP packets received on a single transport layer flow at a WebRTC Endpoint is to separate the RTP packet streams based on their SSRC value; once that is done, additional demultiplexing steps can determine how and where to render the media. RTP allows a mixer, or other RTP-layer middlebox, to combine encoded streams from multiple media sources to form a new encoded stream from a new media source (the mixer). The RTP packets in that new RTP packet stream can include a Contributing Source (CSRC) list, indicating which original SSRCs contributed to the combined source stream. As described in Section 4.1, implementations need to support reception of RTP data packets containing a CSRC list and RTCP packets that relate to sources present in the CSRC list. The CSRC list can change on a packet-by-packet basis, depending on the mixing operation being performed. Knowledge of what media sources contributed to a particular RTP packet can be important if the user interface indicates which participants are active in the session. Changes in the CSRC list included in packets needs to be exposed to the WebRTC application using some API, if the application is to be able to track changes in session participation. It is desirable to map CSRC values back into WebRTC MediaStream identities as they cross this API, to avoid exposing the SSRC/CSRC name space to WebRTC applications. If the mixer-to-client audio level extension [RFC6465] is being used in the session (see Section 5.2.3), the information in the CSRC list Perkins, et al. Expires September 18, 2016 [Page 35] Internet-Draft RTP for WebRTC March 2016 is augmented by audio level information for each contributing source. It is desirable to expose this information to the WebRTC application using some API, after mapping the CSRC values to WebRTC MediaStream identities, so it can be exposed in the user interface. 12.2.2. SSRC Collision Detection The RTP standard requires RTP implementations to have support for detecting and handling SSRC collisions, i.e., resolve the conflict when two different endpoints use the same SSRC value (see section 8.2 of [RFC3550]). This requirement also applies to WebRTC Endpoints. There are several scenarios where SSRC collisions can occur: o In a point-to-point session where each SSRC is associated with either of the two endpoints and where the main media carrying SSRC identifier will be announced in the signalling channel, a collision is less likely to occur due to the information about used SSRCs. If SDP is used, this information is provided by Source-Specific SDP Attributes [RFC5576]. Still, collisions can occur if both endpoints start using a new SSRC identifier prior to having signalled it to the peer and received acknowledgement on the signalling message. The Source-Specific SDP Attributes [RFC5576] contains a mechanism to signal how the endpoint resolved the SSRC collision. o SSRC values that have not been signalled could also appear in an RTP session. This is more likely than it appears, since some RTP functions use extra SSRCs to provide their functionality. For example, retransmission data might be transmitted using a separate RTP packet stream that requires its own SSRC, separate to the SSRC of the source RTP packet stream [RFC4588]. In those cases, an endpoint can create a new SSRC that strictly doesn't need to be announced over the signalling channel to function correctly on both RTP and RTCPeerConnection level. o Multiple endpoints in a multiparty conference can create new sources and signal those towards the RTP middlebox. In cases where the SSRC/CSRC are propagated between the different endpoints from the RTP middlebox collisions can occur. o An RTP middlebox could connect an endpoint's RTCPeerConnection to another RTCPeerConnection from the same endpoint, thus forming a loop where the endpoint will receive its own traffic. While it is clearly considered a bug, it is important that the endpoint is able to recognise and handle the case when it occurs. This case becomes even more problematic when media mixers, and so on, are involved, where the stream received is a different stream but still contains this client's input. Perkins, et al. Expires September 18, 2016 [Page 36] Internet-Draft RTP for WebRTC March 2016 These SSRC/CSRC collisions can only be handled on RTP level as long as the same RTP session is extended across multiple RTCPeerConnections by a RTP middlebox. To resolve the more generic case where multiple RTCPeerConnections are interconnected, identification of the media source(s) part of a MediaStreamTrack being propagated across multiple interconnected RTCPeerConnection needs to be preserved across these interconnections. 12.2.3. Media Synchronisation Context When an endpoint sends media from more than one media source, it needs to consider if (and which of) these media sources are to be synchronized. In RTP/RTCP, synchronisation is provided by having a set of RTP packet streams be indicated as coming from the same synchronisation context and logical endpoint by using the same RTCP CNAME identifier. The next provision is that the internal clocks of all media sources, i.e., what drives the RTP timestamp, can be correlated to a system clock that is provided in RTCP Sender Reports encoded in an NTP format. By correlating all RTP timestamps to a common system clock for all sources, the timing relation of the different RTP packet streams, also across multiple RTP sessions can be derived at the receiver and, if desired, the streams can be synchronized. The requirement is for the media sender to provide the correlation information; it is up to the receiver to use it or not. 13. Security Considerations The overall security architecture for WebRTC is described in [I-D.ietf-rtcweb-security-arch], and security considerations for the WebRTC framework are described in [I-D.ietf-rtcweb-security]. These considerations also apply to this memo. The security considerations of the RTP specification, the RTP/SAVPF profile, and the various RTP/RTCP extensions and RTP payload formats that form the complete protocol suite described in this memo apply. It is not believed there are any new security considerations resulting from the combination of these various protocol extensions. The Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides handling of fundamental issues by offering confidentiality, integrity and partial source authentication. A mandatory to implement and use media security solution is created by combining this secured RTP profile and DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of [I-D.ietf-rtcweb-security-arch]. Perkins, et al. Expires September 18, 2016 [Page 37] Internet-Draft RTP for WebRTC March 2016 RTCP packets convey a Canonical Name (CNAME) identifier that is used to associate RTP packet streams that need to be synchronised across related RTP sessions. Inappropriate choice of CNAME values can be a privacy concern, since long-term persistent CNAME identifiers can be used to track users across multiple WebRTC calls. Section 4.9 of this memo mandates generation of short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in untraceable CNAME values that alleviate this risk. Some potential denial of service attacks exist if the RTCP reporting interval is configured to an inappropriate value. This could be done by configuring the RTCP bandwidth fraction to an excessively large or small value using the SDP "b=RR:" or "b=RS:" lines [RFC3556], or some similar mechanism, or by choosing an excessively large or small value for the RTP/AVPF minimal receiver report interval (if using SDP, this is the "a=rtcp-fb:... trr-int" parameter) [RFC4585]. The risks are as follows: 1. the RTCP bandwidth could be configured to make the regular reporting interval so large that effective congestion control cannot be maintained, potentially leading to denial of service due to congestion caused by the media traffic; 2. the RTCP interval could be configured to a very small value, causing endpoints to generate high rate RTCP traffic, potentially leading to denial of service due to the non-congestion controlled RTCP traffic; and 3. RTCP parameters could be configured differently for each endpoint, with some of the endpoints using a large reporting interval and some using a smaller interval, leading to denial of service due to premature participant timeouts due to mismatched timeout periods which are based on the reporting interval (this is a particular concern if endpoints use a small but non-zero value for the RTP/AVPF minimal receiver report interval (trr-int) [RFC4585], as discussed in Section 6.1 of [I-D.ietf-avtcore-rtp-multi-stream]). Premature participant timeout can be avoided by using the fixed (non- reduced) minimum interval when calculating the participant timeout (see Section 4.1 of this memo and Section 6.1 of [I-D.ietf-avtcore-rtp-multi-stream]). To address the other concerns, endpoints SHOULD ignore parameters that configure the RTCP reporting interval to be significantly longer than the default five second interval specified in [RFC3550] (unless the media data rate is so low that the longer reporting interval roughly corresponds to 5% of the media data rate), or that configure the RTCP reporting interval small enough that the RTCP bandwidth would exceed the media bandwidth. Perkins, et al. Expires September 18, 2016 [Page 38] Internet-Draft RTP for WebRTC March 2016 The guidelines in [RFC6562] apply when using variable bit rate (VBR) audio codecs such as Opus (see Section 4.3 for discussion of mandated audio codecs). The guidelines in [RFC6562] also apply, but are of lesser importance, when using the client-to-mixer audio level header extensions (Section 5.2.2) or the mixer-to-client audio level header extensions (Section 5.2.3). The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP middleboxes performing voice activity based source selection or third party monitoring that will greatly benefit from the information, and this has been expressed using API or signalling. If further evidence are produced to show that information leakage is significant from audio level indications, then use of encryption needs to be mandated at that time. In multi-party communication scenarios using RTP Middleboxes, a lot of trust is placed on these middleboxes to preserve the sessions security. The middlebox needs to maintain the confidentiality, integrity and perform source authentication. As discussed in Section 12.1.1 the middlebox can perform checks that prevents any endpoint participating in a conference to impersonate another. Some additional security considerations regarding multi-party topologies can be found in [I-D.ietf-avtcore-rtp-topologies-update]. 14. IANA Considerations This memo makes no request of IANA. Note to RFC Editor: this section is to be removed on publication as an RFC. 15. Acknowledgements The authors would like to thank Bernard Aboba, Harald Alvestrand, Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim Spring, Martin Thomson, and the other members of the IETF RTCWEB working group for their valuable feedback. 16. References 16.1. Normative References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", draft- ietf-avtcore-multi-media-rtp-session-13 (work in progress), December 2015. Perkins, et al. Expires September 18, 2016 [Page 39] Internet-Draft RTP for WebRTC March 2016 [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Varun, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-13 (work in progress), February 2016. [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-avtcore-rtp-multi-stream-optimisation] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work in progress), March 2016. [I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", draft- ietf-avtcore-rtp-topologies-update-10 (work in progress), July 2015. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-03 (work in progress), February 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-27 (work in progress), February 2016. [I-D.ietf-rtcweb-audio] Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Requirements", draft-ietf-rtcweb-audio-10 (work in progress), February 2016. [I-D.ietf-rtcweb-fec] Uberti, J., "WebRTC Forward Error Correction Requirements", draft-ietf-rtcweb-fec-02 (work in progress), October 2015. Perkins, et al. Expires September 18, 2016 [Page 40] Internet-Draft RTP for WebRTC March 2016 [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-15 (work in progress), January 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-11 (work in progress), March 2015. [I-D.ietf-rtcweb-video] Roach, A., "WebRTC Video Processing and Codec Requirements", draft-ietf-rtcweb-video-06 (work in progress), June 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . Perkins, et al. Expires September 18, 2016 [Page 41] Internet-Draft RTP for WebRTC March 2016 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . Perkins, et al. Expires September 18, 2016 [Page 42] Internet-Draft RTP for WebRTC March 2016 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, . [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- time Transport Protocol (RTP) Header Extension for Mixer- to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, . [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . [RFC7007] Terriberry, T., "Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)", RFC 7007, DOI 10.17487/RFC7007, August 2013, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, . [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, DOI 10.17487/RFC7164, March 2014, . Perkins, et al. Expires September 18, 2016 [Page 43] Internet-Draft RTP for WebRTC March 2016 [W3C.WD-mediacapture-streams-20130903] Burnett, D., Bergkvist, A., Jennings, C., and A. Narayanan, "Media Capture and Streams", World Wide Web Consortium WD WD-mediacapture-streams-20130903, September 2013, . [W3C.WD-webrtc-20130910] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20130910, September 2013, . 16.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft-ietf-avtcore- multiplex-guidelines-03 (work in progress), October 2014. [I-D.ietf-avtext-rtp-grouping-taxonomy] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", draft-ietf- avtext-rtp-grouping-taxonomy-08 (work in progress), July 2015. [I-D.ietf-dart-dscp-rtp] Black, D. and P. Jones, "Differentiated Services (DiffServ) and Real-time Communication", draft-ietf-dart- dscp-rtp-10 (work in progress), November 2014. [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", draft-ietf-mmusic-msid-11 (work in progress), October 2015. [I-D.ietf-payload-rtp-howto] Westerlund, M., "How to Write an RTP Payload Format", draft-ietf-payload-rtp-howto-14 (work in progress), May 2015. [I-D.ietf-rmcat-cc-requirements] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", draft-ietf-rmcat-cc- requirements-09 (work in progress), December 2014. Perkins, et al. Expires September 18, 2016 [Page 44] Internet-Draft RTP for WebRTC March 2016 [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-13 (work in progress), March 2016. [I-D.ietf-tsvwg-rtcweb-qos] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP and other packet markings for WebRTC QoS", draft-ietf- tsvwg-rtcweb-qos-14 (work in progress), March 2016. [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, DOI 10.17487/RFC4383, February 2006, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", RFC 5968, DOI 10.17487/RFC5968, September 2010, . [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, . [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC6792, November 2012, . Perkins, et al. Expires September 18, 2016 [Page 45] Internet-Draft RTP for WebRTC March 2016 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . Authors' Addresses Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org URI: https://csperkins.org/ Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Joerg Ott Aalto University School of Electrical Engineering Espoo 02150 Finland Email: jorg.ott@aalto.fi Perkins, et al. Expires September 18, 2016 [Page 46] ./draft-ietf-rtcweb-transports-17.txt0000664000764400076440000012155013004145207017065 0ustar iustyiusty Network Working Group H. Alvestrand Internet-Draft Google Intended status: Standards Track October 26, 2016 Expires: April 29, 2017 Transports for WebRTC draft-ietf-rtcweb-transports-17 Abstract This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Alvestrand Expires April 29, 2017 [Page 1] Internet-Draft WebRTC Transports October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 3. Transport and Middlebox specification . . . . . . . . . . . . 3 3.1. System-provided interfaces . . . . . . . . . . . . . . . 3 3.2. Ability to use IPv4 and IPv6 . . . . . . . . . . . . . . 4 3.3. Usage of temporary IPv6 addresses . . . . . . . . . . . . 4 3.4. Middle box related functions . . . . . . . . . . . . . . 5 3.5. Transport protocols implemented . . . . . . . . . . . . . 6 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 7 4.1. Local prioritization . . . . . . . . . . . . . . . . . . 8 4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 16 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 16 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 17 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 17 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 17 A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17 A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 18 A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 18 A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 18 A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18 A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18 A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 19 A.13. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 19 A.14. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 19 A.15. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 19 A.16. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 19 A.17. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction WebRTC is a protocol suite aimed at real time multimedia exchange between browsers, and between browsers and other entities. WebRTC is described in the WebRTC overview document, [I-D.ietf-rtcweb-overview], which also defines terminology used in this document, including the terms "WebRTC endpoint" and "WebRTC browser". Alvestrand Expires April 29, 2017 [Page 2] Internet-Draft WebRTC Transports October 2016 Terminology for RTP sources is taken from[RFC7656] . This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. This protocol suite intends to satisfy the security considerations described in the WebRTC security documents, [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. This document describes requirements that apply to all WebRTC endpoints. When there are requirements that apply only to WebRTC browsers, this is called out explicitly. 2. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Transport and Middlebox specification 3.1. System-provided interfaces The protocol specifications used here assume that the following protocols are available to the implementations of the WebRTC protocols: o UDP [RFC0768]. This is the protocol assumed by most protocol elements described. o TCP [RFC0793]. This is used for HTTP/WebSockets, as well as for TURN/TLS and ICE-TCP. For both protocols, IPv4 and IPv6 support is assumed. For UDP, this specification assumes the ability to set the DSCP code point of the sockets opened on a per-packet basis, in order to achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos] (see Section 4.2) when multiple media types are multiplexed. It does not assume that the DSCP codepoints will be honored, and does assume that they may be zeroed or changed, since this is a local configuration issue. Platforms that do not give access to these interfaces will not be able to support a conforming WebRTC endpoint. Alvestrand Expires April 29, 2017 [Page 3] Internet-Draft WebRTC Transports October 2016 This specification does not assume that the implementation will have access to ICMP or raw IP. The following protocols may be used, but can be implemented by a WebRTC endpoint, and are therefore not defined as "system-provided interfaces": o TURN - Traversal Using Relays Around NAT, [RFC5766] o STUN - Session Traversal Utilities for NAT, [RFC5389] o ICE - Interactive Connectivity Establishment, [I-D.ietf-ice-rfc5245bis] o TLS - Transport Layer Security, [RFC5246] o DTLS - Datagram Transport Layer Security, [RFC6347]. 3.2. Ability to use IPv4 and IPv6 Web applications running in a WebRTC browser MUST be able to utilize both IPv4 and IPv6 where available - that is, when two peers have only IPv4 connectivity to each other, or they have only IPv6 connectivity to each other, applications running in the WebRTC browser MUST be able to communicate. When TURN is used, and the TURN server has IPv4 or IPv6 connectivity to the peer or the peer's TURN server, candidates of the appropriate types MUST be supported. The "Happy Eyeballs" specification for ICE [I-D.ietf-mmusic-ice-dualstack-fairness] SHOULD be supported. 3.3. Usage of temporary IPv6 addresses The IPv6 default address selection specification [RFC6724] specifies that temporary addresses [RFC4941] are to be preferred over permanent addresses. This is a change from the rules specified by [RFC3484]. For applications that select a single address, this is usually done by the IPV6_PREFER_SRC_TMP preference flag specified in [RFC5014]. However, this rule, which is intended to ensure that privacy-enhanced addresses are used in preference to static addresses, doesn't have the right effect in ICE, where all addresses are gathered and therefore revealed to the application. Therefore, the following rule is applied instead: When a WebRTC endpoint gathers all IPv6 addresses on its host, and both non-deprecated temporary addresses and permanent addresses of the same scope are present, the WebRTC endpoint SHOULD discard the permanent addresses before exposing addresses to the application or Alvestrand Expires April 29, 2017 [Page 4] Internet-Draft WebRTC Transports October 2016 using them in ICE. This is consistent with the default policy described in [RFC6724]. If some of the temporary IPv6 addresses, but not all, are marked deprecated, the WebRTC endpoint SHOULD discard the deprecated addresses, unless they are used by an ongoing connection. In an ICE restart, deprecated addresses that are currently in use MAY be retained. 3.4. Middle box related functions The primary mechanism to deal with middle boxes is ICE, which is an appropriate way to deal with NAT boxes and firewalls that accept traffic from the inside, but only from the outside if it is in response to inside traffic (simple stateful firewalls). ICE [I-D.ietf-ice-rfc5245bis] MUST be supported. The implementation MUST be a full ICE implementation, not ICE-Lite. A full ICE implementation allows interworking with both ICE and ICE-Lite implementations when they are deployed appropriately. In order to deal with situations where both parties are behind NATs of the type that perform endpoint-dependent mapping (as defined in [RFC5128] section 2.4), TURN [RFC5766] MUST be supported. WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application. Note that there is other work around STUN and TURN sever discovery and management, including [I-D.ietf-tram-turn-server-discovery] for server discovery, as well as [I-D.ietf-rtcweb-return]. In order to deal with firewalls that block all UDP traffic, the mode of TURN that uses TCP between the WebRTC endpoint and the TURN server MUST be supported, and the mode of TURN that uses TLS over TCP between the WebRTC endpoint and the TURN server MUST be supported. See [RFC5766] section 2.1 for details. In order to deal with situations where one party is on an IPv4 network and the other party is on an IPv6 network, TURN extensions for IPv6 [RFC6156] MUST be supported. TURN TCP candidates, where the connection from the WebRTC endpoint's TURN server to the peer is a TCP connection, [RFC6062] MAY be supported. However, such candidates are not seen as providing any significant benefit, for the following reasons. Alvestrand Expires April 29, 2017 [Page 5] Internet-Draft WebRTC Transports October 2016 First, use of TURN TCP candidates would only be relevant in cases which both peers are required to use TCP to establish a PeerConnection. Second, that use case is supported in a different way by both sides establishing UDP relay candidates using TURN over TCP to connect to their respective relay servers. Third, using TCP between the WebRTC endpoint's TURN server and the peer may result in more performance problems than using UDP, e.g. due to head of line blocking. ICE-TCP candidates [RFC6544] MUST be supported; this may allow applications to communicate to peers with public IP addresses across UDP-blocking firewalls without using a TURN server. If TCP connections are used, RTP framing according to [RFC4571] MUST be used for all packets. This includes the RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets. The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section 11 (300 Try Alternate) MUST be supported. The WebRTC endpoint MAY support accessing the Internet through an HTTP proxy. If it does so, it MUST include the "ALPN" header as specified in [RFC7639], and proxy authentication as described in Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported. 3.5. Transport protocols implemented For transport of media, secure RTP is used. The details of the profile of RTP used are described in "RTP Usage" [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers] and congstion control (see [I-D.ietf-rmcat-cc-requirements] for further guidance). Key exchange MUST be done using DTLS-SRTP, as described in [I-D.ietf-rtcweb-security-arch]. For data transport over the WebRTC data channel [I-D.ietf-rtcweb-data-channel], WebRTC endpoints MUST support SCTP over DTLS over ICE. This encapsulation is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. Negotiation of this transport in SDP is defined in [I-D.ietf-mmusic-sctp-sdp]. The SCTP extension for NDATA, [I-D.ietf-tsvwg-sctp-ndata], MUST be supported. The setup protocol for WebRTC data channels described in [I-D.ietf-rtcweb-data-protocol] MUST be supported. Alvestrand Expires April 29, 2017 [Page 6] Internet-Draft WebRTC Transports October 2016 Note: DTLS-SRTP as defined in [RFC5764] section 6.7.1 defines the interaction between DTLS and ICE ( [I-D.ietf-ice-rfc5245bis]). The effect of this specification is that all ICE candidate pairs associated with a single component are part of the same DTLS association. Thus, there will only be one DTLS handshake even if there are multiple valid candidate pairs. WebRTC endpoints MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], section 5.1.2, with clarifications in [I-D.ietf-avtcore-rfc5764-mux-fixes]. All application layer protocol payloads over this DTLS connection are SCTP packets. Protocol identification MUST be supplied as part of the DTLS handshake, as specified in [I-D.ietf-rtcweb-alpn]. 4. Media Prioritization The WebRTC prioritization model is that the application tells the WebRTC endpoint about the priority of media and data that is controlled from the API. In this context, a "flow" is used for the units that are given a specific priority through the WebRTC API. For media, a "media flow", which can be an "audio flow" or a "video flow", is what [RFC7656] calls a "media source", which results in a "source RTP stream" and one or more "redundancy RTP streams". This specification does not describe prioritization between the RTP streams that come from a single "media source". All media flows in WebRTC are assumed to be interactive, as defined in [RFC4594]; there is no browser API support for indicating whether media is interactive or non-interactive. A "data flow" is the outgoing data on a single WebRTC data channel. The priority associated with a media flow or data flow is classified as "very-low", "low", "medium or "high". There are only four priority levels at the API. The priority settings affect two pieces of behavior: Packet send sequence decisions and packet markings. Each is described in its own section below. Alvestrand Expires April 29, 2017 [Page 7] Internet-Draft WebRTC Transports October 2016 4.1. Local prioritization Local prioritization is applied at the local node, before the packet is sent. This means that the prioritization has full access to the data about the individual packets, and can choose differing treatment based on the stream a packet belongs to. When an WebRTC endpoint has packets to send on multiple streams that are congestion-controlled under the same congestion control regime, the WebRTC endpoint SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "high" priority flow will have the ability to send 8 times as much data as a "very-low" priority flow if both have data to send. This prioritization is independent of the media type. The details of which packet to send first are implementation defined. For example: If there is a high priority audio flow sending 100 byte packets, and a low priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. Conversely, if the audio flow is marked low priority and the video flow is marked high priority, the scheduler may decide to send 2 video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending > 2500 payload bytes. If there are two high priority audio flows, each will be able to send 4000 bytes in the same period where a low priority video flow is able to send 1000 bytes. Two example implementation strategies are: o When the available bandwidth is known from the congestion control algorithm, configure each codec and each data channel with a target send rate that is appropriate to its share of the available bandwidth. o When congestion control indicates that a specified number of packets can be sent, send packets that are available to send using a weighted round robin scheme across the connections. Alvestrand Expires April 29, 2017 [Page 8] Internet-Draft WebRTC Transports October 2016 Any combination of these, or other schemes that have the same effect, is valid, as long as the distribution of transmission capacity is approximately correct. For media, it is usually inappropriate to use deep queues for sending; it is more useful to, for instance, skip intermediate frames that have no dependencies on them in order to achieve a lower bitrate. For reliable data, queues are useful. Note that this specification doesn't dictate when disparate streams are to be "congestion controlled under the same congestion control regime". The issue of coupling congestion controllers is explored further in [I-D.ietf-rmcat-coupled-cc]. 4.2. Usage of Quality of Service - DSCP and Multiplexing When the packet is sent, the network will make decisions about queueing and/or discarding the packet that can affect the quality of the communication. The sender can attempt to set the DSCP field of the packet to influence these decisions. Implementations SHOULD attempt to set QoS on the packets sent, according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. It is appropriate to depart from this recommendation when running on platforms where QoS marking is not implemented. The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. Some examples of such behaviors are described in [ANRW16]. The detection of these conditions is implementation dependent. A particularly hard problem is when one media transport uses multiple DSCP code points, where one may be blocked and another may be allowed. This is allowed even within a single media flow for video in [I-D.ietf-tsvwg-rtcweb-qos]. Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCP code points that are intended to be used once a candidate pair has been selected. If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0. This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent. This switch will of course invalidate any congestion information gathered up to that point. Failures can also start happening during the lifetime of the call; this case is expected to be rarer, and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart. Alvestrand Expires April 29, 2017 [Page 9] Internet-Draft WebRTC Transports October 2016 Note that when a DSCP code point causes non-delivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes. Other flows on the same transport, using different DSCP code points, don't need to change. All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point. The code point used SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the highest priority data channel carried. Note that this means that all data packets, no matter what their relative priority is, will be treated the same by the network. All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point. More advice on the use of DSCP code points with RTP and on the relationship between DSCP and congestion control is given in [RFC7657]. There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points. Some of these schemes depend on classifying the traffic into flows based on 5-tuple (source address, source port, protocol, destination address, destination port) or 6-tuple (5-tuple + DSCP code point). Under differing conditions, it may therefore make sense for a sending application to choose any of the configurations: o Each media stream carried on its own 5-tuple o Media streams grouped by media type into 5-tuples (such as carrying all audio on one 5-tuple) o All media sent over a single 5-tuple, with or without differentiation into 6-tuples based on DSCP code points In each of the configurations mentioned, data channels may be carried in its own 5-tuple, or multiplexed together with one of the media flows. More complex configurations, such as sending a high priority video stream on one 5-tuple and sending all other video streams multiplexed together over another 5-tuple, can also be envisioned. More information on mapping media flows to 5-tuples can be found in [I-D.ietf-rtcweb-rtp-usage]. A sending implementation MUST be able to support the following configurations: Alvestrand Expires April 29, 2017 [Page 10] Internet-Draft WebRTC Transports October 2016 o Multiplex all media and data on a single 5-tuple (fully bundled) o Send each media stream on its own 5-tuple and data on its own 5-tuple (fully unbundled) It MAY choose to support other configurations, such as bundling each media type (audio, video or data) into its own 5-tuple (bundling by media type). Sending data channel data over multiple 5-tuples is not supported. A receiving implementation MUST be able to receive media and data in all these configurations. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations RTCWEB security considerations are enumerated in [I-D.ietf-rtcweb-security]. Security considerations pertaining to the use of DSCP are enumerated in [I-D.ietf-tsvwg-rtcweb-qos]. 7. Acknowledgements This document is based on earlier versions embedded in [I-D.ietf-rtcweb-overview], which were the results of contributions from many RTCWEB WG members. Special thanks for reviews of earlier versions of this draft go to Eduardo Gueiros, Magnus Westerlund, Markus Isomaki and Dan Wing; the contributions from Andrew Hutton also deserve special mention. 8. References 8.1. Normative References Alvestrand Expires April 29, 2017 [Page 11] Internet-Draft WebRTC Transports October 2016 [I-D.ietf-avtcore-rfc5764-mux-fixes] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", draft-ietf-avtcore-rfc5764-mux-fixes-11 (work in progress), September 2016. [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-06 (work in progress), July 2014. [I-D.ietf-ice-rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-04 (work in progress), June 2016. [I-D.ietf-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE Multihomed and IPv4/IPv6 Dual Stack Fairness", draft-ietf-mmusic-ice- dualstack-fairness-02 (work in progress), September 2015. [I-D.ietf-mmusic-sctp-sdp] Loreto, S. and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-07 (work in progress), July 2014. [I-D.ietf-rmcat-cc-requirements] Jesup, R., "Congestion Control Requirements For RMCAT", draft-ietf-rmcat-cc-requirements-06 (work in progress), October 2014. [I-D.ietf-rtcweb-alpn] Thomson, M., "Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- alpn-00 (work in progress), July 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-12 (work in progress), September 2014. Alvestrand Expires April 29, 2017 [Page 12] Internet-Draft WebRTC Transports October 2016 [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-08 (work in progress), September 2014. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-11 (work in progress), August 2014. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-17 (work in progress), August 2014. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-07 (work in progress), July 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-10 (work in progress), July 2014. [I-D.ietf-tsvwg-rtcweb-qos] Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Polk, "DSCP and other packet markings for RTCWeb QoS", draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June 2014. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-05 (work in progress), July 2014. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and a New Data Chunk for the Stream Control Transmission Protocol", draft-ietf-tsvwg-sctp- ndata-01 (work in progress), July 2014. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. Alvestrand Expires April 29, 2017 [Page 13] Internet-Draft WebRTC Transports October 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, July 2006. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010. [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, March 2012. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. Alvestrand Expires April 29, 2017 [Page 14] Internet-Draft WebRTC Transports October 2016 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. [RFC7639] Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP Header Field", RFC 7639, DOI 10.17487/RFC7639, August 2015, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . 8.2. Informative References [ANRW16] Barik, R., Welzl, M., and A. Elmokashfi, "How to say that you're special: Can we use bits in the IPv4 header?", ACM, IRTF, ISOC Applied Networking Research Workshop (ANRW 2016), Berlin , July 2016. [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-03 (work in progress), July 2016. [I-D.ietf-rtcweb-return] Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC", draft- ietf-rtcweb-return-01 (work in progress), January 2016. [I-D.ietf-tram-turn-server-discovery] Patil, P., Reddy, T., and D. Wing, "TURN Server Auto Discovery", draft-ietf-tram-turn-server-discovery-00 (work in progress), July 2014. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008. Alvestrand Expires April 29, 2017 [Page 15] Internet-Draft WebRTC Transports October 2016 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10 .17487/RFC7657, November 2015, . Appendix A. Change log This section should be removed before publication as an RFC. A.1. Changes from -00 to -01 o Clarified DSCP requirements, with reference to -qos- o Clarified "symmetric NAT" -> "NATs which perform endpoint- dependent mapping" o Made support of TURN over TCP mandatory o Made support of TURN over TLS a MAY, and added open question o Added an informative reference to -firewalls- o Called out that we don't make requirements on HTTP proxy interaction (yet A.2. Changes from -01 to -02 o Required support for 300 Alternate Server from STUN. o Separated the ICE-TCP candidate requirement from the TURN-TCP requirement. o Added new sections on using QoS functions, and on multiplexing considerations. o Removed all mention of RTP profiles. Those are the business of the RTP usage draft, not this one. o Required support for TURN IPv6 extensions. o Removed reference to the TURN URI scheme, as it was unnecessary. o Made an explicit statement that multiplexing (or not) is an application matter. . Alvestrand Expires April 29, 2017 [Page 16] Internet-Draft WebRTC Transports October 2016 A.3. Changes from -02 to -03 o Added required support for draft-ietf-tsvwg-sctp-ndata o Removed discussion of multiplexing, since this is present in rtp- usage. o Added RFC 4571 reference for framing RTP packets over TCP. o Downgraded TURN TCP candidates from SHOULD to MAY, and added more language discussing TCP usage. o Added language on IPv6 temporary addresses. o Added language describing multiplexing choices. o Added a separate section detailing what it means when we say that an WebRTC implementation MUST support both IPv4 and IPv6. A.4. Changes from -03 to -04 o Added a section on prioritization, moved the DSCP section into it, and added a section on local prioritization, giving a specific algorithm for interpreting "priority" in local prioritization. o ICE-TCP candidates was changed from MAY to MUST, in recognition of the sense of the room at the London IETF. A.5. Changes from -04 to -05 o Reworded introduction o Removed all references to "WebRTC". It now uses only the term RTCWEB. o Addressed a number of clarity / language comments o Rewrote the prioritization to cover data channels and to describe multiple ways of prioritizing flows o Made explicit reference to "MUST do DTLS-SRTP", and referred to security-arch for details A.6. Changes from -05 to -06 o Changed all references to "RTCWEB" to "WebRTC", except one reference to the working group Alvestrand Expires April 29, 2017 [Page 17] Internet-Draft WebRTC Transports October 2016 o Added reference to the httpbis "connect" protocol (being adopted by HTTPBIS) o Added reference to the ALPN header (being adopted by RTCWEB) o Added reference to the DART RTP document o Said explicitly that SCTP for data channels has a single DSCP codepoint A.7. Changes from -06 to -07 o Updated references o Removed reference to draft-hutton-rtcweb-nat-firewall- considerations A.8. Changes from -07 to -08 o Updated references o Deleted "bundle each media type (audio, video or data) into its own 5-tuple (bundling by media type)" from MUST support configuration, since JSEP does not have a means to negotiate this configuration A.9. Changes from -08 to -09 o Added a clarifying note about DTLS-SRTP and ICE interaction. A.10. Changes from -09 to -10 o Re-added references to proxy authentication lost in 07-08 transition (Bug #5) o Rearranged and rephrased text in section 4 about prioritization to reflect discussions in TSVWG. o Changed the "Connect" header to "ALPN", and updated reference. (Bug #6) A.11. Changes from -10 to -11 o Added a definition of the term "flow" used in the prioritization chapter o Changed the names of the four priority levels to conform to other specs. Alvestrand Expires April 29, 2017 [Page 18] Internet-Draft WebRTC Transports October 2016 A.12. Changes from -11 to -12 o Added a SHOULD NOT about using deprecated temporary IPv6 addresses. o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657 A.13. Changes from -12 to -13 o Clarify that the ALPN header needs to be sent. o Mentioned that RFC 7657 also talks about congestion control A.14. Changes from -13 to -14 o Add note about non-support for marking flows as interactive or non-interactive. A.15. Changes from -14 to -15 o Various text clarifications based on comments in Last Call and IESG review o Clarified that only non-deprecated IPv6 addresses are used o Described handling of downgrading of DSCP markings when blackholes are detected o Expanded acronyms in a new protocol list A.16. Changes from -15 to -16 These changes are done post IESG approval, and address IESG comments and other late comments. Issue numbers refer to https://github.com/ rtcweb-wg/rtcweb-transport/issues. o Moved RFC 4594, 7656 and -overview to normative (issue #28) o Changed the terms "client", "WebRTC implementation" and "WebRTC device" to consistently be "WebRTC endpoint", as defined in -overview. (issue #40) o Added a note mentioning TURN service discovery and RETURN (issue #42) o Added a note mentioning that rtp-usage requires circut breaker and congestion control (issue #43) Alvestrand Expires April 29, 2017 [Page 19] Internet-Draft WebRTC Transports October 2016 o Added mention of the "don't discard temporary IPv6 addresses that are in use" (issue #44) o Added a reference to draft-ietf-rmcat-coupled-cc (issue #46) A.17. Changes from -16 to -17 o Added an informative reference to the "DSCP blackholing" paper o Changed the reference for ICE from RFC 5245 to draft-ietf-ice- rfc5245bis Author's Address Harald Alvestrand Google Email: harald@alvestrand.no Alvestrand Expires April 29, 2017 [Page 20] ./draft-ietf-rtgwg-rlfa-node-protection-13.txt0000664000764400076440000014165613040372122020550 0ustar iustyiusty Routing Area Working Group P. Sarkar, Ed. Internet-Draft Individual Contributor Intended status: Standards Track S. Hegde Expires: July 24, 2017 C. Bowers Juniper Networks, Inc. H. Gredler RtBrick, Inc. S. Litkowski Orange January 20, 2017 Remote-LFA Node Protection and Manageability draft-ietf-rtgwg-rlfa-node-protection-13 Abstract The loop-free alternates computed following the current Remote-LFA specification guarantees only link-protection. The resulting Remote- LFA nexthops (also called PQ-nodes), may not guarantee node- protection for all destinations being protected by it. This document describes an extension to the Remote Loop-Free based IP fast reroute mechanisms, that specifes procedures for determining if a given PQ-node provides node-protection for a specific destination or not. The document also shows how the same procedure can be utilized for collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate path is precursory to apply operator defined policy for eliminating paths not fitting constraints. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Sarkar, et al. Expires July 24, 2017 [Page 1] Internet-Draft R-LFA Node-Protection and Manageability January 2017 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 24, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 4 2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 6 2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 6 2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4. Link-Protecting PQ Space . . . . . . . . . . . . . . 7 2.2.5. Candidate Node-Protecting PQ Space . . . . . . . . . 7 2.2.6. Cost-Based Definitions . . . . . . . . . . . . . . . 7 2.2.6.1. Link-Protecting Extended P-Space . . . . . . . . 7 2.2.6.2. Node-Protecting Extended P-Space . . . . . . . . 8 2.2.6.3. Q-Space . . . . . . . . . . . . . . . . . . . . . 9 2.3. Computing Node-protecting R-LFA Path . . . . . . . . . . 9 2.3.1. Computing Candidate Node-protecting PQ-Nodes for Primary nexthops . . . . . . . . . . . . . . . . . . 9 2.3.2. Computing node-protecting paths from PQ-nodes to destinations . . . . . . . . . . . . . . . . . . . . 11 2.3.3. Computing Node-Protecting R-LFA Paths for Destinations with ECMP primary nexthop nodes . . . . 13 2.3.4. Limiting extra computational overhead . . . . . . . . 17 3. Manageability of Remote-LFA Alternate Paths . . . . . . . . . 18 3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 18 Sarkar, et al. Expires July 24, 2017 [Page 2] Internet-Draft R-LFA Node-Protection and Manageability January 2017 3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 19 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The Remote-LFA [RFC7490] specification provides loop-free alternates that guarantee only link-protection. The resulting Remote-LFA alternate nexthops (also referred to as the PQ-nodes) may not provide node-protection for all destinations covered by the same Remote-LFA alternate, in case of failure of the primary nexthop node. Neither does the specification provide a means to determine the same. Also, the LFA Manageability [RFC7916] document requires a computing router to find all possible (including all possible Remote-LFA) alternate nexthops, collect the complete set of path characteristics for each alternate path, run an alternate-selection policy (configured by the operator) and find the best alternate path. This will require the Remote-LFA implementation to gather all the required path characteristics along each link on the entire Remote-LFA alternate path. With current LFA [RFC5286] and Remote-LFA implementations, the forward SPF (and reverse SPF) is run with the computing router and its immediate 1-hop routers as the roots. While that enables computation of path attributes (e.g. SRLG, Admin-groups) for first alternate path segment from the computing router to the PQ-node, there is no means for the computing router to gather any path attributes for the path segment from the PQ-node to destination. Consequently any policy-based selection of alternate paths will consider only the path attributes from the computing router up until the PQ-node. This document describes a procedure for determining node-protection with Remote-LFA. The same procedure is also extended for collection of a complete set of path attributes, enabling more accurate policy- based selection for alternate paths obtained with Remote-LFA. 1.1. Abbreviations This document uses the following list of abbreviations. LFA - Loop Free Alternates Sarkar, et al. Expires July 24, 2017 [Page 3] Internet-Draft R-LFA Node-Protection and Manageability January 2017 RLFA or R-LFA - Remote Loop Free Alternates ECMP - Equal Cost Multiple Path SPF - Shortest Path First graph computations NH - Next Hop node 2. Node Protection with Remote-LFA Node-protection is required to provide protection of traffic on a given forwarding node, against the failure of the first-hop node on the primary forwarding path. Such protection becomes more critical in the absence of mechanisms like non-stop-routing in the network. Certain operators refrain from deploying non-stop-routing in their network, due to the required complex state synchronization between redundant control plane hardwares it requires, and the significant additional performance complexities it hence introduces. In such cases node-protection is essential to guarantee un-interrupted flow of traffic, even in the case of an entire forwarding node going down. The following sections discuss the node-protection problem in the context of Remote-LFA and propose a solution. 2.1. The Problem To better illustrate the problem and the solution proposed in this document the following topology diagram from the Remote-LFA [RFC7490] draft is being re-used with slight modification. D1 / S-x-E / \ N R3--D2 \ / R1---R2 Figure 1: Topology 1 In the above topology, for all (non-ECMP) destinations reachable via the S-E link there is no standard LFA alternate. As per the Remote- LFA [RFC7490] alternate specifications node R2 being the only PQ-node for the S-E link provides nexthop for all the above destinations. Table 1 below, shows all possible primary and Remote-LFA alternate paths for each destination. Sarkar, et al. Expires July 24, 2017 [Page 4] Internet-Draft R-LFA Node-Protection and Manageability January 2017 +-------------+--------------+---------+-------------------------+ | Destination | Primary Path | PQ-node | Remote-LFA Backup Path | +-------------+--------------+---------+-------------------------+ | R3 | S->E->R3 | R2 | S=>N=>R1=>R2->R3 | | E | S->E | R2 | S=>N=>R1=>R2->R3->E | | D1 | S->E->D1 | R2 | S=>N=>R1=>R2->R3->E->D1 | | D2 | S->E->R3->D2 | R2 | S=>N=>R1=>R2->R3->D2 | +-------------+--------------+---------+-------------------------+ Table 1: Remote-LFA backup paths via PQ-node R2 A closer look at Table 1 shows that, while the PQ-node R2 provides link-protection for all the destinations, it does not provide node- protection for destinations E and D1. In the event of the node- failure on primary nexthop E, the alternate path from Remote-LFA nexthop R2 to E and D1 also becomes unavailable. So for a Remote-LFA nexthop to provide node-protection for a given destination, it is mandatory that, the shortest path from the given PQ-node to the given destination MUST NOT traverse the primary nexthop. In another extension of the topology in Figure 1 let us consider an additional link between N and E with the same cost as the other links. D1 / S-x-E / / \ N---+ R3--D2 \ / R1---R2 Figure 2: Topology 2 In the above topology, the S-E link is no more on any of the shortest paths from N to R3, E and D1. Hence R3, E and D1 are also included in both the Extended-P space and Q space of E (w.r.t S-E link). Table 2 below, shows all possible primary and R-LFA alternate paths via PQ-node R3, for each destination reachable through the S-E link in the above topology. The R-LFA alternate paths via PQ-node R2 remains same as in Table 1. Sarkar, et al. Expires July 24, 2017 [Page 5] Internet-Draft R-LFA Node-Protection and Manageability January 2017 +-------------+--------------+---------+------------------------+ | Destination | Primary Path | PQ-node | Remote-LFA Backup Path | +-------------+--------------+---------+------------------------+ | R3 | S->E->R3 | R3 | S=>N=>E=>R3 | | E | S->E | R3 | S=>N=>E=>R3->E | | D1 | S->E->D1 | R3 | S=>N=>E=>R3->E->D1 | | D2 | S->E->R3->D2 | R3 | S=>N=>E=>R3->D2 | +-------------+--------------+---------+------------------------+ Table 2: Remote-LFA backup paths via PQ-node R3 Again a closer look at Table 2 shows that, unlike Table 1, where the single PQ-node R2 provided node-protection for destinations R3 and D2, if we choose R3 as the R-LFA nexthop, it does not provide node- protection for R3 and D2 anymore. If S chooses R3 as the R-LFA nexthop, in the event of the node-failure on primary nexthop E, on the alternate path from S to R-LFA nexthop R3, one of parallel ECMP path between N and R3 also becomes unavailable. So for a Remote-LFA nexthop to provide node-protection for a given destination, it is also mandatory that, the shortest paths from S to the chosen PQ-node MUST NOT traverse the primary nexthop node. 2.2. Additional Definitions This document adds and enhances the following definitions extending the ones mentioned in Remote-LFA [RFC7490] specification. 2.2.1. Link-Protecting Extended P-Space The Remote-LFA [RFC7490] specification already defines this. The link-protecting extended P-space for a link S-E being protected is the set of routers that are reachable from one or more direct neighbors of S, except primary node E, without traversing the S-E link on any of the shortest paths from the direct neighbor to the router. This MUST exclude any direct neighbor for which there is at least one ECMP path from the direct neighbor traversing the link(S-E) being protected. For a cost-based definition for Link-protecting Extended P-Space refer to Section 2.2.6.1. 2.2.2. Node-Protecting Extended P-Space The node-protecting extended P-space for a primary nexthop node E being protected, is the set of routers that are reachable from one or more direct neighbors of S, except primary node E, without traversing the node E. This MUST exclude any direct neighbors for which there Sarkar, et al. Expires July 24, 2017 [Page 6] Internet-Draft R-LFA Node-Protection and Manageability January 2017 is at least one ECMP path from the direct neighbor traversing the node E being protected. For a cost-based definition for Node-protecting Extended P-Space refer to Section 2.2.6.2. 2.2.3. Q-Space The Remote-LFA [RFC7490] draft already defines this. The Q-space for a link S-E being protected is the set of nodes that can reach primary node E, without traversing the S-E link on any of the shortest paths from the node itself to primary nexthop E. This MUST exclude any node for which there is at least one ECMP path from the node to the primary nexthop E traversing the link(S-E) being protected. For a cost-based definition for Q-Space refer to Section 2.2.6.3. 2.2.4. Link-Protecting PQ Space A node Y is in link-protecting PQ space w.r.t the link (S-E) being protected, if and only if, Y is present in both link-protecting extended P-space and the Q-space for the link being protected. 2.2.5. Candidate Node-Protecting PQ Space A node Y is in candidate node-protecting PQ space w.r.t the node (E) being protected, if and only if, Y is present in both node-protecting extended P-space and the Q-space for the link being protected. Please note, that a node Y being in candidate node-protecting PQ- space, does not guarantee that the R-LFA alternate path via the same, in entirety, is unaffected in the event of a node failure of primary nexthop node E. It only guarantees that the path segment from S to PQ-node Y is unaffected by the same failure event. The PQ-nodes in the candidate node-protecting PQ space may provide node protection for only a subset of destinations that are reachable through the corresponding primary link. 2.2.6. Cost-Based Definitions This section provides cost-based definitions for some of the terms introduced in Section 2.2 of this document. 2.2.6.1. Link-Protecting Extended P-Space Please refer to Section 2.2.1 for a formal definition for Link- protecting Extended P-Space. Sarkar, et al. Expires July 24, 2017 [Page 7] Internet-Draft R-LFA Node-Protection and Manageability January 2017 A node Y is in link-protecting extended P-space w.r.t the link (S-E) being protected, if and only if, there exists at least one direct neighbor of S, Ni, other than primary nexthop E, that satisfies the following condition. D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y) Where, D_opt(A,B) : Distance on most optimum path from A to B. Ni : A direct neighbor of S other than primary nexthop E. Y : The node being evaluated for link-protecting extended P-Space. Figure 3: Link-Protecting Ext-P-Space Condition 2.2.6.2. Node-Protecting Extended P-Space Please refer to Section 2.2.2 for a formal definition for Node- protecting Extended P-Space. A node Y is in node-protecting extended P-space w.r.t the node E being protected, if and only if, there exists at least one direct neighbor of S, Ni, other than primary nexthop E, that satisfies the following condition. D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y) Where, D_opt(A,B) : Distance on most optimum path from A to B. E : The primary nexthop on shortest path from S to destination. Ni : A direct neighbor of S other than primary nexthop E. Y : The node being evaluated for node-protecting extended P-Space. Figure 4: Node-Protecting Ext-P-Space Condition Please note, that a node Y satisfying the condition in Figure 4 above only guarantees that the R-LFA alternate path segment from S via direct neighbor Ni to the node Y is not affected in the event of a node failure of E. It does not yet guarantee that the path segment from node Y to the destination is also unaffected by the same failure event. Sarkar, et al. Expires July 24, 2017 [Page 8] Internet-Draft R-LFA Node-Protection and Manageability January 2017 2.2.6.3. Q-Space Please refer to Section 2.2.3 for a formal definition for Q-Space. A node Y is in Q-space w.r.t the link (S-E) being protected, if and only if, the following condition is satisfied. D_opt(Y,E) < D_opt(S,E) + D_opt(Y,S) Where, D_opt(A,B) : Distance on most optimum path from A to B. E : The primary nexthop on shortest path from S to destination. Y : The node being evaluated for Q-Space. Figure 5: Q-Space Condition 2.3. Computing Node-protecting R-LFA Path The R-LFA alternate path through a given PQ-node to a given destination is comprised of two path segments as follows. 1. Path segment from the computing router to the PQ-node (Remote-LFA alternate nexthop), and 2. Path segment from the PQ-node to the destination being protected. So to ensure a R-LFA alternate path for a given destination provides node-protection we need to ensure that none of the above path segments are affected in the event of failure of the primary nexthop node. Sections Section 2.3.1 and Section 2.3.2 show how this can be ensured. 2.3.1. Computing Candidate Node-protecting PQ-Nodes for Primary nexthops To choose a node-protecting R-LFA nexthop for a destination R3, router S needs to consider a PQ-node from the candidate node- protecting PQ-space for the primary nexthop E on shortest path from S to R3. As mentioned in Section 2.2.2, to consider a PQ-node as candidate node-protecting PQ-node, there must be at least one direct neighbor Ni of S, such that all shortest paths from Ni to the PQ-node does not traverse primary nexthop node E. Implementations SHOULD run the inequality in Section 2.2.2 Figure 4 for all direct neighbors, other than primary nexthop node E, to determine whether a node Y is a candidate node-protecting PQ-node. Sarkar, et al. Expires July 24, 2017 [Page 9] Internet-Draft R-LFA Node-Protection and Manageability January 2017 All of the metrics needed by this inequality would have been already collected from the forward SPFs rooted at each of direct neighbor S, computed as part of standard LFA [RFC5286] implementation. With reference to the topology in Figure 2, Table 3 below shows how the above condition can be used to determine the candidate node- protecting PQ-space for S-E link (primary nexthop E). +------------+----------+----------+----------+---------+-----------+ | Candidate | Direct | D_opt | D_opt | D_opt | Condition | | PQ-node | Nbr (Ni) | (Ni,Y) | (Ni,E) | (E,Y) | Met | | (Y) | | | | | | +------------+----------+----------+----------+---------+-----------+ | R2 | N | 2 (N,R2) | 1 (N,E) | 2 | Yes | | | | | | (E,R2) | | | R3 | N | 2 (N,R3) | 1 (N,E) | 1 | No | | | | | | (E,R3) | | +------------+----------+----------+----------+---------+-----------+ Table 3: Node-protection evaluation for R-LFA repair tunnel to PQ- node As seen in the above Table 3, R3 does not meet the node-protecting extended-p-space inequality and so, while R2 is in candidate node- protecting PQ space, R3 is not. Some SPF implementations may also produce a list of links and nodes traversed on the shortest path(s) from a given root to others. In such implementations, router S may have executed a forward SPF with each of its direct neighbors as the SPF root, executed as part of the standard LFA [RFC5286] computations. So S may re-use the list of links and nodes collected from the same SPF computations, to decide whether a node Y is a candidate node-protecting PQ-node or not. A node Y shall be considered as a node-protecting PQ-node, if and only if, there is at least one direct neighbor of S, other than the primary nexthop E, for which, the primary nexthop node E does not exist on the list of nodes traversed on any of the shortest paths from the direct neighbor to the PQ-node. Table 4 below is an illustration of the mechanism with the topology in Figure 2. Sarkar, et al. Expires July 24, 2017 [Page 10] Internet-Draft R-LFA Node-Protection and Manageability January 2017 +-----------+-------------------+-----------------+-----------------+ | Candidate | Repair Tunnel | Link-Protection | Node-Protection | | PQ-node | Path(Repairing | | | | | router to PQ- | | | | | node) | | | +-----------+-------------------+-----------------+-----------------+ | R2 | S->N->R1->R2 | Yes | Yes | | R2 | S->E->R3->R2 | No | No | | R3 | S->N->E->R3 | Yes | No | +-----------+-------------------+-----------------+-----------------+ Table 4: Protection of Remote-LFA tunnel to the PQ-node As seen in the above Table 4 while R2 is candidate node-protecting Remote-LFA nexthop for R3 and D2, it is not so for E and D1, since the primary nexthop E is in the shortest path from R2 to E and D1. 2.3.2. Computing node-protecting paths from PQ-nodes to destinations Once a computing router finds all the candidate node-protecting PQ- nodes for a given directly attached primary link, it shall follow the procedure as proposed in this section, to choose one or more node- protecting R-LFA paths, for destinations reachable through the same primary link in the primary SPF graph. To find a node-protecting R-LFA path for a given destination, the computing router needs to pick a subset of PQ-nodes from the candidate node-protecting PQ-space for the corresponding primary nexthop, such that all the path(s) from the PQ-node(s) to the given destination remain unaffected in the event of a node failure of the primary nexthop node. To determine whether a given PQ-node belongs to such a subset of PQ-nodes, the computing router MUST ensure that none of the primary nexthop node are found on any of the shortest paths from the PQ-node to the given destination. This document proposes an additional forward SPF computation for each of the PQ-nodes, to discover all shortest paths from the PQ-nodes to the destination. This will help determine, if a given primary nexthop node is on the shortest paths from the PQ-node to the given destination or not. To determine if a given candidate node- protecting PQ-node provides node-protecting alternate for a given destination, or not, all the shortest paths from the PQ-node to the given destination has to be inspected, to check if the primary nexthop node is found on any of these shortest paths. To compute all the shortest paths from a candidate node-protecting PQ-node to one (or more) destination, the computing router MUST run the forward SPF on the candidate node-protecting PQ-node. Soon after running the forward SPF, the computer router SHOULD run the inequality in Sarkar, et al. Expires July 24, 2017 [Page 11] Internet-Draft R-LFA Node-Protection and Manageability January 2017 Figure 6 below, once for each destination. A PQ-node that does not qualify the condition for a given destination, does not guarantee node-protection for the path segment from the PQ-node to the specific destination. D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D) Where, D_opt(A,B) : Distance on most optimum path from A to B. D : The destination node. E : The primary nexthop on shortest path from S to destination. Y : The node-protecting PQ-node being evaluated Figure 6: Node-Protecting Condition for PQ-node to Destination All of the above metric costs except D_opt(Y, D), can be obtained with forward and reverse SPFs with E(the primary nexthop) as the root, run as part of the regular LFA and Remote-LFA implementation. The Distance_opt(Y, D) metric can only be determined by the additional forward SPF run with PQ-node Y as the root. With reference to the topology in Figure 2, Table 5 below shows how the above condition can be used to determine node-protection with node- protecting PQ-node R2. +-------------+------------+---------+--------+---------+-----------+ | Destination | Primary-NH | D_opt | D_opt | D_opt | Condition | | (D) | (E) | (Y, D) | (Y, E) | (E, D) | Met | +-------------+------------+---------+--------+---------+-----------+ | R3 | E | 1 | 2 | 1 | Yes | | | | (R2,R3) | (R2,E) | (E,R3) | | | E | E | 2 | 2 | 0 (E,E) | No | | | | (R2,E) | (R2,E) | | | | D1 | E | 3 | 2 | 1 | No | | | | (R2,D1) | (R2,E) | (E,D1) | | | D2 | E | 2 | 2 | 1 | Yes | | | | (R2,D2) | (R2,E) | (E,D2) | | +-------------+------------+---------+--------+---------+-----------+ Table 5: Node-protection evaluation for R-LFA path segment between PQ-node and destination As seen in the above example above, R2 does not meet the node- protecting inequality for destination E, and D1. And so, once again, while R2 is a node-protecting Remote-LFA nexthop for R3 and D2, it is not so for E and D1. Sarkar, et al. Expires July 24, 2017 [Page 12] Internet-Draft R-LFA Node-Protection and Manageability January 2017 In SPF implementations that also produce a list of links and nodes traversed on the shortest path(s) from a given root to others, the inequality in Figure 6 above need not be evaluated. Instead, to determine whether a PQ-node provides node-protection for a given destination or not, the list of nodes computed from forward SPF run on the PQ-node, for the given destination, SHOULD be inspected. In case the list contains the primary nexthop node, the PQ-node does not provide node-protection. Else, the PQ-node guarantees node- protecting alternate for the given destination. Below is an illustration of the mechanism with candidate node-protecting PQ-node R2 in the topology in Figure 2. +-------------+-----------------+-----------------+-----------------+ | Destination | Shortest Path | Link-Protection | Node-Protection | | | (Repairing | | | | | router to PQ- | | | | | node) | | | +-------------+-----------------+-----------------+-----------------+ | R3 | R2->R3 | Yes | Yes | | E | R2->R3->E | Yes | No | | D1 | R2->R3->E->D1 | Yes | No | | D2 | R2->R3->D2 | Yes | Yes | +-------------+-----------------+-----------------+-----------------+ Table 6: Protection of Remote-LFA path between PQ-node and destination As seen in the above example while R2 is candidate node-protecting R-LFA nexthop for R3 and D2, it is not so for E and D1, since the primary nexthop E is in the shortest path from R2 to E and D1. The procedure described in this document helps no more than to determine whether a given Remote-LFA alternate provides node- protection for a given destination or not. It does not find out any new Remote-LFA alternate nexthops, outside the ones already computed by standard Remote-LFA procedure. However, in case of availability of more than one PQ-node (Remote-LFA alternates) for a destination, and node-protection is required for the given primary nexthop, this procedure will eliminate the PQ-nodes that do not provide node- protection and choose only the ones that does. 2.3.3. Computing Node-Protecting R-LFA Paths for Destinations with ECMP primary nexthop nodes In certain scenarios, when one or more destinations maybe reachable via multiple ECMP (equal-cost-multi-path) nexthop nodes, and only link-protection is required, there is no need to compute any alternate paths for such destinations. In the event of failure of Sarkar, et al. Expires July 24, 2017 [Page 13] Internet-Draft R-LFA Node-Protection and Manageability January 2017 one of the nexthop links, the remaining primary nexthops shall always provide link-protection. However, if node-protection is required, the rest of the primary nexthops may not guarantee node-protection. Figure 7 below shows one such example topology. D1 2 / S---x---E1 / \ / \ / x / \ / \ / \ N-------E2 R3--D2 \ 2 / \ / \ / R1-------R2 2 Primary Nexthops: Destination D1 = [{ S-E1, E1}, {S-E2, E2}] Destination D2 = [{ S-E1, E1}, {S-E2, E2}] Figure 7: Topology with multiple ECMP primary nexthops In the above example topology, costs of all links are 1, except the following links: Link: S-E1, Cost: 2 Link: N-E2: Cost: 2 Link: R1-R2: Cost: 2 In the above topology, on computing router S, destinations D1 and D2 are reachable via two ECMP nexthop nodes E1 and E2. However the primary paths via nexthop node E2 also traverses via the nexthop node E1. So in the event of node failure of nexthop node E1, both primary paths (via E1 and E2) becomes unavailable. Hence if node-protection is desired for destinations D1 and D2, alternate paths that does not traverse any of the primary nexthop nodes E1 and E2, need to be computed. In the above topology the only alternate neighbor N does not provide such a LFA alternate path. Hence one (or more) R-LFA node-protecting alternate paths for destinations D1 and D2, needs to be computed. In the above topology, following are the link-protecting PQ-nodes. Sarkar, et al. Expires July 24, 2017 [Page 14] Internet-Draft R-LFA Node-Protection and Manageability January 2017 Primary Nexthop: E1, Link-Protecting PQ-Node: { R2 } Primary Nexthop: E2, Link-Protecting PQ-Node: { R2 } To find one (or more) node-protecting R-LFA paths for destinations D1 and D2, one (or more) node-protecting PQ-node(s) needs to be determined first. Inequalities specified in Section 2.2.6.2 and Section 2.2.6.3 can be evaluated to compute the node-protecting PQ- space for each of the nexthop nodes E1 and E2, as shown in Table 7 below. To select a PQ-node as node-protecting PQ-node for a destination with multiple primary nexthop nodes, the PQ-node MUST satisfy the inequality for all primary nexthop nodes. Any PQ-node which is NOT node-protecting PQ-node for all the primary nexthop nodes, MUST NOT be chosen as the node-protecting PQ-node for destination. +--------+----------+-------+--------+--------+---------+-----------+ | Primar | Candidat | Direc | D_opt | D_opt | D_opt | Condition | | y Next | e PQ- | t Nbr | (Ni,Y) | (Ni,E) | (E,Y) | Met | | hop | node (Y) | (Ni) | | | | | | (E) | | | | | | | +--------+----------+-------+--------+--------+---------+-----------+ | E1 | R2 | N | 3 | 3 | 2 | Yes | | | | | (N,R2) | (N,E1) | (E1,R2) | | | E2 | R2 | N | 3 | 2 | 3 | Yes | | | | | (N,R2) | (N,E2) | (E2,R2) | | +--------+----------+-------+--------+--------+---------+-----------+ Table 7: Computing Node-protected PQ-nodes for nexthop E1 and E2 In SPF implementations that also produce a list of links and nodes traversed on the shortest path(s) from a given root to others, the tunnel-repair paths from the computing router to candidate PQ-node can be examined to ensure that none of the primary nexthop nodes is traversed. PQ-nodes that provide one (or more) Tunnel-repair paths(s) that does not traverse any of the primary nexthop nodes, are to be considered as node-protecting PQ-nodes. Table 8 below shows the possible tunnel-repair paths to PQ-node R2. +--------------+------------+-------------------+-------------------+ | Primary-NH | PQ-Node | Tunnel-Repair | Exclude All | | (E) | (Y) | Paths | Primary-NH | +--------------+------------+-------------------+-------------------+ | E1, E2 | R2 | S==>N==>R1==>R2 | Yes | +--------------+------------+-------------------+-------------------+ Table 8: Tunnel-Repair paths to PQ-node R2 Sarkar, et al. Expires July 24, 2017 [Page 15] Internet-Draft R-LFA Node-Protection and Manageability January 2017 From Table 7 and Table 8, in the above example, R2 being node- protecting PQ-node for both primary nexthops E1 and E2, should be chosen as the node-protecting PQ-node for destinations D1 and D2 that are both reachable via primary nexthop nodes E1 and E2. Next, to find a node-protecting R-LFA path from node-protecting PQ- node to destinations D1 and D2, inequalities specified in Figure 6 should be evaluated, to ensure if R2 provides a node-protecting R-LFA path for each of these destinations, as shown below in Table 9. For a R-LFA path to qualify as node-protecting R-LFA path for a destination with multiple ECMP primary nexthop nodes, the R-LFA path from the PQ-node to the destination MUST satisfy the inequality for all primary nexthop nodes. +----------+----------+-------+--------+--------+--------+----------+ | Destinat | Primary- | PQ- | D_opt | D_opt | D_opt | Conditio | | ion (D) | NH (E) | Node | (Y, D) | (Y, E) | (E, D) | n Met | | | | (Y) | | | | | +----------+----------+-------+--------+--------+--------+----------+ | D1 | E1 | R2 | 3 (R2, | 2 (R2, | 1 (E1, | No | | | | | D1) | E1) | D1) | | | D1 | E2 | R2 | 3 (R2, | 3 (R2, | 2 (E2, | Yes | | | | | D1) | E2) | D1) | | | D2 | E1 | R2 | 2 (R2, | 2 (R2, | 2 (E1, | Yes | | | | | D2) | E1) | D2) | | | D2 | E2 | R2 | 2 (R2, | 2 (R2, | 3 (E2, | Yes | | | | | D2) | E2) | D2) | | +----------+----------+-------+--------+--------+--------+----------+ Table 9: Finding node-protecting R-LFA path for destinations D1 and D2 In SPF implementations that also produce a list of links and nodes traversed on the shortest path(s) from a given root to others, the R-LFA paths via node-protecting PQ-node to final destination can be examined to ensure that none of the primary nexthop nodes is traversed. R-LFA path(s) that does not traverse any of the primary nexthop nodes, guarantees node-protection in the event of failure of any of the primary nexthop nodes. Table 10 below shows the possible R-LFA-paths for destinations D1 and D2 via the node-protecting PQ- node R2. Sarkar, et al. Expires July 24, 2017 [Page 16] Internet-Draft R-LFA Node-Protection and Manageability January 2017 +-------------+------------+---------+-----------------+------------+ | Destination | Primary-NH | PQ-Node | R-LFA Paths | Exclude | | (D) | (E) | (Y) | | All | | | | | | Primary-NH | +-------------+------------+---------+-----------------+------------+ | D1 | E1, E2 | R2 | S==>N==>R1==>R2 | No | | | | | -->R3-->E1-->D1 | | | | | | | | | D2 | E1, E2 | R2 | S==>N==>R1==>R2 | Yes | | | | | -->R3-->D2 | | +-------------+------------+---------+-----------------+------------+ Table 10: R-LFA paths for destinations D1 and D2 From Table 9 and Table 10, in the example above, the R-LFA path from R2 does not meet the node-protecting inequality for destination D1, while it does meet the same inequality for destination D2. And so, while R2 provides node-protecting R-LFA alternate for D2, it fails to provide node-protection for destination D1. Finally, while it is possible to get a node-protecting R-LFA path for D2, no such node- protecting R-LFA path can be found for D1. 2.3.4. Limiting extra computational overhead In addition to the extra reverse SPF computations suggested by the Remote-LFA [RFC7490] draft (one reverse SPF for each of the directly connected neighbors), this document proposes a forward SPF computations for each PQ-node discovered in the network. Since the average number of PQ-nodes found in any network is considerably more than the number of direct neighbors of the computing router, the proposal of running one forward SPF per PQ-node may add considerably to the overall SPF computation time. To limit the computational overhead of the approach proposed, this document specifies that implementations MUST choose a subset from the entire set of PQ-nodes computed in the network, with a finite limit on the number of PQ-nodes in the subset. Implementations MUST choose a default value for this limit and may provide user with a configuration knob to override the default limit. This document suggests 16 as a default value for this limit. Implementations MUST also evaluate some default preference criteria while considering a PQ-node in this subset. The exact default preference criteria to be used is outside the scope of this document, and is a matter of implementation. Finally, implementations MAY also allow the user to override the default preference criteria, by providing a policy configuration for the same. Sarkar, et al. Expires July 24, 2017 [Page 17] Internet-Draft R-LFA Node-Protection and Manageability January 2017 This document proposes that implementations SHOULD use a default preference criteria for PQ-node selection which will put a score on each PQ-node, proportional to the number of primary interfaces for which it provides coverage, its distance from the computing router, and its router-id (or system-id in case of IS-IS). PQ-nodes that cover more primary interfaces SHOULD be preferred over PQ-nodes that cover fewer primary interfaces. When two or more PQ-nodes cover the same number of primary interfaces, PQ-nodes which are closer (based on metric) to the computing router SHOULD be preferred over PQ-nodes farther away from it. For PQ-nodes that cover the same number of primary interfaces and are the same distance from the computing router, the PQ-node with smaller router-id (or system-id in case of IS-IS) SHOULD be preferred. Once a subset of PQ-nodes is found, computing router shall run a forward SPF on each of the PQ-nodes in the subset to continue with procedures proposed in Section 2.3.2. 3. Manageability of Remote-LFA Alternate Paths 3.1. The Problem With the regular Remote-LFA [RFC7490] functionality the computing router may compute more than one PQ-node as usable Remote-LFA alternate nexthops. Additionally [RFC7916] specifies a LFA (and Remote-LFA) manageability framework, in which an alternate selection policy may be configured to let the network operator choose one of them as the most appropriate Remote-LFA alternate. For such policy- based alternate selection to run, the computing router needs to collect all the relevant path characteristics (as specified in section 6.2.4 of [RFC7916]) for each of the alternate paths (one through each of the PQ-nodes). As mentioned before in Section 2.3 the R-LFA alternate path through a given PQ-node to a given destination is comprised of two path segments. Section 6.2.5.4 of [RFC7916] specifies that any kind of alternate selection policy must consider path characteristics for both path segments while evaluating one or more RLFA alternate path(s). The first path segment (i.e. from the computing router to the PQ- node) can be calculated from the regular forward SPF done as part of standard and remote LFA computations. However without the mechanism proposed in Section 2.3.2 of this document, there is no way to determine the path characteristics for the second path segment (i.e. from the PQ-node to the destination). In the absence of the path characteristics for the second path segment, two Remote-LFA alternate paths may be equally preferred based on the first path segments characteristics only, although the second path segment attributes may be different. Sarkar, et al. Expires July 24, 2017 [Page 18] Internet-Draft R-LFA Node-Protection and Manageability January 2017 3.2. The Solution The additional forward SPF computation proposed in Section 2.3.2 document shall also collect links, nodes and path characteristics along the second path segment. This shall enable collection of complete path characteristics for a given Remote-LFA alternate path to a given destination. The complete alternate path characteristics shall then facilitate more accurate alternate path selection while running the alternate selection policy. As already specified in Section 2.3.4 to limit the computational overhead of the proposed approach, forward SPF computations must be run on a selected subset from the entire set of PQ-nodes computed in the network, with a finite limit on the number of PQ-nodes in the subset. The detailed suggestion on how to select this subset is specified in the same section. While this limits the number of possible alternate paths provided to the alternate-selection policy, this is needed to keep the computational complexity within affordable limits. However if the alternate-selection policy is very restrictive this may leave few destinations in the entire topology without protection. Yet this limitation provides a necessary tradeoff between extensive coverage and immense computational overhead. The mechanism proposed in this section does not modify or invalidate [RFC7916] or any parts of it. This document specifies a mechanism to meet the requirements specified in section 6.5.2.4 in [RFC7916]. 4. Acknowledgements Many thanks to Bruno Decraene for providing his useful comments. We would also like to thank Uma Chunduri for reviewing this document and providing valuable feedback. Also, many thanks to Harish Raghuveer for his review and comments on the initial versions of this document. 5. IANA Considerations N/A. - No protocol changes are proposed in this document. 6. Security Considerations This document does not introduce any change in any of the protocol specifications. It simply proposes to run an extra SPF rooted on each PQ-node discovered in the whole network. Sarkar, et al. Expires July 24, 2017 [Page 19] Internet-Draft R-LFA Node-Protection and Manageability January 2017 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, . [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, . 7.2. Informative References [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., and P. Sarkar, "Operational Management of Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, July 2016, . Authors' Addresses Pushpasis Sarkar (editor) Individual Contributor Email: pushpasis.ietf@gmail.com Shraddha Hegde Juniper Networks, Inc. Electra, Exora Business Park Bangalore, KA 560103 India Email: shraddha@juniper.net Sarkar, et al. Expires July 24, 2017 [Page 20] Internet-Draft R-LFA Node-Protection and Manageability January 2017 Chris Bowers Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: cbowers@juniper.net Hannes Gredler RtBrick, Inc. Email: hannes@rtbrick.com Stephane Litkowski Orange Email: stephane.litkowski@orange.com Sarkar, et al. Expires July 24, 2017 [Page 21] ./draft-ietf-sidr-adverse-actions-04.txt0000664000764400076440000017465113036077060017424 0ustar iustyiusty SIDR S. Kent Internet-Draft BBN Technologies Intended status: Informational D. Ma Expires: July 16, 2017 ZDNS January 12, 2017 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) draft-ietf-sidr-adverse-actions-04 Abstract This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 16, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Kent & Ma Expires July 16, 2017 [Page 1] Internet-Draft RPKI Adverse CA Actions January 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11 2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 20 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction In the context of this document, any change to the Resource Public Key Infrastructure (RPKI) [RFC6480] that diminishes the set of Internet Number Resources (INRs) associated with an INR holder, and that is contrary to the holder's wishes, is termed "adverse". This analysis is done from the perspective of an affected INR holder. An action that results in an adverse charge (as defined above), may be the result of an attack on a CA [RFC7132], an error by a CA, or an error by or an attack on a repository operator. Note that the CA that allocated the affected INRs may be acting in accordance with established policy, and thus the change may be contractually justified, even though viewed as adverse by the INR holder. This document examines the implications of adverse actions within the RPKI with respect to INRs irrespective of the cause of the actions. Kent & Ma Expires July 16, 2017 [Page 2] Internet-Draft RPKI Adverse CA Actions January 2017 Additionally, when a ROA or router certificate is created that "competes" with an existing ROA or router certificate (respectively), the creation of the new ROA or router certificate may be adverse. (A newer ROA competes with an older ROA if the newer ROA points to a different ASN, contains the same or a more specific prefix, and is issued by a different CA. A newer router certificate competes with an older router certificate if the newer one contains the same ASN a different public key, and is issued by a different CA.) Note that transferring resources, or changing of upstream providers may yield competing ROAs and/or router certificates, under some circumstances. Thus not all instances of competition are adverse actions. As noted above, adverse changes to RPKI data may arise due to several types of causes. A CA may make a mistake in managing the RPKI objects it signs, or it may be subject to an attack. If an attack allows an adversary to use the private key of that CA to sign RPKI objects, then the effect is analogous to the CA making mistakes. There is also the possibility that a CA or repository operator may be subject to legal measures that compel them to make adverse changes to RPKI data. In many cases, such actions may be hard to distinguish from mistakes or attacks, other than with respect to the time required to remedy the adverse action. (Presumably the CA will take remedial action when a mistake or an attack is detected, so the effects are similar in these cases. If a CA has been legally compelled to effect an adverse change, remediation will likely not be swift.) This document analyzes the various types of actions by a CA (or independent repository operator) that can adversely affect the INRs associated with that CA, as well as the INRs of subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository operator) and fetched by Relying Parties (RPs). 2. Analysis of RPKI Repository Objects This section enumerates the RPKI repository system objects and examines how changes to them affect Route Origination Authorizations (ROAs) and router certificate validation. Identifiers are assigned to errors for reference by later sections of this document. Note that not all adverse actions may be encompassed by this taxonomy. The RPKI repository [RFC6481] contains a number of (digitally signed) objects that are fetched and processed by RPs. Until the deployment of BGPsec [I-D.ietf-sidr-bgpsec-protocol], the principal goal of the RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds address space to an Autonomous System Number (ASN). A ROA can be used to verify BGP announcements with respect to route origin Kent & Ma Expires July 16, 2017 [Page 3] Internet-Draft RPKI Adverse CA Actions January 2017 [RFC6483]. The most important objects in the RPKI for origin validation are ROAs; all of the other RPKI objects exist to enable the validation of ROAs in a fashion consistent with the INR allocation system. Thus errors that result in changes to a ROA, or to RPKI objects needed to validate a ROA, can cause RPs to reach different (from what was intended) conclusions about the validity of the bindings expressed in a ROA. When BGPsec is deployed, router certificates [I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository publication points. These are End-Entity (EE) certificates used to verify signatures applied to BGP update data, to enable path validation [I-D.ietf-sidr-bgpsec-protocol]. Router certificates are as important to path validation as ROAs are to origin validation. The objects contained in the RPKI repository are of two types: conventional PKI objects (certificates and Certificate Revocation Lists (CRLs)) and RPKI-specific signed objects. The latter make use of a common encapsulation format [RFC6488] based on the Cryptographic Message Syntax (CMS) [RFC5652]. A syntax error in this common format will cause an RP to reject the object, e.g., a ROA or Manifest, as invalid. Adverse actions take several forms: * Deletion (D) is defined as removing an object from a publication point, without the permission of the INR holder. * Suppression (S) is defined as not deleting an object, or not publishing an object, as intended by an INR holder. This action also includes retaining a prior version of an object in a publication point when a newer version is available for publication. * Corruption (C) is defined as modification of a signed object in a fashion not requiring access to the private key used to sign the object. Thus a corrupted object will not carry a valid signature. Implicitly, the corrupted object replaces the legitimate version. * Modification (M) is defined as publishing a syntactically valid, verifiable version of an object that differs from the (existing) version authorized by the INR holder. Implicitly, the legitimate version of the affected object is deleted and replaced by the modified object. Kent & Ma Expires July 16, 2017 [Page 4] Internet-Draft RPKI Adverse CA Actions January 2017 * Revocation (R) is defined as revoking a certificate (EE or CA) by placing its serial number on the appropriate CRL, without authorization of the INR holder. * Injection (I) is defined as introducing an instance of a signed object into a publication point (without authorization of the INR holder). It assumes that the signature on the object will be viewed as valid by RPs. The first three of these actions (deletion, suppression, and corruption) can be effected by any entity that manages the publication point of the affected INR holder. Also, an entity with the ability to act as a man-in-the-middle between an RP and a repository can effect these actions with respect to the RP in question. The latter three actions (modification, revocation, and injection) nominally require access to the private key of the INR holder. All six of these actions also can be effected by a parent CA. A parent CA could reissue the INR holder's CA certificate, but with a different public key, matching a private key to which the parent CA has access. The CA could generate new signed objects using the private key associated with the reissued certificate, and publish these objects at a location of its choosing. Most of these actions may be performed independently or in combination with one another. For example, a ROA may be revoked and deleted or revoked and replaced with a modified ROA. Where appropriate, the analysis of adverse actions will distinguish between individual actions, or combinations thereof, that yield different outcomes for RPs. Recall that the focus of the analysis is the impact on ROAs and router certificates, with respect to RP processing. The following sections examine how the actions enumerated above affect objects in the RPKI repository system. Each action is addressed in order (Deletion, Suppression, Corruption, Modification, Revocation, and Injection) for each object, making it easy to see how each action has been considered with regard to each object. (For the GhostBusters record we condensed the discussion of the actions because the impact is the same in each case.) 2.1. CA Certificates Every INR holder is represented by one or more CA certificates. An INR holder has multiple CA certificates if it holds resources acquired from different sources. Also, every INR holder has more Kent & Ma Expires July 16, 2017 [Page 5] Internet-Draft RPKI Adverse CA Actions January 2017 than one CA certificate during key rollover [RFC6489] and algorithm rollover [RFC6916]. If a publication point is not a leaf in the RPKI hierarchy, then the publication point will contain one or more CA certificates, each representing a subordinate CA. Each subordinate CA certificate contains a pointer (SIA) to the publication point where the signed objects associated with that CA can be found [RFC6487]. A CA certificate is a complex data structure and thus errors in that structure may have different implications for RPs depending on the specific data that is in error. Adverse actions against a CA certificate can cause the following errors: A-1.1 Deletion A-1.1.1 Deletion of a CA certificate would cause an RP to not be able to locate signed objects generated by that CA, except those that have been cached by the RP. Thus an RP would be unaware of changed or new (issued after the cached data) INR bindings asserted in subordinate ROAs, and the RP would be unable to validate new or changed router certificates. If the missed objects were intended to replace ROAs or router certificates prior to expiration, then when those objects expire, RPs may cease to view them as valid. As a result, valid routes may be viewed as NotFound or Invalid. A-1.2 Suppression A-1.2.1 If publication of a CA certificate is suppressed, the impact depends on what changes appeared in the suppressed certificate. If the SIA value changed, the effect would be the same as in A-1.1 or A-1.4.3. If the [RFC3779] extensions in the suppressed certificate changed, the impact would be the same as in A-1.4.1. If the AIA extension changed in the suppressed certificate, the impact would be the same as in A-1.4.4. Suppression of a renewed/re-issued certificate may cause an old certificate to expire and thus be rejected by RPs. A-1.3 Corruption Kent & Ma Expires July 16, 2017 [Page 6] Internet-Draft RPKI Adverse CA Actions January 2017 A-1.3.1 Corruption of a CA certificate will cause it to be rejected by RPs. In turn, this may cause subordinate signed objects to become invalid. An RP that has cached the subtree under the affected CA certificate may continue to view it as valid, until objects expire. But changed or new objects might not be retrieved, depending on details of the design of the RP software. Thus this action may be equivalent to suppressing changes to the affected subtree. A-1.4 Modification A-1.4.1 If a CA certificate is modified, but still conforms to the RPKI certificate profile [RFC7935], it will be accepted by RPs. If an [RFC3779] extension in this certificate is changed to exclude INRs that were previously present, then subordinate signed objects will become invalid if they rely on the excised INRs. If these objects are CA certificates, their subordinate signed objects will be treated as invalid. If the objects are ROAs, the binding expressed by the affected ROAs will be ignored by RPs. If the objects are router certificates, BGPsec_Path attributes [I-D.ietf-sidr-bgpsec-protocol] verifiable under these certificates will be considered invalid. A-1.4.2 If the SIA extension of a CA certificate is modified to refer to another publication point, this will cause an RP to look at another location for subordinate objects. This could cause RPs to not acquire the objects that the INR holder intended to be retrieved - manifests, ROAs, router certificates, Ghostbuster records, or any subordinate CA certificates associated with that CA. If the objects at this new location contain invalid signatures or appear to be corrupted, they may be rejected. In this case, cached versions of the objects may be viewed as valid by an RP, until they expire. If the objects at the new location have valid signatures and pass path validation checks, they will replace the cached objects, effectively replacing the INR holder's objects. A-1.4.3 If the AIA extension in a CA certificate is modified, it would point to a different CA Kent & Ma Expires July 16, 2017 [Page 7] Internet-Draft RPKI Adverse CA Actions January 2017 certificate, not the parent CA certificate. This extension is used only for path discovery, not path validation. Path discovery in the RPKI is usually performed on a top-down basis, starting with TAs and recursively descending the RPKI hierarchy. Thus there may be no impact on the ability of clients to acquire and validate certificates if the AIA is modified. A-1.4.4 If the Subject Public Key Info (and Subject Key Identifier extension) in a CA certificate is modified to contain a public key corresponding to a private key held by the parent, the parent could sign objects as children of the affected CA certificate. With this capability, the parent could replace the INR holder, issuing new signed objects that would be accepted by RPs (as long as they do not violate the path validation criteria). This would enable the parent to effect modification, revocation, and injection actions against all of the objects under the affected CA certificate, including subordinate CA certificates. (Note that key rollover also yields a new CA certificate. However, the new certificate will co-exist with the old one for a while, which may help distinguish this legitimate activity from an adverse action.) A-1.5 Revocation A-1.5.1 If a CA certificate is revoked an RP will treat as invalid all subordinate signed objects, both immediate and transitively. The effects are essentially the same as described in A-3.4.2. A-1.6 Injection A-1.6.1 If a CA certificate is injected the impact will depend on the data contained in the injected certificate. Changes will generally be equivalent to modification actions as described in A-1.4. 2.2. Manifest Each repository publication point contains a manifest [RFC6486]. The RPKI incorporates manifests to enable RPs to detect suppression and/ or substitution of (more recent) publication point objects, as the result of a mistake or attack. A manifest enumerates (by filename) Kent & Ma Expires July 16, 2017 [Page 8] Internet-Draft RPKI Adverse CA Actions January 2017 all of the other signed objects at the publication point. The manifest also contains a hash of each enumerated file, to enable an RP to determine if the named file content matches what the INR holder identified in the manifest. A manifest is an RPKI signed object, so it is validated as per [RFC6488]. If a manifest is modified in a way that causes any of these checks to fail, the manifest will be considered invalid. Suppression of a manifest itself (indicated by a stale manifest) also can cause an RP to not detect suppression of other signed objects at the publication point. (Note that if a Manifest's EE certificate expires at the time that the Manifest is scheduled to be replaced, a delay in publication will cause the Manifest to become invalid, not merely stale. This very serious outcome should be avoided, e.g., by making the Manifest EE certificate's notAfter value the same as that of the CA certificate under which it was issued). If a signed object at a publication point can be validated (using the rules applicable for that object type), then an RP may accept that object, even if there is no matching entry for it on the manifest. However, it appears that most RP software ignores publication point data that fails to match Manifest entries (at the time this document was written). Corruption, suppression, modification, or deletion of a manifest might not affect RP processing of other publication point objects, as specified in [RFC6486]. However, as noted above, many RP implementations ignore objects that are present at a publication point but not listed in a valid Manifest. Thus the following actions against a manifest can impact RP processing: A-2.1 Deletion A-2.1.1 A Manifest may be deleted from the indicated publication point. In this circumstance an RP may elect to use the previous Manifest (if available), and may ignore any new/changed objects at the publication point. The implications of this action are equivalent to suppression of publication of the objects that are not recognized by RPs because the new objects are not present in the old Manifest. For example, a new ROA could be ignored (A-1.2). A newly issued CA certificate might be ignored (A-1.1). A subordinate CA certificate that was revoked might still be viewed as valid by RPs (A-4.1). A new or changed router Kent & Ma Expires July 16, 2017 [Page 9] Internet-Draft RPKI Adverse CA Actions January 2017 certificate might be ignored (A-6.2) as would a revised Ghostbusters record (A-4.1). A-2.2 Suppression A-2.2.1 Publication of a newer Manifest may be suppressed. Suppression of a newer Manifest probably will cause an RP to rely on a cached Manifest (if available). The older Manifest would not enumerate newly added objects, and thus those objects might be ignored by an RP, equivalent to deletion of those objects (A-1.1, A-3.1, A-4.1, A-5.1, A-6.1). A-2.3 Corruption A-2.3.1 A Manifest may be corrupted. A corrupted Manifest will be rejected by RPs. This may cause RPs to rely on a previous manifest, with the same impact as A-2.2. If an RP does not revert to using a cached Manifest, the impact of this action is very severe, i.e., all publication point objects probably will be viewed as invalid, including subordinate tree objects. This is equivalent to revoking or deleting an entire subtree (see A-4.4.2). A-2.4 Modification A-2.4.1 A Manifest may be modified to remove one or more objects. Because the modified Manifest is viewed as valid by RPs, any objects that were removed may be ignored by RPs. This is equivalent to deleting these objects from the repository. The impact of this action will vary, depending on which objects are (effectively) removed. However, the impact is equivalent to deletion of the object in question, (A-1.1, A-3.1, A-4.1, A-5.1, A-6.1). A-2.4.2 A Manifest may be modified to add one or more objects. If an added object has a valid signature (and is non-expired), it will be accepted by RPs and processed accordingly. If the added object was previously deleted by the INR holder, this action is equivalent to suppressing deletion of that object. If the object is newly created, or modified, it is equivalent to a modification or injection action for the type of object in Kent & Ma Expires July 16, 2017 [Page 10] Internet-Draft RPKI Adverse CA Actions January 2017 question, and thus is discussed in the relevant section for those actions for the object type. A-2.4.3 A Manifest may be modified to list an incorrect hash for one or more objects. An object with an incorrect hash may be ignored by an RP. Thus the effect may be equivalent to corrupting the object in question, although the error reported by RP software would differ from that reported for a corrupted object. (The Manifest specifications do not require an RP to ignore an object that has a valid signature and that is not revoked or expired, but for which the hash doesn't match the object. However, an RP may elect to do so.) A-2.5 Revocation A-2.5.1 A Manifest may be revoked (by including its EE certificate on the CRL for the publication point). A revoked Manifest will be ignored by an RP, which probably would revert to an older (cached) Manifest. The implications for RPs are equivalent to A-2.1, with regard to new/changed objects. A-2.6 Injection A-2.6.1 A Manifest representing different objects may be injected into a publication point. The effects are the same as for a modified Manifest (see above). The impact will depend on the type of the affected object(s), and thus is discussed in the relevant section(s) for each object type. 2.3. Certificate Revocation List Each publication point contains a CRL that enumerates revoked (not yet expired) certificates issued by the CA associated with the publication point [RFC6481]. Adverse actions against a CRL can cause the following errors: A-3.1 Deletion A-3.1.1 If a CRL is deleted, RPs will continue to use an older, previously fetched Certificate Revocation List. As a result, they will not be informed of Kent & Ma Expires July 16, 2017 [Page 11] Internet-Draft RPKI Adverse CA Actions January 2017 any changes in revocation status of subordinate CA or router certificates or the EE certificates of signed objects, e.g., ROAs. This action is equivalent to corruption of a CRL, since a corrupted CRL will not be accepted by an RP. A-3.1.2 Deletion of a CRL could cause an RP to continue to accept a ROA that no longer expresses the intent of an INR holder. As a result, an announcement for the affected prefixes would be viewed as Valid, instead of NotFound or Invalid. In this case, the effect is analogous to A-5.2. A-3.1.3 If a router certificate were revoked, and the CRL were deleted, RPs would not be aware of the revocation. They might continue to accept the old, revoked, router certificate. If the certificate had been revoked due to a compromise of the router's private key, RPs would be vulnerable to accepting routes signed by an unauthorized entity. A-3.1.4 If a subordinate CA certificate were revoked on the deleted CRL, the revocation would not take effect. This could interfere with a transfer of address space from the subordinate CA, adversely affecting routing to the new holder of the space. A-3.2 Suppression A-3.2.1 If publication of the most recent CRL is suppressed, an RP will not be informed of the most recent revocation status of subordinate CA or router certificates or the EE certificates of signed objects. If an EE certificate has been revoked and the associated signed object is still present in the publication point, an RP might mistakenly treat that object as valid. (This would happen if the object is still in the manifest or the RP is configured to process valid objects that are not on the manifest.) This type of action is of special concern if the affected object is a ROA, a router certificate, or a subordinate CA certificate. The effects here are equivalent to CRL deletion (A-3.1), but suppression of a new CRL may not even be reported as an error, i.e., if the suppressed CRL were Kent & Ma Expires July 16, 2017 [Page 12] Internet-Draft RPKI Adverse CA Actions January 2017 issued before the NextUpdate time (of the previous CRL). A-3.3 Corruption A-3.3.1 If a CRL is corrupted, an RP will reject it. If a prior CRL has not yet exceeded its NextUpdate time, an RP will continue to use the prior CRL. Even if the prior CRL has passed the NextUpdate time, an RP may choose to continue to rely on the prior CRL. The effects are essentially equivalent to suppression or deletion of a CRL (A-3.1, A-3.2). A-3.4 Modification A-3.4.1 If a CRL is modified to erroneously list a signed object's EE certificate as revoked, the corresponding object will be treated as invalid by RPs, even if it is present in a publication point. If this object is a ROA, the (legitimate) binding expressed by the ROA will be ignored by an RP (see A-5.5). If a CRL is modified to erroneously list a router certificate as revoked, a path signature associated with that certificate will be treated as Not Valid by RPs (see A-6.5). A-3.4.2 If a CRL is modified to erroneously list a CA certificate as revoked, that CA and all subordinate signed objects will be treated as invalid by RPs. Depending on the location of the affected CA in the hierarchy, these effects could be very substantial, causing routes that should be Valid to be treated as NotFound. A-3.4.3 If a CRL is modified to omit a revoked EE, router, or CA certificate, RPs likely will continue to accept the revoked, signed object as valid. This contravenes the intent of the INR holder. If an RP continues to accept a revoked ROA, it may make routing decisions on now-invalid data. This could cause valid routes to be de-preferenced and invalid routes to continue to be accepted. A-3.5 Revocation A-3.5.1 A CRL cannot be revoked, per se, but it will fail validation if the CA certificate under which it Kent & Ma Expires July 16, 2017 [Page 13] Internet-Draft RPKI Adverse CA Actions January 2017 was issued is revoked. See A-1.5 for a discussion of that action. A-3.6 Injection A-3.6.1 Insertion of a bogus CRL can have the same effects as listed above for a modified CRL, depending on how the inserted CRL differs from the correct CRL. 2.4. ROA In addition to the generic RPKI object syntax checks, ROA validation requires that the signature on the ROA can be validated using the public key from the EE certificate embedded in the ROA [RFC6482]. It also requires that the EE certificate be validated consistently with the procedures described in [RFC6482] and [RFC6487]. Adverse actions against a ROA can cause the following errors: A-4.1 Deletion A-4.1.1 A ROA may be deleted from the indicated publication point. The result is to void the binding between the prefix(es) and the AS number in the ROA. An RP that previously viewed this binding as authentic will now not have any evidence about its validity. For origin validation, this means that a legitimate route will be treated as NotFound (if there are no other ROAs for the same prefix) or Invalid (if there is another ROA for the same prefix, but with a different AS number). A-4.2 Suppression A-4.2.1 Publication of a newer ROA may be suppressed. If the INR holder intended to change the binding between the prefix(es) and the AS number in the ROA, this change will not be effected. As a result, RPs may continue to believe an old prefix/ ASN binding that is no longer what the INR holder intended. A-4.2.2 If an INR holder intends to issue and publish two (or more) new ROAs for the same address space, one (or more) of the new ROAs may be suppressed while the other is published. In this case, RPs will Kent & Ma Expires July 16, 2017 [Page 14] Internet-Draft RPKI Adverse CA Actions January 2017 de-preference the suppressed prefix/ASN binding. Suppression of the new ROA might cause traffic to flow to an ASN other than the one(s) intended by the INR holder. A-4.2.3 If an INR holder intends to delete all ROAs for the same address space, some of them may be retained while the others are deleted. Preventing the deletion of some ROAs can cause traffic to continue to be delivered to the ASNs that were advertised by these ROAs. Deletion of all ROAs is consistent with a transfer of address space to a different INR holder, in a phased fashion. Thus this sort of attack could interfere with the successful transfer of the affected address space (until such time as the prefixes are removed from the previous INR holder's CA certificate). A-4.3 Corruption A-4.3.1 A ROA may be corrupted. A corrupted ROA will be ignored by an RP, so the effect is essentially the same as for A-4.1 and A-4.5. A possible difference is that an RP may be alerted to the fact that the ROA was corrupted, which might attract attention to the attack. A-4.4 Modification A-4.4.1 A ROA may be modified so that the Autonomous System Number (ASN) or one or more of the address blocks in a ROA is different from the values the INR holder intended for this ROA. (This action assumes that the modified ROA's ASN and address ranges are authorized for use by the INR holder.) This attack will cause RPs to de-preference the legitimate prefix/ASN binding intended by the INR holder. A-4.5 Revocation A-4.5.1 A ROA may be revoked (by placing its EE certificate on the CRL for the publication point). This has the same effect as A-4.1. A-4.6 Injection Kent & Ma Expires July 16, 2017 [Page 15] Internet-Draft RPKI Adverse CA Actions January 2017 A-4.6.1 A ROA expressing different bindings than those published by the INR holder may be injected into a publication point. This action could authorize an additional ASN to advertise the specified prefix, allowing that ASN to originate routes for the prefix, thus enabling route origin spoofing. In this case, the injected ROA is considered to be in competition with any existing authorized ROAs for the specified prefix. A-4.6.2 An injected ROA might express a different prefix for an ASN already authorized to originate a route, e.g., a longer prefix, which could enable that ASN to override other advertisements using shorter prefixes. If there are other ROAs that authorize different ASNs to advertise routes to the injected ROA's prefix, then the injected ROA is in competition with these ROAs. 2.5. Ghostbusters Record The Ghostbusters record [RFC6493] is a signed object that may be included at a publication point, at the discretion of the INR holder or publication point operator. The record is validated according to [RFC6488]. Additionally, the syntax of the record is verified based on the vCard profile from Section 5 of [RFC6493]. Errors in this record do not affect RP processing. However, if an RP encounters a problem with objects at a publication point, the RP may use information from the record to contact the publication point operator. Adverse actions against a Ghostbusters record can cause the following error: A-5.1 Deletion, suppression, corruption, or revocation of a Ghostbusters record could prevent an RP from contacting the appropriate entity when a problem is detected by the RP. Modification or injection of a Ghostbusters record could cause an RP to contact the wrong entity, thus delaying remediation of a detected anomaly. All of these actions are viewed as equivalent from an RP processing perspective; they do not alter RP validation of ROAs or router certificates. However, these actions can interfere with remediation of a problem when detected by an RP. Kent & Ma Expires July 16, 2017 [Page 16] Internet-Draft RPKI Adverse CA Actions January 2017 2.6. Router Certificates Router certificates are used by RPs to verify signatures on BGPsec_Path attributes carried in Update messages. Each AS is free to determine the granularity at which router certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each participating AS is represented by one or more router certificates. During key or algorithm rollover, multiple router certificates will be present in a publication point, even if the AS is normally represented by just one such certificate. Adverse actions against router certificates can cause the following errors: A-6.1 Deletion A-6.1.1 Deletion of a router certificate would cause an RP to not be able to verify signatures applied to BGPsec_Path attributes on behalf of the AS in question. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_Path attribute signatures. (However, if another router certificate for the affected AS is valid and contains the same AS number and public key, and is in use by that AS, there would be no effect on routing. This scenario will arise if a router certificate is renewed, i.e., issued with a new validity interval.) A-6.2 Suppression A-6.2.1 Suppression of a router certificate could have the same impact as deletion of a certificate of this type, i.e., if no router certificate was available, BGPsec attributes that should be verified using the certificate would fail validation. If an older certificate existed, and had not expired, it would be used by RPs. If the older certificate contained a different ASN, the impact would be the same as in A-6.4. A-6.3 Corruption Kent & Ma Expires July 16, 2017 [Page 17] Internet-Draft RPKI Adverse CA Actions January 2017 A-6.3.1 Corruption of a router certificate will result in the certificate being rejected by RPs. Absent a valid router certificate, BGPsec_Path attributes associated with that certificate will be unverifiable. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_Path attribute signatures. A-6.4 Modification A-6.4.1 If a router certificate is modified to represent a different ASN, but it still passes syntax checks, then this action could cause signatures on BGPsec_Path attributes to be associated with the wrong AS. This could cause signed routes to be inconsistent with the intent of the INR holder, e.g., traffic might be routed via a different AS than intended. A-6.5 Revocation A-6.5.1 If a router certificate were revoked, BGPsec_Path attributes verifiable using that certificate would not longer be considered valid. The impact would be the same as for a deleted certificate, as described in A-6.1. A-6.6 Injection A-6.6.1 Insertion of a router certificate could authorize additional routers to sign BGPsec traffic for the targeted ASN, and thus undermine fundamental BGPsec security guarantees. If there are existing, authorized router certificates for the same ASN, then the injected router certificate is in competition with these existing certificates. 3. Analysis of Actions Relative to Scenarios This section examines the types of problems that can arise in four scenarios described below. We consider mistakes, (successful) attacks against a CA or a publication point, and situations in which a CA or publication point manager is compelled to take action by a law enforcement authority. We explore the following four scenarios: Kent & Ma Expires July 16, 2017 [Page 18] Internet-Draft RPKI Adverse CA Actions January 2017 A. An INR holder operates its own CA and manages its own repository publication point. B. An INR holder operates its own CA, but outsources management of its repository publication point to its parent or another entity. C. An INR holder outsources management of its CA to its parent, but manages its own repository publication point. D. An INR holder outsources management of its CA and its publication point to its parent. Note that these scenarios focus on the affected INR holder as the party directly affected by an adverse action. The most serious cases arise when the INR holder appears as a high-tier CA in the RPKI hierarchy; in such situations subordinate INR holders may be affected as a result of an action. A mistake by or an attack against a "leaf" has more limited impact because all of the affected INRs belong to the INR holder itself. In Scenario A, actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.) In Scenario B, actions by the (outsourced) repository operator also can adversely affect the resources of the INR holder, and those of any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the outsourced repository operator. In Scenario C, all signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects---ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A. The INR holder is most vulnerable in Scenario D. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect Kent & Ma Expires July 16, 2017 [Page 19] Internet-Draft RPKI Adverse CA Actions January 2017 all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C. 3.1. Scenario A In this scenario, the INR holder acts as its own CA and it manages its own publication point. Actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.) Mistakes by the INR holder can cause any of the actions noted in Section 2. A successful attack against this CA can effect all of the modification, revocation, or injection actions noted in that section. (We assume that objects generated by the CA are automatically published). An attack against the publication point can effect all of the deletion, suppression, or corruption actions noted in that section. 3.2. Scenario B In this scenario, the INR holder acts as its own CA and but it delegates management of it own publication point to a third party. Mistakes by the INR holder can cause any of the modification, revocation, or injection actions described in Section 2. Actions by the repository operator can adversely affect the resources of the INR holder, and those of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the third party repository operator. A successful attack against the CA can effect all of the modification, revocation, or injection actions noted in that section (assuming that objects generated by the CA are automatically published). Here, actions by the publication point manager (or attacks against that entity) can effect all of the deletion, suppression, or corruption actions noted in Section 2. 3.3. Scenario C In this scenario, the INR holder outsources management of its CA to its parent, but manages its own repository publication point. All signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate Kent & Ma Expires July 16, 2017 [Page 20] Internet-Draft RPKI Adverse CA Actions January 2017 alternative signed objects -- ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect, unless the INR holder checks the signed objects before publishing them. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2, unless the INR holder checks the signed objects before publishing them. An attack against the INR holder (in its role as repository operator) can effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the INR holder is managing its publication point), unless the INR holder checks the signed objects before publishing them. (An attack against the INR holder implies that the path it uses to direct the parent CA to issue and publish objects has been compromised.) 3.4. Scenario D In this scenario an INR holder outsources management of both its CA and its publication point to its parent. The INR holder is most vulnerable in this scenario. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2. An attack against the parent CA can also effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the parent CA is managing the INR holder's publication point). 4. Security Considerations This informational document describes a threat model for the RPKI, focusing on mistakes by or attacks against CAs and independent repository managers. It is intended to provide a basis for the design of future RPKI security mechanisms that seek to address the concerns associated with such actions. Kent & Ma Expires July 16, 2017 [Page 21] Internet-Draft RPKI Adverse CA Actions January 2017 The analysis in this document identifies a number of circumstances in which attacks or errors can have significant impacts on routing. One ought not interpret this as a condemnation of the RPKI. It is only an attempt to document the implications of a wide range of attacks and errors, in the context of the RPKI. The primary alternative mechanism for disseminating routing information is Internet Routing Registry (IRR) technology ([RFC2650], [RFC2725]), which uses the Routing Policy Specification Language (RPSL) [RFC2622]. IRR technology exhibits its own set of security problems, which are discussed in [RFC7682]. 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgements The authors thank Richard Hansen and David Mandelberg for their extensive review, feedback and editorial assistance. Thanks also go to Daiming Li for her editorial assistance. 7. References 7.1. Normative References [I-D.ietf-sidr-bgpsec-pki-profiles] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", draft-ietf-sidr-bgpsec-pki- profiles-18 (work in progress), July 2016. [I-D.ietf-sidr-bgpsec-protocol] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", draft-ietf-sidr-bgpsec-protocol-21 (work in progress), December 2016. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . Kent & Ma Expires July 16, 2017 [Page 22] Internet-Draft RPKI Adverse CA Actions January 2017 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, . [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, . [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, . [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, . [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, . Kent & Ma Expires July 16, 2017 [Page 23] Internet-Draft RPKI Adverse CA Actions January 2017 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, . 7.2. Informative References [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, . [RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, DOI 10.17487/RFC2650, August 1999, . [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, . [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and D. Mitchell, "Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration", RFC 7682, DOI 10.17487/RFC7682, December 2015, . Authors' Addresses Stephen Kent BBN Technologies 10 Moulton St Cambridge, MA 02138-1119 USA Email: kent@alum.mit.edu Kent & Ma Expires July 16, 2017 [Page 24] Internet-Draft RPKI Adverse CA Actions January 2017 Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian, Beijing 100190 China Email: madi@zdns.cn Kent & Ma Expires July 16, 2017 [Page 25] ./draft-ietf-sidr-bgpsec-ops-16.txt0000664000764400076440000004662713033446751016407 0ustar iustyiusty Network Working Group R. Bush Internet-Draft Internet Initiative Japan Intended status: Best Current Practice January 5, 2017 Expires: July 9, 2017 BGPsec Operational Considerations draft-ietf-sidr-bgpsec-ops-16 Abstract Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 9, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Bush Expires July 9, 2017 [Page 1] Internet-Draft BGPsec Operational Considerations January 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3 4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 3 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4 7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 5 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Origin Validation based on the Resource Public Key Infrastructure (RPKI), [RFC6811], is in its early phases. As BGPsec, [I-D.ietf-sidr-bgpsec-protocol] may require larger memory and/or more modern CPUs, it expected to be deployed incrementally over a longer time span. BGPsec is a new protocol with many operational considerations which this document attempts to describe. As with most operational practices, this document will likely evolve. BGPsec relies on widespread propagation of the RPKI [RFC6480]. How the RPKI is distributed and maintained globally and within an operator's infrastructure may be different for BGPsec than for origin validation. BGPsec needs to be spoken only by an AS's eBGP-speaking border routers. It is designed so that it can be used to protect announcements which are originated by resource constrained edge routers. This has special operational considerations, see Section 6. Different prefixes may have different timing and replay protection considerations. Bush Expires July 9, 2017 [Page 2] Internet-Draft BGPsec Operational Considerations January 2017 2. Suggested Reading It is assumed that the reader understands BGP, see [RFC4271], BGPsec, [I-D.ietf-sidr-bgpsec-protocol], the RPKI, see [RFC6480], the RPKI Repository Structure, see [RFC6481], and Route Origin Authorizations (ROAs), see [RFC6482]. 3. RPKI Distribution and Maintenance The considerations for RPKI objects (Certificates, Certificate Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), Trust Anchor Locators (TALs) [RFC7730], cache behaviours of synchronisation and validation from the section on RPKI Distribution and Maintenance of [RFC7115] apply. Specific considerations relating to ROA objects do not apply to this document. 4. AS/Router Certificates As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers are capable of generating their own public/private key-pairs and having their certificates signed and published in the RPKI by the RPKI CA system, and/or are given public/private key-pairs by the operator. A site/operator may use a single certificate/key in all their routers, one certificate/key per router, or any granularity in between. A large operator, concerned that a compromise of one router's key would make other routers vulnerable, may deploy a more complex certificate/key distribution burden to reduce this exposure. At the other end of the spectrum, an edge site with one or two routers may choose to use a single certificate/key. In anticipation of possible key compromise, a prudent operator SHOULD pre-provision each router's 'next' key in the RPKI so there is no propagation delay for provisioning the new key. 5. Within a Network BGPsec is spoken by edge routers in a network, those which border other networks/ASs. In an AS where edge routers speak BGPsec and therefore inject BGPsec paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and only if there are eBGP speakers in their client cone, i.e. an RR client or the transitive closure of a client's customers. Bush Expires July 9, 2017 [Page 3] Internet-Draft BGPsec Operational Considerations January 2017 A BGPsec capable router MAY use the data it receives to influence local policy within its network, see Section 7. In deployment this policy should fit into the AS's existing policy, preferences, etc. This allows a network to incrementally deploy BGPsec enabled border routers. eBGP speakers which face more critical peers or up/downstreams would be candidates for early deployment. Both securing one's own announcements and validating received announcements should be considered in partial deployment. An operator should be aware that BGPsec, as any other policy change, can cause traffic shifts in their network. And, as with normal policy shift practice, a prudent operator has tools and methods to predict, measure, modify, etc. On the other hand, an operator wanting to monitor router loading, shifts in traffic, etc. might deploy incrementally while watching those and similar effects. BGPsec does not sign over communities, so they are not formally trustable. Additionally, outsourcing verification is not prudent security practice. Therefore an eBGP listener SHOULD NOT strongly trust unsigned security signaling, such as communities, received across a trust boundary. 6. Considerations for Edge Sites An edge site which does not provide transit and trusts its upstream(s) may only originate a signed prefix announcement and not validate received announcements. An Operator might need to use hardware with limited resources. In such cases, BGPsec protocol capability negotiation allows for a resource constrained edge router to hold only its own signing key(s) and sign its announcements, but not receive signed announcements. Therefore, the router would not have to deal with the majority of the RPKI, potentially saving the need for additional hardware. As the vast majority of ASs are stubs, and they announce the majority of prefixes, this allows for simpler and less expensive incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams which support BGPsec. Bush Expires July 9, 2017 [Page 4] Internet-Draft BGPsec Operational Considerations January 2017 7. Routing Policy Unlike origin validation based on the RPKI, BGPsec marks a received announcement as Valid or Not Valid, there is no explicit NotFound state. In some sense, an unsigned BGP4 path is the equivalent of NotFound. How this is used in routing is up to the operator's local policy, similar to origin validation as in [RFC6811]. As BGPsec will be rolled out over years and does not allow for intermediate non-signing edge routers, coverage will be spotty for a long time. This presents a dilemma; should a router evaluating an inbound BGPsec_Path as Not Valid be very strict and discard it? On the other hand, it might be the only path to that prefix, and a very low local-preference would cause it to be used and propagated only if there was no alternative. Either choice is reasonable, but we recommend dropping because of the next point. Operators should be aware that accepting Not Valid announcements, no matter the local preference, will often be the equivalent of treating them as fully Valid. Local preference affects only routes to the same set of destinations. Consider having a Valid announcement from neighbor V for prefix 10.0.0.0/16 and an Not Valid announcement for 10.0.666.0/24 from neighbor I. If local policy on the router is not configured to discard the Not Valid announcement from I, then longest match forwarding will send packets to neighbor I no matter the value of local preference. Validation of signed paths is usually deployed at the eBGP edge. Local policy on the eBGP edge MAY convey the validation state of a BGP signed path through normal local policy mechanisms, e.g. setting a BGP community for internal use, or modifying a metric value such as local-preference or multi-exit discriminator (MED). Some may choose to use the large Local-Pref hammer. Others may choose to let AS-Path rule and set their internal metric, which comes after AS-Path in the BGP decision process. As the mildly stochastic timing of RPKI propagation may cause version skew across routers, an AS Path which does not validate at router R0 might validate at R1. Therefore, signed paths that are Not Valid and yet propagated (because they are chosen as best path) MUST NOT have signatures stripped and MUST be signed if sent to external BGPsec speakers. This implies that updates which a speaker judges to be Not Valid MAY be propagated to iBGP peers. Therefore, unless local policy ensures otherwise, a signed path learned via iBGP may be Not Valid. If Bush Expires July 9, 2017 [Page 5] Internet-Draft BGPsec Operational Considerations January 2017 needed, the validation state should be signaled by normal local policy mechanisms such as communities or metrics. On the other hand, local policy on the eBGP edge might preclude iBGP or eBGP announcement of signed AS Paths which are Not Valid. A BGPsec speaker receiving a path SHOULD perform origin validation per [RFC6811] and [RFC7115]. A route server is usually 'transparent', i.e. does not insert an AS into the path so as not to increase the AS hop count and thereby affect downstream path choices. But, with BGPsec, a client router R needs to be able to validate paths which are forward signed to R. But the sending router can not generate signatures to all the possible clients. Therefore a BGPsec-aware route server needs to validate the incoming BGPsec_Path, and to forward updates which can be validated by clients which must therefore know the route server's AS. This implies that the route server creates signatures per client including its own AS in the BGPsec_Path, forward signing to each client AS, see [I-D.ietf-sidr-bgpsec-protocol]. The route server uses pCount of zero to not increase the effective AS hop count, thereby retaining the intent of 'transparency'. If it is known that a BGPsec neighbor is not a transparent route server, or is otherwise validly using pCount=0 (e,g, see [I-D.ietf-sidr-as-migration]), and the router provides a knob to disallow a received pCount (of zero, that knob SHOULD be applied. Routers should disallow pCount 0 by default. To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker exporting to a non-member removes all intra- confederation Secure_Path segments. Therefore signing within the confederation will not cause external confusion even if non-unique private ASs are used. 8. Notes For protection from attacks replaying BGP data on the order of a day or longer old, re-keying routers with new keys (previously) provisioned in the RPKI is sufficient. For one approach, see [I-D.ietf-sidr-bgpsec-rollover] A router that once negotiated (and/or sent) BGPsec should not be expected to always do so. Like the DNS, the global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, etc. Thus, one cache or router may have different data about a particular prefix or router Bush Expires July 9, 2017 [Page 6] Internet-Draft BGPsec Operational Considerations January 2017 than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches. Operators who manage certificates SHOULD have RPKI GhostBuster Records (see [RFC6493]), signed indirectly by End Entity certificates, for those certificates on which others' routing depends for certificate and/or ROA validation. Operators should be aware of impending algorithm transitions, which will be rare and slow-paced, see [RFC6916]. They should work with their vendors to ensure support for new algorithms. As a router must evaluate certificates and ROAs which are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. The common approach is for operators to deploy servers that provide time service, such as [RFC5905], to client routers. If a router has reason to believe its clock is seriously incorrect, e.g. it has a time earlier than 2011, it SHOULD NOT attempt to validate incoming updates. It SHOULD defer validation until it believes it is within reasonable time tolerance. 9. Security Considerations This document describes operational considerations for the deployment of BGPsec. The security considerations for BGPsec are described in [I-D.ietf-sidr-bgpsec-protocol]. 10. IANA Considerations This document has no IANA Considerations. 11. Acknowledgments The author wishes to thank Thomas King, Arnold Nipper, and Alvaro Retana, and the BGPsec design group. 12. References 12.1. Normative References [I-D.ietf-sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- sidr-bgpsec-protocol-07 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Bush Expires July 9, 2017 [Page 7] Internet-Draft BGPsec Operational Considerations January 2017 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013. [RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, . [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, . 12.2. Informative References [I-D.ietf-sidr-as-migration] George, W. and S. Murphy, "BGPSec Considerations for AS Migration", draft-ietf-sidr-as-migration-06 (work in progress), December 2016. [I-D.ietf-sidr-bgpsec-rollover] Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key rollover as an alternative to beaconing", draft-ietf-sidr- bgpsec-rollover-01 (work in progress), October 2012. [I-D.ietf-sidr-rtr-keying] Turner, S., Patel, K., and R. Bush, "Router Keying for BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), February 2013. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. Bush Expires July 9, 2017 [Page 8] Internet-Draft BGPsec Operational Considerations January 2017 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012. [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012. [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, . Author's Address Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US Email: randy@psg.com Bush Expires July 9, 2017 [Page 9] ./draft-ietf-sidr-bgpsec-pki-profiles-21.txt0000664000764400076440000006727513033441561020202 0ustar iustyiusty Secure Inter-Domain Routing Working Group M. Reynolds Internet-Draft IPSw Updates: 6487 (if approved) S. Turner Intended status: Standard Track sn3rd Expires: July 9, 2017 S. Kent BBN January 5, 2017 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests draft-ietf-sidr-bgpsec-pki-profiles-21 Abstract This document defines a standard profile for X.509 certificates used to enable 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 the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued to routers within an Autonomous System. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Identifier Delegation extension. An EE certificate of this type asserts that the router(s) holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests, and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Reynolds, et al. Expires July 9, 2017 [Page 1] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Describing Resources in Certificates . . . . . . . . . . . . . 3 3. Updates to [RFC6487] . . . . . . . . . . . . . . . . . . . . . 5 3.1 BGPsec Router Certificate Fields . . . . . . . . . . . . . 5 3.1.1. Subject . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Subject Public Key Info . . . . . . . . . . . . . . . 5 3.1.3. BGPsec Router Certificate Version 3 Extension Fields . 5 3.1.3.1. Basic Constraints . . . . . . . . . . . . . . . . 5 3.1.3.2. Extended Key Usage . . . . . . . . . . . . . . . . 5 3.1.3.3. Subject Information Access . . . . . . . . . . . . 6 3.1.3.4. IP Resources . . . . . . . . . . . . . . . . . . . 6 3.1.3.5. AS Resources . . . . . . . . . . . . . . . . . . . 6 3.2. BGPsec Router Certificate Request Profile . . . . . . . . 6 3.3. BGPsec Router Certificate Validation . . . . . . . . . . . 7 3.4. Router Certificates and Signing Functions in the RPKI . . 7 4. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Implementation Considerations . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Reynolds, et al. Expires July 9, 2017 [Page 2] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 1. Introduction This document defines a profile for X.509 end-entity (EE) certificates [RFC5280] for use in the context of certification of Autonomous System (AS) paths in the BGPsec. Such certificates are termed "BGPsec Router Certificates". The holder of the private key associated with a BGPsec Router Certificate is authorized to send secure route advertisements (BGPsec UPDATEs) on behalf of the AS(es) named in the certificate. A router holding the private key is authorized to send route advertisements (to its peers) identifying the router's ASN as the source of the advertisements. A key property provided by BGPsec is that every AS along the AS PATH can verify that the other ASes along the path have authorized the advertisement of the given route (to the next AS along the AS PATH). This document is a profile of [RFC6487], which is a profile of [RFC5280]; thus this document updates [RFC6487]. It establishes requirements imposed on a Resource Certificate that is used as a BGPsec Router Certificate, i.e., it defines constraints for certificate fields and extensions for the certificate to be valid in this context. This document also profiles the certification requests used to acquire BGPsec Router Certificates. Finally, this document specifies the Relying Party (RP) certificate path validation procedures for these certificates. 1.1. Terminology It is assumed that the reader is familiar with the terms and concepts described in "A Profile for X.509 PKIX Resource Certificates" [RFC6487], "BGPsec Protocol Specification" [ID.sidr-bgpsec-protocol], "A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security Vulnerabilities Analysis" [RFC4272], "Considerations in Validating the Path in BGP" [RFC5123], and "Capability Advertisement with BGP-4" [RFC5492]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Describing Resources in Certificates Figure 1 depicts some of the entities in the RPKI and some of the products generated by RPKI entities. IANA issues a Certification Authority (CA) certificate to each Regional Internet Registry (RIR). The RIR, in turn, issues a CA certificate to an Internet Service Provider (ISP). The ISP in turn issues EE Certificates to itself to enable verification of signatures on RPKI signed objects. The CA Reynolds, et al. Expires July 9, 2017 [Page 3] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 also generates Certificate Revocation Lists (CRLs). These CA and EE certificates are referred to as "Resource Certificates", and are profiled in [RFC6487]. [RFC6480] envisioned using Resource Certificates to enable verification of Manifests [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. ROAs and Manifests include the Resource Certificates used to verify them. +---------+ +------+ | CA Cert |---| IANA | +---------+ +------+ \ +---------+ +-----+ | CA Cert |---| RIR | +---------+ +-----+ \ +---------+ +-----+ | CA Cert |---| ISP | +---------+ +-----+ / | | | +-----+ / | | | +-----+ | CRL |--+ | | +---| ROA | +-----+ | | +-----+ | | +----------+ +----+ | +---| Manifest | +-| EE |---+ +----------+ | +----+ +-----+ Figure 1 This document defines another type of Resource Certificate, which is referred to as a "BGPsec Router Certificate". The purpose of this certificate is explained in Section 1 and falls within the scope of appropriate uses defined within [RFC6484]. The issuance of BGPsec Router Certificates has minimal impact on RPKI CAs because the RPKI CA certificate and CRL profile remain unchanged (i.e., they are as specified in [RFC6487]). Further, the algorithms used to generate RPKI CA certificates that issue the BGPsec Router Certificates and the CRLs necessary to check the validity of the BGPsec Router Certificates remain unchanged (i.e., they are as specified in [RFC7935]). The only impact is that RPKI CAs will need to be able to process a profiled certificate request (see Section 5) signed with algorithms found in [ID.sidr-bgpsec-algs]. BGPsec Router Certificates are used only to verify the signature on the BGPsec certificate request (only CAs process these) and the signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers process these); BGPsec Router Certificates are not used to process Manifests and ROAs or verify signatures on Certificates or CRLs. Reynolds, et al. Expires July 9, 2017 [Page 4] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 This document enumerates only the differences between this profile and the profile in [RFC6487]. Note that BGPsec Router Certificates are EE certificates and as such there is no impact on process described in [RFC6916]. 3. Updates to [RFC6487] 3.1 BGPsec Router Certificate Fields A BGPsec Router Certificate is consistent with the profile in [RFC6487] as modified by the specifications in this section. As such, it is a valid X.509 public key certificate and consistent with the PKIX profile [RFC5280]. The differences between this profile and the profile in [RFC6487] are specified in this section. 3.1.1. Subject Common name encoding options that are supported are printableString and UTF8String. For BGPsec Router Certificates, it is RECOMMENDED that the common name attribute contain the literal string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded as eight hexadecimal digits and that the serial number attribute contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as eight hexadecimal digits. If there is more than one AS number, the choice of which to include in the common name is at the discretion of the Issuer. If the same certificate is issued to more than one router (hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer. 3.1.2. Subject Public Key Info Refer to section 3.1 of [ID.sidr-bgpsec-algs]. 3.1.3. BGPsec Router Certificate Version 3 Extension Fields 3.1.3.1. Basic Constraints BGPsec speakers are EEs; therefore, the Basic Constraints extension must not be present, as per [RFC6487]. 3.1.3.2. Extended Key Usage BGPsec Router Certificates MUST include the Extended Key Usage (EKU) extension. As specified in [RFC6487] this extension must be marked as non-critical. This document defines one EKU for BGPsec Router Certificates: Reynolds, et al. Expires July 9, 2017 [Page 5] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } A BGPsec router MUST require the extended key usage extension to be present in a BGPsec Router Certificate it receives. If multiple KeyPurposeId values are included, the BGPsec routers need not recognize all of them, as long as the required KeyPurposeId value is present. BGPsec routers MUST reject certificates that do not contain the BGPsec Router EKU even if they include the anyExtendedKeyUsage OID defined in [RFC5280]. 3.1.3.3. Subject Information Access This extension is not used in BGPsec Router Certificates. It MUST be omitted. 3.1.3.4. IP Resources This extension is not used in BGPsec Router Certificates. It MUST be omitted. 3.1.3.5. AS Resources Each BGPsec Router Certificate MUST include the AS Resource Identifier Delegation extension, as specified in section 4.8.11 of [RFC6487]. The AS Resource Identifier Delegation extension MUST include one or more AS numbers, and the "inherit" element MUST NOT be specified. 3.2. BGPsec Router Certificate Request Profile Refer to section 6 of [RFC6487]. The only differences between this profile and the profile in [RFC6487] are: o The Basic Constraints extension: If included, the CA MUST NOT honor the cA boolean if set to TRUE. o The Extended Key Usage extension: If included, id-kp-bgpsec-router MUST be present (see Section 3.1). If included, the CA MUST honor the request for id-kp- bgpsec-router. Reynolds, et al. Expires July 9, 2017 [Page 6] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 o The Subject Information Access extension: If included, the CA MUST NOT honor the request to include the extension. o The SubjectPublicKeyInfo field is specified in [ID.sidr-bgpsec- algs]. o The request is signed with the algorithms specified in [ID.sidr- bgpsec-algs]. 3.3. BGPsec Router Certificate Validation The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates that procedure), as modified below. For example, in step 3: "The certificate contains all fields that MUST be present" - refers to the fields that are required by this specification. The differences are as follows: o BGPsec Router Certificates MUST include the BGPsec Router EKU defined in Section 3.1.3.2. o BGPsec Router Certificates MUST NOT include the SIA extension. o BGPsec Router Certificates MUST NOT include the IP Resource extension. o BGPsec Router Certificates MUST include the AS Resource Identifier Delegation extension. o BGPsec Router Certificate MUST include the subjectPublicKeyInfo described in [ID.sidr-bgpsec-algs]. NOTE: BGPsec RPs will need to support the algorithms in [ID.sidr- bgpsec-algs], which are used to validate BGPsec signatures, as well as the algorithms in [RFC7935], which are needed to validate signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs. 3.4. Router Certificates and Signing Functions in the RPKI As described in Section 1, the primary function of BGPsec route certificates in the RPKI is for use in the context of certification of Autonomous System (AS) paths in the BGPsec protocol. Reynolds, et al. Expires July 9, 2017 [Page 7] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 The private key associated with a router EE certificate may be used multiple times in generating signatures in multiple instances of the BGPsec_Path Attribute Signature Segments [ID.sidr-bgpsec-protocol]. I.e., the BGPsec router certificate is used to validate multiple signatures. BGPsec router certificates are stored in the issuing CA's repository, where a repository following RFC6481 MUST use a .cer filename extension for the certificate file. 4. Design Notes The BGPsec Router Certificate profile is based on the Resource Certificate profile as specified in [RFC7935]. As a result, many of the design choices herein are a reflection of the design choices that were taken in that prior work. The reader is referred to [RFC6484] for a fuller discussion of those choices. CAs are required by the Certificate Policy (CP) [RFC6484] to issue properly formed BGPsec Router Certificates regardless of what is present in the certification request so there is some flexibility permitted in the certificate requests: o BGPsec Router Certificates are always EE certificates; therefore, requests to issue a CA certificate result in EE certificates; o BGPsec Router Certificates are always EE certificates; therefore, requests for Key Usage extension values keyCertSign and cRLSign result in certificates with neither of these values; o BGPsec Router Certificates always include the BGPsec Rouer EKU value; therefore, request without the value result in certificates with the value; and, o BGPsec Router Certificates never include the Subject Information Access extension; therefore, request with this extension result in certificates without the extension. Note that this behavior is similar to the CA including the AS Resource Identifier Delegation extension in issued BGPsec Router Certificates despite the fact it is not present in the request. 5. Implementation Considerations This document permits the operator to include a list of ASNs in a BGPsec Router Certificate. In that case, the router certificate would become invalid if any one of the ASNs is removed from any superior CA certificate along the path to a trust anchor. Operators could choose Reynolds, et al. Expires July 9, 2017 [Page 8] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 to avoid this possibility by issuing a separate BGPsec Router Certificate for each distinct ASN, so that the router certificates for ASNs that are retained in the superior CA certificate would remain valid. 6. Security Considerations The Security Considerations of [RFC6487] apply. A BGPsec Router Certificate will fail RPKI validation, as defined in [RFC6487], because the cryptographic algorithms used are different. Consequently, a RP needs to identify the EKU to determine the appropriate Validation constraint. A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to encompass routers. It is a building block BGPsec and is used to validate signatures on BGPsec Signature-Segment origination of Signed-Path segments [ID.sidr-bgpsec-protocol]. Thus its essential security function is the secure binding of one or more AS numbers to a public key, consistent with the RPKI allocation/assignment hierarchy. Hash functions [ID.sidr-bgpsec-algs] are used when generating the two key identifier extensions (i.e., Subject Key Identifier and Issuer Key Identifier) included in BGPsec certificates. However as noted in [RFC6818], collision resistance is not a required property of one-way hash functions when used to generate key identifiers. Regardless, hash collisions are unlikely, but they are possible and if detected an operator should be alerted. A subject key identifier collision might cause the incorrect certificate to be selected from the cache, resulting in a failed signature validation. 7. IANA Considerations This document makes use of two object identifiers in the SMI Registry for PKIX. One is for the ASN.1 module in Appendix A and it comes from the SMI Security for PKIX Module Identifier IANA registry (id- mod-bgpsec-eku). The other is for the BGPsec router EKU defined in Section 3.1.3.2 and Appendix A and it comes from the SMI Security for PKIX Extended Key Purpose IANA registry. These OIDs were assigned before management of the PKIX Arc was handed to IANA. No IANA allocations are request of IANA, but please update the references in those registries when this document is published by the RFC editor. 8. Acknowledgements We would like to thank Geoff Huston, George Michaelson, and Robert Loomans for their work on [RFC6487], which this work is based on. In Reynolds, et al. Expires July 9, 2017 [Page 9] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 addition, the efforts of Matt Lepinski were instrumental in preparing this work. Additionally, we'd like to thank Rob Austein, Roque Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra Murphy, and Sam Weiller for their reviews and comments. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, . [ID.sidr-bgpsec-protocol] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress. Reynolds, et al. Expires July 9, 2017 [Page 10] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 [ID.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in- progress. 9.2. Informative References [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, . [RFC5123] White, R. and B. Akyol, "Considerations in Validating the Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February 2008, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, . [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, . [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, . Reynolds, et al. Expires July 9, 2017 [Page 11] Internet-Draft BGPsec Router PKI Profiles January 5, 2017 Appendix A. ASN.1 Module BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- -- IMPORTS NOTHING -- -- OID Arc -- id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } -- BGPsec Router Extended Key Usage -- id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } END Authors' Addresses Mark Reynolds Island Peak Software 328 Virginia Road Concord, MA 01742 Email: mcr@islandpeaksoftware.com Sean Turner sn3rd EMail: sean@sn3rd.com Stephen Kent Raytheon BBN Technologies 10 Moulton St. Cambridge, MA 02138 Email: kent@bbn.com Reynolds, et al. Expires July 9, 2017 [Page 12] ./draft-ietf-sidr-bgpsec-protocol-22.txt0000664000764400076440000033720713037250735017440 0ustar iustyiusty Network Working Group M. Lepinski, Ed. Internet-Draft NCF Intended status: Standards Track K. Sriram, Ed. Expires: July 20, 2017 NIST January 16, 2017 BGPsec Protocol Specification draft-ietf-sidr-bgpsec-protocol-22 Abstract This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each autonomous system that propagates the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 20, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Lepinski & Sriram Expires July 20, 2017 [Page 1] Internet-Draft BGPsec Protocol January 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 4 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10 4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . 11 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . 13 4.3. Processing Instructions for Confederation Members . . . . 18 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 21 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27 6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28 6.3. Extensibility Considerations . . . . . . . . . . . . . . 28 7. Operations and Management Considerations . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33 8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34 8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 35 8.4. Additional Security Considerations . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 39 10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.2. Informative References . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction This document describes BGPsec, a mechanism for providing path security for Border Gateway Protocol (BGP) [RFC4271] route advertisements. That is, a BGP speaker who receives a valid BGPsec update has cryptographic assurance that the advertised route has the Lepinski & Sriram Expires July 20, 2017 [Page 2] Internet-Draft BGPsec Protocol January 2017 following property: Every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route to the subsequent AS in the path. This document specifies an optional (non-transitive) BGP path attribute, BGPsec_Path. It also describes how a BGPsec-compliant BGP speaker (referred to hereafter as a BGPsec speaker) can generate, propagate, and validate BGP update messages containing this attribute to obtain the above assurances. BGPsec is intended to be used to supplement BGP Origin Validation [RFC6483][RFC6811] and when used in conjunction with origin validation, it is possible to prevent a wide variety of route hijacking attacks against BGP. BGPsec relies on the Resource Public Key Infrastructure (RPKI) certificates that attest to the allocation of AS number and IP address resources. (For more information on the RPKI, see RFC 6480 [RFC6480] and the documents referenced therein.) Any BGPsec speaker who wishes to send, to external (eBGP) peers, BGP update messages containing the BGPsec_Path needs to possess a private key associated with an RPKI router certificate [I-D.ietf-sidr-bgpsec-pki-profiles] that corresponds to the BGPsec speaker's AS number. Note, however, that a BGPsec speaker does not need such a certificate in order to validate received update messages containing the BGPsec_Path attribute (see Section 5.2). 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. BGPsec Negotiation This document defines a BGP capability [RFC5492] that allows a BGP speaker to advertise to a neighbor the ability to send or to receive BGPsec update messages (i.e., update messages containing the BGPsec_Path attribute). 2.1. The BGPsec Capability This capability has capability code: TBD The capability length for this capability MUST be set to 3. The three octets of the capability format are specified in Figure 1. Lepinski & Sriram Expires July 20, 2017 [Page 3] Internet-Draft BGPsec Protocol January 2017 0 1 2 3 4 5 6 7 +---------------------------------------+ | Version | Dir | Unassigned | +---------------------------------------+ | | +------ AFI -----+ | | +---------------------------------------+ Figure 1: BGPsec Capability format. The first four bits of the first octet indicate the version of BGPsec for which the BGP speaker is advertising support. This document defines only BGPsec version 0 (all four bits set to zero). Other versions of BGPsec may be defined in future documents. A BGPsec speaker MAY advertise support for multiple versions of BGPsec by including multiple versions of the BGPsec capability in its BGP OPEN message. The fifth bit of the first octet is a direction bit which indicates whether the BGP speaker is advertising the capability to send BGPsec update messages or receive BGPsec update messages. The BGP speaker sets this bit to 0 to indicate the capability to receive BGPsec update messages. The BGP speaker sets this bit to 1 to indicate the capability to send BGPsec update messages. The remaining three bits of the first octet are unassigned and for future use. These bits are set to zero by the sender of the capability and ignored by the receiver of the capability. The second and third octets contain the 16-bit Address Family Identifier (AFI) which indicates the address family for which the BGPsec speaker is advertising support for BGPsec. This document only specifies BGPsec for use with two address families, IPv4 and IPv6, AFI values 1 and 2 respectively [IANA-AF]. BGPsec for use with other address families may be specified in future documents. 2.2. Negotiating BGPsec Support In order to indicate that a BGP speaker is willing to send BGPsec update messages (for a particular address family), a BGP speaker sends the BGPsec Capability (see Section 2.1) with the Direction bit (the fifth bit of the first octet) set to 1. In order to indicate that the speaker is willing to receive BGP update messages containing the BGPsec_Path attribute (for a particular address family), a BGP speaker sends the BGPsec capability with the Direction bit set to 0. In order to advertise the capability to both send and receive BGPsec update messages, the BGP speaker sends two copies of the BGPsec Lepinski & Sriram Expires July 20, 2017 [Page 4] Internet-Draft BGPsec Protocol January 2017 capability (one with the direction bit set to 0 and one with the direction bit set to 1). Similarly, if a BGP speaker wishes to use BGPsec with two different address families (i.e., IPv4 and IPv6) over the same BGP session, then the speaker includes two instances of this capability (one for each address family) in the BGP OPEN message. A BGP speaker MUST NOT announce BGPsec capability if it does not support the BGP multiprotocol extension [RFC4760]. Additionally, a BGP speaker MUST NOT advertise the capability of BGPsec support for a particular AFI unless it has also advertised the multiprotocol extension capability for the same AFI [RFC4760]. In a BGPsec peering session, a peer is permitted to send update messages containing the BGPsec_Path attribute if, and only if: o The given peer sent the BGPsec capability for a particular version of BGPsec and a particular address family with the Direction bit set to 1; and o The other (receiving) peer sent the BGPsec capability for the same version of BGPsec and the same address family with the Direction bit set to 0. In such a session, it can be said that the use of the particular version of BGPsec has been negotiated for a particular address family. BGP update messages without the BGPsec_Path attribute MAY be sent within a session regardless of whether or not the use of BGPsec is successfully negotiated. However, if BGPsec is not successfully negotiated, then BGP update messages containing the BGPsec_Path attribute MUST NOT be sent. This document defines the behavior of implementations in the case where BGPsec version zero is the only version that has been successfully negotiated. Any future document which specifies additional versions of BGPsec will need to specify behavior in the case that support for multiple versions is negotiated. BGPsec cannot provide meaningful security guarantees without support for four-byte AS numbers. Therefore, any BGP speaker that announces the BGPsec capability, MUST also announce the capability for four- byte AS support [RFC6793]. If a BGP speaker sends the BGPsec capability but not the four-byte AS support capability then BGPsec has not been successfully negotiated, and update messages containing the BGPsec_Path attribute MUST NOT be sent within such a session. Note that BGPsec update messages can be quite large, therefore any BGPsec speaker announcing the capability to receive BGPsec messages Lepinski & Sriram Expires July 20, 2017 [Page 5] Internet-Draft BGPsec Protocol January 2017 SHOULD also announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. Please see related operational guidance in Section 7. 3. The BGPsec_Path Attribute The BGPsec_Path attribute is an optional non-transitive BGP path attribute. This document registers an attribute type code for this attribute: BGPsec_Path (see Section 9). The BGPsec_Path attribute carries the secured information regarding the path of ASes through which an update message passes. This includes the digital signatures used to protect the path information. The update messages that contain the BGPsec_Path attribute are referred to as "BGPsec Update messages". The BGPsec_Path attribute replaces the AS_PATH attribute in a BGPsec update message. That is, update messages that contain the BGPsec_Path attribute MUST NOT contain the AS_PATH attribute, and vice versa. The BGPsec_Path attribute is made up of several parts. The high- level diagram in Figure 2 provides an overview of the structure of the BGPsec_Path attribute. Lepinski & Sriram Expires July 20, 2017 [Page 6] Internet-Draft BGPsec Protocol January 2017 +---------------------------------------------------------+ | +-----------------+ | | | Secure Path | | | +-----------------+ | | | pCount X | | | | Flags X | | | | AS X | | | | pCount Y | | | | Flags Y | | | | AS Y | | | | ... | | | +-----------------+ | | | | +-----------------+ +-----------------+ | | | Sig Block 1 | | Sig Block 2 | | | +-----------------+ +-----------------+ | | | Alg Suite 1 | | Alg Suite 2 | | | | SKI X1 | | SKI X2 | | | | Signature X1 | | Signature X2 | | | | SKI Y1 | | SKI Y2 | | | | Signature Y1 | | Signature Y2 | | | | ... | | .... | | | +-----------------+ +-----------------+ | | | +---------------------------------------------------------+ Figure 2: High-level diagram of the BGPsec_Path attribute. Figure 3 provides the specification of the format for the BGPsec_Path attribute. +-------------------------------------------------------+ | Secure_Path (variable) | +-------------------------------------------------------+ | Sequence of one or two Signature_Blocks (variable) | +-------------------------------------------------------+ Figure 3: BGPsec_Path attribute format. The Secure_Path contains AS path information for the BGPsec update message. This is logically equivalent to the information that is contained in a non-BGPsec AS_PATH attribute. The information in Secure_Path is used by BGPsec speakers in the same way that information from the AS_PATH is used by non-BGPsec speakers. The format of the Secure_Path is described below in Section 3.1. Lepinski & Sriram Expires July 20, 2017 [Page 7] Internet-Draft BGPsec Protocol January 2017 The BGPsec_Path attribute will contain one or two Signature_Blocks, each of which corresponds to a different algorithm suite. Each of the Signature_Blocks will contain a Signature Segment for each AS number (i.e., Secure_Path Segment) in the Secure_Path. In the most common case, the BGPsec_Path attribute will contain only a single Signature_Block. However, in order to enable a transition from an old algorithm suite to a new algorithm suite (without a flag day), it will be necessary to include two Signature_Blocks (one for the old algorithm suite and one for the new algorithm suite) during the transition period. (See Section 6.1 for more discussion of algorithm transitions.) The format of the Signature_Blocks is described below in Section 3.2. 3.1. Secure_Path A detailed description of the Secure_Path information in the BGPsec_Path attribute is provided here. +-----------------------------------------------+ | Secure_Path Length (2 octets) | +-----------------------------------------------+ | One or More Secure_Path Segments (variable) | +-----------------------------------------------+ Figure 4: Secure_Path format. The specification for the Secure_Path field is provided in Figure 4 and Figure 5. The Secure_Path Length contains the length (in octets) of the entire Secure_Path (including the two octets used to express this length field). As explained below, each Secure_Path Segment is six octets long. Note that this means the Secure_Path Length is two greater than six times the number Secure_Path Segments (i.e., the number of AS numbers in the path). The Secure_Path contains one Secure_Path Segment (see Figure 5) for each Autonomous System in the path to the originating AS of the prefix specified in the update message. (Note: Repeated Autonomous Systems are compressed out using the pCount field as discussed below). Lepinski & Sriram Expires July 20, 2017 [Page 8] Internet-Draft BGPsec Protocol January 2017 +------------------------------------------------------+ | pCount (1 octet) | +------------------------------------------------------+ | Confed_Segment flag (1 bit) | Unassigned (7 bits) | (Flags) +------------------------------------------------------+ | AS Number (4 octets) | +------------------------------------------------------+ Figure 5: Secure_Path Segment format. The AS Number (in Figure 5) is the AS number of the BGP speaker that added this Secure_Path Segment to the BGPsec_Path attribute. (See Section 4 for more information on populating this field.) The pCount field contains the number of repetitions of the associated autonomous system number that the signature covers. This field enables a BGPsec speaker to mimic the semantics of prepending multiple copies of their AS to the AS_PATH without requiring the speaker to generate multiple signatures. Note that Section 9.1.2.2 ("Breaking Ties") in [RFC4271] mentions "number of AS numbers" in the AS_PATH attribute that is used in the route selection process. This metric (number of AS numbers) is the same as the AS path length obtained in BGPsec by summing the pCount values in the BGPsec_Path attribute. The pCount field is also useful in managing route servers (see Section 4.2), AS confederations (see Section 4.3), and AS Number migrations (see [I-D.ietf-sidr-as-migration] for details). The left most (i.e. the most significant) bit of the Flags field in Figure 5 is the Confed_Segment flag. The Confed_Segment flag is set to one to indicate that the BGPsec speaker that constructed this Secure_Path Segment is sending the update message to a peer AS within the same Autonomous System confederation [RFC5065]. (That is, a sequence of consecutive the Confed_Segment flags are set in a BGPsec update message whenever, in a non-BGPsec update message, an AS_PATH segment of type AS_CONFED_SEQUENCE occurs.) In all other cases the Confed_Segment flag is set to zero. The remaining seven bits of the Flags are unassigned and MUST be set to zero by the sender, and ignored by the receiver. Note, however, that the signature is computed over all eight bits of the flags field. As stated earlier in Section 2.2, BGPsec peering requires that the peering ASes MUST each support four-byte AS numbers. Currently- assigned two-byte AS numbers are converted into four-byte AS numbers by setting the two high-order octets of the four-octet field to zero [RFC6793]. Lepinski & Sriram Expires July 20, 2017 [Page 9] Internet-Draft BGPsec Protocol January 2017 3.2. Signature_Block A detailed description of the Signature_Blocks in the BGPsec_Path attribute is provided here using Figure 6 and Figure 7. +---------------------------------------------+ | Signature_Block Length (2 octets) | +---------------------------------------------+ | Algorithm Suite Identifier (1 octet) | +---------------------------------------------+ | Sequence of Signature Segments (variable) | +---------------------------------------------+ Figure 6: Signature_Block format. The Signature_Block Length in Figure 6 is the total number of octets in the Signature_Block (including the two octets used to express this length field). The Algorithm Suite Identifier is a one-octet identifier specifying the digest algorithm and digital signature algorithm used to produce the digital signature in each Signature Segment. An IANA registry of algorithm identifiers for use in BGPsec is specified in the BGPsec algorithms document [I-D.ietf-sidr-bgpsec-algs]. A Signature_Block in Figure 6 has exactly one Signature Segment (see Figure 7) for each Secure_Path Segment in the Secure_Path portion of the BGPsec_Path Attribute. (That is, one Signature Segment for each distinct AS on the path for the prefix in the Update message.) +---------------------------------------------+ | Subject Key Identifier (SKI) (20 octets) | +---------------------------------------------+ | Signature Length (2 octets) | +---------------------------------------------+ | Signature (variable) | +---------------------------------------------+ Figure 7: Signature Segment format. The Subject Key Identifier (SKI) field in Figure 7 contains the value in the Subject Key Identifier extension of the RPKI router certificate [RFC6487] that is used to verify the signature (see Section 5 for details on validity of BGPsec update messages). The SKI field has a fixed 20 octets size. See Section 6.2 for considerations for the SKI size. Lepinski & Sriram Expires July 20, 2017 [Page 10] Internet-Draft BGPsec Protocol January 2017 The Signature Length field contains the size (in octets) of the value in the Signature field of the Signature Segment. The Signature in Figure 7 contains a digital signature that protects the prefix and the BGPsec_Path attribute (see Section 4 and Section 5 for details on signature generation and validation, respectively). 4. BGPsec Update Messages Section 4.1 provides general guidance on the creation of BGPsec Update Messages -- that is, update messages containing the BGPsec_Path attribute. Section 4.2 specifies how a BGPsec speaker generates the BGPsec_Path attribute to include in a BGPsec Update message. Section 4.3 contains special processing instructions for members of an autonomous system confederation [RFC5065]. A BGPsec speaker that is not a member of such a confederation MUST NOT set the Confed_Segment flag in its Secure_Path Segment (i.e. leave the flag bit at default value zero) in all BGPsec update messages it sends. Section 4.4 contains instructions for reconstructing the AS_PATH attribute in cases where a BGPsec speaker receives an update message with a BGPsec_Path attribute and wishes to propagate the update message to a peer who does not support BGPsec. 4.1. General Guidance The information protected by the signature on a BGPsec update message includes the AS number of the peer to whom the update message is being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec update to multiple BGP peers, it MUST generate a separate BGPsec update message for each unique peer AS to whom the update message is sent. A BGPsec update message MUST advertise a route to only a single prefix. This is because a BGPsec speaker receiving an update message with multiple prefixes would be unable to construct a valid BGPsec update message (i.e., valid path signatures) containing a subset of the prefixes in the received update. If a BGPsec speaker wishes to advertise routes to multiple prefixes, then it MUST generate a separate BGPsec update message for each prefix. Additionally, a BGPsec update message MUST use the MP_REACH_NLRI [RFC4760] attribute to encode the prefix. The BGPsec_Path attribute and the AS_PATH attribute are mutually exclusive. That is, any update message containing the BGPsec_Path Lepinski & Sriram Expires July 20, 2017 [Page 11] Internet-Draft BGPsec Protocol January 2017 attribute MUST NOT contain the AS_PATH attribute. The information that would be contained in the AS_PATH attribute is instead conveyed in the Secure_Path portion of the BGPsec_Path attribute. In order to create or add a new signature to a BGPsec update message with a given algorithm suite, the BGPsec speaker MUST possess a private key suitable for generating signatures for this algorithm suite. Additionally, this private key must correspond to the public key in a valid Resource PKI end-entity certificate whose AS number resource extension includes the BGPsec speaker's AS number [I-D.ietf-sidr-bgpsec-pki-profiles]. Note also that new signatures are only added to a BGPsec update message when a BGPsec speaker is generating an update message to send to an external peer (i.e., when the AS number of the peer is not equal to the BGPsec speaker's own AS number). The Resource PKI enables the legitimate holder of IP address prefix(es) to issue a signed object, called a Route Origination Authorization (ROA), that authorizes a given AS to originate routes to a given set of prefixes (see RFC 6482 [RFC6482]). It is expected that most relying parties will utilize BGPsec in tandem with origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]). Therefore, it is RECOMMENDED that a BGPsec speaker only originate a BGPsec update advertising a route for a given prefix if there exists a valid ROA authorizing the BGPsec speaker's AS to originate routes to this prefix. If a BGPsec router has received only a non-BGPsec update message containing the AS_PATH attribute (instead of the BGPsec_Path attribute) from a peer for a given prefix, then it MUST NOT attach a BGPsec_Path attribute when it propagates the update message. (Note that a BGPsec router may also receive a non-BGPsec update message from an internal peer without the AS_PATH attribute, i.e., with just the NLRI in it. In that case, the prefix is originating from that AS, and if it is selected for advertisement, the BGPsec speaker SHOULD attach a BGPsec_Path attribute and send a signed route (for that prefix) to its external BGPsec-speaking peers.) Conversely, if a BGPsec router has received a BGPsec update message (with the BGPsec_Path attribute) from a peer for a given prefix and it chooses to propagate that peer's route for the prefix, then it SHOULD propagate the route as a BGPsec update message containing the BGPsec_Path attribute. Note that removing BGPsec signatures (i.e., propagating a route advertisement without the BGPsec_Path attribute) has significant security ramifications. (See Section 8 for discussion of the security ramifications of removing BGPsec signatures.) Therefore, Lepinski & Sriram Expires July 20, 2017 [Page 12] Internet-Draft BGPsec Protocol January 2017 when a route advertisement is received via a BGPsec update message, propagating the route advertisement without the BGPsec_Path attribute is NOT RECOMMENDED, unless the message is sent to a peer that did not advertise the capability to receive BGPsec update messages (see Section 4.4). Furthermore, note that when a BGPsec speaker propagates a route advertisement with the BGPsec_Path attribute it is not attesting to the validation state of the update message it received. (See Section 8 for more discussion of the security semantics of BGPsec signatures.) If the BGPsec speaker is producing an update message which would, in the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is performing proxy aggregation), then the BGPsec speaker MUST NOT include the BGPsec_Path attribute. In such a case, the BGPsec speaker MUST remove any existing BGPsec_Path in the received advertisement(s) for this prefix and produce a traditional (non- BGPsec) update message. It should be noted that BCP 172 [RFC6472] recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH of BGP updates. The case where the BGPsec speaker sends a BGPsec update message to an iBGP peer is quite simple. When originating a new route advertisement and sending it to a BGPsec-capable iBGP peer, the BGPsec speaker omits the BGPsec_Path attribute. When originating a new route advertisement and sending it to a non-BGPsec iBGP peer, the BGPsec speaker includes an empty AS_PATH attribute in the update message. (An empty AS_PATH attribute is one whose length field contains the value zero [RFC4271].) When a BGPsec speaker chooses to forward a BGPsec update message to an iBGP peer, the BGPsec_Path attribute SHOULD NOT be removed, unless the peer doesn't support BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a BGP update with AS_PATH is reconstructed from the BGPsec update and then forwarded (see Section 4.4). In particular, when forwarding to a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_Path attribute SHOULD NOT be removed even in the case where the BGPsec update message has not been successfully validated. (See Section 5 for more information on validation, and Section 8 for the security ramifications of removing BGPsec signatures.) 4.2. Constructing the BGPsec_Path Attribute When a BGPsec speaker receives a BGPsec update message containing a BGPsec_Path attribute (with one or more signatures) from an (internal or external) peer, it may choose to propagate the route advertisement by sending it to its other (internal or external) peers. When sending the route advertisement to an internal BGPsec-speaking peer, Lepinski & Sriram Expires July 20, 2017 [Page 13] Internet-Draft BGPsec Protocol January 2017 the BGPsec_Path attribute SHALL NOT be modified. When sending the route advertisement to an external BGPsec-speaking peer, the following procedures are used to form or update the BGPsec_Path attribute. To generate the BGPsec_Path attribute on the outgoing update message, the BGPsec speaker first generates a new Secure_Path Segment. Note that if the BGPsec speaker is not the origin AS and there is an existing BGPsec_Path attribute, then the BGPsec speaker prepends its new Secure_Path Segment (places in first position) onto the existing Secure_Path. The AS number in this Secure_Path Segment MUST match the AS number in the Subject field of the Resource PKI router certificate that will be used to verify the digital signature constructed by this BGPsec speaker (see Section 3.1.1.1 in [I-D.ietf-sidr-bgpsec-pki-profiles] and RFC 6487 [RFC6487]). The pCount field of the Secure_Path Segment is typically set to the value 1. However, a BGPsec speaker may set the pCount field to a value greater than 1. Setting the pCount field to a value greater than one has the same semantics as repeating an AS number multiple times in the AS_PATH of a non-BGPsec update message (e.g., for traffic engineering purposes). To prevent unnecessary processing load in the validation of BGPsec signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive Secure_Path Segments with the same AS number. This means that to achieve the semantics of prepending the same AS number k times, a BGPsec speaker SHOULD produce a single Secure_Path Segment -- with pCount of k -- and a single corresponding Signature Segment. A route server that participates in the BGP control plane, but does not act as a transit AS in the data plane, may choose to set pCount to 0. This option enables the route server to participate in BGPsec and obtain the associated security guarantees without increasing the length of the AS path. (Note that BGPsec speakers compute the length of the AS path by summing the pCount values in the BGPsec_Path attribute, see Section 5.) However, when a route server sets the pCount value to 0, it still inserts its AS number into the Secure_Path Segment, as this information is needed to validate the signature added by the route server. See [I-D.ietf-sidr-as-migration] for a discussion of setting pCount to 0 to facilitate AS Number Migration. Also see Section 4.3 for the use of pCount=0 in the context of an AS confederation. See Section 7 for operational guidance for configuring a BGPsec router for setting pCount=0 and/or accepting pCount=0 from a peer. Lepinski & Sriram Expires July 20, 2017 [Page 14] Internet-Draft BGPsec Protocol January 2017 Next, the BGPsec speaker generates one or two Signature_Blocks. Typically, a BGPsec speaker will use only a single algorithm suite, and thus create only a single Signature_Block in the BGPsec_Path attribute. However, to ensure backwards compatibility during a period of transition from a 'current' algorithm suite to a 'new' algorithm suite, it will be necessary to originate update messages that contain a Signature_Block for both the 'current' and the 'new' algorithm suites (see Section 6.1). If the received BGPsec update message contains two Signature_Blocks and the BGPsec speaker supports both of the corresponding algorithm suites, then the new update message generated by the BGPsec speaker MUST include both of the Signature_Blocks. If the received BGPsec update message contains two Signature_Blocks and the BGPsec speaker only supports one of the two corresponding algorithm suites, then the BGPsec speaker MUST remove the Signature_Block corresponding to the algorithm suite that it does not understand. If the BGPsec speaker does not support the algorithm suites in any of the Signature_Blocks contained in the received update message, then the BGPsec speaker MUST NOT propagate the route advertisement with the BGPsec_Path attribute. (That is, if it chooses to propagate this route advertisement at all, it MUST do so as an unsigned BGP update message. See Section 4.4 for more information on converting to an unsigned BGP message.) Note that in the case where the BGPsec_Path has two Signature_Blocks (corresponding to different algorithm suites), the validation algorithm (see Section 5.2) deems a BGPsec update message to be 'Valid' if there is at least one supported algorithm suite (and corresponding Signature_Block) that is deemed 'Valid'. This means that a 'Valid' BGPsec update message may contain a Signature_Block which is not deemed 'Valid' (e.g., contains signatures that BGPsec does not successfully verify). Nonetheless, such Signature_Blocks MUST NOT be removed. (See Section 8 for a discussion of the security ramifications of this design choice.) For each Signature_Block corresponding to an algorithm suite that the BGPsec speaker does support, the BGPsec speaker MUST add a new Signature Segment to the Signature_Block. This Signature Segment is prepended to the list of Signature Segments (placed in the first position) so that the list of Signature Segments appears in the same order as the corresponding Secure_Path Segments. The BGPsec speaker populates the fields of this new Signature Segment as follows. The Subject Key Identifier field in the new segment is populated with the identifier contained in the Subject Key Identifier extension of the RPKI router certificate corresponding to the BGPsec speaker [I-D.ietf-sidr-bgpsec-pki-profiles]. This Subject Key Identifier Lepinski & Sriram Expires July 20, 2017 [Page 15] Internet-Draft BGPsec Protocol January 2017 will be used by recipients of the route advertisement to identify the proper certificate to use in verifying the signature. The Signature field in the new segment contains a digital signature that binds the prefix and BGPsec_Path attribute to the RPKI router certificate corresponding to the BGPsec speaker. The digital signature is computed as follows: o For clarity, let us number the Secure_Path and corresponding Signature Segments from 1 to N as follows. Let Secure_Path Segment 1 and Signature Segment 1 be the segments produced by the origin AS. Let Secure_Path Segment 2 and Signature Segment 2 be the segments added by the next AS after the origin. Continue this method of numbering and ultimately let Secure_Path Segment N and Signature Segment N be those that are being added by the current AS. The current AS (Nth AS) is signing and forwarding the update to the next AS (i.e. (N+1)th AS) in the chain of ASes that form the AS path. o In order to construct the digital signature for Signature Segment N (the Signature Segment being produced by the current AS), first construct the sequence of octets to be hashed as shown in Figure 8. This sequence of octets includes all the data that the Nth AS attests to by adding its digital signature in the update which is being forwarded to a BGPsec speaker in the (N+1)th AS. (For the design rationale for choosing the specific structure in Figure 8, please see [Borchert].) Lepinski & Sriram Expires July 20, 2017 [Page 16] Internet-Draft BGPsec Protocol January 2017 +------------------------------------+ | Target AS Number | +------------------------------------+ ---\ | Signature Segment : N-1 | \ +------------------------------------+ | | Secure_Path Segment : N | | +------------------------------------+ \ ... > Data from +------------------------------------+ / N Segments | Signature Segment : 1 | | +------------------------------------+ | | Secure_Path Segment : 2 | | +------------------------------------+ / | Secure_Path Segment : 1 | / +------------------------------------+---/ | Algorithm Suite Identifier | +------------------------------------+ | AFI | +------------------------------------+ | SAFI | +------------------------------------+ | Prefix | +------------------------------------+ Figure 8: Sequence of octets to be hashed. The elements in this sequence (Figure 8) MUST be ordered exactly as shown. The 'Target AS Number' is the AS to whom the BGPsec speaker intends to send the update message. (Note that the 'Target AS Number' is the AS number announced by the peer in the OPEN message of the BGP session within which the update is sent.) The Secure_Path and Signature Segments (1 through N-1) are obtained from the BGPsec_Path attribute. Finally, the Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI), and Prefix fields are obtained from the MP_REACH_NLRI attribute [RFC4760]. Additionally, in the Prefix field all of the trailing bits MUST be set to zero when constructing this sequence. o Apply to this octet sequence (in Figure 8) the digest algorithm (for the algorithm suite of this Signature_Block) to obtain a digest value. o Apply to this digest value the signature algorithm, (for the algorithm suite of this Signature_Block) to obtain the digital signature. Then populate the Signature Field (in Figure 7) with this digital signature. Lepinski & Sriram Expires July 20, 2017 [Page 17] Internet-Draft BGPsec Protocol January 2017 The Signature Length field (in Figure 7) is populated with the length (in octets) of the value in the Signature field. 4.3. Processing Instructions for Confederation Members Members of autonomous system confederations [RFC5065] MUST additionally follow the instructions in this section for processing BGPsec update messages. When a BGPsec speaker in an AS confederation receives a BGPsec update from a peer that is external to the confederation and chooses to propagate the update within the confederation, then it first adds a signature signed to its own Member-AS (i.e. the Target AS number is the BGPsec speaker's Member-AS number). In this internally modified update, the newly added Secure_Path Segment contains the public AS number (i.e. Confederation Identifier), the Segment's pCount value is set to 0, and Confed_Segment flag is set to one. Setting pCount=0 in this case helps ensure that the AS path length is not unnecessarily incremented. The newly added signature is generated using a private key corresponding to the public AS number of the confederation. The BGPsec speaker propagates the modified update to its peers within the confederation. Any BGPsec_Path modifications mentioned below in the context of propagation of the update within the confederation are in addition to the modification described above (with pCount=0). When a BGPsec speaker sends a BGPsec update message to a peer that belongs within its own Member-AS, the confederation member SHALL NOT modify the BGPsec_Path attribute. When a BGPsec speaker sends a BGPsec update message to a peer that is within the same confederation but in a different Member-AS, the BGPsec speaker puts its Member-AS number in the AS Number field of the Secure_Path Segment that it adds to the BGPsec update message. Additionally, in this case, the Member-AS that generates the Secure_Path Segment sets the Confed_Segment flag to one. Further, the signature is generated with a private key corresponding to the BGPsec speaker's Member-AS Number. (Note: In this document, intra-Member-AS peering is regarded as iBGP and inter-Member-AS peering is regarded as eBGP. The latter is also known as confederation-eBGP.) Within a confederation, the verification of BGPsec signatures added by other members of the confederation is optional. Note that if a confederation chooses not to verify digital signatures within the confederation, then BGPsec is able to provide no assurances about the integrity of the Member-AS Numbers placed in Secure_Path Segments where the Confed_Segment flag is set to one. Lepinski & Sriram Expires July 20, 2017 [Page 18] Internet-Draft BGPsec Protocol January 2017 When a confederation member receives a BGPsec update message from a peer within the confederation and propagates it to a peer outside the confederation, it needs to remove all of the Secure_Path Segments added by confederation members as well as the corresponding Signature Segments. To do this, the confederation member propagating the route outside the confederation does the following: o First, starting with the most recently added Secure_Path Segment, remove all of the consecutive Secure_Path Segments that have the Confed_Segment flag set to one. Stop this process once a Secure_Path Segment is reached which has its Confed_Segment flag set to zero. Keep a count of the number of segments removed in this fashion. o Second, starting with the most recently added Signature Segment, remove a number of Signature Segments equal to the number of Secure_Path Segments removed in the previous step. (That is, remove the K most recently added Signature Segments, where K is the number of Secure_Path Segments removed in the previous step.) o Finally, add a Secure_Path Segment containing, in the AS field, the AS Confederation Identifier (the public AS number of the confederation) as well as a corresponding Signature Segment. Note that all fields other than the AS field are populated as per Section 4.2. Finally, as discussed above, an AS confederation MAY optionally decide that its members will not verify digital signatures added by members. In such a confederation, when a BGPsec speaker runs the algorithm in Section 5.2, the BGPsec speaker, during the process of Signature verifications, first checks whether the Confed_Segment flag in a Secure_Path Segment is set to one. If the flag is set to one, the BGPsec speaker skips the verification for the corresponding Signature, and immediately moves on to the next Secure_Path Segment. Note that as specified in Section 5.2, it is an error when a BGPsec speaker receives from a peer, who is not in the same AS confederation, a BGPsec update containing a Confed_Segment flag set to one. 4.4. Reconstructing the AS_PATH Attribute BGPsec update messages do not contain the AS_PATH attribute. However, the AS_PATH attribute can be reconstructed from the BGPsec_Path attribute. This is necessary in the case where a route advertisement is received via a BGPsec update message and then propagated to a peer via a non-BGPsec update message (e.g., because the latter peer does not support BGPsec). Note that there may be additional cases where an implementation finds it useful to perform Lepinski & Sriram Expires July 20, 2017 [Page 19] Internet-Draft BGPsec Protocol January 2017 this reconstruction. Before attempting to reconstruct an AS_PATH for the purpose of forwarding an unsigned (non-BGPsec) update to a peer, a BGPsec speaker MUST perform the basic integrity checks listed in Section 5.2 to ensure that the received BGPsec update is properly formed. The AS_PATH attribute can be constructed from the BGPsec_Path attribute as follows. Starting with a blank AS_PATH attribute, process the Secure_Path Segments in order from least-recently added (corresponding to the origin) to most-recently added. For each Secure_Path Segment perform the following steps: 1. If the Secure_Path Segment has pCount=0, then do nothing (i.e. move on to process the next Secure_Path Segment). 2. If the Secure_Path Segment has pCount greater than 0 and the Confed_Segment flag is set to one, then look at the most-recently added segment in the AS_PATH. * In the case where the AS_PATH is blank or in the case where the most-recently added segment is of type AS_SEQUENCE, add (prepend to the AS_PATH) a new AS_PATH segment of type AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE shall contain a number of elements equal to the pCount field in the current Secure_Path Segment. Each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then the segment of type AS_CONFED_SEQUENCE contains X copies of the Secure_Path Segment's AS Number field.) * In the case where the most-recently added segment in the AS_PATH is of type AS_CONFED_SEQUENCE then add (prepend to the segment) a number of elements equal to the pCount field in the current Secure_Path Segment. The value of each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then add X copies of the Secure_Path Segment's AS Number field to the existing AS_CONFED_SEQUENCE.) 3. If the Secure_Path Segment has pCount greater than 0 and the Confed_Segment flag is set to zero, then look at the most- recently added segment in the AS_PATH. * In the case where the AS_PATH is blank or in the case where the most-recently added segment is of type AS_CONFED_SEQUENCE, add (prepend to the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE. This segment of type AS_SEQUENCE shall contain a number of elements equal to the pCount field in the current Lepinski & Sriram Expires July 20, 2017 [Page 20] Internet-Draft BGPsec Protocol January 2017 Secure_Path Segment. Each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then the segment of type AS_SEQUENCE contains X copies of the Secure_Path Segment's AS Number field.) * In the case where the most recently added segment in the AS_PATH is of type AS_SEQUENCE then add (prepend to the segment) a number of elements equal to the pCount field in the current Secure_Path Segment. The value of each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then add X copies of the Secure_Path Segment's AS Number field to the existing AS_SEQUENCE.) As part of the above described procedure, the following additional actions are performed in order not to exceed the size limitations of AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next Secure_Path Segment (with its prepends, if any) to the AS_PATH being assembled, if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE) at hand to exceed the limit of 255 AS numbers per segment [RFC4271] [RFC5065], then the BGPsec speaker would follow the recommendations in RFC 4271 [RFC4271] and RFC 5065 [RFC5065] of creating another segment of the same type (AS_SEQUENCE or AS_CONFED_SEQUENCE) and continue filling that. Finally, one special case of reconstruction of AS_PATH is when the BGPsec_Path attribute is absent. As explained in Section 4.1, when a BGPsec speaker originates a prefix and sends it to a BGPsec-capable iBGP peer, the BGPsec_Path is not attached. So when received from a BGPsec-capable iBGP peer, no BGPsec_Path attribute in a BGPsec update is equivalent to an empty AS_PATH [RFC4271]. 5. Processing a Received BGPsec Update Upon receiving a BGPsec update message from an external (eBGP) peer, a BGPsec speaker SHOULD validate the message to determine the authenticity of the path information contained in the BGPsec_Path attribute. Typically, a BGPsec speaker will also wish to perform origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]) on an incoming BGPsec update message, but such validation is independent of the validation described in this section. Section 5.1 provides an overview of BGPsec validation and Section 5.2 provides a specific algorithm for performing such validation. (Note that an implementation need not follow the specific algorithm in Section 5.2 as long as the input/output behavior of the validation is identical to that of the algorithm in Section 5.2.) During Lepinski & Sriram Expires July 20, 2017 [Page 21] Internet-Draft BGPsec Protocol January 2017 exceptional conditions (e.g., the BGPsec speaker receives an incredibly large number of update messages at once) a BGPsec speaker MAY temporarily defer validation of incoming BGPsec update messages. The treatment of such BGPsec update messages, whose validation has been deferred, is a matter of local policy. However, an implementation SHOULD ensure that deferment of validation and status of deferred messages is visible to the operator. The validity of BGPsec update messages is a function of the current RPKI state. When a BGPsec speaker learns that RPKI state has changed (e.g., from an RPKI validating cache via the RPKI-to-Router protocol [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]), the BGPsec speaker MUST re-run validation on all affected update messages stored in its Adj-RIB-In [RFC4271]. For example, when a given RPKI certificate ceases to be valid (e.g., it expires or is revoked), all update messages containing a signature whose SKI matches the SKI in the given certificate MUST be re-assessed to determine if they are still valid. If this reassessment determines that the validity state of an update has changed then, depending on local policy, it may be necessary to re-run best path selection. BGPsec update messages do not contain an AS_PATH attribute. The Secure_Path contains AS path information for the BGPsec update message. Therefore, a BGPsec speaker MUST utilize the AS path information in the Secure_Path in all cases where it would otherwise use the AS path information in the AS_PATH attribute. The only exception to this rule is when AS path information must be updated in order to propagate a route to a peer (in which case the BGPsec speaker follows the instructions in Section 4). Section 4.4 provides an algorithm for constructing an AS_PATH attribute from a BGPsec_Path attribute. Whenever the use of AS path information is called for (e.g., loop detection, or use of AS path length in best path selection) the externally visible behavior of the implementation shall be the same as if the implementation had run the algorithm in Section 4.4 and used the resulting AS_PATH attribute as it would for a non-BGPsec update message. 5.1. Overview of BGPsec Validation Validation of a BGPsec update messages makes use of data from RPKI certificates. In particular, it is necessary that the recipient have access to the following data obtained from valid RPKI certificates: the AS Number, Public Key and Subject Key Identifier from each valid RPKI router certificate. Note that the BGPsec speaker could perform the validation of RPKI certificates on its own and extract the required data, or it could receive the same data from a trusted cache that performs RPKI Lepinski & Sriram Expires July 20, 2017 [Page 22] Internet-Draft BGPsec Protocol January 2017 validation on behalf of (some set of) BGPsec speakers. (For example, the trusted cache could deliver the necessary validity information to the BGPsec speaker using the router key PDU for the RPKI-to-Router protocol [I-D.ietf-sidr-rpki-rtr-rfc6810-bis].) To validate a BGPsec update message containing the BGPsec_Path attribute, the recipient performs the validation steps specified in Section 5.2. The validation procedure results in one of two states: 'Valid' and 'Not Valid'. It is expected that the output of the validation procedure will be used as an input to BGP route selection. That said, BGP route selection, and thus the handling of the validation states is a matter of local policy, and is handled using local policy mechanisms. Implementations SHOULD enable operators to set such local policy on a per-session basis. (That is, it is expected that some operators will choose to treat BGPsec validation status differently for update messages received over different BGP sessions.) BGPsec validation needs only be performed at the eBGP edge. The validation status of a BGP signed/unsigned update MAY be conveyed via iBGP from an ingress edge router to an egress edge router via some mechanism, according to local policy within an AS. As discussed in Section 4, when a BGPsec speaker chooses to forward a (syntactically correct) BGPsec update message, it SHOULD be forwarded with its BGPsec_Path attribute intact (regardless of the validation state of the update message). Based entirely on local policy, an egress router receiving a BGPsec update message from within its own AS MAY choose to perform its own validation. 5.2. Validation Algorithm This section specifies an algorithm for validation of BGPsec update messages. A conformant implementation MUST include a BGPsec update validation algorithm that is functionally equivalent to the externally visible behavior of this algorithm. First, the recipient of a BGPsec update message performs a check to ensure that the message is properly formed. Both syntactical and protocol violation errors are checked. BGPsec_Path attribute MUST be present when a BGPsec update is received from an external (eBGP) BGPsec peer and also when such an update is propagated to an internal (iBGP) BGPsec peer (see Section 4.2). The error checks specified in Section 6.3 of [RFC4271] are performed, except that for BGPsec updates the checks on the AS_PATH attribute do not apply and instead the following checks on BGPsec_Path attribute are performed: Lepinski & Sriram Expires July 20, 2017 [Page 23] Internet-Draft BGPsec Protocol January 2017 1. Check to ensure that the entire BGPsec_Path attribute is syntactically correct (conforms to the specification in this document). 2. Check that AS number in the most recently added Secure_Path Segment (i.e. the one corresponding to the eBGP peer from which the update message was received) matches the AS number of that peer as specified in the BGP OPEN message. (Note: This check is performed only at an ingress BGPsec routers where the update is first received from a peer AS.) 3. Check that each Signature_Block contains one Signature Segment for each Secure_Path Segment in the Secure_Path portion of the BGPsec_Path attribute. (Note that the entirety of each Signature_Block MUST be checked to ensure that it is well formed, even though the validation process may terminate before all signatures are cryptographically verified.) 4. Check that the update message does not contain an AS_PATH attribute. 5. If the update message was received from an BGPsec peer that is not a member of the BGPsec speaker's AS confederation, check to ensure that none of the Secure_Path Segments contain a Flags field with the Confed_Segment flag set to one. 6. If the update message was received from a BGPsec peer that is a member of the BGPsec speaker's AS confederation, check to ensure that the Secure_Path Segment corresponding to that peer contains a Flags field with the Confed_Segment flag set to one. 7. If the update message was received from a peer that is not expected to set pCount=0 (see Section 4.2 and Section 4.3) then check to ensure that the pCount field in the most-recently added Secure_Path Segment is not equal to zero. (Note: See router configuration guidance related to this in Section 7.) 8. Using the equivalent of AS_PATH corresponding to the Secure_Path in the update (see Section 4.4), check that the local AS number is not present in the AS path (i.e. rule out AS loop). If any of these checks fail, it is an error in the BGPsec_Path attribute. BGPsec speakers MUST handle any syntactical or protocol errors in the BGPsec_Path attribute using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]. (Note: Since the AS number of a transparent route server does appear in the Secure_Path with pCount=0, the route server MAY check if its local AS is listed Lepinski & Sriram Expires July 20, 2017 [Page 24] Internet-Draft BGPsec Protocol January 2017 in the Secure_Path, and this check MAY be included in the loop detection check listed above.) Next, the BGPsec speaker examines the Signature_Blocks in the BGPsec_Path attribute. A Signature_Block corresponding to an algorithm suite that the BGPsec speaker does not support is not considered in validation. If there is no Signature_Block corresponding to an algorithm suite that the BGPsec speaker supports, then in order to consider the update in the route selection process, the BGPsec speaker MUST strip the Signature_Block(s), reconstruct the AS_PATH from the Secure_Path (see Section 4.4), and treat the update as if it was received as an unsigned BGP update. For each remaining Signature_Block (corresponding to an algorithm suite supported by the BGPsec speaker), the BGPsec speaker iterates through the Signature Segments in the Signature_Block, starting with the most recently added segment (and concluding with the least recently added segment). Note that there is a one-to-one correspondence between Signature Segments and Secure_Path Segments within the BGPsec_Path attribute. The following steps make use of this correspondence. o (Step 1): Let there be K AS hops in a received BGPsec_Path attribute that is to be validated. Let AS(1), AS(2), ..., AS(K+1) denote the sequence of AS numbers from the origin AS to the validating AS. Let Secure_Path Segment N and Signature Segment N in the BGPsec_Path attribute refer to those corresponding to AS(N) (where N = 1, 2, ..., K). The BGPsec speaker that is processing and validating the BGPsec_Path attribute resides in AS(K+1). Let Signature Segment N be the Signature Segment that is currently being verified. o (Step 2): Locate the public key needed to verify the signature (in the current Signature Segment). To do this, consult the valid RPKI router certificate data and look up all valid (AS, SKI, Public Key) triples in which the AS matches the AS number in the corresponding Secure_Path Segment. Of these triples that match the AS number, check whether there is an SKI that matches the value in the Subject Key Identifier field of the Signature Segment. If this check finds no such matching SKI value, then mark the entire Signature_Block as 'Not Valid' and proceed to the next Signature_Block. o (Step 3): Compute the digest function (for the given algorithm suite) on the appropriate data. In order to verify the digital signature in Signature Segment N, construct the sequence of octets to be hashed as shown in Figure 9 Lepinski & Sriram Expires July 20, 2017 [Page 25] Internet-Draft BGPsec Protocol January 2017 (using the notations defined in Step 1). (Note that this sequence is the same sequence that was used by AS(N) that created the Signature Segment N (see Section 4.2 and Figure 8).) +------------------------------------+ | Target AS Number | +------------------------------------+ ---\ | Signature Segment : N-1 | \ +------------------------------------+ | | Secure_Path Segment : N | | +------------------------------------+ \ ... > Data from +------------------------------------+ / N Segments | Signature Segment : 1 | | +------------------------------------+ | | Secure_Path Segment : 2 | | +------------------------------------+ / | Secure_Path Segment : 1 | / +------------------------------------+---/ | Algorithm Suite Identifier | +------------------------------------+ | AFI | +------------------------------------+ | SAFI | +------------------------------------+ | Prefix | +------------------------------------+ Figure 9: The Sequence of octets to be hashed for signature verification of Signature Segment N; N = 1,2, ..., K, where K is the number of AS hops in the BGPsec_Path attribute. The elements in this sequence (Figure 9) MUST be ordered exactly as shown. For the first segment to be processed (the most recently added segment (i.e. N = K) given that there are K hops in the Secure_Path), the 'Target AS Number' is AS(K+1), the AS number of the BGPsec speaker validating the update message. Note that if a BGPsec speaker uses multiple AS Numbers (e.g., the BGPsec speaker is a member of a confederation), the AS number used here MUST be the AS number announced in the OPEN message for the BGP session over which the BGPsec update was received. For each other Signature Segment (N smaller than K), the 'Target AS Number' is AS(N+1), the AS number in the Secure_Path Segment that corresponds to the Signature Segment added immediately after the one being processed. (That is, in the Secure_Path Segment Lepinski & Sriram Expires July 20, 2017 [Page 26] Internet-Draft BGPsec Protocol January 2017 that corresponds to the Signature Segment that the validator just finished processing.) The Secure_Path and Signature Segment are obtained from the BGPsec_Path attribute. The Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI), and Prefix fields are obtained from the MP_REACH_NLRI attribute [RFC4760]. Additionally, in the Prefix field all of the trailing bits MUST be set to zero when constructing this sequence. o (Step 4): Use the signature validation algorithm (for the given algorithm suite) to verify the signature in the current segment. That is, invoke the signature validation algorithm on the following three inputs: the value of the Signature field in the current segment; the digest value computed in Step 3 above; and the public key obtained from the valid RPKI data in Step 2 above. If the signature validation algorithm determines that the signature is invalid, then mark the entire Signature_Block as 'Not Valid' and proceed to the next Signature_Block. If the signature validation algorithm determines that the signature is valid, then continue processing Signature Segments (within the current Signature_Block). If all Signature Segments within a Signature_Block pass validation (i.e., all segments are processed and the Signature_Block has not yet been marked 'Not Valid'), then the Signature_Block is marked as 'Valid'. If at least one Signature_Block is marked as 'Valid', then the validation algorithm terminates and the BGPsec update message is deemed to be 'Valid'. (That is, if a BGPsec update message contains two Signature_Blocks then the update message is deemed 'Valid' if the first Signature_Block is marked 'Valid' OR the second Signature_Block is marked 'Valid'.) 6. Algorithms and Extensibility 6.1. Algorithm Suite Considerations Note that there is currently no support for bilateral negotiation (using BGP capabilities) between BGPsec peers to use a particular (digest and signature) algorithm suite. This is because the algorithm suite used by the sender of a BGPsec update message MUST be understood not only by the peer to whom it is directly sending the message, but also by all BGPsec speakers to whom the route advertisement is eventually propagated. Therefore, selection of an algorithm suite cannot be a local matter negotiated by BGP peers, but instead must be coordinated throughout the Internet. Lepinski & Sriram Expires July 20, 2017 [Page 27] Internet-Draft BGPsec Protocol January 2017 To this end, a mandatory algorithm suites document exists which specifies a mandatory-to-use 'current' algorithm suite for use by all BGPsec speakers [I-D.ietf-sidr-bgpsec-algs]. It is anticipated that, in the future, the mandatory algorithm suites document will be updated to specify a transition from the 'current' algorithm suite to a 'new' algorithm suite. During the period of transition, all BGPsec update messages SHOULD simultaneously use both the 'current' algorithm suite and the 'new' algorithm suite. (Note that Section 3 and Section 4 specify how the BGPsec_Path attribute can contain signatures, in parallel, for two algorithm suites.) Once the transition is complete, use of the old 'current' algorithm will be deprecated, use of the 'new' algorithm will be mandatory, and a subsequent 'even newer' algorithm suite may be specified as recommended to implement. Once the transition has successfully been completed in this manner, BGPsec speakers SHOULD include only a single Signature_Block (corresponding to the 'new' algorithm). 6.2. Considerations for the SKI Size Depending on the method of generating key identifiers [RFC7093], the size of the SKI in a RPKI router certificate may vary. The SKI field in the BGPsec_Path attribute has a fixed 20 octets size (see Figure 7). If the SKI is longer than 20 octets, then use the leftmost 20 octets of the SKI (excluding the tag and length) [RFC7093]. If the SKI value is shorter than 20 octets, then pad the SKI (excluding the tag and length) to the right (least significant octets) with octets having zero values. 6.3. Extensibility Considerations This section discusses potential changes to BGPsec that would require substantial changes to the processing of the BGPsec_Path and thus necessitate a new version of BGPsec. Examples of such changes include: o A new type of signature algorithm that produces signatures of variable length o A new type of signature algorithm for which the number of signatures in the Signature_Block is not equal to the number of ASes in the Secure_Path (e.g., aggregate signatures) o Changes to the data that is protected by the BGPsec signatures (e.g., attributes other than the AS path) In the case that such a change to BGPsec were deemed desirable, it is expected that a subsequent version of BGPsec would be created and Lepinski & Sriram Expires July 20, 2017 [Page 28] Internet-Draft BGPsec Protocol January 2017 that this version of BGPsec would specify a new BGP path attribute, let's call it BGPsec_Path_Two, which is designed to accommodate the desired changes to BGPsec. In such a case, the mandatory algorithm suites document would be updated to specify algorithm suites appropriate for the new version of BGPsec. At this point a transition would begin which is analogous to the algorithm transition discussed in Section 6.1. During the transition period all BGPsec speakers SHOULD simultaneously include both the BGPsec_Path attribute and the new BGPsec_Path_Two attribute. Once the transition is complete, the use of BGPsec_Path could then be deprecated, at which point BGPsec speakers should include only the new BGPsec_Path_Two attribute. Such a process could facilitate a transition to a new BGPsec semantics in a backwards compatible fashion. 7. Operations and Management Considerations Some operations and management issues that are closely relevant to BGPsec protocol specification and its deployment are highlighted here. The Best Current Practices concerning operations and deployment of BGPsec are provided in [I-D.ietf-sidr-bgpsec-ops]. Section 2.2 describes the negotiation required to establish a BGPsec- capable peering session. Not only must the BGPsec capability be exchanged (and agreed on), but the BGP multiprotocol extension [RFC4760] for the same AFI and the four-byte AS capability [RFC6793] MUST also be exchanged. Failure to properly negotiate a BGPsec session, due to a missing capability, for example, may still result in the exchange of BGP (unsigned) updates. It is RECOMMENDED that an implementation log the failure to properly negotiate a BGPsec session. Also, an implementation MUST have the ability to prevent a BGP session from being established if configured for only BGPsec use. A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) with a transparent AS is expected to set pCount=0 in its Secure_Path Segment while forwarding an update to a peer (see Section 4.2). Clearly, such an IXP MUST configure its BGPsec router to set pCount=0 in its Secure_Path Segment. This also means that a BGPsec speaker MUST be configured so that it permits pCount=0 from an IXP peer. Two other cases where pCount is set to zero are in the context AS confederation (see Section 4.2) and AS migration [I-D.ietf-sidr-as-migration]. In these two cases, pCount=0 is set and accepted within the same AS (albeit the AS has two different identities). Note that if a BGPsec speaker does not expect a peer AS to set its pCount=0, and if an update received from that peer violates this, then the update MUST be considered to be in error (see Lepinski & Sriram Expires July 20, 2017 [Page 29] Internet-Draft BGPsec Protocol January 2017 the list of checks in Section 5.2). See Section 8.4 for a discussion of security considerations concerning pCount=0. During the validation of a BGPsec update, route processor performance speedup can be achieved by incorporating the following observations. An update is deemed 'Valid' if at least one of the Signature_Blocks is marked as 'Valid' (see Section 5.2). Therefore, if an update contains two Signature_Blocks and the first one verified is found 'Valid', then the second Signature_Block does not have to be verified. And if the update is chosen for best path, then the BGPsec speaker adds its signature (generated with the respective algorithm) to each of the two Signature_Blocks and forwards the update. Also, a BGPsec update is deemed 'Not Valid' if at least one signature in each of the Signature_Blocks is invalid. This principle can also be used for route processor workload savings, i.e. the verification for a Signature_Block terminates early when the first invalid signature is encountered. Many signature algorithms are non-deterministic. That is, many signature algorithms will produce different signatures each time they are run (even when they are signing the same data with the same key). Therefore, if a BGPsec router receives a BGPsec update from a peer and later receives a second BGPsec update message from the same peer for the same prefix with the same Secure_Path and SKIs, the second update MAY differ from the first update in the signature fields (for a non-deterministic signature algorithm). However, the two sets of signature fields will not differ if the sender caches and reuses the previous signature. For a deterministic signature algorithm, the signature fields MUST be identical between the two updates. On the basis of these observations, an implementation MAY incorporate optimizations in update validation processing. In Section 2.2, is was stated that a BGPsec speaker SHOULD announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. Lack of negotiation of this capability is not expected to pose a problem in the early years of BGPsec deployment. However, as BGPsec is deployed more and more, the BGPsec update messages would grow in size and some messages may be dropped due to their size exceeding the current 4K bytes limit. Therefore, it is strongly RECOMMENDED that all BGPsec speakers negotiate the extended message capability within a reasonable period of time after initial deployment of BGPsec. It is possible that a stub customer of an ISP employs a private AS number. Such a stub customer cannot publish a ROA in the global RPKI for the private AS number and the prefixes that they use. Also, the global RPKI cannot support private AS numbers (i.e. BGPsec speakers in private ASes cannot be issued router certificates in the global Lepinski & Sriram Expires July 20, 2017 [Page 30] Internet-Draft BGPsec Protocol January 2017 RPKI). For interactions between the stub customer and the ISP, the following two scenarios are possible: 1. The stub customer sends an unsigned BGP update for a prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the private AS number, and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the global RPKI authorizing the ISP's AS to originate it. 2. The ISP and the stub customer may use a local RPKI repository (using a mechanism such as described in [I-D.ietf-sidr-slurm]). Then there can be a ROA for the prefix originated by the stub AS, and the eBGP speaker in the stub AS can be a BGPsec speaker having a router certificate, albeit the ROA and router certificate are valid only locally. With this arrangement, the stub AS sends a signed update for the prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS validates the update using RPKI data based the local RPKI view. Further, it may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the Secure_Path and the Signature Segment received from the stub AS with the private AS number, and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the global RPKI authorizing the ISP's AS to originate it. It is possible that private AS numbers are used in an AS confederation [RFC5065]. BGPsec protocol requires that when a BGPsec update propagates through a confederation, each Member-AS that forwards it to a peer Member-AS MUST sign the update (see Section 4.3). However, the global RPKI cannot support private AS numbers. In order for the BGPsec speakers in Member-ASes with private AS numbers to have digital certificates, there MUST be a mechanism in place in the confederation that allows establishment of a local, customized view of the RPKI, augmenting the global RPKI repository data as needed. Since this mechanism (for augmenting and maintaining a local image of RPKI data) operates locally within an AS or AS confederation, it need not be standard based. However, a standard-based mechanism can be used (see [I-D.ietf-sidr-slurm]). Recall that in order to prevent exposure of the internals of AS confederations, a BGPsec speaker exporting to a non-member removes all intra-confederation Secure_Path Segments and Signatures (see Section 4.3). Lepinski & Sriram Expires July 20, 2017 [Page 31] Internet-Draft BGPsec Protocol January 2017 The deployment structure, technologies and best practices concerning global RPKI data to reach routers (via local RPKI caches) are described in [RFC6810] [I-D.ietf-sidr-rpki-rtr-rfc6810-bis] [I-D.ietf-sidr-publication] [RFC7115] [I-D.ietf-sidr-bgpsec-ops] [I-D.ietf-sidr-delta-protocol]. For example, serial-number based incremental update mechanisms are used for efficient transfer of just the data records that have changed since last update [RFC6810] [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]. Update notification file is used by relying parties (RPs) to discover whether any changes exist between the state of the global RPKI repository and the RP's cache [I-D.ietf-sidr-delta-protocol]. The notification describes the location of the files containing the snapshot and incremental deltas which can be used by the RP to synchronize with the repository. Making use of these technologies and best practices results in enabling robustness, efficiency, and better security for the BGPsec routers and RPKI caches in terms of the flow of RPKI data from repositories to RPKI caches to routers. With these mechanisms, it is believed that an attacker wouldn't be able to meaningfully correlate RPKI data flows with BGPsec RP (or router) actions, thus avoiding attacks that may attempt to determine the set of ASes interacting with an RP via the interactions between the RP and RPKI servers. During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale as well as not differentiating between stale and other information during forwarding will be the same as specified in [RFC4724]. The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 is used for signing updates in BGPsec [I-D.ietf-sidr-bgpsec-algs]. For ECDSA, it is stated in Section 6.3 of [FIPS186-4] that a new secret random number "k" shall be generated prior to the generation of each digital signature. A high entropy random bit generator (RBG) must be used for generating "k", and any potential bias in the "k" generation algorithm must be mitigated (see methods described in [FIPS186-4] [SP800-90A]). How will migration from BGP to BGPsec look like? What are the benefits for the first adopters? Initially small groups of contiguous ASes would be doing BGPsec. There would be possibly one or more such groups in different geographic regions of the global Internet. Only the routes originated within each group and propagated within its borders would get the benefits of cryptographic AS path protection. As BGPsec adoption grows, each group grows in size and eventually they join together to form even larger BGPsec capable groups of contiguous ASes. The benefit for early adopters Lepinski & Sriram Expires July 20, 2017 [Page 32] Internet-Draft BGPsec Protocol January 2017 starts with AS path security within the contiguous-AS regions spanned by their respective groups. Over time they would see those contiguous-AS regions grow much larger. 8. Security Considerations For a discussion of the BGPsec threat model and related security considerations, please see RFC 7132 [RFC7132]. 8.1. Security Guarantees When used in conjunction with Origin Validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a valid BGPsec update message, containing a route advertisement for a given prefix, is provided with the following security guarantees: o The origin AS number corresponds to an autonomous system that has been authorized, in the RPKI, by the IP address space holder to originate route advertisements for the given prefix. o For each AS in the path, a BGPsec speaker authorized by the holder of the AS number intentionally chose (in accordance with local policy) to propagate the route advertisement to the subsequent AS in the path. That is, the recipient of a valid BGPsec update message is assured that the update propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_Path attribute. (It should be noted that BGPsec does not offer any guarantee that the data packets would flow along the indicated path; it only guarantees that the BGP update conveying the path indeed propagated along the indicated path.) Furthermore, the recipient is assured that this path terminates in an autonomous system that has been authorized by the IP address space holder as a legitimate destination for traffic to the given prefix. Note that although BGPsec provides a mechanism for an AS to validate that a received update message has certain security properties, the use of such a mechanism to influence route selection is completely a matter of local policy. Therefore, a BGPsec speaker can make no assumptions about the validity of a route received from an external (eBGP) BGPsec peer. That is, a compliant BGPsec peer may (depending on the local policy of the peer) send update messages that fail the validity test in Section 5. Thus, a BGPsec speaker MUST completely validate all BGPsec update messages received from external peers. (Validation of update messages received from internal peers is a matter of local policy, see Section 5). Lepinski & Sriram Expires July 20, 2017 [Page 33] Internet-Draft BGPsec Protocol January 2017 8.2. On the Removal of BGPsec Signatures There may be cases where a BGPsec speaker deems 'Valid' (as per the validation algorithm in Section 5.2) a BGPsec update message that contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, the update message contains two sets of signatures corresponding to two algorithm suites, and one set of signatures verifies correctly and the other set of signatures fails to verify. In this case, the protocol specifies that a BGPsec speaker choosing to propagate the route advertisement in such an update message MUST add its signature to each of the Signature_Blocks (see Section 4.2). Thus the BGPsec speaker creates a signature using both algorithm suites and creates a new update message that contains both the 'Valid' and the 'Not Valid' set of signatures (from its own vantage point). To understand the reason for such a design decision, consider the case where the BGPsec speaker receives an update message with both a set of algorithm A signatures which are 'Valid' and a set of algorithm B signatures which are 'Not Valid'. In such a case it is possible (perhaps even likely, depending on the state of the algorithm transition) that some of the BGPsec speaker's peers (or other entities further 'downstream' in the BGP topology) do not support algorithm A. Therefore, if the BGPsec speaker were to remove the 'Not Valid' set of signatures corresponding to algorithm B, such entities would treat the message as though it were unsigned. By including the 'Not Valid' set of signatures when propagating a route advertisement, the BGPsec speaker ensures that 'downstream' entities have as much information as possible to make an informed opinion about the validation status of a BGPsec update. Note also that during a period of partial BGPsec deployment, a 'downstream' entity might reasonably treat unsigned messages differently from BGPsec updates that contain a single set of 'Not Valid' signatures. That is, by removing the set of 'Not Valid' signatures the BGPsec speaker might actually cause a downstream entity to 'upgrade' the status of a route advertisement from 'Not Valid' to unsigned. Finally, note that in the above scenario, the BGPsec speaker might have deemed algorithm A signatures 'Valid' only because of some issue with RPKI state local to its AS (for example, its AS might not yet have obtained a CRL indicating that a key used to verify an algorithm A signature belongs to a newly revoked certificate). In such a case, it is highly desirable for a downstream entity to treat the update as 'Not Valid' (due to the revocation) and not as 'unsigned' (which would happen if the 'Not Valid' Signature_Blocks were removed). A similar argument applies to the case where a BGPsec speaker (for some reason such as lack of viable alternatives) selects as its best Lepinski & Sriram Expires July 20, 2017 [Page 34] Internet-Draft BGPsec Protocol January 2017 path (to a given prefix) a route obtained via a 'Not Valid' BGPsec update message. In such a case, the BGPsec speaker should propagate a signed BGPsec update message, adding its signature to the 'Not Valid' signatures that already exist. Again, this is to ensure that 'downstream' entities are able to make an informed decision and not erroneously treat the route as unsigned. It should also be noted that due to possible differences in RPKI data observed at different vantage points in the network, a BGPsec update deemed 'Not Valid' at an upstream BGPsec speaker may be deemed 'Valid' by another BGP speaker downstream. Indeed, when a BGPsec speaker signs an outgoing update message, it is not attesting to a belief that all signatures prior to its are valid. Instead it is merely asserting that: o The BGPsec speaker received the given route advertisement with the indicated prefix, AFI, SAFI, and Secure_Path; and o The BGPsec speaker chose to propagate an advertisement for this route to the peer (implicitly) indicated by the 'Target AS Number'. 8.3. Mitigation of Denial of Service Attacks The BGPsec update validation procedure is a potential target for denial of service attacks against a BGPsec speaker. The mitigation of denial of service attacks that are specific to the BGPsec protocol is considered here. To mitigate the effectiveness of such denial of service attacks, BGPsec speakers should implement an update validation algorithm that performs expensive checks (e.g., signature verification) after performing less expensive checks (e.g., syntax checks). The validation algorithm specified in Section 5.2 was chosen so as to perform checks which are likely to be expensive after checks that are likely to be inexpensive. However, the relative cost of performing required validation steps may vary between implementations, and thus the algorithm specified in Section 5.2 may not provide the best denial of service protection for all implementations. Additionally, sending update messages with very long AS paths (and hence a large number of signatures) is a potential mechanism to conduct denial of service attacks. For this reason, it is important that an implementation of the validation algorithm stops attempting to verify signatures as soon as an invalid signature is found. (This ensures that long sequences of invalid signatures cannot be used for denial of service attacks.) Furthermore, implementations can mitigate such attacks by only performing validation on update Lepinski & Sriram Expires July 20, 2017 [Page 35] Internet-Draft BGPsec Protocol January 2017 messages that, if valid, would be selected as the best path. That is, if an update message contains a route that would lose out in best path selection for other reasons (e.g., a very long AS path) then it is not necessary to determine the BGPsec-validity status of the route. 8.4. Additional Security Considerations The mechanism of setting the pCount field to zero is included in this specification to enable route servers in the control path to participate in BGPsec without increasing the length of the AS path. Two other scenarios where pCount=0 is utilized are in the context AS confederation (see Section 4.2) and AS migration [I-D.ietf-sidr-as-migration]. In these two scenarios, pCount=0 is set and also accepted within the same AS (albeit the AS has two different identities). However, entities other than route servers, confederation ASes or migrating ASes could conceivably use this mechanism (set the pCount to zero) to attract traffic (by reducing the length of the AS path) illegitimately. This risk is largely mitigated if every BGPsec speaker follows the operational guidance in Section 7 for configuration for setting pCount=0 and/or accepting pCount=0 from a peer. However, note that a recipient of a BGPsec update message within which an upstream entity two or more hops away has set pCount to zero is unable to verify for themselves whether pCount was set to zero legitimately. There is a possibility of passing a BGPsec update via tunneling between colluding ASes. For example, say, AS-X does not peer with AS-Y, but colludes with AS-Y, signs and sends a BGPsec update to AS-Y by tunneling. AS-Y can then further sign and propagate the BGPsec update to its peers. It is beyond the scope of the BGPsec protocol to detect this form of malicious behavior. BGPsec is designed to protect messages sent within BGP (i.e. within the control plane) - not when the control plane in bypassed. A variant of the collusion by tunneling mentioned above can happen in the context of AS confederations. When a BGPsec router (outside of a confederation) is forwarding an update to a Member-AS in the confederation, it signs the update to the public AS number of the confederation and not to the member's AS number (see Section 4.3). The Member-AS can tunnel the signed update to another Member-AS as received (i.e. without adding a signature). The update can then be propagated using BGPsec to other confederation members or to BGPsec neighbors outside of the confederation. This kind of operation is possible, but no grave security or reachability compromise is feared for the following reasons: (1) The confederation members belong to one organization and strong internal trust is expected; and (2) Recall that the signatures that are internal to the confederation Lepinski & Sriram Expires July 20, 2017 [Page 36] Internet-Draft BGPsec Protocol January 2017 MUST be removed prior to forwarding the update to an outside BGPsec router (see Section 4.3). BGPsec does not provide protection against attacks at the transport layer. As with any BGP session, an adversary on the path between a BGPsec speaker and its peer is able to perform attacks such as modifying valid BGPsec updates to cause them to fail validation, injecting (unsigned) BGP update messages without BGPsec_Path attributes, injecting BGPsec update messages with BGPsec_Path attributes that fail validation, or causing the peer to tear-down the BGP session. The use of BGPsec does nothing to increase the power of an on-path adversary -- in particular, even an on-path adversary cannot cause a BGPsec speaker to believe a BGPsec-invalid route is valid. However, as with any BGP session, BGPsec sessions SHOULD be protected by appropriate transport security mechanisms (see the Security Considerations section in [RFC4271]). There is a possibility of replay attacks which are defined as follows. In the context of BGPsec, a replay attack occurs when a malicious BGPsec speaker in the AS path suppresses a prefix withdrawal (implicit or explicit). Further, a replay attack is said to occur also when a malicious BGPsec speaker replays a previously received BGPsec announcement for a prefix that has since been withdrawn. The mitigation strategy for replay attacks involves router certificate rollover; please see [I-D.ietf-sidr-bgpsec-rollover] for details. 9. IANA Considerations IANA is requested to register a new BGP capability from Section 2.1 in the BGP Capabilities Code registry's "IETF Review" range. The description for the new capability is "BGPsec Capability". The reference for the new capability is this document (i.e. the RFC that replaces draft-ietf-sidr-bgpsec-protocol). IANA is also requested to register a new path attribute from Section 3 in the BGP Path Attributes registry. The code for this new attribute is "BGPsec_Path". The reference for the new capability is this document (i.e. the RFC that replaces draft-ietf-sidr-bgpsec- protocol). IANA is requested to define the "BGPsec Capability" registry in the Resource Public Key Infrastructure (RPKI) group. The registry is as shown in Figure 10 with values assigned from Section 2.1: Lepinski & Sriram Expires July 20, 2017 [Page 37] Internet-Draft BGPsec Protocol January 2017 +------+------------------------------------+------------+ | Bits | Field | Reference | +------+------------------------------------+------------+ | 0-3 | Version | [This RFC] | | +------------------------------------+------------+ | | Value = 0x0 | [This RFC] | +------+------------------------------------+------------+ | 4 | Direction | [This RFC] | | +------------------------------------+------------+ | |(Both possible values 0 and 1 are | [This RFC] | | | fully specified by this RFC) | | +------+------------------------------------+------------+ | 5-7 | Unassigned | [This RFC] | | +------------------------------------+------------+ | | Value = 000 (in binary) | [This RFC] | +------+------------------------------------+------------+ Figure 10: IANA registry for BGPsec Capability. The Direction bit (4th bit) has value either 0 or 1, and both values are fully specified by this document (i.e. the RFC that replaces draft-ietf-sidr-bgpsec-protocol). Future Version values and future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 5226 [RFC5226]. IANA is requested to define the "BGPsec_Path Flags" registry in the RPKI group. The registry is as shown in Figure 11 with one value assigned from Section 3.1: +------+-------------------------------------------+------------+ | Flag | Description | Reference | +------+-------------------------------------------+------------+ | 0 | Confed_Segment | [This RFC] | +------+-------------------------------------------+------------+ | | Bit value = 1 means Flag set | [This RFC] | | | (indicates Confed_Segment) | | | | Bit value = 0 is default | | +------+-------------------------------------------+------------+ | 1-7 | Unassigned | [This RFC] | | +-------------------------------------------+------------+ | | Value: All 7 bits set to zero | [This RFC] | +------+-------------------------------------------+------------+ Figure 11: IANA registry for BGPsec_Path Flags field. Lepinski & Sriram Expires July 20, 2017 [Page 38] Internet-Draft BGPsec Protocol January 2017 Future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 5226 [RFC5226]. 10. Contributors 10.1. Authors Rob Austein Dragon Research Labs sra@hactrn.net Steven Bellovin Columbia University smb@cs.columbia.edu Randy Bush Internet Initiative Japan randy@psg.com Russ Housley Vigil Security housley@vigilsec.com Matt Lepinski New College of Florida mlepinski@ncf.edu Stephen Kent BBN Technologies kent@bbn.com Warren Kumari Google warren@kumari.net Doug Montgomery USA National Institute of Standards and Technology dougm@nist.gov Kotikalapudi Sriram USA National Institute of Standards and Technology kotikalapudi.sriram@nist.gov Samuel Weiler W3C/MIT weiler@csail.mit.edu Lepinski & Sriram Expires July 20, 2017 [Page 39] Internet-Draft BGPsec Protocol January 2017 10.2. Acknowledgements The authors would like to thank Michael Baer, Oliver Borchert, David Mandelberg, Mehmet Adalier, Sean Turner, John Scudder, Wes George, Jeff Haas, Keyur Patel, Alvaro Retana, Nevil Brownlee, Matthias Waehlisch, Sandy Murphy, Chris Morrow, Tim Polk, Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Doug Maughan, Pradosh Mohapatra, Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and David Ward for their review, comments, and suggestions during the course of this work. Thanks are also due to many IESG reviewers whose comments greatly helped improve the clarity, accuracy, and presentation in the document. 11. References 11.1. Normative References [I-D.ietf-idr-bgp-extended-messages] Bush, R., Patel, K., and D. Ward, "Extended Message support for BGP", draft-ietf-idr-bgp-extended-messages-14 (work in progress), December 2016. [I-D.ietf-sidr-bgpsec-algs] Turner, S., "BGPsec Algorithms, Key Formats, & Signature Formats", draft-ietf-sidr-bgpsec-algs-16 (work in progress), November 2016. [I-D.ietf-sidr-bgpsec-pki-profiles] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", draft-ietf-sidr-bgpsec-pki- profiles-21 (work in progress), January 2017. [IANA-AF] "Address Family Numbers", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . Lepinski & Sriram Expires July 20, 2017 [Page 40] Internet-Draft BGPsec Protocol January 2017 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . Lepinski & Sriram Expires July 20, 2017 [Page 41] Internet-Draft BGPsec Protocol January 2017 11.2. Informative References [Borchert] Borchert, O. and M. Baer, "Modification request: draft- ietf-sidr-bgpsec-protocol-14", IETF SIDR WG Mailing List message , February 10, 2016, . [FIPS186-4] "FIPS Standards Publication 186-4: Digital Signature Standard", July 2013, . [I-D.ietf-sidr-as-migration] George, W. and S. Murphy, "BGPSec Considerations for AS Migration", draft-ietf-sidr-as-migration-06 (work in progress), December 2016. [I-D.ietf-sidr-bgpsec-ops] Bush, R., "BGPsec Operational Considerations", draft-ietf- sidr-bgpsec-ops-16 (work in progress), January 2017. [I-D.ietf-sidr-bgpsec-rollover] Gagliano, R., Weis, B., and K. Patel, "BGPsec Router Certificate Rollover", draft-ietf-sidr-bgpsec-rollover-06 (work in progress), October 2016. [I-D.ietf-sidr-delta-protocol] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "RPKI Repository Delta Protocol", draft-ietf-sidr-delta- protocol-05 (work in progress), January 2017. [I-D.ietf-sidr-publication] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", draft-ietf-sidr-publication-10 (work in progress), January 2017. [I-D.ietf-sidr-rpki-rtr-rfc6810-bis] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", draft-ietf- sidr-rpki-rtr-rfc6810-bis-08 (work in progress), January 2017. Lepinski & Sriram Expires July 20, 2017 [Page 42] Internet-Draft BGPsec Protocol January 2017 [I-D.ietf-sidr-slurm] Mandelberg, D. and D. Ma, "Simplified Local internet nUmber Resource Management with the RPKI", draft-ietf- sidr-slurm-02 (work in progress), August 2016. [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI 10.17487/RFC6472, December 2011, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, . [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods for Generating Key Identifiers Values", RFC 7093, DOI 10.17487/RFC7093, December 2013, . [RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, . [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, . Lepinski & Sriram Expires July 20, 2017 [Page 43] Internet-Draft BGPsec Protocol January 2017 [SP800-90A] "NIST 800-90A: Deterministic Random Bit Generator Validation System", October 2015, . Authors' Addresses Matthew Lepinski (editor) NCF 5800 Bay Shore Road Sarasota FL 34243 USA Email: mlepinski@ncf.edu Kotikalapudi Sriram (editor) NIST 100 Bureau Drive Gaithersburg MD 20899 USA Email: kotikalapudi.sriram@nist.gov Lepinski & Sriram Expires July 20, 2017 [Page 44] ./draft-ietf-siprec-callflows-08.txt0000664000764400076440000017646213025715453016660 0ustar iustyiusty SIPREC Ram. Ravindranath Internet-Draft Cisco Systems, Inc. Intended status: Informational Parthasarathi. Ravindran Expires: June 22, 2017 Nokia Networks Paul. Kyzivat Huawei December 19, 2016 Session Initiation Protocol (SIP) Recording Call Flows draft-ietf-siprec-callflows-08 Abstract Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client(SRC) to a Session Recording Server(SRS). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 22, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Ravindranath, et al. Expires June 22, 2017 [Page 1] Internet-Draft SIP Recording Callflows December 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Metadata XML Instances . . . . . . . . . . . . . . . . . . . 3 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . 3 3.2. Call Scenarios with SRC recording streams without mixing 5 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . 8 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 12 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . 18 3.3. Call Scenarios with SRC recording streams by mixing . . . 19 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 20 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.3. Example 3: Metadata snapshot of joining/dropping of a participant to a session . . . . . . . . . . . . . . 24 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . 27 3.4. Call scenarios with persistent RS between SRC and SRS . . 27 3.4.1. Example 1: Metadata snapshot during CS disconnect with persistent RS between SRC and SRS . . . . . . . 27 3.5. Turret-Case: Multiple CS into single RS with mixed stream 29 4. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Normative References . . . . . . . . . . . . . . . . . . 32 7.2. Informative References . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Overview Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. [RFC7865] focuses on the recording metadata which describes the Communication Session(CS). This document lists few examples and shows the snapshots of metadata sent from a Session Recording Client(SRC) to Session Recording Server Ravindranath, et al. Expires June 22, 2017 [Page 2] Internet-Draft SIP Recording Callflows December 2016 (SRS). For the sake of simplicity the entire Session Initiation Protocol (SIP) [RFC3261] messages are not shown, instead only snippets of the SIP and Session Description Protocol (SDP)[RFC4566] messages and the XML snapshot of metadata is shown. 2. Terminology The terms used in this document are defined in [RFC7865] and [RFC6341]. No new definitions are introduced in this document. 3. Metadata XML Instances The following sub-sections have examples that contain the metadata snapshot sent from SRC to SRS. 3.1. Sample Call flow The following is a sample call flow that shows the SRC establishing a Recording Session(RS) towards the SRS. The SRC in this example could be part of any one of the architectures described in section 3 of [RFC7245]. Ravindranath, et al. Expires June 22, 2017 [Page 3] Internet-Draft SIP Recording Callflows December 2016 Figure 1: Sample call flow between SRC and SRS SRC SRS | | |(1) INVITE (metadata snapshot) F1 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| |(3) ACK | |---------------------------------------------------->| |(4) RTP | |====================================================>| |====================================================>| |====================================================>| |====================================================>| |(5) UPDATE/RE-INVITE (metadata update 1) F2 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| | ................................................... | | ................................................... | | | |====================================================>| |====================================================>| |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| For the sake of simplicity, ACKs to RE-INVITES and BYEs are not shown. The subsequent sections describe the snapshot of metadata sent from SRC to SRS for each of the above transactions (F1 ... Fn- 1). There may be multiple UPDATES/RE-INVITES mid call to indicate snapshots of different CS changes. Depending on the architecture described in section 3 of [RFC7245] an SRC may be an endpoint or Back-to-Back User Agent(B2BUA) or as part of MEDIACTRL or Conference focus. The subsequent sections in this document try to list some example metadata snapshots for three major categories. o SRC recording streams unmixed to SRS. This includes cases where SRC is SIP UA or B2BUA. o SRC recording mixed streams to SRS. This includes cases where SRC is part of SIP conference model explained in [RFC4353]. o SRC having a persistent RS with SRS. Ravindranath, et al. Expires June 22, 2017 [Page 4] Internet-Draft SIP Recording Callflows December 2016 o Special flows like Turret flows (used on financial trading floors to manage call activity). A trading turret is a specialized telephony key system that has a highly distributed switching architecture enabling parallel processing of calls. Figure 6 in Section 4 of [RFC6341] has the turret use-case. Note that only those examples for which metadata changes are listed in each category. For some of the call flows the snapshots may be same (like in case of endpoint or B2BUA acting as SRC) and the same is mentioned in the text preceding the example. 3.2. Call Scenarios with SRC recording streams without mixing This section describes example flows where SRC can be a SIP-UA or B2BUA as described in section 3 of [RFC7245]. The SRS here can be a SIP-UA or an entity part of MEDIACTRL architecture described in section 3 of [RFC7245]. 3.2.1. Example 1: Basic Call Basic call between two participants Alice and Bob who are part of the same CS. In this use case each participant sends two media streams(audio and video). Media streams sent by each participant are received by the other participant in this use-case. In this example the SRC is a B2BUA in the path between Alice and Bob as described in section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by SRC in the INVITE to SRS. This snapshot has the complete metadata. For the sake of simplicity only snippets of SIP/SDP are shown. In this example the SRCs records the streams of each participant to SRS without mixing. Metadata snapshot for CS setup: INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=00000000000000000000000000000000 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, Ravindranath, et al. Expires June 22, 2017 [Page 5] Internet-Draft SIP Recording Callflows December 2016 application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session complete 2010-12-16T23:41:07Z sip:alice@atlanta.com FOO! bar ab30317f1a784dc48ff824d0d3715d86; Ravindranath, et al. Expires June 22, 2017 [Page 6] Internet-Draft SIP Recording Callflows December 2016 remote=47755a9de7794ba387653f2099600ef2 7+OTCyoxTmqmqyA/1weDAg== FOO! bar Alice FOO! bar Bob FOO! bar Ravindranath, et al. Expires June 22, 2017 [Page 7] Internet-Draft SIP Recording Callflows December 2016 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== UAAMm5GRQKSCMVvLyl4rFw== i1Pz3to5hGk8fuXl+PbwCw== 3.2.2. Example 2: Hold/resume A call between two participants Alice and Bob is established and a RS is created for recording as in example 1. One of the participants Bob puts Alice on hold and then resumes as part of the same CS. The 'send' and 'recv' XML elements of a 'participantstreamassoc' XML element is used to indicate whether a participant is contributing to a media stream or not. SRC sends a snapshot with only the changed XML elements. During hold Metadata snapshot for CS hold: RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Ravindranath, et al. Expires June 22, 2017 [Page 8] Internet-Draft SIP Recording Callflows December 2016 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial Ravindranath, et al. Expires June 22, 2017 [Page 9] Internet-Draft SIP Recording Callflows December 2016 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== In the above snippet, Alice with participant_id srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not send any media. The same is indicated by the absence of 'send' XML element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other hand would be sending media but does not receive any media from Alice and so 'recv' XML element is absent in this instance. During resume The snapshot now has 'send' and 'recv' XML elements for both Alice and Bob indicating that both are receiving and sending media. Metadata snapshot for CS resume: RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... Ravindranath, et al. Expires June 22, 2017 [Page 10] Internet-Draft SIP Recording Callflows December 2016 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== Ravindranath, et al. Expires June 22, 2017 [Page 11] Internet-Draft SIP Recording Callflows December 2016 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) Basic call between two Participants Alice and Bob is connected and SRC(B2BUA acting as SRC as per section 3.1.1 of [RFC7245]) has sent a snapshot as described in example 1. Transfer is initiated by one of the participants(Alice). After the transfer is completed, SRC sends a snapshot of the participant changes to SRS. In this transfer scenario, Alice drops out after transfer is completed and Bob and Carol gets connected and recording of media between Bob and Carol is done by SRC. There are two flows that can happen here as described below. Transfer with in the same session - (.e.g. RE-INVITE based transfer). Participant Alice drops out and Carol is added to the same session. No change to session/group element. A 'participantsessassoc' XML element indicating that Alice has disassociated from the CS will be present in the snapshot. A new 'participant' XML element representing Carol with mapping to the same RS SDP stream used for mapping earlier Alice's stream is sent in the snapshot. A new 'sipSessionID' XML element that has UUID tuples which corresponds to Bob and Carol is sent in the snapshot from SRC to SRS. Note that one half of the session ID that corresponds to Bob remains same. Metadata snapshot for INVITE based transfer in CS: RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... Ravindranath, et al. Expires June 22, 2017 [Page 12] Internet-Draft SIP Recording Callflows December 2016 m=audio 49180 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49182 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51374 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49178 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial 3363127f0d084c10876dddd4f8e5eeb9 ;remote=2272bb7e70fe41dba0025ae9a26d54cf Carol 2013-12-16T23:41:07Z 2013-12-16T23:41:07Z 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 2013-12-16T23:42:07Z Transfer with new session - (.e.g. REFER based transfer). In this case a new session (CS) is created and shall be part of same CS-group (done by SRC). SRC first sends an optional snapshot indicating disassociation of participant from the old CS. Please note this is an optional message. An SRC may choose to just send an INVITE with a new 'session' XML element to implicitly indicate that the participants are now part of a different CS without sending disassociation from the old CS. The SRC in this example uses the same RS. In case the SRC wishes to use a new RS, it will tear down the current RS using normal SIP procedures (BYE) with metadata as in example 4. Metadata snapshot for REFER based transfer in CS: RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Ravindranath, et al. Expires June 22, 2017 [Page 14] Internet-Draft SIP Recording Callflows December 2016 Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49180 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49182 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51374 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49178 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z Ravindranath, et al. Expires June 22, 2017 [Page 15] Internet-Draft SIP Recording Callflows December 2016 In the above snapshot, the 'participantsessionassoc' XML element is optional as indicating 'session' XML element with a 'stop-time' implicitly means that all the participants associated with that session have been disassociated. SRC sends another snapshot to indicate the participant change (due to REFER) and new session information after transfer. In this example it is assumed SRC uses the same RS to continue recording the call. The 'sipSessionID' XML element in metadata snapshot now indicates Bob and Carol in the (local, remote) uuid pair. Metadata snapshot for REFER based transfer in CS: RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49180 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49182 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51374 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Ravindranath, et al. Expires June 22, 2017 [Page 16] Internet-Draft SIP Recording Callflows December 2016 a=label:98 a=sendonly ... m=video 49178 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata complete 3363127f0d084c10876dddd4f8e5eeb9 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 2010-12-16T23:41:07Z 2010-12-16T23:32:03Z Ravindranath, et al. Expires June 22, 2017 [Page 17] Internet-Draft SIP Recording Callflows December 2016 2010-12-16T23:41:07Z 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 3.2.4. Example 4: Call disconnect This example shows a snapshot of metadata sent by the SRC to SRS when a CS with Alice and Bob as participants is disconnected. SRC SRS | | |(1) BYE (metadata snapshot) F1 | |---------------------------------------------------->| | 200 OK F2 | |<----------------------------------------------------| Metadata snapshot for a CS disconnect: F1 BYE SRC -----------> SRS BYE sip:2001@example.com SIP/2.0 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Ravindranath, et al. Expires June 22, 2017 [Page 18] Internet-Draft SIP Recording Callflows December 2016 Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 102 BYE Max-Forwards: 70 Require: siprec Accept: application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/rs-metadata partial 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 3.3. Call Scenarios with SRC recording streams by mixing This section describes a few example call flows where SRC may be part of conference model either as focus or a participant in conference as explained in section 3.1.5 of [RFC7245]. The SRS here can be a SIP UA or an entity part of MEDIACTRL architecture. Note that the disconnect case is not shown since the metadata snapshot will be same as for a non-mixing case. Ravindranath, et al. Expires June 22, 2017 [Page 19] Internet-Draft SIP Recording Callflows December 2016 3.3.1. Example 1: Basic call with SRC mixing streams Basic call between two participants Alice and Bob who are part of one CS. In this use case each participant calls into a conference server (say, an MCU) to attend one of many conferences hosted on or managed by that server. Media streams sent by each participant are received by all the other participants in the conference. Below is the initial snapshot sent by SRC in the INVITE to SRS that has the complete metadata. For the sake of simplicity only snippets of SIP/ SDP are shown. The SRC records the streams of each participant to SRS by mixing in this example. The SRC here is part of conference model described in section 3 of [RFC7245] as a focus and does mixing. The SRC here is not a participant by itself and hence it does not contribute to media. Metadata snapshot with SRC mixing streams to SRS: F1 INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: a358d2b81a444a8c8fb05950cef331e7 ;remote=00000000000000000000000000000000 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session Ravindranath, et al. Expires June 22, 2017 [Page 20] Internet-Draft SIP Recording Callflows December 2016 complete fa3b60f27e91441e84c55a9a0095f075 ;remote=a358d2b81a444a8c8fb05950cef331e7 ca718e1430474b5485a53aa5d0bea45e ;remote=68caf509b9284b7ea45f84a049febf0a 2010-12-16T23:41:07Z Alice Bob 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== Ravindranath, et al. Expires June 22, 2017 [Page 21] Internet-Draft SIP Recording Callflows December 2016 In the above example there are two participants Alice and Bob in the conference. Among other things, SRC sends Session-ID in the metadata snapshot. There are two Session-ID's here, one that corresponds to the SIP session between Alice and conference focus and the other for the SIP session between Bob and conference focus. In this use-case, since Alice and Bob calls into the conference these Session-ID's are different. 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams This is the continuation of Example 1: Basic call with SRC mixing streams. Given a call between two participants Alice and Bob is established and a RS is created for recording as in example 5. One of the participants, Bob puts Alice on hold and then resumes as part of the same CS. The 'send' and 'recv' XML elements of a 'participant' XML element are used to indicate whether a participant is contributing or not to a media stream. The metadata snapshot looks as below: During hold Metadata snapshot when a CS participant goes hold and SRC mixing streams: RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: a358d2b81a444a8c8fb05950cef331e7 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP Ravindranath, et al. Expires June 22, 2017 [Page 22] Internet-Draft SIP Recording Callflows December 2016 ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== During resume a snapshot shown below will be sent from SRC to SRS. Metadata snapshot when a CS participant resumes and SRC mixing streams: RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: a358d2b81a444a8c8fb05950cef331e7 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Ravindranath, et al. Expires June 22, 2017 [Page 23] Internet-Draft SIP Recording Callflows December 2016 Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== 3.3.3. Example 3: Metadata snapshot of joining/dropping of a participant to a session In a conference model, participants can join and drop a session any time during the session. Below is a snapshot sent from SRC to SRS in this case. Note the SRC here can be a focus or a participant in the conference. In the case where the SRC is a participant it may learn the information required for metadata by subscribing to conference event package [RFC4575]. Assume Alice and Bob were in the conference and a third participant Carol joins, then SRC sends the below snapshot with the indication of new participant. Ravindranath, et al. Expires June 22, 2017 [Page 24] Internet-Draft SIP Recording Callflows December 2016 Metadata snapshot for a new participant joining CS: RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: a358d2b81a444a8c8fb05950cef331e7 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial fa3b60f27e91441e84c55a9a0095f075 ;remote=a358d2b81a444a8c8fb05950cef331e7 ca718e1430474b5485a53aa5d0bea45e ;remote=68caf509b9284b7ea45f84a049febf0a 497c0f13929643b4a16858e2a3885edc ;remote=0e8a82bedda74f57be4a4a4da54167c4 Carol Ravindranath, et al. Expires June 22, 2017 [Page 25] Internet-Draft SIP Recording Callflows December 2016 2013-12-16T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== Given Alice drops after some time from the conference. SRC generates a new snapshot showing Alice disassociating from the session. Metadata snapshot for a participant dropping from CS: RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: a358d2b81a444a8c8fb05950cef331e7 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... Ravindranath, et al. Expires June 22, 2017 [Page 26] Internet-Draft SIP Recording Callflows December 2016 --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial ca718e1430474b5485a53aa5d0bea45e ;remote=68caf509b9284b7ea45f84a049febf0a 497c0f13929643b4a16858e2a3885edc ;remote=0e8a82bedda74f57be4a4a4da54167c4 2010-12-16T23:41:07Z 3.3.4. Example 4: Call disconnect When a CS is disconnected, SRC sends BYE with a snapshot of metadata having session stop time and participant dis-associate times. The snapshot looks same as listed in section 3.2.4 3.4. Call scenarios with persistent RS between SRC and SRS This section shows the snapshots of metadata for the cases where a persistent RS exists between SRC and SRS. An SRC here may be SIP UA or a B2BUA or may be part of Conference model either as focus or a participant in a conference. The SRS here could be a SIP UA or an entity part of MEDIACTRL architecture. Except in the disconnect case, the snapshot remains same as mentioned in previous sections. 3.4.1. Example 1: Metadata snapshot during CS disconnect with persistent RS between SRC and SRS Ravindranath, et al. Expires June 22, 2017 [Page 27] Internet-Draft SIP Recording Callflows December 2016 Metadata snapshot for a CS disconnect with a persistent RS: RE-INVITE sent from SRC -----------> SRS INVITE sip:2001@example.com SIP/2.0 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/rs-metadata partial 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z Ravindranath, et al. Expires June 22, 2017 [Page 28] Internet-Draft SIP Recording Callflows December 2016 3.5. Turret-Case: Multiple CS into single RS with mixed stream In trading floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (each call is one CS) on different handsets/ speakers on the same turret into a single RS. This would means media in each CS is mixed and recorded as part of single media stream and multiple such CSs are recording in one RSfrom a SRC to SRS. Taking an example where there are two CS [CS1 and CS2]. Assume mixing is done in each of these CS and both these CS are recorded as part of single RS from a single SRC which is part of both the CS. There are three possibilities here: o CS1 and CS2 uses the same focus for mixing and that focus is also acting as SRC in each of the CS. o One of the CS (e.g. CS1), SRC is Focus and the other CS (e.g. CS2), SRC is just one of the participant of the conference. o In both CS1 and CS2, SRC is just a participant of conference. The following example shows the first possibility where CS1 and CS2 uses the same focus for mixing and that focus is also acting as SRC in each of the CS. Metadata snapshot with two CS recorded as part of same RS: INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: a358d2b81a444a8c8fb05950cef331e7 ;remote=00000000000000000000000000000000 Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... complete Ravindranath, et al. Expires June 22, 2017 [Page 29] Internet-Draft SIP Recording Callflows December 2016 2010-12-16T23:41:07Z fa3b60f27e91441e84c55a9a0095f075 ;remote=a358d2b81a444a8c8fb05950cef331e7 ca718e1430474b5485a53aa5d0bea45e ;remote=a358d2b81a444a8c8fb05950cef331e7 497c0f13929643b4a16858e2a3885edc ;remote=a358d2b81a444a8c8fb05950cef331e7 7+OTCyoxTmqmqyA/1weDAg== 2010-12-16T23:41:07Z ae10731ca50343a5aaae2dd0904a65de ;remote=a358d2b81a444a8c8fb05950cef331e7 33c77aac7deb414cbc8c10f363fccb71 ;remote=a358d2b81a444a8c8fb05950cef331e7 fd6932e9e5fc489fae2d5b3779723b7e ;remote=a358d2b81a444a8c8fb05950cef331e7 7+OTCyoxTmqmqyA/1weDAg== 2010-12-16T23:43:07Z Alice Bob Carol Ravindranath, et al. Expires June 22, 2017 [Page 30] Internet-Draft SIP Recording Callflows December 2016 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:43:07Z 2010-12-16T23:43:07Z UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== 4. Security Considerations Security and privacy considerations mentioned in [RFC7865] and [RFC7866] has to be followed by SRC and SRS for setting up RS SIP dialog and sending metadata. 5. IANA Considerations This document has no IANA considerations Ravindranath, et al. Expires June 22, 2017 [Page 31] Internet-Draft SIP Recording Callflows December 2016 6. Acknowledgement Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev and Charles Armitage for their review comments. Thanks to Alissa Cooper, Stephen Farrell, Kathleen Moriarty, Suresh Krishnan, Benoit Claise, Carlos Pignataro, Dan Romascanu and Derek Atkins for their feedback and comments during IESG reviews. 7. References 7.1. Normative References [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, . [RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", RFC 7865, DOI 10.17487/RFC7865, May 2016, . [RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", RFC 7866, DOI 10.17487/RFC7866, May 2016, . [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, "An Architecture for Media Recording Using the Session Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 2014, . 7.2. Informative References [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . Ravindranath, et al. Expires June 22, 2017 [Page 32] Internet-Draft SIP Recording Callflows December 2016 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . Authors' Addresses Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: rmohanr@cisco.com Parthasarathi Ravindran Nokia Networks Bangalore, Karnataka India Email: partha@parthasarathi.co.in Paul Kyzivat Huawei Hudson, MA USA Email: pkyzivat@alum.mit.edu Ravindranath, et al. Expires June 22, 2017 [Page 33] ./draft-ietf-straw-b2bua-rtcp-17.txt0000664000764400076440000013416113026775645016506 0ustar iustyiusty STRAW Working Group L. Miniero Internet-Draft Meetecho Intended status: Standards Track S. Garcia Murillo Expires: June 25, 2017 Medooze V. Pascual Oracle December 22, 2016 Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) draft-ietf-straw-b2bua-rtcp-17 Abstract SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 25, 2017. Miniero, et al. Expires June 25, 2017 [Page 1] Internet-Draft RTCP translation in B2BUAs December 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 4 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Session Initiation Protocol [RFC3261] Back-to-Back User Agents (B2BUAs) are SIP entities that can act as a logical combination of both a User Agent Server (UAS) and a User Agent Client (UAC). As such, their behaviour is not always completely adherent to the standards, and can lead to unexpected situations. [RFC7092] presents a taxonomy of the most commonly deployed B2BUA implementations, describing how they differ in terms of the functionality and features they provide. Such components often do not only act on the signalling plane, that is intercepting and possibly modifying SIP messages, but also on the media plane. This means that, in order to receive and manage all RTP and RTCP [RFC3550] packets in a session, these components also Miniero, et al. Expires June 25, 2017 [Page 2] Internet-Draft RTCP translation in B2BUAs December 2016 manipulate the session descriptions [RFC4566] in the related offer/ answer exchanges [RFC3264]. The reasons for such a behaviour can be different. The B2BUA may want, for instance, to provide transcoding functionality for participants with incompatible codecs, or it may need the traffic to be directly handled for different reasons. This can lead to several different topologies for RTP-based communication, as documented in [RFC7667]. Whatever the reason, such a behaviour does not come without a cost. In fact, whenever a media-aware component is placed on the path between two or more participants that want to communicate by means of RTP/RTCP, the end-to-end nature of such protocols is broken. While this may not be a problem for RTP packets, which can be quite easily relayed, it definitely can cause serious issue for RTCP messages, which carry important information and feedback on the communication quality the participants are experiencing. Consider, for instance, the simple scenario only involving two participants and a single RTP session depicted in Figure 1: +--------+ +---------+ +---------+ | |=== SSRC1 ===>| |=== SSRC3 ===>| | | Alice | | B2BUA | | Bob | | |<=== SSRC2 ===| |<=== SSRC4 ===| | +--------+ +---------+ +---------+ Figure 1: B2BUA modifying RTP headers In this common scenario, a participant (Alice) is communicating with another participant (Bob) as a result of a signalling session managed by a B2BUA: this B2BUA is also on the media path between the two, and is acting as a media relay. This means that two separate RTP sessions are involved (one per side), each carrying two RTP streams (one per media direction). As part of this process, though, the B2BUA is also rewriting some of the RTP header information on the way. In this example, just the SSRC of the incoming RTP streams is changed, but more information may be modified as well (e.g., sequence numbers, timestamps, etc.). In particular, whenever Alice sends an RTP packet, she sets her SSRC (SSRC1) in the RTP header of her RTP source stream. The B2BUA rewrites the SSRC (SSRC3) before relaying the packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) get their SSRC rewritten as well (SSRC2) before being relayed to Alice. Assuming now that Alice needs to inform Bob she has lost several packets in the last few seconds, she will place the related received RTP stream SSRC she is aware of (SSRC2), together with her own Miniero, et al. Expires June 25, 2017 [Page 3] Internet-Draft RTCP translation in B2BUAs December 2016 (SSRC1), in RTCP Reports and/or NACKs. Since the B2BUA is making use of different SSRCs for the RTP streams in the RTP session it established with each participant, blindly relaying Alice's incoming RTCP messages to Bob would cause issues. These RTCP messages would reference SSRCs Bob doesn't know about, which would result in precious feedback being dropped. In fact, Bob is only aware of SSRCs SSRC4 (the one his source RTP stream uses) and SSRC3 (the one he's receiving from the B2BUA in the received RTP stream), and knows nothing about SSRCs SSRC1 and SSRC2 in the messages he received instead. Considering the feedback being dropped because of this may contain precious information, e.g., related to packet loss, congestion, and other network issues or considerations, the inability to take them into account may lead to severe issues. For instance, Bob may flood Alice with more media packets she can handle, and/or not retransmit Alice the packets she missed and asked for. This may easily lead to a very bad communication experience, if not eventually to an unwanted termination of the communication itself. This is just a trivial example that, together with additional scenarios, will be addressed in the following sections. Nevertheless, it is a valid example of how such a simple mishandling of precious information may lead to serious consequences. This is especially true if we picture more complex scenarios involving several participants at the same time, multiple RTP sessions (e.g., a video stream along audio) rather than a single one, redundancy RTP streams, SSRC multiplexing and so on. Considering how common B2BUA deployments are, it is very important for them to properly address RTCP messages, in order to be sure that their activities on the media plane do not break or interfere with anything relevant to the session. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Besides, this document addresses, where relevant, the RTP-related terminology as disciplined in [RFC7656]. 3. Signalling/Media Plane B2BUAs As described in the introductory section, it's very common for B2BUA deployments to also act on the media plane, rather than just signalling alone. In particular, [RFC7092] describes three different categories of such B2BUAs: a B2BUA, in fact, may act as a simple media relay (1), effectively unaware of anything that is transported; it may be a media-aware relay (2), also inspecting and/or modifying Miniero, et al. Expires June 25, 2017 [Page 4] Internet-Draft RTCP translation in B2BUAs December 2016 RTP and RTCP messages as they flow by; or it may be a full-fledged media termination entity (3), terminating and generating RTP and RTCP messages as needed. [RFC3550] and [RFC7667] already mandate some specific behaviours in the presence of certain topologies. Anyway, due to their mixed nature B2BUAs sometimes can't or won't implement all relevant specifications. This means that it's not rare to encounter issues that may be avoided with a more disciplined behaviour in that regard, that is if the B2BUAs followed at least a set of guidelines to ensure no known problems occur. For this reason, the following subsections will describe the proper behaviour B2BUAs, whatever above category they fall in, should follow in order not to impact any end-to-end RTCP effectiveness. 3.1. Media Relay A media relay, as identified in [RFC7092], simply forwards all RTP and RTCP messages it receives, without either inspecting or modifying them. Using the RTP Topologies terminology, this can be seen as a RTP Transport Translator. As such, B2BUA acting as media relays are not aware of what traffic they're handling. This means that both packet payloads and packet headers are opaque to them. Many Session Border Controllers (SBC) implement this kind of behaviour, e.g., when acting as a bridge between an inner and outer network. Considering all headers and identifiers in both RTP and RTCP are left untouched, issues like the SSRC mismatch described in the previous section would not occur. Similar problems could still happen, though, for different reasons, as for instance if the session description prepared by the B2BUA, whether it has been modified or not, ends up providing incorrect information. This may happen, for example, if the SDP on either side contains 'ssrc' [RFC5576] attributes that don't match the actual SSRC being advertized on the media plane, or when the B2BUA advertized support for NACK because it implements it, while the original INVITE didn't. Such issues might occur, for instance, when the B2BUA acting as a media relay is generating a new session description when bridging an incoming call, rather than using the original session description. This may cause participants to find a mismatch between the SSRCs advertized in the SDP and the ones actually observed in RTP and RTCP messages, or to have them either ignore or generate RTCP feedback packets that were not explicitly advertized as supported. In order to prevent such an issue, a media-relay B2BUA SHOULD forward all the SSRC- and RTCP-related SDP attributes when handling a multimedia session setup between participants: this includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr- Miniero, et al. Expires June 25, 2017 [Page 5] Internet-Draft RTCP translation in B2BUAs December 2016 attrib' [RFC3611] and others. However, certain SDP attributes may lead to call failures when forwarded by a media relay, as they have an implied assumption that the attribute describes the immediate peer. A clear example of this is the 'rtcp' [RFC3605] attribute, which describes the expected RTCP peer port. Other attributes might include the immediate peer's IP address, preferred transport, etc. In general, the guideline is to require rewriting of attributes that are implicitly describing the immediate peer. B2BUAs SHOULD forward all other SDP attributes in order to avoid breaking additional functionality endpoints may be relying on. If implementors have doubts about whether this guidance applies to a specific attribute, they should test to determine if call failures occur. The cited 'rtcp' example is also relevant whenever RTP/RTCP multiplexing [RFC5761] support is being negotiated. If the B2BUA acting as a Media Relay is unaware of the specifics of the traffic it is handling, and as such may not have RTP/RTCP parsing capabilities, it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP attribute. If instead the Media Relay is able to parse RTP/RTCP, and can verify that demultiplexing can be performed without any RTP Payload Type rewrites (i.e., no overlap between any RTP Payload Types and the RTCP Payload Type space has been detected), then the B2BUA SHOULD negotiate RTP/RTCP multiplexing support if advertized. It is worth mentioning that, leaving RTCP messages untouched, a media relay may also leak information that, according to policies, may need to be hidden or masqueraded, e.g., domain names in CNAME items. Besides, these CNAME items may actually contain IP addresses: this means that, should a NAT be involved in the communication, this may actually result in CNAME collisions, which could indeed break the end-to-end RTCP behaviour. While [RFC7022] can prevent this from happening, there may be implementations that don't make use of it. As such, a B2BUA MAY rewrite CNAME items if any potential collision is detected, even in the Media Relay case. If a B2BUA does indeed decide to rewrite CNAME items, though, then it MUST generate new CNAMEs following [RFC7022]. The same SHOULD be done in case RTP extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp- hdrext:sdes:cname", [RFC7941]). If that is not possible, e.g., because the Media Relay does not have RTP header editing capabilities or does not support these extensions, then the B2BUA MUST reject the negotiation of such extensions when negotiating the session. 3.2. Media-aware Relay A Media-aware relay, unlike the the Media Relay addressed in the previous section, is aware of the media traffic it is handling. This means it inspects RTP and RTCP messages flowing by, and may even modify their headers. Using the RFC3550 terminology, this can be Miniero, et al. Expires June 25, 2017 [Page 6] Internet-Draft RTCP translation in B2BUAs December 2016 seen as a RTP Translator. A B2BUA implementing this role, though, typically does not inspect the RTP payloads, which would be opaque to them: this means that the actual media would not be manipulated (e.g, transcoded). This makes them quite different from the Media Relay previously discussed, especially in terms of the potential issues that may occur at the RTCP level. In fact, being able to modify the RTP and RTCP headers, such B2BUAs may end up modifying RTP related information like SSRC/CSRC, sequence numbers, timestamps and others in an RTP stream, before forwarding the modified packets to the other interested participants. This means that, if not properly disciplined, such a behaviour may easily lead to issues like the one described in the introductory section. For this reason, it is very important for a B2BUA modifying RTP-related information across two related RTP streams to also modify, in a coherent way, the same information in RTCP messages. It is worthwile to point out that such a B2BUA may not necessarily forward all the packets it receives, though. Selective Forwarding Units (SFU) [RFC7667], for instance, may be implemented to aggregate or drop incoming RTCP messages, while at the same time originating new ones on their own. It is important to clarify that a B2BUA SHOULD NOT randomly drop or forward RTCP feedback of the same type (e.g., a specific XR block type, or specific Feedback messages) within the context of the same session, as that may lead to confusing, if not broken, feedback to the recipients of the message due to gaps in the communication. As to the messages that are forwarded and/or aggregated, though, it's important to make sure the information is coherent. Besides the behaviour already mandated for RTCP translators in Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming RTCP messages to forward following this guideline: SR: [RFC3550] If the B2BUA has changed the SSRC of the sender RTP stream a Sender Report refers to, it MUST update the SSRC in the SR packet header as well. If the B2BUA has changed the SSRCs of other RTP streams too, and any of these streams are addressed in any of the SR report blocks, it MUST update the related values in the SR report blocks as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the 'extended highest sequence number received' field in the Report Blocks. In case the B2BUA is acting as a Selective Forwarding Units (SFU) [RFC7667], it needs to track in the outgoing SR the relevant number of packets sent and total amount of bytes sent to the receiver. Miniero, et al. Expires June 25, 2017 [Page 7] Internet-Draft RTCP translation in B2BUAs December 2016 RR: [RFC3550] The same guidelines given for SR apply for RR as well. SDES: [RFC3550] If the B2BUA has changed the SSRC of any RTP stream addressed in any of the chunks of an incoming SDES message, it MUST update the related SSRCs in all the chunks. The same considerations made with respect to CNAME collisions at the end of Section 3.1 apply here as well. BYE: [RFC3550] If the B2BUA has changed the SSRC of any RTP stream addressed in the SSRC/CSRC identifiers included in a BYE packet, it MUST update them in the message. APP: [RFC3550] If the B2BUA has changed the SSRC of any RTP stream addressed in the header of an APP packet, it MUST update the identifier in the message. Should the B2BUA be aware of any specific APP message format that contains additional information related to SSRCs, it SHOULD update them as well accordingly. Extended Reports (XR): [RFC3611] If the B2BUA has changed the SSRC of the RTP stream associated with the originator of an XR packet, it MUST update the SSRC in the XR message header. The same guidelines given for SR/RR, with respect to SSRC identifiers in report blocks, apply for all the Report Block types in the XR message as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the 'begin_seq' and 'end_seq' fields that are available in most of the Report Block types that are part of the XR specification. Receiver Summary Information (RSI): [RFC5760] If the B2BUA has changed any SSRC of RTP streams addressed in a RSI packet, it MUST update the SSRC identifiers in the message. This includes the distribution source SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, the summarized SSRC and, when a Collision Sub- Report Block is available, the SSRCs in the related list. Port Mapping (TOKEN): [RFC6284] If the B2BUA has changed any SSRC of RTP streams addressed in a TOKEN packet, it MUST update the SSRC identifiers in the message. This includes the Packet Sender SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, and the Requesting Client SSRC when the message is a Miniero, et al. Expires June 25, 2017 [Page 8] Internet-Draft RTCP translation in B2BUAs December 2016 response, which MUST be rewritten using the related sender participant(s) SSRC. Feedback messages: [RFC4585] All Feedback messages have a common packet format, which includes the SSRC identifier of the packet sender and the SSRC identifier of the media source the feedack is related to. Just as described for the previous messages, these SSRC identifiers MUST be updated in the message if the B2BUA has changed the SSRC of the RTP streams addressed there. It MUST NOT, though, change a media source SSRC that was originally set to zero, unless zero is actually the SSRC that was chosen by one of the involved endpoints, in which case the above mentioned rules as to SSRC rewriting apply. Considering that many feedback messages also include additional data as part of their specific Feedback Control Information (FCI), a media-aware B2BUA MUST take care of them accordingly, if it can parse and regenerate them, according to the following guidelines: NACK: [RFC4585] A media-aware B2BUA MUST properly rewrite the Packet ID (PID) of all addressed lost packets in the NACK FCI if it changed the RTP sequence numbers. TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] A media-aware B2BUA MUST properly rewrite the additional SSRC identifier in the specific FCI, if it changed the related RTP SSRC of the media sender. REMB: [I-D.alvestrand-rmcat-remb] This draft describes an RTCP Payload-Specific feedback message that reports the receiver's available bandwidth to the the sender. As of the time of this writing, REMB has been widely deployed, but has not been standardized. The REMB mechanism will not function correctly across a media-aware B2BUA that changes the SSRC of the media sender unless it also changes the SSRC values in the REMB packet. Explicit Congestion Notification (ECN): [RFC6679] The same guidelines given for SR/RR management apply, considering the presence of sequence numbers in the ECN Feedback Report format. For what concerns the management of RTCP XR ECN Summary Report messages, the same guidelines given for generic XR messages apply. Apart from the generic guidelines related to Feedback messages, no additional modifications are needed for PLI, SLI and RPSI feedback messages. Miniero, et al. Expires June 25, 2017 [Page 9] Internet-Draft RTCP translation in B2BUAs December 2016 Of course, the same considerations about the need for SDP and RTP/ RTCP information to be coherent applies to media-aware B2BUAs. This means that, if a B2BUA changes any SSRC, it MUST update the related 'ssrc' attributes, if present, before sending it to the recipient. Besides, it MUST rewrite the 'rtcp' attribute if provided. At the same time, while a media-aware B2BUA is typically able to inspect/ modify RTCP messages, it may not support all RTCP messages. This means that a B2BUA may choose to drop RTCP messages it can't parse. In that case, a media-aware B2BUA MUST advertize its RTCP level of support in the SDP in a coherent way, in order to prevent, for instance, a UAC to from sending NACK messages that would never reach the intended recipients. It's important to point out that, in case a compound RTCP packet was received and any RTCP message in it needs to be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP packet, but only the selected messages. The same considerations on CNAMEs made when talking of Media Relays apply for Media-aware Relays as well. Specifically, if RTP extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp- hdrext:sdes:cname", [RFC7941]) and negotiated because the B2BUA supports them, then the B2BUA MUST update the CNAME value in there as well, if it was changed. It is worth pointing out that, if the new CNAME is larger than the old one, this would result in a larger RTP packet than originally received. If the length of the updated packet exceeds the MTU of any of the networks the packet will traverse, this can result in the packet being dropped and lost by the recipient. A different set of considerations is worthwhile for what concerns RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506]. While the former allows for a better management of network resources by multiplexing RTP packets and RTCP messages over the same transport, the latter allows for a compression of RTCP messages, thus leading to less network traffic. For what concerns RTP/RTCP multiplexing, a B2BUA acting as a Media Relay may use it on either RTP session independently. This means that, for instance, a Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the communication, and not use it on the other side, if the endpoint does not support it. This allows for a better management of network resources on the side that does support it. In case any of the parties in the communications supports it and the B2BUA does too, the related 'rtcp-mux' SDP attribute MUST be forwarded on the other side(s). If the B2BUA detects that any of the parties in the communication do not support the feature, it may decide to either disable it entirely or still advertize it for the RTP sessions with parties that do support it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it MUST ensure that there are no conflicting RTP payload type numbers on either side. When there are, it MUST rewrite RTP payload type numbers to prevent conflicts in the session Miniero, et al. Expires June 25, 2017 [Page 10] Internet-Draft RTCP translation in B2BUAs December 2016 where the RTP/RTCP multiplexing is applied. Should RTP payload types be rewritten, the related information in the SDP MUST be updated accordingly. For what concerns Reduced-Size RTCP, instead, the considerations are a bit different. In fact, while a Media Relay B2BUA may choose to use it on the side that supports it and not on the side that doesn't, there are several reasons for discouraging such a behaviour. While Reduced-Size allows indeed for less network traffic related to RTCP messaging in general, this gain may lead a Reduced-Size RTCP implementation to also issue a higher rate of RTCP feedback messages. This would result in an increased RTCP traffic on the side that does not support Reduced-Size, and could as a consequence be actually counterproductive if the available bandwidth is different on the two sides. Negotiating a session with both sides would allow the B2BUA to discover which one supports Reduced-Size and which doesn't, and in case decide whether to allow the sides to independently use Reduced- Size or not. Should the B2BUA decide to disable the feature on all sides, which is suggested in case Reduced-Size is not supported by all parties involved, it MUST NOT advertize support for the Reduced- Size RTCP functionality on either side, by removing the 'rtcp-rsize' attribute from the SDP. 3.3. Media Terminator A Media Terminator B2BUA, unlike simple relays and media-aware ones, is also able to terminate media itself. As such, it can inspect and/ or modify RTP payloads as well. This means that such components, for instance, can act as media transcoders and/or originate specific RTP media. Using the RTP Topologies terminology, this can be seen as a RTP Media Translator. Such a topology can also be seen as a Back-to- back RTP sessions through a Middlebox, as described in Section 3.2.2 of [RFC7667]. Such a capability makes them quite different from the previously introduced B2BUA typologies. Since such a B2BUA would terminate RTP itself, it can take care of the related statistics and feedback functionality directly, with no need to simply relay any message between the participants in the multimedia session. For this reason, no specific guideline is needed to ensure a proper end-to-end RTCP behaviour in such scenarios, mostly because most of the times there would be no end-to-end RTCP interaction among the involved participants in the first place. Nevertheless, should any RTCP message actually need to be forwarded to another participant in the multimedia session, the same guidelines provided for the media- aware B2BUA case apply. For what concerns RTP/RTCP multiplexing support, the same considerations already given for the Media Relay management also Miniero, et al. Expires June 25, 2017 [Page 11] Internet-Draft RTCP translation in B2BUAs December 2016 apply for a Media Terminator. Some different considerations might be given as to the Reduced-Size RTCP functionality, instead. In fact, in the Media Terminator case it is safe to use the feature independently on each side, as the B2BUA would terminate RTCP. In that case, the B2BUA SHOULD advertize and negotiate support for Reduced-Size if available, and MUST NOT otherwise. 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations The discussion made in the previous sections on the management of RTCP messages by a B2BUA worked under the assumption that the B2BUA has actually access to the RTP/RTCP information itself. This is indeed true if we assume that plain RTP and RTCP is being handled, but may not be once any security is enforced on RTP packets and RTCP messages by means of SRTP [RFC3711]. While typically not an issue in the Media Relay case, where RTP and RTCP packets are forwarded without any modification no matter whether security is involved or not, this could definitely have an impact on Media-aware Relays and Media Terminator B2BUAs. To make a simple example, if we envisage a SRTP/SRTCP session across a B2BUA, where the B2BUA itself has no access to the keys used to secure the session, there would be no way to manipulate SRTP headers without violating the hashing on the packet. At the same time, there would be no way to rewrite the RTCP information accordingly either. For this reason, it is important to point out that the operations described in the previous sections are only possible if the B2BUA has a way to effectively manipulate the packets and messages flowing by. This means that, when media security is involved, only the Media- unaware Relay scenario can be properly addressed. Attempting to cover Media-aware Relay and Media Termination scenarios when involving secure sessions will inevitably lead to the B2BUA acting as a man-in-the-middle, and consequently its behaviour is unspecified and discouraged. More considerations on this are provided in [RFC7879]. It is also worth pointing out that there are scenarios where an improper management of RTCP messaging across a B2BUA may lead, willingly or not, to situations not unlike an attack. To make a simple example, an improper management of a REMB feedback message containing, e.g., information on the limited bandwidth availability for a user, may lead to missing or misleading information to its peer. This may cause the peer to increase the encoder bitrate, maybe Miniero, et al. Expires June 25, 2017 [Page 12] Internet-Draft RTCP translation in B2BUAs December 2016 up to a point where a user with poor connectivity will inevitably be choked by an amount of data it cannot process. This scenario may thus result in what looks like a Denial of Service (DOS) attack towards the user. 6. IANA Considerations This document has no IANA actions. 7. Change Summary Note to RFC Editor: Please remove this whole section. The following are the major changes between the 16 and the 17 versions of the draft: o Clarified the meaning of a sentence. The following are the major changes between the 14 and the 15 versions of the draft: o Several changes addressing the IESG review (list follows). o Addressed 'rtcp-mux' in 3.1 as well, and not only 3.2. o Clarified that, if CNAMEs are rewritten, RTP extensions referencing them (e.g., [RFC7941]) should be updated too. Clarified that MTU issues can occur if the rewriting results in a larger RTP packet. o Clarified that when handling SR packets, the an SFU B2BUA must track packets/bytes sent. o Removed references to billing, lawful interception, etc. from the intro. o Moved some references (especially those affected by MUSTs in 3.2) to Normative. o Rewritten the "Such attributes SHOULD NOT be forwarded" section to clarify the context of the attributes that may lead to a failure if not taken care of. o Clarified that randomly dropping RTCP packets can lead to confusion on the recipient. o Updated text related to REMB. Miniero, et al. Expires June 25, 2017 [Page 13] Internet-Draft RTCP translation in B2BUAs December 2016 o Smaller fixes here and there. The following are the major changes between the 13 and the 14 versions of the draft: o Removed first paragraph of Security Considerations which was unclear. o Added an IANA Considerations section to clarify there are no actions. The following are the major changes between the 12 and the 13 versions of the draft: o Updated authors' affiliations and mail addresses. The following are the major changes between the 11 and the 12 versions of the draft: o Addressed remaining points in Ben's second review. o Updated reference of STRAW's DTLS-SRTP draft to new [RFC7879]. The following are the major changes between the 10 and the 11 versions of the draft: o Addressed Ben's second review. The following are the major changes between the 09 and the 10 versions of the draft: o Replaced references to obsoleted RFC 5117 with [RFC7667]. o Made reference to [RFC7656] normative. o Clarified text across the whole document to address Ben's review. The following are the major changes between the 08 and the 09 versions of the draft: o Updated references to documents which have become RFC in the meanwhile, [RFC7667] and [RFC7656]. The following are the major changes between the 06 and the 07 versions of the draft: o Clarified the suggested changed by Colin Perkins on the management of CNAME items in SDES, and added reference to [RFC7022]. Miniero, et al. Expires June 25, 2017 [Page 14] Internet-Draft RTCP translation in B2BUAs December 2016 o Addressed comment by Simon Perreault on CNAME collisions management. The following are the major changes between the 05 and the 06 versions of the draft: o Addressed comment by Colin Perkins on the management of CNAME items in SDES. The following are the major changes between the 04 and the 05 versions of the draft: o Clarified behaviour when SSRC is zero. o Fixed a couple of nits found by the Idnits tool. The following are the major changes between the 03 and the 04 versions of the draft: o Addressed review by Magnus Westerlund. o Added guidelines for ECN RTCP messages. o Clarified that if an RTCP message is dropped because unsupported, only the unsupported packet is dropped and not the compound packet that contains it. o Added reference to Section 3.2.2 of [RFC7667] to Section 3.3. o Added considerations on RTP/RTCP multiplexing and Reduced-Size RTCP. The following are the major changes between the 02 and the 03 versions of the draft: o Rephrased the Media Path Security section to take into account the MITM-related discussion in Honolulu. o Added some Security Considerations. The following are the major changes between the 01 and the 02 versions of the draft: o Updated terminology to better adhere to [RFC7656]. o Rephrased the Media Path Security section to take into account the MITM-related discussion in Toronto. Miniero, et al. Expires June 25, 2017 [Page 15] Internet-Draft RTCP translation in B2BUAs December 2016 o Clarified that NACK management might be trickier when SRTP is involved. The following are the major changes between the 00 and the 01 versions of the draft: o Updated references and mapping per taxonomy RFC (7092). o Added a reference to RTP topologies, and tried a mapping as per- discussion in London. o Added more RTCP message types to the Media-Aware section. o Clarified that fixing the 'rtcp' SDP attribute is important. o Added a new section on the impact of media security. 8. Acknowledgements The authors would like to thank Flavio Battimo and Pierluigi Palma for their invaluable feedback in the early stages of the document. The authors would also like to thank Colin Perkins, Bernard Aboba, Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, Stephen Farrell, Magnus Westerlund, Simon Perreault and Ben Campbell for their constructive comments, suggestions, and reviews that were critical to the formulation and refinement of this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . Miniero, et al. Expires June 25, 2017 [Page 16] Internet-Draft RTCP translation in B2BUAs December 2016 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, February 2010, . [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, June 2011, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . Miniero, et al. Expires June 25, 2017 [Page 17] Internet-Draft RTCP translation in B2BUAs December 2016 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, . 9.2. Informative References [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . [I-D.alvestrand-rmcat-remb] Alvestrand, H., "RTCP message for Receiver Estimated Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in progress), October 2013. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . Miniero, et al. Expires June 25, 2017 [Page 18] Internet-Draft RTCP translation in B2BUAs December 2016 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, . Authors' Addresses Lorenzo Miniero Meetecho Email: lorenzo@meetecho.com Sergio Garcia Murillo Medooze Email: sergio.garcia.murillo@gmail.com Victor Pascual Oracle Email: victor.pascual.avila@oracle.com Miniero, et al. Expires June 25, 2017 [Page 19] ./draft-ietf-taps-transports-14.txt0000664000764400076440000037017513021553032016552 0ustar iustyiusty Network Working Group G. Fairhurst, Ed. Internet-Draft University of Aberdeen Intended status: Informational B. Trammell, Ed. Expires: June 9, 2017 M. Kuehlewind, Ed. ETH Zurich December 06, 2016 Services provided by IETF transport protocols and congestion control mechanisms draft-ietf-taps-transports-14 Abstract This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/ Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 9, 2017. Fairhurst, et al. Expires June 9, 2017 [Page 1] Internet-Draft TAPS Transports December 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of Transport Features . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 6 3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 6 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 3.1.2. Interface description . . . . . . . . . . . . . . . . 8 3.1.3. Transport Features . . . . . . . . . . . . . . . . . 8 3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 9 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 3.2.2. Interface Description . . . . . . . . . . . . . . . . 10 3.2.3. Transport features . . . . . . . . . . . . . . . . . 10 3.3. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 11 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 3.3.2. Interface Description . . . . . . . . . . . . . . . . 12 3.3.3. Transport Features . . . . . . . . . . . . . . . . . 12 3.4. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 13 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 13 3.4.2. Interface Description . . . . . . . . . . . . . . . . 13 3.4.3. Transport Features . . . . . . . . . . . . . . . . . 14 3.5. Stream Control Transmission Protocol (SCTP) . . . . . . . 14 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 14 3.5.2. Interface Description . . . . . . . . . . . . . . . . 16 3.5.3. Transport Features . . . . . . . . . . . . . . . . . 19 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 20 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 20 3.6.2. Interface Description . . . . . . . . . . . . . . . . 21 3.6.3. Transport Features . . . . . . . . . . . . . . . . . 22 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a pseudotransport . . . . . . . . . . . . . . . . . . . . 22 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 23 Fairhurst, et al. Expires June 9, 2017 [Page 2] Internet-Draft TAPS Transports December 2016 3.7.2. Interface Description . . . . . . . . . . . . . . . . 24 3.7.3. Transport Features . . . . . . . . . . . . . . . . . 24 3.8. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 25 3.8.1. Protocol Description . . . . . . . . . . . . . . . . 25 3.8.2. Interface Description . . . . . . . . . . . . . . . . 26 3.8.3. Transport Features . . . . . . . . . . . . . . . . . 27 3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport . . . . . . . . . . . . . . . . . . . . . 27 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 28 3.9.2. Interface Description . . . . . . . . . . . . . . . . 29 3.9.3. Transport features . . . . . . . . . . . . . . . . . 29 3.10. File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 30 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 31 3.10.2. Interface Description . . . . . . . . . . . . . . . 32 3.10.3. Transport Features . . . . . . . . . . . . . . . . . 32 3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 33 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 33 3.11.2. Interface Description . . . . . . . . . . . . . . . 35 3.11.3. Transport Features . . . . . . . . . . . . . . . . . 35 3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 35 3.12.1. Protocol Description . . . . . . . . . . . . . . . . 36 3.12.2. Interface Description . . . . . . . . . . . . . . . 37 3.12.3. Transport Features . . . . . . . . . . . . . . . . . 37 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 37 5. Transport Features . . . . . . . . . . . . . . . . . . . . . 38 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 10. Informative References . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction Internet applications make use of the Services provided by a Transport protocol, such as TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean the end-to-end service provided to an application by the transport layer. That service can only be provided correctly if information about the intended usage is supplied from the application. The application may determine this information at design time, compile time, or run time, and may include guidance on whether a feature is required, a preference by the application, or something in between. Examples of features of Transport Services are reliable delivery, ordered delivery, content privacy to in-path devices, and integrity protection. Fairhurst, et al. Expires June 9, 2017 [Page 3] Internet-Draft TAPS Transports December 2016 The IETF has defined a wide variety of transport protocols beyond TCP and UDP, including SCTP, DCCP, MPTCP, and UDP-Lite. Transport services may be provided directly by these transport protocols, or layered on top of them using protocols such as WebSockets (which runs over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run over SCTP over DTLS over UDP or TCP). Services built on top of UDP or UDP-Lite typically also need to specify additional mechanisms, including a congestion control mechanism (such as NewReno [RFC6582], TFRC [RFC5348] or LEDBAT [RFC6817]). This extends the set of available Transport Services beyond those provided to applications by TCP and UDP. The transport protocols described in this document provide a basis for the definition of transport services provided by common protocols, as background for the TAPS working group. The protocols listed here were chosen to help expose as many potential transport services as possible, and are not meant to be a comprehensive survey or classification of all transport protocols. 1.1. Overview of Transport Features Transport protocols can be differentiated by the features of the services they provide. Some of these provided features are closely related to basic control function that a protocol needs to work over a network path, such as addressing. The number of participants in a given association also determines its applicability: if a connection is between endpoints (unicast), to one of multiple endpoints (anycast), or simultaneously to multiple endpoints (multicast). Unicast protocols usually support bidirectional communication, while multicast is generally unidirectional. Another feature is whether a transport requires a control exchange across the network at setup (e.g., TCP), or whether it is connection-less (e.g., UDP). For packet delivery itself, reliability and integrity protection, ordering, and framing are basic features. However, these features are implemented with different levels of assurance in different protocols. As an example, a transport service may provide full reliability, providing detection of loss and retransmission (e.g., TCP). SCTP offers a message-based service that can provide full or partial reliability, and allows the protocol to minimize the head of line blocking due to the support of ordered and unordered message delivery within multiple streams. UDP-Lite and DCCP can provide partial integrity protection to enable corruption tolerance. Usually a protocol has been designed to support one specific type of delivery/framing: data either needs to be divided into transmission Fairhurst, et al. Expires June 9, 2017 [Page 4] Internet-Draft TAPS Transports December 2016 units based on network packets (datagram service), a data stream is segmented and re-combined across multiple packets (stream service), or whole objects such as files are handled accordingly. This decision strongly influences the interface that is provided to the upper layer. In addition, transport protocols offer a certain support for transmission control. For example, a transport service can provide flow control to allow a receiver to regulate the transmission rate of a sender. Further a transport service can provide congestion control (see Section 4). As an example TCP and SCTP provide congestion control for use in the Internet, whereas UDP leaves this function to the upper layer protocol that uses UDP. Security features are often provided independent of the transport protocol, via Transport Layer Security (TLS, see Section 3.7) or by the application layer protocol itself. The security properties TLS provides to the application (such as confidentiality, integrity, and authenticity) are also features of the transport layer, even though they are often presently implemented in a separate protocol. 2. Terminology The following terms are used throughout this document, and in subsequent documents produced by TAPS that describe the composition and decomposition of transport services. Transport Service Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. Transport Service: a set of Transport Features, without an association to any given framing protocol, which provides a complete service to an application. Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire. Transport Service Instance: an arrangement of transport protocols with a selected set of features and configuration parameters that implements a single transport service, e.g., a protocol stack (RTP over UDP). Application: an entity that uses the transport layer for end-to-end delivery data across the network (this may also be an upper layer protocol or tunnel encapsulation). Fairhurst, et al. Expires June 9, 2017 [Page 5] Internet-Draft TAPS Transports December 2016 3. Existing Transport Protocols This section provides a list of known IETF transport protocols and transport protocol frameworks. It does not make an assessment about whether specific implementations of protocols are fully compliant to current IETF specifications. 3.1. Transport Control Protocol (TCP) TCP is an IETF standards track transport protocol. [RFC0793] introduces TCP as follows: "The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks." Since its introduction, TCP has become the default connection- oriented, stream-based transport protocol in the Internet. It is widely implemented by endpoints and widely used by common applications. 3.1.1. Protocol Description TCP is a connection-oriented protocol, providing a three way handshake to allow a client and server to set up a connection and negotiate features, and mechanisms for orderly completion and immediate teardown of a connection. TCP is defined by a family of RFCs [RFC7414]. TCP provides multiplexing to multiple sockets on each host using port numbers. A similar approach is adopted by other IETF-defined transports. An active TCP session is identified by its four-tuple of local and remote IP addresses and local port and remote port numbers. The destination port during connection setup is often used to indicate the requested service. TCP partitions a continuous stream of bytes into segments, sized to fit in IP packets based on a negotiated maximum segment size and further constrained by the effective Maximum Transmission Unit (MTU) from Path MTU Discovery (PMTUD). ICMP-based Path MTU discovery [RFC1191][RFC1981] as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] have been defined by the IETF. Each byte in the stream is identified by a sequence number. The sequence number is used to order segments on receipt, to identify segments in acknowledgments, and to detect unacknowledged segments for retransmission. This is the basis of the reliable, ordered delivery of data in a TCP stream. TCP Selective Acknowledgment (SACK) [RFC2018] extends this mechanism by making it possible to provide earlier identification of which segments are missing, Fairhurst, et al. Expires June 9, 2017 [Page 6] Internet-Draft TAPS Transports December 2016 allowing faster retransmission. SACK-based methods (e.g. Duplicate Selective ACK) can also result in less spurious retransmission. Receiver flow control is provided by a sliding window: limiting the amount of unacknowledged data that can be outstanding at a given time. The window scale option [RFC7323] allows a receiver to use windows greater than 64KB. All TCP senders provide congestion control, such as described in [RFC5681]. TCP uses a sequence number with a sliding receiver window for flow control. The TCP congestion control mechanism also utilises this TCP sequence number to manage a separate congestion window [RFC5681]. The sending window at a given point in time is the minimum of the receiver window and the congestion window. The congestion window is increased in the absence of congestion and, respectively, decreased if congestion is detected. Often loss is implicitly handled as a congestion indication which is detected in TCP (also as input for retransmission handling) based on two mechanisms: A retransmission timer with exponential back-off or the reception of three acknowledgment for the same segment, so called duplicated ACKs (Fast retransmit). In addition, Explicit Congestion Notification (ECN) [RFC3168] can be used in TCP, if supported by both endpoints, that allows a network node to signal congestion without inducing loss. Alternatively, a delay-based congestion control scheme can be used in TCP that reacts to changes in delay as an early indication of congestion as also further described in Section 4. Examples for different kind of congestion control schemes are given in Section 4. TCP protocol instances can be extended [RFC7414] and tuned. Some features are sender-side only, requiring no negotiation with the receiver; some are receiver-side only, some are explicitly negotiated during connection setup. TCP may buffer data, e.g., to optimize processing or capacity usage. TCP can therefore provides mechanisms to control this, including an optional "PUSH" function [RFC0793] that explicitly requests the transport service not to delay data. By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] to buffer data at the sender into large segments, potentially incurring sender-side buffering delay; this algorithm can be disabled by the sender to transmit more immediately, e.g., to reduce latency for interactive sessions. TCP provides an "urgent data" function for limited out-of-order delivery of the data. This function is deprecated [RFC6093]. Fairhurst, et al. Expires June 9, 2017 [Page 7] Internet-Draft TAPS Transports December 2016 A TCP Reset (RST) control message may be used to force a TCP endpoint to close a session [RFC0793], aborting the connection. A mandatory checksum provides a basic integrity check against misdelivery and data corruption over the entire packet. Applications that require end to end integrity of data are recommended to include a stronger integrity check of their payload data. The TCP checksum [RFC1071] [RFC2460] does not support partial payload protection (as in DCCP/UDP-Lite). TCP supports only unicast connections. 3.1.2. Interface description A User/TCP Interface is defined in [RFC0793] providing six user commands: Open, Send, Receive, Close, Status. This interface does not describe configuration of TCP options or parameters beside use of the PUSH and URGENT flags. [RFC1122] describes extensions of the TCP/application layer interface for: o reporting soft errors such as reception of ICMP error messages, extensive retransmission or urgent pointer advance, o providing a possibility to specify the Differentiated Services Code Point (DSCP) [RFC3260] (formerly, the Type-of-Service, TOS) for segments, o providing a flush call to empty the TCP send queue, and o multihoming support. In API implementations derived from the BSD Sockets API, TCP sockets are created using the "SOCK_STREAM" socket type as described in the IEEE Portable Operating System Interface (POSIX) Base Specifications [POSIX]. The features used by a protocol instance may be set and tuned via this API. There are currently no documents in the RFC Series that describe this interface. 3.1.3. Transport Features The transport features provided by TCP are: o connection-oriented transport with feature negotiation and application-to-port mapping (implemented using SYN segments and the TCP option field to negotiate features), Fairhurst, et al. Expires June 9, 2017 [Page 8] Internet-Draft TAPS Transports December 2016 o unicast transport (though anycast TCP is implemented, at risk of instability due to rerouting), o port multiplexing, o uni- or bidirectional communication, o stream-oriented delivery in a single stream, o fully reliable delivery (implemented using ACKs sent from the receiver to confirm delivery), o error detection (implemented using a segment checksum to verify delivery to the correct endpoint and integrity of the data and options), o segmentation, o data bundling (optional; uses Nagle's algorithm to coalesce data sent within the same RTT into full-sized segments), o flow control (implemented using a window-based mechanism where the receiver advertises the window that it is willing to buffer), o congestion control (usually implemented using a window-based mechanism and four algorithms for different phases of the transmission: slow start, congestion avoidance, fast retransmit, and fast recovery [RFC5681]). 3.2. Multipath TCP (MPTCP) Multipath TCP [RFC6824] is an extension for TCP to support multi- homing for resilience, mobility and load-balancing. It is designed to be as indistinguishable to middleboxes from non-multipath TCP as possible. It does so by establishing regular TCP flows between a pair of source/destination endpoints, and multiplexing the application's stream over these flows. Sub- flows can be started over IPv4 or IPv6 for the same session. 3.2.1. Protocol Description MPTCP uses TCP options for its control plane. They are used to signal multipath capabilities, as well as to negotiate data sequence numbers, and advertise other available IP addresses and establish new sessions between pairs of endpoints. By multiplexing one byte stream over separate paths, MPTCP can achieve a higher throughput than TCP in certain situations. However, Fairhurst, et al. Expires June 9, 2017 [Page 9] Internet-Draft TAPS Transports December 2016 if coupled congestion control [RFC6356] is used, it might limit this benefit to maintain fairness to other flows at the bottleneck. When aggregating capacity over multiple paths, and depending on the way packets are scheduled on each TCP subflow, additional delay and higher jitter might be observed observed before in-order delivery of data to the applications. 3.2.2. Interface Description By default, MPTCP exposes the same interface as TCP to the application. [RFC6897] however describes a richer API for MPTCP- aware applications. This Basic API describes how an application can: o enable or disable MPTCP. o bind a socket to one or more selected local endpoints. o query local and remote endpoint addresses. o get a unique connection identifier (similar to an address-port pair for TCP). The document also recommends the use of extensions defined for SCTP [RFC6458] (see next section) to support multihoming for resilience and mobility. 3.2.3. Transport features As an extension to TCP, MPTCP provides mostly the same features. By establishing multiple sessions between available endpoints, it can additionally provide soft failover solutions in the case that one of the paths become unusable. The transport features provided by MPTCP in addition to TCP therefore are: o multihoming for load-balancing, with endpoint multiplexing of a single byte stream, using either coupled congestion control or for throughput maximization, o address family multiplexing (using IPv4 and IPv6 for the same session), o resilience to network failure and/or handover. Fairhurst, et al. Expires June 9, 2017 [Page 10] Internet-Draft TAPS Transports December 2016 3.3. User Datagram Protocol (UDP) The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF standards track transport protocol. It provides a unidirectional datagram protocol that preserves message boundaries. It provides no error correction, congestion control, or flow control. It can be used to send broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in addition to unicast and anycast datagrams. IETF guidance on the use of UDP is provided in [I-D.ietf-tsvwg-rfc5405bis]. UDP is widely implemented and widely used by common applications, including DNS. 3.3.1. Protocol Description UDP is a connection-less protocol that maintains message boundaries, with no connection setup or feature negotiation. The protocol uses independent messages, ordinarily called datagrams. It provides detection of payload errors and misdelivery of packets to an unintended endpoint, either of which result in discard of received datagrams, with no indication to the user of the service. It is possible to create IPv4 UDP datagrams with no checksum, and while this is generally discouraged [RFC1122] [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. These datagrams rely on the IPv4 header checksum to protect from misdelivery to an unintended endpoint. IPv6 does not permit UDP datagrams with no checksum, although in certain cases [RFC6936] this rule may be relaxed [RFC6935]. UDP does not provide reliability and does not provide retransmission. Messages may be re-ordered, lost, or duplicated in transit. Note that due to the relatively weak form of checksum used by UDP, applications that require end to end integrity of data are recommended to include a stronger integrity check of their payload data. Because UDP provides no flow control, a receiving application that is unable to run sufficiently fast, or frequently, may miss messages. The lack of congestion handling implies UDP traffic may experience loss when using an overloaded path, and may cause the loss of messages from other protocols (e.g., TCP) when sharing the same network path. On transmission, UDP encapsulates each datagram into a single IP packet or several IP packet fragments. This allows a datagram to be larger than the effective path MTU. Fragments are reassembled before delivery to the UDP receiver, making this transparent to the user of Fairhurst, et al. Expires June 9, 2017 [Page 11] Internet-Draft TAPS Transports December 2016 the transport service. When the jumbograms are supported, larger messages may be sent without performing fragmentation. UDP on its own does not provide support for segmentation, receiver flow control, congestion control, PathMTU discovery/PLPMTUD, or ECN. Applications that require these features need to provide them on their own, or by using a protocol over UDP that provides them [I-D.ietf-tsvwg-rfc5405bis]. 3.3.2. Interface Description [RFC0768] describes basic requirements for an API for UDP. Guidance on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. A UDP endpoint consists of a tuple of (IP address, port number). De- multiplexing using multiple abstract endpoints (sockets) on the same IP address is supported. The same socket may be used by a single server to interact with multiple clients (note: this behavior differs from TCP, which uses a pair of tuples to identify a connection). Multiple server instances (processes) that bind to the same socket can cooperate to service multiple clients. The socket implementation arranges to not duplicate the same received unicast message to multiple server processes. Many operating systems also allow a UDP socket to be "connected", i.e., to bind a UDP socket to a specific (remote) UDP endpoint. Unlike TCP's connect primitive, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports [I-D.ietf-tsvwg-rfc5405bis]. 3.3.3. Transport Features The transport features provided by UDP are: o unicast, multicast, anycast, or IPv4 broadcast transport, o port multiplexing (where a receiving port can be configured to receive datagrams from multiple senders), o message-oriented delivery, o uni- or bidirectional communication where the transmissions in each direction are independent, o non-reliable delivery, o unordered delivery, Fairhurst, et al. Expires June 9, 2017 [Page 12] Internet-Draft TAPS Transports December 2016 o error detection (implemented using a segment checksum to verify delivery to the correct endpoint and integrity of the data; optional for IPv4 and optional under specific conditions for IPv6 where all or none of the payload data is protected), 3.4. Lightweight User Datagram Protocol (UDP-Lite) The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an IETF standards track transport protocol. It provides a unidirectional, datagram protocol that preserves message boundaries. IETF guidance on the use of UDP- Lite is provided in [I-D.ietf-tsvwg-rfc5405bis]. A UDP-Lite service may support IPv4 broadcast, multicast, anycast and unicast, and IPv6 multicast, anycast and unicast. Examples of use include a class of applications that can derive benefit from having partially-damaged payloads delivered, rather than discarded. One use is to provider header integrity checks but allow delivery of corrupted payloads to error-tolerant applications, or when payload integrity is provided by some other mechanism (see [RFC6936]). 3.4.1. Protocol Description Like UDP, UDP-Lite is a connection-less datagram protocol, with no connection setup or feature negotiation. It changes the semantics of the UDP "payload length" field to that of a "checksum coverage length" field, and is identified by a different IP protocol/next- header value. The "checksum coverage length" field specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error-insensitive part". Applications using UDP-Lite therefore cannot make assumptions regarding the correctness of the data received in the insensitive part of the UDP-Lite payload. Otherwise, UDP-Lite is semantically identical to UDP. In the same way as for UDP, mechanisms for receiver flow control, congestion control, PMTU or PLPMTU discovery, support for ECN, etc. needs to be provided by upper layer protocols [I-D.ietf-tsvwg-rfc5405bis]. 3.4.2. Interface Description There is no API currently specified in the RFC Series, but guidance on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. The interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates a checksum coverage length value. The checksum coverage may also be made visible to the application via the UDP-Lite MIB module [RFC5097]. Fairhurst, et al. Expires June 9, 2017 [Page 13] Internet-Draft TAPS Transports December 2016 3.4.3. Transport Features The transport features provided by UDP-Lite are: o unicast, multicast, anycast, or IPv4 broadcast transport (as for UDP), o port multiplexing (as for UDP), o message-oriented delivery (as for UDP), o Uni- or bidirectional communication where the transmissions in each direction are independent (as for UDP), o non-reliable delivery (as for UDP), o non-ordered delivery (as for UDP), o partial or full payload error detection (where the checksum coverage field indicates the size of the payload data covered by the checksum). 3.5. Stream Control Transmission Protocol (SCTP) SCTP is a message-oriented IETF standards track transport protocol. The base protocol is specified in [RFC4960]. It supports multi- homing and path failover to provide resilience to path failures. An SCTP association has multiple streams in each direction, providing in-sequence delivery of user messages within each stream. This allows it to minimize head of line blocking. SCTP supports multiple stream scheduling schemes controlling stream multiplexing, including priority and fair weighting schemes. SCTP was originally developed for transporting telephony signaling messages and is deployed in telephony signaling networks, especially in mobile telephony networks. It can also be used for other services, for example, in the WebRTC framework for data channels. 3.5.1. Protocol Description SCTP is a connection-oriented protocol using a four way handshake to establish an SCTP association, and a three way message exchange to gracefully shut it down. It uses the same port number concept as DCCP, TCP, UDP, and UDP-Lite. SCTP only supports unicast. SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit errors and misdelivery of packets to an unintended endpoint. This is stronger than the 16-bit checksums used by TCP or UDP. However, Fairhurst, et al. Expires June 9, 2017 [Page 14] Internet-Draft TAPS Transports December 2016 partial payload checksum coverage as provided by DCCP or UDP-Lite is not supported. SCTP has been designed with extensibility in mind. A common header is followed by a sequence of chunks. [RFC4960] defines how a receiver processes chunks with an unknown chunk type. The support of extensions can be negotiated during the SCTP handshake. Currently defined extensions include mechanisms for dynamic re-configuration of streams [RFC6525] and IP addresses [RFC5061]. Furthermore, the extension specified in [RFC3758] introduces the concept of partial reliability for user messages. SCTP provides a message-oriented service. Multiple small user messages can be bundled into a single SCTP packet to improve efficiency. For example, this bundling may be done by delaying user messages at the sender, similar to Nagle's algorithm used by TCP. User messages which would result in IP packets larger than the MTU will be fragmented at the sender and reassembled at the receiver. There is no protocol limit on the user message size. For MTU discovery the same mechanism than for TCP can be used [RFC1981][RFC4821], as well as utilizing probe packets with padding chunks, as defined in [RFC4820]. [RFC4960] specifies TCP-friendly congestion control to protect the network against overload. SCTP also uses sliding window flow control to protect receivers against overflow. Similar to TCP, SCTP also supports delaying acknowledgments. [RFC7053] provides a way for the sender of user messages to request the immediate sending of the corresponding acknowledgments. Each SCTP association has between 1 and 65536 uni-directional streams in each direction. The number of streams can be different in each direction. Every user message is sent on a particular stream. User messages can be sent un- ordered, or ordered upon request by the upper layer. Un-ordered messages can be delivered as soon as they are completely received. For user messages not requiring fragmentation, this minimizes head of line blocking. On the other hand, ordered messages sent on the same stream are delivered at the receiver in the same order as sent by the sender. The base protocol defined in [RFC4960] does not allow interleaving of user- messages. Large messages on one stream can therefore block the sending of user messages on other streams. [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. This draft also specifies multiple algorithms for the sender side selection of which streams to send data from, supporting a variety of scheduling algorithms including priority based methods. The stream re- configuration extension defined in [RFC6525] allows streams to be Fairhurst, et al. Expires June 9, 2017 [Page 15] Internet-Draft TAPS Transports December 2016 reset during the lifetime of an association and to increase the number of streams, if the number of streams negotiated in the SCTP handshake becomes insufficient. Each user message sent is either delivered to the receiver or, in case of excessive retransmissions, the association is terminated in a non-graceful way [RFC4960], similar to TCP behavior. In addition to this reliable transfer, the partial reliability extension [RFC3758] allows a sender to abandon user messages. The application can specify the policy for abandoning user messages. SCTP supports multi-homing. Each SCTP endpoint uses a list of IP- addresses and a single port number. These addresses can be any mixture of IPv4 and IPv6 addresses. These addresses are negotiated during the handshake and the address re-configuration extension specified in [RFC5061] in combination with [RFC4895] can be used to change these addresses in an authenticated way during the lifetime of an SCTP association. This allows for transport layer mobility. Multiple addresses are used for improved resilience. If a remote address becomes unreachable, the traffic is switched over to a reachable one, if one exists. For securing user messages, the use of TLS over SCTP has been specified in [RFC3436]. However, this solution does not support all services provided by SCTP, such as un-ordered delivery or partial reliability. Therefore, the use of DTLS over SCTP has been specified in [RFC6083] to overcome these limitations. When using DTLS over SCTP, the application can use almost all services provided by SCTP. [I-D.ietf-tsvwg-natsupp] defines methods for endpoints and middleboxes to provide NAT traversal for SCTP over IPv4. For legacy NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP- packets. Alternatively, SCTP packets can be encapsulated in DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The latter encapsulation is used within the WebRTC [I-D.ietf-rtcweb-transports] context. An SCTP ABORT chunk may be used to force a SCTP endpoint to close a session [RFC4960], aborting the connection. SCTP has a well-defined API, described in the next subsection. 3.5.2. Interface Description [RFC4960] defines an abstract API for the base protocol. This API describes the following functions callable by the upper layer of SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, Fairhurst, et al. Expires June 9, 2017 [Page 16] Internet-Draft TAPS Transports December 2016 Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure Threshold, Set Protocol Parameters, and Destroy. The following notifications are provided by the SCTP stack to the upper layer: COMMUNICATION UP, DATA ARRIVE, SHUTDOWN COMPLETE, COMMUNICATION LOST, COMMUNICATION ERROR, RESTART, SEND FAILURE, NETWORK STATUS CHANGE. An extension to the BSD Sockets API is defined in [RFC6458] and covers: o the base protocol defined in [RFC4960]. The API allows control over local addresses and port numbers and the primary path. Furthermore the application has fine control about parameters like retransmission thresholds, the path supervision parameters, the delayed acknowledgment timeout, and the fragmentation point. The API provides a mechanism to allow the SCTP stack to notify the application about events if the application has requested them. These notifications provide information about status changes of the association and each of the peer addresses. In case of send failures, including drop of messages sent unreliably, the application can also be notified and user messages can be returned to the application. When sending user messages, the stream id, a payload protocol identifier, an indication whether ordered delivery is requested or not. These parameters can also be provided on message reception. Additionally a context can be provided when sending, which can be use in case of send failures. The sending of arbitrary large user messages is supported. o the SCTP Partial Reliability extension defined in [RFC3758] to specify for a user message the PR-SCTP policy and the policy specific parameter. Examples of these policies defined in [RFC3758] and [RFC7496] are: o Limiting the time a user message is dealt with by the sender. o Limiting the number of retransmissions for each fragment of a user message. If the number of retransmissions is limited to 0, one gets a service similar to UDP. o Abandoning messages of lower priority in case of a send buffer shortage. o the SCTP Authentication extension defined in [RFC4895] allowing to manage the shared keys, the HMAC to use, set the chunk types which are only accepted in an authenticated way, and get the list of chunks which are accepted by the local and remote end point in an authenticated way. Fairhurst, et al. Expires June 9, 2017 [Page 17] Internet-Draft TAPS Transports December 2016 o the SCTP Dynamic Address Reconfiguration extension defined in [RFC5061]. It allows to manually add and delete local addresses for SCTP associations and the enabling of automatic address addition and deletion. Furthermore the peer can be given a hint for choosing its primary path. A BSD Sockets API extension has been defined in the documents that specify the following SCTP protocol extensions: o the SCTP Stream Reconfiguration extension defined in [RFC6525]. The API allows to trigger the reset operation for incoming and outgoing streams and the whole association. It provides also a way to notify the association about the corresponding events. Furthermore the application can increase the number of streams. o the UDP Encapsulation of SCTP packets extension defined in [RFC6951]. The API allows the management of the remote UDP encapsulation port. o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. The API allows the sender of a user message to request the receiver to send the corresponding acknowledgment immediately. o the additional PR-SCTP policies defined in [RFC7496]. The API allows to enable/disable the PR-SCTP extension, choose the PR-SCTP policies defined in the document and provide statistical information about abandoned messages. Future documents describing SCTP protocol extensions are expected to describe the corresponding BSD Sockets API extension in a "Socket API Considerations" section. The SCTP socket API supports two kinds of sockets: o one-to-one style sockets (by using the socket type "SOCK_STREAM"). o one-to-many style socket (by using the socket type "SOCK_SEQPACKET"). One-to-one style sockets are similar to TCP sockets, there is a 1:1 relationship between the sockets and the SCTP associations (except for listening sockets). One-to-many style SCTP sockets are similar to unconnected UDP sockets, where there is a 1:n relationship between the sockets and the SCTP associations. The SCTP stack can provide information to the applications about state changes of the individual paths and the association whenever Fairhurst, et al. Expires June 9, 2017 [Page 18] Internet-Draft TAPS Transports December 2016 they occur. These events are delivered similar to user messages but are specifically marked as notifications. New functions have been introduced to support the use of multiple local and remote addresses. Additional SCTP-specific send and receive calls have been defined to permit SCTP-specific information to be sent without using ancillary data in the form of additional cmsgs. These functions provide support for detecting partial delivery of user messages and notifications. The SCTP socket API allows a fine-grained control of the protocol behavior through an extensive set of socket options. The SCTP kernel implementations of FreeBSD, Linux and Solaris follow mostly the specified extension to the BSD Sockets API for the base protocol and the corresponding supported protocol extensions. 3.5.3. Transport Features The transport features provided by SCTP are: o connection-oriented transport with feature negotiation and application-to-port mapping, o unicast transport, o port multiplexing, o uni- or bidirectional communication, o message-oriented delivery with durable message framing supporting multiple concurrent streams, o fully reliable, partially reliable, or unreliable delivery (based on user specified policy to handle abandoned user messages) with drop notification, o ordered and unordered delivery within a stream, o support for stream scheduling prioritization, o segmentation, o user message bundling, o flow control using a window-based mechanism, o congestion control using methods similar to TCP, Fairhurst, et al. Expires June 9, 2017 [Page 19] Internet-Draft TAPS Transports December 2016 o strong error detection (CRC32c), o transport layer multihoming for resilience and mobility. 3.6. Datagram Congestion Control Protocol (DCCP) Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF standards track bidirectional transport protocol that provides unicast connections of congestion-controlled messages without providing reliability. The DCCP Problem Statement describes the goals that DCCP sought to address [RFC4336]: It is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the trade off between timeliness and reliability [RFC4336]. DCCP offers low overhead, and many characteristics common to UDP, but can avoid "re-inventing the wheel" each time a new multimedia application emerges. Specifically it includes core transport functions (feature negotiation, path state management, RTT calculation, PMTUD, etc.): DCCP applications select how they send packets and, where suitable, choose common algorithms to manage their functions. Examples of applications that can benefit from such transport services include interactive applications, streaming media, or on-line games [RFC4336]. 3.6.1. Protocol Description DCCP is a connection-oriented datagram protocol, providing a three- way handshake to allow a client and server to set up a connection, and mechanisms for orderly completion and immediate teardown of a connection. A DCCP protocol instance can be extended [RFC4340] and tuned using additional features. Some features are sender-side only, requiring no negotiation with the receiver; some are receiver-side only; and some are explicitly negotiated during connection setup. DCCP uses a Connect packet to initiate a session, and permits each endpoint to choose the features it wishes to support. Simultaneous open [RFC5596], as in TCP, can enable interoperability in the presence of middleboxes. The Connect packet includes a Service Code [RFC5595] that identifies the application or protocol using DCCP, providing middleboxes with information about the intended use of a connection. The DCCP service is unicast-only. Fairhurst, et al. Expires June 9, 2017 [Page 20] Internet-Draft TAPS Transports December 2016 It provides multiplexing to multiple sockets at each endpoint using port numbers. An active DCCP session is identified by its four-tuple of local and remote IP addresses and local port and remote port numbers. The protocol segments data into messages, typically sized to fit in IP packets, but which may be fragmented providing they are smaller than the maximum packet size. A DCCP interface allows applications to request fragmentation for packets larger than PMTU, but not larger than the maximum packet size allowed by the current congestion control mechanism (CCMPS) [RFC4340]. Each message is identified by a sequence number. The sequence number is used to identify segments in acknowledgments, to detect unacknowledged segments, to measure RTT, etc. The protocol may support unordered delivery of data, and does not itself provide retransmission. DCCP supports reduced checksum coverage, a partial payload protection mechanism similar to UDP-Lite. There is also a Data Checksum option, which when enabled, contains a strong CRC, to enable endpoints to detect application data corruption. Receiver flow control is supported, which limits the amount of unacknowledged data that can be outstanding at a given time. A DCCP Reset packet may be used to force a DCCP endpoint to close a session [RFC4340], aborting the connection. DCCP supports negotiation of the congestion control profile between endpoints, to provide plug-and-play congestion control mechanisms. Examples of specified profiles include "TCP-like" [RFC4341], "TCP- friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622]. Additional mechanisms are recorded in an IANA registry. A lightweight UDP-based encapsulation (DCCP-UDP) has been defined [RFC6773] that permits DCCP to be used over paths where DCCP is not natively supported. Support for DCCP in NAPT/NATs is defined in [RFC4340] and [RFC5595]. Upper layer protocols specified on top of DCCP include DTLS [RFC5595], RTP [RFC5672], ICE/SDP [RFC6773]. 3.6.2. Interface Description Functions expected for a DCCP API include: Open, Close and Management of the progress a DCCP connection. The Open function provides feature negotiation, selection of an appropriate CCID for congestion control and other parameters associated with the DCCP connection. A function allows an application to send DCCP datagrams, including setting the required checksum coverage, and any required options. (DCCP permits sending datagrams with a zero-length payload.) A Fairhurst, et al. Expires June 9, 2017 [Page 21] Internet-Draft TAPS Transports December 2016 function allows reception of data, including indicating if the data was used or dropped. Functions can also make the status of a connection visible to an application, including detection of the maximum packet size and the ability to perform flow control by detecting a slow receiver at the sender. There is no API currently specified in the RFC Series. 3.6.3. Transport Features The transport features provided by DCCP are: o unicast transport, o connection-oriented communication with feature negotiation and application-to-port mapping, o signaling of application class for middlebox support (implemented using Service Codes), o port multiplexing, o uni-or bidirectional communication, o message-oriented delivery, o unreliable delivery with drop notification, o unordered delivery, o flow control (implemented using the slow receiver function) o partial and full payload error detection (with optional strong integrity check). 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a pseudotransport Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) [RFC6347] are IETF protocols that provide several security-related features to applications. TLS is designed to run on top of a reliable streaming transport protocol (usually TCP), while DTLS is designed to run on top of a best-effort datagram protocol (UDP or DCCP [RFC5238]). At the time of writing, the current version of TLS is 1.2, defined in [RFC5246]; work on TLS version 1.3 [I-D.ietf-tls-tls13] nearing completion. DTLS provides nearly identical functionality to applications; it is defined in [RFC6347] and its current version is also 1.2. The TLS protocol evolved from Fairhurst, et al. Expires June 9, 2017 [Page 22] Internet-Draft TAPS Transports December 2016 the Secure Sockets Layer (SSL) [RFC6101] protocols developed in the mid-1990s to support protection of HTTP traffic. While older versions of TLS and DTLS are still in use, they provide weaker security guarantees. [RFC7457] outlines important attacks on TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document that describes secure configurations for TLS and DTLS to counter these attacks. The recommendations are applicable for the vast majority of use cases. 3.7.1. Protocol Description Both TLS and DTLS provide the same security features and can thus be discussed together. The features they provide are: o Confidentiality o Data integrity o Peer authentication (optional) o Perfect forward secrecy (optional) The authentication of the peer entity can be omitted; a common web use case is where the server is authenticated and the client is not. TLS also provides a completely anonymous operation mode in which neither peer's identity is authenticated. It is important to note that TLS itself does not specify how a peering entity's identity should be interpreted. For example, in the common use case of authentication by means of an X.509 certificate, it is the application's decision whether the certificate of the peering entity is acceptable for authorization decisions. Perfect forward secrecy, if enabled and supported by the selected algorithms, ensures that traffic encrypted and captured during a session at time t0 cannot be later decrypted at time t1 (t1 > t0), even if the long-term secrets of the communicating peers are later compromised. As DTLS is generally used over an unreliable datagram transport such as UDP, applications will need to tolerate lost, re-ordered, or duplicated datagrams. Like TLS, DTLS conveys application data in a sequence of independent records. However, because records are mapped to unreliable datagrams, there are several features unique to DTLS that are not applicable to TLS: o Record replay detection (optional). Fairhurst, et al. Expires June 9, 2017 [Page 23] Internet-Draft TAPS Transports December 2016 o Record size negotiation (estimates of PMTU and record size expansion factor). o Conveyance of IP don't fragment (DF) bit settings by application. o An anti-DoS stateless cookie mechanism (optional). Generally, DTLS follows the TLS design as closely as possible. To operate over datagrams, DTLS includes a sequence number and limited forms of retransmission and fragmentation for its internal operations. The sequence number may be used for detecting replayed information, according to the windowing procedure described in Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream ciphers, which are essentially incompatible when operating on independent encrypted records. 3.7.2. Interface Description TLS is commonly invoked using an API provided by packages such as OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the manipulation of several important abstractions, which fall into the following categories: long-term keys and algorithms, session state, and communications/connections. Considerable care is required in the use of TLS APIs to ensure creation of a secure application. The programmer should have at least a basic understanding of encryption and digital signature algorithms and their strengths, public key infrastructure (including X.509 certificates and certificate revocation), and the sockets API. See [RFC7525] and [RFC7457], as mentioned above. As an example, in the case of OpenSSL, the primary abstractions are the library itself and method (protocol), session, context, cipher and connection. After initializing the library and setting the method, a cipher suite is chosen and used to configure a context object. Session objects may then be minted according to the parameters present in a context object and associated with individual connections. Depending on how precisely the programmer wishes to select different algorithmic or protocol options, various levels of details may be required. 3.7.3. Transport Features Both TLS and DTLS employ a layered architecture. The lower layer is commonly called the record protocol. It is responsible for: o message fragmentation, Fairhurst, et al. Expires June 9, 2017 [Page 24] Internet-Draft TAPS Transports December 2016 o authentication and integrity via message authentication codes (MAC), o data encryption, o scheduling transmission using the underlying transport protocol. DTLS augments the TLS record protocol with: o ordering and replay protection, implemented using sequence numbers. Several protocols are layered on top of the record protocol. These include the handshake, alert, and change cipher spec protocols. There is also the data protocol, used to carry application traffic. The handshake protocol is used to establish cryptographic and compression parameters when a connection is first set up. In DTLS, this protocol also has a basic fragmentation and retransmission capability and a cookie-like mechanism to resist DoS attacks. (TLS compression is not recommended at present). The alert protocol is used to inform the peer of various conditions, most of which are terminal for the connection. The change cipher spec protocol is used to synchronize changes in cryptographic parameters for each peer. The data protocol, when used with an appropriate cipher, provides: o authentication of one end or both ends of a connection, o confidentiality, o cryptographic integrity protection. Both TLS and DTLS are unicast-only. 3.8. Realtime Transport Protocol (RTP) RTP provides an end-to-end network transport service, suitable for applications transmitting real-time data, such as audio, video or data, over multicast or unicast transport services, including TCP, UDP, UDP-Lite, DCCP, TLS and DTLS. 3.8.1. Protocol Description The RTP standard [RFC3550] defines a pair of protocols, RTP and the RTP control protocol, RTCP. The transport does not provide connection setup, instead relying on out-of-band techniques or associated control protocols to setup, negotiate parameters or tear down a session. Fairhurst, et al. Expires June 9, 2017 [Page 25] Internet-Draft TAPS Transports December 2016 An RTP sender encapsulates audio/video data into RTP packets to transport media streams. The RFC-series specifies RTP payload formats that allow packets to carry a wide range of media, and specifies a wide range of multiplexing, error control and other support mechanisms. If a frame of media data is large, it will be fragmented into several RTP packets. Likewise, several small frames may be bundled into a single RTP packet. An RTP receiver collects RTP packets from the network, validates them for correctness, and sends them to the media decoder input-queue. Missing packet detection is performed by the channel decoder. The play-out buffer is ordered by time stamp and is used to reorder packets. Damaged frames may be repaired before the media payloads are decompressed to display or store the data. Some uses of RTP are able to exploit the partial payload protection features offered by DCCP and UDP-Lite. RTCP is a control protocol that works alongside an RTP flow. Both the RTP sender and receiver will send RTCP report packets. This is used to periodically send control information and report performance. Based on received RTCP feedback, an RTP sender can adjust the transmission, e.g., perform rate adaptation at the application layer in the case of congestion. An RTCP receiver report (RTCP RR) is returned to the sender periodically to report key parameters (e.g, the fraction of packets lost in the last reporting interval, the cumulative number of packets lost, the highest sequence number received, and the inter-arrival jitter). The RTCP RR packets also contain timing information that allows the sender to estimate the network round trip time (RTT) to the receivers. The interval between reports sent from each receiver tends to be on the order of a few seconds on average, although this varies with the session rate, and sub-second reporting intervals are possible for high rate sessions. The interval is randomized to avoid synchronization of reports from multiple receivers. 3.8.2. Interface Description There is no standard application programming interface defined for RTP or RTCP. Implementations are typically tightly integrated with a particular application, and closely follow the principles of application level framing and integrated layer processing [ClarkArch] in media processing [RFC2736], error recovery and concealment, rate adaptation, and security [RFC7202]. Accordingly, RTP implementations Fairhurst, et al. Expires June 9, 2017 [Page 26] Internet-Draft TAPS Transports December 2016 tend to be targeted at particular application domains (e.g., voice- over-IP, IPTV, or video conferencing), with a feature set optimized for that domain, rather than being general purpose implementations of the protocol. 3.8.3. Transport Features The transport features provided by RTP are: o unicast, multicast or IPv4 broadcast (provided by lower layer protocol), o port multiplexing (provided by lower layer protocol), o uni- or bidirectional communication (provided by lower layer protocol), o message-oriented delivery with support for media types and other extensions, o reliable delivery when using erasure coding or unreliable delivery with drop notification (if supported by lower layer protocol), o connection setup with feature negotiation (using associated protocols) and application-to-port mapping (provided by lower layer protocol), o segmentation, o performance metric reporting (using associated protocols). 3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport The Hypertext Transfer Protocol (HTTP) is an application-level protocol widely used on the Internet. It provides object-oriented delivery of discrete data or files. Version 1.1 of the protocol is specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], and version 2 in [RFC7540]. HTTP is usually transported over TCP using port 80 and 443, although it can be used with other transports. When used over TCP it inherits TCP's properties. Application layer protocols may use HTTP as a substrate with an existing method and data formats, or specify new methods and data formats. There are various reasons for this practice listed in [RFC3205]; these include being a well-known and well-understood protocol, reusability of existing servers and client libraries, easy use of existing security mechanisms such as HTTP digest authentication [RFC2617] and TLS [RFC5246], the ability of HTTP to Fairhurst, et al. Expires June 9, 2017 [Page 27] Internet-Draft TAPS Transports December 2016 traverse firewalls makes it work over many types of infrastructure, and in cases where an application server often needs to support HTTP anyway. Depending on application need, the use of HTTP as a substrate protocol may add complexity and overhead in comparison to a special- purpose protocol (e.g., HTTP headers, suitability of the HTTP security model, etc.). [RFC3205] addresses this issue and provides some guidelines and identifies concerns about the use of HTTP standard port 80 and 443, the use of HTTP URL scheme and interaction with existing firewalls, proxies and NATs. Representational State Transfer (REST) [REST] is another example of how applications can use HTTP as transport protocol. REST is an architecture style that may be used to build applications using HTTP as a communication protocol. 3.9.1. Protocol Description Hypertext Transfer Protocol (HTTP) is a request/response protocol. A client sends a request containing a request method, URI and protocol version followed message whose design is inspired by MIME (see [RFC7231] for the differences between an HTTP object and a MIME message), containing information about the client and request modifiers. The message can also contain a message body carrying application data. The server responds with a status or error code followed by a message containing information about the server and information about the data. This may include a message body. It is possible to specify a data format for the message body using MIME media types [RFC2045]. The protocol has additional features, some relevant to pseudo-transport are described below. Content negotiation, specified in [RFC7231], is a mechanism provided by HTTP to allow selection of a representation for a requested resource. The client and server negotiate acceptable data formats, character sets, data encoding (e.g., data can be transferred compressed using gzip). HTTP can accommodate exchange of messages as well as data streaming (using chunked transfer encoding [RFC7230]). It is also possible to request a part of a resource using an object range request [RFC7233]. The protocol provides powerful cache control signaling defined in [RFC7234]. The persistent connections of HTTP 1.1 and HTTP 2.0 allow multiple request- response transactions (streams) during the life-time of a single HTTP connection. This reduces overhead during connection establishment and mitigates transport layer slow-start that would have otherwise been incurred for each transaction. HTTP 2.0 connections can multiplex many request/response pairs in parallel on Fairhurst, et al. Expires June 9, 2017 [Page 28] Internet-Draft TAPS Transports December 2016 a single transport connection. Both are important to reduce latency for HTTP's primary use case. HTTP can be combined with security mechanisms, such as TLS (denoted by HTTPS). This adds protocol properties provided by such a mechanism (e.g., authentication, encryption). The TLS Application- Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to negotiate the HTTP version within the TLS handshake, eliminating the latency incurred by additional round-trip exchanges. Arbitrary cookie strings, included as part of the request headers, are often used as bearer tokens in HTTP. 3.9.2. Interface Description There are many HTTP libraries available exposing different APIs. The APIs provide a way to specify a request by providing a URI, a method, request modifiers and optionally a request body. For the response, callbacks can be registered that will be invoked when the response is received. If HTTPS is used, the API exposes a registration of callbacks for a server that requests client authentication and when certificate verification is needed. The World Wide Web Consortium (W3C) has standardized the XMLHttpRequest API [XHR]. This API can be used for sending HTTP/ HTTPS requests and receiving server responses. Besides the XML data format, the request and response data format can also be JSON, HTML, and plain text. JavaScript and XMLHttpRequest are ubiquitous programming models for websites, and more general applications, where native code is less attractive. 3.9.3. Transport features The transport features provided by HTTP, when used as a pseudo- transport, are: o unicast transport (provided by the lower layer protocol, usually TCP), o uni- or bidirectional communication, o transfer of objects in multiple streams with object content type negotiation, supporting partial transmission of object ranges, o ordered delivery (provided by the lower layer protocol, usually TCP), o fully reliable delivery (provided by the lower layer protocol, usually TCP), Fairhurst, et al. Expires June 9, 2017 [Page 29] Internet-Draft TAPS Transports December 2016 o flow control (provided by the lower layer protocol, usually TCP). o congestion control (provided by the lower layer protocol, usually TCP). HTTPS (HTTP over TLS) additionally provides the following features (as provided by TLS): o authentication (of one or both ends of a connection), o confidentiality, o integrity protection. 3.10. File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC) FLUTE/ALC is an IETF standards track protocol specified in [RFC6726] and [RFC5775]. It provides object-oriented delivery of discrete data or files. Asynchronous Layer Coding (ALC) provides an underlying reliable transport service and FLUTE a file-oriented specialization of the ALC service (e.g., to carry associated metadata). The [RFC6726] and [RFC5775] protocols are non-backward-compatible updates of the [RFC3926] and [RFC3450] experimental protocols; these experimental protocols are currently largely deployed in the 3GPP Multimedia Broadcast and Multicast Services (MBMS) (see [MBMS], section 7) and similar contexts (e.g., the Japanese ISDB-Tmm standard). The FLUTE/ALC protocol has been designed to support massively scalable reliable bulk data dissemination to receiver groups of arbitrary size using IP Multicast over any type of delivery network, including unidirectional networks (e.g., broadcast wireless channels). However, the FLUTE/ALC protocol also supports point-to- point unicast transmissions. FLUTE/ALC bulk data dissemination has been designed for discrete file or memory-based "objects". Although FLUTE/ALC is not well adapted to byte- and message-streaming, there is an exception: FLUTE/ALC is used to carry 3GPP Dynamic Adaptive Streaming over HTTP (DASH) when scalability is a requirement (see [MBMS], section 5.6). FLUTE/ALC's reliability, delivery mode, congestion control, and flow/ rate control mechanisms can be separately controlled to meet different application needs. Section 4.1 of [I-D.ietf-tsvwg-rfc5405bis] describes multicast congestion control requirements for UDP. Fairhurst, et al. Expires June 9, 2017 [Page 30] Internet-Draft TAPS Transports December 2016 3.10.1. Protocol Description The FLUTE/ALC protocol works on top of UDP (though it could work on top of any datagram delivery transport protocol), without requiring any connectivity from receivers to the sender. Purely unidirectional networks are therefore supported by FLUTE/ALC. This guarantees scalability to an unlimited number of receivers in a session, since the sender behaves exactly the same regardless of the number of receivers. FLUTE/ALC supports the transfer of bulk objects such as file or in- memory content, using either a push or an on-demand mode. in push mode, content is sent once to the receivers, while in on-demand mode, content is sent continuously during periods of time that can greatly exceed the average time required to download the session objects (see [RFC5651], section 4.2). This enables receivers to join a session asynchronously, at their own discretion, receive the content and leave the session. In this case, data content is typically sent continuously, in loops (also known as "carousels"). FLUTE/ALC also supports the transfer of an object stream, with loose real-time constraints. This is particularly useful to carry 3GPP DASH when scalability is a requirement and unicast transmissions over HTTP cannot be used ([MBMS], section 5.6). In this case, packets are sent in sequence using push mode. FLUTE/ ALC is not well adapted to byte- and message-streaming and other solutions could be preferred (e.g., FECFRAME [RFC6363] with real-time flows). The FLUTE file delivery instantiation of ALC provides a metadata delivery service. Each object of the FLUTE/ALC session is described in a dedicated entry of a File Delivery Table (FDT), using an XML format (see [RFC6726], section 3.2). This metadata can include, but is not restricted to, a URI attribute (to identify and locate the object), a media type attribute, a size attribute, an encoding attribute, or a message digest attribute. Since the set of objects sent within a session can be dynamic, with new objects being added and old ones removed, several instances of the FDT can be sent and a mechanism is provided to identify a new FDT Instance. Error detection and verification of the protocol control information relies on the on the underlying transport (e.g., UDP checksum). To provide robustness against packet loss and improve the efficiency of the on-demand mode, FLUTE/ALC relies on packet erasure coding (AL- FEC). AL-FEC encoding is proactive (since there is no feedback and therefore no (N)ACK-based retransmission) and ALC packets containing repair data are sent along with ALC packets containing source data. Fairhurst, et al. Expires June 9, 2017 [Page 31] Internet-Draft TAPS Transports December 2016 Several FEC Schemes have been standardized; FLUTE/ALC does not mandate the use of any particular one. Several strategies concerning the transmission order of ALC source and repair packets are possible, in particular in on-demand mode where it can deeply impact the service provided (e.g., to favor the recovery of objects in sequence, or at the other extreme, to favor the recovery of all objects in parallel), and FLUTE/ALC does not mandate nor recommend the use of any particular one. A FLUTE/ALC session is composed of one or more channels, associated to different destination unicast and/or multicast IP addresses. ALC packets are sent in those channels at a certain transmission rate, with a rate that often differs depending on the channel. FLUTE/ALC does not mandate nor recommend any strategy to select which ALC packet to send on which channel. FLUTE/ALC can use a multiple rate congestion control building block (e.g., WEBRC) to provide congestion control that is feedback free, where receivers adjust their reception rates individually by joining and leaving channels associated with the session. To that purpose, the ALC header provides a specific field to carry congestion control specific information. However FLUTE/ALC does not mandate the use of a particular congestion control mechanism although WEBRC is mandatory to support for the Internet ([RFC6726], section 1.1.4). FLUTE/ALC is often used over a network path with pre-provisioned capacity [I-D.ietf-tsvwg-rfc5405bis] where there are no flows competing for capacity. In this case, a sender- based rate control mechanism and a single channel is sufficient. [RFC6584] provides per-packet authentication, integrity, and anti- replay protection in the context of the ALC and NORM protocols. Several mechanisms are proposed that seamlessly integrate into these protocols using the ALC and NORM header extension mechanisms. 3.10.2. Interface Description The FLUTE/ALC specification does not describe a specific application programming interface (API) to control protocol operation. Although open source and commercial implementations have specified APIs, there is no IETF- specified API for FLUTE/ALC. 3.10.3. Transport Features The transport features provided by FLUTE/ALC are: o unicast, multicast, anycast or IPv4 broadcast transmission, o object-oriented delivery of discrete data or files and associated metadata, Fairhurst, et al. Expires June 9, 2017 [Page 32] Internet-Draft TAPS Transports December 2016 o fully reliable or partially reliable delivery (of file or in- memory objects), using proactive packet erasure coding (AL-FEC) to recover from packet erasures, o ordered or unordered delivery (of file or in-memory objects), o error detection (based on the UDP checksum), o per-packet authentication, o per-packet integrity, o per-packet replay protection, o congestion control for layered flows (e.g., with WEBRC). 3.11. NACK-Oriented Reliable Multicast (NORM) NORM is an IETF standards track protocol specified in [RFC5740]. It provides object-oriented delivery of discrete data or files. The protocol was designed to support reliable bulk data dissemination to receiver groups using IP Multicast but also provides for point-to- point unicast operation. Support for bulk data dissemination includes discrete file or computer memory-based "objects" as well as byte- and message-streaming. NORM can incorporate packet erasure coding as a part of its selective ARQ in response to negative acknowledgments from the receiver. The packet erasure coding can also be proactively applied for forward protection from packet loss. NORM transmissions are governed by TCP- friendly multicast congestion control (TFMCC, [RFC4654]). The reliability, congestion control and flow control mechanisms can be separately controlled to meet different application needs. 3.11.1. Protocol Description The NORM protocol is encapsulated in UDP datagrams and thus provides multiplexing for multiple sockets on hosts using port numbers. For loosely coordinated IP Multicast, NORM is not strictly connection- oriented although per-sender state is maintained by receivers for protocol operation. [RFC5740] does not specify a handshake protocol for connection establishment. Separate session initiation can be used to coordinate port numbers. However, in-band "client-server" style connection establishment can be accomplished with the NORM congestion control signaling messages using port binding techniques like those for TCP client-server connections. Fairhurst, et al. Expires June 9, 2017 [Page 33] Internet-Draft TAPS Transports December 2016 NORM supports bulk "objects" such as file or in-memory content but also can treat a stream of data as a logical bulk object for purposes of packet erasure coding. In the case of stream transport, NORM can support either byte streams or message streams where application- defined message boundary information is carried in the NORM protocol messages. This allows the receiver(s) to join/re-join and recover message boundaries mid-stream as needed. Application content is carried and identified by the NORM protocol with encoding symbol identifiers depending upon the Forward Error Correction (FEC) Scheme [RFC3452] configured. NORM uses NACK-based selective ARQ to reliably deliver the application content to the receiver(s). NORM proactively measures round-trip timing information to scale ARQ timers appropriately and to support congestion control. For multicast operation, timer-based feedback suppression is uses to achieve group size scaling with low feedback traffic levels. The feedback suppression is not applied for unicast operation. NORM uses rate-based congestion control based upon the TCP-Friendly Rate Control (TFRC) [RFC4324] principles that are also used in DCCP [RFC4340]. NORM uses control messages to measure RTT and collect congestion event information (e.g., reflecting a loss event or ECN event) from the receiver(s) to support dynamic adjustment or the rate. The TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654] provides extra features to support multicast, but is functionally equivalent to TFRC for unicast. Error detection and verification of the protocol control information relies on the on the underlying transport(e.g., UDP checksum). The reliability mechanism is decoupled from congestion control. This allows invocation of alternative arrangements of transport services. For example, to support, fixed-rate reliable delivery or unreliable delivery (that may optionally be "better than best effort" via packet erasure coding) using TFRC. Alternative congestion control techniques may be applied. For example, TFRC rate control with congestion event detection based on ECN. While NORM provides NACK-based reliability, it also supports a positive acknowledgment (ACK) mechanism that can be used for receiver flow control. This mechanism is decoupled from the reliability and congestion control, supporting applications with different needs. One example is use of NORM for quasi-reliable delivery, where timely delivery of newer content may be favored over completely reliable delivery of older content within buffering and RTT constraints. Fairhurst, et al. Expires June 9, 2017 [Page 34] Internet-Draft TAPS Transports December 2016 3.11.2. Interface Description The NORM specification does not describe a specific application programming interface (API) to control protocol operation. A freely- available, open source reference implementation of NORM is available at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented API is provided for this implementation. While a sockets-like API is not currently documented, the existing API supports the necessary functions for that to be implemented. 3.11.3. Transport Features The transport features provided by NORM are: o unicast or multicast transport, o unidirectional communication, o stream-oriented delivery in a single stream or object-oriented delivery of in-memory data or file bulk content objects, o fully reliable (NACK-based) or partially reliable (using erasure coding both proactively and as part of ARQ) delivery, o unordered delivery, o error detection (relies on UDP checksum), o segmentation, o data bundling (using Nagle's algorithm), o flow control (timer-based and/or ack-based), o congestion control (also supporting fixed rate reliable or unreliable delivery). 3.12. Internet Control Message Protocol (ICMP) The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and ICMP for IPv6 [RFC4443] are IETF standards track protocols. It is a connection-less unidirectional protocol that delivers individual messages, without error correction, congestion control, or flow control. Messages may be sent as unicast, IPv4 broadcast or multicast datagrams (IPv4 and IPv6), in addition to anycast datagrams. Fairhurst, et al. Expires June 9, 2017 [Page 35] Internet-Draft TAPS Transports December 2016 While ICMP is not typically described as a transport protocol, it does position itself over the network layer, and the operation of other transport protocols can be closely linked to the functions provided by ICMP. Transport Protocols and upper layer protocols can use received ICMP messages to help them take appropriate decisions when network or endpoint errors are reported. For example, to implement, ICMP-based Path MTU discovery [RFC1191][RFC1981] or assist in Packetization Layer Path MTU Discovery (PMTUD) [RFC4821]. Such reactions to received messages need to protect from off-path data injection [I-D.ietf-tsvwg-rfc5405bis], to avoid an application receiving packets created by an unauthorized third party. An application therefore needs to ensure that all messages are appropriately validated, by checking the payload of the messages to ensure these are received in response to actually transmitted traffic (e.g., a reported error condition that corresponds to a UDP datagram or TCP segment was actually sent by the application). This requires context [RFC6056], such as local state about communication instances to each destination (e.g., in the TCP, DCCP, or SCTP protocols). This state is not always maintained by UDP-based applications [I-D.ietf-tsvwg-rfc5405bis]. 3.12.1. Protocol Description ICMP is a connection-less unidirectional protocol, It delivers independent messages, called datagrams. Each message is required to carry a checksum as an integrity check and to protect from mis- delivery to an unintended endpoint. ICMP messages typically relay diagnostic information from an endpoint [RFC1122] or network device [RFC1812] addressed to the sender of a flow. This usually contains the network protocol header of a packet that encountered a reported issue. Some formats of messages can also carry other payload data. Each message carries an integrity check calculated in the same way as for UDP, this checksum is not optional. The RFC series defines additional IPv6 message formats to support a range of uses. In the case of IPv6 the protocol incorporates neighbor discovery [RFC2461] [RFC3971] (provided by ARP for IPv4) and the Multicast Listener Discovery (MLD) [RFC2710] group management functions (provided by IGMP for IPv4). Reliable transmission can not be assumed. A receiving application that is unable to run sufficiently fast, or frequently, may miss messages since there is no flow or congestion control. In addition some network devices rate-limit ICMP messages. Fairhurst, et al. Expires June 9, 2017 [Page 36] Internet-Draft TAPS Transports December 2016 3.12.2. Interface Description ICMP processing is integrated in many connection-oriented transports, but like other functions needs to be provided by an upper-layer protocol when using UDP and UDP-Lite. On some stacks, a bound socket also allows a UDP application to be notified when ICMP error messages are received for its transmissions [I-D.ietf-tsvwg-rfc5405bis]. Any response to ICMP error messages ought to be robust to temporary routing failures (sometimes called "soft errors"), e.g., transient ICMP "unreachable" messages ought to not normally cause a communication abort [RFC5461] [I-D.ietf-tsvwg-rfc5405bis]. 3.12.3. Transport Features ICMP does not provide any transport service directly to applications. Used together with other transport protocols, it provides transmission of control, error, and measurement data between endpoints, or from devices along the path to one endpoint. 4. Congestion Control Congestion control is critical to the stable operation of the Internet. A variety of mechanisms are used to provide the congestion control needed by many Internet transport protocols. Congestion is detected based on sensing of network conditions, whether through explicit or implicit feedback. The congestion control mechanisms that can be applied by different transport protocols are largely orthogonal to the choice of transport protocol. This section provides an overview of the congestion control mechanisms available to the protocols described in Section 3. Many protocols use a separate window to determine the maximum sending rate that is allowed by the congestion control. The used congestion control mechanism will increase the congestion window if feedback is received that indicates that the currently used network path is not congested, and will reduce the window otherwise. Window-based mechanisms often increase their window slowing over multiple RTTs, while decreasing strongly when the first indication of congestion is received. One example is an Additive Increase Multiplicative Decrease (AIMD) scheme, where the window is increased by a certain number of packets/bytes for each data segment that has been successfully transmitted, while the window decreases multiplicatively on the occurrence of a congestion event. This can lead to a rather unstable, oscillating sending rate, but will resolve a congestion situation quickly. TCP New Reno [RFC5681] which is one of the Fairhurst, et al. Expires June 9, 2017 [Page 37] Internet-Draft TAPS Transports December 2016 initial proposed schemes for TCP as well as TCP Cubic [I-D.ietf-tcpm-cubic] which is the default mechanism for TCP in Linux are two examples for window-based AIMD schemes. This approach is also used by DCCP CCID-2 for datagram congestion control. Some classes of applications prefer to use a transport service that allows sending at a more stable rate, that is slowly varied in response to congestion. Rate-based methods offer this type of congestion control and have been defined based on the loss ratio and observed round trip time, such as TFRC [RFC5348] and TFRC-SP [RFC4828]. These methods utilize a throughput equation to determine the maximum acceptable rate. Such methods are used with DCCP CCID-3 [RFC4342] and CCID-4 [RFC5622], WEBRC [RFC3738], and other applications. Another class of applications prefer a transport service that yields to other (higher-priority) traffic, such as interactive transmissions. While most traffic in the Internet uses loss-based congestion control and therefore tends to fill the network buffers (to a certain level if Active Queue Management (AQM) is used), low- priority congestion control methods often react to changes in delay as an earlier indication of congestion. This approach tends to induce less loss than a loss-based method but does generally not compete well with loss-based traffic across shared bottleneck links. Therefore, methods such as LEDBAT [RFC6824], are deployed in the Internet for scavenger traffic that aim to only utilize otherwise unused capacity. 5. Transport Features The transport protocol features described in this document can be used as a basis for defining common transport features, listed below with the protocols supporting them: o Control Functions * Addressing + unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP, HTTP, ICMP) + multicast (UDP, UDP-Lite, RTP, ICMP, FLUTE/ALC, NORM). Note that, as TLS and DTLS are unicast-only, there is no widely deployed mechanism for supporting the features in the Security section below when using multicast addressing. + IPv4 broadcast (UDP, UDP-Lite, ICMP) Fairhurst, et al. Expires June 9, 2017 [Page 38] Internet-Draft TAPS Transports December 2016 + anycast (UDP, UDP-Lite). Connection-oriented protocols such as TCP and DCCP have also been deployed using anycast addressing, with the risk that routing changes may cause connection failure. * Association type + connection-oriented (TCP, MPTCP, DCCP, SCTP, TLS, RTP, HTTP, NORM) + connectionless (UDP, UDP-Lite, FLUTE/ALC) * Multihoming support + resilience and mobility (MPTCP, SCTP) + load-balancing (MPTCP) + address family multiplexing (MPTCP, SCTP) * Middlebox cooperation + application-class signaling to middleboxes (DCCP) + error condition signaling from middleboxes and routers to endpoints (ICMP) * Signaling + control information and error signaling (ICMP) + application performance reporting (RTP) o Delivery * Reliability + fully reliable delivery (TCP, MPTCP, SCTP, TLS, HTTP, FLUTE/ ALC, NORM) + partially reliable delivery (SCTP, NORM) - using packet erasure coding (RTP, FLUTE/ALC, NORM) - with specified policy for dropped messages (SCTP) + unreliable delivery (SCTP, UDP, UDP-Lite, DCCP, RTP) Fairhurst, et al. Expires June 9, 2017 [Page 39] Internet-Draft TAPS Transports December 2016 - with drop notification to sender (SCTP, DCCP, RTP) + error detection - checksum for error detection (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, DTLS, FLUTE/ALC, NORM, ICMP) - partial payload checksum protection (UDP-Lite, DCCP). Some uses of RTP can exploit partial payload checksum protection feature to provide a corruption tolerant transport service. - checksum optional (UDP). Possible with IPv4 and in certain cases with IPv6. * Ordering + ordered delivery (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE) + unordered delivery permitted (UDP, UDP-Lite, SCTP, DCCP, RTP, NORM) * Type/framing + stream-oriented delivery (TCP, MPTCP, SCTP, TLS, HTTP) - with multiple streams per association (SCTP, HTTP2) + message-oriented delivery (UDP, UDP-Lite, SCTP, DCCP, DTLS, RTP) + object-oriented delivery of discrete data or files and associated metadata (HTTP, FLUTE/ALC, NORM) - with partial delivery of object ranges (HTTP) * Directionality + unidirectional (UDP, UDP-Lite, DCCP, RTP, FLUTE/ALC, NORM) + bidirectional (TCP, MPTCP, SCTP, TLS, HTTP) o Transmission control * flow control (TCP, MPTCP, SCTP, DCCP, TLS, RTP, HTTP) Fairhurst, et al. Expires June 9, 2017 [Page 40] Internet-Draft TAPS Transports December 2016 * congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, NORM). Congestion control can also provided by the transport supporting an upper later transport (e.g., TLS, RTP, HTTP). * segmentation (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE/ALC, NORM) * data/message bundling (TCP, MPTCP, SCTP, TLS, HTTP) * stream scheduling prioritization (SCTP, HTTP2) * endpoint multiplexing (MPTCP) o Security * authentication of one end of a connection (TLS, DTLS, FLUTE/ ALC) * authentication of both ends of a connection (TLS, DTLS) * confidentiality (TLS, DTLS) * cryptographic integrity protection (TLS, DTLS) * replay protection (TLS, DTLS, FLUTE/ALC) 6. IANA Considerations This document has no considerations for IANA. 7. Security Considerations This document surveys existing transport protocols and protocols providing transport-like services. Confidentiality, integrity, and authenticity are among the features provided by those services. This document does not specify any new features or mechanisms for providing these features. Each RFC referenced by this document discusses the security considerations of the specification it contains. 8. Contributors In addition to the editors, this document is the work of Brian Adamson, Dragana Damjanovic, Kevin Fall, Simone Ferlin-Oliviera, Ralph Holz, Olivier Mehani, Karen Nielsen, Colin Perkins, Vincent Roca, and Michael Tuexen. Fairhurst, et al. Expires June 9, 2017 [Page 41] Internet-Draft TAPS Transports December 2016 o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera (ferlin@simula.no) and Olivier Mehani (olivier.mehani@nicta.com.au) o Section 3.3 on UDP was contributed by Kevin Fall (kfall@kfall.com) o Section 3.5 on SCTP was contributed by Michael Tuexen (tuexen@fh- muenster.de) and Karen Nielsen (karen.nielsen@tieto.com) o Section 3.7 on TLS and DTLS was contributed by Ralph Holz (ralph.holz@nicta.com.au) and Olivier Mehani (olivier.mehani@nicta.com.au) o Section 3.8 on RTP contains contributions from Colin Perkins (csp@csperkins.org) o Section 3.9 on HTTP was contributed by Dragana Damjanovic (ddamjanovic@mozilla.com) o Section 3.10 on FLUTE/ALC was contributed by Vincent Roca (vincent.roca@inria.fr) o Section 3.11 on NORM was contributed by Brian Adamson (brian.adamson@nrl.navy.mil) 9. Acknowledgments Thanks to Joe Touch, Michael Welzl, Spencer Dawkins, and the TAPS Working Group for the comments, feedback, and discussion. This work is supported by the European Commission under grant agreement No. 318627 mPlane and from the Horizon 2020 research and innovation program under grant agreements No. 644334 (NEAT) and No. 688421 (MAMI). This support does not imply endorsement. 10. Informative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . Fairhurst, et al. Expires June 9, 2017 [Page 42] Internet-Draft TAPS Transports December 2016 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, . [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, DOI 10.17487/RFC2461, December 1998, . Fairhurst, et al. Expires June 9, 2017 [Page 43] Internet-Draft TAPS Transports December 2016 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, . [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, . [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, DOI 10.17487/RFC3205, February 2002, . [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, . [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, DOI 10.17487/RFC3436, December 2002, . [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, DOI 10.17487/RFC3450, December 2002, . [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, DOI 10.17487/RFC3452, December 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . Fairhurst, et al. Expires June 9, 2017 [Page 44] Internet-Draft TAPS Transports December 2016 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/RFC3738, April 2004, . [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, . [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, . [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, DOI 10.17487/RFC3926, October 2004, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December 2005, . [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement for the Datagram Congestion Control Protocol (DCCP)", RFC 4336, DOI 10.17487/RFC4336, March 2006, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, . Fairhurst, et al. Expires June 9, 2017 [Page 45] Internet-Draft TAPS Transports December 2016 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, . [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, DOI 10.17487/RFC4828, April 2007, . [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, . Fairhurst, et al. Expires June 9, 2017 [Page 46] Internet-Draft TAPS Transports December 2016 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, DOI 10.17487/RFC5238, May 2008, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, . [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, . [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/ Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, September 2009, . [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, . [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, DOI 10.17487/RFC5651, October 2009, . [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, DOI 10.17487/RFC5672, August 2009, . Fairhurst, et al. Expires June 9, 2017 [Page 47] Internet-Draft TAPS Transports December 2016 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, . [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, . [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, . [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, . [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, . Fairhurst, et al. Expires June 9, 2017 [Page 48] Internet-Draft TAPS Transports December 2016 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, . [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, . [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, DOI 10.17487/RFC6582, April 2012, . [RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, DOI 10.17487/RFC6584, April 2012, . [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, . [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, . [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, . Fairhurst, et al. Expires June 9, 2017 [Page 49] Internet-Draft TAPS Transports December 2016 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, . [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, . [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, . [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, . Fairhurst, et al. Expires June 9, 2017 [Page 50] Internet-Draft TAPS Transports December 2016 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, . [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, . [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . Fairhurst, et al. Expires June 9, 2017 [Page 51] Internet-Draft TAPS Transports December 2016 [I-D.ietf-tsvwg-rfc5405bis] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", draft-ietf-tsvwg-rfc5405bis-16 (work in progress), July 2016. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-09 (work in progress), January 2015. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", draft-ietf-tsvwg- sctp-ndata-07 (work in progress), July 2016. [I-D.ietf-tsvwg-natsupp] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", draft-ietf-tsvwg-natsupp-09 (work in progress), May 2016. [I-D.ietf-tcpm-cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", draft-ietf-tcpm-cubic-02 (work in progress), August 2016. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-15 (work in progress), August 2016. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-14 (work in progress), July 2016. [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, "XMLHttpRequest working draft (http://www.w3.org/TR/XMLHttpRequest/)", 2000. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Ph. D. (UC Irvine), Chapter 5: Representational State Transfer", 2000. [POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX) Base Specifications, Issue 7", n.d.. Fairhurst, et al. Expires June 9, 2017 [Page 52] Internet-Draft TAPS Transports December 2016 [MBMS] 3GPP TSG WS S4, ., "3GPP TS 26.346: Multimedia Broadcast/ Multicast Service (MBMS); Protocols and codecs, release 13 (http://www.3gpp.org/DynaReport/26346.htm).", 2015. [ClarkArch] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols (Proc. ACM SIGCOMM)", 1990. Authors' Addresses Godred Fairhurst (editor) University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE Email: gorry@erg.abdn.ac.uk Brian Trammell (editor) ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Email: ietf@trammell.ch Mirja Kuehlewind (editor) ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Email: mirja.kuehlewind@tik.ee.ethz.ch Fairhurst, et al. Expires June 9, 2017 [Page 53] ./draft-ietf-tsvwg-circuit-breaker-15.txt0000664000764400076440000020345212700451400017602 0ustar iustyiusty TSVWG Working Group G. Fairhurst Internet-Draft University of Aberdeen Intended status: Best Current Practice April 04, 2016 Expires: October 6, 2016 Network Transport Circuit Breakers draft-ietf-tsvwg-circuit-breaker-15 Abstract This document explains what is meant by the term "network transport Circuit Breaker" (CB). It describes the need for circuit breakers for network tunnels and applications when using non-congestion- controlled traffic, and explains where circuit breakers are, and are not, needed. It also defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 6, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Fairhurst Expires October 6, 2016 [Page 1] Internet-Draft April 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Types of Circuit Breaker . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design of a Circuit-Breaker (What makes a good circuit breaker?) . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Functional Components . . . . . . . . . . . . . . . . . . 7 3.2. Other network topologies . . . . . . . . . . . . . . . . 10 3.2.1. Use with a multicast control/routing protocol . . . . 10 3.2.2. Use with control protocols supporting pre-provisioned capacity . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Unidirectional Circuit Breakers over Controlled Paths 12 4. Requirements for a Network Transport Circuit Breaker . . . . 12 5. Examples of Circuit Breakers . . . . . . . . . . . . . . . . 15 5.1. A Fast-Trip Circuit Breaker . . . . . . . . . . . . . . . 15 5.1.1. A Fast-Trip Circuit Breaker for RTP . . . . . . . . . 16 5.2. A Slow-trip Circuit Breaker . . . . . . . . . . . . . . . 17 5.3. A Managed Circuit Breaker . . . . . . . . . . . . . . . . 17 5.3.1. A Managed Circuit Breaker for SAToP Pseudo-Wires . . 17 5.3.2. A Managed Circuit Breaker for Pseudowires (PWs) . . . 18 6. Examples where circuit breakers may not be needed. . . . . . 19 6.1. CBs over pre-provisioned Capacity . . . . . . . . . . . . 19 6.2. CBs with tunnels carrying Congestion-Controlled Traffic . 19 6.3. CBs with Uni-directional Traffic and no Control Path . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Revision Notes . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction The term "Circuit Breaker" originates in electricity supply, and has nothing to do with network circuits or virtual circuits. In electricity supply, a Circuit Breaker is intended as a protection mechanism of last resort. Under normal circumstances, a Circuit Breaker ought not to be triggered; it is designed to protect the supply network and attached equipment when there is overload. People do not expect an electrical circuit-breaker (or fuse) in their home to be triggered, except when there is a wiring fault or a problem with an electrical appliance. Fairhurst Expires October 6, 2016 [Page 2] Internet-Draft April 2016 In networking, the Circuit Breaker (CB) principle can be used as a protection mechanism of last resort to avoid persistent excessive congestion impacting other flows that share network capacity. Persistent congestion was a feature of the early Internet of the 1980s. This resulted in excess traffic starving other connections from access to the Internet. It was countered by the requirement to use congestion control (CC) in the Transmission Control Protocol (TCP) [Jacobsen88]. These mechanisms operate in Internet hosts to cause TCP connections to "back off" during congestion. The addition of a congestion control to TCP (currently documented in [RFC5681] ensured the stability of the Internet, because it was able to detect congestion and promptly react. This was effective in an Internet where most TCP flows were long-lived (ensuring that they could detect and respond to congestion before the flows terminated). Although TCP was by far the dominant traffic, this is no longer the always the case, and non-congestion-controlled traffic, including many applications using the User Datagram Protocol (UDP), can form a significant proportion of the total traffic traversing a link. The current Internet therefore requires that non-congestion-controlled traffic is considered to avoid persistent excessive congestion. A network transport Circuit Breaker is an automatic mechanism that is used to continuously monitor a flow or aggregate set of flows. The mechanism seeks to detect when the flow(s) experience persistent excessive congestion. When this is detected, a Circuit Breaker terminates (or significantly reduce the rate of) the flow(s). This is a safety measure to prevent starvation of network resources denying other flows from access to the Internet. Such measures are essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance. Avoiding persistent excessive congestion is important to reduce the potential for "Congestion Collapse" [RFC2914]. There are important differences between a transport Circuit Breaker and a congestion control method. Congestion control (as implemented in TCP, SCTP, and DCCP) operates on a timescale on the order of a packet round-trip-time (RTT), the time from sender to destination and return. Congestion at a network link can also be detected using Explicit Congestion Notification (ECN) [RFC3168], which allows the network to signal congestion by marking ECN-capable packets with a Congestion Experienced (CE) mark. Both loss and reception of CE- marked packets are treated as congestion events. Congestion control methods are able to react to a congestion event by continuously adapting to reduce their transmission rate. The goal is usually to limit the transmission rate to a maximum rate that reflects a fair use of the available capacity across a network path. These methods typically operate on individual traffic flows (e.g., a 5-tuple that includes the IP addresses, protocol, and ports). Fairhurst Expires October 6, 2016 [Page 3] Internet-Draft April 2016 In contrast, Circuit Breakers are recommended for non-congestion- controlled Internet flows and for traffic aggregates, e.g., traffic sent using a network tunnel. They operate on timescales much longer than the packet RTT, and trigger under situations of abnormal (excessive) congestion. People have been implementing what this document characterizes as circuit breakers on an ad hoc basis to protect Internet traffic. This document therefore provides guidance on how to deploy and use these mechanisms. Later sections provide examples of cases where circuit-breakers may or may not be desirable. A Circuit Breaker needs to measure (meter) some portion of the traffic to determine if the network is experiencing congestion and needs to be designed to trigger robustly when there is persistent excessive congestion. A Circuit Breaker trigger will often utilize a series of successive sample measurements metered at an ingress point and an egress point (either of which could be a transport endpoint). The trigger needs to operate on a timescale much longer than the path round trip time (e.g., seconds to possibly many tens of seconds). This longer period is needed to provide sufficient time for transport congestion control (or applications) to adjust their rate following congestion, and for the network load to stabilize after any adjustment. Congestion events can be common when a congestion-controlled transport is used over a network link operating near capacity. Each event results in reduction in the rate of the transport flow experiencing congestion. The longer period seeks to ensure that a Circuit Breaker does not accidentally trigger following a single (or even successive) congestion events. Once triggered, the Circuit Breaker needs to provide a control function (called the "reaction"). This removes traffic from the network, either by disabling the flow or by significantly reducing the level of traffic. This reaction provides the required protection to prevent persistent excessive congestion being experienced by other flows that share the congested part of the network path. Section 4 defines requirements for building a Circuit Breaker. The operational conditions that cause a Circuit Breaker to trigger ought to be regarded as abnormal. Examples of situations that could trigger a Circuit Breaker include: o anomalous traffic that exceeds the provisioned capacity (or whose traffic characteristics exceed the threshold configured for the Circuit Breaker); Fairhurst Expires October 6, 2016 [Page 4] Internet-Draft April 2016 o traffic generated by an application at a time when the provisioned network capacity is being utilised for other purposes; o routing changes that cause additional traffic to start using the path monitored by the Circuit Breaker; o misconfiguration of a service/network device where the capacity available is insufficient to support the current traffic aggregate; o misconfiguration of an admission controller or traffic policer that allows more traffic than expected across the path monitored by the Circuit Breaker. Other mechanisms could also be available to network operators to detect excessive congestion (e.g., an observation of excessive utilisation for a port on a network device). Utilising such information, operational mechanisms could react to reduce network load over a shorter timescale than those of a network transport Circuit Breaker. The role of the Circuit Breaker over such paths remains as a method of last resort. Because it acts over a longer timescale, the Circuit Breaker ought to trigger only when other reactions did not succeed in reducing persistent excessive congestion. In many cases, the reason for triggering a Circuit Breaker will not be evident to the source of the traffic (user, application, endpoint, etc). A Circuit Breaker can be used to limit traffic from applications that are unable, or choose not, to use congestion control, or where the congestion control properties of the traffic cannot be relied upon (e.g., traffic carried over a network tunnel). In such circumstances, it is all but impossible for the Circuit Breaker to signal back to the impacted applications. In some cases applications could therefore have difficulty in determining that a Circuit Breaker has triggered, and where in the network this happened. Application developers are therefore advised, where possible, to deploy appropriate congestion control mechanisms. An application that uses congestion control will be aware of congestion events in the network. This allows it to regulate the network load under congestion, and is expected to avoid triggering a network Circuit Breaker. For applications that can generate elastic traffic, this will often be a preferred solution. Fairhurst Expires October 6, 2016 [Page 5] Internet-Draft April 2016 1.1. Types of Circuit Breaker There are various forms of network transport circuit breaker. These are differentiated mainly on the timescale over which they are triggered, but also in the intended protection they offer: o Fast-Trip Circuit Breakers: The relatively short timescale used by this form of circuit breaker is intended to provide protection for network traffic from a single flow or related group of flows. o Slow-Trip Circuit Breakers: This circuit breaker utilizes a longer timescale and is designed to protect network traffic from congestion by traffic aggregates. o Managed Circuit Breakers: Utilize the operations and management functions that might be present in a managed service to implement a circuit breaker. Examples of each type of circuit breaker are provided in section 4. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Design of a Circuit-Breaker (What makes a good circuit breaker?) Although circuit breakers have been talked about in the IETF for many years, there has not yet been guidance on the cases where circuit breakers are needed or upon the design of circuit breaker mechanisms. This document seeks to offer advice on these two topics. Circuit Breakers are RECOMMENDED for IETF protocols and tunnels that carry non-congestion-controlled Internet flows and for traffic aggregates. This includes traffic sent using a network tunnel. Designers of other protocols and tunnel encapsulations also ought to consider the use of these techniques as a last resort to protect traffic that shares the network path being used. This document defines the requirements for design of a Circuit Breaker and provides examples of how a Circuit Breaker can be constructed. The specifications of individual protocols and tunnel encapsulations need to detail the protocol mechanisms needed to implement a Circuit Breaker. Fairhurst Expires October 6, 2016 [Page 6] Internet-Draft April 2016 Section 3.1 describes the functional components of a circuit breaker and section 3.2 defines requirements for implementing a Circuit Breaker. 3.1. Functional Components The basic design of a Circuit Breaker involves communication between an ingress point (a sender) and an egress point (a receiver) of a network flow or set of flows. A simple picture of operation is provided in figure 1. This shows a set of routers (each labelled R) connecting a set of endpoints. A Circuit Breaker is used to control traffic passing through a subset of these routers, acting between the ingress and a egress point network devices. The path between the ingress and egress could be provided by a tunnel or other network-layer technique. One expected use would be at the ingress and egress of a service, where all traffic being considered terminates beyond the egress point, and hence the ingress and egress carry the same set of flows. +--------+ +--------+ |Endpoint| |Endpoint| +--+-----+ >>> circuit breaker traffic >>> +--+-----+ | | | +-+ +-+ +---------+ +-+ +-+ +-+ +--------+ +-+ +-+ | +-+R+--+R+->+ Ingress +--+R+--+R+--+R+--+ Egress |--+R+--+R+-+ +++ +-+ +------+--+ +-+ +-+ +-+ +-----+--+ +++ +-+ | ^ | | | | | +--+------+ +------+--+ | | | | Ingress | | Egress | | | | | Meter | | Meter | | | | +----+----+ +----+----+ | | | | | | +-+ | | +----+----+ | | +-+ |R+--+ | | Measure +<----------------+ +--+R| +++ | +----+----+ Reported +++ | | | Egress | | | +----+----+ Measurement | +--+-----+ | | Trigger + +--+-----+ |Endpoint| | +----+----+ |Endpoint| +--------+ | | +--------+ +---<---+ Reaction Figure 1: A CB controlling the part of the end-to-end path between an ingress point and an egress point. (Note: In some cases, the trigger Fairhurst Expires October 6, 2016 [Page 7] Internet-Draft April 2016 and measurement functions could alternatively be located at other locations (e.g., at a network operations centre.) In the context of a Circuit Breaker, the ingress and egress functions could be implemented in different places. For example, they could be located in network devices at a tunnel ingress and at the tunnel egress. In some cases, they could be located at one or both network endpoints (see figure 2), implemented as components within a transport protocol. +----------+ +----------+ | Ingress | +-+ +-+ +-+ | Egress | | Endpoint +->+R+--+R+--+R+--+ Endpoint | +--+----+--+ +-+ +-+ +-+ +----+-----+ ^ | | | +--+------+ +----+----+ | | Ingress | | Egress | | | Meter | | Meter | | +----+----+ +----+----+ | | | | +--- +----+ | | | Measure +<-----------------+ | +----+----+ Reported | | Egress | +----+----+ Measurement | | Trigger | | +----+----+ | | +---<--+ Reaction Figure 2: An endpoint CB implemented at the sender (ingress) and receiver (egress). The set of components needed to implement a Circuit Breaker are: 1. An ingress meter (at the sender or tunnel ingress) that records the number of packets/bytes sent in each measurement interval. This measures the offered network load for a flow or set of flows. For example, the measurement interval could be many seconds (or every few tens of seconds or a series of successive shorter measurements that are combined by the Circuit Breaker Measurement function). 2. An egress meter (at the receiver or tunnel egress) that records the number/bytes received in each measurement interval. This measures the supported load for the flow or set of flows, and Fairhurst Expires October 6, 2016 [Page 8] Internet-Draft April 2016 could utilize other signals to detect the effect of congestion (e.g., loss/congestion marking [RFC3168] experienced over the path). The measurements at the egress could be synchronised (including an offset for the time of flight of the data, or referencing the measurements to a particular packet) to ensure any counters refer to the same span of packets. 3. A method that communicates the measured values at the ingress and egress to the Circuit Breaker Measurement function. This could use several methods including: Sending return measurement packets (or control messages) from a receiver to a trigger function at the sender; an implementation using Operations, Administration and Management (OAM); or sending an in-band signalling datagram to the trigger function. This could also be implemented purely as a control plane function, e.g., using a software-defined network controller. 4. A measurement function that combines the ingress and egress measurements to assess the present level of network congestion. (For example, the loss rate for each measurement interval could be deduced from calculating the difference between ingress and egress counter values.) Note the method does not require high accuracy for the period of the measurement interval (or therefore the measured value, since isolated and/or infrequent loss events need to be disregarded.) 5. A trigger function that determines whether the measurements indicate persistent excessive congestion. This function defines an appropriate threshold for determining that there is persistent excessive congestion between the ingress and egress. This preferably considers a rate or ratio, rather than an absolute value (e.g., more than 10% loss, but other methods could also be based on the rate of transmission as well as the loss rate). The Circuit Breaker is triggered when the threshold is exceeded in multiple measurement intervals (e.g., 3 successive measurements). Designs need to be robust so that single or spurious events do not trigger a reaction. 6. A reaction that is applied at the Ingress when the Circuit Breaker is triggered. This seeks to automatically remove the traffic causing persistent excessive congestion. 7. A feedback control mechanism that triggers when either the receive or ingress and egress measurements are not available, since this also could indicate a loss of control packets (also a symptom of heavy congestion or inability to control the load). Fairhurst Expires October 6, 2016 [Page 9] Internet-Draft April 2016 3.2. Other network topologies A Circuit Breaker can be deployed in networks with topologies different to that presented in figures 1 and 2. This section describes examples of such usage, and possible places where functions can be implemented. 3.2.1. Use with a multicast control/routing protocol +----------+ +--------+ +----------+ | Ingress | +-+ +-+ +-+ | Egress | | Egress | | Endpoint +->+R+--+R+--+R+--+ Router |--+ Endpoint +->+ +----+-----+ +-+ +-+ +-+ +---+--+-+ +----+-----+ | ^ ^ ^ ^ | ^ | | | | | | | | | | +----+----+ + - - - < - - - - + | +----+----+ | Reported | Ingress | multicast Prune | | Egress | | Ingress | Meter | | | Meter | | Measurement +---------+ | +----+----+ | | | | | +----+----+ | | | Measure +<--+ | +----+----+ | | | +----+----+ multicast | | Trigger | Leave | +----+----+ Message | | +----<----+ Figure 3: An example of a multicast CB controlling the end-to-end path between an ingress endpoint and an egress endpoint. Figure 3 shows one example of how a multicast Circuit Breaker could be implemented at a pair of multicast endpoints (e.g., to implement a Fast-Trip Circuit Breaker, Section 5.1). The ingress endpoint (the sender that sources the multicast traffic) meters the ingress load, generating an ingress measurement (e.g., recording timestamped packet counts), and sends this measurement to the multicast group together with the traffic it has measured. Routers along a multicast path forward the multicast traffic (including the ingress measurement) to all active endpoint receivers. Each last hop (egress) router forwards the traffic to one or more egress endpoint(s). Fairhurst Expires October 6, 2016 [Page 10] Internet-Draft April 2016 In this figure, each endpoint includes a meter that performs a local egress load measurement. An endpoint also extracts the received ingress measurement from the traffic, and compares the ingress and egress measurements to determine if the Circuit Breaker ought to be triggered. This measurement has to be robust to loss (see previous section). If the Circuit Breaker is triggered, it generates a multicast leave message for the egress (e.g., an IGMP or MLD message sent to the last hop router), which causes the upstream router to cease forwarding traffic to the egress endpoint [RFC1112]. Any multicast router that has no active receivers for a particular multicast group will prune traffic for that group, sending a prune message to its upstream router. This starts the process of releasing the capacity used by the traffic and is a standard multicast routing function (e.g., using Protocol Independent Multicast Sparse Mode (PIM-SM) routing protocol [RFC4601]). Each egress operates autonomously, and the Circuit Breaker "reaction" is executed by the multicast control plane (e.g., by PIM) requiring no explicit signalling by the Circuit Breaker along the communication path used for the control messages. Note: there is no direct communication with the Ingress, and hence a triggered Circuit Breaker only controls traffic downstream of the first hop multicast router. It does not stop traffic flowing from the sender to the first hop router; this is common practice for multicast deployment. The method could also be used with a multicast tunnel or subnetwork (e.g., Section 5.2, Section 5.3), where a meter at the ingress generates additional control messages to carry the measurement data towards the egress where the egress metering is implemented. 3.2.2. Use with control protocols supporting pre-provisioned capacity Some paths are provisioned using a control protocol, e.g., flows provisioned using the Multi-Protocol Label Switching (MPLS) services, paths provisioned using the resource reservation protocol (RSVP), networks utilizing Software Defined Network (SDN) functions, or admission-controlled Differentiated Services. Figure 1 shows one expected use case, where in this usage a separate device could be used to perform the measurement and trigger functions. The reaction generated by the trigger could take the form of a network control message sent to the ingress and/or other network elements causing these elements to react to the Circuit Breaker. Examples of this type of use are provided in section Section 5.3. Fairhurst Expires October 6, 2016 [Page 11] Internet-Draft April 2016 3.2.3. Unidirectional Circuit Breakers over Controlled Paths A Circuit Breaker can be used to control uni-directional UDP traffic, providing that there is a communication path that can be used for control messages to connect the functional components at the Ingress and Egress. This communication path for the control messages can exist in networks for which the traffic flow is purely unidirectional. For example, a multicast stream that sends packets across an Internet path and can use multicast routing to prune flows to shed network load. Some other types of subnetwork also utilize control protocols that can be used to control traffic flows. 4. Requirements for a Network Transport Circuit Breaker The requirements for implementing a Circuit Breaker are: 1. There needs to be a communication path for control messages to carry measurement data from the ingress meter and from the egress meter to the point of measurement. (Requirements 16-18 relate to the transmission of control messages.) 2. A CB is REQUIRED to define a measurement period over which the CB Measurement function measures the level of congestion or loss. This method does not have to detect individual packet loss, but MUST have a way to know that packets have been lost/ marked from the traffic flow. 3. An egress meter can also count ECN [RFC3168] congestion marks as a part of measurement of congestion, but in this case, loss MUST also be measured to provide a complete view of the level of congestion. For tunnels, [ID-ietf-tsvwg-tunnel-congestion-feedback] describes a way to measure both loss and ECN-marking; these measurements could be used on a relatively short timescale to drive a congestion control response and/or aggregated over a longer timescale with a higher trigger threshold to drive a CB. Subsequent bullet items in this section discuss the necessity of using a longer timescale and a higher trigger threshold. 4. The measurement period used by a CB Measurement function MUST be longer than the time that current Congestion Control algorithms need to reduce their rate following detection of congestion. This is important because end-to-end Congestion Control algorithms require at least one RTT to notify and adjust the traffic when congestion is experienced, and congestion bottlenecks can share traffic with a diverse range of RTTs. The measurement period is therefore expected to be significantly longer than the RTT experienced by the CB itself. Fairhurst Expires October 6, 2016 [Page 12] Internet-Draft April 2016 5. If necessary, a CB MAY combine successive individual meter samples from the ingress and egress to ensure observation of an average measurement over a sufficiently long interval. (Note when meter samples need to be combined, the combination needs to reflect the sum of the individual sample counts divided by the total time/volume over which the samples were measured. Individual samples over different intervals can not be directly combined to generate an average value.) 6. A CB MUST be constructed so that it does not trigger under light or intermittent congestion (see requirements 7-9). 7. A CB is REQUIRED to define a threshold to determine whether the measured congestion is considered excessive. 8. A CB is REQUIRED to define the triggering interval, defining the period over which the trigger uses the collected measurements. CBs need to trigger over a sufficiently long period to avoid additionally penalizing flows with a long path RTT (e.g., many path RTTs). 9. A CB MUST be robust to multiple congestion events. This usually will define a number of measured persistent congestion events per triggering period. For example, a CB MAY combine the results of several measurement periods to determine if the CB is triggered (e.g., it is triggered when persistent excessive congestion is detected in 3 of the measurements within the triggering interval). 10. The normal reaction to a trigger SHOULD disable all traffic that contributed to congestion (otherwise, see requirements 11,12). 11. The reaction MUST be much more severe than that of a Congestion Control algorithm (such as TCP's congestion control [RFC5681] or TCP-Friendly Rate Control, TFRC [RFC5348]), because the CB reacts to more persistent congestion and operates over longer timescales (i.e., the overload condition will have persisted for a longer time before the CB is triggered). 12. A reaction that results in a reduction SHOULD result in reducing the traffic by at least an order of magnitude. A response that achieves the reduction by terminating flows, rather than randomly dropping packets, will often be more desirable to users of the service. A CB that reduces the rate of a flow, MUST continue to monitor the level of congestion and MUST further react to reduce the rate if the CB is again triggered. Fairhurst Expires October 6, 2016 [Page 13] Internet-Draft April 2016 13. The reaction to a triggered CB MUST continue for a period that is at least the triggering interval. Operator intervention will usually be required to restore a flow. If an automated response is needed to reset the trigger, then this needs to not be immediate. The design of an automated reset mechanism needs to be sufficiently conservative that it does not adversely interact with other mechanisms (including other CB algorithms that control traffic over a common path). It SHOULD NOT perform an automated reset when there is evidence of continued congestion. 14. A CB trigger SHOULD be regarded as an abnormal network event. As such, this event SHOULD be logged. The measurements that lead to triggering of the CB SHOULD also be logged. 15. The control communication needs to carry measurements (requirement 1) and, in some uses, also needs to transmit trigger messages to the ingress. This control communication may be in-band or out-of-band. The use of in-band communication is RECOMMENDED when either design would be possible. The preferred CB design is one that triggers when it fails to receive measurement reports that indicate an absence of congestion, in contrast to relying on the successful transmission of a "congested" signal back to the sender. (The feedback signal could itself be lost under congestion). in-Band: An in-band control method SHOULD assume that loss of control messages is an indication of potential congestion on the path, and repeated loss ought to cause the CB to be triggered. This design has the advantage that it provides fate-sharing of the traffic flow(s) and the control communications. This fate-sharing property is weaker when some or all of the measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic and control messages follow a different path due to use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic). Out-of-Band: An out-of-band control method SHOULD NOT trigger CB reaction when there is loss of control messages (e.g., a loss of measurements). This avoids failure amplification/ propagation when the measurement and data paths fail independently. A failure of an out-of-band communication path SHOULD be regarded as abnormal network event and be handled as appropriate for the network, e.g., this event SHOULD be logged, and additional network operator action might be appropriate, depending on the network and the traffic involved. Fairhurst Expires October 6, 2016 [Page 14] Internet-Draft April 2016 16. The control communication MUST be designed to be robust to packet loss. A control message can be lost if there is a failure of the communication path used for the control messages, loss is likely to also be experienced during congestion/ overload. This does not imply that it is desirable to provide reliable delivery (e.g., over TCP), since this can incur additional delay in responding to congestion. Appropriate mechanisms could be to duplicate control messages to provide increased robustness to loss, or/and to regard a lack of control traffic as an indication that excessive congestion could be being experienced [ID-ietf-tsvwg-RFC5405.bis]. If control messages traffic are sent over a shared path, it is RECOMMENDED that this control traffic is prioritized to reduce the probability of loss under congestion. Control traffic also needs to be considered when provisioning a network that uses a Circuit Breaker. 17. There are security requirements for the control communication between endpoints and/or network devices (Section 7). The authenticity of the source and integrity of the control messages (measurements and triggers) MUST be protected from off-path attacks. When there is a risk of on-path attack, a cryptographic authentication mechanism for all control/ measurement messages is RECOMMENDED. 5. Examples of Circuit Breakers There are multiple types of Circuit Breaker that could be defined for use in different deployment cases. There could be cases where a flow become controlled by multiple Circuit Breakers (e.g., when the traffic of an end-to-end flow is carried in a tunnel within the network). This section provides examples of different types of Circuit Breaker: 5.1. A Fast-Trip Circuit Breaker [RFC2309] discusses the dangers of congestion-unresponsive flows and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms". Some applications do not use a full-featured transport (TCP, SCTP, DCCP). These applications (e.g., using UDP and its UDP-Lite variant) need to provide appropriate congestion avoidance. Guidance for applications that do not use congestion-controlled transports is provided in [ID-ietf-tsvwg-RFC5405.bis]. Such mechanisms can be designed to react on much shorter timescales than a Circuit Breaker, that only observes a traffic envelope. Congestion control methods can also interact with an application to more effectively control its sending rate. Fairhurst Expires October 6, 2016 [Page 15] Internet-Draft April 2016 A fast-trip Circuit Breaker is the most responsive form of Circuit Breaker. It has a response time that is only slightly larger than that of the traffic that it controls. It is suited to traffic with well-understood characteristics (and could include one or more trigger functions specifically tailored the type of traffic for which it is designed). It is not suited to arbitrary network traffic and could be unsuitable for traffic aggregates, since it could prematurely trigger (e.g., when the combined traffic from multiple congestion-controlled flows leads to short-term overload). Although the mechanisms can be implemented in RTP-aware network devices, these mechanisms are also suitable for implementation in endpoints (e.g., as a part of the transport system) where they can also compliment end-to-end congestion control methods. A shorter response time enables these mechanisms to triggers before other forms of Circuit Breaker (e.g., Circuit Breakers operating on traffic aggregates at a point along the network path). 5.1.1. A Fast-Trip Circuit Breaker for RTP A set of fast-trip Circuit Breaker methods have been specified for use together by a Real-time Transport Protocol (RTP) flow using the RTP/AVP Profile [RTP-CB]. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these Circuit Breakers. A fast-trip RTP Circuit Breaker is therefore implemented as a fail-safe that when triggered will terminate RTP traffic. The sending endpoint monitors reception of in-band RTP Control Protocol (RTCP) reception report blocks, as contained in SR or RR packets, that convey reception quality feedback information. This is used to measure (congestion) loss, possibly in combination with ECN [RFC6679]. The Circuit Breaker action (shutdown of the flow) is triggered when any of the following trigger conditions are true: 1. An RTP Circuit Breaker triggers on reported lack of progress. 2. An RTP Circuit Breaker triggers when no receiver reports messages are received. 3. An RTP Circuit Breaker triggers when the long-term RTP throughput (over many RTTs) exceeds a hard upper limit determined by a method that resembles TCP-Friendly Rate Control (TFRC). 4. An RTP Circuit Breaker includes the notion of Media Usability. This Circuit Breaker is triggered when the quality of the Fairhurst Expires October 6, 2016 [Page 16] Internet-Draft April 2016 transported media falls below some required minimum acceptable quality. 5.2. A Slow-trip Circuit Breaker A slow-trip Circuit Breaker could be implemented in an endpoint or network device. This type of Circuit Breaker is much slower at responding to congestion than a fast-trip Circuit Breaker. This is expected to be more common. One example where a slow-trip Circuit Breaker is needed is where flows or traffic-aggregates use a tunnel or encapsulation and the flows within the tunnel do not all support TCP-style congestion control (e.g., TCP, SCTP, TFRC), see [ID-ietf-tsvwg-RFC5405.bis] section 3.1.3. A use case is where tunnels are deployed in the general Internet (rather than "controlled environments" within an Internet service provider or enterprise network), especially when the tunnel could need to cross a customer access router. 5.3. A Managed Circuit Breaker A managed Circuit Breaker is implemented in the signalling protocol or management plane that relates to the traffic aggregate being controlled. This type of Circuit Breaker is typically applicable when the deployment is within a "controlled environment". A Circuit Breaker requires more than the ability to determine that a network path is forwarding data, or to measure the rate of a path - which are often normal network operational functions. There is an additional need to determine a metric for congestion on the path and to trigger a reaction when a threshold is crossed that indicates persistent excessive congestion. The control messages can use either in-band or out-of-band communications. 5.3.1. A Managed Circuit Breaker for SAToP Pseudo-Wires [RFC4553], SAToP Pseudo-Wires (PWE3), section 8 describes an example of a managed Circuit Breaker for isochronous flows. If such flows were to run over a pre-provisioned (e.g., Multi- Protocol Label Switching, MPLS) infrastructure, then it could be expected that the Pseudowire (PW) would not experience congestion, because a flow is not expected to either increase (or decrease) their rate. If, instead, PW traffic is multiplexed with other traffic over the general Internet, it could experience congestion. [RFC4553] states: "If SAToP PWs run over a PSN providing best-effort service, Fairhurst Expires October 6, 2016 [Page 17] Internet-Draft April 2016 they SHOULD monitor packet loss in order to detect "severe congestion". The currently recommended measurement period is 1 second, and the trigger operates when there are more than three measured Severely Errored Seconds (SES) within a period. If such a condition is detected, a SAToP PW ought to shut down bidirectionally for some period of time...". The concept was that when the packet loss ratio (congestion) level increased above a threshold, the PW was by default disabled. This use case considered fixed-rate transmission, where the PW had no reasonable way to shed load. The trigger needs to be set at the rate that the PW was likely to experience a serious problem, possibly making the service non- compliant. At this point, triggering the Circuit Breaker would remove the traffic preventing undue impact on congestion-responsive traffic (e.g., TCP). Part of the rationale, was that high loss ratios typically indicated that something was "broken" and ought to have already resulted in operator intervention, and therefore need to trigger this intervention. An operator-based response to triggering of a Circuit Breaker provides an opportunity for other action to restore the service quality, e.g., by shedding other loads or assigning additional capacity, or to consciously avoid reacting to the trigger while engineering a solution to the problem. This could require the trigger function to send a control message to a third location (e.g., a network operations centre, NOC) that is responsible for operation of the tunnel ingress, rather than the tunnel ingress itself. 5.3.2. A Managed Circuit Breaker for Pseudowires (PWs) Pseudowires (PWs) [RFC3985] have become a common mechanism for tunneling traffic, and could compete for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. [ID-ietf-pals-congcons] discusses congestion conditions that can arise when PWs compete with elastic (i.e., congestion responsive) network traffic (e.g, TCP traffic). Elastic PWs carrying IP traffic (see [RFC4488]) do not raise major concerns because all of the traffic involved responds, reducing the transmission rate when network congestion is detected. In contrast, inelastic PWs (e.g., a fixed bandwidth Time Division Multiplex, TDM) [RFC4553] [RFC5086] [RFC5087]) have the potential to harm congestion responsive traffic or to contribute to excessive congestion because inelastic PWs do not adjust their transmission rate in response to congestion. [ID-ietf-pals-congcons] analyses TDM Fairhurst Expires October 6, 2016 [Page 18] Internet-Draft April 2016 PWs, with an initial conclusion that a TDM PW operating with a degree of loss that could result in congestion-related problems is also operating with a degree of loss that results in an unacceptable TDM service. For that reason, the document suggests that a managed Circuit Breaker that shuts down a PW when it persistently fails to deliver acceptable TDM service is a useful means for addressing these congestion concerns. (See Appendix A of [ID-ietf-pals-congcons] for further discussion.) 6. Examples where circuit breakers may not be needed. A Circuit Breaker is not required for a single congestion-controlled flow using TCP, SCTP, TFRC, etc. In these cases, the congestion control methods are already designed to prevent persistent excessive congestion. 6.1. CBs over pre-provisioned Capacity One common question is whether a Circuit Breaker is needed when a tunnel is deployed in a private network with pre-provisioned capacity. In this case, compliant traffic that does not exceed the provisioned capacity ought not to result in persistent congestion. A Circuit Breaker will hence only be triggered when there is non-compliant traffic. It could be argued that this event ought never to happen - but it could also be argued that the Circuit Breaker equally ought never to be triggered. If a Circuit Breaker were to be implemented, it will provide an appropriate response if persistent congestion occurs in an operational network. Implementing a Circuit Breaker will not reduce the performance of the flows, but in the event that persistent excessive congestion occurs it protects network traffic that shares network capacity with these flows. It also protects network traffic from a failure when Circuit Breaker traffic is (re)routed to cause additional network load on a non-pre-provisioned path. 6.2. CBs with tunnels carrying Congestion-Controlled Traffic IP-based traffic is generally assumed to be congestion-controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. A question therefore arises when people deploy a tunnel that is thought to only carry an aggregate of TCP traffic (or traffic using some other congestion control method): Is there advantage in this case in using a Circuit Breaker? Fairhurst Expires October 6, 2016 [Page 19] Internet-Draft April 2016 TCP (and SCTP) traffic in a tunnel is expected to reduce the transmission rate when network congestion is detected. Other transports (e.g, using UDP) can employ mechanisms that are sufficient to address congestion on the path [ID-ietf-tsvwg-RFC5405.bis]. However, even if the individual flows sharing a tunnel each implement a congestion control mechanism, and individually reduce their transmission rate when network congestion is detected, the overall traffic resulting from the aggregate of the flows does not necessarily avoid persistent congestion. For instance, most congestion control mechanisms require long-lived flows to react to reduce the rate of a flow. An aggregate of many short flows could result in many flows terminating before they experience congestion. It is also often impossible for a tunnel service provider to know that the tunnel only contains congestion-controlled traffic (e.g., Inspecting packet headers might not be possible). Some IP-based applications might not implement adequate mechanisms to address congestion. The important thing to note is that if the aggregate of the traffic does not result in persistent excessive congestion (impacting other flows), then the Circuit Breaker will not trigger. This is the expected case in this context - so implementing a Circuit Breaker ought not to reduce performance of the tunnel, but in the event that persistent excessive congestion occurs the Circuit Breaker protects other network traffic that shares capacity with the tunnel traffic. 6.3. CBs with Uni-directional Traffic and no Control Path A one-way forwarding path could have no associated communication path for sending control messages, and therefore cannot be controlled using a Circuit Breaker (compare with Section 3.2.3). A one-way service could be provided using a path with dedicated pre- provisioned capacity that is not shared with other elastic Internet flows (i.e., flows that vary their rate). A forwarding path could also be shared with other flows. One way to mitigate the impact of traffic on the other flows is to manage the traffic envelope by using ingress policing. Supporting this type of traffic in the general Internet requires operator monitoring to detect and respond to persistent excessive congestion. 7. Security Considerations All Circuit Breaker mechanisms rely upon coordination between the ingress and egress meters and communication with the trigger function. This is usually achieved by passing network control information (or protocol messages) across the network. Timely operation of a Circuit Breaker depends on the choice of measurement period. If the receiver has an interval that is overly long, then Fairhurst Expires October 6, 2016 [Page 20] Internet-Draft April 2016 the responsiveness of the Circuit Breaker decreases. This impacts the ability of the Circuit Breaker to detect and react to congestion. If the interval is too short the Circuit Breaker could trigger prematurely resulting in insufficient time for other mechanisms to act, potentially resulting in unnecessary disruption to the service. A Circuit Breaker could potentially be exploited by an attacker to mount a Denial of Service (DoS) attack against the traffic being controlled by the Circuit Breaker. Mechanisms therefore need to be implemented to prevent attacks on the network control information that would result in DoS. The authenticity of the source and integrity of the control messages (measurements and triggers) MUST be protected from off-path attacks. Without protection, it could be trivial for an attacker to inject fake or modified control/measurement messages (e.g., indicating high packet loss rates) causing a Circuit Breaker to trigger and to therefore mount a DoS attack that disrupts a flow. Simple protection can be provided by using a randomized source port, or equivalent field in the packet header (such as the RTP SSRC value and the RTP sequence number) expected not to be known to an off-path attacker. Stronger protection can be achieved using a secure authentication protocol to mitigate this concern. An attack on the control messages is relatively easy for an attacker on the control path when the messages are neither encrypted nor authenticated. Use of a cryptographic authentication mechanism for all control/measurement messages is RECOMMENDED to mitigate this concern, and would also provide protection from off-path attacks. There is a design trade-off between the cost of introducing cryptographic security for control messages and the desire to protect control communication. For some deployment scenarios the value of additional protection from DoS attack will therefore lead to a requirement to authenticate all control messages. Transmission of network control messages consumes network capacity. This control traffic needs to be considered in the design of a Circuit Breaker and could potentially add to network congestion. If this traffic is sent over a shared path, it is RECOMMENDED that this control traffic is prioritized to reduce the probability of loss under congestion. Control traffic also needs to be considered when provisioning a network that uses a Circuit Breaker. The Circuit Breaker MUST be designed to be robust to packet loss that can also be experienced during congestion/overload. Loss of control messages could be a side-effect of a congested network, but also could arise from other causes Section 4. Fairhurst Expires October 6, 2016 [Page 21] Internet-Draft April 2016 The security implications depend on the design of the mechanisms, the type of traffic being controlled and the intended deployment scenario. Each design of a Circuit Breaker MUST therefore evaluate whether the particular Circuit Breaker mechanism has new security implications. 8. IANA Considerations This document makes no request from IANA. 9. Acknowledgments There are many people who have discussed and described the issues that have motivated this document. Contributions and comments included: Lars Eggert, Colin Perkins, David Black, Matt Mathis, Andrew McGregor, Bob Briscoe and Eliot Lear. This work was part- funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). 10. Revision Notes XXX RFC-Editor: Please remove this section prior to publication XXX Draft 00 This was the first revision. Help and comments are greatly appreciated. Draft 01 Contained clarifications and changes in response to received comments, plus addition of diagram and definitions. Comments are welcome. WG Draft 00 Approved as a WG work item on 28th Aug 2014. WG Draft 01 Incorporates feedback after Dallas IETF TSVWG meeting. This version is thought ready for WGLC comments. Definitions of abbreviations. WG Draft 02 Minor fixes for typos. Rewritten security considerations section. Fairhurst Expires October 6, 2016 [Page 22] Internet-Draft April 2016 WG Draft 03 Updates following WGLC comments (see TSV mailing list). Comments from C Perkins; D Black and off-list feedback. A clear recommendation of intended scope. Changes include: Improvement of language on timescales and minimum measurement period; clearer articulation of endpoint and multicast examples - with new diagrams; separation of the controlled network case; updated text on position of trigger function; corrections to RTP-CB text; clarification of loss v ECN metrics; checks against submission checklist 9use of keywords, added meters to diagrams). WG Draft 04 Added section on PW CB for TDM - a newly adopted draft (D. Black). WG Draft 05 Added clarifications requested during AD review. WG Draft 06 Fixed some remaining typos. Update following detailed review by Bob Briscoe, and comments by D. Black. WG Draft 07 Additional update following review by Bob Briscoe. WG Draft 08 Updated text on the response to lack of meter measurements with managed circuit breakers. Additional comments from Eliot Lear (APPs area). WG Draft 09 Updated text on applications from Eliot Lear. Additional feedback from Bob Briscoe. WG Draft 10 Fairhurst Expires October 6, 2016 [Page 23] Internet-Draft April 2016 Updated text following comments by D Black including a rewritten ECN requirements bullet with of a reference to a tunnel measurement method in [ID-ietf-tsvwg-tunnel-congestion-feedback]. WG Draft 11 Minor corrections after second WGLC. WG Draft 12 Update following Gen-ART, RTG, and OPS review comments. WG Draft 13 Fixed a typo. WG Draft 14 Update after IESG discussion, including: Reworded introduction. Added definition of ECN. Requirement Addressed inconsistency between requirements for control messages. - Removed a "MUST" - following WG feedback on a anearlier version of the draft that "SHOULD" is more appropriate. Addressed comment about grouping requirements to help show they were inter-related. This reordered some requirements. Reworded the security considerations. Corrections to wording to improve clarity. WG Draft 15 (incorporating pending corrections) Corrected /applications might be implement/applications might not implement/ Corrected /Inspecting packet headers could/Inspecting packet headers might/ Removed Requirement 9, now duplicated (and renumbered remaining items). Added "(See Appendix A of [ID-ietf-pals-congcons] for further discussion.)" to end of 5.3.2 - missed comment. Fairhurst Expires October 6, 2016 [Page 24] Internet-Draft April 2016 Simplified a sentence in section 6.1, without intended change of meaning. Added a linking sentence to the second para of Section 6.3. 11. References 11.1. Normative References [ID-ietf-tsvwg-RFC5405.bis] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines (Work-in-Progress)", 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . 11.2. Informative References [ID-ietf-pals-congcons] Stein, YJ., Black, D., and B. Briscoe, "Pseudowire Congestion Considerations (Work-in-Progress)", 2015. [ID-ietf-tsvwg-tunnel-congestion-feedback] Wei, X., Zhu, L., and L. Dend, "Tunnel Congestion Feedback (Work-in-Progress)", 2015. [Jacobsen88] European Telecommunication Standards, Institute (ETSI), "Congestion Avoidance and Control", SIGCOMM Symposium proceedings on Communications architectures and protocols", August 1998. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . Fairhurst Expires October 6, 2016 [Page 25] Internet-Draft April 2016 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, . [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, . [RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, DOI 10.17487/RFC4488, May 2006, . [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, . [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, . [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, . [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10.17487/RFC5087, December 2007, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . Fairhurst Expires October 6, 2016 [Page 26] Internet-Draft April 2016 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RTP-CB] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions (draft-ietf- avtcore-rtp-circuit-breakers)", February 2014. Author's Address Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen, Scotland AB24 3UE UK Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Fairhurst Expires October 6, 2016 [Page 27] ./draft-ietf-tsvwg-diffserv-intercon-14.txt0000664000764400076440000014402613024510506020161 0ustar iustyiusty TSVWG R. Geib, Ed. Internet-Draft Deutsche Telekom Intended status: Informational D. Black Expires: June 18, 2017 Dell EMC December 15, 2016 Diffserv-Interconnection classes and practice draft-ietf-tsvwg-diffserv-intercon-14 Abstract This document defines a limited common set of Diffserv Per Hop Behaviours (PHBs) and codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and explains how this approach can simplify network configuration and operation. Many network providers operate Multi Protocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per Hop Behaviors, and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short-Pipe tunnel mode. While motivated by the requirements of MPLS network operators that use Short-Pipe tunnels, this document is applicable to other networks, both MPLS and non- MPLS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 18, 2017. Geib & Black Expires June 18, 2017 [Page 1] Internet-Draft Diffserv-Intercon December 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 5 3. Relationship to RFC5127 . . . . . . . . . . . . . . . . . . . 6 3.1. RFC5127 Background . . . . . . . . . . . . . . . . . . . 6 3.2. Differences from RFC5127 . . . . . . . . . . . . . . . . 7 4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8 4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 10 4.2. End-to-end PHB and DSCP Transparency . . . . . . . . . . 13 4.3. Treatment of Network Control traffic at carrier interconnection interfaces . . . . . . . . . . . . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Diffserv has been deployed in many networks; it provides differentiated traffic forwarding based on the Diffserv Codepoint (DSCP) field, which is part of the IP header [RFC2474]. This document defines a set of common Diffserv classes (Per Hop Behaviors, PHBs) and code points for use at interconnection points to which and from which locally used classes and code points should be mapped. Geib & Black Expires June 18, 2017 [Page 2] Internet-Draft Diffserv-Intercon December 2016 As described by section 2.3.4.2 of RFC2475, remarking of packets at domain boundaries is a Diffserv feature [RFC2475]. If traffic marked with unknown or unexpected DSCPs is received, RFC2474 recommends forwarding that traffic with default (best effort) treatment without changing the DSCP markings to better support incremental Diffserv deployment in existing networks as well as with routers that do not support Diffserv or are not configured to support it. Many networks do not follow this recommendation, and instead remark unknown or unexpected DSCPs to zero upon receipt for default (best effort) forwarding in accordance with the guidance in RFC2475 [RFC2475] to ensure that appropriate DSCPs are used within a Diffserv domain. This draft is based on the latter approach, and defines additional DSCPs that are known and expected at network interconnection interfaces in order to reduce the amount of traffic whose DSCPs are remarked to zero. This document is motivated by requirements for IP network interconnection with Diffserv support among providers that operate Multi Protocol Label Switching (MPLS) in their backbones, but is also applicable to other technologies. The operational simplifications and methods in this document help align IP Diffserv functionality with MPLS limitations resulting from the widely deployed Short Pipe tunnel model for operation [RFC3270]. Further, limiting Diffserv to a small number of Treatment Aggregates can enable network traffic to leave a network with the DSCP value with which it was received, even if a different DSCP is used within the network, thus providing an opportunity to extend consistent Diffserv treatment across network boundaries. In isolation, use of a defined set of interconnection PHBs and DSCPs may appear to be additional effort for a network operator. The primary offsetting benefit is that mapping from or to the interconnection PHBs and DSCPs is specified once for all of the interconnections to other networks that can use this approach. Absent this approach, the PHBs and DSCPs have to be negotiated and configured independently for each network interconnection, which has poor administrative and operational scaling properties. Further, consistent end-to-end Diffserv treatment is more likely to result when an interconnection code point scheme is used because traffic is remarked to the same PHBs at all network interconnections. The interconnection approach described in this document (referred to as Diffserv-Intercon) uses a set of PHBs (mapped to four corresponding MPLS treatment aggregates) along with a set of interconnection DSCPs allowing straightforward rewriting to domain- internal DSCPs and defined DSCP markings for traffic forwarded to interconnected domains. The solution described here can be used in Geib & Black Expires June 18, 2017 [Page 3] Internet-Draft Diffserv-Intercon December 2016 other contexts benefitting from a defined Diffserv interconnection interface. The basic idea is that traffic sent with a Diffserv-Interconnect PHB and DSCP is restored to that PHB and DSCP at each network interconnection, even though a different PHB and DSCP may be used by each network involved. The key requirement is that the network ingress interconnect DSCP be restored at network egress, and a key observation is that this is only feasible in general for a small number of DSCPs. Traffic sent with other DSCPs can be remarked to an interconnect DSCP or dealt with via additional agreement(s) among the operators of the interconnected networks; use of the MPLS Short Pipe model favors remarking unexpected DSCPs to zero in the absence of additional agreement(s), as explained further in this document. In addition to the common interconnecting PHBs and DSCPs, interconnecting operators need to further agree on the tunneling technology used for interconnection (e.g., MPLS, if used) and control or mitigate the impacts of tunneling on reliability and MTU. 1.1. Related work In addition to the activities that triggered this work, there are additional RFCs and Internet-drafts that may benefit from an interconnection PHB and DSCP scheme. RFC5160 suggests Meta-QoS- Classes to help enabling deployment of standardized end to end QoS classes [RFC5160]. The Diffserv-Intercon class- and codepoint scheme is intended to complement that work (e.g., by enabling a defined set of interconnection DSCPs and PHBs). Border Gateway Protocol (BGP) signaling Class of Service at interconnection interfaces by BGP [I-D.knoll-idr-cos-interconnect], [ID.ietf-idr-sla] is complementary to Diffserv-Intercon. These two BGP documents focus on exchanging Service Level Agreement (SLA) and traffic conditioning parameters and assume that common PHBs identified by the signaled DSCPs have been established (e.g., via use of the Diffserv-Intercon DSCPs) prior to BGP signaling of PHB id codes. 1.2. Applicability Statement This document is applicable to use of Differentiated Services for interconnection traffic between networks, and is particularly suited to interconnection of MPLS-based networks that use MPLS Short-pipe tunnels. This document is also applicable to other network technologies, but it is not intended for use within an individual network, where the approach specified in RFC5127 [RFC5127] is among the possible alternatives; see Section 3 for further discussion. Geib & Black Expires June 18, 2017 [Page 4] Internet-Draft Diffserv-Intercon December 2016 The Diffserv-Intercon approach described in this document simplifies IP based interconnection to domains operating the MPLS Short Pipe model for IP traffic, both terminating within the domain and transiting onward to another domain. Transiting traffic is received and sent with the same PHB and DSCP. Terminating traffic maintains the PHB with which it was received, however the DSCP may change. Diffserv-Intercon is also applicable to the Pipe tunneling model [RFC2983], [RFC3270], but it is not applicable to the Uniform tunneling model [RFC2983], [RFC3270]. The Diffserv-Intercon approach defines a set of four PHBs for support at interconnections (or network boundaries in general). Corresponding DSCPs for use at an interconnection interface are added. Diffserv-intercon allows for a simple mapping of PHBs and DSCPs to MPLS Treatment Aggregates. It is extensible by IETF standardisation and this allows additional PHBs and DSCPs to be specified for the Diffserv-intercon scheme. Coding space for private interconnection agreements or provider internal services is left too. 1.3. Document Organization This document is organized as follows: section 2 reviews the MPLS Short Pipe tunnel model for Diffserv Tunnels [RFC3270], because effective support for that model is a crucial goal of Diffserv- Intercon. Section 3 provides background on RFC5127's approach to traffic class aggregation within a Diffserv network domain and contrasts it with the Diffserv-Intercon approach. Section 4 introduces Diffserv-Interconnection Treatment Aggregates, along with the PHBs and DSCPs that they use, and explains how other PHBs (and associated DSCPs) may be mapped to these Treatment Aggregates. Section 4 also discusses treatment of IP traffic, MPLS VPN Diffserv considerations and handling of high-priority Network Management traffic. Appendix A describes how the MPLS Short Pipe model (penultimate hop popping) impacts DSCP marking for IP interconnections. 2. MPLS and the Short Pipe tunnel model This section provides a summary of the implications of the MPLS Short Pipe tunnels, and in particular their use of Penultimate Hop Popping (PHP, see RFC3270) on the Diffserv tunnel framework described in RFC2983. The Pipe and Uniform models for Differentiated Services and Tunnels are defined in [RFC2983]. RFC3270 adds the Short Pipe model to reflect the impact of MPLS PHP, primarily for MPLS-based IP tunnels and VPNs. The Short Pipe model and PHP have subsequently become popular with network providers that operate MPLS networks and Geib & Black Expires June 18, 2017 [Page 5] Internet-Draft Diffserv-Intercon December 2016 are now widely used to transport unencapsulated IP traffic. This has important implications for Diffserv functionality in MPLS networks. RFC2474's recommendation to forward traffic with unrecognized DSCPs with Default (best effort) service without rewriting the DSCP has not been widely deployed in practice. Network operation and management are simplified when there is a 1-1 match between the DSCP marked on the packet and the forwarding treatment (PHB) applied by network nodes. When this is done, CS0 (the all-zero DSCP) is the only DSCP used for Default forwarding of best effort traffic, and a common practice is to remark to CS0 any traffic received with unrecognized or unsupported DSCPs at network edges. MPLS networks are more subtle in this regard, as it is possible to encode the provider's DSCP in the MPLS Traffic Class (TC) field and allow that to differ from the PHB indicated by the DSCP in the MPLS- encapsulated IP packet. If the MPLS label with the provider's TC field is present at all hops within the provider network, this approach would allow an unrecognized DSCP to be carried edge-to-edge over an MPLS network, because the effective DSCP used by the provider's MPLS network would be encoded in the MPLS label TC field (and also carried edge-to-edge). Unfortunately this is only true for the Pipe tunnel model. The Short Pipe tunnel model and PHP behave differently because PHP removes and discards the MPLS provider label carrying the provider's TC field before the traffic exits the provider's network. That discard occurs one hop upstream of the MPLS tunnel endpoint (which is usually at the network edge), resulting in no provider TC info being available at tunnel egress. To ensure consistent handling of traffic at the tunnel egress, the DSCP field in the MPLS-encapsulated IP header has to contain a DSCP that is valid for the provider's network, so that IP header cannot be used to carry a different DSCP edge-to-edge. See Appendix A for a more detailed discussion. 3. Relationship to RFC5127 This document draws heavily upon RFC5127's approach to aggregation of Diffserv traffic classes for use within a network, but there are important differences caused by characteristics of network interconnects that differ from links within a network. 3.1. RFC5127 Background Many providers operate MPLS-based backbones that employ backbone traffic engineering to ensure that if a major link, switch, or router fails, the result will be a routed network that continues to function. Based on that foundation, [RFC5127] introduced the concept Geib & Black Expires June 18, 2017 [Page 6] Internet-Draft Diffserv-Intercon December 2016 of Diffserv Treatment Aggregates, which enable traffic marked with multiple DSCPs to be forwarded in a single MPLS Traffic Class (TC) based on robust provider backbone traffic engineering. This enables differentiated forwarding behaviors within a domain in a fashion that does not consume a large number of MPLS Traffic Classes. RFC5127 provides an example aggregation of Diffserv service classes into 4 Treatment Aggregates. A small number of aggregates are used because: o The available coding space for carrying Traffic Class information (e.g., Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size, and is intended for more than just Diffserv purposes (see, e.g., [RFC5129]). o The common interconnection DSCPs ought not to use all 8 possible values. This leaves space for future standards, for private bilateral agreements and for local use PHBs and DSCPs. o Migrations from one Diffserv code point scheme to a different one is another possible application of otherwise unused DSCPs. 3.2. Differences from RFC5127 Like RFC5127, this document also uses four traffic aggregates, but differs from RFC5127 in some important ways: o It follows RFC2475 in allowing the DSCPs used within a network to differ from those to exchange traffic with other networks (at network edges), but provides support to restore ingress DSCP values if one of the recommended interconnect DSCPs in this draft is used. This results in DSCP remarking at both network ingress and network egress, and this draft assumes that such remarking at network edges is possible for all interface types. o Diffserv-Intercon suggests limiting the number of interconnection PHBs per Treatment Aggregate to the minimum required. As further discussed below, the number of PHBs per Treatment Aggregate is no more than two. When two PHBs are specified for a Diffserv- Intercon treatment aggregate, the expectation is that the provider network supports DSCPs for both PHBs, but uses a single MPLS TC for the Treatment Aggregate that contains the two PHBs. o Diffserv-Intercon suggests mapping other PHBs and DSCPs into the interconnection Treatment Aggregates as further discussed below. o Diffserv-Intercon treats network control traffic as a special case. Within a provider's network, the CS6 DSCP is used for local Geib & Black Expires June 18, 2017 [Page 7] Internet-Draft Diffserv-Intercon December 2016 network control traffic (routing protocols and Operations, Administration, and Maintenance (OAM) traffic that is essential to network operation administration, control and management) that may be destined for any node within the network. In contrast, network control traffic exchanged between networks (e.g., BGP) usually terminates at or close to a network edge, and is not forwarded through the network because it is not part of internal routing or OAM for the receiving network. In addition, such traffic is unlikely to be covered by standard interconnection agreements; rather, it is more likely to be specifically configured (e.g., most networks impose restrictions on use of BGP with other networks for obvious reasons). See Section 4.2 for further discussion. o Because RFC5127 used a Treatment Aggregate for network control traffic, Diffserv-Intercon can instead define a fourth traffic aggregate to be defined for use at network interconnections instead of the Network Control aggregate in RFC5127. Network Control traffic may still be exchanged across network interconnections as further discussed in Section 4.2. Diffserv- Intercon uses this fourth traffic aggregate for VoIP traffic, where network-provided service differentiation is crucial, as even minor glitches are immediately apparent to the humans involved in the conversation. 4. The Diffserv-Intercon Interconnection Classes At an interconnection, the networks involved need to agree on the PHBs used for interconnection and the specific DSCP for each PHB. This document defines a set of 4 interconnection Treatment Aggregates with well-defined DSCPs to be aggregated by them. A sending party remarks DSCPs from internal schemes to the interconnection code points. The receiving party remarks DSCPs to their internal scheme. The interconnect SLA defines the set of DSCPs and PHBs supported across the two interconnected domains and the treatment of PHBs and DSCPs that are not recognized by the receiving domain. Similar approaches that use a small number of traffic aggregates (including recognition of the importance of VoIP traffic) have been taken in related standards and recommendations from outside the IETF, e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34]and MEF23.1 [MEF23.1]. The list of the four Diffserv-Interconnect traffic aggregates follows, highlighting differences from RFC5127 and suggesting mappings for all RFC4594 traffic classes to Diffserv-Intercon Treatment Aggregates: Geib & Black Expires June 18, 2017 [Page 8] Internet-Draft Diffserv-Intercon December 2016 Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and PHB VOICE-ADMIT, DSCP 101 100, see [RFC3246], [RFC4594] and [RFC5865]. This Treatment Aggregate corresponds to RFC5127's real time Treatment Aggregate definition regarding the queuing (both delay and jitter should be minimized), but this aggregate is restricted to transport Telephony Service Class traffic in the sense of RFC4594 [RFC4594]. Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is designed to transport PHB AF41, DSCP 100 010 (the other AF4 PHB group PHBs and DSCPs may be used for future extension of the set of DSCPs carried by this Treatment Aggregate). This Treatment Aggregate is intended for Diffserv-Intercon network interconnection of the portions of RFC5127's Real Time Treatment Aggregate, that consume significant bandwidth. This traffic is expected to consist of the RFC4594 classes Broadcast Video, Real-Time Interactive and Multimedia Conferencing. This treatment aggregate should be configured with a rate queue (consistent with RFC4594's recommendation for the transported traffic classes). By comparison to RFC5127, the number of DSCPs has been reduced to one (initially). The AF42 and AF43 PHBs could be added if there is a need for three-color marked Multimedia Conferencing traffic. Assured Elastic Treatment Aggregate This Treatment Aggregate consists of PHBs AF31 and AF32 ( i.e., DSCPs 011 010 and 011 100). By comparison to RFC5127, the number of DSCPs has been reduced to two. This document suggests to transport signaling marked by AF31 (e.g., as recommended by GSMA IR.34 [IR.34]). AF33 is reserved for extension of PHBs to be aggregated by this TA. For Diffserv-Intercon network interconnection, the following RFC4594 service classes should be mapped to the Assured Elastic Treatment Aggregate: the Signaling Service Class (being marked for lowest loss probability), Multimedia Streaming Service Class, the Low- Latency Data Service Class and the High-Throughput Data Service Class. Default / Elastic Treatment Aggregate: transports the default PHB, CS0 with DSCP 000 000. RFC5127 example refers to this Treatment Aggregate as Aggregate Elastic. An important difference from RFC5127 is that any traffic with unrecognized or unsupported DSCPs may be remarked to this DSCP. For Diffserv-Intercon network interconnection, the RFC4594 standard service class and Low-priority Data service class should be mapped to this Treatment Aggregate. This document does not specify an interconnection class for RFC4594 Low- Geib & Black Expires June 18, 2017 [Page 9] Internet-Draft Diffserv-Intercon December 2016 priority data. This data may be forwarded by a Lower Effort PHB in one domain (like the PHB proposed by Informational [RFC3662]), but using the methods specified in this document will be remarked with DSCP CS0 at a Diffserv-Intercon network interconnection. This has the effect that Low-priority data is treated the same as data sent using the default class. (Note: In a network that implements RFC2474, Low-priority traffic marked as CS1 would otherwise receive better treatment than traffic using the default class.) RFC2475 states that Ingress nodes must condition all inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to CS0. As a consequence, an interconnect SLA needs to specify not only the treatment of traffic that arrives with a supported interconnect DSCP, but also the treatment of traffic that arrives with unsupported or unexpected DSCPs; remarking to CS0 is a widely deployed behavior. During the process of setting up a Diffserv interconnection, both networks should define the set of acceptable and unacceptable DSCPs and specify the treatment of traffic marked with each DSCP. While Diffserv-Intercon allows modification of unacceptable DSCPs, if traffic using one or more of the PHBs in a PHB group (e.g., AF3x, consisting of AF31, AF32 and AF33) is accepted as part of a supported Diffserv-Intercon Treatment Aggregate, then traffic using other PHBs from the same PHB group should not be modified to use PHBs outside of that PHB group, and in particular should not be remarked to CS0 unless the entire PHB group is remarked to CS0. This avoids unexpected forwarding behavior (and potential reordering, see also [RFC7657]) when using Assured Forwarding (AF) PHBs [RFC2597]. 4.1. Diffserv-Intercon Example The overall approach to DSCP marking at network interconnections is illustrated by the following example. Provider O and provider W are peered with provider T. They have agreed upon a Diffserv interconnection SLA. Traffic of provider O terminates within provider T's network, while provider W's traffic transits through the network of provider T to provider F. This example assumes that all providers use their own internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in Geib & Black Expires June 18, 2017 [Page 10] Internet-Draft Diffserv-Intercon December 2016 the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21 and CS2 are used in the example). Geib & Black Expires June 18, 2017 [Page 11] Internet-Draft Diffserv-Intercon December 2016 Provider O Provider W | | +----------+ +----------+ | AF21 | | CS2 | +----------+ +----------+ V V +~~~~~~~+ +~~~~~~~+ |Rtr PrO| |Rtr PrW| Rtr: Router +~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L] | DiffServ | +----------+ +----------+ | AF31 | | AF31 | +----------+ +----------+ V Intercon V +~~~~~~~+ | |RtrPrTI|------------------+ Router Provider T Ingress +~~~~~~~+ | Provider T domain +------------------+ | MPLS TC 2, AF21 | +------------------+ | | +----------+ +~~~~~~~+ V `--->| AF21 |->-|RtrDstH| Router Destination Host +----------+ +----------+ +~~~~~~~+ | AF21 | Local DSCPs Provider T +----------+ | +~~~~~~~+ |RtrPrTE| Router Provider T Egress +~~~~~~~+ | DiffServ +----------+ | AF31 | +----------+ | Intercon +~~~~~~~+ |RtrPrF | Router Provider F +~~~~~~~+ | +----------+ | AF11 | Provider F +----------+ Diffserv-Intercon example Figure 1 Geib & Black Expires June 18, 2017 [Page 12] Internet-Draft Diffserv-Intercon December 2016 Providers only need to deploy mappings of internal DSCPs to/from Diffserv-Intercon DSCPs so that they can exchange traffic using the desired PHBs. In the example, provider O has decided that the properties of his internal class AF21 are best met by the Diffserv- Intercon Assured Elastic Treatment Aggregate, PHB AF31. At the outgoing peering interface connecting provider O with provider T the former's peering router remarks AF21 traffic to AF31. The domain internal PHB of provider T meeting the requirement of Diffserv- Intercon Assured Elastic Treatment Aggregate are from AF2x PHB group. Hence AF31 traffic received at the interconnection with provider T is remarked to AF21 by the peering router of domain T, and domain T has chosen to use MPLS Traffic Class value 2 for this aggregate. At the penultimate MPLS node, the top MPLS label is removed and exposes the IP header marked by the DSCP that has been set at the network ingress. The peering router connecting domain T with domain F classifies the packet by its domain-T-internal DSCP AF21. As the packet leaves domain T on the interface to domain F, this causes the packet's DSCP to be remarked to AF31. The peering router of domain F classifies the packet for domain-F-internal PHB AF11, as this is the PHB with properties matching Diffserv-Intercon's Assured Elastic Treatment Aggregate. This example can be extended. The figure shows Provider-W using CS2 for traffic that corresponds to Diffserv-Intercon Assured Elastic Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the Diffserv-Intercon interconnection to Provider-T. In addition, suppose that Provider-O supports a PHB marked by AF22 and this PHB is supposed to obtain Diffserv transport within Provider-T domain. Then Provider-O will remark it with DSCP AF32 for interconnection to Provider-T. Finally suppose that Provider-W supports CS3 for internal use only. Then no Diffserv- Intercon DSCP mapping needs to be configured at the peering router. Traffic, sent by Provider-W to Provider-T marked by CS3 due to a misconfiguration may be remarked to CS0 by Provider-T. 4.2. End-to-end PHB and DSCP Transparency This section briefly discusses end-to-end Diffserv approaches related to the Uniform, Pipe and Short Pipe tunnel models ([RFC2983], [RFC3270]), when used edge-to-edge in a network. o With the Uniform model, neither the DCSP nor the PHB change. This implies that a network management packet received with a CS6 DSCP would be forwarded with an MPLS Traffic Class corresponding to CS6. The uniform model is outside the scope of this document. Geib & Black Expires June 18, 2017 [Page 13] Internet-Draft Diffserv-Intercon December 2016 o With the Pipe model, the inner tunnel DCSP remains unchanged, but an outer tunnel DSCP and the PHB could changed. For example a packet received with a (network specific) CS1 DSCP would be transported by default PHB and if MPLS is applicable, forwarded with an MPLS Traffic Class corresponding to Default PHB. The CS1 DSCP is not rewritten. Transport of a large variety (much greater than 4) DSCPs may be required across an interconnected network operating MPLS Short pipe transport for IP traffic. In that case, a tunnel based on the Pipe model is among the possible approaches. The Pipe model is outside the scope of this document. o With the Short Pipe model, the DCSP likely changes and the PHB might change. This document describes a method to simplify Diffserv network interconnection when a DSCP rewrite can't be avoided. 4.3. Treatment of Network Control traffic at carrier interconnection interfaces As specified by RFC4594, section 3.2, Network Control (NC) traffic marked by CS6 is expected at some interconnection interfaces. This document does not change RFC4594, but observes that network control traffic received at network ingress is generally different from network control traffic within a network that is the primary use of CS6 envisioned by RFC4594. A specific example is that some CS6 traffic exchanged across carrier interconnections is terminated at the network ingress node, e.g., when BGP is used between the two routers on opposite ends of an interconnection link; in this case the operators would enter into a bilateral agreement to use CS6 for that BGP traffic. The end-to-end discussion in the previous section (4.2) is generally inapplicable to network control traffic - network control traffic is generally intended to control a network, not be transported between networks. One exception is that network control traffic makes sense for a purchased transit agreement, and preservation of the CS6 DSCP marking for network control traffic that is transited is reasonable in some cases, although it is generally inappropriate to use CS6 for forwarding that traffic within the network that provides transit. Use of an IP tunnel is suggested in order to conceal the CS6 markings on transiting network control traffic from the network that provides the transit. In this case, Pipe model for Diffserv tunneling is used. If the MPLS Short Pipe model is deployed for unencapsulated IPv4 traffic, an IP network provider should limit access to the CS6 and CS7 DSCPs so that they are only used for network control traffic for the provider's own network. Geib & Black Expires June 18, 2017 [Page 14] Internet-Draft Diffserv-Intercon December 2016 Interconnecting carriers should specify treatment of CS6 marked traffic received at a carrier interconnection which is to be forwarded beyond the ingress node. An SLA covering the following cases is recommended when a provider wishes to send CS6 marked traffic across an interconnection link and that traffic's destination is beyond the interconnected ingress node: o classification of traffic that is network control traffic for both domains. This traffic should be classified and marked for the CS6 DSCP. o classification of traffic that is network control traffic for the sending domain only. This traffic should be forwarded with a PHB that is appropriate for the NC service class [RFC4594], e.g., AF31 as specified by this document. As an example GSMA IR.34 recommends an Interactive class / AF31 to carry SIP and DIAMETER traffic. While this is service control traffic of high importance to interconnected Mobile Network Operators, it is certainly not Network Control traffic for a fixed network providing transit among such operators, and hence should not receive CS6 treatment in such a transit network. o any other CS6 marked traffic should be remarked or dropped. 5. Acknowledgements Bob Briscoe and Gorry Fairhurst reviewed the draft and provided rich feedback. Brian Carpenter, Fred Baker, Al Morton and Sebastien Jobert discussed the draft and helped improving it. Mohamed Boucadair and Thomas Knoll helped adding awareness of related work. James Polk's discussion during IETF 89 helped to improve the text on the relation of this draft to RFC4594 and RFC5127. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations The DSCP field in the IP header can expose additional traffic classification information at network interconnections by comparison to use of a zero DSCP for all interconnect traffic. If traffic classification info is sensitive, the DSCP field could be remarked to zero to hide the classification as a countermeasure, at the cost of loss of Diffserv info and differentiated traffic handling on the interconnect and subsequent networks. When AF PHBs are used, any such remarking should respect AF PHB group boundaries as further discussed at the end of Section 4. Geib & Black Expires June 18, 2017 [Page 15] Internet-Draft Diffserv-Intercon December 2016 This document does not introduce new features; it describes how to use existing ones. The Diffserv security considerations in [RFC2475] and [RFC4594] apply. 8. References 8.1. Normative References [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, . [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, . [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, . [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, . [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, . 8.2. Informative References [I-D.knoll-idr-cos-interconnect] Knoll, T., "BGP Class of Service Interconnection", draft- knoll-idr-cos-interconnect-17 (work in progress), November 2016. Geib & Black Expires June 18, 2017 [Page 16] Internet-Draft Diffserv-Intercon December 2016 [ID.ietf-idr-sla] IETF, "Inter-domain SLA Exchange", IETF, http://datatracker.ietf.org/doc/ draft-ietf-idr-sla-exchange/, 2013. [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ ir.34.pdf, 2012. [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet Class of Service Phase 2", MEF, MEF23.1 http://metroethernetforum.org/PDF_Documents/technical- specifications/MEF_23.1.pdf, 2012. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, . [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, . [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, . [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, . [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- to-Provider Agreements for Internet-Scale Quality of Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 2008, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . Geib & Black Expires June 18, 2017 [Page 17] Internet-Draft Diffserv-Intercon December 2016 [Y.1566] ITU-T, "Quality of service mapping and interconnection between Ethernet, IP and multiprotocol label switching networks", ITU, http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic The MPLS Short Pipe Model (or penultimate Hop Label Popping) is widely deployed in carrier networks. If unencapsulated IP traffic is transported using MPLS Short Pipe, IP headers appear inside the last section of the MPLS domain. This impacts the number of PHBs and DSCPs that a network provider can reasonably support. See Figure 2 (below) for an example. For encapsulated IP traffic, only the outer tunnel header is relevant for forwarding. If the tunnel does not terminate within the MPLS network section, only the outer tunnel DSCP is involved, as the inner DSCP does not affect forwarding behavior; in this case all DSCPs could be used in the inner IP header without affecting network behavior based on the outer MPLS header. Here the Pipe model applies. Layer 2 and Layer 3 VPN traffic all use an additional MPLS label; in this case, the MPLS tunnel follows the Pipe model. Classification and queuing within an MPLS network is always based on an MPLS label, as opposed to the outer IP header. Carriers often select PHBs and DSCP without regard to interconnection. As a result PHBs and DSCPs typically differ between network carriers. With the exception of best effort traffic, a DSCP change should be expected at an interconnection at least for unencapsulated IP traffic, even if the PHB is suitably mapped by the carriers involved. Although RFC3270 suggests that the Short Pipe Model is only applicable to VPNs, current networks also use it to transport non- tunneled IPv4 traffic. This is shown in figure 2 where Diffserv- Intercon is not used, resulting in exposure of the internal DSCPs of the upstream network to the downstream network across the interconnection. Geib & Black Expires June 18, 2017 [Page 18] Internet-Draft Diffserv-Intercon December 2016 | \|/ IPv4, DSCP_send V | Peering Router | \|/ IPv4, DSCP_send V | MPLS Edge Router | Mark MPLS Label, TC_internal \|/ Remark DSCP to V (Inner: IPv4, DSCP_d) | MPLS Core Router (penultimate hop label popping) | \ | IPv4, DSCP_d | The DSCP needs to be in network- | ^^^^^^^^| internal Diffserv context. The Core \|/ > Router may require or enforce V | that. The Edge Router may wrongly | | classify, if the DSCP is not in | / network-internal Diffserv context. MPLS Edge Router | \ Traffic leaves the network marked \|/ IPv4, DSCP_d | with the network-internal V > DSCP_d that must be dealt with | | by the next network (downstream). | / Peer Router | Remark DSCP to \|/ IPv4, DSCP_send V | Short-Pipe / penultimate hop popping example Figure 2 The packets IP DSCP must be in a well understood Diffserv context for schedulers and classifiers on the interfaces of the ultimate MPLS link (last link traversed before leaving the network). The necessary Diffserv context is network-internal and a network operating in this mode enforces DSCP usage in order to obtain robust differentiated forwarding behavior. Without Diffserv-Intercon treatment, the traffic is likely to leave each network marked with network-internal DSCP. DSCP_send in the Geib & Black Expires June 18, 2017 [Page 19] Internet-Draft Diffserv-Intercon December 2016 figure above has to be remarked into the first network's Diffserv scheme at the ingress MPLS Edge Router, to DSCP_d in the example. For that reason, the traffic leaves this domain marked by the network-internal DSCP_d. This structure requires that every carrier deploys per-peer PHB and DSCP mapping schemes. If Diffserv-Intercon is applied DSCPs for traffic transiting the domain can be mapped from and remapped to an original DSCP. This is shown in figure 3. Internal traffic may continue to use internal DSCPs (e.g., DSCP_d) and they may also be used between a carrier and its direct customers. Geib & Black Expires June 18, 2017 [Page 20] Internet-Draft Diffserv-Intercon December 2016 Internal Router | | Outer Header \|/ IPv4, DSCP_send V | Peering Router | Remark DSCP to \|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB V | MPLS Edge Router | | Mark MPLS Label, TC_internal \|/ Remark DSCP to V (Inner: IPv4, DSCP_d) domain internal DSCP for | the PHB MPLS Core Router (penultimate hop label popping) | | IPv4, DSCP_d | ^^^^^^ \|/ V | | MPLS Edge Router--------------------+ | | \|/ Remark DSCP to \|/ IPv4, DSCP_d V IPv4, DSCP_ds-int V | | | | Peer Router Domain internal Broadband | Access Router \|/ Remark DSCP to \|/ V IPv4, DSCP_send V IPv4, DSCP_d | | Short-Pipe example with Diffserv-Intercon Figure 3 Authors' Addresses Geib & Black Expires June 18, 2017 [Page 21] Internet-Draft Diffserv-Intercon December 2016 Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de David L. Black Dell EMC 176 South Street Hopkinton, MA USA Phone: +1 (508) 293-7953 Email: david.black@dell.com Geib & Black Expires June 18, 2017 [Page 22] ./draft-ietf-tsvwg-gre-in-udp-encap-19.txt0000664000764400076440000016104512773561617017615 0ustar iustyiustyNetwork Working Group Lucy Yong(Ed.) Internet-Draft Huawei Technologies Intended status: Standard Track E. Crabbe Oracle X. Xu Huawei Technologies T. Herbert Facebook Expires: February 2017 September 30, 2016 GRE-in-UDP Encapsulation draft-ietf-tsvwg-gre-in-udp-encap-19 Abstract This document specifies a method of encapsulating network protocol packet within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load balancing of GRE traffic in transit networks using existing ECMP mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet; (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet. Status of This Document This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 30,2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Yong, Crabbe, Xu, Herbert [Page 1] Internet-Draft GRE-in-UDP Encapsulation September 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................4 1.2. Requirements Language.....................................5 2. Applicability Statement........................................5 2.1. GRE-in-UDP Tunnel Requirements............................6 2.1.1. Requirements for Default GRE-in-UDP Tunnel...........6 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel..............7 3. GRE-in-UDP Encapsulation.......................................7 3.1. IP Header................................................10 3.2. UDP Header...............................................10 3.2.1. Source Port.........................................10 3.2.2. Destination Port....................................11 3.2.3. Checksum............................................11 3.2.4. Length..............................................11 3.3. GRE Header...............................................11 4. Encapsulation Process Procedures..............................12 4.1. MTU and Fragmentation....................................12 4.2. Differentiated Services and ECN Marking..................13 5. Use of DTLS...................................................13 6. UDP Checksum Handling.........................................14 6.1. UDP Checksum with IPv4...................................14 6.2. UDP Checksum with IPv6...................................14 7. Middlebox Considerations......................................17 7.1. Middlebox Considerations for Zero Checksums..............18 8. Congestion Considerations.....................................18 9. Backward Compatibility........................................19 10. IANA Considerations..........................................20 11. Security Considerations......................................21 12. Acknowledgements.............................................21 13. Contributors.................................................22 14. References...................................................23 14.1. Normative References....................................23 14.2. Informative References..................................24 15. Authors' Addresses...........................................25 Yong, Crabber, Xu, Herbert [Page 2] Internet-Draft GRE-in-UDP Encapsulation September 2016 1. Introduction This document specifies a generic GRE-in-UDP encapsulation for tunneling network protocol packets across an IP network based on Generic Routing Encapsulation (GRE) [RFC2784][RFC7676] and User Datagram Protocol(UDP) [RFC768] headers. The GRE header indicates the payload protocol type via an EtherType [RFC7042] in the protocol type field, and the source port field in the UDP header may be used to provide additional entropy. A GRE-in-UDP tunnel offers the possibility of better performance for load balancing GRE traffic in transit networks using existing Equal- Cost Multi-Path (ECMP) mechanisms that use a hash of the five-tuple of source IP address, destination IP address, UDP/TCP source port, UDP/TCP destination port. While such hashing distributes UDP and Transmission Control Protocol (TCP)[RFC793] traffic between a common pair of IP addresses across paths, it uses a single path for corresponding GRE traffic because only the two IP addresses and protocol/next header fields participate in the ECMP hash. Encapsulating GRE in UDP enables use of the UDP source port to provide entropy to ECMP hashing. In addition, GRE-in-UDP enables extending use of GRE across networks that otherwise disallow it; for example, GRE-in-UDP may be used to bridge two islands where GRE is not supported natively across the middleboxes. GRE-in-UDP encapsulation may be used to encapsulate already tunneled traffic, i.e., tunnel-in-tunnel. In this case, GRE-in-UDP tunnels treat the endpoints of the outer tunnel as the end hosts; the presence of an inner tunnel does not change the outer tunnel's handling of network traffic. A GRE-in-UDP tunnel is capable of carrying arbitrary traffic and behaves as a UDP application on an IP network. However, a GRE-in-UDP tunnel carrying certain types of traffic does not satisfy the requirements for UDP applications on the Internet [RFC5405bis]. GRE- in-UDP tunnels that do not satisfy these requirements MUST NOT be deployed to carry such traffic over the Internet. For this reason, this document specifies two deployment scenarios for GRE-in-UDP tunnels with GRE-in-UDP tunnel requirements for each of them: (1) general Internet; (2) a traffic-managed controlled environment (TMCE). The TMCE scenario has less restrictive technical requirements for the protocol but more restrictive management and operation requirements for the network by comparison to the general Internet scenario. Yong, Crabber, Xu, Herbert [Page 3] Internet-Draft GRE-in-UDP Encapsulation September 2016 To provide security for traffic carried by a GRE-in-UDP tunnel, this document also specifies Datagram Transport Layer Security (DTLS) for GRE-in-UDP tunnels, which SHOULD be used when security is a concern. GRE-in-UDP encapsulation usage requires no changes to the transit IP network. ECMP hash functions in most existing IP routers may utilize and benefit from the additional entropy enabled by GRE-in-UDP tunnels without any change or upgrade to their ECMP implementation. The encapsulation mechanism is applicable to a variety of IP networks including Data Center and Wide Area Networks, as well as both IPv4 and IPv6 networks. 1.1. Terminology The terms defined in [RFC768] and [RFC2784] are used in this document. Following are additional terms used in this draft. Decapsulator: a component performing packet decapsulation at tunnel egress. ECMP: Equal-Cost Multi-Path. Encapsulator: a component performing packet encapsulation at tunnel egress. Flow Entropy: The information to be derived from traffic or applications and to be used by network devices in ECMP process [RFC6438]. Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the general Internet. TMCE: A Traffic-managed controlled environment, i.e. an IP network that is traffic-engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion, as defined in Section 2. TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a traffic-managed controlled environment that is defined in Section 2. Tunnel Egress: A tunnel end point that performs packet decapsulation. Tunnel Ingress: A tunnel end point that performs packet encapsulation. Yong, Crabber, Xu, Herbert [Page 4] Internet-Draft GRE-in-UDP Encapsulation September 2016 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Applicability Statement GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks; in both cases, encapsulated packets are treated as UDP datagrams. Therefore, a GRE-in-UDP tunnel needs to meet the UDP usage requirements specified in [RFC5405bis]. These requirements depend on both the delivery network and the nature of the encapsulated traffic. For example, the GRE-in-UDP tunnel protocol does not provide any congestion control functionality beyond that of the encapsulated traffic. Therefore, a GRE-in-UDP tunnel MUST be used only with congestion controlled traffic (e.g., IP unicast traffic) and/or within a network that is traffic-managed to avoid congestion. [RFC5405bis] describes two applicability scenarios for UDP applications: 1) General Internet and 2) A controlled environment. The controlled environment means a single administrative domain or bilaterally agreed connection between domains. A network forming a controlled environment can be managed/operated to meet certain conditions while the general Internet cannot be; thus the requirements for a tunnel protocol operating under a controlled environment can be less restrictive than the requirements in the general Internet. For the purpose of this document, a traffic-managed controlled environment (TMCE) is defined as an IP network that is traffic- engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion. This document specifies GRE-in-UDP tunnel usage in the general Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in- UDP tunnel" terms to refer to each usage. NOTE: Although this document specifies two different sets of GRE-in- UDP tunnel requirements based on tunnel usage, the tunnel implementation itself has no ability to detect how and where it is deployed. Therefore it is the responsibility of the user or operator who deploys a GRE-in-UDP tunnel to ensure that it meets the appropriate requirements. Yong, Crabber, Xu, Herbert [Page 5] Internet-Draft GRE-in-UDP Encapsulation September 2016 2.1. GRE-in-UDP Tunnel Requirements This section states out the requirements for a GRE-in-UDP tunnel. Section 2.1.1 describes the requirements for a default GRE-in-UDP tunnel that is suitable for the general Internet; Section 2.1.2 describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel used in a traffic-managed controlled environment. Both Sections 2.1.1 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network. 2.1.1. Requirements for Default GRE-in-UDP Tunnel The following is a summary of the default GRE-in-UDP tunnel requirements: 1. A UDP checksum SHOULD be used when encapsulating in IPv4. 2. A UDP checksum MUST be used when encapsulating in IPv6. 3. GRE-in-UDP tunnel MUST NOT be deployed or configured to carry traffic that is not congestion controlled. As stated in [RFC5405bis], IP-based unicast traffic is generally assumed to be congestion- controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. A default GRE-in-UDP tunnel is not appropriate for traffic that is not known to be congestion-controlled (e.g., most IP multicast traffic). 4. UDP source port values that are used as a source of flow entropy SHOULD be chosen from the ephemeral port range (49152-65535) [RFC5405bis]. 5. The use of the UDP source port MUST be configurable so that a single value can be set for all traffic within the tunnel (this disables use of the UDP source port to provide flow entropy). When a single value is set, a random port SHOULD be selected in order to minimize the vulnerability to off-path attacks [RFC6056]. 6. For IPv6 delivery networks, the flow entropy SHOULD also be placed in the flow label field for ECMP per [RFC6438]. 7. At the tunnel ingress, any fragmentation of the incoming packet (e.g., because the tunnel has a Maximum Transmission Unit (MTU) that is smaller than the packet) SHOULD be performed before encapsulation. In addition, the tunnel ingress MUST apply the UDP checksum to all encapsulated fragments so that the tunnel egress can validate reassembly of the fragments; it MUST set the same Differentiated Services Code Point (DSCP) value as in the Differentiated Services Yong, Crabber, Xu, Herbert [Page 6] Internet-Draft GRE-in-UDP Encapsulation September 2016 (DS) field of the payload packet in all fragments [RFC2474]. To avoid unwanted forwarding over multiple paths, the same source UDP port value SHOULD be set in all packet fragments. 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel The section contains the TMCE GRE-in-UDP tunnel requirements. It lists the changed requirements, compared with a Default GRE-in-UDP Tunnel, for a TMCE GRE-in-UDP Tunnel, which corresponds to the requirements 1-3 listed in Section 2.1.1. 1. A UDP checksum SHOULD be used when encapsulating in IPv4. A tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum, since GRE has been designed to work without a UDP checksum [RFC2784]. However, a checksum also offers protection from mis-delivery to another port. 2. Use of UDP checksum MUST be the default when encapsulating in IPv6. This default MAY be overridden via configuration of UDP zero- checksum mode. All usage of UDP zero-checksum mode with IPv6 is subject to the additional requirements specified in Section 6.2. 3. A GRE-in-UDP tunnel MAY encapsulate traffic that is not congestion controlled. The requirements 4-7 listed in Section 2.1.1 also apply to a TMCE GRE-in-UDP Tunnel. 3. GRE-in-UDP Encapsulation The GRE-in-UDP encapsulation format contains a UDP header [RFC768] and a GRE header [RFC2890]. The format is shown as follows: (presented in bit order) Yong, Crabber, Xu, Herbert [Page 7] Internet-Draft GRE-in-UDP Encapsulation September 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 IPv4 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live |Protcol=17(UDP)| Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = Entropy Value | Dest. Port = TBD1/TBD2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 UDP+GRE Headers in IPv4 Yong, Crabber, Xu, Herbert [Page 8] Internet-Draft GRE-in-UDP Encapsulation September 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 IPv6 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NxtHdr=17(UDP)| Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Outer Source IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Outer Destination IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = entropy value | Dest. Port = TBD1/TBD2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 UDP+GRE Headers in IPv6 Yong, Crabber, Xu, Herbert [Page 9] Internet-Draft GRE-in-UDP Encapsulation September 2016 The contents of the IP, UDP, and GRE headers that are relevant in this encapsulation are described below. 3.1. IP Header An encapsulator MUST encode its own IP address as the source IP address and the decapsulator's IP address as the destination IP address. A sufficiently large value is needed in the IPv4 TTL field or IPv6 Hop Count field to allow delivery of the encapsulated packet to the peer of the encapsulation. 3.2. UDP Header 3.2.1. Source Port GRE-in-UDP permits the UDP source port value to be used to encode an entropy value. The UDP source port contains a 16-bit entropy value that is generated by the encapsulator to identify a flow for the encapsulated packet. The port value SHOULD be within the ephemeral port range, i.e., 49152 to 65535, where the high order two bits of the port are set to one. This provides fourteen bits of entropy for the inner flow identifier. In the case that an encapsulator is unable to derive flow entropy from the payload header or the entropy usage has to be disabled to meet operational requirements (see Section 7), to avoid reordering with a packet flow, the encapsulator SHOULD use the same UDP source port value for all packets assigned to a flow e.g., the result of an algorithm that perform a hash of the tunnel ingress and egress IP address. The source port value for a flow set by an encapsulator MAY change over the lifetime of the encapsulated flow. For instance, an encapsulator may change the assignment for Denial of Service (DOS) mitigation or as a means to effect routing through the ECMP network. An encapsulator SHOULD NOT change the source port selected for a flow more than once every thirty seconds. An IPv6 GRE-in-UDP tunnel endpoint SHOULD copy a flow entropy value in the IPv6 flow label field (requirement 6). This permits network equipment to inspect this value and utilize it during forwarding, e.g. to perform ECMP [RFC6438]. This document places requirements on the generation of the flow entropy value [RFC5405bis] but does not specify the algorithm that an implementation should use to derive this value. Yong, Crabber, Xu, Herbert [Page 10] Internet-Draft GRE-in-UDP Encapsulation September 2016 3.2.2. Destination Port The destination port of the UDP header is set either GRE-in-UDP (TBD1) or GRE-UDP-DTLS (TBD2) (see Section 5). 3.2.3. Checksum The UDP checksum is set and processed per [RFC768] and [RFC1122] for IPv4, and [RFC2460] for IPv6. Requirements for checksum handling and use of zero UDP checksums are detailed in Section 6. 3.2.4. Length The usage of this field is in accordance with the current UDP specification in [RFC768]. This length will include the UDP header (eight bytes), GRE header, and the GRE payload (encapsulated packet). 3.3. GRE Header An encapsulator sets the protocol type (EtherType) of the packet being encapsulated in the GRE Protocol Type field. An encapsulator MAY set the GRE Key Present, Sequence Number Present, and Checksum Present bits and associated fields in the GRE header as defined by [RFC2784] and [RFC2890]. Usage of the reserved bits, i.e., Reserved0, is specified in [RFC2784]. The GRE checksum MAY be enabled to protect the GRE header and payload. When the UDP checksum is enabled, it protects the GRE payload, resulting in the GRE checksum being mostly redundant. Enabling both checksums may result in unnecessary processing. Since the UDP checksum covers the pseudo-header and the packet payload, including the GRE header and its payload, the UDP checksum SHOULD be used in preference to using the GRE checksum. An implementation MAY use the GRE keyid to authenticate the encapsulator.(See Security Considerations Section) In this model, a shared value is either configured or negotiated between an encapsulator and decapsulator. When a decapsulator determines a presented keyid is not valid for the source, the packet MUST be dropped. Although GRE-in-UDP encapsulation protocol uses both UDP header and GRE header, it is one tunnel encapsulation protocol. GRE and UDP headers MUST be applied and removed as a pair at the encapsulation and decapsulation points. This specification does not support UDP encapsulation of a GRE header where that GRE header is applied or Yong, Crabber, Xu, Herbert [Page 11] Internet-Draft GRE-in-UDP Encapsulation September 2016 removed at a network node other than the UDP tunnel ingress or egress. 4. Encapsulation Process Procedures The procedures specified in this section apply to both a default GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel. The GRE-in-UDP encapsulation allows encapsulated packets to be forwarded through "GRE-in-UDP tunnels". The encapsulator MUST set the UDP and GRE header according to Section 3. Intermediate routers, upon receiving these UDP encapsulated packets, could load balance these packets based on the hash of the five-tuple of UDP packets. Upon receiving these UDP encapsulated packets, the decapsulator decapsulates them by removing the UDP and GRE headers and then processes them accordingly. GRE-in-UDP can encapsulate traffic with unicast, IPv4 broadcast, or multicast (see requirement 3 in Section 2.1.1). However a default GRE-in-UDP tunnel MUST NOT be deployed or configured to carry traffic that is not congestion-controlled (See requirement 3 in Section 2.1.1). Entropy may be generated from the header of encapsulated packets at an encapsulator. The mapping mechanism between the encapsulated multicast traffic and the multicast capability in the IP network is transparent and independent of the encapsulation and is otherwise outside the scope of this document. To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep- alive. It is RECOMMENED not to use GRE keep-alive in the GRE-in-UDP tunnel. This aligns with middlebox traversal guidelines in Section 3.5 of [RFC5405bis]. 4.1. MTU and Fragmentation Regarding packet fragmentation, an encapsulator/decapsulator SHOULD perform fragmentation before the encapsulation. The size of fragments SHOULD be less or equal to the Path MTU (PMTU) associated with the path between the GRE ingress and the GRE egress tunnel endpoints minus the GRE and UDP overhead, assuming the egress MTU for reassembled packets is larger than PMTU. When applying payload fragmentation, the UDP checksum MUST be used so that the receiving endpoint can validate reassembly of the fragments; the same source UDP port SHOULD be used for all packet fragments to ensure the transit routers will forward the fragments on the same path. Yong, Crabber, Xu, Herbert [Page 12] Internet-Draft GRE-in-UDP Encapsulation September 2016 If the operator of the transit network supporting the tunnel is able to control the payload MTU size, the MTU SHOULD be configured to avoid fragmentation, i.e., sufficient for the largest supported size of packet, including all additional bytes introduced by the tunnel overhead [RFC5405bis]. 4.2. Differentiated Services and ECN Marking To ensure that tunneled traffic receives the same treatment over the IP network as traffic that is not tunneled, prior to the encapsulation process, an encapsulator processes the tunneled IP packet headers to retrieve appropriate parameters for the encapsulating IP packet header such as DiffServ [RFC2983]. Encapsulation end points that support Explicit Congestion Notification (ECN) must use the method described in [RFC6040] for ECN marking propagation. The congestion control process is outside of the scope of this document. Additional information on IP header processing is provided in Section 3.1. 5. Use of DTLS Datagram Transport Layer Security (DTLS) [RFC6347] can be used for application security and can preserve network and transport layer protocol information. Specifically, if DTLS is used to secure the GRE-in-UDP tunnel, the destination port of the UDP header MUST be set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS, and that UDP port MUST NOT be used for other traffic. The UDP source port field can still be used to add entropy, e.g., for load-sharing purposes. DTLS applies to a default GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel. Use of DTLS is limited to a single DTLS session for any specific tunnel encapsulator/decapsulator pair (identified by source and destination IP addresses). Both IP addresses MUST be unicast addresses - multicast traffic is not supported when DTLS is used. A GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be able to establish DTLS sessions with multiple tunnel encapsulators, and likewise a GRE-in-UDP tunnel encapsulator is expected to be able to establish DTLS sessions with multiple decapsulators. Different source and/or destination IP addresses will be involved (see Section 6.2) for discussion of one situation where use of different source IP addresses is important. When DTLS is used for a GRE-in-UDP tunnel, if a packet is received from the tunnel and that packet is not protected by the DTLS session Yong, Crabber, Xu, Herbert [Page 13] Internet-Draft GRE-in-UDP Encapsulation September 2016 or part of DTLS negotiation (e.g., a DTLS handshake message [RFC6347]), the tunnel receiver MUST discard that packet and SHOULD log that discard event and information about the discarded packet. DTLS SHOULD be used for a GRE-in-UDP tunnel to meet security requirements of the original traffic that is delivered by a GRE-in- UDP tunnel. There are cases where no additional security is required, e.g., the traffic to be encapsulated is already encrypted or the tunnel is deployed within an operationally secured network. Use of DTLS for a GRE-in-UDP tunnel requires both tunnel endpoints to configure use of DTLS. 6. UDP Checksum Handling 6.1. UDP Checksum with IPv4 For UDP in IPv4, when a non-zero UDP checksum is used, the UDP checksum MUST be processed as specified in [RFC768] and [RFC1122] for both transmit and receive. The IPv4 header includes a checksum that protects against mis-delivery of the packet due to corruption of IP addresses. The UDP checksum potentially provides protection against corruption of the UDP header, GRE header, and GRE payload. Disabling the use of checksums is a deployment consideration that should take into account the risk and effects of packet corruption. When a decapsulator receives a packet, the UDP checksum field MUST be processed. If the UDP checksum is non-zero, the decapsulator MUST verify the checksum before accepting the packet. By default a decapsulator SHOULD accept UDP packets with a zero checksum. A node MAY be configured to disallow zero checksums per [RFC1122]; this may be done selectively, for instance disallowing zero checksums from certain hosts that are known to be sending over paths subject to packet corruption. If verification of a non-zero checksum fails, a decapsulator lacks the capability to verify a non-zero checksum, or a packet with a zero-checksum was received and the decapsulator is configured to disallow, the packet MUST be dropped and an event MAY be logged. 6.2. UDP Checksum with IPv6 For UDP in IPv6, the UDP checksum MUST be processed as specified in [RFC768] and [RFC2460] for both transmit and receive. When UDP is used over IPv6, the UDP checksum is relied upon to protect both the IPv6 and UDP headers from corruption. As such, A default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in- UDP Tunnel MAY be configured with the UDP zero-checksum mode if the Yong, Crabber, Xu, Herbert [Page 14] Internet-Draft GRE-in-UDP Encapsulation September 2016 traffic-managed controlled environment or a set of closely cooperating traffic-managed controlled environments (such as by network operators who have agreed to work together in order to jointly provide specific services) meet at least one of following conditions: a. It is known (perhaps through knowledge of equipment types and lower layer checks) that packet corruption is exceptionally unlikely and where the operator is willing to take the risk of undetected packet corruption. b. It is judged through observational measurements (perhaps of historic or current traffic flows that use a non-zero checksum) that the level of packet corruption is tolerably low and where the operator is willing to take the risk of undetected packet corruption. c. Carrying applications that are tolerant of mis-delivered or corrupted packets (perhaps through higher layer checksum, validation, and retransmission or transmission redundancy) where the operator is willing to rely on the applications using the tunnel to survive any corrupt packets. The following requirements apply to a TMCE GRE-in-UDP tunnel that uses UDP zero-checksum mode: a. Use of the UDP checksum with IPv6 MUST be the default configuration of all GRE-in-UDP tunnels. b. The GRE-in-UDP tunnel implementation MUST comply with all requirements specified in Section 4 of [RFC6936] and with requirement 1 specified in Section 5 of [RFC6936]. c. The tunnel decapsulator SHOULD only allow the use of UDP zero- checksum mode for IPv6 on a single received UDP Destination Port regardless of the encapsulator. The motivation for this requirement is possible corruption of the UDP Destination Port, which may cause packet delivery to the wrong UDP port. If that other UDP port requires the UDP checksum, the mis-delivered packet will be discarded. d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is only enabled for certain selected source addresses. The tunnel decapsulator MUST check that the source and destination IPv6 addresses are valid for the GRE-in-UDP tunnel on which the packet was received if that tunnel uses UDP zero-checksum mode and discard any packet for which this check fails. Yong, Crabber, Xu, Herbert [Page 15] Internet-Draft GRE-in-UDP Encapsulation September 2016 e. The tunnel encapsulator SHOULD use different IPv6 addresses for each GRE-in-UDP tunnel that uses UDP zero-checksum mode regardless of the decapsulator in order to strengthen the decapsulator's check of the IPv6 source address (i.e., the same IPv6 source address SHOULD NOT be used with more than one IPv6 destination address, independent of whether that destination address is a unicast or multicast address). When this is not possible, it is RECOMMENDED to use each source IPv6 address for as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. f. When any middlebox exists on the path of a GRE-in-UDP tunnel, it is RECOMMENDED to use the default mode, i.e. use UDP checksum, to reduce the chance that the encapsulated packets will be dropped. g. Any middlebox that allows the UDP zero-checksum mode for IPv6 MUST comply with requirement 1 and 8-10 in Section 5 of [RFC6936]. h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP checksums from "escaping" to the general Internet; see Section 8 for examples of such measures. i. IPv6 traffic with zero UDP checksums MUST be actively monitored for errors by the network operator. For example, the operator may monitor Ethernet layer packet error rates. j. If a packet with a non-zero checksum is received, the checksum MUST be verified before accepting the packet. This is regardless of whether the tunnel encapsulator and decapsulator have been configured with UDP zero-checksum mode. The above requirements do not change either the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC6936]. The requirement to check the source IPv6 address in addition to the destination IPv6 address, plus the strong recommendation against reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. A traffic-managed controlled environment that satisfies at least one of three conditions listed at the beginning of this section provides additional assurance. A GRE-in-UDP tunnel is suitable for transmission over lower layers in the traffic-managed controlled environments that are allowed by the exceptions stated above and the rate of corruption of the inner Yong, Crabber, Xu, Herbert [Page 16] Internet-Draft GRE-in-UDP Encapsulation September 2016 IP packet on such networks is not expected to increase by comparison to GRE traffic that is not encapsulated in UDP. For these reasons, GRE-in-UDP does not provide an additional integrity check except when GRE checksum is used when UDP zero-checksum mode is used with IPv6, and this design is in accordance with requirements 2, 3 and 5 specified in Section 5 of [RFC6936]. Generic Router Encapsulation (GRE) does not accumulate incorrect transport layer state as a consequence of GRE header corruption. A corrupt GRE packet may result in either packet discard or forwarding of the packet without accumulation of GRE state. Active monitoring of GRE-in-UDP traffic for errors is REQUIRED as occurrence of errors will result in some accumulation of error information outside the protocol for operational and management purposes. This design is in accordance with requirement 4 specified in Section 5 of [RFC6936]. The remaining requirements specified in Section 5 of [RFC6936] are not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply because GRE does not include a control feedback mechanism. Requirements 8-10 are middlebox requirements that do not apply to GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox discussion). It is worth mentioning that the use of a zero UDP checksum should present the equivalent risk of undetected packet corruption when sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and without GRE checksums. In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero- checksum mode for IPv6 when the conditions and requirements stated above are met. Otherwise the UDP checksum need to be used for IPv6 as specified in [RFC768] and [RFC2460]. Use of GRE checksum is RECOMMENED when the UDP checksum is not used. 7. Middlebox Considerations Many middleboxes read or update UDP port information of the packets that they forward. Network Address/Port Translator (NAPT) is the most commonly deployed Network Address Translation (NAT) device [RFC4787]. An NAPT device establishes a NAT session to translate the {private IP address, private source port number} tuple to a {public IP address, public source port number} tuple, and vice versa, for the duration of the UDP session. This provides a UDP application with the "NAT-pass-through" function. NAPT allows multiple internal hosts to share a single public IP address. The port number, i.e., the UDP Source Port number, is used as the demultiplexer of the multiple internal hosts. However, the above NAPT behaviors conflict Yong, Crabber, Xu, Herbert [Page 17] Internet-Draft GRE-in-UDP Encapsulation September 2016 with the behavior a GRE-in-UDP tunnel that is configured to use the UDP source port value to provide entropy. A GRE-in-UDP tunnel is unidirectional; the tunnel traffic is not expected to be returned back to the UDP source port values used to generate entropy. However some middleboxes (e.g., firewall) assume that bidirectional traffic uses a common pair of UDP ports. This assumption also conflicts with the use of the UDP source port field as entropy. Hence, use of the UDP source port for entropy may impact middleboxes behavior. If a GRE-in-UDP tunnel is expected to be used on a path with a middlebox, the tunnel can be configured to either disable use of the UDP source port for entropy or to configure middleboxes to pass packets with UDP source port entropy. 7.1. Middlebox Considerations for Zero Checksums IPv6 datagrams with a zero UDP checksum will not be passed by any middlebox that updates the UDP checksum field or simply validates the checksum based on [RFC2460], such as firewalls. Changing this behavior would require such middleboxes to be updated to correctly handle datagrams with zero UDP checksums. The GRE-in-UDP encapsulation does not provide a mechanism to safely fall back to using a checksum when a path change occurs redirecting a tunnel over a path that includes a middlebox that discards IPv6 datagrams with a zero UDP checksum. In this case the GRE-in-UDP tunnel will be black- holed by that middlebox. As such, when any middlebox exists on the path of GRE-in-UDP tunnel, use of the UDP checksum is RECOMMENDED to increase the probability of successful transmission of GRE-in-UDP packets. Recommended changes to allow firewalls and other middleboxes to support use of an IPv6 zero UDP checksum are described in Section 5 of [RFC6936]. 8. Congestion Considerations Section 3.1.9 of [RFC5405bis] discusses the congestion considerations for design and use of UDP tunnels; this is important because other flows could share the path with one or more UDP tunnels, necessitating congestion control [RFC2914] to avoid distractive interference. Congestion has potential impacts both on the rest of the network containing a UDP tunnel, and on the traffic flows using the UDP tunnels. These impacts depend upon what sort of traffic is carried over the tunnel, as well as the path of the tunnel. The GRE-in-UDP Yong, Crabber, Xu, Herbert [Page 18] Internet-Draft GRE-in-UDP Encapsulation September 2016 tunnel protocol does not provide any congestion control and GRE-in- UDP packets are regular UDP packets. Therefore, a GRE-in-UDP tunnel MUST NOT be deployed to carry non-congestion controlled traffic over the Internet [RFC5405bis]. Within a TMCE network, GRE-in-UDP tunnels are appropriate for carrying traffic that is not known to be congestion controlled. For example, a GRE-in-UDP tunnel may be used to carry Multiprotocol Label Switching (MPLS) traffic such as pseudowires or VPNs where specific bandwidth guarantees are provided to each pseudowire or VPN. In such cases, operators of TMCE networks avoid congestion by careful provisioning of their networks, rate limiting of user data traffic, and traffic engineering according to path capacity. When a GRE-in-UDP tunnel carries traffic that is not known to be congestion controlled in a TMCE network, the tunnel MUST be deployed entirely within that network, and measures SHOULD be taken to prevent the GRE-in-UDP traffic from "escaping" the network to the general Internet, e.g.: o Physical or logical isolation of the links carrying GRE-in-UDP from the general Internet. o Deployment of packet filters that block the UDP ports assigned for GRE-in-UDP. o Imposition of restrictions on GRE-in-UDP traffic by software tools used to set up GRE-in-UDP tunnels between specific end systems (as might be used within a single data center) or by tunnel ingress nodes for tunnels that don't terminate at end systems. 9. Backward Compatibility In general, tunnel ingress routers have to be upgraded in order to support the encapsulations described in this document. No change is required at transit routers to support forwarding of the encapsulation described in this document. If a tunnel endpoint (a host or router) that is intended for use as a decapsulator does not support or enable the GRE-in-UDP encapsulation described in this document, that endpoint will not listen on the destination port assigned to the GRE-encapsulation (TBD1 and TBD2). In these cases, the endpoint will perform normal UDP processing and respond to an encapsulator with an ICMP message Yong, Crabber, Xu, Herbert [Page 19] Internet-Draft GRE-in-UDP Encapsulation September 2016 indicating "port unreachable" according to [RFC792]. Upon receiving this ICMP message, the node MUST NOT continue to use GRE-in-UDP encapsulation toward this peer without management intervention. 10. IANA Considerations IANA is requested to make the following allocations: One UDP destination port number for the indication of GRE, Service Name: GRE-in-UDP Transport Protocol(s): UDP Assignee: IESG Contact: IETF Chair Description: GRE-in-UDP Encapsulation Reference: [This.I-D] Port Number: TBD1 Service Code: N/A Known Unauthorized Uses: N/A Assignment Notes: N/A Editor Note: replace "TBD1" in section 3 and 9 with IANA assigned number. One UDP destination port number for the indication of GRE with DTLS, Service Name: GRE-UDP-DTLS Transport Protocol(s): UDP Assignee: IESG Contact: IETF Chair Description: GRE-in-UDP Encapsulation with DTLS Reference: [This.I-D] Port Number: TBD2 Service Code: N/A Known Unauthorized Uses: N/A Assignment Notes: N/A Editor Note: replace "TBD2" in section 3, 5, and 9 with IANA assigned number. Yong, Crabber, Xu, Herbert [Page 20] Internet-Draft GRE-in-UDP Encapsulation September 2016 11. Security Considerations GRE-in-UDP encapsulation does not affect security for the payload protocol. The security considerations for GRE apply to GRE-in-UDP, see [RFC2784]. To secure traffic carried by a GRE-in-UDP tunnel, DTLS SHOULD be used as specified in Section 5. In the case that UDP source port for entropy usage is disabled, a random port SHOULD be selected in order to minimize the vulnerability to off-path attacks [RFC6056]. The random port may also be periodically changed to mitigate certain denial of service attacks as mentioned in Section 3.2.1. Using one standardized value as the UDP destination port to indicate an encapsulation may increase the vulnerability of off-path attack. To overcome this, an alternate port may be agreed upon to use between an encapsulator and decapsulator [RFC6056]. How the encapsulator end points communicate the value is outside scope of this document. This document does not require that a decapsulator validates the IP source address of the tunneled packets (with the exception that the IPv6 source address MUST be validated when UDP zero-checksum mode is used with IPv6), but it should be understood that failure to do so presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries. Corruption of GRE headers can cause security concerns for applications that rely on the GRE key field for traffic separation or segregation. When the GRE key field is used for this purpose such as an application of a Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637], GRE header corruption is a concern. In such situations, at least one of the UDP and GRE checksums MUST be used for both IPv4 and IPv6 GRE-in-UDP tunnels. 12. Acknowledgements Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger Geib, Lars Eggert, Lloyd Wood, Bob Briscoe, Rick Casarez, Jouni Korhonen, Kathleen Moriarty, Ben Campbell, and many others for their review and valuable input on this draft. Yong, Crabber, Xu, Herbert [Page 21] Internet-Draft GRE-in-UDP Encapsulation September 2016 Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer Dawkins for their detail reviews and valuable suggestions in WGLC and IESG process. Thank the design team led by David Black (members: Ross Callon, Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the descriptions for the congestion considerations and IPv6 UDP zero checksum. Thank David Black and Gorry Fairhurst for their great help in document content and editing. 13. Contributors The following people all contributed significantly to this document and are listed below in alphabetical order: David Black EMC Corporation 176 South Street Hopkinton, MA 01748 USA Email: david.black@emc.com Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: rcallon@juniper.net John E. Drake Juniper Networks Email: jdrake@juniper.net Gorry Fairhurst University of Aberdeen Email: gorry@erg.abdn.ac.uk Yong, Crabber, Xu, Herbert [Page 22] Internet-Draft GRE-in-UDP Encapsulation September 2016 Yongbing Fan China Telecom Guangzhou, China. Phone: +86 20 38639121 Email: fanyb@gsta.com Adrian Farrel Juniper Networks Email: adrian@olddog.co.uk Vishwas Manral Hewlett-Packard Corp. 3000 Hanover St, Palo Alto. Email: vishwas.manral@hp.com Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA Email: cpignata@cisco.com 14. References 14.1. Normative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC2474] Nichols K., Blake S., Baker F., Black D., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", December 1998. Yong, Crabber, Xu, Herbert [Page 23] Internet-Draft GRE-in-UDP Encapsulation September 2016 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC2890, September 2000. [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for Application Designers", draft-ietf-tsvwg-rfc5405bis, work in progress. [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion Notification", RFC6040, November 2010. [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer Security Version 1.2", RFC6347, 2012. [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in tunnels", RFC6438, November, 2011. [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013. 14.2. Informative References [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC793] DARPA, "Transmission Control Protocol", RFC793, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2914] Floyd, S., "Congestion Control Principles", RFC2914, September 2000. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, October 2000. Yong, Crabber, Xu, Herbert [Page 24] Internet-Draft GRE-in-UDP Encapsulation September 2016 [RFC4787] Audet, F., et al, "network Address Translation (NAT) Behavioral Requirements for Unicast UDP", RFC4787, January 2007. [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- Protocol Port Randomization", RFC6056, January 2011. [RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC6438, November 2011. [RFC7042] Eastlake 3rd, D. and Abley, J., "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameter", RFC7042, October 2013. [RFC7637] Garg, P. and Wang, Y., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC7637, September 2015. [RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC7676, October 2015. 15. Authors' Addresses Lucy Yong Huawei Technologies, USA Email: lucy.yong@huawei.com Edward Crabbe Oracle Email: edward.crabbe@gmail.com Xiaohu Xu Huawei Technologies, Beijing, China Email: xuxiaohu@huawei.com Tom Herbert Facebook 1 Hacker Way Menlo Park, CA Email : tom@herbertland.com Yong, Crabber, Xu, Herbert [Page 25] ./draft-ietf-tsvwg-rfc5405bis-19.txt0000664000764400076440000045310613000161133016317 0ustar iustyiusty Transport Area Working Group L. Eggert Internet-Draft NetApp Obsoletes: 5405 (if approved) G. Fairhurst Intended status: Best Current Practice University of Aberdeen Expires: April 17, 2017 G. Shepherd Cisco Systems October 14, 2016 UDP Usage Guidelines draft-ietf-tsvwg-rfc5405bis-19 Abstract The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ECN, DSCPs, and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC5405 and adds guidelines for multicast UDP usage. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Eggert, et al. Expires April 17, 2017 [Page 1] Internet-Draft UDP Usage Guidelines October 2016 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 17, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . 5 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 18 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . 20 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 21 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . 24 3.6. Limited Applicability and Controlled Environments . . . . 26 4. Multicast UDP Usage Guidelines . . . . . . . . . . . . . . . 27 4.1. Multicast Congestion Control Guidelines . . . . . . . . . 29 4.2. Message Size Guidelines for Multicast . . . . . . . . . . 31 5. Programming Guidelines . . . . . . . . . . . . . . . . . . . 31 5.1. Using UDP Ports . . . . . . . . . . . . . . . . . . . . . 33 5.2. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 10.2. Informative References . . . . . . . . . . . . . . . . . 43 Appendix A. Case Study of the Use of IPv6 UDP Zero-Checksum Mode 52 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 53 Eggert, et al. Expires April 17, 2017 [Page 2] Internet-Draft UDP Usage Guidelines October 2016 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 1. Introduction The User Datagram Protocol (UDP) [RFC0768] provides a minimal, unreliable, best-effort, message-passing transport to applications and other protocols (such as tunnels) that desire to operate over IP. Both are simply called "applications" in the remainder of this document. Compared to other transport protocols, UDP and its UDP-Lite variant [RFC3828] are unique in that they do not establish end-to-end connections between communicating end systems. UDP communication consequently does not incur connection establishment and teardown overheads, and there is minimal associated end system state. Because of these characteristics, UDP can offer a very efficient communication transport to some applications. A second unique characteristic of UDP is that it provides no inherent congestion control mechanisms. On many platforms, applications can send UDP datagrams at the line rate of the platform's link interface, which is often much greater than the available end-to-end path capacity, and doing so contributes to congestion along the path. [RFC2914] describes the best current practice for congestion control in the Internet. It identifies two major reasons why congestion control mechanisms are critical for the stable operation of the Internet: 1. The prevention of congestion collapse, i.e., a state where an increase in network load results in a decrease in useful work done by the network. 2. The establishment of a degree of fairness, i.e., allowing multiple flows to share the capacity of a path reasonably equitably. Because UDP itself provides no congestion control mechanisms, it is up to the applications that use UDP for Internet communication to employ suitable mechanisms to prevent congestion collapse and establish a degree of fairness. [RFC2309] discusses the dangers of congestion-unresponsive flows and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms." [RFC7567] reaffirms this statement. This is an important requirement, even for applications that do not use UDP for streaming. In addition, congestion-controlled transmission is of benefit to an application itself, because it can reduce self-induced packet loss, minimize retransmissions, and hence reduce delays. Congestion control is essential even at relatively slow transmission Eggert, et al. Expires April 17, 2017 [Page 3] Internet-Draft UDP Usage Guidelines October 2016 rates. For example, an application that generates five 1500-byte UDP datagrams in one second can already exceed the capacity of a 56 Kb/s path. For applications that can operate at higher, potentially unbounded data rates, congestion control becomes vital to prevent congestion collapse and establish some degree of fairness. Section 3 describes a number of simple guidelines for the designers of such applications. A UDP datagram is carried in a single IP packet and is hence limited to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for IPv6. The transmission of large IP packets usually requires IP fragmentation. Fragmentation decreases communication reliability and efficiency and should be avoided. IPv6 allows the option of transmitting large packets ("jumbograms") without fragmentation when all link layers along the path support this [RFC2675]. Some of the guidelines in Section 3 describe how applications should determine appropriate message sizes. Other sections of this document provide guidance on reliability, checksums, middlebox traversal and use of multicast. This document provides guidelines and recommendations. Although most UDP applications are expected to follow these guidelines, there do exist valid reasons why a specific application may decide not to follow a given guideline. In such cases, it is RECOMMENDED that application designers cite the respective section(s) of this document in the technical specification of their application or protocol and explain their rationale for their design choice. [RFC5405] was scoped to provide guidelines for unicast applications only, whereas this document also provides guidelines for UDP flows that use IP anycast, multicast, broadcast, and applications that use UDP tunnels to support IP flows. Finally, although this document specifically refers to usage of UDP, the spirit of some of its guidelines also applies to other message- passing applications and protocols (specifically on the topics of congestion control, message sizes, and reliability). Examples include signaling, tunnel, or control applications that choose to run directly over IP by registering their own IP protocol number with IANA. This document is expected to provide useful background reading to the designers of such applications and protocols. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Eggert, et al. Expires April 17, 2017 [Page 4] Internet-Draft UDP Usage Guidelines October 2016 3. UDP Usage Guidelines Internet paths can have widely varying characteristics, including transmission delays, available bandwidths, congestion levels, reordering probabilities, supported message sizes, or loss rates. Furthermore, the same Internet path can have very different conditions over time. Consequently, applications that may be used on the Internet MUST NOT make assumptions about specific path characteristics. They MUST instead use mechanisms that let them operate safely under very different path conditions. Typically, this requires conservatively probing the current conditions of the Internet path they communicate over to establish a transmission behavior that it can sustain and that is reasonably fair to other traffic sharing the path. These mechanisms are difficult to implement correctly. For most applications, the use of one of the existing IETF transport protocols is the simplest method of acquiring the required mechanisms. Doing so also avoids issues that protocols using a new IP protocol number face when being deployed over the Internet, where middleboxes that only support TCP and UDP are sometimes present. Consequently, the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol such as TCP [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control Protocol (DCCP) [RFC4340] with its different congestion control types [RFC4341][RFC4342][RFC5622], or transport protocols specified by the IETF in the future. (UDP-encapsulated SCTP [RFC6951] and DCCP [RFC6773] can offer support for traversing firewalls and other middleboxes where the native protocols are not supported.) If used correctly, these more fully-featured transport protocols are not as "heavyweight" as often claimed. For example, the TCP algorithms have been continuously improved over decades, and have reached a level of efficiency and correctness that custom application-layer mechanisms will struggle to easily duplicate. In addition, many TCP implementations allow connections to be tuned by an application to its purposes. For example, TCP's "Nagle" algorithm [RFC1122] can be disabled, improving communication latency at the expense of more frequent -- but still congestion-controlled -- packet transmissions. Another example is the TCP SYN cookie mechanism [RFC4987], which is available on many platforms. TCP with SYN cookies does not require a server to maintain per-connection state until the connection is established. TCP also requires the end that closes a connection to maintain the TIME-WAIT state that prevents delayed segments from one connection instance from interfering with a later one. Applications that are aware of and designed for this Eggert, et al. Expires April 17, 2017 [Page 5] Internet-Draft UDP Usage Guidelines October 2016 behavior can shift maintenance of the TIME-WAIT state to conserve resources by controlling which end closes a TCP connection [FABER]. Finally, TCP's built-in capacity-probing and awareness of the maximum transmission unit supported by the path (PMTU) results in efficient data transmission that quickly compensates for the initial connection setup delay, in the case of transfers that exchange more than a few segments. 3.1. Congestion Control Guidelines If an application or protocol chooses not to use a congestion- controlled transport protocol, it SHOULD control the rate at which it sends UDP datagrams to a destination host, in order to fulfill the requirements of [RFC2914]. It is important to stress that an application SHOULD perform congestion control over all UDP traffic it sends to a destination, independently from how it generates this traffic. For example, an application that forks multiple worker processes or otherwise uses multiple sockets to generate UDP datagrams SHOULD perform congestion control over the aggregate traffic. Several approaches to perform congestion control are discussed in the remainder of this section. The section describes generic topics with an intended emphasis on unicast and anycast [RFC1546] usage. Not all approaches discussed below are appropriate for all UDP-transmitting applications. Section 3.1.2 discusses congestion control options for applications that perform bulk transfers over UDP. Such applications can employ schemes that sample the path over several subsequent round-trips during which data is exchanged to determine a sending rate that the path at its current load can support. Other applications only exchange a few UDP datagrams with a destination. Section 3.1.3 discusses congestion control options for such "low data-volume" applications. Because they typically do not transmit enough data to iteratively sample the path to determine a safe sending rate, they need to employ different kinds of congestion control mechanisms. Section 3.1.11 discusses congestion control considerations when UDP is used as a tunneling protocol. Section 4 provides additional recommendations for broadcast and multicast usage. It is important to note that congestion control should not be viewed as an add-on to a finished application. Many of the mechanisms discussed in the guidelines below require application support to operate correctly. Application designers need to consider congestion control throughout the design of their application, similar to how they consider security aspects throughout the design process. Eggert, et al. Expires April 17, 2017 [Page 6] Internet-Draft UDP Usage Guidelines October 2016 In the past, the IETF has also investigated integrated congestion control mechanisms that act on the traffic aggregate between two hosts, i.e., a framework such as the Congestion Manager [RFC3124], where active sessions may share current congestion information in a way that is independent of the transport protocol. Such mechanisms have currently failed to see deployment, but would otherwise simplify the design of congestion control mechanisms for UDP sessions, so that they fulfill the requirements in [RFC2914]. 3.1.1. Protocol Timer Guidelines Understanding the latency between communicating endpoints is usually a crucial part of effective congestion control implementations for protocols and applications. Latency estimation can be used in a number of protocol functions, such as calculating a congestion- controlled transmission rate, triggering retransmission, and detecting packet loss. Additional protocol functions, for example, determining an interval for probing a path, determining an interval between keep-alive messages, determining an interval for measuring the quality of experience, or determining if a remote endpoint has responded to a request to perform an action typically operate over longer timescales than congestion control and therefore are not covered in this section. The general recommendation in this document is that applications SHOULD leverage existing congestion control techniques and the latency estimators specified therein (see next subsection). The following guidelines are provided for applications that need to design their own latency estimation mechanisms. The guidelines are framed in terms of "latency" and not "round-trip time" because some situations require characterizing only the network-based latency (e.g., TCP-Friendly Rate Control [RFC5348]), while other cases necessitate inclusion of the time required by the remote endpoint to provide feedback (e.g., developing an understanding of when to retransmit a message). The latency between endpoints is generally a dynamic property. Therefore, estimates SHOULD represent some sort of averaging of multiple recent measurement samples to account for variance. Leveraging an Exponentially Weighted Moving Average (EWMA) has proven useful for this purpose (e.g., in TCP [RFC6298] and TCP-Friendly Rate Control (TFRC) [RFC5348]). Independent latency estimates SHOULD be maintained for each destination with which an endpoint communicates. Eggert, et al. Expires April 17, 2017 [Page 7] Internet-Draft UDP Usage Guidelines October 2016 Latency samples MUST NOT be derived from ambiguous transactions. The canonical example is in a protocol that retransmits data, but subsequently cannot determine which copy is being acknowledged. This ambiguity makes correct computation of the latency problematic. See the discussion of Karn's algorithm in [RFC6298]. This requirement ensures a sender establishes a sound estimate of the latency without relying on mis-leading measurements. When a latency estimate is used to arm a timer that provides loss detection - with or without retransmission - expiry of the timer MUST be interpreted as an indication of congestion in the network, causing the sending rate to be adapted to a safe conservative rate (e.g., TCP collapses the congestion window to one segment [RFC5681]). Some applications require an initial latency estimate before the latency between endpoints can be empirically sampled. For instance, when arming a retransmission timer an initial value is needed to protect the messages sent before the endpoints sample the latency. This initial latency estimate SHOULD generally be as conservative (large) as possible for the given application. For instance, in the absence of any knowledge about the latency of a path, TCP requires the initial Retransmission Timeout (RTO) to be set to no less than 1 second [RFC6298]. UDP applications SHOULD similarly use an initial latency estimate of 1 second. Values shorter than 1 second can be problematic (see the data analysis in the appendix of [RFC6298]). 3.1.2. Bulk Transfer Applications Applications that perform bulk transmission of data to a peer over UDP, i.e., applications that exchange more than a few UDP datagrams per round-trip time (RTT), SHOULD implement TFRC [RFC5348], window- based TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles. TFRC has been designed to provide both congestion control and fairness in a way that is compatible with the IETF's other transport protocols. If an application implements TFRC, it need not follow the remaining guidelines in Section 3.1.2, because TFRC already addresses them, but SHOULD still follow the remaining guidelines in the subsequent subsections of Section 3. Bulk transfer applications that choose not to implement TFRC or TCP- like windowing SHOULD implement a congestion control scheme that results in bandwidth (capacity) use that competes fairly with TCP within an order of magnitude. Section 2 of [RFC3551] suggests that applications SHOULD monitor the packet loss rate to ensure that it is within acceptable parameters. Eggert, et al. Expires April 17, 2017 [Page 8] Internet-Draft UDP Usage Guidelines October 2016 Packet loss is considered acceptable if a TCP flow across the same network path under the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than that of the UDP flow. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The recommendations for managing timers specified in Section 3.1.1 also apply. Finally, some bulk transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity (see Section 3.1.9). This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation over the wider Internet. When the UDP traffic of such applications leaks out into unprovisioned Internet paths, it can significantly degrade the performance of other traffic sharing the path and even result in congestion collapse. Applications that support an uncontrolled or unadaptive transmission behavior SHOULD NOT do so by default and SHOULD instead require users to explicitly enable this mode of operation, and they SHOULD verify that sufficient path capacity has been reserved for them. 3.1.3. Low Data-Volume Applications When applications that at any time exchange only a few UDP datagrams with a destination implement TFRC or one of the other congestion control schemes in Section 3.1.2, the network sees little benefit, because those mechanisms perform congestion control in a way that is only effective for longer transmissions. Applications that at any time exchange only a few UDP datagrams with a destination SHOULD still control their transmission behavior by not sending on average more than one UDP datagram per RTT to a destination. Similar to the recommendation in [RFC1536], an application SHOULD maintain an estimate of the RTT for any destination with which it communicates using the methods specified in Section 3.1.1. Some applications cannot maintain a reliable RTT estimate for a destination. These applications do not need to or are unable to use protocol timers to measure the RTT (Section 3.1.1). Two cases can be identified: 1. The first case is that of applications that exchange too few UDP datagrams with a peer to establish a statistically accurate RTT estimate, but can monitor the reliability of transmission (Section 3.3). Such applications MAY use a predetermined transmission interval that is exponentially backed-off when Eggert, et al. Expires April 17, 2017 [Page 9] Internet-Draft UDP Usage Guidelines October 2016 packets are found to be lost. TCP specifies an initial value of 1 second [RFC6298], which is also RECOMMENDED as an initial value for UDP applications. Some low data-volume applications, e.g., SIP [RFC3261] and GIST [RFC5971] use an interval of 500 ms, and shorter values are likely problematic in many cases. As in the previous case, note that the initial timeout is not the maximum possible timeout, see Section 3.1.1. 2. A second case of applications cannot maintain an RTT estimate for a destination, because the destination does not send return traffic. Such applications SHOULD NOT send more than one UDP datagram every 3 seconds, and SHOULD use an even less aggressive rate when possible. Shorter values are likely problematic in many cases. Note that the sending rate in this case must be more conservative than in the previous cases, because the lack of return traffic prevents the detection of packet loss, i.e., congestion, and the application therefore cannot perform exponential back-off to reduce load. 3.1.4. Applications supporting bidirectional communications Applications that communicate bidirectionally SHOULD employ congestion control for both directions of the communication. For example, for a client-server, request-response-style application, clients SHOULD congestion-control their request transmission to a server, and the server SHOULD congestion-control its responses to the clients. Congestion in the forward and reverse direction is uncorrelated, and an application SHOULD either independently detect and respond to congestion along both directions, or limit new and retransmitted requests based on acknowledged responses across the entire round-trip path. 3.1.5. Implications of RTT and Loss Measurements on Congestion Control Transports such as TCP, SCTP and DCCP provide timely detection of congestion that results in an immediate reduction of their maximum sending rate when congestion is experienced. This reaction is typically completed 1-2 RTTs after loss/congestion is encountered. Applications using UDP SHOULD implement a congestion control scheme that provides a prompt reaction to signals indicating congestion (e.g., by reducing the rate within the next RTT following a congestion signal). The operation of a UDP congestion control algorithm can be very different to the way TCP operates. This includes congestion controls that respond on timescales that fit applications that cannot usefully work within the "change rate every RTT" model of TCP. Applications that experience a low or varying RTT are particularly vulnerable to Eggert, et al. Expires April 17, 2017 [Page 10] Internet-Draft UDP Usage Guidelines October 2016 sampling errors (e.g., due to measurement noise, or timer accuracy). This suggests the need to average loss/congestion and RTT measurements over a longer interval, however this also can contribute additional delay in detecting congestion. Some applications may not react by reducing their sending rate immediately for various reasons, including: RTT and loss measurements are only made periodically (e.g., using RTCP), additional time is required to filter information, or the application is only able to change its sending rate at predetermined interval (e.g., some video codecs). When designing a congestion control algorithm, the designer therefore needs to consider the total time taken to reduce the load following a lack of feedback or a congestion event. An application where the most recent RTT measurement is smaller than the actual RTT or the measured loss rate is smaller than the current rate, can result in over estimating the available capacity. Such over estimation can result in a sending rate that creates congestion to the application or other flows sharing the path capacity, and can contribute to congestion collapse - both of these need to be avoided. A congestion control designed for UDP SHOULD respond as quickly as possible when it experiences congestion, and SHOULD take into account both the loss rate and the response time when choosing a new rate. The implemented congestion control scheme SHOULD result in bandwidth (capacity) use that is comparable to that of TCP within an order of magnitude, so that it does not starve other flows sharing a common bottleneck. 3.1.6. Burst Mitigation and Pacing UDP applications SHOULD provide mechanisms to regulate the bursts of transmission that the application may send to the network. Many TCP and SCTP implementations provide mechanisms that prevent a sender from generating long bursts at line-rate, since these are known to induce early loss to applications sharing a common network bottleneck. The use of pacing with TCP [ALLMAN] has also been shown to improve the coexistence of TCP flows with other flows. The need to avoid excessive transmission bursts is also noted in specifications for applications (e.g., [RFC7143]). Even low data-volume UDP flows may benefit from packet pacing, e.g., an application that sends three copies of a packet to improve robustness to loss is RECOMMENDED to pace out those three packets over several RTTs, to reduce the probability that all three packets will be lost due to the same congestion event (or other event, such as burst corruption). Eggert, et al. Expires April 17, 2017 [Page 11] Internet-Draft UDP Usage Guidelines October 2016 3.1.7. Explicit Congestion Notification Internet applications can use Explicit Congestion Notification (ECN) [RFC3168] to gain benefits for the services they support [I-D.ietf-aqm-ecn-benefits]. Internet transports, such as TCP, provide a set of mechanisms that are needed to utilize ECN. ECN operates by setting an ECN-capable codepoint (ECT(0) or ECT(1)) in the IP header of packets that are sent. This indicates to ECN-capable network devices (routers, and other devices) that they may mark (set the congestion experienced, CE codepoint), rather than drop the IP packet as a signal of incipient congestion. UDP applications can also benefit from enabling ECN, providing that the API supports ECN and that they implement the required protocol mechanisms to support ECN. The set of mechanisms required for an application to use ECN over UDP are: o A sender MUST provide a method to determine (e.g., negotiate) that the corresponding application is able to provide ECN feedback using a compatible ECN method. o A receiver that enables the use of ECN for a UDP port MUST check the ECN field at the receiver for each UDP datagram that it receives on this port. o The receiving application needs to provide feedback of congestion information to the sending application. This MUST report the presence of datagrams received with a CE-mark by providing a mechanism to feed this congestion information back to the sending application. The feedback MAY also report the presence of ECT(1) and ECT(0)/Not-ECT packets [RFC7560]. ([RFC3168] and [RFC7560] specify methods for TCP.) o An application sending ECN-capable datagrams MUST provide an appropriate congestion reaction when it receives feedback indicating that congestion has been experienced. This ought to result in reduction of the sending rate by the UDP congestion control method (see Section 3.1) that is not less than the reaction of TCP under equivalent conditions. o A sender SHOULD detect network paths that do not support the ECN field correctly. When detected they need to either conservatively react to congestion or even fall back to not using ECN [I-D.ietf-aqm-ecn-benefits]. This method needs to be robust to Eggert, et al. Expires April 17, 2017 [Page 12] Internet-Draft UDP Usage Guidelines October 2016 changes within the network path that may occur over the lifetime of a session. o A sender is encouraged to provide a mechanism to detect and react appropriately to misbehaving receivers that fail to report CE- marked packets [I-D.ietf-aqm-ecn-benefits]. [RFC6679] provides guidance and an example of this support, by describing a method to allow ECN to be used for UDP-based applications using the Real-Time Protocol (RTP). Applications that cannot provide this set of mechanisms, but wish to gain the benefits of using ECN, are encouraged to use a transport protocol that already supports ECN (such as TCP). 3.1.8. Differentiated Services Model An application using UDP can use the differentiated services (DiffServ) Quality of Service (QoS) framework. To enable differentiated services processing, a UDP sender sets the Differentiated Services Code Point (DSCP) field [RFC2475] in packets sent to the network. Normally, a UDP source/destination port pair will set a single DSCP value for all packets belonging to a flow, but multiple DSCPs can be used as described later in this section. A DSCP may be chosen from a small set of fixed values (the class selector code points), or from a set of recommended values defined in the Per Hop Behavior (PHB) specifications, or from values that have purely local meanings to a specific network that supports DiffServ. In general, packets may be forwarded across multiple networks between source and destination. In setting a non-default DSCP value, an application must be aware that DSCP markings may be changed or removed between the traffic source and destination. This has implications on the design of applications that use DSCPs. Specifically, applications SHOULD be designed to not rely on implementation of a specific network treatment, they need instead to implement congestion control methods to determine if their current sending rate is inducing congestion in the network. [RFC7657] describes the implications of using DSCPs and provides recommendations on using multiple DSCPs within a single network five- tuple (source and destination addresses, source and destination ports, and the transport protocol used, in this case, UDP or UDP- Lite), and particularly the expected impact on transport protocol interactions, with congestion control or reliability functionality (e.g., retransmission, reordering). Use of multiple DSCPs can result in reordering by increasing the set of network forwarding resources Eggert, et al. Expires April 17, 2017 [Page 13] Internet-Draft UDP Usage Guidelines October 2016 used by a sender. It can also increase exposure to resource depletion or failure. 3.1.9. QoS, Pre-Provisioned or Reserved Capacity The IETF usually specifies protocols for use within the Best Effort General Internet. Sometimes it is relevant to specify protocols with a different applicability. An application using UDP can use the integrated services QoS framework. This framework is usually made available within controlled environments (e.g., within a single administrative domain or bilaterally agreed connection between domains). Applications intended for the Internet SHOULD NOT assume that QoS mechanisms are supported by the networks they use, and therefore need to provide congestion control, error recovery, etc. in case the actual network path does not provide provisioned service. Some UDP applications are only expected to be deployed over network paths that use pre-provisioned capacity or capacity reserved using dynamic provisioning, e.g., through the Resource Reservation Protocol (RSVP). Multicast applications are also used with pre-provisioned capacity (e.g., IPTV deployments within access networks). These applications MAY choose not to implement any congestion control mechanism and instead rely on transmitting only on paths where the capacity is provisioned and reserved for this use. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation over the wider Internet. Applications that choose this option SHOULD carefully and in detail describe the provisioning and management procedures that result in the desired containment. Applications that support an uncontrolled or unadaptive transmission behavior SHOULD NOT do so by default and SHOULD instead require users to explicitly enable this mode of operation. Applications designed for use within a controlled environment (see Section 3.6) may be able to exploit network management functions to detect whether they are causing congestion, and react accordingly. If the traffic of such applications leaks out into unprovisioned Internet paths, it can significantly degrade the performance of other traffic sharing the path and even result in congestion collapse. Protocols designed for such networks SHOULD provide mechanisms at the network edge to prevent leakage of traffic into unprovisioned Internet paths (e.g., [RFC7510]). To protect other applications sharing the same path, applications SHOULD also deploy an appropriate circuit breaker, as described in Section 3.1.10. Eggert, et al. Expires April 17, 2017 [Page 14] Internet-Draft UDP Usage Guidelines October 2016 An IETF specification targeting a controlled environment is expected to provide an applicability statement that restricts the application to the controlled environment (see Section 3.6). 3.1.10. Circuit Breaker Mechanisms A transport circuit breaker is an automatic mechanism that is used to estimate the congestion caused by a flow, and to terminate (or significantly reduce the rate of) the flow when excessive congestion is detected [I-D.ietf-tsvwg-circuit-breaker]. This is a safety measure to prevent congestion collapse (starvation of resources available to other flows), essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance. A circuit breaker is intended as a protection mechanism of last resort. Under normal circumstances, a circuit breaker should not be triggered; it is designed to protect things when there is severe overload. The goal is usually to limit the maximum transmission rate that reflects the available capacity of a network path. Circuit breakers can operate on individual UDP flows or traffic aggregates, e.g., traffic sent using a network tunnel. [I-D.ietf-tsvwg-circuit-breaker] provides guidance and examples on the use of circuit breakers. The use of a circuit breaker in RTP is specified in [I-D.ietf-avtcore-rtp-circuit-breakers]. Applications used in the general Internet SHOULD implement a transport circuit breaker if they do not implement congestion control or operate a low volume data service (see Section 3.6). All applications MAY implement a transport circuit breaker [I-D.ietf-tsvwg-circuit-breaker] and are encouraged to consider implementing at least a slow-acting transport circuit breaker to provide a protection of last resort for their network traffic. 3.1.11. UDP Tunnels One increasingly popular use of UDP is as a tunneling protocol [I-D.ietf-intarea-tunnels], where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint, which decapsulates the UDP datagrams and forwards the original packets contained in the payload. One example of such a protocol is Teredo [RFC4380]. Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology and can be used to create virtual (private) networks. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by middleboxes that may exist along the path, because many middleboxes support transmission using UDP. Eggert, et al. Expires April 17, 2017 [Page 15] Internet-Draft UDP Usage Guidelines October 2016 Well-implemented tunnels are generally invisible to the endpoints that happen to transmit over a path that includes tunneled links. On the other hand, to the routers along the path of a UDP tunnel, i.e., the routers between the two tunnel endpoints, the traffic that a UDP tunnel generates is a regular UDP flow, and the encapsulator and decapsulator appear as regular UDP-sending and -receiving applications. Because other flows can share the path with one or more UDP tunnels, congestion control needs to be considered. Two factors determine whether a UDP tunnel needs to employ specific congestion control mechanisms -- first, whether the payload traffic is IP-based; second, whether the tunneling scheme generates UDP traffic at a volume that corresponds to the volume of payload traffic carried within the tunnel. IP-based unicast traffic is generally assumed to be congestion- controlled, i.e., it is assumed that the transport protocols generating IP-based unicast traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Consequently, a tunnel carrying IP-based unicast traffic should already interact appropriately with other traffic sharing the path, and specific congestion control mechanisms for the tunnel are not necessary. However, if the IP traffic in the tunnel is known to not be congestion-controlled, additional measures are RECOMMENDED to limit the impact of the tunneled traffic on other traffic sharing the path. For the specific case of a tunnel that carries IP multicast traffic, see Section 4.1. The following guidelines define these possible cases in more detail: 1. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is IP- based and congestion-controlled. This is arguably the most common case for Internet tunnels. In this case, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. A circuit breaker mechanism may provide benefit by controlling the envelope of the aggregated traffic. Note that this guideline is built on the assumption that most IP- based communication is congestion-controlled. If a UDP tunnel is used for IP-based traffic that is known to not be congestion- controlled, the next set of guidelines applies. Eggert, et al. Expires April 17, 2017 [Page 16] Internet-Draft UDP Usage Guidelines October 2016 2. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled. This can be the case, for example, when some link-layer protocols are encapsulated within UDP (but not all link-layer protocols; some are congestion-controlled). Because it is not known that congestion losses of tunneled non-IP traffic will trigger an appropriate congestion response at the senders, the UDP tunnel SHOULD employ an appropriate congestion control mechanism or circuit breaker mechanism designed for the traffic it carries. Because tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines in Section 3.1.2 apply. 3. A tunnel generates UDP traffic at a volume that does not correspond to the volume of payload traffic, independent of whether the payload traffic is IP-based or congestion-controlled. Examples of this class include UDP tunnels that send at a constant rate, increase their transmission rates under loss, for example, due to increasing redundancy when Forward Error Correction is used, or are otherwise unconstrained in their transmission behavior. These specialized uses of UDP for tunneling go beyond the scope of the general guidelines given in this document. The implementer of such specialized tunnels SHOULD carefully consider congestion control in the design of their tunneling mechanism and SHOULD consider use of a circuit breaker mechanism. The type of encapsulated payload might be identified by a UDP port; identified by an Ethernet Type or IP protocol number. A tunnel SHOULD provide mechanisms to restrict the types of flows that may be carried by the tunnel. For instance, a UDP tunnel designed to carry IP needs to filter out non-IP traffic at the ingress. This is particularly important when a generic tunnel encapsulation is used (e.g., one that encapsulates using an EtherType value). Such tunnels SHOULD provide a mechanism to restrict the types of traffic that are allowed to be encapsulated for a given deployment (see [I-D.ietf-intarea-tunnels]). Designing a tunneling mechanism requires significantly more expertise than needed for many other UDP applications, because tunnels are usually intended to be transparent to the endpoints transmitting over them, so they need to correctly emulate the behavior of an IP link [I-D.ietf-intarea-tunnels], e.g.: Eggert, et al. Expires April 17, 2017 [Page 17] Internet-Draft UDP Usage Guidelines October 2016 o Requirements for tunnels that carry or encapsulate using ECN code points [RFC6040]. o Usage of the IP DSCP field by tunnel endpoints [RFC2983]. o Encapsulation considerations in the design of tunnels [I-D.ietf-rtgwg-dt-encap]. o Usage of ICMP messages [I-D.ietf-intarea-tunnels]. o Handling of fragmentation and packet size for tunnels [I-D.ietf-intarea-tunnels]. o Source port usage for tunnels designed to support equal cost multipath (ECMP) routing (see Section 5.1.1). o Guidance on the need to protect headers [I-D.ietf-intarea-tunnels] and the use of checksums for IPv6 tunnels (see Section 3.4.1). o Support for operations and maintenance [I-D.ietf-intarea-tunnels]. At the same time, the tunneled traffic is application traffic like any other from the perspective of the networks the tunnel transmits over. This document only touches upon the congestion control considerations for implementing UDP tunnels; a discussion of other required tunneling behavior is out of scope. 3.2. Message Size Guidelines IP fragmentation lowers the efficiency and reliability of Internet communication. The loss of a single fragment results in the loss of an entire fragmented packet, because even if all other fragments are received correctly, the original packet cannot be reassembled and delivered. This fundamental issue with fragmentation exists for both IPv4 and IPv6. In addition, some network address translators (NATs) and firewalls drop IP fragments. The network address translation performed by a NAT only operates on complete IP packets, and some firewall policies also require inspection of complete IP packets. Even with these being the case, some NATs and firewalls simply do not implement the necessary reassembly functionality, and instead choose to drop all fragments. Finally, [RFC4963] documents other issues specific to IPv4 fragmentation. Due to these issues, an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination. Consequently, an Eggert, et al. Expires April 17, 2017 [Page 18] Internet-Draft UDP Usage Guidelines October 2016 application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191][RFC1981][RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation. However, the ICMP messages that enable path MTU discovery are being increasingly filtered by middleboxes (including Firewalls) [RFC4890]. When the path includes a tunnel, some devices acting as a tunnel ingress discard ICMP messages that originate from network devices over which the tunnel passes, preventing these reaching the UDP endpoint. Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not rely upon network support for ICMP messages and is therefore considered more robust than standard PMTUD. It is not susceptible to "black holing" of ICMP message. To operate, PLPMTUD requires changes to the way the transport is used, both to transmit probe packets, and to account for the loss or success of these probes. This updates not only the PMTU algorithm, it also impacts loss recovery, congestion control, etc. These updated mechanisms can be implemented within a connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a part of UDP, but this type of feedback is not typically present for unidirectional applications. PLPMTUD therefore places additional design requirements on a UDP application that wishes to use this method. This is especially true for UDP tunnels, because the overhead of sending probe packets needs to be accounted for and may require adding a congestion control mechanism to the tunnel (see Section 3.1.11) as well as complicating the data path at a tunnel decapsulator. Applications that do not follow this recommendation to do PMTU/ PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would result in IP packets that exceed the path MTU. Because the actual path MTU is unknown, such applications SHOULD fall back to sending messages that are shorter than the default effective MTU for sending (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes [RFC2460]. The effective PMTU for a directly connected destination (with no routers on the path) is the configured interface MTU, which could be less than the maximum link payload size. Transmission of minimum-sized UDP datagrams is inefficient over paths that support a larger PMTU, which is a second reason to implement PMTU discovery. To determine an appropriate UDP payload size, applications MUST subtract the size of the IP header (which includes any IPv4 optional headers or IPv6 extension headers) as well as the length of the UDP header (8 bytes) from the PMTU size. This size, known as the Maximum Segment Size (MSS), can be obtained from the TCP/IP stack [RFC1122]. Eggert, et al. Expires April 17, 2017 [Page 19] Internet-Draft UDP Usage Guidelines October 2016 Applications that do not send messages that exceed the effective PMTU of IPv4 or IPv6 need not implement any of the above mechanisms. Note that the presence of tunnels can cause an additional reduction of the effective PMTU [I-D.ietf-intarea-tunnels], so implementing PMTU discovery may be beneficial. Applications that fragment an application-layer message into multiple UDP datagrams SHOULD perform this fragmentation so that each datagram can be received independently, and be independently retransmitted in the case where an application implements its own reliability mechanisms. 3.3. Reliability Guidelines Application designers are generally aware that UDP does not provide any reliability, e.g., it does not retransmit any lost packets. Often, this is a main reason to consider UDP as a transport protocol. Applications that do require reliable message delivery MUST implement an appropriate mechanism themselves. UDP also does not protect against datagram duplication, i.e., an application may receive multiple copies of the same UDP datagram, with some duplicates arriving potentially much later than the first. Application designers SHOULD handle such datagram duplication gracefully, and may consequently need to implement mechanisms to detect duplicates. Even if UDP datagram reception triggers only idempotent operations, applications may want to suppress duplicate datagrams to reduce load. Applications that require ordered delivery MUST reestablish datagram ordering themselves. The Internet can significantly delay some packets with respect to others, e.g., due to routing transients, intermittent connectivity, or mobility. This can cause reordering, where UDP datagrams arrive at the receiver in an order different from the transmission order. Applications that use multiple transport ports need to be robust to reordering between sessions. Load-balancing techniques within the network, such as Equal Cost Multipath (ECMP) forwarding can also result in a lack of ordering between different transport sessions, even between the same two network endpoints. It is important to note that the time by which packets are reordered or after which duplicates can still arrive can be very large. Even more importantly, there is no well-defined upper boundary here. [RFC0793] defines the maximum delay a TCP segment should experience -- the Maximum Segment Lifetime (MSL) -- as 2 minutes. No other RFC defines an MSL for other transport protocols or IP itself. The MSL Eggert, et al. Expires April 17, 2017 [Page 20] Internet-Draft UDP Usage Guidelines October 2016 value defined for TCP is conservative enough that it SHOULD be used by other protocols, including UDP. Therefore, applications SHOULD be robust to the reception of delayed or duplicate packets that are received within this 2-minute interval. Retransmission of lost packets or messages is a common reliability mechanism. Such retransmissions can increase network load in response to congestion, worsening that congestion. Any application that uses retransmission is responsible for congestion control of its retransmissions (as well as the application's original traffic), and hence is subject to the Congestion Control guidelines in Section 3.1. Guidance on the appropriate measurement of RTT in Section 3.1.1 also applies for timers used for retransmission packet loss detection. Instead of implementing these relatively complex reliability mechanisms by itself, an application that requires reliable and ordered message delivery SHOULD whenever possible choose an IETF standard transport protocol that provides these features. 3.4. Checksum Guidelines The UDP header includes an optional, 16-bit one's complement checksum that provides an integrity check. These checks are not strong from a coding or cryptographic perspective, and are not designed to detect physical-layer errors or malicious modification of the datagram [RFC3819]. Application developers SHOULD implement additional checks where data integrity is important, e.g., through a Cyclic Redundancy Check (CRC) or keyed or non-keyed cryptographic hash included with the data to verify the integrity of an entire object/file sent over the UDP service. The UDP checksum provides a statistical guarantee that the payload was not corrupted in transit. It also allows the receiver to verify that it was the intended destination of the packet, because it covers the IP addresses, port numbers, and protocol number, and it verifies that the packet is not truncated or padded, because it covers the size field. It therefore protects an application against receiving corrupted payload data in place of, or in addition to, the data that was sent. More description of the set of checks performed using the checksum field is provided in Section 3.1 of [RFC6396]. Applications SHOULD enable UDP checksums [RFC1122]. For IPv4, [RFC0768] permits an option to disable their use, by setting a zero checksum value. An application is permitted to optionally discard UDP datagrams with a zero checksum [RFC1122]. When UDP is used over IPv6, the UDP checksum is relied upon to protect both the IPv6 and UDP headers from corruption (because IPv6 Eggert, et al. Expires April 17, 2017 [Page 21] Internet-Draft UDP Usage Guidelines October 2016 lacks a checksum) and MUST be used as specified in [RFC2460]. Under specific conditions a UDP application is allowed to use a zero UDP zero-checksum mode with a tunnel protocol (see Section 3.4.1). Applications that choose to disable UDP checksums MUST NOT make assumptions regarding the correctness of received data and MUST behave correctly when a UDP datagram is received that was originally sent to a different destination or is otherwise corrupted. 3.4.1. IPv6 Zero UDP Checksum [RFC6935] defines a method that enables use of a zero UDP zero- checksum mode with a tunnel protocol, providing that the method satisfies the requirements in [RFC6936]. The application MUST implement mechanisms and/or usage restrictions when enabling this mode. This includes defining the scope for usage and measures to prevent leakage of traffic to other UDP applications (see Appendix A Section 3.6). These additional design requirements for using a zero IPv6 UDP checksum are not present for IPv4, since the IPv4 header validates information that is not protected in an IPv6 packet. Key requirements are: o Use of the UDP checksum with IPv6 MUST be the default configuration for all implementations [RFC6935]. The receiving endpoint MUST only allow the use of UDP zero-checksum mode for IPv6 on a UDP destination port that is specifically enabled. o An application that support a checksum different to that in [RFC2460] MUST comply with all implementation requirements specified in Section 4 of [RFC6936] and with the usage requirements specified in Section 5 of [RFC6936]. o A UDP application MUST check that the source and destination IPv6 addresses are valid for any packets with a UDP zero-checksum and MUST discard any packet for which this check fails. To protect from misdelivery, new encapsulation designs SHOULD include an integrity check at the transport layer that includes at least the IPv6 header, the UDP header and the shim header for the encapsulation, if any [RFC6936]. o One way to help satisfy the requirements of [RFC6936] may be to limit the usage of such tunnels, e.g., to constrain traffic to an operator network, as discussed in Section 3.6. The encapsulation defined for MPLS in UDP [RFC7510] chooses this approach. As in IPv4, IPv6 applications that choose to disable UDP checksums MUST NOT make assumptions regarding the correctness of received data Eggert, et al. Expires April 17, 2017 [Page 22] Internet-Draft UDP Usage Guidelines October 2016 and MUST behave correctly when a UDP datagram is received that was originally sent to a different destination or is otherwise corrupted. IPv6 datagrams with a zero UDP checksum will not be passed by any middlebox that validates the checksum based on [RFC2460] or that updates the UDP checksum field, such as NATs or firewalls. Changing this behavior would require such middleboxes to be updated to correctly handle datagrams with zero UDP checksums To ensure end-to- end robustness, applications that may be deployed in the general Internet MUST provide a mechanism to safely fall back to using a checksum when a path change occurs that redirects a zero UDP checksum flow over a path that includes a middlebox that discards IPv6 datagrams with a zero UDP checksum. 3.4.2. UDP-Lite A special class of applications can derive benefit from having partially-damaged payloads delivered, rather than discarded, when using paths that include error-prone links. Such applications can tolerate payload corruption and MAY choose to use the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of basic UDP. Applications that choose to use UDP-Lite instead of UDP should still follow the congestion control and other guidelines described for use with UDP in Section 3. UDP-Lite changes the semantics of the UDP "payload length" field to that of a "checksum coverage length" field. Otherwise, UDP-Lite is semantically identical to UDP. The interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates the checksum coverage length: at the sender, this specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error-insensitive part." By default, the UDP-Lite checksum coverage extends across the entire datagram. If required, an application may dynamically modify this length value, e.g., to offer greater protection to some messages. UDP-Lite always verifies that a packet was delivered to the intended destination, i.e., always verifies the header fields. Errors in the insensitive part will not cause a UDP datagram to be discarded by the destination. Applications using UDP-Lite therefore MUST NOT make assumptions regarding the correctness of the data received in the insensitive part of the UDP-Lite payload. A UDP-Lite sender SHOULD select the minimum checksum coverage to include all sensitive payload information. For example, applications that use the Real-Time Protocol (RTP) [RFC3550] will likely want to protect the RTP header against corruption. Applications, where appropriate, MUST also introduce their own appropriate validity Eggert, et al. Expires April 17, 2017 [Page 23] Internet-Draft UDP Usage Guidelines October 2016 checks for protocol information carried in the insensitive part of the UDP-Lite payload (e.g., internal CRCs). A UDP-Lite receiver MUST set a minimum coverage threshold for incoming packets that is not smaller than the smallest coverage used by the sender [RFC3828]. The receiver SHOULD select a threshold that is sufficiently large to block packets with an inappropriately short coverage field. This may be a fixed value, or may be negotiated by an application. UDP-Lite does not provide mechanisms to negotiate the checksum coverage between the sender and receiver. This therefore needs to be performed by the application. Applications can still experience packet loss when using UDP-Lite. The enhancements offered by UDP-Lite rely upon a link being able to intercept the UDP-Lite header to correctly identify the partial coverage required. When tunnels and/or encryption are used, this can result in UDP-Lite datagrams being treated the same as UDP datagrams, i.e., result in packet loss. Use of IP fragmentation can also prevent special treatment for UDP-Lite datagrams, and this is another reason why applications SHOULD avoid IP fragmentation (Section 3.2). UDP-Lite is supported in some endpoint protocol stacks. Current support for middlebox traversal using UDP-Lite is poor, because UDP- Lite uses a different IPv4 protocol number or IPv6 "next header" value than that used for UDP; therefore, few middleboxes are currently able to interpret UDP-Lite and take appropriate actions when forwarding the packet. This makes UDP-Lite less suited for applications needing general Internet support, until such time as UDP-Lite has achieved better support in middleboxes. 3.5. Middlebox Traversal Guidelines Network address translators (NATs) and firewalls are examples of intermediary devices ("middleboxes") that can exist along an end-to- end path. A middlebox typically performs a function that requires it to maintain per-flow state. For connection-oriented protocols, such as TCP, middleboxes snoop and parse the connection-management information, and create and destroy per-flow state accordingly. For a connectionless protocol such as UDP, this approach is not possible. Consequently, middleboxes can create per-flow state when they see a packet that -- according to some local criteria -- indicates a new flow, and destroy the state after some time during which no packets belonging to the same flow have arrived. Depending on the specific function that the middlebox performs, this behavior can introduce a time-dependency that restricts the kinds of UDP traffic exchanges that will be successful across the middlebox. For example, NATs and firewalls typically define the partial path on Eggert, et al. Expires April 17, 2017 [Page 24] Internet-Draft UDP Usage Guidelines October 2016 one side of them to be interior to the domain they serve, whereas the partial path on their other side is defined to be exterior to that domain. Per-flow state is typically created when the first packet crosses from the interior to the exterior, and while the state is present, NATs and firewalls will forward return traffic. Return traffic that arrives after the per-flow state has timed out is dropped, as is other traffic that arrives from the exterior. Many applications that use UDP for communication operate across middleboxes without needing to employ additional mechanisms. One example is the Domain Name System (DNS), which has a strict request- response communication pattern that typically completes within seconds. Other applications may experience communication failures when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Applications SHOULD be able to gracefully handle such communication failures and implement mechanisms to re-establish application-layer sessions and state. For some applications, such as media transmissions, this re- synchronization is highly undesirable, because it can cause user- perceivable playback artifacts. Such specialized applications MAY send periodic keep-alive messages to attempt to refresh middlebox state (e.g., [RFC7675]). It is important to note that keep-alive messages are not recommended for general use -- they are unnecessary for many applications and can consume significant amounts of system and network resources. An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT transmit them more frequently than once every 15 seconds and SHOULD use longer intervals when possible. No common timeout has been specified for per-flow UDP state for arbitrary middleboxes. NATs require a state timeout of 2 minutes or longer [RFC4787]. However, empirical evidence suggests that a significant fraction of currently deployed middleboxes unfortunately use shorter timeouts. The timeout of 15 seconds originates with the Interactive Connectivity Establishment (ICE) protocol [RFC5245]. When an application is deployed in a controlled environment, the deployer SHOULD investigate whether the target environment allows applications to use longer intervals, or whether it offers mechanisms to explicitly control middlebox state timeout durations, for example, using the Port Control Protocol (PCP) [RFC6887], Middlebox Communications (MIDCOM) [RFC3303], Next Steps in Signaling (NSIS) [RFC5973], or Universal Plug and Play (UPnP) [UPnP]. It is RECOMMENDED that applications apply slight random variations ("jitter") to the timing of keep-alive Eggert, et al. Expires April 17, 2017 [Page 25] Internet-Draft UDP Usage Guidelines October 2016 transmissions, to reduce the potential for persistent synchronization between keep-alive transmissions from different hosts [RFC7675]. Sending keep-alive messages is not a substitute for implementing a mechanism to recover from broken sessions. Like all UDP datagrams, keep-alive messages can be delayed or dropped, causing middlebox state to time out. In addition, the congestion control guidelines in Section 3.1 cover all UDP transmissions by an application, including the transmission of middlebox keep-alive messages. Congestion control may thus lead to delays or temporary suspension of keep-alive transmission. Keep-alive messages are NOT RECOMMENDED for general use. They are unnecessary for many applications and may consume significant resources. For example, on battery-powered devices, if an application needs to maintain connectivity for long periods with little traffic, the frequency at which keep-alive messages are sent can become the determining factor that governs power consumption, depending on the underlying network technology. Because many middleboxes are designed to require keep-alive messages for TCP connections at a frequency that is much lower than that needed for UDP, this difference alone can often be sufficient to prefer TCP over UDP for these deployments. On the other hand, there is anecdotal evidence that suggests that direct communication through middleboxes, e.g., by using ICE [RFC5245], does succeed less often with TCP than with UDP. The trade-offs between different transport protocols -- especially when it comes to middlebox traversal -- deserve careful analysis. UDP applications that could be deployed in the Internet need to be designed understanding that there are many variants of middlebox behavior, and although UDP is connectionless, middleboxes often maintain state for each UDP flow. Using multiple UDP flows can consume available state space and also can lead to changes in the way the middlebox handles subsequent packets (either to protect its internal resources, or to prevent perceived misuse). The probability of path failure can increase when applications use multiple UDP flows in parallel (see Section 5.1.2 for recommendations on usage of multiple ports). 3.6. Limited Applicability and Controlled Environments Two different types of applicability have been identified for the specification of IETF applications that utilize UDP: General Internet. By default, IETF specifications target deployment on the general Internet. Experience has shown that successful Eggert, et al. Expires April 17, 2017 [Page 26] Internet-Draft UDP Usage Guidelines October 2016 protocols developed in one specific context or for a particular application tend to become used in a wider range of contexts. For example, a protocol with an initial deployment within a local area network may subsequently be used over a virtual network that traverses the Internet, or in the Internet in general. Applications designed for general Internet use may experience a range of network device behaviors, and in particular should consider whether applications need to operate over paths that may include middleboxes. Controlled Environment. A protocol/encapsulation/tunnel could be designed to be used only within a controlled environment. For example, an application designed for use by a network operator might only be deployed within the network of that single network operator or on networks of an adjacent set of cooperating network operators. The application traffic may then be managed to avoid congestion, rather than relying on built-in mechanisms, which are required when operating over the general Internet. Applications that target a limited applicability use case may be able to take advantage of specific hardware (e.g., carrier-grade equipment) or underlying protocol features of the subnetwork over which they are used. Specifications addressing a limited applicability use case or a controlled environment SHOULD identify how in their restricted deployment a level of safety is provided that is equivalent to that of a protocol designed for operation over the general Internet (e.g., a design based on extensive experience with deployments of particular methods that provide features that cannot be expected in general Internet equipment and the robustness of the design of MPLS to corruption of headers both helped justify use of an alternate UDP integrity check [RFC7510]). An IETF specification targeting a controlled environment is expected to provide an applicability statement that restricts the application traffic to the controlled environment, and would be expected to describe how methods can be provided to discourage or prevent escape of corrupted packets from the environment (for example, section 5 of [RFC7510]). 4. Multicast UDP Usage Guidelines This section complements Section 3 by providing additional guidelines that are applicable to multicast and broadcast usage of UDP. Multicast and broadcast transmission [RFC1112] usually employ the UDP transport protocol, although they may be used with other transport protocols (e.g., UDP-Lite). Eggert, et al. Expires April 17, 2017 [Page 27] Internet-Draft UDP Usage Guidelines October 2016 There are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in [RFC1112] and the Source-Specific Multicast (SSM) model as defined in [RFC4607]. ASM group members will receive all data sent to the group by any source, while SSM constrains the distribution tree to only one single source. Specialized classes of applications also use UDP for IP multicast or broadcast [RFC0919]. The design of such specialized applications requires expertise that goes beyond simple, unicast-specific guidelines, since these senders may transmit to potentially very many receivers across potentially very heterogeneous paths at the same time, which significantly complicates congestion control, flow control, and reliability mechanisms. This section provides guidance on multicast and broadcast UDP usage. Use of broadcast by an application is normally constrained by routers to the local subnetwork. However, use of tunneling techniques and proxies can and does result in some broadcast traffic traversing Internet paths. These guidelines therefore also apply to broadcast traffic. The IETF has defined a reliable multicast framework [RFC3048] and several building blocks to aid the designers of multicast applications, such as [RFC3738] or [RFC4654]. Senders to anycast destinations must be aware that successive messages sent to the same anycast IP address may be delivered to different anycast nodes, i.e., arrive at different locations in the topology. Most UDP tunnels that carry IP multicast traffic use a tunnel encapsulation with a unicast destination address, such as Automatic Multicast Tunneling [RFC7450]. These MUST follow the same requirements as a tunnel carrying unicast data (see Section 3.1.11). There are deployment cases and solutions where the outer header of a UDP tunnel contains a multicast destination address, such as [RFC6513]. These cases are primarily deployed in controlled environments over reserved capacity, often operating within a single administrative domain, or between two domains over a bi-laterally agreed upon path with reserved capacity, and so congestion control is OPTIONAL, but circuit breaker techniques are still RECOMMENDED in order to restore some degree of service should the offered load exceed the reserved capacity (e.g., due to misconfiguration). Eggert, et al. Expires April 17, 2017 [Page 28] Internet-Draft UDP Usage Guidelines October 2016 4.1. Multicast Congestion Control Guidelines Unicast congestion-controlled transport mechanisms are often not applicable to multicast distribution services, or simply do not scale to large multicast trees, since they require bi-directional communication and adapt the sending rate to accommodate the network conditions to a single receiver. In contrast, multicast distribution trees may fan out to massive numbers of receivers, which limits the scalability of an in-band return channel to control the sending rate, and the one-to-many nature of multicast distribution trees prevents adapting the rate to the requirements of an individual receiver. For this reason, generating TCP-compatible aggregate flow rates for Internet multicast data, either native or tunneled, is the responsibility of the application implementing the congestion control. Applications using multicast SHOULD provide appropriate congestion control. Multicast congestion control needs to be designed using mechanisms that are robust to the potential heterogeneity of both the multicast distribution tree and the receivers belonging to a group. Heterogeneity may manifest itself in some receivers experiencing more loss that others, higher delay, and/or less ability to respond to network conditions. Congestion control is particularly important for any multicast session where all or part of the multicast distribution tree spans an access network (e.g., a home gateway). Two styles of congestion control have been defined in the RFC-series: o Feedback-based congestion control, in which the sender receives multicast or unicast UDP messages from the receivers allowing it to assess the level of congestion and then adjust the sender rate(s) (e.g., [RFC5740],[RFC4654]). Multicast methods may operate on longer timescales than for unicast (e.g., due to the higher group RTT of a heterogeneous group). A control method could decide not to reduce the rate of the entire multicast group in response to a control message received from a single receiver (e.g., a sender could set a minimum rate and decide to request a congested receiver to leave the multicast group and could also decide to distribute content to these congested receivers at a lower rate using unicast congestion control). o Receiver-driven congestion control, which does not require a receiver to send explicit UDP control messages for congestion control (e.g., [RFC3738], [RFC5775]). Instead, the sender distributes the data across multiple IP multicast groups (e.g., using a set of {S,G} channels). Each receiver determines its own level of congestion and controls its reception rate using only multicast join/leave messages sent in the network control plane. This method scales to arbitrary large groups of receivers. Eggert, et al. Expires April 17, 2017 [Page 29] Internet-Draft UDP Usage Guidelines October 2016 Any multicast-enabled receiver may attempt to join and receive traffic from any group. This may imply the need for rate limits on individual receivers or the aggregate multicast service. Note there is no way at the transport layer to prevent a join message propagating to the next-hop router. Some classes of multicast applications support applications that can monitor the user-level quality of the transfer at the receiver. Applications that can detect a significant reduction in user quality SHOULD regard this as a congestion signal (e.g., to leave a group using layered multicast encoding) or, if not, SHOULD use this signal to provide a circuit breaker to terminate the flow by leaving the multicast group. 4.1.1. Bulk Transfer Multicast Applications Applications that perform bulk transmission of data over a multicast distribution tree, i.e., applications that exchange more than a few UDP datagrams per RTT, SHOULD implement a method for congestion control. The currently RECOMMENDED IETF methods are: Asynchronous Layered Coding (ALC) [RFC5775], TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654], Wave and Equation Based Rate Control (WEBRC) [RFC3738], NACK-Oriented Reliable Multicast (NORM) transport protocol [RFC5740], File Delivery over Unidirectional Transport (FLUTE) [RFC6726], Real Time Protocol/Control Protocol (RTP/RTCP) [RFC3550]. An application can alternatively implement another congestion control schemes following the guidelines of [RFC2887] and utilizing the framework of [RFC3048]. Bulk transfer applications that choose not to implement [RFC4654], [RFC5775], [RFC3738], [RFC5740], [RFC6726], or [RFC3550] SHOULD implement a congestion control scheme that results in bandwidth use that competes fairly with TCP within an order of magnitude. Section 2 of [RFC3551] states that multimedia applications SHOULD monitor the packet loss rate to ensure that it is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path under the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than that of the UDP flow. The comparison to TCP cannot be specified exactly, but is intended as an "order-of- magnitude" comparison in timescale and throughput. Eggert, et al. Expires April 17, 2017 [Page 30] Internet-Draft UDP Usage Guidelines October 2016 4.1.2. Low Data-Volume Multicast Applications All the recommendations in Section 3.1.3 are also applicable to low data-volume multicast applications. 4.2. Message Size Guidelines for Multicast A multicast application SHOULD NOT send UDP datagrams that result in IP packets that exceed the effective MTU as described in section 3 of [RFC6807]. Consequently, an application SHOULD either use the effective MTU information provided by the Population Count Extensions to Protocol Independent Multicast [RFC6807] or implement path MTU discovery itself (see Section 3.2) to determine whether the path to each destination will support its desired message size without fragmentation. 5. Programming Guidelines The de facto standard application programming interface (API) for TCP/IP applications is the "sockets" interface [POSIX]. Some platforms also offer applications the ability to directly assemble and transmit IP packets through "raw sockets" or similar facilities. This is a second, more cumbersome method of using UDP. The guidelines in this document cover all such methods through which an application may use UDP. Because the sockets API is by far the most common method, the remainder of this section discusses it in more detail. Although the sockets API was developed for UNIX in the early 1980s, a wide variety of non-UNIX operating systems also implement it. The sockets API supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs from that for TCP in several key ways. Because application programmers are typically more familiar with the TCP sockets API, this section discusses these differences. [STEVENS] provides usage examples of the UDP sockets API. UDP datagrams may be directly sent and received, without any connection setup. Using the sockets API, applications can receive packets from more than one IP source address on a single UDP socket. Some servers use this to exchange data with more than one remote host through a single UDP socket at the same time. Many applications need to ensure that they receive packets from a particular source address; these applications MUST implement corresponding checks at the application layer or explicitly request that the operating system filter the received packets. Many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This Eggert, et al. Expires April 17, 2017 [Page 31] Internet-Draft UDP Usage Guidelines October 2016 is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports. Binding a UDP socket does not establish a connection -- UDP does not notify the remote end when a local UDP socket is bound. Binding a socket also allows configuring options that affect the UDP or IP layers, for example, use of the UDP checksum or the IP Timestamp option. On some stacks, a bound socket also allows an application to be notified when ICMP error messages are received for its transmissions [RFC1122]. If a client/server application executes on a host with more than one IP interface, the application SHOULD send any UDP responses with an IP source address that matches the IP destination address of the UDP datagram that carried the request (see [RFC1122], Section 4.1.3.5). Many middleboxes expect this transmission behavior and drop replies that are sent from a different IP address, as explained in Section 3.5. A UDP receiver can receive a valid UDP datagram with a zero-length payload. Note that this is different from a return value of zero from a read() socket call, which for TCP indicates the end of the connection. UDP provides no flow-control, i.e., the sender at any given time does not know whether the receiver is able to handle incoming transmissions. This is another reason why UDP-based applications need to be robust in the presence of packet loss. This loss can also occur within the sending host, when an application sends data faster than the line rate of the outbound network interface. It can also occur at the destination, where receive calls fail to return all the data that was sent when the application issues them too infrequently (i.e., such that the receive buffer overflows). Robust flow control mechanisms are difficult to implement, which is why applications that need this functionality SHOULD consider using a full-featured transport protocol such as TCP. When an application closes a TCP, SCTP or DCCP socket, the transport protocol on the receiving host is required to maintain TIME-WAIT state. This prevents delayed packets from the closed connection instance from being mistakenly associated with a later connection instance that happens to reuse the same IP address and port pairs. The UDP protocol does not implement such a mechanism. Therefore, UDP-based applications need to be robust to reordering and delay. One application may close a socket or terminate, followed in time by another application receiving on the same port. This later application may then receive packets intended for the first application that were delayed in the network. Eggert, et al. Expires April 17, 2017 [Page 32] Internet-Draft UDP Usage Guidelines October 2016 5.1. Using UDP Ports The rules and procedures for the management of the Service Name and Transport Protocol Port Number Registry are specified in [RFC6335]. Recommendations for use of UDP ports are provided in [RFC7605]. A UDP sender SHOULD NOT use a source port value of zero. A source port number that cannot be easily determined from the address or payload type provides protection at the receiver from data injection attacks by off-path devices. A UDP receiver SHOULD NOT bind to port zero. Applications SHOULD implement receiver port and address checks at the application layer or explicitly request that the operating system filter the received packets to prevent receiving packets with an arbitrary port. This measure is designed to provide additional protection from data injection attacks from an off-path source (where the port values may not be known). Applications SHOULD provide a check that protects from off-path data injection, avoiding an application receiving packets that were created by an unauthorized third party. TCP stacks commonly use a randomized source port to provide this protection [RFC6056]; UDP applications should follow the same technique. Middleboxes and end systems often make assumptions about the system ports or user ports, hence it is recommended to use randomized ports in the Dynamic and/or Private Port range. Setting a "randomized" source port also provides greater assurance that reported ICMP errors originate from network systems on the path used by a particular flow. Some UDP applications choose to use a predetermined value for the source port (including some multicast applications), these applications need to therefore employ a different technique. Protection from off-path data attacks can also be provided by randomizing the initial value of another protocol field within the datagram payload, and checking the validity of this field at the receiver (e.g., RTP has random initial sequence number and random media timestamp offsets [RFC3550]). When using multicast, IP routers perform a reverse-path forwarding (RPF) check for each multicast packet. This provides protection from off-path data injection. When a receiver joins a multicast group and filters based on the source address the filter verifies the sender's IP address. This is always the case when using a SSM {S,G} channel. 5.1.1. Usage of UDP for source port entropy and the IPv6 Flow Label Some applications use the UDP datagram header as a source of entropy for network devices that implement ECMP [RFC6438]. A UDP tunnel application targeting this usage, encapsulates an inner packet using Eggert, et al. Expires April 17, 2017 [Page 33] Internet-Draft UDP Usage Guidelines October 2016 UDP, where the UDP source port value forms a part of the entropy that can be used to balance forwarding of network traffic by the devices that use ECMP. A sending tunnel endpoint selects a source port value in the UDP datagram header that is computed from the inner flow information (e.g., the encapsulated packet headers). To provide sufficient entropy the sending tunnel endpoint maps the encapsulated traffic to one of a range of UDP source values. The value SHOULD be within the ephemeral port range, i.e., 49152 to 65535, where the high order two bits of the port are set to one. The available source port entropy of 14 bits (using the ephemeral port range) plus the outer IP addresses seems sufficient for entropy for most ECMP applications [I-D.ietf-rtgwg-dt-encap]. To avoid reordering within an IP flow, the same UDP source port value SHOULD be used for all packets assigned to an encapsulated flow (e.g., using a hash of the relevant headers). The entropy mapping for a flow MAY change over the lifetime of the encapsulated flow [I-D.ietf-rtgwg-dt-encap]. For instance, this could be changed as a Denial of Service (DOS) mitigation, or as a means to effect routing through the ECMP network. However, the source port selected for a flow SHOULD NOT change more than once in every thirty seconds (e.g., as in [I-D.ietf-tsvwg-gre-in-udp-encap]). The use of the source port field for entropy has several side-effects that need to be considered, including: o It can increase the probability of misdelivery of corrupted packets, which increases the need for checksum computation or an equivalent mechanism to protect other UDP applications from misdelivery errors Section 3.4. o It is expected to reduce the probability of successful middlebox traversal Section 3.5. This use of the source port field will often not be suitable for applications targeting deployment in the general Internet. o It can prevent the field being usable to protect from off-path attacks (described in Section 5.1). Designers therefore need to consider other mechanisms to provide equivalent protection (e.g., to restrict use to a controlled environment [RFC7510] Section 3.6). The UDP source port number field has also been leveraged to produce entropy with IPv6. However, in the case of IPv6, the "flow label" [RFC6437] may also alternatively be used as entropy for load balancing [RFC6438]. This use of the flow label for load balancing is consistent with the definition of the field, although further clarity was needed to ensure the field can be consistently used for Eggert, et al. Expires April 17, 2017 [Page 34] Internet-Draft UDP Usage Guidelines October 2016 this purpose. Therefore, an updated IPv6 flow label [RFC6437] and ECMP routing [RFC6438] usage was specified. To ensure future opportunities to use the flow label, UDP applications SHOULD set the flow label field, even when an entropy value is also set in the source port field (e.g., An IPv6 tunnel endpoint could copy the source port flow entropy value to the IPv6 flow label field [I-D.ietf-tsvwg-gre-in-udp-encap]). Router vendors are encouraged to start using the IPv6 flow label as a part of the flow hash, providing support for IP-level ECMP without requiring use of UDP. The end-to-end use of flow labels for load balancing is a long-term solution. Even if the usage of the flow label has been clarified, there will be a transition time before a significant proportion of endpoints start to assign a good quality flow label to the flows that they originate. The use of load balancing using the transport header fields will likely continue until widespread deployment is finally achieved. 5.1.2. Applications using Multiple UDP Ports A single application may exchange several types of data. In some cases, this may require multiple UDP flows (e.g., multiple sets of flows, identified by different five-tuples). [RFC6335] recommends application developers not to apply to IANA to be assigned multiple well-known ports (user or system). This does not discuss the implications of using multiple flows with the same well-known port or pairs of dynamic ports (e.g., identified by a service name or signaling protocol). Use of multiple flows can affect the network in several ways: o Starting a series of successive connections can increase the number of state bindings in middleboxes (e.g., NAPT or Firewall) along the network path. UDP-based middlebox traversal usually relies on timeouts to remove old state, since middleboxes are unaware when a particular flow ceases to be used by an application. o Using several flows at the same time may result in seeing different network characteristics for each flow. It cannot be assumed both follow the same path (e.g., when ECMP is used, traffic is intentionally hashed onto different parallel paths based on the port numbers). o Using several flows can also increase the occupancy of a binding or lookup table in a middlebox (e.g., NAPT or Firewall), which may cause the device to change the way it manages the flow state. Eggert, et al. Expires April 17, 2017 [Page 35] Internet-Draft UDP Usage Guidelines October 2016 o Further, using excessive numbers of flows can degrade the ability of a unicast congestion control to react to congestion events, unless the congestion state is shared between all flows in a session. A receiver-driven multicast congestion control requires the sending application to distribute its data over a set of IP multicast groups, each receiver is therefore expected to receive data from a modest number of simultaneously active UDP ports. Therefore, applications MUST NOT assume consistent behavior of middleboxes when multiple UDP flows are used; many devices respond differently as the number of used ports increases. Using multiple flows with different QoS requirements requires applications to verify that the expected performance is achieved using each individual flow (five-tuple), see Section 3.1.9. 5.2. ICMP Guidelines Applications can utilize information about ICMP error messages that the UDP layer passes up for a variety of purposes [RFC1122]. Applications SHOULD appropriately validate the payload of ICMP messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to a UDP datagram actually sent by the application). This requires context, such as local state about communication instances to each destination, that although readily available in connection-oriented transport protocols is not always maintained by UDP-based applications. Note that not all platforms have the necessary APIs to support this validation, and some platforms already perform this validation internally before passing ICMP information to the application. Any application response to ICMP error messages SHOULD be robust to temporary routing failures (sometimes called "soft errors"), e.g., transient ICMP "unreachable" messages ought to not normally cause a communication abort. ICMP messages are being increasingly filtered by middleboxes. A UDP application therefore SHOULD NOT rely on their delivery for correct and safe operation. 6. Security Considerations UDP does not provide communications security. Applications that need to protect their communications against eavesdropping, tampering, or message forgery SHOULD employ end-to-end security services provided by other IETF protocols. Eggert, et al. Expires April 17, 2017 [Page 36] Internet-Draft UDP Usage Guidelines October 2016 UDP applications SHOULD provide protection from off-path data injection attacks using a randomized source port or equivalent technique (see Section 5.1). Applications that respond to short requests with potentially large responses are a potential vector for amplification attacks, and SHOULD take steps to minimize their potential for being abused as part of a DoS attack. That could mean authenticating the sender before responding; noting that the source IP address of a request is not a useful authenticator, because it can easily be spoofed. Or it may mean otherwise limiting the cases where short unauthenticated requests produce large responses. Applications MAY also want to offer ways to limit the number of requests they respond to in a time interval, in order to cap the bandwidth they consume. One option for securing UDP communications is with IPsec [RFC4301], which can provide authentication for flows of IP packets through the Authentication Header (AH) [RFC4302] and encryption and/or authentication through the Encapsulating Security Payload (ESP) [RFC4303]. Applications use the Internet Key Exchange (IKE) [RFC7296] to configure IPsec for their sessions. Depending on how IPsec is configured for a flow, it can authenticate or encrypt the UDP headers as well as UDP payloads. If an application only requires authentication, ESP with no encryption but with authentication is often a better option than AH, because ESP can operate across middleboxes. An application that uses IPsec requires the support of an operating system that implements the IPsec protocol suite, and the network path must permit IKE and IPsec traffic. This may become more common with IPv6 deployments [RFC6092]. Although it is possible to use IPsec to secure UDP communications, not all operating systems support IPsec or allow applications to easily configure it for their flows. A second option for securing UDP communications is through Datagram Transport Layer Security (DTLS) [RFC6347][RFC7525]. DTLS provides communication privacy by encrypting UDP payloads. It does not protect the UDP headers. Applications can implement DTLS without relying on support from the operating system. Many other options for authenticating or encrypting UDP payloads exist. For example, the GSS-API security framework [RFC2743] or Cryptographic Message Syntax (CMS) [RFC5652] could be used to protect UDP payloads. There exist a number of security options for RTP [RFC3550] over UDP, especially to accomplish key-management, see [RFC7201]. These options covers many usages, including point-to- point, centralized group communication as well as multicast. In some applications, a better solution is to protect larger stand-alone objects, such as files or messages, instead of individual UDP Eggert, et al. Expires April 17, 2017 [Page 37] Internet-Draft UDP Usage Guidelines October 2016 payloads. In these situations, CMS [RFC5652], S/MIME [RFC5751] or OpenPGP [RFC4880] could be used. In addition, there are many non- IETF protocols in this area. Like congestion control mechanisms, security mechanisms are difficult to design and implement correctly. It is hence RECOMMENDED that applications employ well-known standard security mechanisms such as DTLS or IPsec, rather than inventing their own. The Generalized TTL Security Mechanism (GTSM) [RFC5082] may be used with UDP applications when the intended endpoint is on the same link as the sender. This lightweight mechanism allows a receiver to filter unwanted packets. In terms of congestion control, [RFC2309] and [RFC2914] discuss the dangers of congestion-unresponsive flows to the Internet. [I-D.ietf-tsvwg-circuit-breaker] describes methods that can be used to set a performance envelope that can assist in preventing congestion collapse in the absence of congestion control or when the congestion control fails to react to congestion events. This document provides guidelines to designers of UDP-based applications to congestion-control their transmissions, and does not raise any additional security concerns. Some network operators have experienced surges of UDP attack traffic that are multiple orders of magnitude above the baseline traffic rate for UDP. This can motivate operators to limit the data rate or packet rate of UDP traffic. This may in turn limit the throughput that an application can achieve using UDP and could also result in higher packet loss for UDP traffic that would not be experienced if other transport protocols had been used. A UDP application with a long-lived association between the sender and receiver, ought to be designed so that the sender periodically checks that the receiver still wants ("consents") to receive traffic and need to be designed to stop if there is no explicit confirmation of this [RFC7675]. Applications that require communications in two directions to implement protocol functions (such as reliability or congestion control) will need to independently check both directions of communication, and may have to exchange keep-alive messages to traverse middleboxes (see Section 3.5). 7. Summary This section summarizes the key guidelines made in Sections 3 - 6 in a tabular format (Table 1) for easy referencing. +---------------------------------------------------------+---------+ Eggert, et al. Expires April 17, 2017 [Page 38] Internet-Draft UDP Usage Guidelines October 2016 | Recommendation | Section | +---------------------------------------------------------+---------+ | MUST tolerate a wide range of Internet path conditions | 3 | | SHOULD use a full-featured transport (e.g., TCP) | | | | | | SHOULD control rate of transmission | 3.1 | | SHOULD perform congestion control over all traffic | | | | | | for bulk transfers, | 3.1.2 | | SHOULD consider implementing TFRC | | | else, SHOULD in other ways use bandwidth similar to TCP | | | | | | for non-bulk transfers, | 3.1.3 | | SHOULD measure RTT and transmit max. 1 datagram/RTT | 3.1.1 | | else, SHOULD send at most 1 datagram every 3 seconds | | | SHOULD back-off retransmission timers following loss | | | | | | SHOULD provide mechanisms to regulate the bursts of | 3.1.6 | | transmission | | | | | | MAY implement ECN; a specific set of application | 3.1.7 | | mechanisms are REQUIRED if ECN is used. | | | | | | for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.8 | | | | | for QoS-enabled paths, MAY choose not to use CC | 3.1.9 | | | | | SHOULD NOT rely solely on QoS for their capacity | 3.1.10 | | non-CC controlled flows SHOULD implement a transport | | | circuit breaker | | | MAY implement a circuit breaker for other applications | | | | | | for tunnels carrying IP traffic, | 3.1.11 | | SHOULD NOT perform congestion control | | | MUST correctly process the IP ECN field | | | | | | for non-IP tunnels or rate not determined by traffic, | | | SHOULD perform CC or use circuit breaker | 3.1.11 | | SHOULD restrict types of traffic transported by the | | | tunnel | | | | | | SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | | SHOULD discover PMTU or send datagrams < minimum PMTU; | | | Specific application mechanisms are REQUIRED if PLPMTUD | | | is used. | | | | | | SHOULD handle datagram loss, duplication, reordering | 3.3 | | SHOULD be robust to delivery delays up to 2 minutes | | Eggert, et al. Expires April 17, 2017 [Page 39] Internet-Draft UDP Usage Guidelines October 2016 | | | | SHOULD enable IPv4 UDP checksum | 3.4 | | SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 | | mechanisms are REQUIRED if a zero IPv6 UDP checksum is | | | used. | | | | | | SHOULD provide protection from off-path attacks | 5.1 | | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 | | | | | SHOULD NOT always send middlebox keep-alive messages | 3.5 | | MAY use keep-alives when needed (min. interval 15 sec) | | | | | | Applications specified for use in limited use (or | 3.6 | | controlled environments) SHOULD identify equivalent | | | mechanisms and describe their use-case. | | | | | | Bulk multicast apps SHOULD implement congestion control | 4.1.1 | | | | | Low volume multicast apps SHOULD implement congestion | 4.1.2 | | control | | | | | | Multicast apps SHOULD use a safe PMTU | 4.2 | | | | | SHOULD avoid using multiple ports | 5.1.2 | | MUST check received IP source address | | | | | | SHOULD validate payload in ICMP messages | 5.2 | | | | | SHOULD use a randomized source port or equivalent | 6 | | technique, and, for client/server applications, SHOULD | | | send responses from source address matching request | | | | | | SHOULD use standard IETF security protocols when needed | 6 | +---------------------------------------------------------+---------+ Table 1: Summary of recommendations 8. IANA Considerations Note to RFC-Editor: please remove this entire section prior to publication. This document raises no IANA considerations. Eggert, et al. Expires April 17, 2017 [Page 40] Internet-Draft UDP Usage Guidelines October 2016 9. Acknowledgments The middlebox traversal guidelines in Section 3.5 incorporate ideas from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh, and Dan Kegel. The protocol timer guidelines in Section 3.1.1 were largely contributed by Mark Allman. G. Fairhurst received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644334 (NEAT). Lars Eggert has received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document reflects only the authors' views and the European Commission is not responsible for any use that may be made of the information it contains. 10. References 10.1. Normative References [I-D.ietf-tsvwg-circuit-breaker] Fairhurst, G., "Network Transport Circuit Breakers", draft-ietf-tsvwg-circuit-breaker-15 (work in progress), April 2016. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . Eggert, et al. Expires April 17, 2017 [Page 41] Internet-Draft UDP Usage Guidelines October 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, . [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, . Eggert, et al. Expires April 17, 2017 [Page 42] Internet-Draft UDP Usage Guidelines October 2016 10.2. Informative References [ALLMAN] Allman, M. and E. Blanton, "Notes on burst mitigation for transport protocols", March 2005. [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, March 1999. [I-D.ford-behave-app] Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", draft-ford-behave- app-05 (work in progress), March 2007. [I-D.ietf-aqm-ecn-benefits] Fairhurst, G. and M. Welzl, "The Benefits of using Explicit Congestion Notification (ECN)", draft-ietf-aqm- ecn-benefits-08 (work in progress), November 2015. [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-18 (work in progress), August 2016. [I-D.ietf-intarea-tunnels] Touch, J. and W. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-03 (work in progress), July 2016. [I-D.ietf-rtgwg-dt-encap] Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation Considerations", draft-ietf-rtgwg-dt-encap-01 (work in progress), March 2016. [I-D.ietf-tsvwg-gre-in-udp-encap] Yong, L., Crabbe, E., Xu, X., and T. Herbert, "GRE-in-UDP Encapsulation", draft-ietf-tsvwg-gre-in-udp-encap-19 (work in progress), September 2016. [POSIX] IEEE Std. 1003.1-2001, , "Standard for Information Technology - Portable Operating System Interface (POSIX)", Open Group Technical Standard: Base Specifications Issue 6, ISO/IEC 9945:2002, December 2001. Eggert, et al. Expires April 17, 2017 [Page 43] Internet-Draft UDP Usage Guidelines October 2016 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, . [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, . [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, November 1993, . [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, . [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, . [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, DOI 10.17487/RFC2887, August 2000, . [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, . Eggert, et al. Expires April 17, 2017 [Page 44] Internet-Draft UDP Usage Guidelines October 2016 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, DOI 10.17487/RFC3048, January 2001, . [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, DOI 10.17487/RFC3124, June 2001, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, . [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/RFC3738, April 2004, . Eggert, et al. Expires April 17, 2017 [Page 45] Internet-Draft UDP Usage Guidelines October 2016 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, . [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, . [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, . [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, . [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, . Eggert, et al. Expires April 17, 2017 [Page 46] Internet-Draft UDP Usage Guidelines October 2016 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . Eggert, et al. Expires April 17, 2017 [Page 47] Internet-Draft UDP Usage Guidelines October 2016 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, . [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, . [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, DOI 10.17487/RFC5973, October 2010, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . Eggert, et al. Expires April 17, 2017 [Page 48] Internet-Draft UDP Usage Guidelines October 2016 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format", RFC 6396, DOI 10.17487/RFC6396, October 2011, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, . [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, . [RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, "Population Count Extensions to Protocol Independent Multicast (PIM)", RFC 6807, DOI 10.17487/RFC6807, December 2012, . [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, . Eggert, et al. Expires April 17, 2017 [Page 49] Internet-Draft UDP Usage Guidelines October 2016 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, . [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . Eggert, et al. Expires April 17, 2017 [Page 50] Internet-Draft UDP Usage Guidelines October 2016 [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, "Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback", RFC 7560, DOI 10.17487/RFC7560, August 2015, . [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, . [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network Programming, The sockets Networking API", Addison-Wesley, 2004. [UPnP] UPnP Forum, , "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001. Eggert, et al. Expires April 17, 2017 [Page 51] Internet-Draft UDP Usage Guidelines October 2016 Appendix A. Case Study of the Use of IPv6 UDP Zero-Checksum Mode This appendix provides a brief review of MPLS-in-UDP as an example of a UDP Tunnel Encapsulation that defines a UDP encapsulation. The purpose of the appendix is to provide a concrete example of which mechanisms were required in order to safely use UDP zero-checksum mode for MPLS-in-UDP tunnels over IPv6. By default, UDP requires a checksum for use with IPv6. An option has been specified that permits a zero IPv6 UDP checksum when used in specific environments, specified in [RFC7510], and defines a set of operational constraints for use of this mode. These are summarized below: A UDP tunnel or encapsulation using a zero-checksum mode with IPv6 must only be deployed within a single network (with a single network operator) or networks of an adjacent set of co-operating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. MPLS-in-UDP has been specified for networks under single administrative control (such as within a single operator's network) where it is known (perhaps through knowledge of equipment types and lower layer checks) that packet corruption is exceptionally unlikely and where the operator is willing to take the risk of undetected packet corruption. The tunnel encapsulator SHOULD use different IPv6 addresses for each UDP tunnel that uses the UDP zero-checksum mode, regardless of the decapsulator, to strengthen the decapsulator's check of the IPv6 source address (i.e., the same IPv6 source address SHOULD NOT be used with more than one IPv6 destination address, independent of whether that destination address is a unicast or multicast address). Use of MPLS-in-UDP may be extended to networks within a set of closely cooperating network administrations (such as network operators who have agreed to work together to jointly provide specific services) [RFC7510]. The requirement for MPLS-in-UDP endpoints to check the source IPv6 address in addition to the destination IPv6 address, plus the strong recommendation against reuse of source IPv6 addresses among MPLS-in- UDP tunnels collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. In addition, the MPLS data plane only forwards packets with valid labels (i.e., labels that have been distributed by the tunnel egress Label Switched Router, LSR), providing some additional opportunity to detect MPLS-in-UDP packet misdelivery when the misdelivered packet contains a label that is not valid for forwarding at the receiving LSR. The expected result for IPv6 UDP zero-checksum mode for MPLS-in-UDP is that corruption of the destination IPv6 address will usually cause packet discard, as Eggert, et al. Expires April 17, 2017 [Page 52] Internet-Draft UDP Usage Guidelines October 2016 offsetting corruptions to the source IPv6 and/or MPLS top label are unlikely. Additional assurance is provided by the restrictions in the above exceptions that limit usage of IPv6 UDP zero-checksum mode to well- managed networks for which MPLS packet corruption has not been a problem in practice. Hence, MPLS-in-UDP is suitable for transmission over lower layers in well-managed networks that are allowed by the exceptions stated above and the rate of corruption of the inner IP packet on such networks is not expected to increase by comparison to MPLS traffic that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does not provide an additional integrity check when UDP zero-checksum mode is used with IPv6, and this design is in accordance with requirements 2, 3 and 5 specified in Section 5 of [RFC6936]. The MPLS-in-UDP encapsulation does not provide a mechanism to safely fall back to using a checksum when a path change occurs that redirects a tunnel over a path that includes a middlebox that discards IPv6 datagrams with a zero UDP checksum. In this case, the MPLS-in-UDP tunnel will be black-holed by that middlebox. Recommended changes to allow firewalls, NATs and other middleboxes to support use of an IPv6 zero UDP checksum are described in Section 5 of [RFC6936]. MPLS does not accumulate incorrect state as a consequence of label stack corruption. A corrupt MPLS label results in either packet discard or forwarding (and forgetting) of the packet without accumulation of MPLS protocol state. Active monitoring of MPLS-in-UDP traffic for errors is REQUIRED because the occurrence of errors will result in some accumulation of error information outside the MPLS protocol for operational and management purposes. This design is in accordance with requirement 4 specified in Section 5 of [RFC6936]. In addition, IPv6 traffic with a zero UDP checksum MUST be actively monitored for errors by the network operator. Operators SHOULD also deploy packet filters to prevent IPv6 packets with a zero UDP checksum from escaping from the network due to misconfiguration or packet errors. In addition, IPv6 traffic with a zero UDP checksum MUST be actively monitored for errors by the network operator. Appendix B. Revision Notes Note to RFC-Editor: please remove this entire section prior to publication. Changes in draft-ietf-tsvwg-rfc5405bis-19: o Addressed IESG review comments. Eggert, et al. Expires April 17, 2017 [Page 53] Internet-Draft UDP Usage Guidelines October 2016 Changes in draft-ietf-tsvwg-rfc5405bis-18: o Fix a nit. Changes in draft-ietf-tsvwg-rfc5405bis-17: o Incorporated text from Mark Allman for the section on "Protocol Timer Guidelines". Changes in draft-ietf-tsvwg-rfc5405bis-16: o Addressed suggestions by David Black. Changes in draft-ietf-tsvwg-rfc5405bis-15: o Addressed more suggestions by Takeshi Takahashi. Changes in draft-ietf-tsvwg-rfc5405bis-14: o Addressed SEC_DIR review by Takeshi Takahashi. o Addressed Gen-ART review by Paul Kyzivat. o Addressed OPS-DIR review by Tim Chown. o Addressed some of Mark Allman's comments regarding RTTs and RTOs. o Addressed some of Brian Trammell;s comments regarding new IETF transports. Changes in draft-ietf-tsvwg-rfc5405bis-13: o Minor corrections. o Changes recommended by Spencer Dawkins. o Placed the recommendations on timers within section 3.1 o Updated the recommendations on reliability to also reference the recommendations on timers. Changes in draft-ietf-tsvwg-rfc5405bis-12: o Introduced a separate section on the usage of timers to avoid repeating similar guidance in multiple sections. o Updated RTT measurement text to align with revised min RTO recommendation for TCP. Eggert, et al. Expires April 17, 2017 [Page 54] Internet-Draft UDP Usage Guidelines October 2016 o Updated text based on draft-ietf-tcpm-rto-consider-03 and to now cite this draft. o Fixed inconsistency in term used for keep-alive messages (keep- alive packet, keep-alives). Changes in draft-ietf-tsvwg-rfc5405bis-11: o Address some issues that idnits found. Changes in draft-ietf-tsvwg-rfc5405bis-10: o Restored changes from -08 that -09 accidentally rolled back. Changes in draft-ietf-tsvwg-rfc5405bis-09: o Fix to cross reference in summary table. Changes in draft-ietf-tsvwg-rfc5405bis-08: This update introduces new text in the following sections: o The ID from RTGWG on encap Section 7 makes recommendations on entropy. Section 5.1 of the 5405bis draft had a single sentence on use of the UDP source port to inject entropy. Related work such as UDP-in-MPLS and GRE-in-UDP have also made recommendations on entropy usage. A new section has been added to address this. o Added reference to RFC2983 on DSCP with tunnels. o New text after comment from David Black on needing to improve the header protection text. o Replaced replace /controlled network environment/ with /controlled environment/ to be more consistent with other drafts. o Section 3.1.7 now explicitly refers to the applicability subsection describing controlled environments. o PLPMTUD section updated. o Reworded checksum text to place IPv6 UDP zero checksum text in a separate subsection (this became too long in the main section) o Updated summary table Changes in draft-ietf-tsvwg-rfc5405bis-07: Eggert, et al. Expires April 17, 2017 [Page 55] Internet-Draft UDP Usage Guidelines October 2016 This update introduces new text in the following sections: o Addressed David Black's review during WG LC. Changes in draft-ietf-tsvwg-rfc5405bis-06: This update introduces new text in the following sections: o Multicast Congestion Control Guidelines (Section rewritten by Greg and Gorry to differentiate sender-driven and receiver-driven CC) o Using UDP Ports (Added a short para on RPF checks protecting from off-path attacks) o Applications using Multiple UDP Ports (Added text on layered multicast) Changes in draft-ietf-tsvwg-rfc5405bis-05: o Amended text in section discussing RTT for CC (feedback from Colin) Changes in draft-ietf-tsvwg-rfc5405bis-04: o Added text on consent freshness (STUN) - (From Colin) o Reworked text on ECN (From David) o Reworked text on RTT with CC (with help from Mirja) o Added references to [RFC7675], [I-D.ietf-rtgwg-dt-encap], [I-D.ietf-intarea-tunnels] and [RFC7510] Changes in draft-ietf-tsvwg-rfc5405bis-03: o Mention crypto hash in addition to CRC for integrity protection. (From Magnus.) o Mention PCP. (From Magnus.) o More accurate text on secure RTP (From Magnus.) o Reordered abstract to reflect .bis focus (Gorry) o Added a section on ECN, with actual ECN requirements (Gorry, help from Mirja) o Added section on Implications of RTT on Congestion Control (Gorry) Eggert, et al. Expires April 17, 2017 [Page 56] Internet-Draft UDP Usage Guidelines October 2016 o Added note that this refers to other protocols over IP (E Nordmark, rtg encaps guidance) o Added reordering text between sessions (consistent with use of ECMP, rtg encaps guidance) o Reworked text on off-path data protection (port usage) o Updated summary table Changes in draft-ietf-tsvwg-rfc5405bis-02: o Added note that guidance may be applicable beyond UDP to abstract (from Erik Nordmark). o Small editorial changes to fix English nits. o Added a circuit may provide benefit to CC tunnels by controlling envelope. o Added tunnels should ingress-filter by packet type (from Erik Nordmark). o Added tunnels should perform IETF ECN processing when supporting ECN. o Multicast apps may employ CC or a circuit breaker. o Added programming guidance on off-path attacks (with C. Perkins). o Added reference to ECN benefits. Changes in draft-ietf-tsvwg-rfc5405bis-01: o Added text on DSCP-usage. o More guidance on use of the checksum, including an example of how MPLS/UDP allowed support of a zero IPv6 UDP Checksum in some cases. o Added description of diffuse usage. o Clarified usage of the source port field. draft-eggert-tsvwg-rfc5405bis-01 was adopted by the TSVWG and resubmitted as draft-ietf-tsvwg-rfc5405bis-00. There were no technical changes. Eggert, et al. Expires April 17, 2017 [Page 57] Internet-Draft UDP Usage Guidelines October 2016 Changes in draft-eggert-tsvwg-rfc5405bis-01: o Added Greg Shepherd as a co-author, based on the multicast guidelines that originated with him. Changes in draft-eggert-tsvwg-rfc5405bis-00 (relative to RFC5405): o The words "application designers" were removed from the draft title and the wording of the abstract was clarified abstract. o New text to clarify various issues and set new recommendations not previously included in RFC 5405. These include new recommendations for multicast, the use of checksums with IPv6, ECMP, recommendations on port usage, use of ECN, use of DiffServ, circuit breakers (initial text), etc. Authors' Addresses Lars Eggert NetApp Sonnenallee 1 Kirchheim 85551 Germany Phone: +49 151 120 55791 EMail: lars@netapp.com URI: https://eggert.org/ Godred Fairhurst University of Aberdeen Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/ Greg Shepherd Cisco Systems Tasman Drive San Jose USA EMail: gjshep@gmail.com Eggert, et al. Expires April 17, 2017 [Page 58] ./draft-ietf-tsvwg-rtcweb-qos-18.txt0000664000764400076440000006310112755720053016630 0ustar iustyiusty Network Working Group P. Jones Internet-Draft S. Dhesikan Intended status: Standards Track C. Jennings Expires: February 20, 2017 Cisco Systems D. Druta AT&T August 19, 2016 DSCP Packet Markings for WebRTC QoS draft-ietf-tsvwg-rtcweb-qos-18 Abstract Many networks, such as service provider and enterprise networks, can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 20, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Jones, et al. Expires February 20, 2017 [Page 1] Internet-Draft WebRTC QoS August 2016 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Relation to Other Specifications . . . . . . . . . . . . . . 3 4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Downward References . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Document History . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Differentiated Services Code Point (DSCP) [RFC2474] packet marking can help provide QoS in some environments. This specification provides default packet marking for browsers that support WebRTC applications, but does not change any advice or requirements in other IETF RFCs. The contents of this specification are intended to be a simple set of implementation recommendations based on the previous RFCs. Networks where these DSCP markings are beneficial (likely to improve QoS for WebRTC traffic) include: 1. Private, wide-area networks. Network administrators have control over remarking packets and treatment of packets. 2. Residential Networks. If the congested link is the broadband uplink in a cable or DSL scenario, often residential routers/NAT support preferential treatment based on DSCP. 3. Wireless Networks. If the congested link is a local wireless network, marking may help. There are cases where these DSCP markings do not help, but, aside from possible priority inversion for "less than best effort traffic" Jones, et al. Expires February 20, 2017 [Page 2] Internet-Draft WebRTC QoS August 2016 (see Section 5), they seldom make things worse if packets are marked appropriately. DSCP values are in principle site specific, with each site selecting its own code points for controlling per-hop-behavior to influence the QoS for transport-layer flows. However in the WebRTC use cases, the browsers need to set them to something when there is no site specific information. This document describes a subset of DSCP code point values drawn from existing RFCs and common usage for use with WebRTC applications. These code points are intended to be the default values used by a WebRTC application. While other values could be used, using a non-default value may result in unexpected per-hop behavior. It is RECOMMENDED that WebRTC applications use non-default values only in private networks that are configured to use different values. This specification defines inputs that are provided by the WebRTC application hosted in the browser that aid the browser in determining how to set the various packet markings. The specification also defines the mapping from abstract QoS policies (flow type, priority level) to those packet markings. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms "browser" and "non-browser" are defined in [RFC7742] and carry the same meaning in this document. 3. Relation to Other Specifications This document is a complement to [RFC7657], which describes the interaction between DSCP and real-time communications. That RFC covers the implications of using various DSCP values, particularly focusing on Real-time Transport Protocol (RTP) [RFC3550] streams that are multiplexed onto a single transport-layer flow. There are a number of guidelines specified in [RFC7657] that apply to marking traffic sent by WebRTC applications, as it is common for multiple RTP streams to be multiplexed on the same transport-layer flow. Generally, the RTP streams would be marked with a value as appropriate from Table 1. A WebRTC application might also multiplex data channel [I-D.ietf-rtcweb-data-channel] traffic over the same 5-tuple as RTP streams, which would also be marked as per that table. The guidance in [RFC7657] says that all data channel traffic would be marked with a single value that is typically different than the Jones, et al. Expires February 20, 2017 [Page 3] Internet-Draft WebRTC QoS August 2016 value(s) used for RTP streams multiplexed with the data channel traffic over the same 5-tuple, assuming RTP streams are marked with a value other than default forwarding (DF). This is expanded upon further in the next section. This specification does not change or override the advice in any other IETF RFCs about setting packet markings. Rather, it simply selects a subset of DSCP values that is relevant in the WebRTC context. The DSCP value set by the endpoint is not trusted by the network. In addition, the DSCP value may be remarked at any place in the network for a variety of reasons to any other DSCP value, including default forwarding (DF) value to provide basic best effort service. Even so, there is benefit in marking traffic even if it only benefits the first few hops. The implications are discussed in Secton 3.2 of [RFC7657]. Further, a mitigation for such action is through an authorization mechanism. Such an authorization mechanism is outside the scope of this document. 4. Inputs WebRTC applications send and receive two types of flows of significance to this document: o media flows which are RTP streams [I-D.ietf-rtcweb-rtp-usage] o data flows which are data channels [I-D.ietf-rtcweb-data-channel] Each of the RTP streams and distinct data channels consists of all of the packets associated with an independent media entity, so an RTP stream or distinct data channel is not always equivalent to a transport-layer flow defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). There may be multiple RTP streams and data channels multiplexed over the same 5-tuple, with each having a different level of importance to the application and, therefore, potentially marked using different DSCP values than another RTP stream or data channel within the same transport-layer flow. (Note that there are restrictions with respect to marking different data channels carried within the same SCTP association as outlined in Section 5.) The following are the inputs provided by the WebRTC application to the browser: o Flow Type: The application provides this input because it knows if the flow is audio, interactive video [RFC4594] [G.1010] with or without audio, or data. Jones, et al. Expires February 20, 2017 [Page 4] Internet-Draft WebRTC QoS August 2016 o Application Priority: Another input is the relative importance of an RTP stream or data channel. Many applications have multiple flows of the same Flow Type and often some flows are more important than others. For example, in a video conference where there are usually audio and video flows, the audio flow may be more important than the video flow. JavaScript applications can tell the browser whether a particular flow is high, medium, low or very low importance to the application. [I-D.ietf-rtcweb-transports] defines in more detail what an individual flow is within the WebRTC context and priorities for media and data flows. Currently in WebRTC, media sent over RTP is assumed to be interactive [I-D.ietf-rtcweb-transports] and browser APIs do not exist to allow an application to to differentiate between interactive and non- interactive video. 5. DSCP Mappings The DSCP values for each flow type of interest to WebRTC based on application priority are shown in Table 1. These values are based on the framework and recommended values in [RFC4594]. A web browser SHOULD use these values to mark the appropriate media packets. More information on EF can be found in [RFC3246]. More information on AF can be found in [RFC2597]. DF is default forwarding which provides the basic best effort service [RFC2474]. WebRTC use of multiple DSCP values may encounter network blocking of packets with certain DSCP values. See section 4.2 of [I-D.ietf-rtcweb-transports] for further discussion, including how WebRTC implementations establish and maintain connectivity when such blocking is encountered. Jones, et al. Expires February 20, 2017 [Page 5] Internet-Draft WebRTC QoS August 2016 +------------------------+-------+------+-------------+-------------+ | Flow Type | Very | Low | Medium | High | | | Low | | | | +------------------------+-------+------+-------------+-------------+ | Audio | CS1 | DF | EF (46) | EF (46) | | | (8) | (0) | | | | | | | | | | Interactive Video with | CS1 | DF | AF42, AF43 | AF41, AF42 | | or without Audio | (8) | (0) | (36, 38) | (34, 36) | | | | | | | | Non-Interactive Video | CS1 | DF | AF32, AF33 | AF31, AF32 | | with or without Audio | (8) | (0) | (28, 30) | (26, 28) | | | | | | | | Data | CS1 | DF | AF11 | AF21 | | | (8) | (0) | | | +------------------------+-------+------+-------------+-------------+ Table 1: Recommended DSCP Values for WebRTC Applications The application priority, indicated by the columns "very low", "low", "Medium", and "high", signifies the relative importance of the flow within the application. It is an input that the browser receives to assist in selecting the DSCP value and adjusting the network transport behavior. The above table assumes that packets marked with CS1 are treated as "less than best effort", such as the LE behavior described in [RFC3662]. However, the treatment of CS1 is implementation dependent. If an implementation treats CS1 as other than "less than best effort", then the actual priority (or, more precisely, the per- hop-behavior) of the packets may be changed from what is intended. It is common for CS1 to be treated the same as DF, so applications and browsers using CS1 cannot assume that CS1 will be treated differently than DF [RFC7657]. However, it is also possible per [RFC2474] for CS1 traffic to be given better treatment than DF, thus caution should be exercised when electing to use CS1. This is one of the cases where marking packets using these recommendations can make things worse. Implementers should also note that excess EF traffic is dropped. This could mean that a packet marked as EF may not get through, although the same packet marked with a different DSCP value would have gotten through. This is not a flaw, but how excess EF traffic is intended to be treated. The browser SHOULD first select the flow type of the flow. Within the flow type, the relative importance of the flow SHOULD be used to select the appropriate DSCP value. Jones, et al. Expires February 20, 2017 [Page 6] Internet-Draft WebRTC QoS August 2016 Currently, all WebRTC video is assumed to be interactive [I-D.ietf-rtcweb-transports], for which the Interactive Video DSCP values in Table 1 SHOULD be used. Browsers MUST NOT use the AF3x DSCP values (for Non-Interactive Video in Table 1) for WebRTC applications. Non-browser implementations of WebRTC MAY use the AF3x DSCP values for video that is known not to be interactive, e.g., all video in a WebRTC video playback application that is not implemented in a browser. The combination of flow type and application priority provides specificity and helps in selecting the right DSCP value for the flow. All packets within a flow SHOULD have the same application priority. In some cases, the selected application priority cell may have multiple DSCP values, such as AF41 and AF42. These offer different drop precedences. The different drop precedence values provides additional granularity in classifying packets within a flow. For example, in a video conference the video flow may have medium application priority, thus either AF42 or AF43 may be selected. More important video packets (e.g., a video picture or frame encoded without any dependency on any prior pictures or frames) might be marked with AF42 and less important packets (e.g., a video picture or frame encoded based on the content of one or more prior pictures or frames) might be marked with AF43 (e.g., receipt of the more important packets enables a video renderer to continue after one or more packets are lost). It is worth noting that the application priority is utilized by the coupled congestion control mechanism for media flows per [I-D.ietf-rmcat-coupled-cc] and the SCTP scheduler for data channel traffic per [I-D.ietf-rtcweb-data-channel]. For reasons discussed in Section 6 of [RFC7657], if multiple flows are multiplexed using a reliable transport (e.g., TCP) then all of the packets for all flows multiplexed over that transport-layer flow MUST be marked using the same DSCP value. Likewise, all WebRTC data channel packets transmitted over an SCTP association MUST be marked using the same DSCP value, regardless of how many data channels (streams) exist or what kind of traffic is carried over the various SCTP streams. In the event that the browser wishes to change the DSCP value in use for an SCTP association, it MUST reset the SCTP congestion controller after changing values. Frequent changes in the DSCP value used for an SCTP association are discouraged, though, as this would defeat any attempts at effectively managing congestion. It should also be noted that any change in DSCP value that results in a reset of the congestion controller puts the SCTP association back into slow start, which may have undesirable effects on application performance. Jones, et al. Expires February 20, 2017 [Page 7] Internet-Draft WebRTC QoS August 2016 For the data channel traffic multiplexed over an SCTP association, it is RECOMMENDED that the DSCP value selected be the one associated with the highest priority requested for all data channels multiplexed over the SCTP association. Likewise, when multiplexing multiple flows over a TCP connection, the DCSP value selected should be the one associated with the highest priority requested for all multiplexed flows. If a packet enters a network that has no support for a flow type- application priority combination specified in Table 1, then the network node at the edge will remark the DSCP value based on policies. This could result in the flow not getting the network treatment it expects based on the original DSCP value in the packet. Subsequently, if the packet enters a network that supports a larger number of these combinations, there may not be sufficient information in the packet to restore the original markings. Mechanisms for restoring such original DSCP is outside the scope of this document. In summary, DSCP marking provides neither guarantees nor promised levels of service. However, DSCP marking is expected to provide a statistical improvement in real-time service as a whole. The service provided to a packet is dependent upon the network design along the path, as well as the network conditions at every hop. 6. Security Considerations Since the JavaScript application specifies the flow type and application priority that determine the media flow DSCP values used by the browser, the browser could consider application use of a large number of higher priority flows to be suspicious. If the server hosting the JavaScript application is compromised, many browsers within the network might simultaneously transmit flows with the same DSCP marking. The DiffServ architecture requires ingress traffic conditioning for reasons that include protecting the network from this sort of attack. Otherwise, this specification does not add any additional security implications beyond those addressed in the following DSCP-related specifications. For security implications on use of DSCP, please refer to Section 7 of [RFC7657] and Section 6 of [RFC4594]. Please also see [I-D.ietf-rtcweb-security] as an additional reference. 7. IANA Considerations This specification does not require any actions from IANA. Jones, et al. Expires February 20, 2017 [Page 8] Internet-Draft WebRTC QoS August 2016 8. Downward References This specification contains a downwards reference to [RFC4594] and [RFC7657]. However, the parts of the former RFC used by this specification are sufficiently stable for this downward reference. The guidance in the latter RFC is necessary to understand the Diffserv technology used in this document and the motivation for the recommended DSCP values and procedures. 9. Acknowledgements Thanks to David Black, Magnus Westerlund, Paolo Severini, Jim Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tuexen, and Brian Carpenter for their invaluable input. 10. Dedication This document is dedicated to the memory of James Polk, a long-time friend and colleague. James made important contributions to this specification, including serving initially as one of the primary authors. The IETF global community mourns his loss and he will be missed dearly. 11. Document History Note to RFC Editor: Please remove this section. This document was originally an individual submission in RTCWeb WG. The RTCWeb working group selected it to be become a WG document. Later the transport ADs requested that this be moved to the TSVWG WG as that seemed to be a better match. 12. References 12.1. Normative References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-rtcweb-rtp-usage] Perkins, D., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 2016. Jones, et al. Expires February 20, 2017 [Page 9] Internet-Draft WebRTC QoS August 2016 [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-15 (work in progress), August 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC7742] Roach, A., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, . 12.2. Informative References [G.1010] International Telecommunications Union, "End-user multimedia QoS categories", Recommendation ITU-T G.1010, November 2001. [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-03 (work in progress), July 2016. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/ RFC2597, June 1999, . Jones, et al. Expires February 20, 2017 [Page 10] Internet-Draft WebRTC QoS August 2016 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, . Authors' Addresses Paul E. Jones Cisco Systems Email: paulej@packetizer.com Subha Dhesikan Cisco Systems Email: sdhesika@cisco.com Cullen Jennings Cisco Systems Email: fluffy@cisco.com Dan Druta AT&T Email: dd5826@att.com Jones, et al. Expires February 20, 2017 [Page 11] ./draft-ietf-tsvwg-sctp-dtls-encaps-09.txt0000664000764400076440000004736312461002734017733 0ustar iustyiusty Network Working Group M. Tuexen Internet-Draft Muenster Univ. of Appl. Sciences Intended status: Standards Track R. Stewart Expires: July 28, 2015 Netflix, Inc. R. Jesup WorldGate Communications S. Loreto Ericsson January 24, 2015 DTLS Encapsulation of SCTP Packets draft-ietf-tsvwg-sctp-dtls-encaps-09.txt Abstract The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single homed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 28, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Tuexen, et al. Expires July 28, 2015 [Page 1] Internet-Draft SCTP over DTLS January 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3 4. General Considerations . . . . . . . . . . . . . . . . . . . 3 5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. NOTE to the RFC-Editor . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Overview The Stream Control Transmission Protocol (SCTP) as defined in [RFC4960] is a transport protocol running on top of the network protocols IPv4 [RFC0791] or IPv6 [RFC2460]. This document specifies how SCTP is used on top of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.0 is defined in [RFC4347] and the latest version when this RFC was published, DTLS 1.2, is defined in [RFC6347]. This encapsulation is used for example within the WebRTC protocol suite (see [I-D.ietf-rtcweb-overview] for an overview) for transporting non-SRTP data between browsers. The architecture of this stack is described in [I-D.ietf-rtcweb-data-channel]. [NOTE to RFC-Editor: Please ensure that the authors double check the above statement about DTLS 1.2 during AUTH48 and then remove this note before publication. ] Tuexen, et al. Expires July 28, 2015 [Page 2] Internet-Draft SCTP over DTLS January 2015 +----------+ | SCTP | +----------+ | DTLS | +----------+ | ICE/UDP | +----------+ Figure 1: Basic stack diagram This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see [RFC5245]) can provide a NAT traversal solution in addition to confidentiality, source authentication, and integrity protected transfers. Please note that using ICE does not necessarily imply that a different packet format is used on the wire. Please note that the procedures defined in [RFC6951] for dealing with the UDP port numbers do not apply here. When using the encapsulation defined in this document, SCTP is unaware about the protocols used below DTLS. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Encapsulation and Decapsulation Procedure When an SCTP packet is provided to the DTLS layer, the complete SCTP packet, consisting of the SCTP common header and a number of SCTP chunks, is handled as the payload of the application layer protocol of DTLS. When the DTLS layer has processed a DTLS record containing a message of the application layer protocol, the payload is passed to the SCTP layer. The SCTP layer expects an SCTP common header followed by a number of SCTP chunks. 4. General Considerations An implementation of SCTP over DTLS MUST implement and use a path maximum transmission unit (MTU) discovery method that functions without ICMP to provide SCTP/DTLS with an MTU estimate. An implementation of "Packetization Layer Path MTU Discovery" [RFC4821] either in SCTP or DTLS is RECOMMENDED. The path MTU discovery is performed by SCTP when SCTP over DTLS is used for data channels (see Section 5 of [I-D.ietf-rtcweb-data-channel]). Tuexen, et al. Expires July 28, 2015 [Page 3] Internet-Draft SCTP over DTLS January 2015 5. DTLS Considerations The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD support the most recently published version of DTLS, which was DTLS 1.2 [RFC6347] when this RFC was published. In the absence of a revision to this document, the latter requirement applies to all future versions of DTLS when they are published as RFCs. This document will only be revised if a revision to DTLS or SCTP makes a revision to the encapsulation necessary. [NOTE to RFC-Editor: Please ensure that the authors double check the above statement about DTLS 1.2 during AUTH48 and then remove this note before publication. ] SCTP performs segmentation and reassembly based on the path MTU. Therefore the DTLS layer MUST NOT use any compression algorithm. The DTLS MUST support sending messages larger than the current path MTU. This might result in sending IP level fragmented messages. If path MTU discovery is performed by the DTLS layer, the method described in [RFC4821] MUST be used. For probe packets, the extension defined in [RFC6520] MUST be used. If path MTU discovery is performed by the SCTP layer and IPv4 is used as the network layer protocol, the DTLS implementation SHOULD allow the DTLS user to enforce that the corresponding IPv4 packet is sent with the Don't Fragment (DF) bit set. If controlling the DF bit is not possible, for example due to implementation restrictions, a safe value for the path MTU has to be used by the SCTP stack. It is RECOMMENDED that the safe value does not exceed 1200 bytes. Please note that [RFC1122] only requires end hosts to be able to reassemble fragmented IP packets up to 576 bytes in length. The DTLS implementation SHOULD allow the DTLS user to set the Differentiated services code point (DSCP) used for IP packets being sent (see [RFC2474]). This requires the DTLS implementation to pass the value through and the lower layer to allow setting this value. If the lower layer does not support setting the DSCP, then the DTLS user will end up with the default value used by protocol stack. Please note that only a single DSCP value can be used for all packets belonging to the same SCTP association. Tuexen, et al. Expires July 28, 2015 [Page 4] Internet-Draft SCTP over DTLS January 2015 Using explicit congestion notifications (ECN) in SCTP requires the DTLS layer to pass the ECN bits through and its lower layer to expose access to them for sent and received packets (see [RFC3168]). The implementation of DTLS and its lower layer have to provide this support. If this is not possible, for example due to implementation restrictions, ECN can't be used by SCTP. 6. SCTP Considerations This section describes the usage of the base protocol and the applicability of various SCTP extensions. 6.1. Base Protocol This document uses SCTP [RFC4960] with the following restrictions, which are required to reflect that the lower layer is DTLS instead of IPv4 and IPv6 and that SCTP does not deal with the IP addresses or the transport protocol used below DTLS: o A DTLS connection MUST be established before an SCTP association can be set up. o Multiple SCTP associations MAY be multiplexed over a single DTLS connection. The SCTP port numbers are used for multiplexing and demultiplexing the SCTP associations carried over a single DTLS connection. o All SCTP associations are single-homed, because DTLS does not expose any address management to its upper layer. Therefore it is RECOMMENDED to set the SCTP parameter path.max.retrans to association.max.retrans. o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or IPv6 Address parameters. The INIT chunk MUST NOT contain the Supported Address Types parameter. o The implementation MUST NOT rely on processing ICMP or ICMPv6 packets, since the SCTP layer most likely is unable to access the SCTP common header in the plain text of the packet, which triggered the sending of the ICMP or ICMPv6 packet. This applies in particular to path MTU discovery when performed by SCTP. o If the SCTP layer is notified about a path change by its lower layers, SCTP SHOULD retest the Path MTU and reset the congestion state to the initial state. The window-based congestion control method specified in [RFC4960], resets the congestion window and slow start threshold to their initial values. Tuexen, et al. Expires July 28, 2015 [Page 5] Internet-Draft SCTP over DTLS January 2015 6.2. Padding Extension When the SCTP layer performs path MTU discovery as specified in [RFC4821], the padding extension defined in [RFC4820] MUST be supported and used for probe packets (HEARTBEAT chunks bundled with PADDING chunks [RFC4820]). 6.3. Dynamic Address Reconfiguration Extension If the dynamic address reconfiguration extension defined in [RFC5061] is used, ASCONF chunks MUST use wildcard addresses only. 6.4. SCTP Authentication Extension The SCTP authentication extension defined in [RFC4895] can be used with DTLS encapsulation, but does not provide any additional benefit. 6.5. Partial Reliability Extension Partial reliability as defined in [RFC3758] can be used in combination with DTLS encapsulation. It is also possible to use additional PR-SCTP policies, for example the ones defined in [I-D.ietf-tsvwg-sctp-prpolicies]. 6.6. Stream Reset Extension The SCTP stream reset extension defined in [RFC6525] can be used with DTLS encapsulation. It is used to reset SCTP streams and add SCTP streams during the lifetime of the SCTP association. 6.7. Interleaving of Large User Messages SCTP as defined in [RFC4960] does not support the interleaving of large user messages that need to be fragmented and reassembled by the SCTP layer. The protocol extension defined in [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and can be used with DTLS encapsulation. 7. IANA Considerations This document requires no actions from IANA. 8. Security Considerations Security considerations for DTLS are specified in [RFC4347] and for SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP and DTLS introduces no new security considerations. Tuexen, et al. Expires July 28, 2015 [Page 6] Internet-Draft SCTP over DTLS January 2015 SCTP should not process the IP addresses used for the underlying communication since DTLS provides no guarantees about them. It should be noted that the inability to process ICMP or ICMPv6 messages does not add any security issue. When SCTP is carried over a connection-less lower layer like IPv4, IPv6, or UDP, processing of these messages is required to protect other nodes not supporting SCTP. Since DTLS provides a connection-oriented lower layer, this kind of protection is not necessary. 9. Acknowledgments The authors wish to thank David Black, Benoit Claise, Spencer Dawkins, Francis Dupont, Gorry Fairhurst, Stephen Farrell, Christer Holmberg, Barry Leiba, Eric Rescorla, Tom Taylor, Joe Touch and Magnus Westerlund for their invaluable comments. 10. References 10.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012. Tuexen, et al. Expires July 28, 2015 [Page 7] Internet-Draft SCTP over DTLS January 2015 10.2. Informative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012. [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, May 2013. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-13 (work in progress), November 2014. Tuexen, et al. Expires July 28, 2015 [Page 8] Internet-Draft SCTP over DTLS January 2015 [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-tsvwg-sctp-prpolicies] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol", draft-ietf- tsvwg-sctp-prpolicies-06 (work in progress), December 2014. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and a New Data Chunk for the Stream Control Transmission Protocol", draft-ietf-tsvwg-sctp- ndata-02 (work in progress), January 2015. Appendix A. NOTE to the RFC-Editor Although the references to [I-D.ietf-tsvwg-sctp-prpolicies] and [I-D.ietf-tsvwg-sctp-ndata] are informative, put this document in REF-HOLD until these two references have been approved and update these references to the corresponding RFCs. Authors' Addresses Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt DE Email: tuexen@fh-muenster.de Randall R. Stewart Netflix, Inc. Chapin, SC 29036 US Email: randall@lakerest.net Tuexen, et al. Expires July 28, 2015 [Page 9] Internet-Draft SCTP over DTLS January 2015 Randell Jesup WorldGate Communications 3800 Horizon Blvd, Suite #103 Trevose, PA 19053-4947 US Phone: +1-215-354-5166 Email: randell_ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 FI Email: Salvatore.Loreto@ericsson.com Tuexen, et al. Expires July 28, 2015 [Page 10] ./draft-leiba-3967upd-downref-03.txt0000664000764400076440000001433213022552135016266 0ustar iustyiusty Network Working Group B. Leiba Internet-Draft Huawei Technologies Updates: 3967 (if approved) December 09, 2016 Intended status: Best Current Practice Expires: June 10, 2017 Updating when Standards Track Documents may Refer Normatively to Documents at a Lower Level draft-leiba-3967upd-downref-03 Abstract RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the last call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 10, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Leiba Expires June 10, 2017 [Page 1] Internet-Draft Document Down-Ref Update December 2016 [RFC3967] notes the importance of assuring that normative references from Standards Track and Best Current Practice (BCP) documents are appropriately mature, and specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"). That process starts at Last Call (see Section 3 of [RFC3967]): For Standards Track or BCP documents requiring normative reference to documents of lower maturity, the normal IETF Last Call procedure will be issued, with the need for the downward reference explicitly documented in the Last Call itself. Any community comments on the appropriateness of downward references will be considered by the IESG as part of its deliberations. Section 2 of [RFC3967] lists some conditions under which downrefs may make sense. In addition to those, it has become common for working groups to produce foundational documents at Informational status, which contain important information such as terminology definitions and architectural design and considerations, and those documents are often needed as normative references in the Standards Track protocol documents that follow. The requirement to explicitly mention the downrefs and the need for them in the Last Call message has proven to be unnecessarily restrictive, and has often resulted in unnecessary repetitions of Last Call, with the corresponding delay and with no real benefit. 2. The IESG's Responsibility with Respect to Downrefs The process in RFC 3967 is hereby updated to specify that explicitly documenting the downward references in the Last Call message is strongly recommended, but not required. The responsible AD should still check for downrefs before sending out the last call notice, but if an undetected downref is noticed during last call or IESG review, any need to repeat the last call is at the discretion of the IESG. However, the process in RFC 3967 is not fundamentally altered: If the IESG decides not to repeat the last call, the status of the affected downrefs is not changed, and the process in RFC 3967 will still apply if those downrefs are used in the future. This gives the IESG the responsibility to determine the actual maturity level of the downward reference with respect to the document at hand, and to decide whether or not it is necessary to explicitly ask the IETF community for comments on the downref on a case-by-case basis. In making that decision, the IESG should take into account the general discussion in RFC 3967. The responsible AD should make sure that the omission is recorded as a comment in the datatracker. 3. IANA Considerations There are no IANA considerations for this document. 4. Security Considerations Leiba Expires June 10, 2017 [Page 2] Internet-Draft Document Down-Ref Update December 2016 Referencing immature protocols can have security and stability implications, and the IESG should take that into account when deciding whether re-consulting the community is useful. 5. Normative References [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December 2004, . Author's Address Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.org/ Leiba Expires June 10, 2017 [Page 3] ./draft-moriarty-pkcs5-v2dot1-04.txt0000664000764400076440000022160712763706725016466 0ustar iustyiusty INTERNET-DRAFT K. Moriarty, Ed. Intended Status: Informational EMC Obsoletes: 2898 (once approved) B. Kaliski Expires: March 13, 2017 Verisign A. Rusch RSA September 6, 2016 PKCS #5: Password-Based Cryptography Specification Version 2.1 draft-moriarty-pkcs5-v2dot1-04 Abstract This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys, as in PKCS #8. It is expected that application standards and implementation profiles based on these specifications may include additional constraints. Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope. This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 2898. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Salt and Iteration Count . . . . . . . . . . . . . . . . . . . 6 4.1. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Iteration Count . . . . . . . . . . . . . . . . . . . . . . 8 5. Key Derivation Functions . . . . . . . . . . . . . . . . . . . 8 5.1. PBKDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Encryption Schemes . . . . . . . . . . . . . . . . . . . . . . 12 6.1. PBES1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. PBES1 Encryption Operation . . . . . . . . . . . . . . 12 6.1.2. PBES1 Decryption Operation . . . . . . . . . . . . . . 13 6.2. PBES2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2.1. PBES2 Encryption Operation . . . . . . . . . . . . . . 14 6.2.2. PBES2 Decryption Operation . . . . . . . . . . . . . . 15 7. Message Authentication Schemes . . . . . . . . . . . . . . . . 16 7.1. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1.1 PBMAC1 Generation Operation . . . . . . . . . . . . . . 16 7.1.2. PBMAC1 Verification Operation . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1. PBKDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.3. PBES1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4. PBES2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.5. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B. Supporting Techniques . . . . . . . . . . . . . . . . . . . . . 22 B.1. Pseudorandom functions . . . . . . . . . . . . . . . . . . 22 B.1.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . . 22 B.1.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . . 23 B.2. Encryption Schemes . . . . . . . . . . . . . . . . . . . . 24 B.2.1. DES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 24 B.2.2. DES-EDE3-CBC-Pad . . . . . . . . . . . . . . . . . . . 25 B.2.3. RC2-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 25 B.2.4. RC5-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 26 B.2.5. AES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 27 B.3. Message Authentication Schemes . . . . . . . . . . . . . . 27 B.3.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . . 27 B.3.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . . 28 C. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 28 D. Intellectual Property Considerations . . . . . . . . . . . . . 32 E. Revision History . . . . . . . . . . . . . . . . . . . . . . . 32 F. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 F.1 Normative References . . . . . . . . . . . . . . . . . . . 34 G. About PKCS . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This document provides recommendations for the implementation of password-based cryptography, covering the following aspects: - key derivation functions - encryption schemes - message-authentication schemes - ASN.1 syntax identifying the techniques The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys as in PKCS #8 [PKCS8][RFC5958]. It is expected that application standards and implementation profiles based on these specifications may include additional constraints. Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols [BELLOV][JABLON][WU] are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope. This document supersedes PKCS #5 version 2.0 [RFC2898], but includes compatible techniques. 2. Notation C ciphertext, an octet string c iteration count, a positive integer DK derived key, an octet string dkLen length in octets of derived key, a positive integer EM encoded message, an octet string Hash underlying hash function hLen length in octets of pseudorandom function output, a positive integer l length in blocks of derived key, a positive integer IV initialization vector, an octet string K encryption key, an octet string KDF key derivation function M message, an octet string P password, an octet string PRF underlying pseudorandom function PS padding string, an octet string psLen length in octets of padding string, a positive integer S salt, an octet string T message authentication code, an octet string T_1, ..., T_l, U_1, ..., U_c intermediate values, octet strings 01, 02, ..., 08 octets with value 1, 2, ..., 8 \xor bit-wise exclusive-or of two octet strings || || octet length operator || concatenation operator substring extraction operator: extracts octets i through j, 0 <= i <= j 3. Overview In many applications of public-key cryptography, user security is ultimately dependent on one or more secret text values or passwords. Since a password is not directly applicable as a key to any conventional cryptosystem, however, some processing of the password is required to perform cryptographic operations with it. Moreover, as passwords are often chosen from a relatively small space, special care is required in that processing to defend against search attacks. A general approach to password-based cryptography, as described by Morris and Thompson [MORRIS] for the protection of password tables, is to combine a password with a salt to produce a key. The salt can be viewed as an index into a large set of keys derived from the password, and need not be kept secret. Although it may be possible for an opponent to construct a table of possible passwords (a so- called "dictionary attack"), constructing a table of possible keys will be difficult, since there will be many possible keys for each password. An opponent will thus be limited to searching through passwords separately for each salt. Another approach to password-based cryptography is to construct key derivation techniques that are relatively expensive, thereby increasing the cost of exhaustive search. One way to do this is to include an iteration count in the key derivation technique, indicating how many times to iterate some underlying function by which keys are derived. A modest number of iterations, say 1000, is not likely to be a burden for legitimate parties when computing a key, but will be a significant burden for opponents. Salt and iteration count formed the basis for password-based encryption in PKCS #5 v2.0, and adopted here as well for the various cryptographic operations. Thus, password-based key derivation as defined here is a function of a password, a salt, and an iteration count, where the latter two quantities need not be kept secret. From a password-based key derivation function, it is straightforward to define password-based encryption and message authentication schemes. As in PKCS #5 v2.0, the password-based encryption schemes here are based on an underlying, conventional encryption scheme, where the key for the conventional scheme is derived from the password. Similarly, the password-based message authentication scheme is based on an underlying conventional scheme. This two-layered approach makes the password-based techniques modular in terms of the underlying techniques they can be based on. It is expected that the password-based key derivation functions may find other applications than just the encryption and message authentication schemes defined here. For instance, one might derive a set of keys with a single application of a key derivation function, rather than derive each key with a separate application of the function. The keys in the set would be obtained as substrings of the output of the key derivation function. This approach might be employed as part of key establishment in a session-oriented protocol. Another application is password checking, where the output of the key derivation function is stored (along with the salt and iteration count) for the purposes of subsequent verification of a password. Throughout this document, a password is considered to be an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 [RFC2279] are two possibilities. (ASCII is a subset of UTF-8.) Although the selection of passwords is outside the scope of this document, guidelines have been published [NISTSP63] that may well be taken into account. 4. Salt and Iteration Count Inasmuch as salt and iteration count are central to the techniques defined in this document, some further discussion is warranted. 4.1. Salt A salt in password-based cryptography has traditionally served the purpose of producing a large set of keys corresponding to a given password, among which one is selected at random according to the salt. An individual key in the set is selected by applying a key derivation function KDF, as DK = KDF (P, S) where DK is the derived key, P is the password, and S is the salt. This has two benefits: 1. It is difficult for an opponent to precompute all the keys corresponding to a dictionary of passwords, or even the most likely keys. If the salt is 64 bits long, for instance, there will be as many as 2^64 keys for each password. An opponent is thus limited to searching for passwords after a password-based operation has been performed and the salt is known. 2. It is unlikely that the same key will be selected twice. Again, if the salt is 64 bits long, the chance of "collision" between keys does not become significant until about 2^32 keys have been produced, according to the Birthday Paradox. This addresses some of the concerns about interactions between multiple uses of the same key, which may apply for some encryption and authentication techniques. In password-based encryption, the party encrypting a message can gain assurance that these benefits are realized simply by selecting a large and sufficiently random salt when deriving an encryption key from a password. A party generating a message authentication code can gain such assurance in a similar fashion. The party decrypting a message or verifying a message authentication code, however, cannot be sure that a salt supplied by another party has actually been generated at random. It is possible, for instance, that the salt may have been copied from another password-based operation, in an attempt to exploit interactions between multiple uses of the same key. For instance, suppose two legitimate parties exchange a encrypted message, where the encryption key is an 80-bit key derived from a shared password with some salt. An opponent could take the salt from that encryption and provide it to one of the parties as though it were for a 40-bit key. If the party reveals the result of decryption with the 40-bit key, the opponent may be able to solve for the 40-bit key. In the case that 40-bit key is the first half of the 80-bit key, the opponent can then readily solve for the remaining 40 bits of the 80-bit key. To defend against such attacks, either the interaction between multiple uses of the same key should be carefully analyzed, or the salt should contain data that explicitly distinguishes between different operations. For instance, the salt might have an additional, non-random octet that specifies whether the derived key is for encryption, for message authentication, or for some other operation. Based on this, the following is recommended for salt selection: 1. If there is no concern about interactions between multiple uses of the same key (or a prefix of that key) with the password- based encryption and authentication techniques supported for a given password, then the salt may be generated at random and need not be checked for a particular format by the party receiving the salt. It should be at least eight octets (64 bits) long. 2. Otherwise, the salt should contain data that explicitly distinguishes between different operations and different key lengths, in addition to a random part that is at least eight octets long, and this data should be checked or regenerated by the party receiving the salt. For instance, the salt could have an additional non-random octet that specifies the purpose of the derived key. Alternatively, it could be the encoding of a structure that specifies detailed information about the derived key, such as the encryption or authentication technique and a sequence number among the different keys derived from the password. The particular format of the additional data is left to the application. Note. If a random number generator or pseudorandom generator is not available, a deterministic alternative for generating the salt (or the random part of it) is to apply a password-based key derivation function to the password and the message M to be processed. For instance, the salt could be computed with a key derivation function as S = KDF (P, M). This approach is not recommended if the message M is known to belong to a small message space (e.g., "Yes" or "No"), however, since then there will only be a small number of possible salts. 4.2. Iteration Count An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. Mathematically, an iteration count of c will increase the security strength of a password by log2(c) bits against trial based attacks like brute force or dictionary attacks. Choosing a reasonable value for the iteration count depends on environment and circumstances, and varies from application to application. This document follows the recommendations made in FIPS Special Publication 800-132 [NISTSP132], which says "The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. [...] A minimum iteration count of 1,000 is recommended. For especially critical keys, or for very powerful systems or systems where user-perceived performance is not critical, an iteration count of 10,000,000 may be appropriate". 5. Key Derivation Functions A key derivation function produces a derived key from a base key and other parameters. In a password-based key derivation function, the base key is a password and the other parameters are a salt value and an iteration count, as outlined in Section 3. The primary application of the password-based key derivation functions defined here is in the encryption schemes in Section 6 and the message authentication scheme in Section 7. Other applications are certainly possible, hence the independent definition of these functions. Two functions are specified in this section: PBKDF1 and PBKDF2. PBKDF2 is recommended for new applications; PBKDF1 is included only for compatibility with existing applications, and is not recommended for new applications. A typical application of the key derivation functions defined here might include the following steps: 1. Select a salt S and an iteration count c, as outlined in Section 4. 2. Select a length in octets for the derived key, dkLen. 3. Apply the key derivation function to the password, the salt, the iteration count and the key length to produce a derived key. 4. Output the derived key. Any number of keys may be derived from a password by varying the salt, as described in Section 3. 5.1. PBKDF1 PBKDF1 applies a hash function, which shall be MD2 [RFC1319], MD5 [RFC1321] or SHA-1 [NIST180], to derive keys. The length of the derived key is bounded by the length of the hash function output, which is 16 octets for MD2 and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key derivation process in PKCS #5 v1.5 [PKCS5_15]. PBKDF1 is recommended only for compatibility with existing applications since the keys it produces may not be large enough for some applications. PBKDF1 (P, S, c, dkLen) Options: Hash underlying hash function Input: P password, an octet string S salt, an octet string c iteration count, a positive integer dkLen intended length in octets of derived key, a positive integer, at most 16 for MD2 or MD5 and 20 for SHA-1 Output: DK derived key, a dkLen-octet string Steps: 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output "derived key too long" and stop. 2. Apply the underlying hash function Hash for c iterations to the concatenation of the password P and the salt S, then extract the first dkLen octets to produce a derived key DK: T_1 = Hash (P || S) , T_2 = Hash (T_1) , ... T_c = Hash (T_{c-1}) , DK = T_c<0..dkLen-1> 3. Output the derived key DK. 5.2. PBKDF2 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an example) to derive keys. The length of the derived key is essentially unbounded. (However, the maximum effective search space for the derived key may be limited by the structure of the underlying pseudorandom function. See Appendix B.1 for further discussion.) PBKDF2 is recommended for new applications. PBKDF2 (P, S, c, dkLen) Options: PRF underlying pseudorandom function (hLen denotes the length in octets of the pseudorandom function output) Input: P password, an octet string S salt, an octet string c iteration count, a positive integer dkLen intended length in octets of the derived key, a positive integer, at most (2^32 - 1) * hLen Output: DK derived key, a dkLen-octet string Steps: 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" and stop. 2. Let l be the number of hLen-octet blocks in the derived key, rounding up, and let r be the number of octets in the last block: l = CEIL (dkLen / hLen) , r = dkLen - (l - 1) * hLen . Here, CEIL (x) is the "ceiling" function, i.e. the smallest integer greater than, or equal to, x. 3. For each block of the derived key apply the function F defined below to the password P, the salt S, the iteration count c, and the block index to compute the block: T_1 = F (P, S, c, 1) , T_2 = F (P, S, c, 2) , ... T_l = F (P, S, c, l) , where the function F is defined as the exclusive-or sum of the first c iterates of the underlying pseudorandom function PRF applied to the password P and the concatenation of the salt S and the block index i: F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c where U_1 = PRF (P, S || INT (i)) , U_2 = PRF (P, U_1) , ... U_c = PRF (P, U_{c-1}) . Here, INT (i) is a four-octet encoding of the integer i, most significant octet first. 4. Concatenate the blocks and extract the first dkLen octets to produce a derived key DK: DK = T_1 || T_2 || ... || T_l<0..r-1> 5. Output the derived key DK. Note. The construction of the function F follows a "belt-and- suspenders" approach. The iterates U_i are computed recursively to remove a degree of parallelism from an opponent; they are exclusive- ored together to reduce concerns about the recursion degenerating into a small set of values. 6. Encryption Schemes An encryption scheme, in the symmetric setting, consists of an encryption operation and a decryption operation, where the encryption operation produces a ciphertext from a message under a key, and the decryption operation recovers the message from the ciphertext under the same key. In a password-based encryption scheme, the key is a password. A typical application of a password-based encryption scheme is a private-key protection method, where the message contains private-key information, as in PKCS #8. The encryption schemes defined here would be suitable encryption algorithms in that context. Two schemes are specified in this section: PBES1 and PBES2. PBES2 is recommended for new applications; PBES1 is included only for compatibility with existing applications, and is not recommended for new applications. 6.1. PBES1 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying block cipher, which shall be either DES [NIST46] or RC2(tm) [RFC2268] in CBC mode [NIST81]. PBES1 is compatible with the encryption scheme in PKCS #5 v1.5 [PKCS5_15]. PBES1 is recommended only for compatibility with existing applications, since it supports only two underlying encryption schemes, each of which has a key size (56 or 64 bits) that may not be large enough for some applications. 6.1.1. PBES1 Encryption Operation The encryption operation for PBES1 consists of the following steps, which encrypt a message M under a password P to produce a ciphertext C: 1. Select an eight-octet salt S and an iteration count c, as outlined in Section 4. 2. Apply the PBKDF1 key derivation function (Section 5.1) to the password P, the salt S, and the iteration count c to produce at derived key DK of length 16 octets: DK = PBKDF1 (P, S, c, 16) . 3. Separate the derived key DK into an encryption key K consisting of the first eight octets of DK and an initialization vector IV consisting of the next eight octets: K = DK<0..7> , IV = DK<8..15> . 4. Concatenate M and a padding string PS to form an encoded message EM: EM = M || PS , where the padding string PS consists of 8-(||M|| mod 8) octets each with value 8-(||M|| mod 8). The padding string PS will satisfy one of the following statements: PS = 01, if ||M|| mod 8 = 7 ; PS = 02 02, if ||M|| mod 8 = 6 ; ... PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0. The length in octets of the encoded message will be a multiple of eight and it will be possible to recover the message M unambiguously from the encoded message. (This padding rule is taken from RFC 1423 [RFC1423].) 5. Encrypt the encoded message EM with the underlying block cipher (DES or RC2) in cipher block chaining mode under the encryption key K with initialization vector IV to produce the ciphertext C. For DES, the key K shall be considered as a 64-bit encoding of a 56-bit DES key with parity bits ignored (see [NIST46]). For RC2, the "effective key bits" shall be 64 bits. 6. Output the ciphertext C. The salt S and the iteration count c may be conveyed to the party performing decryption in an AlgorithmIdentifier value (see Appendix A.3). 6.1.2. PBES1 Decryption Operation The decryption operation for PBES1 consists of the following steps, which decrypt a ciphertext C under a password P to recover a message M: 1. Obtain the eight-octet salt S and the iteration count c. 2. Apply the PBKDF1 key derivation function (Section 5.1) to the password P, the salt S, and the iteration count c to produce a derived key DK of length 16 octets: DK = PBKDF1 (P, S, c, 16) 3. Separate the derived key DK into an encryption key K consisting of the first eight octets of DK and an initialization vector IV consisting of the next eight octets: K = DK<0..7> , IV = DK<8..15> . 4. Decrypt the ciphertext C with the underlying block cipher (DES or RC2) in cipher block chaining mode under the encryption key K with initialization vector IV to recover an encoded message EM. If the length in octets of the ciphertext C is not a multiple of eight, output "decryption error" and stop. 5. Separate the encoded message EM into a message M and a padding string PS: EM = M || PS , where the padding string PS consists of some number psLen octets each with value psLen, where psLen is between 1 and 8. If it is not possible to separate the encoded message EM in this manner, output "decryption error" and stop. 6. Output the recovered message M. 6.2. PBES2 PBES2 combines a password-based key derivation function, which shall be PBKDF2 (Section 5.2) for this version of PKCS #5, with an underlying encryption scheme (see Appendix B.2 for examples). The key length and any other parameters for the underlying encryption scheme depend on the scheme. PBES2 is recommended for new applications. 6.2.1. PBES2 Encryption Operation The encryption operation for PBES2 consists of the following steps, which encrypt a message M under a password P to produce a ciphertext C, applying a selected key derivation function KDF and a selected underlying encryption scheme: 1. Select a salt S and an iteration count c, as outlined in Section 4. 2. Select the length in octets, dkLen, for the derived key for the underlying encryption scheme. 3. Apply the selected key derivation function to the password P, the salt S, and the iteration count c to produce a derived key DK of length dkLen octets: DK = KDF (P, S, c, dkLen) . 4. Encrypt the message M with the underlying encryption scheme under the derived key DK to produce a ciphertext C. (This step may involve selection of parameters such as an initialization vector and padding, depending on the underlying scheme.) 5. Output the ciphertext C. The salt S, the iteration count c, the key length dkLen, and identifiers for the key derivation function and the underlying encryption scheme may be conveyed to the party performing decryption in an AlgorithmIdentifier value (see Appendix A.4). 6.2.2. PBES2 Decryption Operation The decryption operation for PBES2 consists of the following steps, which decrypt a ciphertext C under a password P to recover a message M: 1. Obtain the salt S for the operation. 2. Obtain the iteration count c for the key derivation function. 3. Obtain the key length in octets, dkLen, for the derived key for the underlying encryption scheme. 4. Apply the selected key derivation function to the password P, the salt S, and the iteration count c to produce a derived key DK of length dkLen octets: DK = KDF (P, S, c, dkLen) . 5. Decrypt the ciphertext C with the underlying encryption scheme under the derived key DK to recover a message M. If the decryption function outputs "decryption error," then output "decryption error" and stop. 6. Output the recovered message M. 7. Message Authentication Schemes A message authentication scheme consists of a MAC (message authentication code) generation operation and a MAC verification operation, where the MAC generation operation produces a message authentication code from a message under a key, and the MAC verification operation verifies the message authentication code under the same key. In a password-based message authentication scheme, the key is a password. One scheme is specified in this section: PBMAC1. 7.1. PBMAC1 PBMAC1 combines a password-based key derivation function, which shall be PBKDF2 (Section 5.2) for this version of PKCS #5, with an underlying message authentication scheme (see Appendix B.3 for an example). The key length and any other parameters for the underlying message authentication scheme depend on the scheme. 7.1.1 PBMAC1 Generation Operation The MAC generation operation for PBMAC1 consists of the following steps, which process a message M under a password P to generate a message authentication code T, applying a selected key derivation function KDF and a selected underlying message authentication scheme: 1. Select a salt S and an iteration count c, as outlined in Section 4. 2. Select a key length in octets, dkLen, for the derived key for the underlying message authentication function. 3. Apply the selected key derivation function to the password P, the salt S, and the iteration count c to produce a derived key DK of length dkLen octets: DK = KDF (P, S, c, dkLen) . 4. Process the message M with the underlying message authentication scheme under the derived key DK to generate a message authentication code T. 5. Output the message authentication code T. The salt S, the iteration count c, the key length dkLen, and identifiers for the key derivation function and underlying message authentication scheme may be conveyed to the party performing verification in an AlgorithmIdentifier value (see Appendix A.5). 7.1.2. PBMAC1 Verification Operation The MAC verification operation for PBMAC1 consists of the following steps, which process a message M under a password P to verify a message authentication code T: 1. Obtain the salt S and the iteration count c. 2. Obtain the key length in octets, dkLen, for the derived key for the underlying message authentication scheme. 3. Apply the selected key derivation function to the password P, the salt S, and the iteration count c to produce a derived key DK of length dkLen octets: DK = KDF (P, S, c, dkLen) . 4. Process the message M with the underlying message authentication scheme under the derived key DK to verify the message authentication code T. 5. If the message authentication code verifies, output "correct"; else output "incorrect." 8. Security Considerations Password-based cryptography is generally limited in the security that it can provide, particularly for methods such as those defined in this document where off-line password search is possible. While the use of salt and iteration count can increase the complexity of attack (see Section 4 for recommendations), it is essential that passwords are selected well, and relevant guidelines (e.g., [NISTSP63]) should be taken into account. It is also important that passwords be protected well if stored. In general, different keys should be derived from a password for different uses to minimize the possibility of unintended interactions. For password-based encryption with a single algorithm, a random salt is sufficient to ensure that different keys will be produced. In certain other situations, as outlined in Section 4, a structured salt is necessary. The recommendations in Section 4 should thus be taken into account when selecting the salt value. For information on security considerations for MD2 [RFC1319] see [RFC6149], for MD5 [RFC1321] see [RFC6151], for SHA-1 [NIST180] see [RFC6194]. 9. IANA Considerations None. A. ASN.1 Syntax This section defines ASN.1 syntax for the key derivation functions, the encryption schemes, the message authentication scheme, and supporting techniques. The intended application of these definitions includes PKCS #8 and other syntax for key management, encrypted data, and integrity-protected data. (Various aspects of ASN.1 are specified in several ISO/IEC standards [ISO8824-1][ISO8824-2][ISO8824-3] [ISO8824-4].) The object identifier pkcs-5 identifies the arc of the OID tree from which the PKCS #5-specific OIDs in this section are derived: rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} pkcs OBJECT IDENTIFIER ::= {rsadsi 1} pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} A.1. PBKDF1 No object identifier is given for PBKDF1, as the object identifiers for PBES1 are sufficient for existing applications and PBKDF2 is recommended for new applications. A.2. PBKDF2 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation function (Section 5.2). id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} The parameters field associated with this OID in an AlgorithmIdentifier shall have type PBKDF2-params: PBKDF2-params ::= SEQUENCE { salt CHOICE { specified OCTET STRING, otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} }, iterationCount INTEGER (1..MAX), keyLength INTEGER (1..MAX) OPTIONAL, prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1 } The fields of type PBKDF2-params have the following meanings: - salt specifies the salt value, or the source of the salt value. It shall either be an octet string or an algorithm ID with an OID in the set PBKDF2-SaltSources, which is reserved for future versions of PKCS #5. The salt-source approach is intended to indicate how the salt value is to be generated as a function of parameters in the algorithm ID, application data, or both. For instance, it may indicate that the salt value is produced from the encoding of a structure that specifies detailed information about the derived key as suggested in Section 4.1. Some of the information may be carried elsewhere, e.g., in the encryption algorithm ID. However, such facilities are deferred to a future version of PKCS #5. In this version, an application may achieve the benefits mentioned in Section 4.1 by choosing a particular interpretation of the salt value in the specified alternative. PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } - iterationCount specifies the iteration count. The maximum iteration count allowed depends on the implementation. It is expected that implementation profiles may further constrain the bounds. - keyLength, an optional field, is the length in octets of the derived key. The maximum key length allowed depends on the implementation; it is expected that implementation profiles may further constrain the bounds. The field is provided for convenience only; the key length is not cryptographically protected. If there is concern about interaction between operations with different key lengths for a given salt (see Section 4.1), the salt should distinguish among the different key lengths. - prf identifies the underlying pseudorandom function. It shall be an algorithm ID with an OID in the set PBKDF2-PRFs, which for this version of PKCS #5 shall consist of id-hmacWithSHA1 (see Appendix B.1.1) and any other OIDs defined by the application. PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { {NULL IDENTIFIED BY id-hmacWithSHA1}, {NULL IDENTIFIED BY id-hmacWithSHA224}, {NULL IDENTIFIED BY id-hmacWithSHA256}, {NULL IDENTIFIED BY id-hmacWithSHA384}, {NULL IDENTIFIED BY id-hmacWithSHA512}, {NULL IDENTIFIED BY id-hmacWithSHA512-224}, {NULL IDENTIFIED BY id-hmacWithSHA512-256}, ... } The default pseudorandom function is HMAC-SHA-1: algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= {algorithm id-hmacWithSHA1, parameters NULL : NULL} A.3. PBES1 Different object identifiers identify the PBES1 encryption scheme (Section 6.1) according to the underlying hash function in the key derivation function and the underlying block cipher, as summarized in the following table: Hash Function Block Cipher OID MD2 DES pkcs-5.1 MD2 RC2 pkcs-5.4 MD5 DES pkcs-5.3 MD5 RC2 pkcs-5.6 SHA-1 DES pkcs-5.10 SHA-1 RC2 pkcs-5.11 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} For each OID, the parameters field associated with the OID in an AlgorithmIdentifier shall have type PBEParameter: PBEParameter ::= SEQUENCE { salt OCTET STRING (SIZE(8)), iterationCount INTEGER } The fields of type PBEParameter have the following meanings: - salt specifies the salt value, an eight-octet string. - iterationCount specifies the iteration count. A.4. PBES2 The object identifier id-PBES2 identifies the PBES2 encryption scheme (Section 6.2). id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} The parameters field associated with this OID in an AlgorithmIdentifier shall have type PBES2-params: PBES2-params ::= SEQUENCE { keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } The fields of type PBES2-params have the following meanings: - keyDerivationFunc identifies the underlying key derivation function. It shall be an algorithm ID with an OID in the set PBES2-KDFs, which for this version of PKCS #5 shall consist of id-PBKDF2 (Appendix A.2). PBES2-KDFs ALGORITHM-IDENTIFIER ::= { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } - encryptionScheme identifies the underlying encryption scheme. It shall be an algorithm ID with an OID in the set PBES2-Encs, whose definition is left to the application. Example underlying encryption schemes are given in Appendix B.2. PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } A.5. PBMAC1 The object identifier id-PBMAC1 identifies the PBMAC1 message authentication scheme (Section 7.1). id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} The parameters field associated with this OID in an AlgorithmIdentifier shall have type PBMAC1-params: PBMAC1-params ::= SEQUENCE { keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } The keyDerivationFunc field has the same meaning as the corresponding field of PBES2-params (Appendix A.4) except that the set of OIDs is PBMAC1-KDFs. PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } The messageAuthScheme field identifies the underlying message authentication scheme. It shall be an algorithm ID with an OID in the set PBMAC1-MACs, whose definition is left to the application. Example underlying encryption schemes are given in Appendix B.3. PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } B. Supporting Techniques This section gives several examples of underlying functions and schemes supporting the password-based schemes in Sections 5, 6 and 7. While these supporting techniques are appropriate for applications to implement, none of them is required to be implemented. It is expected, however, that profiles for PKCS #5 will be developed that specify particular supporting techniques. This section also gives object identifiers for the supporting techniques. The object identifiers digestAlgorithm and encryptionAlgorithm identify the arcs from which certain algorithm OIDs referenced in this section are derived: digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} B.1. Pseudorandom functions Examples of pseudorandom function for PBKDF2 (Section 5.2) include HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA512/256. Applications may employ other schemes as well. B.1.1. HMAC-SHA-1 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC message authentication code [RFC2104] based on the SHA-1 hash function [NIST180]. The pseudorandom function is the same function by which the message authentication code is computed, with a full- length output. (The first argument to the pseudorandom function PRF serves as HMAC's "key," and the second serves as HMAC's "text." In the case of PBKDF2, the "key" is thus the password and the "text" is the salt.) HMAC-SHA-1 has a variable key length and a 20-octet (160-bit) output value. Although the length of the key to HMAC-SHA-1 is essentially unbounded, the effective search space for pseudorandom function outputs may be limited by the structure of the function. In particular, when the key is longer than 512 bits, HMAC-SHA-1 will first hash it to 160 bits. Thus, even if a long derived key consisting of several pseudorandom function outputs is produced from a key, the effective search space for the derived key will be at most 160 bits. Although the specific limitation for other key sizes depends on details of the HMAC construction, one should assume, to be conservative, that the effective search space is limited to 160 bits for other key sizes as well. (The 160-bit limitation should not generally pose a practical limitation in the case of password-based cryptography, since the search space for a password is unlikely to be greater than 160 bits.) The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1 pseudorandom function: id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} The parameters field associated with this OID in an AlgorithmIdentifier shall have type NULL. This object identifier is employed in the object set PBKDF2-PRFs (Appendix A.2). Note. Although HMAC-SHA-1 was designed as a message authentication code, its proof of security is readily modified to accommodate requirements for a pseudorandom function, under stronger assumptions. A hash function may also meet the requirements of a pseudorandom function under certain assumptions. For instance, the direct application of a hash function to to the concatenation of the "key" and the "text" may be appropriate, provided that "text" has appropriate structure to prevent certain attacks. HMAC-SHA-1 is preferable, however, because it treats "key" and "text" as separate arguments and does not require "text" to have any structure. During 2004 and 2005 there were a number of attacks on SHA-1 that reduced its perceived effective strength against collision attacks to 62 bits instead of the expected 80 bits (e.g. Wang et al. [WANG], confirmed by M. Cochran [COCHRAN]). However, since these attacks centered on finding collisions between values they are not a direct security consideration here because the collision-resistant property is not required by the HMAC authentication scheme. B.1.2. HMAC-SHA-2 HMAC-SHA-2 refers to the set of pseudo-random functions corresponding to the HMAC message authentication code (now a FIPS standard [NIST198]) based on the new SHA-2 functions (FIPS 180-4 [NIST180]). HMAC-SHA-2 has a variable key length and variable output value depending on the hash function chosen (SHA-224, SHA-256, SHA-384, SHA-512, SHA -512/224, or SHA-512/256), that is 28, 32, 48, or 64 octets. Using the new hash functions extends the search space for the produced keys. Where SHA-1 limits the search space to 20 octets, SHA-2 sets new limits of 28, 32, 48 and 64 octets. Object identifiers for HMAC are defined as follows: id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} B.2. Encryption Schemes An example encryption scheme for PBES2 (Section 6.2) is AES-CBC-Pad. The schemes defined in PKCS #5 v2.0 [RFC2898], DES-CBC-Pad, DES-EDE3- CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad, are still supported, but DES-CBC-Pad, DES-EDE3-CBC-Pad, RC2-CBC-Pad are now considered legacy and should only be used for backwards compatibility reasons. The object identifiers given in this section are intended to be employed in the object set PBES2-Encs (Appendix A.4). B.2.1. DES-CBC-Pad DES-CBC-Pad is single-key DES [NIST46] in CBC mode [NIST81] with the RFC 1423 [RFC1423] padding operation (see Section 6.1.1). DES-CBC-Pad has an eight- octet encryption key and an eight-octet initialization vector. The key is considered as a 64-bit encoding of a 56-bit DES key with parity bits ignored. The object identifier desCBC (defined in the NIST/OSI Implementors' Workshop agreements) identifies the DES-CBC-Pad encryption scheme: desCBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 7} The parameters field associated with this OID in an AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), specifying the initialization vector for CBC mode. B.2.2. DES-EDE3-CBC-Pad DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [ANSIX952] with the RFC 1423 [RFC1423] padding operation. DES-EDE3-CBC-Pad has a 24-octet encryption key and an eight-octet initialization vector. The key is considered as the concatenation of three eight-octet keys, each of which is a 64-bit encoding of a 56-bit DES key with parity bits ignored. The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad encryption scheme: des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} The parameters field associated with this OID in an AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), specifying the initialization vector for CBC mode. Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 [ANSIX952]; the one given here is preferred since it specifies padding. B.2.3. RC2-CBC-Pad RC2-CBC-Pad is the RC2(tm) encryption algorithm [RFC2268] in CBC mode with the RFC 1423 [RFC1423] padding operation. RC2-CBC-Pad has a variable key length, from one to 128 octets, a separate "effective key bits" parameter from one to 1024 bits that limits the effective search space independent of the key length, and an eight-octet initialization vector. The object identifier rc2CBC identifies the RC2-CBC-Pad encryption scheme: rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} The parameters field associated with OID in an AlgorithmIdentifier shall have type RC2-CBC-Parameter: RC2-CBC-Parameter ::= SEQUENCE { rc2ParameterVersion INTEGER OPTIONAL, iv OCTET STRING (SIZE(8)) } The fields of type RC2-CBCParameter have the following meanings: - rc2ParameterVersion is a proprietary RSA Security Inc. encoding of the "effective key bits" for RC2. The following encodings are defined: Effective Key Bits Encoding 40 160 64 120 128 58 b >= 256 b If the rc2ParameterVersion field is omitted, the "effective key bits" defaults to 32. (This is for backward compatibility with certain very old implementations.) - iv is the eight-octet initialization vector. B.2.4. RC5-CBC-Pad RC5-CBC-Pad is the RC5(tm) encryption algorithm [RC5] in CBC mode with RFC 5652 [RFC5652] padding operation, which is a generalization of the RFC 1423 [RFC1423] padding operation. The scheme is fully specified in [RFC2040]. RC5-CBC-Pad has a variable key length, from 0 to 256 octets, and supports both a 64-bit block size and a 128-bit block size. For the former, it has an eight-octet initialization vector, and for the latter, a 16-octet initialization vector. RC5-CBC-Pad also has a variable number of "rounds" in the encryption operation, from 8 to 127. Note: For RC5 with a 64-bit block size, the padding string is as defined in RFC 1423 [RFC1423]. For RC5 with a 128-bit block size, the padding string consists of 16-(||M|| mod 16) octets each with value 16-(||M|| mod 16). The object identifier rc5-CBC-PAD [RFC2040] identifies RC5-CBC-Pad encryption scheme: rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} The parameters field associated with this OID in an AlgorithmIdentifier shall have type RC5-CBC-Parameters: RC5-CBC-Parameters ::= SEQUENCE { version INTEGER {v1-0(16)} (v1-0), rounds INTEGER (8..127), blockSizeInBits INTEGER (64 | 128), iv OCTET STRING OPTIONAL } The fields of type RC5-CBC-Parameters have the following meanings: - version is the version of the algorithm, which shall be v1-0. - rounds is the number of rounds in the encryption operation, which shall be between 8 and 127. - blockSizeInBits is the block size in bits, which shall be 64 or 128. - iv is the initialization vector, an eight-octet string for 64-bit RC5 and a 16-octet string for 128-bit RC5. The default is a string of the appropriate length consisting of zero octets. B.2.5. AES-CBC-Pad AES-CBC-Pad is the AES encryption algorithm [NIST197] in CBC mode with RFC 5652 [RFC5652] padding operation. AES-CBC-Pad has a variable key length of 16, 24, or 32 octets and has a 16-octet block size. It has a 16-octet initialization vector. Note: For AES, the padding string consists of 16-(||M|| mod 16) octets each with value 16-(||M|| mod 16). For AES, object identifiers are defined depending on key size and operation mode. For example, the 16-octet (128 bit) key AES encryption scheme in CBC mode would be aes128-CBC-Pad identifying the AES-CBC-PAD encryption scheme using a 16-octet key: aes128-CBC-PAD OBJECT IDENTIFIER ::= {aes 2} The AES object identifier is defined in Appendix C. The parameters field associated with this OID in an AlgorithmIdentifier shall have type OCTET STRING (SIZE(16)), specifying the initialization vector for CBC mode. B.3. Message Authentication Schemes An example message authentication scheme for PBMAC1 (Section 7.1) is HMAC-SHA-1. B.3.1. HMAC-SHA-1 HMAC-SHA-1 is the HMAC message authentication scheme [RFC2104] based on the SHA-1 hash function [NIST180]. HMAC-SHA-1 has a variable key length and a 20-octet (160-bit) message authentication code. The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies the HMAC-SHA-1 message authentication scheme. (The object identifier is the same for both the pseudorandom function and the message authentication scheme; the distinction is to be understood by context.) This object identifier is intended to be employed in the object set PBMAC1-Macs (Appendix A.5). B.3.2. HMAC-SHA-2 HMAC-SHA-2 refers to the set of HMAC message authentication schemes [NIST198] based on the SHA-2 functions [NIST180]. HMAC-SHA-2 has a variable key length and a message authentication code whose length is based on the hash function chosen (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256giving 28, 32, 48 or 64 octets). The object identifiers id-hmacWithSHA224, id-hmacWithSHA256, id- hmacWithSHA384, id-hmacWithSHA512, id-hmacWithSHA512-224,and id- hmacWithSHA512-256 (see Appendix B.1.2) identify the HMAC-SHA-2 schemes. The object identifiers are the same for both the pseudo-random functions and the message authentication schemes; the distinction is to be understood by context. These object identifiers are intended to be employed in the object set PBMAC1-Macs (Appendix A.5) C. ASN.1 Module For reference purposes, the ASN.1 syntax in the preceding sections is presented as an ASN.1 module here. -- PKCS #5 v2.1 ASN.1 Module -- Revised October 27, 2012 -- This module has been checked for conformance with the -- ASN.1 standard by the OSS ASN.1 Tools PKCS5v2-1 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16) pkcs5v2-1(2) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- ======================== -- Basic object identifiers -- ======================== nistAlgorithms OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) 4} oiw OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) 14} rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} pkcs OBJECT IDENTIFIER ::= {rsadsi 1} pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} -- ======================= -- Basic types and classes -- ======================= AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= SEQUENCE { algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} {@algorithm}) OPTIONAL } ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER -- ====== -- PBKDF2 -- ====== PBKDF2Algorithms ALGORITHM-IDENTIFIER ::= { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= {algorithm id-hmacWithSHA1, parameters NULL : NULL} PBKDF2-params ::= SEQUENCE { salt CHOICE { specified OCTET STRING, otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} }, iterationCount INTEGER (1..MAX), keyLength INTEGER (1..MAX) OPTIONAL, prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1 } PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { {NULL IDENTIFIED BY id-hmacWithSHA1}, {NULL IDENTIFIED BY id-hmacWithSHA224}, {NULL IDENTIFIED BY id-hmacWithSHA256}, {NULL IDENTIFIED BY id-hmacWithSHA384}, {NULL IDENTIFIED BY id-hmacWithSHA512}, {NULL IDENTIFIED BY id-hmacWithSHA512-224}, {NULL IDENTIFIED BY id-hmacWithSHA512-256}, ... } -- ===== -- PBES1 -- ===== PBES1Algorithms ALGORITHM-IDENTIFIER ::= { {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} | {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} | {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} | {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} | {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} | {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC}, ... } pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} PBEParameter ::= SEQUENCE { salt OCTET STRING (SIZE(8)), iterationCount INTEGER } -- ===== -- PBES2 -- ===== PBES2Algorithms ALGORITHM-IDENTIFIER ::= { {PBES2-params IDENTIFIED BY id-PBES2}, ... } id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} PBES2-params ::= SEQUENCE { keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } PBES2-KDFs ALGORITHM-IDENTIFIER ::= { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } -- ====== -- PBMAC1 -- ====== PBMAC1Algorithms ALGORITHM-IDENTIFIER ::= { {PBMAC1-params IDENTIFIED BY id-PBMAC1}, ... } id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} PBMAC1-params ::= SEQUENCE { keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } -- ===================== -- Supporting techniques -- ===================== digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} SupportingAlgorithms ALGORITHM-IDENTIFIER ::= { {NULL IDENTIFIED BY id-hmacWithSHA1} | {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} | {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} | {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} | {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}, | {OCTET STRING (SIZE(16)) IDENTIFIED BY aes128-CBC-PAD} | {OCTET STRING (SIZE(16)) IDENTIFIED BY aes192-CBC-PAD} | {OCTET STRING (SIZE(16)) IDENTIFIED BY aes256-CBC-PAD}, ... } id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} desCBC OBJECT IDENTIFIER ::= {oiw secsig(3) algorithms(2) 7} des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} RC2-CBC-Parameter ::= SEQUENCE { rc2ParameterVersion INTEGER OPTIONAL, iv OCTET STRING (SIZE(8)) } rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} RC5-CBC-Parameters ::= SEQUENCE { version INTEGER {v1-0(16)} (v1-0), rounds INTEGER (8..127), blockSizeInBits INTEGER (64 | 128), iv OCTET STRING OPTIONAL } aes OBJECT IDENTIFIER ::= { nistAlgorithms 1 } aes128-CBC-PAD OBJECT IDENTIFIER ::= { aes 2 } aes192-CBC-PAD OBJECT IDENTIFIER ::= { aes 22 } aes256-CBC-PAD OBJECT IDENTIFIER ::= { aes 42 } END D. Intellectual Property Considerations EMC Corporation makes no patent claims on the general constructions described in this document, although specific underlying techniques may be covered. Among the underlying techniques, the RC5 encryption algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 [RBLOCK1] and 5,835,600 [RBLOCK2]. RC2 and RC5 are trademarks of EMC Corporation. EMC Corporation makes no representation regarding intellectual property claims by other parties. Such determination is the responsibility of the user. E. Revision History Versions 1.0-1.3 Versions 1.0-1.3 were distributed to participants in RSA Data Security Inc.'s Public-Key Cryptography Standards meetings in February and March 1991. Version 1.4 Version 1.4 was part of the June 3, 1991 initial public release of PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop document SEC-SIG-91-20. Version 1.5 Version 1.5 incorporated several editorial changes, including updates to the references and the addition of a revision history. Version 2.0 Version 2.0 incorporates major editorial changes in terms of the document structure, and introduces the PBES2 encryption scheme, the PBMAC1 message authentication scheme, and independent password-based key derivation functions. This version continues to support the encryption process in version 1.5. Version 2.1 This document transfers PKCS #5 into the IETF and includes some minor changes from the authors for this submission. o Introduces AES/CBC as an encryption scheme for PBES2 and HMAC with the hash functions SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA512/256 as pseudo-random functions for PBKDF2 and message authentication schemes for PBMAC1. o Replacement of RSA with EMC in the "Intellectual Property Considerations". o Changes references to PKCS #5 and PKCS #8 to RSA 2898 and RFC 5208/5898. o Incorporates two editorial errata reported on PKCS #5 [RFC2898]. o Added security considerations for MD2, MD5, and SHA-1. F. References F.1 Normative References [ANSIX952] American National Standard X9.52 - 1998, Triple Data Encryption Algorithm Modes of Operation. Working draft, Accredited Standards Committee X9, July 27, 1998. [BELLOV] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password- based protocols secure against dictionary attacks. In Proceedings of the 1992 IEEE Computer Society Conference on Research in Security and Privacy, pages 72-84, IEEE Computer Society, 1992. [COCHRAN] M. Cochran. Notes on the Wang et al. 2^63 SHA-1 Differential Path. International Association for Cryptologic Research, ePrint Archive. August 2008. Available from [ISO8824-1] ISO/IEC 8824-1: 2008: Information technology - Abstract Syntax Notation One (ASN.1) - Specification of basic notation. 2008. [ISO8824-2] ISO/IEC 8824-2: 2008: Information technology - Abstract Syntax Notation One (ASN.1) - Information object specification. 2008. [ISO8824-3] ISO/IEC 8824-3: 2008: Information technology - Abstract Syntax Notation One (ASN.1) - Constraint specification. 2008. [ISO8824-4] ISO/IEC 8824-4: 2008: Information technology - Abstract Syntax Notation One (ASN.1) - Parameterization of ASN.1 specifications. 2008. [JABLON] D. Jablon. Strong password-only authenticated key exchange. ACM Computer Communications Review, October 1996. [MORRIS] Robert Morris and Ken Thompson. Password security: A case history. Communications of the ACM, 22(11):594-597, November 1979. [NIST46] National Institute of Standards and Technology (NIST). FIPS PUB 46-3: Data Encryption Standard. October 1999. [NIST81] National Institute of Standards and Technology (NIST). FIPS PUB 81: DES Modes of Operation. December 2, 1980. [NIST180] National Institute of Standards and Technology (NIST). FIPS PUB 180-4: Secure Hash Standard. March 2012. [NIST197] National Institute of Standards and Technology (NIST). FIPS PUB 197: Advance Encryption Standard (AES). November 2001. [NIST198] National Institute of Standards and Technology (NIST). FIPS Publication 198-1: The Keyed - Hash Message Authentication Code (HMAC). July 2008. [NISTSP63] National Institute of Standards and Technology (NIST). Special Publication 800-63-2: Electronic Authentication Guideline, Appendix A. August 2013. [NISTSP132] National Institute of Standards and Technology (NIST). Special Publication 800-132: Recommendation for Password - Based Key Derivation, Part 1: Storage Applications. December 2010. [PKCS5_15] RSA Laboratories. PKCS #5: Password-Based Encryption Standard Version 1.5, November 1993. [PKCS5_21] RSA Laboratories. PKCS #5: Password-Based Encryption Standard Version 2.1, October 2012. [PKCS8] RSA Laboratories. "PKCS #8: Private-Key Information Syntax Standard Version 1.2", RFC 5208, May 2008. [RBLOCK1] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent Rotations. U.S. Patent No. 5,724,428, March 3, 1998. [RBLOCK2] R.L. Rivest. Block Encryption Algorithm with Data-Dependent Rotations. U.S. Patent No. 5,835,600, November 10, 1998. [RC5] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the Second International Workshop on Fast Software Encryption, pages 86-96, Springer-Verlag, 1994. [RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992, . [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992, . [RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993, . [RFC2040] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996, . [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997, . [RFC2268] Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, March 1998, . [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998, . [RFC2898] B. Kaliski., "PKCS #5: Password-Based Encryption Standard Version 2.0", RFC 2898, September 2000, . [RFC5652] R. Housley. RFC 5652: Cryptographic Message Syntax. IETF, September 2009, . [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010, . [RFC6149] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, March 2011, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011, . [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011, . [WANG] X. Wang, A.C. Yao, and F. Yao. Cryptanalysis on SHA-1. Presented by Adi Shamir at the rump session of CRYPTO 2005. Slides may be found currently at [WU] T. Wu. The Secure Remote Password protocol. In Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, pages 97-111, Internet Society, 1998. G. About PKCS The Public-Key Cryptography Standards are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide for the purpose of accelerating the deployment of public- key cryptography. First published in 1991 as a result of meetings with a small group of early adopters of public-key technology, the PKCS documents have become widely referenced and implemented. Contributions from the PKCS series have become part of many formal and de facto standards, including ANSI X9 documents, PKIX, SET, S/MIME, and SSL. Further development of most PKCS documents occurs through the IETF. Suggestions for improvement are welcome. H. Acknowledgements This document is based on a contribution of RSA Laboratories, the research center of RSA Security Inc. Authors' Addresses Kathleen M. Moriarty (editor) EMC Corporation 176 South Street Hopkinton, MA 01748 US Email: kathleen.moriarty@emc.com Burt Kaliski Verisign 12061 Bluemont Way Reston, VA 20190 US Email: bkaliski@verisign.com URI: http://verisignlabs.com Andreas Rusch RSA 345 Queen Street Brisbane, QLD 4000 AU Email: andreas.rusch@rsa.com ./draft-murchison-nntp-compress-06.txt0000664000764400076440000014621713004205450017254 0ustar iustyiusty Independent Submission K. Murchison Internet-Draft Carnegie Mellon University Intended status: Standards Track J. Elie Expires: April 29, 2017 October 26, 2016 Network News Transfer Protocol (NNTP) Extension for Compression draft-murchison-nntp-compress-06 Abstract This document defines an extension to the Network News Transport Protocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Murchison & Elie Expires April 29, 2017 [Page 1] Internet-Draft NNTP Extension for Compression October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. About TLS-level Compression . . . . . . . . . . . . . . . 3 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.3. Authors' Note . . . . . . . . . . . . . . . . . . . . . . 4 2. The COMPRESS Extension . . . . . . . . . . . . . . . . . . . 4 2.1. Advertising the COMPRESS Extension . . . . . . . . . . . 4 2.2. COMPRESS Command . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Description . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 7 3. Compression Efficiency . . . . . . . . . . . . . . . . . . . 10 4. DEFLATE Specificities . . . . . . . . . . . . . . . . . . . . 12 5. Augmented BNF Syntax for the COMPRESS Extension . . . . . . . 12 5.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Capability Entries . . . . . . . . . . . . . . . . . . . 13 5.3. General Non-terminals . . . . . . . . . . . . . . . . . . 13 6. Summary of Response Codes . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.1. NNTP Compression Algorithm Registry . . . . . . . . . . . 15 8.1.1. Algorithm Name Registration Procedure . . . . . . . . 16 8.1.2. Comments on Algorithm Registrations . . . . . . . . . 16 8.1.3. Change Control . . . . . . . . . . . . . . . . . . . 17 8.2. Registration of the DEFLATE Compression Algorithm . . . . 17 8.3. Registration of the NNTP COMPRESS Extension . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix B. Document History (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . 22 B.1. Changes since -05 . . . . . . . . . . . . . . . . . . . . 22 B.2. Changes since -04 . . . . . . . . . . . . . . . . . . . . 23 B.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 23 B.4. Changes since -02 . . . . . . . . . . . . . . . . . . . . 24 B.5. Changes since -01 . . . . . . . . . . . . . . . . . . . . 24 B.6. Changes since -00 . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The goal of COMPRESS is to reduce the bandwidth usage of NNTP. Compared to PPP compression [RFC1962] and modem-based compression ([MNP] and [V42bis]), COMPRESS offers greater compression efficiency. COMPRESS can be used together with Transport Layer Security (TLS) Murchison & Elie Expires April 29, 2017 [Page 2] Internet-Draft NNTP Extension for Compression October 2016 [RFC5246], Simple Authentication and Security Layer (SASL) encryption [RFC4422], Virtual Private Networks (VPNs), etc. The point of COMPRESS as an NNTP extension is to act as a compression layer, similarly to a security layer like the one negotiated by STARTTLS [RFC4642]. Compression can therefore benefit to all NNTP commands sent or received after the use of COMPRESS. This facility responds to a long-standing need for NNTP to compress data, that has partially been addressed by unstandardized commands like XZVER, XZHDR, XFEATURE COMPRESS, or MODE COMPRESS. These commands are not wholly satisfactory because they enable compression only for the responses sent by the news server. On the contrary, the COMPRESS command permits to compress data sent by both the client and the server, and removes the constraint of having to implement compression separately in each NNTP command. Besides, the compression level can be dynamically adjusted and optimized at any time during the connection, which even allows to disable compression for certain commands, if need be. If the news client wants to stop compression on a particular connection, it can simply use QUIT ([RFC3977] Section 5.4), and establish a new connection. For these reasons, using other NNTP commands than COMPRESS to enable compression is discouraged once COMPRESS is supported. In order to increase interoperability, it is desirable to have as few different compression algorithms as possible, so this document specifies only one. The DEFLATE algorithm (defined in [RFC1951]) MUST be implemented as part of this extension. This compression algorithm is standard, widely available, and fairly efficient. This specification should be read in conjunction with the NNTP base specification [RFC3977]. In the case of a conflict between these two documents, [RFC3977] takes precedence. 1.1. About TLS-level Compression Though lossless data compression is already possible via the use of TLS with NNTP [RFC4642], the best current practice is to disable TLS- level compression as explained in Section 3.3 of [RFC7525]. The COMPRESS command will permit to keep the compression facility in NNTP, and control when it is available during a connection. Compared to TLS-level compression [RFC3749], NNTP COMPRESS has the following advantages: o COMPRESS can be implemented easily both by NNTP servers and clients. Murchison & Elie Expires April 29, 2017 [Page 3] Internet-Draft NNTP Extension for Compression October 2016 o COMPRESS benefits from an intimate knowledge of the NNTP protocol's state machine, allowing for dynamic and aggressive optimization of the underlying compression algorithm's parameters. o COMPRESS can be activated after authentication has completed, thus reducing the chances that authentication credentials can be leaked via for instance a CRIME attack ([RFC7457] Section 2.6). 1.2. Conventions Used in This Document The notational conventions used in this document are the same as those in [RFC3977], and any term not defined in this document has the same meaning as it does in that one. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S]. The client is the initiator of the NNTP connection; the server is the other endpoint. 1.3. Authors' Note Please write the first letter of "Elie" with an acute accent wherever possible -- it is U+00C9 ("É" in XML). The third letter of "Stephane" and the penultimate letter of "allee" similarly have an acute accent (U+00E9, "é" in XML). Also, the letters "ae" in "Baeuerle" should be written as an a-umlaut (U+00E4, "ä" in XML), and the first letter of "Angel" as well as the fifth letter of "Gonzalez" should be written with an acute accent (respectively U+00C1 and U+00E1, that is to say "Á" and "á" in XML). 2. The COMPRESS Extension The COMPRESS extension is used to enable lossless data compression on an NNTP connection. This extension provides a new COMPRESS command and has capability label COMPRESS. 2.1. Advertising the COMPRESS Extension A server supporting the COMPRESS command as defined in this document will advertise the "COMPRESS" capability label in response to the CAPABILITIES command ([RFC3977] Section 5.2). However, this capability MUST NOT be advertised once a compression layer is active Murchison & Elie Expires April 29, 2017 [Page 4] Internet-Draft NNTP Extension for Compression October 2016 (see Section 2.2.2). This capability MAY be advertised both before and after any use of the MODE READER command ([RFC3977] Section 5.3), with the same semantics. The COMPRESS capability label contains a whitespace-separated list of available compression algorithms. This document defines one compression algorithm: DEFLATE. This algorithm is mandatory to implement; it MUST be supported and listed in the advertisement of the COMPRESS extension. Future extensions may add additional compression algorithms to this capability. Unrecognized algorithms MUST be ignored by the client. Example: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] IHAVE [S] COMPRESS DEFLATE SHRINK [S] LIST ACTIVE NEWSGROUPS [S] . As the COMPRESS command is related to security because it can weaken encryption, cached results of CAPABILITIES from a previous session MUST NOT be relied on, as per Section 12.6 of [RFC3977]. 2.2. COMPRESS Command 2.2.1. Usage This command MUST NOT be pipelined. Syntax COMPRESS algorithm Responses 206 Compression active 403 Unable to activate compression 502 Command unavailable [1] [1] If a compression layer is already active, COMPRESS is not a valid command (see Section 2.2.2). Parameters algorithm = Name of compression algorithm (e.g., "DEFLATE") Murchison & Elie Expires April 29, 2017 [Page 5] Internet-Draft NNTP Extension for Compression October 2016 2.2.2. Description The COMPRESS command instructs the server to use the named compression algorithm ("DEFLATE" is the only one defined in this document) for all commands and responses after COMPRESS. The client MUST NOT send any further commands until it has seen the result of COMPRESS. If the requested compression algorithm is syntactically incorrect, the server MUST reject the COMPRESS command with a 501 response code ([RFC3977] Section 3.2.1). If the requested compression algorithm is invalid (e.g., is not supported), the server MUST reject the COMPRESS command with a 503 response code ([RFC3977] Section 3.2.1). If the server is unable to activate compression for any reason (e.g., a server configuration or resource problem), the server MUST reject the COMPRESS command with a 403 response code ([RFC3977] Section 3.2.1). Otherwise, the server issues a 206 response code and the compression layer takes effect for both client and server immediately following the CRLF of the success reply. Additionally, the client MUST NOT issue a MODE READER command after activating a compression layer, and a server MUST NOT advertise the MODE-READER capability. Both the client and the server MUST know if there is a compression layer active (for instance via the previous use of the COMPRESS command or the negotiation of a TLS-level compression method [RFC3749]). A client MUST NOT attempt to activate compression (for instance via the COMPRESS command) or negotiate a TLS security layer (because STARTTLS [RFC4642] may activate TLS-level compression) if a compression layer is already active. A server MUST NOT return the COMPRESS or STARTTLS capability labels in response to a CAPABILITIES command received after a compression layer is active, and a server MUST reply with a 502 response code if a syntactically valid COMPRESS or STARTTLS command is received while a compression layer is already active. In order to help mitigate leaking authentication credentials via for instance a CRIME attack [CRIME], authentication MUST NOT be attempted after a successful use of the COMPRESS command. Consequently, a server MUST either list the AUTHINFO capability with no arguments or not advertise it at all, in response to a CAPABILITIES command received from an unauthenticated client after a successful use of the COMPRESS command, and such a client MUST NOT attempt to utilize any AUTHINFO [RFC4643] commands. It implies that a server MUST reply with a 502 response code if a syntactically valid AUTHINFO command is received after a successful use of the COMPRESS command. (Note that Murchison & Elie Expires April 29, 2017 [Page 6] Internet-Draft NNTP Extension for Compression October 2016 this specification does not change the behaviour of AUTHINFO as described in [RFC4643] independently of TLS-level compression. Authentication is therefore still allowed, even though TLS-level compression is active.) For DEFLATE [RFC1951] (as for many other compression algorithms), the sending compressor can trade speed against compression ratio. The receiving decompressor MUST automatically adjust to the parameters selected by the sender. Consequently, the client and server are both free to pick the best reasonable rate of compression for the data they send. Besides, all data that was submitted for compression MUST be included in the compressed output, and appropriately flushed so as to ensure that the receiving decompressor can completely decompress it. When COMPRESS is combined with TLS [RFC5246] or SASL [RFC4422] security layers, the processing order of the three layers MUST be first COMPRESS, then SASL, and finally TLS. That is, before data is transmitted, it is first compressed. Second, if a SASL security layer has been negotiated, the compressed data is then signed and/or encrypted accordingly. Third, if a TLS security layer has been negotiated, the data from the previous step is signed and/or encrypted accordingly (with a possible additional TLS-level compression). When receiving data, the processing order MUST be reversed. This ensures that before sending, data is compressed before it is encrypted. When compression is active and either the client or the server receives invalid or corrupted compressed data, the receiving end immediately closes the connection, in response to which the sending end will do the same. 2.2.3. Examples Example of layering a TLS security layer and NNTP compression: Murchison & Elie Expires April 29, 2017 [Page 7] Internet-Draft NNTP Extension for Compression October 2016 [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] STARTTLS [S] AUTHINFO [S] COMPRESS DEFLATE [S] LIST ACTIVE NEWSGROUPS [S] . [C] STARTTLS [S] 382 Continue with TLS negotiation [TLS negotiation without compression occurs here] [Following successful negotiation, all traffic is encrypted] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] AUTHINFO USER [S] COMPRESS DEFLATE [S] LIST ACTIVE NEWSGROUPS [S] . [C] AUTHINFO USER fred [S] 381 Enter passphrase [C] AUTHINFO PASS flintstone [S] 281 Authentication accepted [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] POST [S] COMPRESS DEFLATE [S] LIST ACTIVE NEWSGROUPS [S] . [C] COMPRESS DEFLATE [S] 206 Compression active [Henceforth, all traffic is compressed before being encrypted] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] POST [S] LIST ACTIVE NEWSGROUPS [S] . Example of a server failing to activate compression: Murchison & Elie Expires April 29, 2017 [Page 8] Internet-Draft NNTP Extension for Compression October 2016 [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] COMPRESS DEFLATE [S] . [C] COMPRESS DEFLATE [S] 403 Unable to activate compression Example of attempting to use an unsupported compression algorithm: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] COMPRESS DEFLATE [S] . [C] COMPRESS SHRINK [S] 503 Compression algorithm not supported Example of a server refusing to compress twice: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] STARTTLS [S] COMPRESS DEFLATE [S] . [C] STARTTLS [S] 382 Continue with TLS negotiation [TLS negotiation with compression occurs here] [Following successful negotiation, all traffic is encrypted] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] . [C] COMPRESS DEFLATE [S] 502 Compression already active via TLS Example of a server refusing to negotiate a TLS security layer after compression has been activated: Murchison & Elie Expires April 29, 2017 [Page 9] Internet-Draft NNTP Extension for Compression October 2016 [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] STARTTLS [S] COMPRESS DEFLATE [S] . [C] COMPRESS DEFLATE [S] 206 Compression active [Henceforth, all traffic is compressed] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] . [C] STARTTLS [S] 502 DEFLATE compression already active Example of a server not advertising AUTHINFO arguments after compression has been activated: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] AUTHINFO USER [S] COMPRESS DEFLATE [S] LIST ACTIVE NEWSGROUPS [S] . [C] COMPRESS DEFLATE [S] 206 Compression active [Henceforth, all traffic is compressed] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] AUTHINFO [S] LIST ACTIVE NEWSGROUPS [S] . [C] AUTHINFO USER fred [S] 502 DEFLATE compression already active 3. Compression Efficiency This section is informative, not normative. NNTP poses some unusual problems for a compression layer. Murchison & Elie Expires April 29, 2017 [Page 10] Internet-Draft NNTP Extension for Compression October 2016 Upstream traffic is fairly simple. Most NNTP clients send the same few commands again and again, so any compression algorithm that can exploit repetition works efficiently. The article posting and transfer commands (e.g., POST, IHAVE, and TAKETHIS [RFC4644]) are exceptions; clients that send many article posting or transfer commands may want to surround large multi-line data blocks with a dictionary flush and/or, depending on the compression algorithm, a change of compression level in the same way as is recommended for servers later in this document (Section 4). Downstream traffic has the unusual property that several kinds of data are sent, possibly confusing a dictionary-based compression algorithm. One type is NNTP responses not related to article header/body retrieval. Compressing NNTP simple responses (e.g., in answer to CHECK [RFC4644], DATE, GROUP, LAST, NEXT, STAT, etc.) generally does not save many bytes, unless repeated several times in the same NNTP session. On the contrary, most of NNTP multi-line responses (e.g., in answer to LIST, LISTGROUP, NEWGROUPS, NEWNEWS, etc.) are highly compressible; zlib using its least CPU-intensive setting compresses typical responses to 25-40% of their original size. Another type is article headers (as retrieved for instance via the HEAD, HDR, OVER, or ARTICLE commands). These are equally compressible, and benefit from using the same dictionary as the NNTP responses. A third type is article body text (as retrieved for instance via the BODY or ARTICLE commands). Text is usually fairly short and includes much ASCII, so the same compression dictionary will do a good job here, too. When multiple messages in the same thread are read at the same time, quoted lines, etc. can often be compressed almost to zero. Finally, non-text article bodies or attachments (as retrieved for instance via the BODY or ARTICLE commands) are transmitted in encoded form, usually Base64 [RFC4648], UUencode [IEEE.1003-2.1992], or yEnc [yEnc]. When already compressed articles or attachments are retrieved, a compression algorithm may be able to compress them, but the format of their encoding is usually not NNTP-like, so the dictionary built while compressing NNTP does not help much. The compressor has to adapt its dictionary from NNTP to the attachment's encoding format, and then back. When attachments are retrieved in Base64 or UUencode form, the Huffman coding usually compresses those to approximatively only 75% Murchison & Elie Expires April 29, 2017 [Page 11] Internet-Draft NNTP Extension for Compression October 2016 of their encoding size. 8-bit compression algorithms such as DEFLATE work well on 8-bit file formats; however, both Base64 and UUencode transform a file into something resembling 6-bit bytes, hiding most of the 8-bit file format from the compressor. On the other end, attachments encoded using a compression algorithm that retains the full 8-bit spectrum, like yEnc, are much more likely to be incompressible. 4. DEFLATE Specificities When using the zlib library (see [RFC1951]), the functions deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to implement this extension. The windowBits value MUST be in the range -8 to -15 for deflateInit2(), or else it will use the wrong format. The windowBits value SHOULD be -15 for inflateInit2(), or else it will not be able to decompress a stream with a larger window size, thus reducing interoperability. deflateParams() can be used to improve compression rate and resource use. Regarding flush operations, the Z_FULL_FLUSH argument to deflate() permits to clear the dictionary, which generally results in compression that is less effective than performing a Z_PARTIAL_FLUSH. As a matter of fact, keeping the 32kB dictionary from previous data, no matter how unrelated, can be of help (if there are no matching strings in there, then it is simply not referenced). A server can improve downstream compression and the CPU efficiency both of the server and the client if it adjusts the compression level (e.g., using the deflateParams() function in zlib) at the start and end of large non-text multi-line data blocks (before and after 'content-lines' in the definition of 'multi-line-data-block' in [RFC3977] Section 9.8). It permits to avoid trying to compress incompressible attachments. A very simple strategy is to change the compression level to 0 at the start of an incompressible multi-line data block, for instance when encoded using yEnc [yEnc], and to keep it at 1-5 the rest of the time. More complex strategies are of course possible, and encouraged. 5. Augmented BNF Syntax for the COMPRESS Extension This section describes the formal syntax of the COMPRESS extension using ABNF [RFC7405] [RFC5234]. It extends the syntax in Section 9 of [RFC3977], and non-terminals not defined in this document are Murchison & Elie Expires April 29, 2017 [Page 12] Internet-Draft NNTP Extension for Compression October 2016 defined there. The [RFC3977] ABNF should be imported first, before attempting to validate these rules. 5.1. Commands This syntax extends the non-terminal , which represents an NNTP command. command =/ compress-command compress-command = "COMPRESS" WS algorithm 5.2. Capability Entries This syntax extends the non-terminal , which represents a capability that may be advertised by the server. capability-entry =/ compress-capability compress-capability = "COMPRESS" 1*(WS algorithm) 5.3. General Non-terminals algorithm = %s"DEFLATE" / 1*20alg-char ; case-sensitive alg-char = UPPER / DIGIT / "-" / "_" 6. Summary of Response Codes This section defines the following new response code. It is not multi-line and has no arguments. Response code 206 Generated by: COMPRESS Meaning: compression layer activated 7. Security Considerations Security issues are discussed throughout this document. In general, the security considerations of the NNTP core specification ([RFC3977] Section 12) and the DEFLATE compressed data format specification ([RFC1951] Section 6) are applicable here. Implementers should be aware that combining compression with encryption like TLS can sometimes reveal information that would not have been revealed without compression, as explained in Section 6 of [RFC3749]. As a matter of fact, adversaries that observe the length of the compressed data might be able to derive information about the Murchison & Elie Expires April 29, 2017 [Page 13] Internet-Draft NNTP Extension for Compression October 2016 corresponding uncompressed data. The CRIME and the BREACH attacks ([RFC7457] Section 2.6) are examples of such case. In order to help mitigate leaking authentication credentials, this document states in Section 2.2.2 that authentication MUST NOT be attempted after a successful use of COMPRESS. Therefore, when a client wants to authenticate, compress data, and negotiate a TLS security layer (without TLS-level compression) in the same NNTP connection, it MUST use the STARTTLS, AUTHINFO, and COMPRESS commands in that order. Of course, instead of using the STARTTLS command, a client can also use implicit TLS, that is to say it begins the TLS negotiation immediately upon connection on a separate port dedicated to NNTP over TLS. NNTP commands other than AUTHINFO are not believed to divulge confidential information as long as only public Netnews newsgroups and articles are accessed. That is why this specification only prohibits the use of AUTHINFO after COMPRESS. In case confidential articles are accessed in private newsgroups, special care is needed: implementations SHOULD NOT compress confidential data together with public data when a TLS [RFC5246] or SASL [RFC4422] security layer is active. As a matter of fact, adversaries that observe the length of the compressed data might be able to derive information about it, when public data (that adversaries know is read) and confidential data are compressed in the same compress session. Additionally, it is preferable not to compress the contents of two distinct confidential articles together if it can be avoided, as adversaries might be able to derive information about them (for instance if they have a few header fields or body lines in common). This can be achieved for instance with DEFLATE by clearing the compression dictionary each time a confidential article is sent. More complex implementations are of course possible, and encouraged. Implementations are encouraged to unconditionally allow compression when no security layer is active, and to support an option to enable or disable compression when a security layer is active. Such an option could for instance be with global scope or server/connection based. Besides, as compression may in general weaken the confidentiality of a security layer, implementations SHOULD NOT automatically enable compression when a security layer is active unless the user explicitly enabled it with this knowledge. Future extensions to NNTP that define commands conveying confidential data SHOULD ensure to state that these confidential data SHOULD NOT be compressed together with public data when a security layer is active. Murchison & Elie Expires April 29, 2017 [Page 14] Internet-Draft NNTP Extension for Compression October 2016 Last but not least, careful consideration should be given to protections against implementation errors that introduce security risks with regards to compression algorithms. See for instance the part of Section 6 of [RFC3749] about compression algorithms that can occasionally expand, rather than compress, input data. 8. IANA Considerations 8.1. NNTP Compression Algorithm Registry The NNTP Compression Algorithm registry will be maintained by IANA. The registry will be available at . The purpose of this registry is not only to ensure uniqueness of values used to name NNTP compression algorithms, but also to provide a definitive reference to technical specifications detailing each NNTP compression algorithm available for use on the Internet. An NNTP compression algorithm is either a private algorithm, or its name is included in the IANA NNTP Compression Algorithm registry (in which case it is a "registered NNTP compression algorithm"). Different entries in the registry MUST use different names. Private algorithms with unregistered names are allowed, but SHOULD NOT be used because it is difficult to achieve interoperability with them. The 206, 403, and 502 response codes that a news server answers to the COMPRESS command using a private compression algorithm MUST have the same meaning as the one documented in Section 2.2 of this document. The procedure detailed in Section 8.1.1 is to be used for registration of a value naming a specific individual compression algorithm. Any name that conforms to the syntax of an NNTP compression algorithm name (Section 5.3) can be used. Especially, NNTP compression algorithms are named by strings, from 1 to 20 characters in length, consisting of upper-case letters, digits, hyphens, and/or underscores. Comments may be included in the registry as discussed in Section 8.1.2 and may be changed as discussed in Section 8.1.3. Murchison & Elie Expires April 29, 2017 [Page 15] Internet-Draft NNTP Extension for Compression October 2016 8.1.1. Algorithm Name Registration Procedure IANA will register new NNTP compression algorithm names on a First Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has the right to reject obviously bogus registration requests, but will perform no review of claims made in the registration form. Registration of an NNTP compression algorithm is requested by filling in the following template and sending it via electronic mail to IANA at : Subject: Registration of NNTP compression algorithm Z NNTP compression algorithm name: Security considerations: Published specification (recommended): Contact for further information: Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) Owner/Change controller: Note: (Any other information that the author deems relevant may be added here.) While this registration procedure does not require expert review, authors of NNTP compression algorithms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed algorithm as an Internet-Draft. NNTP compression algorithms intended for widespread use should be standardized through the normal IETF process, when appropriate. 8.1.2. Comments on Algorithm Registrations Comments on a registered NNTP compression algorithm should first be sent to the "owner" of the algorithm and/or to the mailing list for the now concluded IETF NNTPEXT working group (). Submitters of comments may, after a reasonable attempt to contact the owner and/or the above mailing list, request IANA to attach their comment to the NNTP compression algorithm registration itself by sending mail to . At IANA's sole discretion, IANA may attach the comment to the NNTP compression algorithm's registration. Murchison & Elie Expires April 29, 2017 [Page 16] Internet-Draft NNTP Extension for Compression October 2016 8.1.3. Change Control Once an NNTP compression algorithm registration has been published by IANA, the owner may request a change to its definition. The change request follows the same procedure as the initial registration request. The owner of an NNTP compression algorithm may pass responsibility for the algorithm to another person or agency by informing IANA; this can be done without discussion or review. The IESG may reassign responsibility for an NNTP compression algorithm. The most common case of this will be to enable changes to be made to algorithms where the owner of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community. NNTP compression algorithm registrations MUST NOT be deleted; algorithms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" field; such algorithms will be clearly marked in the registry published by IANA. The IESG is considered to be the owner of all NNTP compression algorithms that are on the IETF standards track. 8.2. Registration of the DEFLATE Compression Algorithm This section gives a formal definition of the DEFLATE compression algorithm as required by Section 8.1.1 for the IANA registry. NNTP compression algorithm name: DEFLATE Security considerations: See Section 7 of this document Published specification: This document Contact for further information: Authors of this document Intended usage: COMMON Owner/Change controller: IESG Note: This algorithm is mandatory to implement This registration will appear as follows in the NNTP Compression Algorithm registry: Murchison & Elie Expires April 29, 2017 [Page 17] Internet-Draft NNTP Extension for Compression October 2016 +----------------+----------------+---------------+ | Algorithm Name | Intended Usage | Reference | +----------------+----------------+---------------+ | DEFLATE | COMMON | [ RFC-to-be ] | +----------------+----------------+---------------+ 8.3. Registration of the NNTP COMPRESS Extension This section gives a formal definition of the COMPRESS extension as required by Section 3.3.3 of [RFC3977] for the IANA registry. o The COMPRESS extension allows an NNTP connection to be effectively and efficiently compressed. o The capability label for this extension is "COMPRESS", whose arguments list the available compression algorithms. o This extension defines one new command, COMPRESS, whose behavior, arguments, and responses are defined in Section 2.2. o This extension does not associate any new responses with pre- existing NNTP commands. o This extension does affect the overall behavior of both server and client, in that after successful use of the COMPRESS command, all communication is transmitted in a compressed format. o This extension does not affect the maximum length of commands or initial response lines. o This extension does not alter pipelining, but the COMPRESS command cannot be pipelined. o Use of this extension does alter the capabilities list; once the COMPRESS command has been used successfully, the COMPRESS capability can no longer be advertised by CAPABILITIES. Additionally, the STARTTLS and MODE-READER capabilities MUST NOT be advertised, and the AUTHINFO capability label MUST either be listed with no arguments or not advertised at all after a successful execution of the COMPRESS command. o This extension does not cause any pre-existing command to produce a 401, 480, or 483 response code. o This extension is unaffected by any use of the MODE READER command; however, the MODE READER command MUST NOT be used in the same session following a successful execution of the COMPRESS command. Murchison & Elie Expires April 29, 2017 [Page 18] Internet-Draft NNTP Extension for Compression October 2016 o The STARTTLS and AUTHINFO commands MUST NOT be used in the same session following a successful execution of the COMPRESS command. o Published Specification: This document. o Contact for Further Information: Authors of this document. o Change Controller: IESG . This registration will appear as follows in the NNTP capability labels registry contained in the Network News Transfer Protocol (NNTP) Parameters registry: +----------+----------------------------------+---------------+ | Label | Meaning | Reference | +----------+----------------------------------+---------------+ | COMPRESS | Supported compression algorithms | [ RFC-to-be ] | +----------+----------------------------------+---------------+ 9. References 9.1. Normative References [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, DOI 10.17487/RFC3977, October 2006, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Murchison & Elie Expires April 29, 2017 [Page 19] Internet-Draft NNTP Extension for Compression October 2016 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . 9.2. Informative References [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty Security Conference, 2012. [IEEE.1003-2.1992] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2, 1992. [MNP] Held, G., "The Complete Modem Reference", Second Edition, Wiley Professional Computing, May 1994. [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, DOI 10.17487/RFC1962, June 1996, . [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 2004, . [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, . [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 2006, . [RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Authentication", RFC 4643, DOI 10.17487/RFC4643, October 2006, . [RFC4644] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Streaming Feeds", RFC 4644, DOI 10.17487/RFC4644, October 2006, . Murchison & Elie Expires April 29, 2017 [Page 20] Internet-Draft NNTP Extension for Compression October 2016 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, DOI 10.17487/RFC4978, August 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [V42bis] International Telecommunications Union, "Data compression procedures for data circuit-terminating equipment (DCE) using error correction procedures", ITU-T Recommendation V.42bis, January 1990. [yEnc] Helbing, J., "yEnc - Efficient encoding for Usenet and eMail", March 2002, . Murchison & Elie Expires April 29, 2017 [Page 21] Internet-Draft NNTP Extension for Compression October 2016 Appendix A. Acknowledgments This document draws heavily on ideas in [RFC4978] by Arnt Gulbrandsen; a large portion of this text was borrowed from that specification. The authors would like to thank the following individuals for contributing their ideas and reviewing this specification: Mark Adler, Russ Allbery, Stephane Bortzmeyer, Francis Dupont, Angel Gonzalez, Barry Leiba, John Levine, and Brian Peterson. Special thanks to our Document Shepherd, Michael Baeuerle, who significantly helped to increase the quality of this specification. Many thanks to the Responsible Area Director, Alexey Melnikov, for reviewing and sponsoring this document. Appendix B. Document History (to be removed by RFC Editor before publication) B.1. Changes since -05 o Take into account all the remarks sent during IETF Last Call. o Do not prevent the registration of compression algorithm names beginning with "X" (in conformance with RFC6648). Also, in the examples, use "SHRINK" instead of "X-SHRINK". o Separate Section 3 and Section 4 because the latter uses normative keywords. Also improve and simplify the wording of these two Sections, notably by distinguishing NNTP simple responses and NNTP multi-line responses, and by not being categorical that Z_PARTIAL_FLUSH is the best and only flush operation to use. o Do not declare non-compliant an implementation that only supports COMPRESS when there is no security layer. o Move [RFC1951] reference to normative, and [RFC4642] reference to informative. o Explain why STARTTLS is not allowed after COMPRESS. o Improve security by stating that authentication MUST NOT be attempted after COMPRESS has been successfully executed. Do not change, though, the behaviour of AUTHINFO as described in [RFC4643], allowing authentication even though TLS-level compression is active. Murchison & Elie Expires April 29, 2017 [Page 22] Internet-Draft NNTP Extension for Compression October 2016 o Require that all data that was submitted for compression MUST be included in the compressed output, and appropriately flushed. o Mention possible security risks with regards to compression algorithms. o Mention that using unregistered algorithms decrease interoperability. o Mention the exact contents of the IANA registrations asked by this document. o NNTP compression algorithm names really are case-sensitive. Update ABNF syntax accordingly. o Minor other wording improvements. B.2. Changes since -04 o Reworded a sentence wrongly using "MAY NOT" (not a key word defined in [RFC2119]). o Uppercased a "must" and a "should" in Section 4. B.3. Changes since -03 o Added a naming convention for NNTP compression algorithms. Improve the wording of registered vs private compression algorithms. o If a registered NNTP compression algorithm is advertised, it MUST fully conform with its related specification. o Fixed the wording of security considerations to reflect that the threat appears when public and confidential data are compressed together inside a security layer. Thanks to Angel Gonzalez for pointing that. o The default configuration SHOULD be disabled compression when a security layer is active. o COMPRESS acts as a compression layer, not a transport layer. o Minor editorial changes. Murchison & Elie Expires April 29, 2017 [Page 23] Internet-Draft NNTP Extension for Compression October 2016 B.4. Changes since -02 o Added text stating that the receiving end SHOULD terminate the connection when receiving invalid or corrupted compressed data. o Explained why COMPRESS permits to do better than existing unstandardized commands like XZVER, XZHDR, MODE COMPRESS, and XFEATURE GZIP. o Added an example of AUTHINFO command when compression is active. o The LIST capability label was missing in the examples when READER was also advertised. o Improved an example to send CAPABILITIES after successful authentication. o Mentioned that COMPRESS is related to security. CAPABILITIES is therefore sent again after COMPRESS. o Re-added discussion of attachments in binary form and incompressible file formats. Improve the discussion about flushes, and add a specific section about DEFLATE. o Changed a MUST NOT to SHOULD NOT for the use of AUTHINFO after COMPRESS. o Algorithm names are case-insensitive. o Mentioned the use of the 501 response code. o Added the Security Considerations Section. o Added Julien Elie as co-author of this document. o Minor editorial changes. B.5. Changes since -01 o Switched to using 206 response code when compression has been activated. o Added text stating that TLS-level compression is susceptible to CRIME attack and current BCP is to disable it. o Added text stating that AUTHINFO shouldn't be advertised or used after COMPRESS to prevent possible CRIME attack (with example). Murchison & Elie Expires April 29, 2017 [Page 24] Internet-Draft NNTP Extension for Compression October 2016 o Added text stating that a windowBits value of -15 should be used for inflateInit2(). o Minor editorial changes. B.6. Changes since -00 o Made DEFLATE the mandatory to implement compression algorithm. o Removed the requirement that clients/servers implementing COMPRESS also implement TLS compression. o Added an example of a client trying to use an unsupported compression algorithm. o Rewrote Compression Efficiency (Section 3) as follows: * Included a sample listing of which NNTP commands produce which type of data to be compressed. * Removed discussion of attachments in binary form and incompressible file formats. * Mentioned UUencode and yEnc encoding of attachments. o Added IANA registry of NNTP compression algorithms. o Miscellaneous editorial changes submitted by Julien Elie. Authors' Addresses Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 USA Phone: +1 412 268 1982 EMail: murch@andrew.cmu.edu Julien Elie 10 allee Clovis Noisy-le-Grand 93160 France EMail: julien@trigofacile.com URI: http://www.trigofacile.com/ Murchison & Elie Expires April 29, 2017 [Page 25] ./draft-weis-gdoi-iec62351-9-10.txt0000664000764400076440000015227313004703501015625 0ustar iustyiusty Network Working Group B. Weis Internet-Draft M. Seewald Intended status: Standards Track Cisco Systems Expires: May 1, 2017 H. Falk SISCO October 28, 2016 GDOI Protocol Support for IEC 62351 Security Services draft-weis-gdoi-iec62351-9-10 Abstract The IEC 61850 power utility automation family of standards describe methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC 62351-9 standards specify the use of the Group Domain of Interpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo defines GDOI payloads to support those security protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 1, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Weis, et al. Expires May 1, 2017 [Page 1] Internet-Draft GDOI-IEC62351 October 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 2. IEC 61850 Protocol Information . . . . . . . . . . . . . . . 4 2.1. ID Payload . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . 6 2.3. KD Payload . . . . . . . . . . . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 . 18 Appendix B. Implementation Considerations . . . . . . . . . . . 23 B.1. DER Length Fields . . . . . . . . . . . . . . . . . . . . 23 B.2. Groups with Multiple Senders . . . . . . . . . . . . . . 23 Appendix C. Data Attribute Format . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Power substations use Generic Object Oriented Substation Events (GOOSE) protocol [IEC-61850-8-1] to distribute control information to groups of devices using a multicast strategy. Sources within the power substations also distribute IEC 61850-9-2 sampled values data streams [IEC-61850-9-2]. The IEC 62351-9 standard [IEC-62351-9] describes key management methods for the security methods protecting these IEC 61850 messages, including methods of device authentication and authorization, and methods of policy and keying material agreement for IEC 61850 message encryption and data integrity protection. These key management methods include the use of GDOI [RFC6407] to distribute the security policy and session keying material used to protect IEC 61850 messages when the messages are sent to a group of devices. The protection of the messages is defined within IEC 62351-6 [IEC-62351-6], IEC 61850-8-1 [IEC-61850-8-1], and IEC 61850-9-2 [IEC-61850-9-2]. Protected IEC 61850 messages typically include the output of a Message Authentication Code (MAC) and may also be Weis, et al. Expires May 1, 2017 [Page 2] Internet-Draft GDOI-IEC62351 October 2016 encrypted using a symmetric cipher such as the Advanced Encryption Standard (AES). Section 5.5.2 of RFC 6407 specifies that the following information needs to be provided in order to fully define a new Security Protocol: o The Protocol-ID for the particular Security Protocol. o The SPI Size o The method of SPI generation o The transforms, attributes, and keys needed by the Security Protocol. This document defines GDOI payloads to distribute policy and keying material to protect IEC 61850 messages, and defines the necessary information to ensure interoperability between IEC 61850 implementations. This memo extends RFC 6407 in order to define extensions needed by IEC 62351-9. With the current IANA registry rules setup by RFC 6407, this requires a standards action by the IETF - essentially that means the production of this document. As the relevant IEC specifications are not available to the IETF community, it is not possible for this RFC to fully describe the security considerations applying. Implementers therefore need to depend on the security analysis within the IEC specifications. As two different Standards Development Organizations are involved here, and since group key management is inherently complex, it is possible some security issues have not been identified, so additional analysis of the security of the combined set of specifications may be advisable. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology The following key terms are used throughout this document: Generic Object Oriented Substation Events: Power substation control model defined as per IEC 61850. Weis, et al. Expires May 1, 2017 [Page 3] Internet-Draft GDOI-IEC62351 October 2016 IEC 61850 message: A message in the IEC 61850 family of protocols carrying control or data between Substation devices. 1.3. Acronyms and Abbreviations The following acronyms and abbreviations are used throughout this document AES Advanced Encryption Standard GCKS Group Controller/Key Server GDOI Group Domain of Interpretation GM Group Member GOOSE Generic Object Oriented Substation Events KD Key Download KEK Key Encryption Key MAC Message Authentication Code SA Security Association SPI Security Parameter Index TEK Traffic Encryption Key 2. IEC 61850 Protocol Information The following sections describe the GDOI payload extensions that are needed in order to distribute security policy and keying material for the IEC 62351 Security Services. The Identification (ID) Payload is used to describe an IEC 62351 GDOI group. The Security Association (SA) Traffic Encryption Key (TEK) payload is used to describe the policy defined by a Group Controller/Key Server (GCKS) for a particular IEC 62351 traffic selector. No changes are required to the Key Download (KD) Payload, but a mapping of IEC 62351 keys to KD Payload key types is included. All multioctet fields are in network byte order. Weis, et al. Expires May 1, 2017 [Page 4] Internet-Draft GDOI-IEC62351 October 2016 2.1. ID Payload The ID payload in a GDOI GROUPKEY-PULL exchange allows the Group Member (GM) to declare the group it would like to join. A group is defined by an ID payload as defined in GDOI [RFC6407] and reproduced in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ID Type ! DOI-Specific ID Data = 0 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 1: RFC 6407 Identification Payload An ID Type name of ID_OID (value 13) is defined in this memo to specify an Object Identifier (OID) [ITU-T-X.683] encoded using Distinguished Encoding Rules (DER) [ITU-T-X.690]. Associated with the OID may be an OID Specific Payload DER encoded as further defining the group. Several OIDs are specified in [IEC-62351-9] for use with IEC 61850. Each OID represents a GOOSE or Sampled Value protocol, and in some cases IEC 61850 also specifies a particular multicast destination address to be described in the OID Specific Payload field. The format of the ID_OID Identification Data is specified as shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Length ! OID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Specific Payload Length ! OID Specific Payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 2: ID_OID Identification Data The ID_OID Identification Data fields are defined as follows: o OID Length (1 octet) -- Length of the OID field. o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER [ITU-T-X.690]. Weis, et al. Expires May 1, 2017 [Page 5] Internet-Draft GDOI-IEC62351 October 2016 o OID Specific Payload Length (2 octets) -- Length of the OID Specific Payload. Set to zero if the OID does not require an OID Specific Payload. o OID Specific Payload (variable) -- OID specific selector encoded in DER. If OID Specific Payload Length is set to zero this field does not appear in the ID payload. 2.2. SA TEK Payload The SA TEK payload contains security attributes for a single set of policy associated with a group TEK. The type of policy to be used with the TEK is described by a Protocol-ID field included in the SA TEK. As shown in Figure 3 reproduced from RFC 6407, each Protocol-ID describes a particular TEK Protocol-Specific Payload definition. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Protocol-ID ! TEK Protocol-Specific Payload ~ +-+-+-+-+-+-+-+-+ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 3: RFC 6407 SA TEK Payload The Protocol-ID name of GDOI_PROTO_IEC_61850 (value TBD1) is defined in this memo for the purposes of distributing IEC 61850 policy. A GDOI_PROTO_IEC_61850 SA TEK includes an OID and (optionally) an OID Specific Payload that together define the selectors for the network traffic. The selector fields are followed by security policy fields indicating how the specified traffic is to be protected. The GDOI_PROTO_IEC_61850 TEK Protocol-Specific Payload is defined as shown in Figure 4. Weis, et al. Expires May 1, 2017 [Page 6] Internet-Draft GDOI-IEC62351 October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Length ! OID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Specific Payload Length ! OID Specific Payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Auth Alg ! Enc Alg ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Remaining Lifetime Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SA Data Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 4: IEC-61850 SA TEK Payload The GDOI_PROTO_IEC_61850 SA TEK Payload fields are defined as follows: o OID Length (1 octet) -- Length of the OID field. o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER. OIDs defined in IEC 61850 declare the type of IEC 61850 message to be protected, as defined by [IEC-62351-9]. o OID Specific Payload Length (2 octets) -- Length of the OID Specific Payload. This field is set to zero if the policy does not include an OID Specific Payload. o OID Specific Payload (variable) -- The traffic selector (e.g., multicast address) specific to the OID encoded using DER. Some OID policy settings do not require the use of an OID Specific Payload, in which case this field is not included in the TEK and the OID Specific Payload Length is set to zero. o SPI (4 octets) -- Identifier for the Current Key. This field represents a SPI. o Auth Alg (2 octets) -- Authentication Algorithm ID. Valid values are define in Section 2.2.2. o Enc Alg (2 octets) -- Confidentiality Algorithm ID. Valid values are define in Section 2.2.3. Weis, et al. Expires May 1, 2017 [Page 7] Internet-Draft GDOI-IEC62351 October 2016 o Remaining Lifetime value (4 octets) -- The number of seconds remaining before this TEK expires. A value of zero (0) shall indicate that the TEK does not have an expire time. o SA Data Attributes (variable length) -- Contains zero or more attributes associated with this SA. Section Section 2.2.4 defines attributes. 2.2.1. Selectors The OID and (optionally) an OID Specific Payload that together define the selectors for the network traffic. While they may match the OID and OID Specific Payload that the GM had previously requested in the ID payload, there is no guarantee that this will be the case. Including selectors in the SA TEK is important for at least the following reasons: o The KS policy may direct the KS to return multiple TEKs, each representing different traffic selectors and it is important that every GM receiving the set of TEKs explicitly identify the traffic selectors associated with the TEK. o The KS policy may include the use of a GDOI GROUPKEY-PUSH message, which distributes new or replacement TEKs to group members. Since the GROUPKEY-PUSH message does not contain an ID payload the TEK definition must include the traffic selectors. 2.2.2. Authentication Algorithms This memo defines the following Authentication Algorithms for use with this TEK. These algorithms are defined in [IEC-TR-61850-90-5], including requirements on one or more algorithms defined as mandatory to implement. o NONE. Specifies that a Authentication Algorithm is not required, or when the accompanying confidentiality algorithm includes authentication (e.g., AES-GCM-128). See Section 3 for cautionary notes regarding using this value without any confidentiality algorithm. o HMAC-SHA256-128. Specifies the use of SHA-256 [FIPS180-3.2008] combined with HMAC [RFC2104]. The output is truncated to 128 bits, as per [RFC2104]. The key size is the size of the hash value produced by SHA-256 (256 bits). o HMAC-SHA256. Specifies the use of SHA-256 [FIPS180-3.2008] combined with HMAC [RFC2104]. The key size is the size of the hash value produced by SHA-256 (256 bits). Weis, et al. Expires May 1, 2017 [Page 8] Internet-Draft GDOI-IEC62351 October 2016 o AES-GMAC-128. Specifies the use of AES [FIPS197] in the Galois Message Authentication Code (GMAC) mode [SP.800-38D] with a 128 bit key size. o AES-GMAC-256. Specifies the use of AES [FIPS197] in the Galois Message Authentication Code (GMAC) mode [SP.800-38D] with a 256 bit key size. 2.2.3. Confidentiality Algorithms This memo defines the following Confidentiality Algorithms for use with this TEK. These algorithms are defined in [IEC-TR-61850-90-5], including requirements on one or more algorithms defined as mandatory to implement. o NONE. Specifies that Confidentiality is not required. NOTE: See Section 3 for guidance for cautionary notes regarding using this value. o AES-CBC-128. Specifies the use of AES [FIPS197] in the Cipher Block Chaining (CBC) mode [SP.800-38A] with a 128 bit key size. This encryption algorithm does not provide authentication and MUST NOT be used with the NONE Authentication Algorithm. o AES-CBC-256. Specifies the use of AES [FIPS197] in the Cipher Block Chaining (CBC) mode [SP.800-38A] with a 256 bit key size. This encryption algorithm does not provide authentication and MUST NOT be used with the NONE Authentication Algorithm. o AES-GCM-128. Specifies the use of AES [FIPS197] in the Galois/ Counter Mode (GCM) mode [SP.800-38D] with a 128 bit key size. This encryption algorithm provides authentication and is used with a NONE Authentication Algorithm. o AES-GCM-256. Specifies the use of AES [FIPS197] in the Galois/ Counter Mode (GCM) mode [SP.800-38D] with a 256 bit key size. This encryption algorithm provides authentication and is used with a NONE Authentication Algorithm. 2.2.4. SA Attributes The following attributes may be present in an SA TEK. The attributes must follow the format described in Appendix C). Weis, et al. Expires May 1, 2017 [Page 9] Internet-Draft GDOI-IEC62351 October 2016 2.2.4.1. SA Time Activation Delay (SA_ATD) A GCKS will sometimes distribute an SA TEK in advance of when it is expected to be used. This is communicated to group members using the SA Activation Time Delay (SA_ATD) attribute. When a GM receives an SA_TEK with this attribute, it waits for the number of seconds contained within the attribute before installing it for either transmission or receiving. This Activation Time Delay attribute applies only this SA, and MAY be used in either a GROUPKEY-PULL or GROUPKEY-PUSH exchange. RFC 6407 also describe an ACTIVATION_TIME_DELAY attribute for the Group Associated Policy (GAP) payload, which is applied to all Security Associations and restricted to use in a GROUPKEY-PUSH message. If both attributes are included in a GROUPKEY-PUSH payload, the value contained in SA_ATD will be used. 2.2.4.2. Key Delivery Assurance (SA_KDA) Group policy can include notifying a multicast source ("Publisher") of an indication of whether multicast receivers ("Subscribers") have previously received the SA TEK. This notification allows a Publisher to set a policy as to whether to activate the new SA TEK or not based on the percentage of Subscribers that are able to receive packets protected by the SA TEK. The attribute value is a number between 0 and 100 (inclusive). 2.2.5. SPI Discussion As noted in Section 1, RFC 6407 requires that characteristics of a SPI must be defined. A SPI in a GDOI_PROTO_IEC_61850 SA TEK is represented as a Key Identifier (KeyID). The SPI size is 4 octets. The SPI is unilaterally chosen by the GCKS using any method chosen by the implementation. However, an implementation needs to take care not to duplicate a SPI value that is currently in use for a particular group. 2.3. KD Payload The KD Payload contains group keys for the policy specified in the SA Payload. It is comprised of a set of Key Packets, each of which hold the keying material associated with a SPI (i.e., an IEC 61850 Key Identifier). The RFC 6407 KD payload format is reproduced in Figure 5. Weis, et al. Expires May 1, 2017 [Page 10] Internet-Draft GDOI-IEC62351 October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Number of Key Packets ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packets ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 5: KD Payload Each Key Packet holds the keying material associated with a particular IEC 61850 Key Identifier, although GDOI refers to it as a SPI. The keying material is described in a set of attributes indicating an encryption key, integrity key, etc., in accordance with the security policy of the group as defined by the associated SA Payload. Each Key Packet has the following format, reproduced in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! KD Type ! RESERVED ! Key Packet Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI Size ! SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packet Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 6: Key Packet No changes are needed to GDOI in order to distribute IEC 61850 keying material, but the keys MUST be distributed as defined in Section 5.6 of RFC 6407. The KD Type MUST be TEK (1). A key associated with an IEC 61850 Authentication Algorithm (distributed in the Auth Alg field) MUST be distributed as a TEK_INTEGRITY_KEY attribute. The value of the attribute is interpreted according to the type of key distributed in the SA TEK: o HMAC-SHA256-128, HMAC-SHA256. The value is 32 octets. o AES-GMAC-128. The value is 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the salt value in the nonce. Weis, et al. Expires May 1, 2017 [Page 11] Internet-Draft GDOI-IEC62351 October 2016 o AES-GMAC-256. The value is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the salt value in the nonce. A key associated with an IEC 61850 Confidentiality Algorithm (distributed in the Enc Alg SA TEK field) MUST be distributed as a TEK_ALGORITHM_KEY attribute. The value of the attribute is interpreted according to the type of key distributed in the SA TEK: o AES-CBC-128. The value is 16 octets. o AES-CBC-256. The value is 32 octets. o AES-GCM-128. The value is 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the salt value in the nonce. o AES-GCM-256. The value is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the salt value in the nonce. 3. Security Considerations GDOI is a security association (SA) management protocol for groups of senders and receivers. This protocol performs authentication of communicating protocol participants (Group Member, Group Controller/ Key Server). GDOI provides confidentiality of key management messages, and it provides source authentication of those messages. GDOI includes defenses against man-in-middle, connection hijacking, replay, reflection, and denial-of-service (DOS) attacks on unsecured networks. GDOI assumes the network is not secure and may be under the complete control of an attacker. The Security Considerations described in RFC 6407 are relevant to the distribution of GOOSE and sampled values policy as defined in this memo. Message Authentication is an optional property for IEC 62351 Security Services, however when encryption is used authentication MUST also be provided by using an authenticated encryption algorithm such as AES- GCM-128 or by using a specific authentication algorithm such as HMAC- SHA-256. Setting the Authentication Algorithm to NONE, but setting the Confidentiality Algorithm to an algorithm that does not include authentication (i.e., is marked with an N in the "Authenticated Encryption" column of the IEC62351-9 Confidentiality Values IANA Registry) is not safe, and MUST NOT be used. When Message Authentication is used, a common practice is to truncate the output of a MAC and include part of the bits in the integrity protection field of the data security transform. Current guidance in Weis, et al. Expires May 1, 2017 [Page 12] Internet-Draft GDOI-IEC62351 October 2016 [RFC2104] is to truncate no less than half of the length of the hash output. The authentication algorithm HMAC-SHA256-128 defined in this memo truncates the output to exactly half of the output, which follows this guidance. Confidentiality is an optional security property for IEC 62351 Security Services. Confidentiality Algorithm IDs SHOULD be included in the IEC-61850 SA TEK Payload if the IEC 61850 messages are expected to traverse public network links and not protected by another level of encryption (e.g., an encrypted Virtual Private Network). Current cryptographic advice indicates that the use of AES-CBC-128 for confidentiality is sufficient for the foreseeable future [SP.800-131], but some security policies may require the use of AES-CBC-256. IEC 62351 Security Services describes a variety of policy choices for protecting network traffic, including the option of specifying no protection at all. This is enabled with the use of NONE as an Authentication Algorithm and/or Confidentiality Algorithm. The following guidance is given regarding the use of NONE. o Setting both Authentication Algorithm and Confidentiality Algorithm to NONE is possible, but NOT RECOMMENDED. Setting such a policy is sometimes necessary during a migration period, when traffic is being protected incrementally and some traffic has not yet been scheduled for protection. Alternatively, site security policy for some packet flows requires inspection of packet data on the private network followed by network-layer encryption before delivery to a public network. o Setting the Confidentiality Algorithm to NONE, but setting the Authentication Algorithm to a MAC can be an acceptable policy in the following conditions: the disclosed information in the data packets is comprised of raw data values, and the disclosure of the data files is believed to be of no more value to an observer than traffic analysis on the frequency and size of packets protected for confidentiality. Alternatively, site security policy for some packet flows requires inspection of packet data on the private network followed by network-layer encryption before delivery to a public network. o Setting the Authentication Algorithm to NONE, but setting the Confidentiality Algorithm to an algorithm that does not includes authentication is not safe, and MUST NOT be used. Weis, et al. Expires May 1, 2017 [Page 13] Internet-Draft GDOI-IEC62351 October 2016 4. IANA Considerations The following additions are made to the GDOI payloads registry [GDOI-REG]. A new SA TEK Payload Values - Protocol-ID value is defined. Its type is GDOI_PROTO_IEC_61850, with a value of TBD1. A new registry is added defining Auth Alg values. The Attribute Class is called "IEC62351-9 Authentication Values". The terms Reserved, Expert Review and Private Use are to be applied as defined in [RFC5226]. Name Value ---- ----- Reserved 0 NONE 1 HMAC-SHA256-128 2 HMAC-SHA256 3 AES-GMAC-128 4 AES-GMAC-256 5 Expert Review 6-61439 Private Use 61440-65535 A new registry is added defining Enc Alg values. The Attribute Class is called "IEC62351-9 Confidentiality Values". The terms Expert Review and Private Use are to be applied as defined in [RFC5226]. Name Value Authenticated Encryption ---- ----- ------------------------ Reserved 0 NONE 1 AES-CBC-128 2 N AES-CBC-256 3 N AES-GCM-128 4 Y AES-GCM-256 5 Y Expert Review 6-61439 Private Use 61440-65535 A new registry for SA TEK attributes is defined. The Attribute call is called "GDOI SA TEK Attributes". The terms Expert Review and Expert Review are to be applied as defined in [RFC5226]. In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V). Weis, et al. Expires May 1, 2017 [Page 14] Internet-Draft GDOI-IEC62351 October 2016 Attribute Value Type --------- ----- ---- Reserved 0 SA_ATD 1 V SA_KDA 2 B Expert Review 3-28671 Private Use 28672-32767 A new registry for ID Types is defined for the Identification Payload when the DOI is GDOI. The registry is taken from the ID Types registry for the IPsec DOI, which were previously assumed. Values 1-12 are defined identically to the equivalent values in the IPsec DOI. Value 13 is defined in this memo. The terms Expert Review and Private Use are to be applied as defined in [RFC5226]. Name Value ---- ----- Reserved 0 ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 ID_LIST 12 ID_OID 13 Expert Review 14-61439 Private Use 61440-65535 5. Acknowledgements The authors thanks Sean Turner, Steffen Fries, Yoav Nir, Vincent Roca, Dennis Bourget, and David Boose for their thoughtful reviews, each of which resulted in substantial improvements to the memo. Joe Salowey provided valuable guidance as document shepherd during the publication process. The authors are indebted to Kathleen Moriarty for her agreement to sponsor the publication of the document. 6. References Weis, et al. Expires May 1, 2017 [Page 15] Internet-Draft GDOI-IEC62351 October 2016 6.1. Normative References [IEC-62351-9] International Electrotechnical Commission, "IEC 62351 Part 9 - Key Management", IEC 62351-9 , January 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, . 6.2. Informative References [FIPS180-3.2008] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008, . [FIPS197] "Advanced Encryption Standard (AES)", United States of America, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 197, November 2001. [GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, December 2004, . [IEC-61850-8-1] International Electrotechnical Commission, "Specific Communication networks and systems for power utility automation - Part 8-1: Specific communication service mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3", IEC-61850-8-1 , June 2011. Weis, et al. Expires May 1, 2017 [Page 16] Internet-Draft GDOI-IEC62351 October 2016 [IEC-61850-9-2] International Electrotechnical Commission, "Communication networks and systems for power utility automation - Part 9-2: Specific communication service mapping (SCSM) - Sampled values over ISO/IEC 8802-3", IEC-61850-2 , September 2011. [IEC-62351-6] International Electrotechnical Commission, "Power systems management and associated information exchange - Data and communications security - Part 6: Security for IEC 61850", IEC-62351-6 , June 2007. [IEC-TR-61850-90-5] International Electrotechnical Commission, "Communication networks and systems for power utility automation - Part 90-5: Use of IEC 61850 to transmit synchrophasor information according to IEEE C37.118", IEC 62351-9 , May 2012. [ITU-T-X.683] "Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications", SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI networking and system aspects - Abstract Syntax Notation One (ASN.1) , July 2002, . [ITU-T-X.690] "Information technology-ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", SERIES X: DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY OSI networking and system aspects - Abstract Syntax Notation One (ASN.1) , 2008, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [SP.800-131] Barker, E. and A. Roginsky, "Recommendation for the Transitioning of Cryptographic Algorithms and Key Lengths", United States of America, National Institute of Science and Technology DRAFT NIST Special Publication 800-131, June 2010. Weis, et al. Expires May 1, 2017 [Page 17] Internet-Draft GDOI-IEC62351 October 2016 [SP.800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", United States of America, National Institute of Science and Technology, NIST Special Publication 800-38A 2001 Edition, December 2001. [SP.800-38D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", United States of America, National Institute of Science and Technology, NIST Special Publication 800-38D, November 2007. Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 An IED begins a GROUPKEY-PULL exchange and requests keys and security policy for 61850_UDP_ADDR_GOOSE (OID = 1.2.840.10070.61850.8.1.2 as defined in [IEC-61850-9-2]) and IP multicast address 233.252.0.1 encoded as specified in [IEC-61850-9-2]. OID and OID Specific Payload protocol fields are variable length fields. To improve readability, their representations in Figure 7 and Figure 8 are "compressed" in the figure, as indicated by a trailing "~" for these fields. Implementations should be aware that because these fields are variably sized, some payload fields may not be conveniently aligned on an even octet. Note 2: The actual DER for the OID Specific Payload field is defined in [IEC-62351-6]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ID Type=13 ! DOI-Specific ID Data = 0 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Specific Payload Len ! OID SP= ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 7: Sample Identification Payload The Key Server responds with the following SA TEK payload including two GDOI_PROTO_IEC_61850 Protocol-Specific TEK payloads in the second GROUPKEY-PULL message. The first one is to be activated immediately, and has a lifetime of 3600 seconds (0x0E10) remaining. The second Weis, et al. Expires May 1, 2017 [Page 18] Internet-Draft GDOI-IEC62351 October 2016 has a lifetime of 12 hours (0xA8C0) and should be activated in 3300 seconds (0x0CE4), which givens a 5 minute (300 seconds) overlap of the two SAs. Weis, et al. Expires May 1, 2017 [Page 19] Internet-Draft GDOI-IEC62351 October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DOI = 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Situation = 0 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! NP=16 (SA TEK)! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Prot-ID=TBD1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Specific Payload Len !OID SP= ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI=1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! AuthAlg=1 (HMAC-SHA256-128) ! EncAlg=2 (AES-CBC-128) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Remaining Lifetime=0x0E01 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! NP=0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Prot-ID=TBD1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! OID Specific Payload Len !OID SP= ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI=2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! AuthAlg=0 (NONE) ! EncAlg=4 (AES-GCM-128) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Remaining Lifetime=0xA8C0 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Type=1 (SA_ATD) ! Length=4 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Value=0x0CE4 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 8: Sample IEC-61850 SA Payload Weis, et al. Expires May 1, 2017 [Page 20] Internet-Draft GDOI-IEC62351 October 2016 The IED acknowledges that it is capable and willing to use this policy in the third GROUPKEY-PULL message. In response the KS sends a KD payload to the requesting IED. This concludes the GROUPKEY-PULL exchange. Weis, et al. Expires May 1, 2017 [Page 21] Internet-Draft GDOI-IEC62351 October 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Number of Key Packets=2 ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! KD Type=1 ! RESERVED ! Key Packet Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI Size=4 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI=1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ! ! ! ! ! HMAC-SHA256 Key ! ! ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ! AES-CBC-128 Key ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! KD Type=1 ! RESERVED ! Key Packet Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI Size=4 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI=2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=20 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ! AES-GCM-128 Key & Salt ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 9: Sample KD Payload Weis, et al. Expires May 1, 2017 [Page 22] Internet-Draft GDOI-IEC62351 October 2016 Appendix B. Implementation Considerations Several topics have been suggested as useful for implementors. B.1. DER Length Fields The ID and SA TEK payloads defined in this memo include explicit lengths for fields formatted as DER. This includes the OID Length and OID Specific Payload Length fields shown in Figure 2 and Figure 4. Strictly speaking, these lengths are redundant since the length of the DER value is also encoded within the DER fields. It would be possible to determine the lengths of the fields from those encoded values. However, many implementations will find the explicit length fields convenient when constructing and sanity checking the GDOI messages including these payloads. Implementations will thus be spared from manipulating the DER itself when performing activities that do not otherwise require parsing in order to obtain values therein. B.2. Groups with Multiple Senders GCKS policy may specify more than one protected type of IEC 61850 message within a GDOI group. This is represented within a GDOI SA Payload by the presence of an SA TEK Payload for each multicast group that is protected as part of group policy. The OID contained in each of the SA TEK Payloads may be identical, but the value of each OID Specific Payload would be unique. Typically, the OID Specific Payload defines a destination address, and typically there is a single sender to that destination address. Appendix C. Data Attribute Format Data attributes attached to an SA TEK following the Data Attribute format described in this section. Data attributes can be in Type/ Value (TV) format (useful when a value is defined to be less than two octets in size) or in Type/Length/Value (TLV) form. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !A! Attribute Type ! AF=0 Attribute Length ! !F! ! AF=1 Attribute Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . AF=0 Attribute Value . . AF=1 Not Transmitted . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Data Attributes Weis, et al. Expires May 1, 2017 [Page 23] Internet-Draft GDOI-IEC62351 October 2016 The Data Attributes fields are defined as follows: o Attribute Type (2 octets) - Unique identifier for each type of attribute. These attributes are defined as part of the DOI- specific information. The most significant bit, or Attribute Format (AF), indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is a zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form. o Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present. o Attribute Value (variable length) - Value of the attribute associated with the DOI-specific Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets. Authors' Addresses Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1 408 526 4796 Email: bew@cisco.com Maik Seewald Cisco Systems Am Soeldnermoos 17 D-85399 Hallbergmoos Germany Phone: +49 619 6773 9655 Email: maseewal@cisco.com Weis, et al. Expires May 1, 2017 [Page 24] Internet-Draft GDOI-IEC62351 October 2016 Herb Falk SISCO 6605 19-1/2 Mile Road Sterling Heights, MI 48314 USA Phone: +1 586 254 0020 x105 Email: herb@sisconet.com Weis, et al. Expires May 1, 2017 [Page 25] ./draft-wilde-json-seq-suffix-03.txt0000664000764400076440000002323313032060764016577 0ustar iustyiusty Network Working Group E. Wilde Internet-Draft CA Technologies Intended status: Informational December 31, 2016 Expires: July 4, 2017 A Media Type Structured Syntax Suffix for JSON Text Sequences draft-wilde-json-seq-suffix-03 Abstract Structured Syntax Suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+json-seq" as a structured syntax suffix for JSON Text Sequences. Note to Readers [[ The RFC Editor is requested to remove this section at publication. ]] This draft should be discussed on the ietf mailing list (). Online access to all versions and files is available on GitHub (). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 4, 2017. Wilde Expires July 4, 2017 [Page 1] Internet-DraftA Media Type Structured Syntax Suffix for JSODecember 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The "+json-seq" Structured Syntax Suffix . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Media Type Structured Syntax Suffixes [RFC6838] were introduced as a way for a media type to signal that it is based on another media type as its foundation. Some structured syntax suffixes were registered initially [RFC6839], including "+json" for the widely popular JSON Format [RFC7159]. JSON Text Sequences [RFC7464] is a recent specification in the JSON space that defines how a sequence of multiple JSON texts can be represented in one representation. This document defines and registers the "+json-seq" structured syntax suffix in the Structured Syntax Suffix Registry. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Wilde Expires July 4, 2017 [Page 2] Internet-DraftA Media Type Structured Syntax Suffix for JSODecember 2016 3. The "+json-seq" Structured Syntax Suffix The use case for the "+json-seq" structured syntax suffix is the same as for "+json": It SHOULD be used by media types when parsing the JSON Text Sequence of a media type leads to a meaningful result, by simply using the generic JSON Text Sequence processing. Applications encountering such a media type can then either simply use generic processing if all they need is a generic view of the JSON Text Sequence, or they can use generic JSON Text Sequence tools for initial parsing, and then can implement their own specific processing on top of that generic parsing tool. 4. IANA Considerations Structured Syntax Suffixes are registered within the "Structured Syntax Suffix Registry" maintained at . IANA is requested to register the "+json-seq" structured syntax suffix in accordance with [RFC6838]. Name: JSON Text Sequence +suffix: +json-seq References: [RFC7464], RFC [[ RFC Editor, please insert assigned RFC number. ]] Encoding considerations: See [RFC7464] Section 2.2 Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +json-seq SHOULD be as specified for "application/json-seq". (At publication of this document, there is no fragment identification syntax defined for "application/json-seq".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+json-seq" SHOULD be processed as follows: For cases defined in +json-seq, where the fragment identifier resolves per the +json-seq rules, then process as specified in +json-seq. For cases defined in +json-seq, where the fragment identifier does not resolve per the +json-seq rules, then process as specified in "xxx/yyy+json-seq". Wilde Expires July 4, 2017 [Page 3] Internet-DraftA Media Type Structured Syntax Suffix for JSODecember 2016 For cases not defined in +json-seq, then process as specified in "xxx/yyy+json-seq". Interoperability considerations: n/a Security considerations: See [RFC7464] Section 3 Contact: Applications and Real-Time Area Discussion (art@ietf.org), or any IESG designated successor. Author/Change controller: The Applications and Real-Time Area Working Group. IESG has change control over this registration. 5. Security Considerations All the security considerations of JSON Text Sequences [RFC7464] apply. They are as follows: All the security considerations of JSON [RFC7159] apply. This format provides no cryptographic integrity protection of any kind. As usual, parsers must operate on input that is assumed to be untrusted. This means that parsers must fail gracefully in the face of malicious inputs. Note that incremental JSON text parsers can produce partial results and later indicate failure to parse the remainder of a text. A sequence parser that uses an incremental JSON text parser might treat a sequence like '"foo"456' as a sequence of one element ("foo"), while a sequence parser that uses a non-incremental JSON text parser might treat the same sequence as being empty. This effect, and texts that fail to parse and are ignored, can be used to smuggle data past sequence parsers that don't warn about JSON text failures. Repeated parsing and re-encoding of a JSON text sequence can result in the addition (or stripping) of trailing LF bytes from (to) individual sequence element JSON texts. This can break signature validation. JSON has no canonical form for JSON texts, therefore neither does the JSON text sequence format. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Wilde Expires July 4, 2017 [Page 4] Internet-DraftA Media Type Structured Syntax Suffix for JSODecember 2016 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015, . 6.2. Informative References [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . Appendix A. Acknowledgements Thanks for comments and suggestions provided by Ben Campbell, Allan Doyle, Warren Kumari, Sean Leonard, Alexey Melnikov, Brian Raymor, and Peter Yee. Author's Address Erik Wilde CA Technologies Email: erik.wilde@dret.net URI: http://dret.net/netdret/ Wilde Expires July 4, 2017 [Page 5]